(adding René to cc) Hi Rajendra On Tue, 11 Jan 2011, Rajendra Nayak wrote: > > -----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 > > > > 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. OK, great - saw that you posted these. Will take a closer look. > 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. OK. The design of your initial implementation of these combined sleep/wakeup dependencies in the RFC series looks good to me. > > 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. OK, sounds good. > > 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. OK. > > 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 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. According to the 34xx TRM Rev. ZH section 4.8.5.2, both the GRPSEL and WKDEP bits need to be set for the target clockdomain to be awakened, if the target clockdomain contains a 'processor'. I had been under the impression that these were separate mechanisms. Is this also true for OMAP4 with the WKUPDEP/STATICDEP bits? The implication in section 3.1.1.1.7.3 is that the WKUPDEP bits are simply there for an 'acceleration'. > 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. OK, that's fine. You might want to touch base with René Sapiens on the GRPSEL/WKUPDEP stuff, I think he was looking at implementing GRPSEL control in software. Thanks for the summary, - Paul
