Partager via

Objets d’espace de noms de gestion des appareils

  • Article

La spécification ACPI 5.0 définit plusieurs types d’objets d’espace de noms qui peuvent être utilisés pour gérer des appareils. Par exemple, les objets d’identification d’appareil contiennent des informations d’identification pour les appareils qui se connectent à des bus, tels que I2C, qui ne prennent pas en charge l’énumération matérielle des appareils enfants. D’autres types d’objets d’espace de noms peuvent spécifier des ressources système, décrire les dépendances des appareils et indiquer quels appareils peuvent être désactivés.

Identification de l’appareil dans Windows

Windows Plug-and-Play recherche et charge les pilotes de périphérique en fonction d’un identificateur de périphérique fourni par l’énumérateur de l’appareil. Les énumérateurs sont des pilotes de bus qui savent comment extraire les informations d’identification de l’appareil. Certains bus (tels que PCI, SD et USB) ont des mécanismes définis par le matériel pour effectuer cette extraction. Pour les bus qui ne le font pas (par exemple, le bus processeur ou un bus périphérique simple), ACPI définit des objets d’identification dans l’espace de noms.

Le pilote ACPI Windows, Acpi.sys, assemble les valeurs trouvées dans ces objets en différentes chaînes d’identificateur de périphérique qui peuvent identifier un appareil spécifiquement, ou de manière générique, en fonction des besoins du pilote. Voici quelques-uns des modèles de chaîne créés pour identifier les appareils énumérés par ACPI :

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

Vous pouvez voir les identificateurs d’appareil créés par Windows pour votre appareil en ouvrant Gestionnaire de périphériques et en inspectant les propriétés ID matériels et ID compatibles de l’appareil énuméré. Chacune de ces chaînes peut être spécifiée dans un fichier INF pour identifier le pilote à charger pour l’appareil. L’ordre de correspondance INF va de l’identificateur matériel le plus spécifique (pilote le plus préféré) à l’identificateur le moins spécifique (pilote le moins préféré), de sorte que les pilotes qui en savent plus sur les fonctionnalités spécifiques de l’appareil peuvent remplacer celles qui sont moins spécifiques (et ne prennent donc en charge qu’un sous-ensemble des fonctionnalités de l’appareil).

Les identificateurs d’appareil doivent être utilisés uniquement pour la correspondance INF et ne doivent jamais être analysés ou traités par le pilote de périphérique. Si le pilote de périphérique a besoin d’identifier le matériel spécifique pour lequel il a été chargé, la méthode recommandée consiste à définir les clés de Registre appropriées au moment de l’installation du fichier INF. Le pilote peut ensuite accéder à ces clés pendant l’initialisation pour obtenir les informations requises.

Identification de l’appareil dans ACPI

ID matériel (_HID)

La configuration minimale requise pour identifier un appareil dans ACPI est l’objet Id matériel (_HID). _HID retourne une chaîne au format « ABC[D]xxxx », où « ABC[D] » est une chaîne de 3 caractères ou 4 caractères qui identifie le fabricant de l’appareil (l'« ID du fournisseur ») et xxxx est un nombre hexadécimal qui identifie l’appareil spécifique fabriqué par ce fournisseur (l'« ID de l’appareil »). Les ID de fournisseur doivent être uniques dans l’ensemble du secteur. Microsoft alloue ces chaînes pour s’assurer qu’elles sont uniques. Les ID de fournisseur peuvent être obtenus à partir de l’ID Plug-and-Play - Demande PNPID.

ACPI 5.0 prend également en charge l’utilisation d’ID de fournisseur attribués par PCI dans _HID et d’autres objets d’identification, de sorte que vous n’aurez peut-être pas besoin d’obtenir un ID de fournisseur auprès de Microsoft. Pour plus d’informations sur la configuration requise pour l’identification du matériel, consultez la section 6.1.5, « _HID (ID matériel) », de la spécification ACPI 5.0.

ID compatible (_CID)

Microsoft a réservé l’ID de fournisseur « PNP » pour les appareils compatibles avec les pilotes de boîte de réception fournis avec Windows. Windows définit un certain nombre d’ID d’appareil à utiliser avec cet ID de fournisseur qui peuvent être utilisés pour charger le pilote fourni par Windows pour un appareil. Un objet distinct, l’objet Compatible ID (_CID), est utilisé pour renvoyer ces identificateurs. Windows préfère toujours les ID matériels (retournés par _HID) aux ID compatibles (retournés par _CID) dans la correspondance INF et la sélection du pilote. Cette préférence permet au pilote fourni par Windows d’être traité comme un pilote par défaut si un pilote spécifique au périphérique fourni par le fournisseur n’est pas disponible. Les ID compatibles dans le tableau suivant sont nouvellement créés pour une utilisation avec les plateformes SoC.

Compatible ID Description
PNP0C40 Tableau de boutons compatible Windows
PNP0C50 Appareil compatible HID-over-I2C
PNP0C60 Appareil de capteur d’affichage d’ordinateur portable convertible
PNP0C70 Dispositif de capteur d’ancrage
PNP0D10 Contrôleur USB compatible XHCI avec débogage standard
PNP0D15 Contrôleur USB compatible XHCI sans débogage standard
PNP0D20 Contrôleur USB conforme à EHCI sans débogage standard
PNP0D25 Contrôleur USB compatible EHCI avec débogage standard
PNP0D40 Contrôleur d’hôte SD conforme aux normes SDA
PNP0D80 Contrôleur de gestion de l’alimentation système compatible avec Windows

ID de sous-système (_SUB), révision matérielle (_HRV) et classe (_CLS)

ACPI 5.0 définit les objets _SUB, _HRV et _CLS qui peuvent être utilisés avec les _HID pour créer des identificateurs qui identifient de manière plus unique une version, une intégration ou une révision matérielle spécifique d’un appareil, ou pour indiquer l’appartenance à une classe d’appareil définie par pci. Ces objets sont généralement facultatifs, mais peuvent être requis par certaines classes d’appareils dans Windows. Pour plus d’informations sur ces objets, consultez la section 6.1, « Device Identification Objects », de la spécification ACPI 5.0.

Pour des raisons de maintenance, le Kit de certification matérielle Windows (HCK) exige que les ID d’appareil sur les systèmes OEM soient des ID « en quatre parties ». Les quatre parties sont l’ID du fournisseur, l’ID de l’appareil, l’ID de fournisseur de sous-système (OEM) et l’ID d’appareil du sous-système (OEM). Par conséquent, l’objet ID de sous-système (_SUB) est requis pour les plateformes OEM.

Device-Specific, méthode (_DSM)

La méthode _DSM est définie dans la section 9.14.1, « _DSM (méthode spécifique à l’appareil) », de la spécification ACPI 5.0. Cette méthode fournit des fonctions de contrôle et de données individuelles spécifiques aux appareils qui peuvent être appelées par un pilote de périphérique sans entrer en conflit avec d’autres méthodes spécifiques à l’appareil. La _DSM d’un appareil ou d’une classe d’appareil spécifique définit un UUID (GUID) qui n’entre pas en conflit avec d’autres UUID. Pour chaque UUID, il existe un ensemble de fonctions définies que la méthode _DSM peut implémenter pour fournir des données ou pour effectuer des fonctions de contrôle pour le pilote. Les données et les formats de données spécifiques aux classes sont fournis dans des spécifications distinctes spécifiques à la classe d’appareil, et sont également abordés dans méthodes Device-Specific ACPI.

Adresse (_ADR) et ID unique (_UID)

Il existe trois exigences supplémentaires pour l’identification de l’appareil :

  • Pour les appareils qui se connectent à un bus parent énumérable matériel (par exemple, SDIO, USB HSIC), mais qui disposent de fonctionnalités ou de contrôles spécifiques à la plateforme (par exemple, interruption d’alimentation ou de sortie de bande latérale), le _HID n’est pas utilisé. Au lieu de cela, l’identificateur de périphérique est créé par le pilote de bus parent (comme indiqué précédemment). Dans ce cas, toutefois, l’objet Address (_ADR) doit se trouver dans l’espace de noms ACPI de l’appareil. Cet objet permet au système d’exploitation d’associer l’appareil énuméré par bus à ses fonctionnalités ou contrôles décrits par ACPI.
  • Sur les plateformes où plusieurs instances d’un bloc IP particulier sont utilisées, afin que chaque bloc ait les mêmes objets d’identification d’appareil, l’objet Identificateur unique (_UID) est nécessaire pour permettre au système d’exploitation de faire la distinction entre les blocs.
  • Deux appareils dans une étendue d’espace de noms particulière ne peuvent pas avoir le même nom.

Objets de configuration d’appareil

Pour chaque appareil identifié dans l’espace de noms, les ressources système (adresses mémoire, interruptions, etc.) consommées par l’appareil doivent également être signalées par l’objet Paramètres de ressources actuels (_CRS). Les rapports sur plusieurs configurations de ressources possibles (_PRS) et les contrôles permettant de modifier la configuration des ressources d’un appareil (_SRS) sont pris en charge, mais facultatifs.

Les nouvelles plateformes SoC sont les ressources GPIO et SPB (Simple Peripheral Bus) qu’un appareil peut consommer. Pour plus d’informations, consultez usage général E/S (GPIO) et SPB (Simple Peripheral Bus).

Une autre nouveauté pour les plateformes SoC est un descripteur DMA fixe à usage général. Le descripteur FixedDMA prend en charge le partage du matériel du contrôleur DMA par un certain nombre d’appareils système. Les ressources DMA (registres de ligne de requête et de canal) allouées statiquement à un appareil système particulier sont répertoriées dans le descripteur FixedDMA. Pour plus d’informations, consultez la section 19.5.49, « FixedDMA (macro de descripteur de ressources DMA) », de la spécification ACPI 5.0.

Modifications de l’état de l’appareil

Les appareils énumérés par ACPI peuvent être désactivés ou supprimés pour diverses raisons. L’objet Status (_STA) est fourni pour permettre la communication de ces modifications d’état au système d’exploitation. Pour obtenir une description de _STA, consultez la section 6.3.7 de la spécification ACPI 5.0. Windows utilise _STA pour déterminer si l’appareil doit être énuméré, affiché comme désactivé ou non visible par l’utilisateur. Ce contrôle dans le microprogramme est utile pour de nombreuses applications, y compris la station d’accueil et le basculement d’hôte à fonction USB OTG.

En outre, ACPI fournit un mécanisme de notification qu’ASL peut utiliser pour notifier les pilotes d’événements dans la plateforme, tels qu’un appareil supprimé dans le cadre d’une station d’accueil. En général, lorsque l’état d’un appareil ACPI change, le microprogramme doit effectuer une notification de « vérification de l’appareil » ou de « vérification de bus » pour que Windows réinscrire l’appareil et réévalue ses _STA. Pour plus d’informations sur les notifications ACPI, consultez la section 5.6.6, « Notifications d’objets d’appareil », de la spécification ACPI 5.0.

Activer/désactiver

Dans le cadre de Windows Plug-and-Play, les pilotes doivent pouvoir être activés et désactivés dynamiquement par l’utilisateur ou par le système (par exemple, pour mettre à jour un pilote).

Les appareils on-SoC sont intégrés à la puce SoC et ne peuvent pas être supprimés. Les pilotes de la plupart des appareils on-SoC peuvent être exemptés des exigences d’activation et de désactivation. Pour les pilotes qui ne sont pas exemptés, il existe des interfaces de pilote pour indiquer que le pilote prend en charge la suppression ordonnée. Pour plus d’informations, consultez le document intitulé « Réduction des exigences PNP pour les pilotes SoC » sur le site web Microsoft Connect.

Si un pilote prend en charge la suppression ordonnée et que le matériel de l’appareil peut être désactivé (autrement dit, l’appareil peut être configuré pour cesser d’accéder aux ressources qui lui sont affectées), le nœud d’espace de noms ACPI de l’appareil peut inclure l’objet Disable (_DIS). Cette méthode est évaluée par le système d’exploitation chaque fois que le pilote est supprimé. L’utilisation de _DIS présente les exigences supplémentaires suivantes :

  • _STA devez effacer le bit « activé et décoder ses ressources » chaque fois que l’appareil est désactivé.
  • L’appareil doit fournir l’objet Définir les paramètres de ressource (_SRS) pour réactiver le matériel de l’appareil et définir le bit ci-dessus dans _STA.

Pour plus d’informations, consultez les sections 6.2.3 (_DIS), 6.2.15 (_SRS) et 6.3.7 (_STA) de la spécification ACPI 5.0.

Dépendances d’appareil

En règle générale, il existe des dépendances matérielles entre les appareils sur une plateforme particulière. Windows exige que toutes ces dépendances soient décrites afin de s’assurer que tous les appareils fonctionnent correctement à mesure que les choses changent dynamiquement dans le système (l’alimentation du périphérique est supprimée, les pilotes sont arrêtés et démarrés, etc.). Dans ACPI, les dépendances entre les appareils sont décrites de la manière suivante :

  1. Hiérarchie des espaces de noms. Tout appareil qui est un appareil enfant (répertorié en tant qu’appareil dans l’espace de noms d’un autre appareil) dépend de l’appareil parent. Par exemple, un périphérique HSIC USB dépend du port (parent) et du contrôleur (grand-parent) auquel il est connecté. De même, un appareil GPU répertorié dans l’espace de noms d’un appareil MMU (system memory-management unit) dépend de l’appareil MMU.

  2. Connexions de ressources. Les appareils connectés aux contrôleurs GPIO ou SPB dépendent de ces contrôleurs. Ce type de dépendance est décrit par l’inclusion des ressources de connexion dans le _CRS de l’appareil.

  3. Dépendances OpRegion. Pour les méthodes de contrôle ASL qui utilisent OpRegions pour effectuer des E/S, les dépendances ne sont pas implicitement connues par le système d’exploitation, car elles sont déterminées uniquement pendant l’évaluation de la méthode de contrôle. Ce problème s’applique à GeneralPurposeIO et GenericSerialBus OpRegions dans lesquelles Plug-and-Play pilotes fournissent l’accès à la région. Pour atténuer ce problème, ACPI définit l’objet OpRegion Dependency (_DEP). _DEP doivent être utilisés dans n’importe quel espace de noms d’appareil dans lequel une opregion (ressource HW) est référencée par une méthode de contrôle, et ni 1 ni 2 ci-dessus ne s’applique déjà à la ressource de connexion OpRegion référencée. Pour plus d’informations, consultez la section 6.5.8, « _DEP (dépendances de région d’opération) », de la spécification ACPI 5.0.

Il peut également y avoir des dépendances logicielles entre les pilotes de périphérique. Ces dépendances doivent également être décrites.

Pour plus d’informations, consultez les ressources suivantes :