Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

Hi,

On Fri, 2012-02-10 at 11:45 +0530, Archit Taneja wrote:
> For DSS clock domain to transition from idle to active state. It's necessary
> to enable the optional clock DSS_FCLK before we enable the module using the
> MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
> 
> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
> called for hdmi's platform device.
> 
> Since the clock domain failed to change it's state to active, the hwmod code
> disables any clocks it had enabled before for this hwmod. This led to the clock
> 'dss_48mhz_clk' gettind disabled.
> 
> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
> correctly enables the DSS clock domain this time. However, the clock
> 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
> disabled previously, the driver fails when it tries to enable HDMI's PHY.
> 
> Fix this for now by ensuring that dss_runtime_get() is called before we call
> pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
> be to modify the DSS related hwmod's mainclks, and also some changes in how
> opt clocks are handled in the DSS driver.
> 
> This fixes the issue of HDMI not working when it's the default display. The
> issue is not seen if any other display is already enabled as the first display
> would have correctly enabled the DSS clockdomain.

I think this looks fine, it's shouldn't have any side effects and is
easy to remove later.

Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]