Re: OMAP4 DSS clock setup

Paul Walmsley
2011-04-07T19:27:55Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2767 bytes --]

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@vger.kernel.org mailing list dated Wed, 30 Mar 2011 05:59:06
-0700.
<http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47665.html>

2. ibid.