Statistiques de puissance 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'état stable, par exemple lorsque l'écran est allumé ou que l'appareil est en état d'inactivité. Cela fonctionne pour les sous-systèmes avec une consommation d'énergie constante ou dans des conditions facilement mesurables dans des environnements de laboratoire, mais pas pour certains cas d'utilisation, comme lorsqu'un écran affiche une vidéo.

IPower.hal 1.0 fournit une interface permettant de transmettre des conseils d'alimentation et de rapporter des données cumulées sur les métriques d'état de veille du sous-système. Sous Android 10 et versions ultérieures, la fonction de rapport de statistiques cumulées réside dans les API de collecte de statistiques d'alimentation IPowerStats.hal et fournit un moyen de récupérer les données de consommation d'énergie sur l'appareil. Cela remplace la partie de collecte de statistiques cumulatives de l'interface IPower.hal , pour une séparation plus claire des fonctionnalités.

Les lectures du service IPowerStats ne sont pas périodiques. Ils surviennent à des moments clés, comme lorsqu'il y a une baisse de batterie de 1 %. Les lectures sont moins fréquentes lorsque la décharge de la batterie est faible et plus fréquentes lorsqu'elle est élevée. Les données peuvent être renvoyées aux serveurs et utilisées dans les rapports de bogues à des fins d'analyse et de tri. Cela soutient les efforts continus visant à réduire la consommation d’énergie et à augmenter la durée de vie de la batterie.

IPower.hal et IPowerStats.hal

Les interfaces IPower.hal et IPowerStats.hal sont disponibles sur Android 10, mais la fonctionnalité de collecte de statistiques IPower.hal n'est disponible qu'à partir de l'interface IPowerStats.hal . La fonctionnalité IPowerStats.hal comprend des API permettant d'acquérir et d'utiliser les données collectées à partir des mesures de puissance sur l'appareil pour les appareils pris en charge :

  • Effectue des mesures d'énergie au niveau du rail pour les clients basse fréquence ( getRailInfo ) et haute fréquence ( streamEnergyData ), et signale l'énergie accumulée depuis le démarrage.
  • Rapporte des informations relatives à chaque PowerEntity prise en charge pour laquelle des données sont disponibles. Une PowerEntity est un sous-système de plate-forme, un périphérique ou un domaine d'alimentation qui a un impact sur la consommation électrique totale de l'appareil.
  • Rapporte l'ensemble des états d'entité de puissance ( getPowerEntityStateInfo ) pour lesquels les entités spécifiées fournissent des données de résidence, puis rapporte les données accumulées pour chaque PowerEntity spécifiée.

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

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

Avec Android 10 et versions ultérieures, un fabricant d'appareil peut choisir entre les fonctions IPower.hal et IPowerStats.hal , mais tous les clients doivent recourir à IPower.hal si IPowerStats.hal n'est pas implémenté.

Options d'implémentation d'IPowerStats.hal

Seules les fonctions IPower.hal sont disponibles sur Android 7 jusqu'à Android 9. Les appareils qui ont été mis à niveau vers Android 10 doivent disposer d'un sous-système matériel de surveillance de l'alimentation ou d'autres moyens disponibles pour surveiller et enregistrer les statistiques d'alimentation. Certains SoC collectent des statistiques de consommation d'énergie pour vous, ou vous pouvez obtenir des informations sur l'état de résidence de l'entité d'alimentation via un logiciel. Le matériel de surveillance de l'alimentation est uniquement nécessaire pour prendre en charge getRailInfo() , getEnergyData() et streamEnergyData() .

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

Voici des exemples de données renvoyées par les API de surveillance ferroviaire :

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

Voici des exemples de données renvoyées par les API d'état de veille du sous-système :

  • Le modem était endormi pendant X ms.
  • Le SoC était dans un état d’effondrement de puissance pendant Y ms.
  • Le GPU était en état de suspension pendant Z ms.

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

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

Vous devez implémenter votre pilote noyau de manière à empêcher le débordement de l'accumulateur. L'algorithme utilisé dépend de la conception unique de votre sous-système matériel de surveillance de l'alimentation, qui doit fournir des mesures instantanées et moyennes de la tension et du courant du bus. Le pilote du noyau doit capturer ces données d'une manière qui n'efface pas les accumulateurs d'énergie, et il doit conserver les données d'énergie accumulées pour chaque sous-rail depuis le démarrage, sous la forme d'une variable de 64 bits qui est incrémentée avec la lecture d'énergie de chaque requête d’accumulateur.

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

Conseils de conception

  • Maintenez une latence faible (1 ms, maximum) lors de la lecture à partir du nœud sysfs ou lors des appels système.
  • Assurez-vous que la prise en charge de la fonctionnalité de statistiques n'augmente pas de manière mesurable la consommation d'énergie :
    • N'augmentez pas les réveils des points d'accès (AP) et/ou des sous-systèmes pour suivre des paramètres tels que le temps passé en mode veille.
    • Transférez les statistiques entre le processeur de l'application et le micrologiciel de manière opportuniste avec un autre 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 les latences/réveils au détriment de données légèrement obsolètes.
    • Effectuer une extrapolation lorsque le sous-système est endormi, pour fournir une durée de sommeil mise à jour sans réveiller le sous-système.

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

Lorsque vous choisissez les composants ou sous-systèmes à partir desquels collecter les données IPowerStats.hal , sélectionnez tout élément sur l'appareil qui consomme un courant important (5 mA ou plus) ou qui prend en charge plusieurs modes de consommation d'énergie, tels que les suivants :

  • Sous-systèmes SoC individuels.
  • Sous-systèmes partiellement ou totalement extérieurs au SoC, comme le WiFi, le processeur d'image ou le processeur de sécurité.
  • Périphériques tels que LED haute puissance et caméras.
  • Domaines de puissance qui utilisent différents modes (comme le domaine de puissance pour le SoC dans son ensemble).

Personnalisation

Cette fonctionnalité facultative peut être personnalisée. Concevez des cas d’usage et personnalisez votre utilisation :

  • Décidez quels rails mesurer et à quelle fréquence les mesurer.
  • Décidez quand lire les données et comment les interpréter.
  • Décidez quelle action entreprendre et quand la réaliser, en fonction de vos données.

Validation

Les tests VTS garantissent que les exigences Android sont respectées. Les commentaires dans IPowerStats.hal sont utilisés pour vérifier qu'un appareil est conforme.

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 les rails surveillés ou le statut SUCCESS renvoyé. De même, si vous avez reçu des informations ferroviaires, mais qu'elles étaient accompagnées d'une réponse NON_SUPPORTED ou FILE_SYSTEM_ERROR , c'est également un échec. Le VTS vérifie que les spécifications du fabricant de l'appareil sont respectées dans le fichier HAL, en utilisant les exigences des commentaires IPower.hal et IPowerStats.hal. Un exemple de commentaires utilisés dans les tests VTS est présenté ci-dessous :

/**
* 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);