On Thu, Apr 26, 2012 at 14:27:20, Paul Walmsley wrote:
> 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.
>
Why do you say that, clockdomain changes are not 100% separate from
clocktree? It is completely independent...
Thanks,
Vaibhav
--
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
