Re: OMAP4 DSS clock setup

Paul Walmsley
2011-04-08T14:55:38Z

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

Hi

On Fri, 8 Apr 2011, Tomi Valkeinen wrote:
> On Thu, 2011-04-07 at 13:27 -0600, Paul Walmsley wrote:
> > 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.
>
> If we don't apply the patch, I think the clock aliases are still broken.
> Let's forget the ick/fck thing for a second, and just think the clock
> from PRCM which is used as the source clock for pixel clock. That is
> currently called "fck" on OMAP2/3, but "dss_dss_clk" on OMAP4. This
> cannot be right, can it? From DSS's point of view that is the same
> clock, it should clearly have the same alias on all platforms. I don't
> care what the name is as long as it's consistent on all platforms.

Yes, I agree. That is another good point.

> And I have to say I still don't quite get it what is the problem with
> "fck" name.

After the hwmod/PM runtime conversion, there shouldn't be any clock
aliases left that are simply called "fck", because it is almost a
meaningless name.

> Or is that meant to be a clock which enables the registers
> on the module,

After the hwmod/PM runtime conversion, that should have an alias name of
"main" that is automatically added by the omap_device code. (Note that it
does not appear to do so now; that is a bug that needs be fixed.)

> and not the clock used for the pixel clock? If so, I'm fine with having
> "fck" to be what it is currently, but then we need a new name for the
> clock used for pixel clock, which is consistent on all platforms.

If there is a separate PRCM-provided clock used only for the pixel clock,
then that clock should have an alias name of "system_pixel_ck" or
something similar that is meaningful to the DSS driver. I think the
problem in this case is that "dss_dss_clk" is (optionally) used for two
purposes: optionally as a "main PRCM-provided functional clock" and
optionally as a system-provided pixel clock.

I'll reply to the rest of your mail in a separate E-mail...

- Paul