RE: RE: on-ness

Woodruff, Richard
2006-04-24T21:32:54Z

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

> Are they? Does "off" imply the device will have been reset the next
> time it goes to "on"? If not, there would seem to be two "off"
states.
> Or maybe more ... PCI_D0 is probably "on", but all of the other PCI
> device states seem to be variants of "off", not of "on".

That would seem device specific. It would seem that applying a reset
when moving from "off" (especially that mapped to PCI_D3) would seem
reasonable. As I was told, the rest of the PCI defined states D1-D3 are
non-functional. So they are all OFF states. If just happens that in D3
you can safely physically remove the device. The current pseudo export
of these non-functional states doesn't seem so useful. Having some
fuzzy level of idleness seems much better.

The point of the idle states Len was floating attempts to define a level
of on-ness/idleness. As it turns out there was a nice correlation to
some ACPI states. Numbering them seems reasonable, else your just
wasting effort translating 'state0, state1, state2, ...', keeping the
naming convention simple '0,1,2,..0xffff' would seem to lend itself to
code sharing of necessary class/device specific translation code.

> Actually the wakeup characteristics are orthogonal, there are
per-device
> bits controlling whether a device can and should do the wakeup. We
don't
> for example treat "PCI_D3hot with wakeup" as a distinct state.

In my current hack attempts I am trying to associate a 'device' D2 state
with a local device sleep with an async wake up enabled. In this state
a devices accesses are locked out until the device wake up event
happens. This async wake can be from a device specific wake up or from
an associated timer resource. Current DPM enabled OMAP sprinkles
suspend lock outs inside of drivers which re-suspend queued waiters and
suspends new requests if the device is in a locked out state. From many
devices this creates a device which just reacts with a higher latency.

Regards,
Richard W.