[PATCH 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces

[Archit Taneja]

Hi Paul,

On Friday 04 May 2012 12:09 PM, Paul Walmsley wrote:
> Hi Archit,
>
> On Fri, 13 Apr 2012, Archit Taneja wrote:
>
>> On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote:
>>> On 4/13/2012 10:01 AM, Archit Taneja wrote:
>>>> The clock for all DSS L3 slave interfaces had been recently changed to
>>>> "dss_fck" from "l3_div_ck". "dss_fck" is an optional clock in DSS
>>>> clock domain
>>>> which can't autoidle when enabled.
>>>>
>>>> Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS
>>>> hwmods so
>>>> that clock is explicitly enabled and disabled by software. Without this,
>>>> "dss_fck" would be left as enabled and the OMAP4 device won't idle
>>>> even when
>>>> DSS is not in use.
>>>
>>> Yeah, that was done on purpose with Tomi knowning well that limitation.
>>>
>>> The issue was mainly due to the lack of proper parent / child
>>> relationship between the DSS (the whole subsystem) and the DSS children
>>> at that time.
>>>
>>> I think that Tomi posted a series to fix that for 3.4. So if we ensure
>>> that every DSS IPs are children of the DSS, then pm_runtime will always
>>> ensure that the DSS will be enabled each time a submodule is used.
>>>
>>> So the right fix is to put back the proper iclk (l3_div) to the DSS
>>> instead of the dss_fck.
>>
>> Ok, I get it now. Tomi's patch series ensured the parent-child
>> dependency, but they didn't switch the iclks back to l3_div, I guess
>> that should be a part of the series too.
>
> Just checking on this one.  Does this patch need to be updated ?
>

We were working on this, but we realised that only having a parent-child 
relation in dss platform devices won't be sufficient to remove "the use 
of dss_fck(or MODULEMODE bits) as a slave clock" hack.

The issue is that during bootup(when omap_hwmod_setup_all() is called), 
all hwmods are enabled independently, so all dss hwmods need to enable 
the MODULEMODE bits for them to be setup correctly.

With the parent-child relation in platform devices in DSS, only the 
parent platform device's hwmod("dss_core" in our case) should enable and 
disable the MODULEMODE bits. If the children also become capable of 
enabling/disabling it, then things wouldn't work.

Hence, to go ahead with this approach, the hwmod's themselves need to 
have some sort of parent child relationship, or atleast some sort of use 
counting for MODULEMODE bits. Benoit and Tomi could comment more on this.

Hence we are sort of stuck :)

Archit

>
> - Paul
>