Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support

["Cousson, Benoit" <b-cousson@ti.com>]

On 6/8/2011 9:55 AM, Valkeinen, Tomi wrote:
> On Tue, 2011-06-07 at 18:43 +0200, Cousson, Benoit wrote:
>> On 6/7/2011 1:51 PM, Valkeinen, Tomi wrote:
>>> On Tue, 2011-06-07 at 13:37 +0200, Cousson, Benoit wrote:
>
>>>> The issue is that there is only one modulemode for the whole DSS.
>>>> Potentially only the dss_hwmod should have it. But then you have to
>>>> ensure that this device is enabled before any other DSS devices.
>>>
>>> Does that change anything? Isn't the above (modulemode enabled before
>>> opt clock) still true, even if it was enabled only once for the dss_core
>>> hwmod?
>>
>> It does not really change anything, but it is more accurate.
>> Modulemode need to be enable after the opt clocks that act as a
>> functional clock and before enabling HW_AUTO for the clockdomain.
>>
>> The important parameter is the clock domain mode change. It is another
>> issue that we have to fix. It might not affect you for the moment.
>
> Ok. But the main issue now is the PM. If I change the clocks in hwmod
> data as you suggested, dss_fck will always stay enabled and prevent RET
> and OFF. So the fix is not acceptable even for temporary use.

Mmm, the issue is probably due to the way we are managing interface 
clock that are usually able to autoidle. Because of that the 
_disable_clocks function will not try to disable an interface clock 
except if you use the following flag: OCPIF_SWSUP_IDLE.

  static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss = {
  	.master		= &omap44xx_l3_main_2_hwmod,
  	.slave		= &omap44xx_dss_hwmod,
	.clk		= "dss_fck",
  	.addr		= omap44xx_dss_dma_addrs,
  	.addr_cnt	= ARRAY_SIZE(omap44xx_dss_dma_addrs),
  	.user		= OCP_USER_SDMA,
+	.flags 		= OCPIF_SWSUP_IDLE,

>
> So is there some way to fix this, or shall we just go forward with the
> current patch series having the somewhat hacky way to use pm_runtime?
>
> I would personally like to get the driver right from the start, even if
> that means more hacks in the hwmod fmwk (because that's where the
> problems are). But if that is very difficult, I'm fine with the current
> patch series.

I hope we'll be able to fix the fmwk for 3.0.1.

Benoit