Re: PCI PM wakeup from D3 Cold

[Gary Solomon <Gary_Solomon@ccm.jf.intel.com>]

---------------------------------- Forwarded ----------------------------------
From: Gary Solomon at JFCCM7
Date: 3/16/97 4:49PM
To: pci-sig@znyx.com at Internet_Gateway
Subject: Re: PCI PM wakeup from D3 Cold
-------------------------------------------------------------------------------

Text item: 

After further discussions it occured to our spec dev. team that we 
are really arguing over semantics here.
     
The key point that appears to have been missed is that when a 
function is requested by the OS to transition to D3hot, the device 
driver for that function should at this point, in anticipation of 
eventually being put into D3cold (no Vcc), save off all necessary 
context that would need to be restored when repowered to resume 
where the system/application left off before being suspended.  This 
is further documented in the spec in indicating that the ONLY 
context that must be preserved within the function itself when in 
D3cold is the PME context (if PME# is supported from D3cold).  All 
other context is assumed to be lost, and hence must be either 
restored on resuming, or otherwise reconfigured with, in this case 
loss of the current state at the time of suspend.
     
So in essence D3cold and D0 uninitialized are identical except for 
the fact that in D3cold there is no Vcc power.  All PME# generation 
and reporting logic (PME context) remains alive while in D3cold by 
an auxiliary power source that the function must have to support 
D3cold wakeup capabilities.  So when power to the slot is switched 
off, even if the component believes it is having RST# asserted the 
only context that is present at the time is the PME context which by 
definition cannot be affected by the assertion of RST#.

(Only way to initialize PME context for function's that support PME# 
from D3cold is by having the OS physically, at initial OS load time, 
write the PMCSR PME_Status and PME_en bits to "1" and "0" 
respectively.) 

Hope this helps.

Regards,

Gary Solomon
Platform Architecture Lab - Intel

 

______________________________ Reply Separator _________________________________
Subject: PCI PM wakeup from D3 Cold
Author:  pontius@west.smc.com at SMTPGATE
Date:    3/10/97 11:32 AM


----- Begin Included Message -----
     
From pontius Mon Mar 10 11:21:04 1997 
To: pci-sig@znyx.com
Subject: PCI PM wakeup from D3 Cold
Content-Length: 1081
X-Lines: 30
     
I believe I've found a problem with the 0.99a rev of the PCI Power Management 
spec, (Figure 7).
     
Devices in D3cold are expected to transition to D0 uninitialized upon PCI RST#. 
What happens on this signal during VCC removed?  I assume it will drop to 0V 
along with the rest of the bus (unless the system actively drives it low). 
Either way, the device (powered off an auxiliary supply) sees RST# asserted
and tries to transition to D0 uninitialized immediately while power is still 
off!
     
Here's what I'm guessing will happen on the VCC and RST# lines:
     
VCC  ~~~~~\_____________/~~~~~~~
RST# ~~~\__________________/~~~~
     ^     ^                ^
     D3hot |                |
           D3cold           |
                            D0uninitialized
     
If this is the case, the transition from D3 to D0uninitialized should occur 
when RST# goes high, not when it is asserted.
     
Perhaps a better solution would be for the device to stay in D3 (as part of 
maintaining PME Context), requiring the OS to switch it back to D0.
     
Does anyone have a better solution?
     
--Mark Pontius
  SMC
     
     
     
----- End Included Message -----

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: PCI PM wakeup from D3 Cold
To: gary_solomon@ccm.jf.intel.com
Message-Id: <9703101932.AA07878@west.smc.com>
From: pontius@west.smc.com (Mark Pontius x4805)
Date: Mon, 10 Mar 97 11:32:14 PST
Received: from zeus.smc.com by west.smc.com (4.1/SMI-4.1)
     id AA07878; Mon, 10 Mar 97 11:32:14 PST
Received: from west.smc.com (west.smc.com [170.129.155.128]) by mail.smc.com (8.
6.9/8.6.9) with SMTP id OAA18453 for <gary_solomon@ccm.jf.intel.com>; Mon, 10 Ma
r 1997 14:36:16 -0500
Received: from mail.smc.com (mail.smc.com [170.129.50.1])
          by ormail.intel.com (8.8.4/8.8.4) with SMTP
       id LAA08695 for <gary_solomon@ccm.jf.intel.com>; Mon, 10 Mar 1997 11:33:2
4 -0800 (PST)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.6/8.7.3) with ESMTP id LAA16345 for <gary_solomon@ccm.jf.intel.com
>; Mon, 10 Mar 1997 11:33:37 -0800 (PST)
Return-Path: pontius@west.smc.com
ælY