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
