On Sunday 18 March 2007 7:27 pm, Ikhwan Lee wrote: > Hi, > > On 3/16/07, David Brownell <david-b@xxxxxxxxxxx> wrote: > > On Thursday 15 March 2007 8:56 pm, Ikhwan Lee wrote: > > > Hi, > > > > > > Although I agree that the current clock framework can handle power or > > > voltage domains in many platforms, having something like (struct clk > > > powerdomain1, powerdomain2;) does not seem like a good implementation, > > > a struct for clocks representing a power domain. > > > > Good thing that's not what I suggested then, right? :) > > > > The point was that in the examples I've seen, the power domains > > are associated with clock domains, so that each clock is tied > > to one power domain. And since you can't use the power domain > > without having a clock ... the implementation can tell if it's > > got to activate a power domain by looking at the clock. > > True, although sometimes it gets dirty because multiple clock sources > are associated with one power domain As clearly allowed for in what I wrote. clock->power_domain. > at the same time multiple power > domains are associated with one clock source. As also allowed for in what I wrote originally. clock->power_domains[]. > Simple parent and child > relationship provided by the clock framework is not always enough. Not implied in what I wrote. > > There may be other models of power domain, but that's the one > > I've had reason to look at (which isn't synonymous with a straight > > voltage/current supply). > > > > > > > If a new framework is more straighforward and introduces a negligible > > > overhead to the current kernel, I think it is worthwhile to have a > > > look at it. Plus this new framework might be able to take care of > > > those platforms that are not nicely supported by the current clock > > > framework. > > > > Perhaps when we see one, we could discuss that as somethong other > > than pure handwaving. But that still won't address the basic point > > that it's wrong to assume the clock framework should be written out > > of the picture. > > I think we can reach an agreement. The clock framework does not need > to be replaced with a new one since it is serving its purpose well > enough. If extra functionalities are needed for clocks, we can extend > the existing clock framework. Such extensions will include functions > like clk_set_rate_pending() and power_transaction_commit(). However, > since clocks and voltages (or power domains) have different > characteristics, it is desirable to have a separate framework for > power domains and associate that framework with the existing clock > framework. If the platform needs power domains to be exposed, yes. But I gave examples where it does NOT need to be exposed, since each clock was in a single power domain. > I am not sure if this is the direction that the original PowerOp > people suggested. If we can agree on this, however, I think we can > proceed to look at the code. I'm not sure why such agreement should be necessary before showing interface definitions. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
