Gestion de l’alimentation de la caméra
Modes de gestion de l’alimentation
Les composants hors système sur une puce (SoC) du sous-système de caméra doivent prendre en charge deux modes de gestion de l’alimentation. Les composants de la caméra doivent prendre en charge un mode actif dans lequel l’appareil photo diffuse activement du contenu vers une application. En outre, les composants de l’appareil photo doivent prendre en charge un mode de mise hors tension dans lequel l’appareil photo est éteint, l’alimentation est supprimée et l’appareil photo consomme zéro watts. Le tableau suivant décrit les modes de gestion de l’alimentation actif et supprimé pour l’appareil photo.
Mode | Description | État d’alimentation de l’appareil (Dx) | Consommation énergétique moyenne | Latence de sortie à actif | Mécanisme de transition |
---|---|---|---|---|---|
Actif (streaming) |
L’appareil photo diffuse activement du contenu vers une application. Le contenu peut être en plein mouvement, en préversion ou encore en capture photo. |
Oui |
Spécifique au capteur, à l’AF et au flash. |
N/A |
Transition D0 initiée par le logiciel. (Une application a lancé la diffusion en continu en définissant l’état d’une broche de capture sur KSSTATE_ACQUIRE.) |
Alimentation - supprimée |
L’appareil photo ne diffuse pas de contenu vers les applications. Aucun contexte n’est conservé sur le capteur de l’appareil photo, le périphérique flash ou le moteur de focus automatique. |
Oui |
0 watts |
< 200 millisecondes jusqu’à la première image (voir la note ci-dessous). |
Transition D3 initiée par le logiciel. (L’état de toutes les broches de diffusion en continu a été défini sur toute valeur autre que KSSTATE_RUN.) |
Note Windows s’attend à ce que le temps de transition entre le mode actif et le mode de mise hors tension (latence d’arrêt) soit inférieur à 100 millisecondes. La plupart des efforts de gestion de l’alimentation sont axés sur la réduction du temps de transition du mode supprimé vers le mode actif (latence).
Les deux mêmes modes de gestion de l’alimentation, actif et supprimé, doivent être pris en charge par les unités de traitement d’images sur SoC. Le fournisseur de SoC définit les composants individuels qui composent les unités de traitement d’images et leurs états de gestion de l’alimentation. Nous recommandons qu’un seul pilote contrôle les unités de traitement d’image sur SoC et que toutes les unités de traitement d’images pour la capture de caméra soient présentées au plug-in du moteur d’alimentation (PEP) en tant que composant unique géré par l’alimentation.
Mécanismes de gestion de l’alimentation logicielle
Les unités de traitement d’image On-System on a Chip (SoC) et les composants de la caméra Hors SoC sont censés ne consommer aucune puissance (zéro watts) lorsque le système est en veille connectée et que l’écran est éteint. Le mécanisme logiciel principal pour la gestion de l’alimentation est le comptage des références de la broche de capture de la caméra. Ce nombre de références est géré par le pilote du contrôleur de caméra, qui est un minidriver AVStream. Ce mécanisme de gestion de l’alimentation de base peut être utilisé chaque fois que le système est allumé, y compris les moments où l’affichage du système est sous tension.
Le pilote du contrôleur de caméra doit transférer les transitions d’état de gestion de l’alimentation vers les pilotes qui contrôlent les composants Hors SoC, tels que le capteur de caméra, le focuseur automatique et le flash. En réponse, les pilotes qui contrôlent ces appareils doivent prendre des mesures spécifiques pour modifier les états d’alimentation et pour supprimer ou appliquer l’alimentation.
Architecture de pilote recommandée
Le sous-système de caméra doit être exposé à Windows via un seul minidriver AVStream appelé pilote de contrôleur de caméra. Nous recommandons au pilote du contrôleur de caméra de ne pas accéder directement au matériel et de ne pas gérer directement les composants matériels de gestion de l’alimentation. Au lieu de cela, le pilote du contrôleur de caméra doit transférer la gestion de l’alimentation et les demandes matérielles à d’autres pilotes qui composent le sous-système de caméra.
Le matériel de traitement d’images sur SoC doit être géré par le plug-in de moteur d’alimentation soC (PEP). Le matériel de traitement d’images doit être géré par un pilote WDF (Windows Driver Frameworks) et ce pilote doit permettre la coopération avec le PEP en définissant le membre IdleTimeout dans la structure WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS sur SystemManagedIdleTimeout. Ce paramètre permet au PEP de contrôler n’importe quelle topologie de partage d’horloge et de rail d’alimentation qui est unique au matériel SoC. Le pilote qui contrôle l’unité de traitement d’images sur le SoC doit représenter l’unité de traitement d’images entière comme un seul composant géré par l’alimentation afin que les fonctionnalités WDF par défaut pour la gestion de l’alimentation puissent être utilisées.
Les composants du sous-système de caméra hors soC doivent être gérés par un ou plusieurs pilotes KMDF (Kernel-Mode Driver Framework). Les pilotes des composants Hors SoC doivent passer à l’état d’arrêt (D3) lorsque leurs composants ne sont plus nécessaires pour la capture de caméra. En outre, les pilotes pour les composants hors SoC doivent activer D3cold, ce qui permet au sous-système ACPI sous-jacent de modifier l’état des lignes GPIO pour appliquer et supprimer l’alimentation. Pour plus d'informations, consultez Prise en charge de D3cold dans un pilote.
Le diagramme de blocs suivant montre l’architecture de pilote recommandée.
Tous les pilotes qui composent le sous-système de caméra, y compris le pilote du contrôleur de caméra, le pilote de l’unité de traitement d’image et les pilotes des composants de caméra Hors SoC, doivent être énumérés dans le même fichier d’installation du pilote (.inf). Tous les pilotes de sous-système de caméra doivent être membres de la classe d’installation de périphérique PnP d’imagerie. Le ClassGuid pour les appareils d’imagerie est {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
Chaque pilote qui représente un seul composant de caméra doit être énuméré en tant qu’appareil unique dans l’espace de noms ACPI.
États actifs et supprimés
Le pilote du contrôleur de caméra doit faire passer les appareils photo à l’état de mise hors tension lorsqu’aucune application ne diffuse du contenu à partir de l’appareil photo. Une application peut arrêter la diffusion en continu, car elle a été fermée par l’utilisateur ou est passée en arrière-plan et suspendue.
Si une application lance la diffusion en continu à partir d’une caméra dont les appareils sont à l’état de mise hors tension, le pilote du contrôleur de caméra doit retourner les appareils photo à l’état actif dans un délai de 100 millisecondes.
Pour modifier les états d’alimentation des différents composants du sous-système de caméra, les pilotes de contrôleur de caméra utilisent des interfaces propriétaires pour communiquer avec les autres pilotes qui composent le sous-système de caméra. Pour rechercher l’interface appropriée, un pilote de sous-système de caméra doit utiliser la méthode standard, qui consiste à envoyer une demande d’E /S IRP_MN_QUERY_INTERFACE qui récupère un ensemble de pointeurs de fonction.
Le pilote du contrôleur de caméra doit placer l’appareil photo à l’état désactivé lorsque toutes les broches de diffusion en continu sont entrées dans l’état KSSTATE_STOP . Windows suspend automatiquement les applications de premier plan lorsque l’utilisateur appuie sur le bouton d’alimentation et que le système entre en veille connectée. Lorsqu’une application de capture est suspendue, les API de capture de caméra fournies par le Windows Runtime sont averties et modifient l’état des broches de capture de caméra, ce qui les amène à entrer dans l’état KSSTATE_STOP.
Lorsque la première broche de diffusion en continu entre dans l’état KSSTATE_ACQUIRE , le pilote du contrôleur de caméra doit placer le périphérique de caméra, y compris l’unité de traitement d’image sur SoC, à l’état actif.
Fonctionnalité de caméra associée
Le capteur d’appareil photo et les périphériques flash peuvent avoir des fonctions supplémentaires au niveau de la plateforme qui doivent être gérées par le pilote. Ces fonctions peuvent inclure les éléments suivants :
- Activation, désactivation et configuration du capteur de caméra sur le bus I2C.
- Configuration du taux de rafale et du niveau de luminosité sur le bus I2C.
- Détection des conditions thermiques du module flash via des lignes GPIO du module flash vers le SoC.
Pour implémenter ces fonctions, les développeurs de pilotes de périphérique de caméra doivent utiliser les méthodes et les conseils résumés dans le tableau suivant.
Fonction | Description | Connexion matérielle/microprogramme | Mécanisme logiciel |
---|---|---|---|
Configuration du capteur | Énumérez les fonctionnalités du matériel du capteur de caméra ou configurez son mode de fonctionnement actuel. | Communication sur le bus I2C. Les ressources I2C sont décrites dans la méthode _CRS sous l’appareil photo dans l’espace de noms ACPI. | L’interface d’entrée/sortie du bus périphérique simple (E/S) est utilisée pour communiquer avec le contrôleur hôte I2C et le capteur de caméra. |
Détection d’événements de capteur | Déclenchez des événements ou indiquez status à l’aide de lignes GPIO du capteur de la caméra vers le SoC. | Ressources GPIO fournies à l’appareil photo. Ces ressources sont décrites dans la méthode _CRS sous l’appareil photo dans l’espace de noms ACPI. Les épingles GPIO qui signalent les événements doivent être décrits comme des ressources d’interruption GPIO. | L’interruption est traitée par le pilote en réponse à l’événement GPIO. L’interface de demande d’E/S SPB est utilisée pour communiquer avec l’appareil de capteur afin de déterminer la cause de l’interruption. |
Configuration flash | Configurez le périphérique flash pour le débit de rafale, le nombre de LED connectées ou d’autres propriétés. | Communication sur le bus I2C. Les ressources I2C sont décrites dans la méthode _CRS sous l’appareil photo dans l’espace de noms ACPI. | L’interface de demande d’E/S SPB est utilisée pour communiquer avec le contrôleur hôte I2C et le capteur de caméra. |
Coordination avec le pilote d’unité de traitement d’image | Lancer et coordonner la capture avec les circuits de traitement d’image sur le SoC. | N/A | L’interface privée est exposée par le pilote qui gère les unités de traitement d’image. |
Énumération des appareils photo
Pour identifier les appareils photo dans la plateforme, les applications interrogent généralement le gestionnaire de Plug-and-Play (PnP) pour les instances d’appareils photo. Chaque instance PnP correspond à un seul appareil photo. Pour identifier un tel instance, l’intégrateur système définit un appareil photo dans l’espace de noms ACPI. Un appareil photo peut diffuser du contenu vers une seule application à la fois. Toutefois, une application peut diffuser simultanément à partir de plusieurs appareils photo.
Chaque appareil photo représenté par le pilote du contrôleur de caméra (le minidriver AVStream) doit être énuméré dans l’espace de noms ACPI en tant que périphérique distinct enfant du pilote graphique.
Dans un cas particulier, si la plateforme SoC n’est pas en mesure de diffuser simultanément du contenu à partir de tous les appareils photo de la plateforme à n’importe quelle combinaison de leurs résolutions ou modes signalés, un seul appareil photo peut être énuméré à la place. Toutefois, cette implémentation nécessite une attention particulière et ne doit être entreprise qu’en collaboration directe avec Microsoft.
Les appareils qui représentent le reste du sous-système de l’appareil photo, y compris l’unité de traitement d’image on-SoC et le capteur de caméra hors SoC, le focuseur automatique et le flash, doivent être énumérés comme un ou plusieurs appareils dans l’espace de noms ACPI. L’unité de traitement d’image on-SoC doit être énumérée en tant qu’appareil distinct des appareils qui représentent les composants hors soC de l’appareil photo.
Liste de contrôle de la gestion de l’alimentation des caméras
Les intégrateurs système, les fournisseurs de capteurs de caméras et les fournisseurs système sur puce (SoC) doivent utiliser la liste de contrôle de cet article pour s’assurer que leur conception de gestion de l’alimentation système est compatible avec Windows 10.
- L’intégrateur système doit communiquer et collaborer avec le fournisseur soC lors de la sélection des composants de capteur de caméra et de l’intégration des appareils photo.
- Le développeur du pilote du contrôleur de caméra doit effectuer les opérations suivantes :
- Désactivez l’alimentation du matériel de la caméra lorsque les applications ne diffusent plus de contenu à partir de l’appareil photo. (Cela se produit lorsque toutes les broches de capture sont à l’état KSSTATE_STOP.)
- Activez l’alimentation du matériel de la caméra lorsqu’une application démarre la diffusion en continu à partir de l’une des broches de capture de l’appareil photo.
- Développez un pilote KMDF qui gère l’unité de traitement d’image on-SoC. Le pilote du contrôleur de caméra doit utiliser des interfaces de pilote personnalisées pour indiquer au pilote d’unité de traitement d’image d’initier ou de terminer la capture de la caméra.
- Vérifiez que le pilote d’unité de traitement d’image est inscrit auprès de l’infrastructure de gestion de l’alimentation Windows (PoFx) afin que le PEP fourni par le fournisseur de SoC puisse contrôler la gestion de l’alimentation du matériel de l’unité de traitement d’image.
- Développez un pilote WDF (Windows Driver Frameworks) pour gérer chaque composant matériel qui gère le matériel de caméra hors SoC, y compris le capteur de caméra, le focuseur automatique et le flash facultatif. Le pilote du contrôleur de caméra doit utiliser des interfaces de pilote personnalisées pour indiquer aux pilotes du matériel de caméra hors SoC d’initier ou de terminer la capture de la caméra.
- Assurez-vous que les pilotes qui gèrent le matériel de caméra hors soC lancent une transition D3 lorsque les composants de la caméra doivent être mis hors tension afin qu’ACPI soit informé de la transition D3 et puisse retirer l’alimentation des composants. • Assurez-vous que les pilotes qui gèrent le matériel de caméra hors soC lancent une transition D0 lorsque les composants de la caméra doivent être sous tension afin qu’ACPI soit informé de la transition D0 et puisse appliquer l’alimentation aux composants.
- Développez n’importe quel code de pilote pour gérer la configuration du matériel du capteur photo ou du périphérique flash.
- Informez l’intégrateur système de l’ordre attendu des ressources GPIO et I2C requises pour gérer le matériel du capteur photo ou l’appareil flash.
- Vérifiez que tous les pilotes qui composent le sous-système de caméra sont énumérés dans le même fichier d’installation de pilote (.inf).
- Vérifiez que tous les pilotes qui composent le sous-système de la caméra sont membres de la classe de configuration du périphérique PnP d’imagerie. Le ClassGuid pour les appareils de création d’images est {6bdd1fc6-810f-11d0-bec7-08002be2092f}.
- L’intégrateur de système doit concevoir le microprogramme ACPI de la plateforme pour effectuer les opérations suivantes :
- Énumérez chaque appareil photo en tant qu’appareil distinct dans l’espace de noms ACPI.
- Incluez un objet _PLD sous chaque appareil photo dans l’espace de noms ACPI pour indiquer si la caméra se trouve à l’avant ou à l’arrière de l’ordinateur.
- Incluez une ressource d’alimentation à la racine de l’espace de noms ACPI pour chaque appareil photo. Tous les composants matériels hors soC d’un appareil photo donné (capteur, AF, flash, etc.) doivent être dans une seule ressource d’alimentation.
- Implémentez les méthodes de contrôle _ON et _OFF pour chaque ressource d’alimentation afin de modifier l’état de la broche GPIO à partir du soC qui pilote le matériel de commutation de rail d’alimentation.
- Fournissez les méthodes _PR0 et _PR3 sous chaque appareil photo de l’espace de noms pour référencer la ressource d’alimentation pour chaque appareil photo et le matériel associé.
- Fournissez un objet _CRS sous chaque appareil photo de l’espace de noms ACPI pour énumérer les ressources GPIO et I2C pour le capteur d’appareil photo et le matériel flash. Les ressources GPIO et I2C doivent être dans l’ordre spécifié par le développeur du pilote de capteur de caméra.
- L’intégrateur de système doit concevoir le routage du matériel et de l’alimentation de la plateforme afin que :
- Chaque appareil photo a son propre rail d’alimentation, qui peut être contrôlé indépendamment des rails d’alimentation pour les autres appareils photo, et qui peut être allumé et désactivé par une broche GPIO du SoC.
- L’intégrateur système doit tester et vérifier que :
- Le matériel de l’appareil photo ne consomme pas d’énergie (zéro watts) lorsque l’appareil photo n’est pas utilisé par une application. L’intégrateur système doit utiliser du matériel instrumenté pour mesurer cette consommation d’énergie.