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 de l’appareil pour un appareil. Par exemple, un ensemble d’objets peut spécifier les ressources d’alimentation requises par un appareil dans chaque état d’alimentation de l’appareil pris en charge. Un autre type d’objet peut décrire la capacité de l’appareil à se réveiller à partir d’un état de faible alimentation en réponse aux événements matériels.

Gestion de l’alimentation des appareils dans Windows

Alors qu’un système est en cours d’exécution (autrement dit, le système se trouve dans l’état de travail défini par ACPI, S0), les appareils individuels peuvent effectuer des transitions entre les états d’alimentation des appareils, en fonction de l’activité, pour économiser de l’alimentation. Dans les systèmes DE 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 SoC Windows. Par conséquent, la durée de vie 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 en termes d'alimentation par PoFx par le biais d’un plug-in de moteur d’alimentation spécifique à SoC (microPEP) qui est informé des spécificités des contrôles d’alimentation et d’horloge du SOC. Pour plus d’informations sur PoFx, consultez Vue d’ensemble de Power Management Framework.

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 la fonction ou le pilote de classe) prend des décisions de transition d’état de l’alimentation de l’appareil 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 de dispositifs le font, d'utiliser la gestion de l'alimentation des dispositifs ACPI seule ou en combinaison avec le microPEP pour la gestion de l'alimentation des dispositifs sur puce.

Comme décrit dans la 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. En utilisant cette prise en charge, les appareils, les plateformes et les pilotes peuvent choisir d’avoir l’alimentation de l’appareil complètement supprimée pendant les périodes d’inactivité de l’exécution. Cette fonctionnalité peut améliorer considérablement la durée de vie de la batterie. Toutefois, la suppression de la puissance doit être prise en charge par tous les composants affectés afin de pouvoir revenir à D0 avec succès. Pour cette raison, les pilotes (bus et fonction) ainsi que la plateforme elle-même doivent indiquer qu'ils le prennent en charge. Pour plus d’informations sur l'activation de D3cold pour un pilote, consultez Prise en charge de D3cold dans un pilote.

Gestion de l’alimentation des appareils dans ACPI

Les appareils de namespace prennent en charge jusqu'à quatre états d'alimentation, numérotés de 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 qui consomment moins de puissance que des états numérotés inférieurs. 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 au bus. Cette exigence, et la puissance utilisée pour y répondre, sont supprimées dans D3cold. Enfin, un appareil peut être armé pour se réveiller à partir d’un état de faible puissance en raison d’un événement matériel, et, si nécessaire, pour faire sortir la plateforme d’un état inactif.

La plateforme indique son support pour D3cold en accordant le contrôle par l’OS de la fonctionnalité « _PR3 Support » (bit 2) lorsqu'il est demandé à l’aide de la méthode des capacité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 ces objets.

Ressources et états d'énergie

Un appareil déclare sa prise en charge d’un état d’alimentation en répertoriant l’ensemble des ressources d’alimentation dont il a besoin pour être 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 conduisent. 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 de laquelle 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 ACPI Windows, Acpi.sys, surveille les dépendances d’alimentation entre les appareils qui partagent des ressources et, à mesure que ces appareils passent entre états d’alimentation, garantit que seules les ressources d’alimentation réellement nécessaires par un appareil sont activées à tout moment particulier.

Exigences en matière de ressources énergétiques (_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.

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 parfois après la transition vers D3Cold.

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

État de l’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 les ressources d’alimentation activées pour l’état. _PSx est destiné à effectuer toutes les actions spécifiques à la plateforme requises autour du cycle d’alimentation. _PSx ne doit pas accéder aux registres d’appareils affectés au pilote de fonction, accéder aux registres standard de bus affectés au pilote de bus, ou activer ou désactiver les ressources d’alimentation, qui est une opération réservée à Acpi.sys.

Fonctionnalités de mise en éveil

Les appareils gérés par l’alimentation peuvent être en mesure de détecter les événements lorsqu’ils sont dans un état de faible alimentation et provoquent le ré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 de réveil du périphérique Sx (_SxW)

Sur une plateforme donnée, il existe un mappage spécifique entre les états d’appareil qui prennent en charge la fonctionnalité de mise en éveil et les états système qui peuvent répondre aux événements de veille. 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 système supporté, Sx. Étant donné que les plateformes SoC sont toujours en S0, le seul objet d’intérêt ici est _S0W. Cet objet spécifie la capacité de la plateforme à se réveiller à partir d’un état d’inactivité à faible alimentation 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é du système à faible puissance. Pour plus d’informations sur _S0W, consultez la section 7.2.20, « _S0W (état de veille de l’appareil S0) » dans la spécification ACPI 5.0.

Pour la plupart des plateformes SoC, les appareils sont gérés de manière agressive à l'état D3 dès qu’ils sont inactifs, et le système est capable de se réveiller du mode veille à faible consommation d'énergie 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 en charge le réveil ou non.

N'importe quel état D peut être désigné comme l'état de réveil à faible consommation le plus bas, et certaines catégories de dispositifs ou certains types de 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 tenu de fournir des _S4W. Actuellement, la seule classe d’appareil qui a cette exigence est la mise en réseau (Ndis.sys).

Interruptions compatibles avec le ré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 veille en marquant une interruption comme étant « compatible avec le réveil » (ExclusiveAndWake ou SharedAndWake). Les pilotes Windows et les pilotes de périphérique fournissent une gestion spéciale de ces interruptions pour s’assurer qu’ils sont activés lorsque l’appareil passe à un état à faible alimentation. Pour plus d’informations, consultez les descriptions des descripteurs de ressources Interruption et GpioInt dans la section 6.4.3.6, « Descripteur d’interruption étendue » et la section 6.4.3.8.1 , « Descripteurs de connexion GPIO », de la spécification ACPI 5.0.

Activation du réveil

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

Réveil en veille de l’appareil (_DSW)

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

Ressources d'alimentation pour réveil (_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 ACPI Windows, Acpi.sys, gère ces ressources d’alimentation normalement, en s’assurant qu’elles sont activées lorsqu’elles sont nécessaires par un appareil (c’est-à-dire un appareil activé pour le réveil) et sont désactivées dans le cas contraire.

_PRW est également utilisé pour définir la capacité de réveil pour les plateformes de PC traditionnelles (matériel ACPI complet).