Re: OMAP4 DSS clock setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux