Statistiques d'alimentation HAL

La puissance du sous-système de l'appareil est souvent mesurée et enregistrée dans un environnement de laboratoire pour diverses conditions d'équilibre, par exemple lorsque l'écran est allumé, ou l'appareil est inactif. Cela fonctionne pour les sous-systèmes avec une constante ou dans des conditions faciles à mesurer dans les environnements de laboratoire, mais pas dans certains cas, comme l'affichage d'une vidéo sur un écran.

IPower.hal 1.0 fournit une interface pour transmettre des des conseils d'alimentation et des rapports sur des données cumulées sur les métriques de sommeil du sous-système. Sur Android 10 ou version ultérieure, la fonction de création de rapports sur les statistiques cumulées se trouve dans les API de collecte de statistiques d'alimentation IPowerStats.hal. permet de récupérer les données sur la consommation d'énergie sur l'appareil. Il remplace les la partie cumulative de la collecte de statistiques de l'interface IPower.hal, pour une séparation plus claire des fonctionnalités.

Les lectures du service IPowerStats ne sont pas périodiques. Elles se produisent à les moments clés, par exemple quand la batterie se décharge de 1 %. Les lectures sont moins fréquentes lorsque la décharge de la batterie est faible et plus fréquente lorsqu'elle est élevée. Les données peuvent être renvoyés aux serveurs et peuvent être utilisés dans les rapports de bogues à des fins d'analyse et de tri. Cela soutient les efforts continus pour réduire la consommation d'énergie et augmenter de la batterie.

IPower.hal et IPowerStats.hal

Les interfaces IPower.hal et IPowerStats.hal sont toutes deux disponibles sur Android 10, mais La fonctionnalité de collecte de statistiques IPower.hal est uniquement disponibles dans l'interface IPowerStats.hal. La La fonctionnalité IPowerStats.hal inclut des API permettant d'acquérir et d'utiliser Données collectées à partir des mesures de puissance sur l'appareil pour les appareils compatibles:

  • Mesure la consommation d'énergie au niveau du rail pour les basses fréquences (getRailInfo) et haute fréquence (streamEnergyData) et signale l'énergie accumulée depuis le démarrage.
  • Informations indiquées dans les rapports concernant chaque PowerEntity compatible pour lequel des données sont disponibles. PowerEntity est un sous-système de la plate-forme, un périphérique ou un domaine d'alimentation qui a un impact sur la consommation d'énergie de l'appareil.
  • Indique l'ensemble des états d'une entité (getPowerEntityStateInfo) pour lesquelles les entités spécifiées fournissent des données de résidence, puis indique des données accumulées pour chaque PowerEntity spécifié.

Les API IPowerStats.hal sont utilisées par les clients suivants:

  • Statsd, pour collecter des métriques de consommation d'énergie par rail.
  • Perfetto, pour corréler la consommation d'énergie avec le processeur activité.
  • Batterystats, pour améliorer l'attribution de la batterie en utilisant plutôt que d'estimer la consommation de la batterie à partir de constantes prédéfinies dans power_profile.xml.

Avec Android 10 ou version ultérieure, le fabricant peut choisir entre les fonctions IPower.hal et IPowerStats.hal, mais tous les clients doivent revenir à IPower.hal si IPowerStats.hal n'est pas implémenté .

Options d'implémentation de IPowerStats.hal

Seules les fonctions IPower.hal sont disponibles sur Android 7 à Android 9. Les appareils mis à niveau vers Android 10 doivent : disposer d'un sous-système matériel de surveillance de l'alimentation ou d'autres moyens permettant de surveiller et enregistrer des statistiques d'alimentation. Certains SoC rassemblent des statistiques d'utilisation de l'alimentation, ou vous pouvez obtenir la résidence de l'état de l'entité d'alimentation des informations par le biais d'un logiciel. Le matériel de surveillance de l'alimentation n'est nécessaire que pour sont compatibles avec getRailInfo(), getEnergyData() et streamEnergyData()

Si vous implémentez IPowerStats.hal sans surveillance de l'alimentation du matériel, getRailInfo(), getEnergyData(), et streamEnergyData() renvoie NOT_SUPPORTED. De même, getPowerEntityInfo(), getPowerEntityStateInfo() et getPowerEntityStateResidencyData()peut également revenir NOT_SUPPORTED s'il n'est pas destiné à être utilisé.

Voici des exemples de données renvoyées par les API Rail-monitoring :

  • Le rail d'alimentation de l'écran a consommé X μW.
  • Le rail d'alimentation du modem a consommé Y μW.

Les exemples de données renvoyées par les API d'état du sommeil du sous-système incluent :

  • Le modem est resté en veille pendant X ms.
  • Le SoC était à l'état de réduction de l'alimentation pendant Y ms.
  • Le GPU était à l'état suspendu pendant Z ms.

Utiliser un sous-système matériel de surveillance de l'alimentation

Si la conception de votre appareil dispose d'un sous-système matériel de surveillance de l'alimentation, implémentez IPowerStats.hal en créant un seul nœud sysfs à partir duquel PowerStats.hal peut analyser des données, ou en créant une collection d'appels système de type ioctl.

Vous devez implémenter votre pilote de noyau de manière à empêcher l'accumulateur overflow. L'algorithme utilisé dépend de votre propre système de surveillance de l'alimentation conception du sous-système, qui doit fournir à la fois la tension instantanée et la tension moyenne des bus et les mesures actuelles. Le pilote du noyau doit capturer ces données qui n'efface pas les accumulateurs d'énergie et doit maintenir des données énergétiques accumulées pour chaque sous-rail depuis le démarrage, sous la forme d'un réseau qui est incrémentée avec l'énergie relevée par chaque accumulateur requête.

Les statistiques d'un composant donné (ou éventuellement de plusieurs composants) doivent figurer dans un seul nœud. Bien qu'il ne s'agisse pas d'une utilisation conventionnelle de sysfs, (ce qui limite normalement chaque nœud à une seule valeur), elle garantit que toutes les données sont cohérentes.

Conseils de conception

  • Maintenez une latence faible (1 ms maximum) lors de la lecture à partir de sysfs ou à effectuer des appels système.
  • Assurez-vous que la fonctionnalité des statistiques complémentaires n'augmente pas de manière mesurable la décharge électrique:
    • Ne pas augmenter les wakeups des points d'accès (PA) et/ou des sous-systèmes pour suivre de paramètres tels que le temps passé en mode Sommeil.
    • Transférez les statistiques entre le processeur d'applications et le micrologiciel avec opportunisme avec d'autres types de trafic lorsque cela est possible.
  • Si nécessaire, le sous-système peut utiliser les fonctions de pilote suivantes:
    • Mise en cache interne des données pour éviter la latence/les réveils au détriment d'une légère des données obsolètes.
    • en effectuant une extrapolation lorsque le sous-système est en veille, pour fournir de s'endormir sans réactiver le sous-système.

Choisissez des composants, des sous-systèmes et des statistiques

Lors du choix des composants ou sous-systèmes à partir desquels collecter Données IPowerStats.hal, sélectionnez tout ce qui consomme sur l'appareil de courant significatif (5 mA ou plus) ou compatible avec plusieurs modes de consommation électrique, tels que:

  • Sous-systèmes SoC individuels.
  • Les sous-systèmes situés partiellement ou entièrement en dehors du SoC, tels que le Wi-Fi, le ou le processeur de sécurité.
  • Périphériques tels que les LED et les caméras haute puissance
  • Domaines d'alimentation qui utilisent différents modes (comme le domaine d'alimentation du SoC dans son ensemble).

Personnalisation

Cette fonctionnalité facultative peut être personnalisée. Concevoir des cas d'utilisation et personnalisez votre utilisation:

  • Décidez quels rails mesurer et à quelle fréquence.
  • Décidez quand lire les données et comment les interpréter.
  • Décidez des mesures à prendre et quand le faire, en fonction de vos données.

Validation

Les tests VTS garantissent que les exigences Android sont respectées. Les commentaires dans Les IPowerStats.hal permettent de vérifier qu'un appareil se trouve dans de conformité.

Par exemple, si vous appelez getRailInfo() et qu'il ne renvoie rien, le test VTS échoue, car vous n'avez pas reçu d'informations sur l'état rails, ou un état renvoyé SUCCESS. De même, si vous avez reçu mais il était accompagné d'un NON_SUPPORTED ou FILE_SYSTEM_ERROR, c'est aussi un échec. VTS vérifie que les spécifications du fabricant de l'appareil sont respectées dans le fichier HAL, en utilisant les exigences dans les commentaires IPower.hal et IPowerStats.hal. Une Voici un exemple de commentaires utilisés dans les tests VTS:

/**
* Rail information:
* Reports information related to the rails being monitored.
*
* @return rails Information about monitored rails.
* @return status SUCCESS on success or NOT_SUPPORTED if
* feature is not enabled or FILESYSTEM_ERROR on filesystem nodes
* access error.
*/
getRailInfo()
generates(vec<e;RailInfo>e; rails, Status status);