OMAPDSS: HDMI: Removing previous HPD state check in HPD handler

Removing the previous HPD state check in the HPD handler. This
was resulting in HPD disconnect not being handled properly when
booted with HDMI connected.

Change-Id: Ie476544397701878ed53c0208ccf27981b51664d
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
OMAPDSS: HDMI: Fix for HDMI interlace timings

Y-res for HDMI interlace timings need to be set to half of the
actual timing to take interlaced frames into account.

Change-Id: I4024f415fbf1070912bc0aff81d36c195475db3d
Signed-off-by: Srinivas Pulukuru <srinivas.pulukuru@ti.com>
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
gpio/omap: fix invalid context restore of gpio bank-0

Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function if the function is populated for
a gpio bank. This function is used to determine if the gpio bank logic state
needs to be restored due to a power transition. This function will be populated
for all banks, but it should only be called for banks that have the
"loses_context" variable set. It is pointless to call this if loses_context is
false as we know the context will never be lost and will not need restoring.

For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will
never lose context. We found that the get_context_loss_count() was being called
for bank-0 during the probe and returning 1 instead of 0 indicating that the
context had been lost. This was causing the context restore function to be
called at probe time for this bank and because the context had never been saved,
was restoring an invalid state. This ultimately resulted in a crash [1].

This issue is a regression that was exposed by commit 1b1287032 (gpio/omap: fix
missing check in *_runtime_suspend()).

There are multiple bugs here that need to be addressed ...

1. Why the always-on power domain returns a context loss count of 1? This needs
   to be fixed in the power domain code [2]. However, the gpio driver should not
   assume the loss count is 0 to begin with.
2. The omap gpio driver should never be calling get_context_loss_count for a
   gpio bank in a always-on domain. This is pointless and adds unneccessary
   overhead.
3. The OMAP gpio driver assumes that the initial power domain context loss count
   will be 0 at the time the gpio driver is probed. However, it could be
   possible that this is not the case and an invalid context restore could be
   performed during the probe. To avoid this only populate the
   get_context_loss_count() function pointer after the initial call to
   pm_runtime_get() has occurred. This will ensure that the first
   pm_runtime_put() initialised the loss count correctly.

This patch addresses issues 2 and 3 above.

[1] http://marc.info/?l=linux-omap&m=134065775323775&w=2
[2] http://marc.info/?l=linux-omap&m=134100413303810&w=2

Cc: Kevin Hilman <khilman@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Franky Lin <frankyl@broadcom.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: NeilBrown <neilb@suse.de>

Reported-by: Franky Lin <frankyl@broadcom.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Franky Lin <frankyl@broadcom.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3.  This prevents device low power
states.

The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active.  This in turn prevents the WKUP
clockdomain from transitioning to idle.  There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.

It turns out that there is no need to take the 32k sync timer out of
idle.  The IP block itself probably does not have any native idle
handling at all, due to its simplicity.  Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active.  So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.

This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive.  If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled.  The
WKUP clockdomains on OMAP3/4 are marked with this flag.  (On OMAP2xxx,
no OCP header existed on the 32k sync timer.)   Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.

Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses.  These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource.  But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.

Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI.  But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.

This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.

Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch.  Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch.  Thanks to BenoÃ®t Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.

References:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
   (SWPU223U), available from:
   http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
   (SWPU223U)

3. ibid.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: BenoÃ®t Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
ARM: OMAP2+: Fix Wake-up power domain power status

Note: Re-sending with updated kernel doc.

The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.

To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.

This is based upon Tony's current linux-omap master branch.

Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
  Paul's 32k timer patch [1]).

[1] http://marc.info/?l=linux-omap&m=134000053229888&w=2

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Merge branch 'p-linux-omap-3.4' into p-android-omap-3.4

* p-linux-omap-3.4:
  ARM: OMAP2+: Fix Wake-up power domain power status
  ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer
  gpio/omap: fix invalid context restore of gpio bank-0
Revert "Revert "Revert "HACK: OMAP: rpmsg: do a frequency search on floor for ducati requests"""

This reverts commit bdab53a6b97b8f273970ff9b22ad145e72712082.
Final revert of this HACK.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAP5sevm: Add IRQ and GPIO offset for the i/o expander

Add the IRQ and the GPIO offset for the TCA6426 i/o expander

Change-Id: Ibd38a6c747a5029e0eaa641dbcd17ecccb0d094a
Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAP: Serial: fix compiler error, add missing comma

Also make function "inline", to prevent creation of useless
code in the kernel binary.

Change-Id: Ifd8c98f983334c85983e5336814b167245fd2f43
Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
ASoC: omap-mcbsp: Avoid unneeded fclk reparenting

McBSP functional clock reparenting will fail if attempted while the
module is already active. McBSP module will be active when its DAI
goes through startup() and  McBSP fclk reparenting is normally called
from DAI link hw_params().

For instance, let's assume McBSP is used for both, playback and capture:
- McBSP playback startup() - McBSP clocks are enabled
- ...
- DAI link playback hw_params() - fclk is reparented properly since
  McBSP is used only by one stream (clocks are gated during reparenting)

- McBSP capture startup() - McBSP clocks are still enabled, but now
  is used by two streams
- ...
- DAI link capture hw_params() - fclk is again trying to be reparented
  to the same parent we already configured for playback direction

In above scenario, capture stream will fail as we try to reparent a
running clock. This can be prevented by avoid unnecessary reparenting.

Change-Id: I20b529d534971572c405bb3f6643d424b69713e3
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
ASoC: omap-abe-twl6040: Remove redundant params check

PCM hw_params passed to hw_params() handlers is error-checked by PCM
native layer before it gets to the low-level drivers' handlers, so
checking "params" pointer in modem hw_params() is redundant.

Change-Id: Ic7763a173e2191b1618c7d6a70683b83bb087f79
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
ASoC: omap-abe-twl6040: Set McBSP threshold only for BEs

McBSP threshold is set in machine driver to match ABE ATC configuration,
so it's applicable only for BEs and shouldn't be set for legacy DAI links
as in that case is handled by McBSP DAI driver.

Change-Id: I7bcdb45913b622fc7e1826af704d1bc3bb8c345b
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
ASoC: omap-abe-twl6040: Use exact McBSP fclk rate

Clock rate used to configure McBSP functional clock was calculated
based on the stream rate. This approach fails when McBSP is connected
to an ABE BE and that BE is used by FEs with different sample rate.
In this scenario, there are two functional clock rates requested so
the last to get requested fails.

The actual clock rate of McBSP functional clock can be retrieved using
the clock framework. Specifically, the rate of the internal clock (also
known as "prcm_fck") is queried as this will be the parent of McBSP
functional clock.

Change-Id: I486664401f3f6246a86d7b9795a8938765a6d048
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
OMAP: hwmod: Disable module when hwmod enable fails

Clock and module mode are explictly enable when hwmod is enabled. But if
the hwmod doesn't get ready on time, clocks are disabled but module is left
enabled.

Change-Id: I0b62f6cd4a7feee6a483f6525177f83787845545
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Merge branch 'p-linux-omap-3.4' into p-android-omap-3.4

* p-linux-omap-3.4:
  OMAP: hwmod: Disable module when hwmod enable fails
  ASoC: omap-abe-twl6040: Use exact McBSP fclk rate
  ASoC: omap-abe-twl6040: Set McBSP threshold only for BEs
  ASoC: omap-abe-twl6040: Remove redundant params check
  ASoC: omap-mcbsp: Avoid unneeded fclk reparenting
  OMAP: Serial: fix compiler error, add missing comma
  OMAP5sevm: Add IRQ and GPIO offset for the i/o expander
gpu: ion: omap: Rename OMAP_ION_HEAP_SYSTEM_HEAP enum

Rename OMAP_ION_HEAP_SYSTEM_HEAP to OMAP_ION_HEAP_SYSTEM

Change-Id: I5ce8e22ed3616099d99d721ac2326d6f60062e6d
Signed-off-by: Rodrigo Obregon <robregon@ti.com>
Video: Protect the dispc error worker from NULL pointer

With HDMI default display the mgr and mgr->device will be NULL
which causes a panic.
Protect against dereferencing a NULL pointer

Change-Id: I4f10fdcc28b4215373126f362b964af417692a7a
Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAPDSS: HDMI: do not set reg HDMI_TXPHY_POWER_CTRL for OMAP5

Do not set register HDMI_TXPHY_POWER_CTRL for OMAP5 as it is
unused in OMAP5. Setting it is resulting in PHY transition error.

Change-Id: Id90f433d5e7017244bf613a582def9ffb993dcaa
Signed-off-by: Fairuz WAN ISMAIL <f-wanismail@ti.com>
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>
Merge remote-tracking branch 'remotes/omapzoom/p-android-omap-3.4' into NTkernel3.4
USB: DWC: dwc3-omap: Fix enum when USB cable is connected during suspend state

If a USB cable is connected when the system is suspended, the enumeration fails
since the get_sync in dwc fails. This is root caused to get_sync being called
even before the runtime is fully up. It is fixed by scheduling a delayed work
that sets the mailbox after some delay.

[m-sonasath@ti.com]
dwc->is_connected is used to prevent the system from entering suspend if a work
has been scheduled but not yet been executed.

Change-Id: I649b3fe8a971fbe376e49b47f42ff73e97e72acf
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
Signed-off-by: Partha Basak <p-basak2@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>