Re: Re: Platform-specific system power states

[David Brownell <david-b@pacbell.net>]

On Friday 22 June 2007, Rafael J. Wysocki wrote:
> On Friday, 22 June 2007 21:49, David Brownell wrote:

> > and as for querying, the many power-related resources involved would seem to
> > be clocks and power domains.  ACPI has an internal notion of the latter, but 
> > skips the former.  You've seen my proposal for what seems to be sufficient in
> > the case of clocks.  (And one of these days I'm sure I'll push it upstream.
> > After that new method lands, to replace the now-missing functionality...)
> 
> In fact the ACPI spec regards clock sources as power resources.  More
> precisely, it defines a power resource as "resources (for example, power planes
> and clock sources) that a device requires to operate in a given power state"
> (Section 2.1 in the 3.0b spec).  Perhaps we also could use a general notion of
> "power resource" in a similar fashion?

The problem with claiming that ACPI has a notion of clocks is that it
doesn't have any clock-like semantics.  Like getting/setting rates,
reparenting, and so forth ... everything the clk_*() interfaces do.
At best it has "stuff that can be enabled/disabled".


Related:  Linux doesn't even expose the limited notion of power resource
that ACPI packages.  And, as shown by some comments on one patch I posted,
even that notion needs work before it behaves.  ISTR the issue was that
the ACPI power methods apply to PCI functions, but the resources applied
to PCI devices.  So in the absense of refcounting, powering down one
function would surprisingly enough power them all down... absolutely
contrary to the intent of powering down just that function.

There's probably some generalizable notion lurking there, but clearly it's
not cooked in today's Linux ACPI stack.

And suffice it to say that I've seen work with such "general notions"
blow up so regularly (the basic crime being loss of contact with real
world problems, leading to useless code bloat) that my first reaction
is almost always "no, don't generalize yet, solve some problems first".

Hence my ongoing belief that we need voltage abstractions (both producer
and consumer) resembling the current clock abstraction, before we start
to think about grouping the two under some umbrella.

- Dave