Re: Wakeup from a PCI device

[sas@corp.cirrus.com (Stephen A. Smith)]

As long as we are going to make a new pin lets do it so that
it is close to the RI# signal that exists today. 

We also must make it not bussed as any one connected to 
a bussed signal that is totally powered down will keep
a wake up brom being signaled (active high signaling) or
signal it all of the time (active low). 

Comments?

SA Smith
> From pci-sig-request@znyx.com Wed Aug 14 14:02:47 1996
> Return-Path: <pci-sig-request@znyx.com>
> Resent-From: pci-sig-request@znyx.com
> Resent-Date: Wed, 14 Aug 1996 13:54:47 -0500
> X-Sender: helms@vanzandt
> X-Mailer: Windows Eudora Version 2.1.1
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset="us-ascii"> 
> Subject: Re: Wakeup from a PCI device
> Resent-Message-Id: <"0Puql3.0.o82.iHY4o"@dart>
> X-Mailing-List: <pci-sig@znyx.com> archive/latest/3465
> X-Loop: pci-sig@znyx.com
> Precedence: list
> Resent-Sender: pci-sig-request@znyx.com
> To: Mailing List Recipients <pci-sig-request@znyx.com>
> Content-Length: 3014
> X-Lines: 58
> 
> Hi Bruce,
> 
> I am in favor of adding a wake-up pin.  It seems reasonable that a portable 
> PC would be expected to wake-up with a modem ring even if the PCI bus was
> powered down for power management reasons.
> 
> Thanks,
> Frank P. Helms 8/14/96
> frank.helms@amd.com 
> - Note: The views expressed are my own, and not necessarily those of AMD. -
> 
> At 10:25 AM 8/14/96 PDT, Bruce Young wrote:
> >     Many of you may recall a thread back in April talking about how a PCI 
> >     device could initiate a wakeup for a powered down system. The proposal 
> >     that I had made as a part of the initial work I did on PCI Power 
> >     Management defined the standard INTx# signals as the mechanism to 
> >     accomplish this. After much discussion and working through as many of 
> >     the technical issues as we could, the PCI Power Management Working 
> >     Group has decided to request that a reserved pin be assigned for this 
> >     purpose. While the technical details are quite involved, the overall 
> >     reason is that we decided that we did not want to eliminate the 
> >     possibility of a device in a powered-down slot initiating a wakeup and 
> >     the only electrically feasible way to do this while maintaining 
> >     compatibility with older PCI cards is to use a new pin. 
> >     
> >     The impact of this should be minimal. Most PCI peripherals don't need 
> >     to initiate a wakeup and therefore have no need to add the pin. 
> >     Chipsets that want to support wakeup will, in general, have dedicated 
> >     inputs for wakeup from other devices (e.g. Lid open or suspend switch) 
> >     that shared for this new signal as well. The only devices which will 
> >     need to add a pin are those that have a need to wake a "sleeping" 
> >     system which will typically be comm and network cards. I realize that 
> >     this can be a significant impact on those devices but we could not 
> >     solve all the technical issues related to using the INTx# pins. 
> >     
> >     I want to emphasize that this is not final and no-one should start 
> >     designing Si with this new pin yet. The ECR will go through the 
> >     standard PCI SIG process of approval which consists of Working Group 
> >     approval (in this case the protocol working group), Steering Committee 
> >     approval and then a 30 day review period for the entire SIG. I am 
> >     posting this to highlight the issue and try to understand how this 
> >     will be received by the entire PCI design community. I believe that a 
> >     dialog early can help minimize the problems later in the process.
> >     
> >     So what do you think? Is this a non-issue that everyone agrees a 
> >     separate pin for wakeup is a good idea? Or is everyone dead-set 
> >     against adding a pin on principle!?
> >     
> >     -Bruce Young, Intel Corporation 
> >     PCI SIG Power Management Working Group Chairman 
> >
> >
> >
> ________________________________________________________
>  Frank P. Helms 
>  frank.helms@amd.com
> -The opinions expressed are my own and not necessarily those of AMD.-
> 
> 
3
ðà