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.) 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. 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. 3. The existing DSS2 driver clock design apparently works fine when this change is implemented[1], so no driver changes will be needed. 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." ... Also, I hope you and the other DSS hackers can finish the PM runtime conversion of the DSS driver soon. Ideally before any new DSS features are added. We really need to be able to separate the OMAP integration details from the drivers, and right now, hwmod and PM runtime are the best way we have to do that. Comments welcome. - Paul 1. Valkeinen, Tomi. _Re: OMAP4 DSS clock setup_. E-mail to linux-omap@xxxxxxxxxxxxxxx mailing list dated Wed, 30 Mar 2011 05:59:06 -0700. <http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg47665.html> 2. ibid.
