Re: Totally broken PCI PM calls

[Nigel Cunningham]

Hi.

On Tue, 2004-10-12 at 14:02, Benjamin Herrenschmidt wrote:

[...]

> An example of the difference between device state and driver state: a
> system "idle" state want devices to be put into some sort of D1 state,
> that is power managed with very fast wakeup. On another hand,
> suspend-to-disk don't care about devices beeing put in any power state
> at all, but the driver must be "frozen" in a consistent state (not
> process requests etc...) so we get a consistent image.

> In the first case, it makes even sense to keep the driver operating
> while the device is D1, the driver would then just wake the device on an
> incoming request (provided this is allowed by the policy). In the later
> case, the driver state is the only thing that matters.

Not quite - you have to be able to get the device into a matching state
at resume time. Probably not a problem in most cases, I realise, but
thought it was worth a mention.

[...]

> Yup, with the exception that it becomes hell when those devices are
> anywhere on the VM path... which makes userspace policy unuseable for
> system suspend.

A device on the VM path? I don't follow here. Can I have a hand please?

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/