RE: [PATCH 2/5] OMAP: clockdomain: Arch specific funcs to handle deps

[Rajendra Nayak <rnayak@ti.com>]

Hi Paul,

<..>..
>
> > > 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'.

Yes, on OMAP4, these are used to accelerate wakeup transition
by parallelizing wakeup on several domains.
Both the func spec and the TRM seem to mention that System would
work *without* them, but with slower wakeup transitions, due to the
cascading of wakeup transition over several domains.

Also Table 3-13 in TRM Section 3.1.1.1.6 mentions the following
conditions OR'ed for a clockdomain Wakeup to happen

The SW_WKUP clock transition mode for the clock domain is set. (CLKTRCTRL
= 0x2)
OR At least one wake-up request asserted by one of the modules of the
clock domain.
OR At least one dynamic dependency(1) from another clock domain is active.
OR At least one static dependency(1) from another clock domain is active.
OR At least one wake-up dependency(1) from a module in another clock
domain is active.

>
> >  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.

Sure, will get in touch with him.

Thanks,
Rajendra

>
> Thanks for the summary,
>
>
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html