[PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations

[Hiremath, Vaibhav]

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