lkml.org 
[lkml]   [2001]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New PCI PM

On Tue, 12 Jun 2001, Jeff Garzik wrote:

>
> What is are the guarantees about the order of calls to
> pci_driver::suspend and pci_driver::resume?
>
> Will a driver get calls like
> suspend(D3)
> suspend(D2)
> suspend(D1)

Not possible, according to the PCI PM Spec.

These are the possible state transitions:

+---------------------------+
| Current State | New State |
+---------------------------+
| D0 | D1, D2, D3|
+---------------------------+
| D1 | D2, D3 |
+---------------------------+
| D2 | D3 |
+---------------------------+
| D1, D2, D3 | D0 |
+---------------------------+

(note the last would be ::resume() from any state)

> or just one suspend call?

Calls to lower power states are possible, but never to higher, except D0.

> What effect does the return value have on the rest of the system? On
> the order of succeeding calls to pci_driver::suspend functions?

On system suspend, it should be ignored. It sounds bad, but there is
justification. With a two-stage suspension, drivers will get a call to
::save_state before suspend. It is then that they should fail, if they're
going to. That way, nothing will be powered off yet, and a graceful
recovery is much more likely.

However, if you're gradually bringing the device down to lower and lower
power states, you may want to know if it fails (e.g. if it can't enter D1
or D2).

> And where is that patch to Documentation/pci.txt young man? :)

It should be in -pre4. Quick Draw Torvalds couldn't wait an extra 15
minutes to release -pre3.

-pat

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

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.626 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site