On Thu, 26 Apr 2012, Hiremath, Vaibhav wrote:
> On Thu, Apr 26, 2012 at 08:49:28, Paul Walmsley wrote:
(attribution lost)
> > > > Also, since we're not defining any autodeps for the AM335x platform, we
> > > > shouldn't need the CLKDM_NO_AUTODEPS flag either? Since no autodeps are
> > > > defined, the default will be to not set any autodeps.
> > > >
> > >
> > > This is required to avoid few "pr_debug", if you don't provide it.
> > > For example, without this flag set, you will get,
> > >
> > > pr_debug("clockdomain: hardware cannot set/clear sleep "
> > > "dependency affecting %s from %s\n", clkdm1->name,
> > > clkdm2->name);
> > >
> > > Refer to the file omap_hwmod.c, function, _enable(), the call sequence is,
> > >
> > > _enable() => _add_initiator_dep() => clkdm_add_sleepdep() =>leads to warning
> >
> > Seems like the better thing to do is to just avoid calling
> > _{add,del}_initiator_dep() on the AM335x.
> >
>
> Don't you think, if flag is doing all the job, why to pollute code with
> cpu_is_am33xx() checks.
That's not what that flag was intended to do. It was originally intended
for OMAP3xxx, to allow autodeps to be disabled for some clockdomains,
while leaving them enabled for others.
If autodeps are completely unneeded, as they are for AM335x, for slower
cores like the Cortex-A8, it seems best to avoid executing any
superfluous code.
> Yeah, I realized it, after your comment; its copy thing...Will correct in
> next version.
I've dropped those lines from the description in the local copy here.
> I am thinking of separating clocktree patch (PATCH-V3 3/3) from this series,
> so that clockdomain stuff can get in independently, and clocktree anyway
> will follow them (it may take some time in review cycle).
Yes, I was thinking of doing this too. The only aspect that gave me pause
is that the clockdomain changes are not 100% separate from the clock tree.
So we may have to update the clockdomain data as the clock tree changes.
- 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
