Hi Paul, > -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Tuesday, January 11, 2011 7:02 AM > To: Rajendra Nayak > Cc: linux-omap@xxxxxxxxxxxxxxx; khilman@xxxxxxxxxxxxxxxxxxx; b-cousson@xxxxxx > Subject: Re: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps > > On Wed, 5 Jan 2011, Rajendra Nayak wrote: > > > Define the following architecture specific funtions for omap2/3 > > .clkdm_add_wkdep > > .clkdm_del_wkdep > > .clkdm_read_wkdep > > .clkdm_clear_all_wkdeps > > .clkdm_add_sleepdep > > .clkdm_del_sleepdep > > .clkdm_read_sleepdep > > .clkdm_clear_all_sleepdeps > > > > Convert the platform-independent framework to call these functions. > > With this also move the clkdm lookups for all wkdep_srcs and > > sleepdep_srcs at clkdm_init. > > > > Signed-off-by: Rajendra Nayak <rnayak@xxxxxx> > > --- > > arch/arm/mach-omap2/Makefile | 2 + > > arch/arm/mach-omap2/clockdomain.c | 80 ++++++--------- > > arch/arm/mach-omap2/clockdomain.h | 2 + > > arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 113 ++++++++++++++++++++++ > > arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 2 +- > > This is definitely a good start, but a lot of OMAP4 stuff still needs > to be done. > > For example, OMAP4 has static wakeup dependencies just like OMAP2/3; > described in section 3.1.1.1.7.3 "Wake-Up Dependency" of the OMAP4430 TRM > Rev. L. > > OMAP4 also has static sleep dependencies just like OMAP3; described in > section 3.1.1.1.7.1 "Static Dependency" of the OMAP4430 TRM > Rev. L. I already have some patches to support static dependencies for OMAP4. Still working towards getting the autogen scripts in place, they seem to be a bit out of sync with whats in mainline today for clockdomains. I can post early patches as RFC to get your views on it. The only difference wrt OMAP3 is there is no control on OMAP4 to set/clear sleep and wakeup dependencies separately and hence they are called Static dependency and not 'Static wakeup' or 'Static sleep'. Setting a static dependency between clock domains on OMAP4 means setting sleep *as well as* wakeup dependency. > > The dynamic wakeup dependencies (section 3.1.1.1.7.2 of the TRM) and the > hardware inactivity timer are new for OMAP4. > > What's the plan to add support for these? I will be working on supporting these as well. Can be supported easily on top of the clockdomain split series. Still need to get the autogen scripts updated to generate the dynamic dependency data. > > Based on a brief look, it would seem to make sense to add support now for > static sleep dependencies. These seem quite similar to the OMAP3 > implementation, in that they are between clockdomains. Again like I said above, my next patch series will add support for static (sleep and wakeup) dependencies. The other 'wakeup dependency' that the TRM section 3.1.1.1.7.3 talks about is slightly different. See my comments below. > > Dynamic wakeup dependencies and the prescaler timer configuration should > be fairly easy to add since it is a new feature, and thus no OMAP2/3 > implementation is needed. The dyndep stuff is between clockdomains, so > there shouldn't be any interaction needed with the hwmod code by my > reading. > > Static wakeup dependency support appears a little more tricky, since the > dependencies are between modules and clockdomains on OMAP4, rather than > between clockdomains and clockdomains as they were on OMAP2/3. One way to > handle this would be to change the existing wkdep interface for all OMAPs > to be between modules and clockdomains; then for the OMAP2/3 > implementations, use the hwmod code/data to get the clockdomain of the > module's main_clk. Another is to add a separate interface to add wkdeps > between a module and clockdomain, use that for OMAP4, but use the existing > clockdomain-to-clockdomain interface for OMAP2/3. It might be necessary > to do both until the hwmod data is more complete, then perhaps phase out > the latter interface. Thoughts? The wakeup dependency here (between a module and a clock domain) is very different from the static dependency (between clock domains) and is very much like what the PM_<processor>_GRPSEL registers handled in OMAP3. They are used to control which processor is woken up on a given module/ peripheral wakeup event. I have not given much thought on this for now but looks like this needs to be handled in some way using hwmod itself. I need to work some more to see how this can be handled. Regards, Rajendra > > > - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
