Re: OMAP4 DSS clock setup

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

Hi Archit,

On 3/31/2011 8:42 AM, Taneja, Archit wrote:
> On Wednesday 30 March 2011 06:51 PM, Cousson, Benoit wrote:
>> On 3/30/2011 2:58 PM, Valkeinen, Tomi wrote:
>>> On Wed, 2011-03-30 at 14:12 +0200, Cousson, Benoit wrote:
>>>> On 3/30/2011 1:03 PM, Valkeinen, Tomi wrote:
>>>>> On Wed, 2011-03-30 at 11:32 +0200, Cousson, Benoit wrote:
>>>>>> Hi Tomi,
>>>>>>
>>>>>> On 3/30/2011 8:48 AM, Valkeinen, Tomi wrote:
>>>>>>> Hi Benoit, Paul,
>>>>>>>
>>>>>>> I've been discussing with Sumit and Archit to understand how the DSS
>>>>>>> clocks are set up on OMAP4. I think I now have some idea how things
>>>>>>> work, but I'm still at loss why things are the way they are.
>>>>>>>
>>>>>>> So, if I look at OMAP4 TRM, Figure 10-4 DSS Clock Tree, there are two
>>>>>>> clocks in PRCM block that are relevant to this discussion: DSS_L3_ICLK
>>>>>>> and DSS_FCLK. To my understanding DSS_L3_ICLK is not really
>>>>>>> controllable, but it is affected by MODULEMODE bit.
>>>>>>>
>>>>>>> Then we have two relevant clocks defined in clock44xx_data.c: dss_fck
>>>>>>> and dss_dss_clk. dss_fck controls the MODULEMODE bit, and dss_dss_clk is
>>>>>>> the TRM's DSS_FCLK.
>>>>>>>
>>>>>>> Was that correct?
>>>>>>
>>>>>> Yes. For the moment, but this is not the final state.
>>>>>>
>>>>>>> If so, from DSS driver's perspective, the dss_fck sounds very much like
>>>>>>> an interface clock (it's always needed when DSS is used) and dss_dss_clk
>>>>>>> sounds very much like functional clock (it's always needed, except if
>>>>>>> DSI PLL is used for DSS functional clock).
>>>>
>>>> dss_dss_fck is one of the possible functional clocks, hence the optional
>>>> attribute. You can run the DSS only for sys_clk is you want.
>>>
>>> We can? I remember this was possible on OMAP2, but I can't seem to find
>>> it on OMAP4 TRM...
>>>
>>> Ah right, you mean sys_clk goes to DSI PLL, and the output from DSI PLL
>>> can be used as functional clock?
>>
>> Yes, you're right, maybe we can still use the sys_clk directly with a
>> parallel QVGA LCD like on OMAP2:-)
>>
>>> We _always_ need DSS_FCLK to get DSS up and running, and to configure
>>> DSI PLL if we want to get the clocks from there. So it's not quite that
>>> optional. But it's true that we can turn it off later.
>
> Just wanted to clarify the issue for myself and summarise:
>
> hwmod and pm runtime ensures that the MODULEMODE bits are set, and
> technically, that should be enough for a module to get up and running.
> But because of the strange design of DSS HW, we need an additional clock
> (DSS_CLK at bootup, could be something else later on) to access DSS
> registers. So we need to enable dss_dss_fclk in our driver in the
> beginning itself to access a register, hence Sumit's patch is needed.
>
> The strange thing is that if dss_dss_fclk is
> off(OMAP4430_OPTFCLKEN_DSSCLK bit is 0) it doesn't mean that the clock
> is surely OFF. Its only OFF when the DPLL per m5x2 divider allows HW
> auto-gating of the clock.

Hehe, welcome to the PRCM world :-)

> So OPTCLKEN_DSSCLK is in a way a dummy bit which when set, ensures that
> the M5 divider doesn't auto gate. So it isn't exactly a enable/disable bit.

It is the case for most clocks in the system. You know when it is 
enabled, but it will be disabled only when the clock domain or in that 
case the parent clock will do HW auto gating.
In this case there is no intermediate gating because the DSS_CLK is the 
only user of the M5 HW divider output, so gating only the parent is enough.

> In our tree(2.6.38-rc series), HW auto gating bit was disabled for m5x2
> divider, and hence, it never mattered to us if OPTCLKEN_DSSCLK was
> enabled or disabled. We went on happily without bothering about this opt
> clock.
>
> When things got merged in mainline, the HW auto gating for m5x2 came
> into picture(HSDIVIDER_CLKOUT2_GATE_CTRL in CM_DIV_M5_DPLL_PER), and
> then suddenly dss_dss_fclk became super crucial, and a register access
> depended on it. This was the main reason of the confusion I guess.

That make sense now, in theory, all these HS divider should be autogated 
by default, it was not the case previously because we were still in a 
non-PM optimize mode. That's why you have to control the clock at your 
level to ensure that the HW will not gate the parent clock.

Benoit