Configuration requise pour le microprogramme pour D3cold
À 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 rubrique décrit les exigences du microprogramme pour l’implémentation de la prise en charge de D3cold pour un appareil incorporé. La discussion suivante est destinée à aider les développeurs de microprogrammes à permettre à leurs appareils incorporés d’entrer et de quitter de manière fiable D3cold.
En outre, les exigences relatives aux pilotes 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 des pilotes de périphérique pour D3cold, consultez Prise en charge de D3cold dans un pilote.
Introduction
Les états d’alimentation des appareils sont définis dans la spécification ACPI et dans différentes spécifications de bus. Depuis l’introduction de la gestion de l’alimentation PCI, la spécification du bus PCI a divisé l’état d’alimentation de l’appareil D3 (désactivé) 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 deux sous-états D3, mais Windows 7 et les versions antérieures de Windows prennent en charge le sous-état D3cold uniquement lorsque l’ensemble de l’ordinateur quitte l’état d’alimentation du système S0 (fonctionnement) pour entrer dans 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, qui est 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 mettre à nouveau sous tension. Dans D3cold, toutes les sources d’alimentation sont supprimées, à l’exception possible d’une petite quantité d’énergie pour piloter la logique de veille de l’appareil. Par exemple, pour les appareils PCI Express (PCIe), la source d’alimentation de l’appareil main, Vcc, est fréquemment désactivée lors d’une transition vers D3cold. La désactivation de Vcc peut réduire la consommation d’énergie et prolonger la durée pendant laquelle une plateforme de matériel mobile peut s’exécuter sur une charge de batterie. Lorsqu’un appareil se trouve dans 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é, qui est généralement équivalent à l’état D0. Le logiciel doit ensuite réin initialiser l’appareil pour le mettre en état de fonctionnement.
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 uniquement que la source d’alimentation main, Vcc, est supprimée. La source d’alimentation auxiliaire, Vaux, peut également être supprimée si elle n’est pas nécessaire pour la logique de sortie de veille. Toutefois, un appareil qui peut être nécessaire pour signaler un événement de sortie de veille au processeur doit être en mesure de tirer suffisamment de puissance pour faire fonctionner la logique de sortie de veille. Par exemple, une carte d’interface réseau Ethernet dont main source d’alimentation est supprimée peut tirer suffisamment d’énergie du câble Ethernet. Ou bien, l’alimentation de secours d’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 requises est décrit pour activer les transitions d’état d’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 les pilotes de périphérique
La première de ces deux catégories est la main objet de cette discussion. Une brève vue d’ensemble de la deuxième catégorie est présentée. Pour plus d’informations sur la configuration requise pour les pilotes 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 pour 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 de D3cold à D0 est déclenchée par la réapplication de l’alimentation Vcc à l’appareil incorporé. La réapplication efficace de l’alimentation restaure la connexion de l’appareil au bus. Windows lit les identificateurs de l’appareil afin de 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, des requêtes pour l’ID de fournisseur, l’ID d’appareil et les ID de sous-système (qui sont divisés en ID de sous-appareil et sous-fournisseur dans certaines versions de la spécification). Ces identificateurs doivent correspondre à ceux de l’appareil précédemment attaché après la ré-application de l’alimentation (et le délai d’attente spécifié par le bus s’est écoulé) ; dans le cas contraire, Windows considère que le nouvel appareil est différent de l’appareil précédent.
Cas 1 : Un appareil incorporé est énuméré dans ACPI
Si un appareil incorporé n’est pas détectable via des mécanismes définis par une spécification de bus comme PCIe ou USB, mais que l’appareil est connecté en permanence (ou du moins que la connexion est dédiée à un appareil connu), cet appareil peut être décrit dans le microprogramme de la plateforme par des 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, vaguement, « logiciel qui n’est pas un microprogramme. ») OSPM énumère un appareil uniquement lorsqu’aucun énumérateur de bus ne peut détecter l’ID d’appareil. Par exemple, les appareils d’un bus ISA sont énumérés par OSPM. En outre, les appareils sur un système sur puce (SoC) sont souvent énumérés par ACPI, car ils se trouvent sur une structure non énumérable. Les contrôleurs hôtes USB et SD sont des exemples de ces appareils.
Microprogramme de plateforme (énuméré dans ACPI)
OSPM utilise \_SB._OSC pour transmettre les fonctionnalités OSPM à l’échelle de la plateforme au microprogramme de la plateforme. Le microprogramme 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, « Fonctionnalités OSPM à l’échelle de la plateforme », 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 ressource d’alimentation ACPI suivants pour l’appareil incorporé :
_PR0 : cet objet correspond aux besoins en 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 besoins en alimentation de l’appareil dans l’état d’alimentation 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 _PR2 soient présents chaque fois 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.
_PR3 : cet objet correspond aux besoins 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 hors tension (mettez la ressource hors tension).
_ON : définissez la ressource d’alimentation sur l’état activé (mise sous tension de la ressource).
_STA : cet objet correspond à l’état actif oudésactivé de la ressource d’alimentation (0 : désactivé, 1 : activé).
Une transition vers D3cold se produit quand 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 dans D3cold, ou entre dans D3cold ultérieurement.
Appareil parent (énuméré dans ACPI)
Il n’est pas nécessaire qu’un appareil parent puisse être géré par l’alimentation. Toutefois, si un appareil parent est géré par l’alimentation, Windows ne met jamais cet appareil hors tension si l’un de ses enfants (appareils dépendants) n’est 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 main (Vcc) et l’alimentation auxiliaire (Vaux) de l’appareil peuvent être activées et désactivées indépendamment via le bloc intitulé 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 ressource PVCC et PVAX sont attribués aux sources d’alimentation main et auxiliaires de l’appareil, Vcc et Vaux. Enfin, les besoins en ressources d’alimentation sont répertoriés 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 appareil incorporé est énuméré par bus
Si l’appareil incorporé est conforme à une spécification de bus courante, telle que PCIe ou USB, ce périphérique est détectable via des mécanismes définis par le 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 main 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 (telle qu’elle est vue par le matériel de bus) à la représentation de la plateforme de l’appareil (telle qu’elle est vue 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é, la prise en charge de D3cold doit être coordonnée avec le pilote de bus parent.
Si le main source d’alimentation d’un appareil incorporé est le lien qui connecte cet appareil à son bus parent, l’exigence clé pour placer l’appareil dans D3cold est de mettre le lien hors tension. Pour plus d’informations sur la transition vers D3cold, consultez le graphique d’état dans État de l’alimentation des appareils.
Microprogramme de plateforme (énuméré par bus)
OSPM utilise \_SB._OSC pour transmettre les fonctionnalités OSPM à l’échelle de la plateforme au microprogramme de la plateforme. Le microprogramme de 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, « Fonctionnalités OSPM à l’échelle de la plateforme », dans la spécification ACPI 5.0.
Appareil incorporé (énuméré par le bus)
Aucune modification ACPI spécifique à D3cold n’est requise. Dans ce cas, tant que le pilote de périphérique et la plateforme ont indiqué la prise en charge de D3cold, le lien de bus qui fournit l’alimentation à l’appareil incorporé peut être désactivé lorsque le bus parent quitte D0 et entre dans un état de faible consommation d’énergie Dx. La transition de l’appareil incorporé de D3hot vers D3cold se produit lorsque l’alimentation est supprimée du lien. L’état Dx entré par le bus parent peut être n’importe quel état qui entraîne l’arrêt de la source d’alimentation du lien.
Appareil parent (énuméré par le bus)
Le descripteur ACPI pour le bus parent doit effectuer les opérations suivantes :
Implémentez _S0W(Dx). Cet objet spécifie Dx comme état D de plus faible puissance à partir duquel l’appareil enfant (incorporé) peut se réveiller lorsque le système est à 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, les objets _ON, _OFF et _STA doivent être définis pour cette ressource d’alimentation. L’exemple de code ASL qui suit cette liste décrit l’alimentation du lien sous la forme de deux ressources, PVC1 et PVX1. Pour chacune de ces ressources, les objets _ON, _OFF et _STA sont définis.
Si « Dx » (l’état D de plus faible puissance ; consultez le premier élément de liste) est D3cold, fournissez un objet _PR3 qui inclut les ressources d’alimentation dont l’appareil enfant (incorporé) a besoin 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 spécifient 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 chaque fois qu'_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 dans l’objet _PR0 pour le bus parent doit inclure les ressources qui alimentent le lien qui connecte le bus parent à l’appareil enfant (incorporé).
Exemple (énuméré par un 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 avec 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é par ACPI.
L’appareil RP01 de ce diagramme a une source d’alimentation main, Vcc1, et une source d’alimentation auxiliaire, Vaux1. De même, l’appareil HD Audio dispose d’une source d’alimentation main, Vcc2, et d’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 illustré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 des configurations qui utilisent à la fois l’alimentation du bus et l’alimentation à bande latérale.
Configuration requise pour les pilotes 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. Le pilote peut également appeler la routine SetD3ColdSupport au moment de l’exécution pour activer ou désactiver dynamiquement les transitions de l’appareil vers D3cold. En permettant à un appareil d’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 jusqu’à ce que l’ordinateur soit redémarré ou entre dans un état de mise en veille. Si l’appareil doit être en mesure de signaler un événement de veille à partir d’un état Dx de faible puissance qu’il entre, l’entrée dans D3cold ne doit pas être activée, sauf si le pilote est certain que le signal de veille de l’appareil fonctionnera dans D3cold.
Pour plus d'informations, consultez Prise en charge de D3cold dans un pilote.