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
