Re: [RFC 3/3] Runtime PM support for named power states

[Pavel Machek <pavel@suse.cz>]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hi!

> > I think they need to go in one-after-one, anyway... Adding parameter
> > to resume() should definitely be separate patch, because it needs to
> > change all drivers *at once*.  Removing power_state usage can be
> > done incrementally...
> 
> I suppose it could be done like that.  It would mean keeping the
> power_state member in the structure until all the drivers are updated,
> even though the core wouldn't use it any more.

Yes... small price for being able to fix stuff incrementally.

> Another question: Initially most drivers won't set up an array of named
> states.  We could have the core treat such devices as though they were
> using a generic two-entry array: "on" and "suspend".  That would provide
> by default essentially the same functionality we have now, and it would
> allow many drivers to use the new runtime PM scheme with (almost) no
> changes.  Do you see anything wrong with that?

It will be broken for most existing drivers, anyway... I'd only enable
it if driver provided states.

> Third question: Is there a usable PCI core routine for choosing power
> states?  If not, should a PCI ->suspend method usually use the
> lowest-power available state?  I have a feeling this should involve ACPI,
> but it looks like the code hasn't been written yet.

pci_choose_state()? It even has some acpi hooks.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]