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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
