Gestion de l’alimentation des appareils

La spécification ACPI 6.3 définit un ensemble d’objets d’espace de noms pour spécifier les informations d’alimentation d’un appareil. Par exemple, un ensemble d’objets peut spécifier les ressources d’alimentation dont un appareil a besoin dans chaque état d’alimentation de l’appareil pris en charge. Un autre type d’objet peut décrire la capacité de l’appareil à sortir d’un état de faible consommation en réponse à des événements matériels.

Gestion de l’alimentation des appareils dans Windows

Pendant qu’un système est en cours d’exécution (autrement dit, le système est dans l’état de fonctionnement défini par ACPI, S0), des appareils individuels peuvent effectuer des transitions entre les états d’alimentation des appareils, en fonction de l’activité, pour économiser de l’énergie. Dans les systèmes PC traditionnels, les états de veille définis par ACPI (S1 à S4) sont également utilisés pour économiser de l’énergie, mais ces états de veille à latence élevée déconnectés ne sont pas utilisés sur les plateformes Windows SoC. Par conséquent, l’autonomie de la batterie dépend fortement de la façon dont les plateformes implémentent la gestion de l’alimentation des appareils au moment de l’exécution.

Les appareils intégrés au SoC peuvent être gérés par le biais de Windows Power Framework (PoFx). Ces appareils intégrés au framework sont gérés par PoFx via un plug-in microPEP (power engine plug-in) spécifique au SoC qui connaît les spécificités des contrôles d’alimentation et d’horloge du SoC. Pour plus d’informations sur PoFx, consultez Vue d’ensemble de l’infrastructure de gestion de l’alimentation.

Pour les périphériques qui ne sont pas intégrés au SoC, Windows utilise la gestion de l’alimentation des appareils ACPI. Pour ces appareils gérés par ACPI, le propriétaire de la stratégie d’alimentation dans une pile de pilotes de périphérique (généralement le pilote de fonction ou de classe) prend des décisions de transition de l’état d’alimentation des appareils, et le pilote ACPI Windows, Acpi.sys, appelle les méthodes de contrôle ASL pour appliquer les contrôles d’alimentation spécifiques à la plateforme requis.

Il est possible, et certaines piles d’appareils le font, d’utiliser la gestion de l’alimentation des appareils ACPI seule ou en combinaison avec le microPEP pour la gestion de l’alimentation des appareils sur SoC.

Comme décrit dans Gestion de l’alimentation des appareils dans ACPI, Windows prend en charge les fonctionnalités de gestion de l’alimentation D3cold définies dans la spécification ACPI 5.0. Grâce à cette prise en charge, les appareils, les plateformes et les pilotes peuvent choisir de supprimer complètement l’alimentation des appareils pendant les périodes d’inactivité au moment de l’exécution. Cette fonctionnalité peut améliorer considérablement l’autonomie de la batterie. Toutefois, la suppression de l’alimentation doit être prise en charge par tous les composants affectés pour pouvoir revenir à D0 avec succès. Pour cette raison, les conducteurs (bus et fonction), ainsi que la plateforme elle-même, doivent indiquer qu’ils le prennent en charge. Pour plus d’informations sur l’inscription du pilote D3cold, consultez Prise en charge de D3cold dans un pilote.

Gestion de l’alimentation des appareils dans ACPI

Les appareils d’espace de noms prennent en charge jusqu’à quatre états d’alimentation des appareils, numérotés D0 (fonction complète ou « activé ») à D3 (aucune fonction ou « désactivé »). Chaque état peut avoir des exigences d’alimentation différentes, avec des états plus numérotés consommant moins d’énergie que les états moins numérotés. En outre, l’état D3 (désactivé) a deux sous-états, D3hot et D3cold. Le sous-état D3hot exige que l’appareil reste accessible sur son bus parent afin qu’il puisse répondre aux commandes logicielles spécifiques du bus. Cette exigence et la puissance utilisée pour y répondre sont supprimées dans D3cold. Enfin, un appareil peut être armé pour sortir d’un état de faible consommation en raison d’un événement matériel et, si nécessaire, pour sortir la plateforme d’un état d’inactivité.

La plateforme indique sa prise en charge de D3cold en accordant au système d’exploitation le contrôle de la fonctionnalité « _PR3 Support » (bit 2) lorsque cela est demandé à l’aide de la méthode de fonctionnalités OSPM à l’échelle de la plateforme. 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.

Les appareils gérés par l’alimentation utilisent des objets enfants pour décrire leurs capacités d’alimentation au système d’exploitation. Les sections suivantes décrivent ces fonctionnalités et objets.

Ressources et états d’alimentation

Un appareil déclare prendre en charge un état d’alimentation en listant l’ensemble des ressources d’alimentation dont il a besoin pour se trouver dans cet état. Les ressources d’alimentation ACPI représentent les rails de tension qui alimentent les appareils et les signaux d’horloge qui les pilotent. Ces ressources sont déclarées à la racine de l’espace de noms. Chaque ressource d’alimentation dispose d’une _ON et d’une méthode de _OFF par le biais desquelles elle est contrôlée, et d’une méthode _STA pour signaler son état. Pour plus d’informations, consultez la section 7.1, « Déclaration d’un objet Power Resource », de la spécification ACPI 5.0.

Le pilote WINDOWS ACPI, Acpi.sys, surveille les dépendances d’alimentation entre les appareils qui partagent des ressources et, à mesure que ces appareils passent d’un état d’alimentation à l’autre, garantit que seules les ressources d’alimentation réellement nécessaires à un appareil sont activées à un moment donné.

Power Resource Requirements (_PRx)

Il existe un objet Power Resource Requirements (_PRx), où x = 0, 1, 2 ou 3, pour chaque état d’alimentation de l’appareil pris en charge. Lorsque le pilote de périphérique décide de passer à un nouvel état d’alimentation, Acpi.sys garantit que toutes les ressources d’alimentation requises pour le nouvel état sont activées et que toutes les ressources qui ne sont plus utilisées sont désactivées.

État de l’appareil pris en charge	Objet d’exigences de ressources à utiliser	Ressources à inclure dans l’objet requirements
D0 (obligatoire)	_PR0	Toute l’alimentation et les horloges requises pour le fonctionnement complet de l’appareil.
D1	_PR1	Toute puissance ou horloge requise pour la fonctionnalité réduite définie par la classe de cet état.
D2	_PR2	Toute puissance ou horloge requise pour la fonctionnalité réduite définie par la classe de cet état.
D3hot (obligatoire)	_PR3	Seules l’alimentation ou les horloges requises pour que l’appareil apparaisse sur son bus et réponde à une commande spécifique au bus.

Si une plateforme particulière prend en charge la fonctionnalité D3cold et que le pilote de périphérique d’un appareil opte pour D3cold, les ressources d’alimentation _PR3 de l’appareil, si elles ne sont pas utilisées par un autre appareil, sont désactivées un peu après la transition vers D3Cold.

Pour plus d’informations sur les besoins en ressources d’alimentation d’un appareil qui prend en charge D3cold, consultez Configuration requise du microprogramme pour D3cold.

État d’alimentation de l’appareil (_PSx)

Il existe une méthode Power State, _PSx, où x = 0, 1, 2 ou 3, pour chaque état d’alimentation d’appareil pris en charge Dx. Cette méthode est facultative, mais, si elle est présente, elle est appelée avant que les ressources d’alimentation de l’état soient désactivées et une fois que les ressources d’alimentation pour l’état sont activées. _PSx est destiné à effectuer toutes les actions spécifiques à la plateforme requises autour du cycle d’alimentation. _PSx ne devez pas accéder aux registres de périphériques affectés au pilote de fonction, accéder aux registres standard du bus qui sont attribués au pilote de bus, ni activer ou désactiver les ressources d’alimentation, ce qui est une opération réservée à Acpi.sys.

Fonctionnalités d’éveil

Les appareils gérés par l’alimentation peuvent être en mesure de détecter des événements lorsqu’ils sont dans un état de faible consommation et de provoquer la mise en éveil de la plateforme pour les gérer. Pour activer cette fonctionnalité, Windows a besoin d’informations sur les fonctionnalités de la plateforme et de l’appareil.

État d’éveil de l’appareil Sx (_SxW)

Sur une plateforme donnée, il existe un mappage spécifique entre les états de l’appareil qui prennent en charge la fonctionnalité de veille et les états système qui peuvent répondre aux événements d’éveil. ACPI définit l’objet _SxW pour fournir ces informations au système d’exploitation. Il existe un objet SxW pour chaque état d’alimentation du système pris en charge, Sx. Étant donné que les plateformes SoC sont toujours en S0, le seul objet intéressant ici est _S0W. Cet objet spécifie la capacité de la plateforme à sortir d’un état d’inactivité de faible consommation en réponse au signal de veille d’un appareil. L’objet est utilisé par Windows pour déterminer l’état D cible de l’appareil pendant l’inactivité à faible consommation d’énergie du système. Pour plus d’informations sur _S0W, consultez la section 7.2.20, « _S0W (S0 Device Wake State) », dans la spécification ACPI 5.0.

Pour la plupart des plateformes SoC, les appareils sont gérés de manière agressive vers l’état D3 lorsqu’ils sont inactifs, et le système est capable de sortir de l’inactivité à faible alimentation pendant que l’appareil est dans cet état. Pour un tel système, l’objet _S0W retourne 3 (ou 4, s’il prend également en charge D3cold).

_S0W(4) est une exigence pour D3Cold, que l’appareil prenne ou non en charge le wake.

N’importe quel état D peut être désigné comme l’état de veille le plus faiblement alimenté, et certaines classes d’appareils ou certains bus utilisent des valeurs différentes. Par exemple, les appareils connectés à SDIO et USB utilisent l’état D2 pour cet état.

Pour faciliter la migration des pilotes de périphérique de Windows 7 vers Windows 8 ou Windows 8.1, votre appareil peut également être amené à fournir _S4W. Actuellement, la seule classe d’appareil qui a cette exigence est la mise en réseau (Ndis.sys).

Interruptions prenant en charge le éveil (_CRS)

La description de la ressource d’un appareil indique que l’appareil est capable de détecter et de signaler un événement de sortie de veille en marquant une interruption comme étant « compatible avec la veille » (ExclusiveAndWake ou SharedAndWake). Windows et les pilotes de périphérique fournissent une gestion spéciale de ces interruptions pour s’assurer qu’elles sont activées lorsque l’appareil passe à un état de faible consommation. Pour plus d’informations, consultez les descriptions des descripteurs de ressources Interrupt et GpioInt dans la section 6.4.3.6, « Descripteur d’interruption étendu » et la section 6.4.3.8.1 , « DEscripteurs de connexion GPIO », de la spécification ACPI 5.0.

Activation de l’éveil

En fonction du scénario utilisateur ou de la stratégie système, les appareils prenant en charge la veille peuvent être ou non réellement armés pour la veille. Par conséquent, les interruptions prenant en charge la veille peuvent être activées ou non lorsque l’appareil est inactif. Outre l’activation des interruptions, Windows utilise les mécanismes suivants pour activer la veille sur un appareil.

Veille veille de l’appareil (_DSW)

ACPI définit l’objet _DSW comme un moyen pour le système d’exploitation d’informer le microprogramme de la plateforme ACPI de la prochaine période d’inactivité en veille ou à faible consommation d’énergie. Cet objet est facultatif et est utilisé uniquement si la plateforme a besoin de configurer à l’avance du matériel d’éveil spécifique à la plateforme. L’état D cible pour l’appareil et l’état S cible pour le système sont tous deux fournis. La combinaison état D et état S est toujours conforme aux informations fournies par le ou les objets _SxW de l’appareil.

Power Resources for Wake (_PRW)

Dans certains cas, des ressources d’alimentation supplémentaires doivent être activées pour qu’un appareil soit activé pour le réveil. Dans ce cas, l’appareil peut fournir l’objet _PRW pour répertorier ces ressources d’alimentation supplémentaires. Le pilote WINDOWS ACPI, Acpi.sys, gère ces ressources d’alimentation comme il le fait normalement, en veillant à ce qu’elles soient activées lorsqu’elles sont nécessaires par un appareil (c’est-à-dire un appareil activé pour la veille) et qu’elles sont désactivées dans le cas contraire.

_PRW est également utilisé pour définir la fonctionnalité de veille pour les plateformes PC traditionnelles (matériels ACPI complets).