Re: OMAP4 DSS clock setup

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

Hi Paul,

On 4/7/2011 9:27 PM, Paul Walmsley wrote:
> Hello Tomi, Benoît,
>
> On Mon, 4 Apr 2011, Tomi Valkeinen wrote:
>
>> On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote:
>>
>>> Based on the E-mail thread so far, I'd say that changing the clock aliases
>>> is the way to go for right now.  The clock aliases are not hardware data;
>>> they just control how the clock hardware is mapped to the drivers.
>>
>> I'd very much prefer this option. Below is a patch for this.
>>
>> If Benoit doesn't complain too much about this, I'd like to get this
>> merged as soon as possible, as OMAP4 DSS is currently crashing in the
>> mainline kernel.
>
> I will queue your clock aliases patch and attempt to merge it upstream for
> the -rc series.  I am not happy to be disagreeing with Benoît here, but
> this is the rationale that I am using.  (Benoît, Tomi, please feel free to
> correct if there is something blatantly false below.)

That's quite good that you were disagreeing with me, because I think 
that you are indeed right:-)

> 1. The integration of the DSS module is an unusual case.  The
>     MODULEMODE bits for the DSS bits do not control the DSS "main"
>     functional clock (the clock that is needed to access device
>     registers); instead, they only control the DSS interface clock.
>     (This is because the DSS can use a functional clock that is not
>     provided by the OMAP core.)  So calling the DSS MODULEMODE struct
>     clk "dss_fck" is not really correct, since it is really controlling
>     the interface clock.

I've just got the confirmation from a PRCM designer that this is indeed 
what is happening.

In the case of the DSS the optional functional clocks are provided by 
the PRCM and thus managed by the PRCM. The only difference is that since 
two different functional clocks are available, the PRCM cannot chose 
automatically the proper one.
Hence the term optional fck, meaning that the SW has to explicitly 
enable them. The PRCM will not do it when modulemode will be enabled.

So in that case enabling the modulemode will effectively enable the 
module for the PRCM point of view and just request the iclk if not 
already available.

The only point that we need to take care of is the sequence.
The PRCM spec clearly specify that one of the optional clock must be 
active before the modulemode is enabled.
That does not seems to be the case in the current DSS code.

> 2. This patch does not create a precedent for hacking around general
>     driver clocking problems in the clock or clock data.  This is only
>     needed because the MODULEMODE bits don't control the module
>     functional clock in this case.  As I understand it, the only other
>     device that this problem could occur with is McBSP, due to
>     mcbsp_clks.

In that case this is slightly different because even the PRCM does not 
control these external clocks. Whereas in the case of the dss_fck, if 
the DPLL is not locked when you request it, it will be enabled 
automatically. Assuming that auto mode are enabled.

> 3. The existing DSS2 driver clock design apparently works fine when
>     this change is implemented[1], so no driver changes will be needed.

Yeah, but my point was that driver changes will be needed anyway, hence 
my preference to hack the driver instead of hacking the clock data.

> 4. The proposed DSS driver patch to work around this uses a nasty hack
>     that really should be NACK'ed[2].
>
> All this said, we may not be able to merge this change upstream, due to
> the recent unhappiness about the clock data changes.  If Linus rejects it,
> you'll need a "Plan B."

That's was my #2 concern as well.

See you soon at ELC.

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html