On Thursday 20 March 2008, Rafael J. Wysocki wrote:
> Is there any reason why pci_choose_state() should try to figure out what kind
> of operation is being performed by the driver and tailor its output to that?
It's always been specified to do that ... but it's always done
that in a buggy way. (Which is why USB never used it.)
> I don't think so. Rather, the driver should know what it's doing and either
> call pci_choose_state() or not. If the state of the device is not to be
> changed, there's no reason to call pci_choose_state() at all.
You seem to object to letting drivers offload this particular
bit of work to infrastructure. What's the dividing line between
being OK to offload vs not eing OK? Why not let the drivers make
that choice?
> [Note that with the new suspend/hibernation callbacks there
> won't be the pm_message_t argument to pass to pci_choose_state().]
The pm_message_t will necessarily linger until all drivers have
been converted and re-tested. Which can't be an overnight thing.
> Now, we need to settle _what_ exactly pci_choose_state() is supposed
> to return, because it's not clear right now.
Kerneldoc says:
* Returns PCI power state suitable for given device and given system
* power state transition.
Some comments added by $SUBJECT also clarify:
/* NOTE: platform_pci_choose_state() should only return
* states where wakeup won't work if
* - !device_may_wakeup(&dev->dev), or
* - dev can't wake from the target system state
*/
That happens to be what acpi_pm_device_sleep_state() computes;
there may not be other implementations of that call, yet. I can
imagine a default that would look at PCI PM capabilities, to be
used on non-ACPI platforms.
> Should that be the lowest power
> state in which the device can be in given system state (that's what
> platform_pci_choose_state() will return)?
Actually the comment above is the *entirety* of the docs for
that call: it chooses a state. You're asking a question of
policy (how/why it chooses); that's outside the scope of PCI.
> Or should that be the highest power
> state in which the device can be in given system state?
> Or anything else?
It happens that the current Linux ACPI glue chooses the
lowest power PCI state that's compatible with the target
system state ... optimizing for power savings rather than
for quick resumes.
It might make sense to support a policy that optimizes for
fast resumes from some states. But I can't see that'd be
worth much effort at this point, with bigger fish to fry!
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
