Could you guys present a clear definition of exactly what you mean by "clock domain" and "power domain"? I can think of several different ways to interpret the phrases, and I'd like to end up with the same meaning that you are arguing from... thanks, scott | From: David Brownell<david-b@xxxxxxxxxxx> | | 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 | -- scott preece motorola mobile devices, il67, 1800 s. oak st., champaign, il 61820 e-mail: preece@xxxxxxxxxxxx fax: +1-217-384-8550 phone: +1-217-384-8589 cell: +1-217-433-6114 pager: 2174336114@xxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
