Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À compter de Windows 8, les appareils peuvent entrer dans le sous-état d’alimentation D3cold même lorsque le système reste dans l’état d’alimentation S0. Cette section décrit les exigences de firmware pour l’implémentation de la prise en charge de D3cold pour un appareil intégré. La discussion suivante vise à aider les développeurs de microprogrammes à permettre à leurs appareils incorporés d’entrer et de quitter D3cold de manière fiable.
En outre, les exigences relatives au pilote de périphérique pour la prise en charge de D3cold sont brièvement abordées. Pour plus d’informations sur la prise en charge du pilote de périphérique pour D3cold, consultez Prise en charge de D3cold dans un pilote.
Présentation
Les états d’alimentation des appareils sont définis dans la spécification ACPI et dans différentes spécifications de bus. La spécification du bus PCI a, depuis l'introduction de la gestion de l'alimentation électrique PCI, fractionné l'état de puissance D3 (désactivé) de l'appareil en deux sous-états, D3hot et D3cold. Cette distinction a été ajoutée à la spécification ACPI dans ACPI 3.0 et étendue dans ACPI 4.0. Windows a toujours pris en charge les sous-états D3, mais Windows 7 et les versions antérieures de Windows prennent en charge le sous-état D3cold uniquement lorsque l’ordinateur entier quitte l’état d’alimentation du système S0 (opérationnel) pour entrer un état de veille ou de mise en veille prolongée, généralement S3 ou S4. À compter de Windows 8, les pilotes de périphérique peuvent permettre à leurs appareils d’entrer dans l’état D3cold même si le système reste dans S0.
D3hot, souvent simplement appelé « D3 », est l'état « soft-off » de l'appareil. Dans cet état, l’appareil peut être détecté par une analyse de bus, et les commandes envoyées à l’appareil peuvent le réactiver. Dans D3cold, toutes les sources d’alimentation sont supprimées, à l’exception d’une petite quantité d’alimentation pour conduire la logique de veille de l’appareil. Par exemple, pour les appareils PCI Express (PCIe), la source d’alimentation principale de l’appareil, Vcc, est fréquemment désactivée dans une transition vers D3cold. La désactivation de Vcc peut réduire la consommation d’alimentation et prolonger le temps d’exécution d’une plateforme matérielle mobile sur une batterie. Lorsqu’un appareil est en D3cold, il ne peut pas être détecté par une analyse de bus et ne peut pas recevoir de commandes. La restauration de l’alimentation Vcc déplace l’appareil vers un état non initialisé, ce qui équivaut généralement à l’état D0. Le logiciel doit ensuite réinscrire l’appareil pour le placer dans l’état de fonctionnement.
Le fait de placer un appareil dans D3cold ne signifie pas nécessairement que toutes les sources d’alimentation de l’appareil ont été supprimées. Cela signifie que seule la source d’alimentation principale, Vcc, est supprimée. La source d’alimentation auxiliaire, Vaux, peut également être supprimée s’il n’est pas nécessaire pour la logique de veille. Toutefois, un appareil susceptible d’être nécessaire pour signaler un événement de veille au processeur doit pouvoir tirer suffisamment de puissance pour utiliser la logique de mise en éveil. Par exemple, une carte d’interface réseau Ethernet dont la source d’alimentation principale est supprimée peut tirer suffisamment de puissance du câble Ethernet. Ou bien, l’alimentation de secours à une carte réseau Wi-Fi peut être fournie à partir d’une source en dehors de l’interface PCIe, auquel cas l’interface PCIe peut être complètement désactivée.
Dans la discussion suivante, un ensemble de conditions est décrit pour activer les transitions d’état de l’alimentation de l’appareil vers D3cold. Ces exigences appartiennent aux deux catégories suivantes :
Configuration requise pour le microprogramme et la plateforme
Configuration requise pour le pilote de périphérique
La première de ces deux catégories est l’objectif principal de cette discussion. Une brève vue d’ensemble de la deuxième catégorie est présentée. Pour plus d’informations sur les exigences relatives au pilote de périphérique, consultez Prise en charge de D3cold dans un pilote.
Configuration requise pour le microprogramme et la plateforme
Dans la discussion suivante, les exigences de microprogramme et de plateforme pour l’activation de D3cold sont présentées dans ces deux cas :
Lorsque l’appareil est énuméré dans ACPI.
Lorsque l’appareil est énuméré par son bus parent.
La plupart des discussions suivantes sont spécifiques à PCIe. Toutefois, les principes généraux décrits ici s’appliquent en grande partie à d’autres autobus.
En résumé, la transition entre D3cold et D0 est déclenchée en appliquant à nouveau la puissance Vcc à l’appareil incorporé. La réapplication de la puissance restaure efficacement la connexion de l’appareil au bus. Windows lit les identificateurs de l’appareil pour faire la distinction entre les deux cas suivants :
Un appareil a été supprimé et remplacé par un autre appareil.
Le même appareil a été supprimé, puis réinséré.
Si les identificateurs correspondent, le pilote de périphérique réinitialise l’appareil. Si les identificateurs ne correspondent pas, Windows décharge le pilote de périphérique et génère une nouvelle pile de pilotes pour le nouvel appareil. PCIe, par exemple, interroge l’ID du fournisseur, l’ID d’appareil et les ID de sous-système (qui sont divisés en ID de sous-appareil et de sous-fournisseur dans certaines versions de la spécification). Ces identificateurs doivent correspondre à ceux de l’appareil précédemment attaché une fois que l’alimentation est réappulée (et la période d’attente spécifiée par bus s’écoule) ; sinon, Windows considère que le nouvel appareil est différent de celui précédent.
Cas 1 : Un appareil incorporé est énuméré dans ACPI
Si un appareil incorporé n’est pas détectable par le biais de mécanismes définis par une spécification de bus telle que PCIe ou USB, mais que l’appareil est connecté définitivement (ou au moins la connexion est dédiée à un appareil connu), cet appareil peut être décrit dans le microprogramme de plateforme par les objets ACPI _HID et/ou _CID. Ces objets permettent à l’appareil d’être énuméré par OSPM. (« OSPM » est un terme défini dans la spécification ACPI. Cela signifie, en toute liberté, « logiciel qui n’est pas microprogramme . » OSPM énumère un appareil uniquement quand aucun énumérateur de bus ne peut détecter l’ID de l’appareil. Par exemple, les appareils d’un bus ISA sont énumérés par OSPM. En outre, les appareils sur un système sur une puce (SoC) sont souvent énumérés par ACPI, car ils se trouvent sur une infrastructure non énumérable. Par exemple, ces appareils incluent des contrôleurs hôtes USB et SD.
Microprogramme de plateforme (énuméré dans ACPI)
OSPM utilise \_SB._OSC pour transmettre des fonctionnalités OSPM à l’échelle de la plateforme vers le microprogramme de la plateforme. Le firmware de la plateforme doit définir le bit 2 dans la valeur de retour \_SB._OSC pour indiquer à OSPM que l’appareil prend en charge _PR3. Pour plus d’informations, consultez la section 6.2.10.2, «Platform-Wide fonctionnalités OSPM », dans la spécification ACPI 5.0.
Appareil incorporé (découvert uniquement via ACPI)
Pour prendre en charge D3cold, le microprogramme de la plateforme doit implémenter les objets de ressources d’alimentation ACPI suivants pour l’appareil incorporé :
_PR0 : cet objet correspond aux exigences d’alimentation de l’appareil dans l’état d’alimentation de l’appareil D0 (entièrement activé). La valeur de retour est la liste des ressources d’alimentation dont l’appareil a besoin dans l’état D0.
_PR2 : cet objet correspond aux exigences d’alimentation de l’appareil dans l’état d’alimentation de l’appareil D2. La valeur de retour est la liste des ressources d’alimentation dont l’appareil a besoin dans l’état D2. Notez que pour des raisons historiques, Windows s’attend à ce que les _PR2 soient présentes chaque fois que _PR0 est présente. Si D2 est implémenté dans le matériel, _PR2 répertorie les ressources d’alimentation nécessaires pour D2. Si D2 n’est pas implémenté, _PR2 répertorie les mêmes ressources que _PR0.
_PR3 : cet objet correspond aux exigences d’alimentation de l’appareil dans l’état d’alimentation de l’appareil D3hot. La valeur de retour est la liste des ressources d’alimentation dont l’appareil a besoin dans l’état D3hot.
Pour chaque ressource d’alimentation identifiée dans n’importe quel objet _PRx, les méthodes de contrôle suivantes doivent être implémentées :
_OFF : définissez la ressource d’alimentation sur l’état désactivé (désactivez la ressource).
_ON: Définissez la source d'alimentation à l'état activé (mise sous tension de la ressource).
_STA : cet objet évalue l’état actuel oudésactivé de la ressource d’alimentation (0 : désactivé, 1 : activé).
Une transition vers D3cold se produit lorsque l’ACPI exécute la méthode de contrôle _OFF sur les ressources d’alimentation répertoriées dans _PR3. Notez que si le pilote de fonction de périphérique indique la prise en charge de D3cold, cette prise en charge n’implique pas que toutes les transitions vers D3 entraînent des transitions rapides vers D3cold. Il est possible que l’appareil entre et reste dans D3hot pendant une période prolongée, puis retourne à D0 sans jamais entrer D3cold, ou entre D3cold ultérieurement.
Appareil parent (énuméré dans ACPI)
Il n’est pas nécessaire qu’un dispositif parent soit capable d’être géré en termes d’alimentation. Toutefois, si un appareil parent est doté de la gestion d'alimentation, Windows ne met jamais cet appareil hors tension si l’un de ses enfants (appareils dépendants) ne se trouve pas dans D3.
Exemple (énuméré dans ACPI)
Le diagramme de blocs suivant montre un appareil incorporé (étiqueté EMBD) sur un bus système. L’alimentation principale (Vcc) et l’alimentation auxiliaire (Vaux) de l’appareil peuvent être activées et désactivées indépendamment via le bloc étiqueté Logique d’alimentation.
L’exemple de code ASL suivant décrit les ressources d’alimentation utilisées par l’appareil incorporé dans le diagramme précédent. Cet exemple commence par une déclaration d’une méthode de contrôle _OSC qui décrit les fonctionnalités du pilote de périphérique. Ensuite, les deux ressources d’alimentation de l’appareil sont déclarées : les noms de ressources PVCC et PVAX sont attribués aux sources d’alimentation principales et auxiliaires de l’appareil, Vcc et Vaux. Enfin, les exigences en matière de ressources d’alimentation sont répertoriées pour chaque état d’alimentation de l’appareil pris en charge et les fonctionnalités de veille de l’appareil sont décrites.
Scope (\_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVCC,0,0) // Power resource representing the main power for the device.
// Required for the device to be fully functional (D0).
{
Name(_STA,VAR1) // Return the state of the power resource.
Method(_ON,0x0) {...} // Turn on the power resource and set VAR1 to 1.
Method(_OFF,0x0) {...} // Turn off the power resource and set VAR1 to 0.
}
PowerResource(PVAX,0,0) // Power resource representing the auxiliary power for the device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
Device(EMBD) // An ACPI-enumerated device on the processor bus that supports D3Cold
{
Name(_HID, ...)
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVCC, PVAX}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package() {PVCC, PVAX}) // If D2 is implemented in the hardware,
// list the power resources needed by D2.
// If D2 is not implemented, list the same
// resources as _PR3.
// Indicate support for D3Cold.
Name(_PR3, Package() {PVCC, PVAX}) // Power resource for D3. These will be
// turned off ONLY if drivers opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the device doesn't
// need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform is
// capable of handling wake events from this device while in S0.
// The value of this object indicates the lowest D-state this device
// can be in to trigger wake events that can be handled while the
// platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way for OSPM to
// enable and disable them. The mechanism for this depends on the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with either of the above, if wake enablement
// varies depending on the target S-state and D-state.
*/
} // End of Device EMBD
} End Scope \_SB
Cas 2 : un dispositif incorporé est énuméré par le bus
Si l’appareil incorporé est conforme à une spécification de bus commune, telle que PCIe ou USB, cet appareil est détectable par le biais de mécanismes définis par bus, et l’alimentation peut être fournie partiellement ou entièrement via le bus. Si cet appareil n’est pas alimenté par d’autres ressources d’alimentation de bande latérale, la source d’alimentation principale de l’appareil est le lien qui connecte l’appareil au contrôleur de bus parent. Les appareils énumérés par bus peuvent être identifiés par l’objet _ADR dans la définition de l’appareil incorporé. Un objet _ADR est utilisé pour fournir OSPM à l’adresse d’un appareil sur le bus parent de l’appareil incorporé. Cette adresse est utilisée pour lier la représentation du bus de l’appareil (comme indiqué par le matériel bus) à la représentation de la plateforme de l’appareil (comme indiqué par le microprogramme ACPI). (L’encodage d’adresse _ADR est spécifique au bus. Pour plus d’informations, consultez la section 6.1.1, « _ADR (Adresse) », dans la spécification ACPI 5.0.) Lorsque ce mécanisme est utilisé, le support D3cold doit être coordonné avec le pilote du bus parent.
Si la source d’alimentation principale d’un appareil incorporé est le lien qui connecte cet appareil à son bus parent, l’exigence clé pour placer l’appareil dans D3cold consiste à mettre hors tension le lien. Pour plus d’informations sur la transition vers D3cold, consultez le graphique d’état dans Device Power States.
Microprogramme de plateforme (énuméré par bus)
OSPM utilise \_SB._OSC pour transmettre des fonctionnalités OSPM à l’échelle de la plateforme vers le microprogramme de la plateforme. Le firmware de la plateforme doit définir le bit 2 dans la valeur de retour \_SB._OSC pour indiquer à OSPM que l’appareil prend en charge _PR3. Pour plus d’informations, consultez la section 6.2.10.2, «Platform-Wide fonctionnalités OSPM », dans la spécification ACPI 5.0.
Appareil incorporé (énuméré par bus)
Aucune modification ACPI spécifique à D3cold n’est requise. Dans ce cas, tant que le pilote et la plateforme de périphérique ont indiqué la prise en charge de D3cold, le lien bus qui fournit de l’alimentation à l’appareil incorporé peut être désactivé lorsque le bus parent quitte D0 et entre dans un état Dx à faible alimentation. La transition de l’appareil incorporé de D3hot à D3cold se produit lorsque l'alimentation électrique est coupée au niveau du lien. L’état Dx entré par le bus parent peut être n’importe quel état qui entraînera la désactivation de la source d’alimentation du lien.
Appareil parent (énuméré par bus)
Le descripteur ACPI pour le bus parent doit effectuer les opérations suivantes :
Implémenter _S0W(Dx). Cet objet spécifie Dx comme état D à alimentation la plus faible à partir duquel l’appareil enfant (incorporé) peut se réveiller lorsque le système est dans l’état S0.
Définissez les ressources d’alimentation pour représenter le lien qui connecte l’appareil enfant (incorporé) au bus parent. En outre, _ON, _OFF et les objets _STA doivent être définis pour cette ressource d’alimentation. L’exemple de code ASL qui suit cette liste décrit la puissance du lien comme deux ressources, PVC1 et PVX1. Pour chacune de ces ressources, _ON, _OFF et _STA objets sont définis.
Si « Dx » (état D à alimentation la plus faible ; consultez le premier élément de liste) est D3cold, fournissez un objet _PR3 qui inclut les ressources d’alimentation requises par l’appareil enfant (incorporé) pour D3hot (par exemple, Vcc et Vaux). Si les mêmes sources d’alimentation sont requises pour D0, D2 et D3hot, _PR0, _PR2 et _PR3 toutes spécifier les mêmes ressources d’alimentation. Ces ressources sont désactivées uniquement lorsque l’appareil enfant entre dans D3cold.
Pour des raisons historiques, Windows s’attend à ce que _PR2 soit présent dès lors que _PR0 est présent. Si D2 est implémenté dans le matériel, _PR2 répertorie les ressources d’alimentation nécessaires pour D2. Si D2 n’est pas implémenté, _PR2 répertorie les mêmes ressources que _PR0.
Implémentez _PR0. La liste des ressources de l’objet _PR0 du bus parent doit inclure les ressources qui alimentent le lien qui connecte le bus parent à l’appareil enfant (incorporé).
Exemple (énuméré par bus)
L’exemple de configuration matérielle dans le diagramme de blocs suivant montre deux façons différentes d’activer D3cold pour les appareils PCIe. Tout d’abord, un point de terminaison (étiqueté ENDP) est connecté à un port racine PCIe (RP01) et reçoit l’alimentation auxiliaire de son appareil parent via un lien PCIe. Deuxièmement, le périphérique AUDIO HD dans le diagramme n’a pas de lien standard vers son appareil parent (le contrôleur PCI étiqueté PCI0) et est donc modélisé de la même façon que le cas énuméré ACPI.
L’appareil RP01 de ce diagramme a une source d’alimentation principale, Vcc1 et une source d’alimentation auxiliaire, Vaux1. De même, l’appareil HD Audio a une source d’alimentation principale, Vcc2 et une source d’alimentation auxiliaire, Vaux2.
Le code ASL suivant décrit le contrôleur de bus parent (PCI0) et les ressources d’alimentation requises pour les périphériques ENDP et HD Audio indiqués dans le diagramme précédent.
Scope (_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVC1,0,0) // Power resource representing Vcc1 for the RP01 device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR0)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX1,0,0) // Power resource representing Vaux1 for the RP01 device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR1)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVC2,0,0) // Power resource representing Vcc2 for the HD device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX2,0,0) // Power resource representing Vaux2 for the HD device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR3)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
... // Power resources for other child devices
Device(PCI0) // The PCI root complex
{
Name(_HID, EISAID("PNP0A08")) // ACPI enumerated
Method(_OSC, 4, NotSerialized) // PCIe-specific Capabilities Check.
{
... // This must support hand-off of PCIe control to the OS.
}
... // Other (non-power) objects for this device
Device(RP01) // PCIe Root Port 1
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC1, PVX1}) // Power resources required for D0.
// Includes the Link Power for ENDP.
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC1, PVX1})
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that
// can be handled while the platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way
// for OSPM to enable and disable them. The mechanism for this depends on
// the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
Device(ENDP) // This device supports D3cold. No power-related objects
// are required.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects
} // End of Device ENDP
} // End of Device RP01
Device(HD) // A PCIe Bus0 device (HD Audio) that supports D3cold. Note that
// this case is modeled similar to the ACPI-enumerated case
// because device HD has no standard link to its parent.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC2, PVX2}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC2, PVX2})
// Indicate support for D3Cold.
Name(_PR3, Package() {PVC2, PVX2}) // Power resource for D3; These will
// be turned off ONLY if drivers
// opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that can
// be handled while the platform is in S0.
// Enable wake events (optional).
// If this device actually does generate wake events, there must be a way for
// OSPM to enable and disable them. The mechanism for this depends on the HW:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
} // End Device HD
... // Device objects for other child devices
} // End Device PCI0
} // End Scope _SB
Autres possibilités
Les techniques présentées dans les deux exemples précédents peuvent être combinées pour prendre en charge les configurations qui utilisent à la fois l’alimentation de bus et la puissance de bande latérale.
Configuration requise pour le pilote de périphérique
Le propriétaire de la stratégie d’alimentation d’un appareil (généralement le pilote de fonction) indique au système d’exploitation s’il faut activer la transition de l’appareil de D3hot à D3cold. Le pilote peut fournir ces informations dans le fichier INF qui installe l’appareil. Ou bien, le pilote peut appeler la routine SetD3ColdSupport au moment de l’exécution pour activer ou désactiver dynamiquement les transitions de l’appareil vers D3cold. En activant un appareil pour entrer D3cold, un pilote garantit le comportement suivant :
L’appareil peut tolérer une transition de D3hot à D3cold lorsque l’ordinateur doit rester dans S0.
L’appareil fonctionne correctement lorsqu’il retourne à D0 à partir de D3cold.
Un appareil qui ne répond pas à l’une ou l’autre exigence peut, après avoir entré D3cold, être indisponible tant que l’ordinateur n’est pas redémarré ou qu’il entre dans un état de veille. Si l'appareil doit pouvoir signaler un événement de réveil à partir de n'importe quel état Dx à faible consommation dans lequel il entre, l'entrée en D3cold ne doit pas être activée, sauf si le pilote est certain que le signal de réveil de l'appareil fonctionnera correctement en D3cold.
Pour plus d’informations, consultez la documentation sur la prise en charge du mode D3cold dans un pilote de périphérique.