Partager via

Autres objets d’espace de noms ACPI

  • Article

Pour certaines classes d’appareils spécifiques, d’autres objets d’espace de noms ACPI (Advanced Configuration and Power Interface) doivent apparaître sous ces appareils dans l’espace de noms. Cette section répertorie les objets supplémentaires requis pour les plateformes basées sur SoC.

Objets d’identification du processeur

Les processeurs doivent être énumérés dans l’espace de noms ACPI. Les processeurs sont déclarés sous \_SB à l’aide de l’instruction « Appareil », comme avec les autres appareils de la plateforme. Les périphériques processeur doivent contenir les objets suivants :

  • _HID : ACPI0007
  • _UID : nombre unique qui correspond à l’entrée du processeur dans le MADT.

Objets spécifiques à l’affichage

Pour plus d’informations sur les objets spécifiques à l’affichage, consultez l’Annexe B, « Extensions vidéo », de la spécification ACPI 5.0.

exigences relatives aux objets Display-Specific

Méthode Description Condition requise
_DOS Activer/désactiver le basculement de sortie. Obligatoire si le système prend en charge la commutation d’affichage ou les niveaux de luminosité DE l’écran LCD.
_DOD Énumérez tous les appareils attachés à l’adaptateur d’affichage. Obligatoire si le contrôleur intégré prend en charge le basculement de sortie.
_ROM Obtenir des données ROM. Obligatoire si l’image ROM est stockée dans un format propriétaire.
_GPD Obtenir l’appareil POST. Obligatoire si _VPO est implémenté.
_SPD Définissez l’appareil POST. Obligatoire si _VPO est implémenté.
_VPO Options POST vidéo. Obligatoire si le système prend en charge la modification de l’appareil post VGA.
_ADR Retourne l’ID unique de cet appareil. Obligatoire.
_BCL Liste des requêtes des niveaux de contrôle de luminosité pris en charge. Obligatoire si l’écran LCD incorporé prend en charge le contrôle de la luminosité.
_BCM Définissez le niveau de luminosité. Obligatoire si _BCL est implémenté.
_DDC Retourne l’EDID pour cet appareil. Obligatoire si l’écran LCD incorporé ne prend pas en charge le retour d’EDID via l’interface standard.
_DCS Retourne status du périphérique de sortie. Obligatoire si le système prend en charge le basculement d’affichage (via une touche d’accès rapide).
_DG Interroger l’état des graphiques. Obligatoire si le système prend en charge le basculement d’affichage (via une touche d’accès rapide).
_DSS État de l’appareil défini. Obligatoire si le système prend en charge le basculement d’affichage (via une touche d’accès rapide).

Contrôleurs et périphériques hôtes USB

Les contrôleurs hôtes USB sont utilisés sur les plateformes SoC pour connecter des appareils internes et externes. Windows inclut des pilotes de boîte de réception pour les contrôleurs hôtes USB standard qui sont conformes aux spécifications EHCI ou XHCI.

Sur les plateformes basées sur SoC, le contrôleur hôte USB peut être énuméré par ACPI. Windows utilise les objets d’espace de noms ACPI suivants lors de l’énumération et de la configuration du matériel USB compatible :

  • UN ID matériel conforme ACPI (_HID) attribué par le fournisseur.

  • Objet ID unique (_UID), s’il existe plusieurs instance du contrôleur USB dans l’espace de noms (autrement dit, deux nœuds ou plus ayant des objets d’identification de périphérique identiques).

  • UN ID compatible (_CID) pour le contrôleur hôte USB compatible EHCI ou XHCI Standard (EHCI : PNP0D20), (XHCI : PNP0D10).

  • Paramètres de ressource actuels (_CRS) attribués au contrôleur USB. Les ressources du contrôleur sont décrites dans la spécification d’interface matérielle appropriée (EHCI ou XHCI).

Méthode Device-Specific USB (_DSM)

Windows définit une méthode Device-Specific (_DSM) pour prendre en charge la configuration spécifique à la classe de périphérique du sous-système USB. Pour plus d’informations, consultez Méthode Device-Specific USB.

Prise en charge du traducteur de transactions intégré (TT) USB (_HRV)

Les contrôleurs hôtes EHCI standard prennent en charge uniquement les périphériques USB à haut débit. Sur les plateformes SoC, Windows prend en charge deux conceptions courantes de contrôleurs hôtes conformes à EHCI qui implémentent un traducteur de transactions intégré pour les périphériques USB à faible vitesse et à vitesse maximale. L’objet Hardware Revision (_HRV) indique le type de prise en charge TT intégrée au pilote du contrôleur hôte USB.

Le _HRV est défini selon les critères suivants :

  • NoIntegratedTT - _HRV = 0

    Les contrôleurs hôtes EHCI standard n’implémentent pas de traducteurs de transactions intégrés, et une valeur _HRV de 0 n’est valide que pour ces contrôleurs. Il n’est pas nécessaire d’inclure l’objet _HRV pour ces contrôleurs.

  • IntegratedTTSpeedInPortSc - _HRV = 1

    Activez la prise en charge TT intégrée. Cette version de l’interface inclut les bits LowSpeed et HiSpeed dans le registre PORTSC lui-même. Ces bits sont aux décalages de bits 26 et 27, respectivement. Lors de la détermination de la vitesse, le pilote EHCI lit le PORTC et extrait les informations de vitesse à partir de ces bits.

  • IntegratedTTSpeedInHostPc - _HRV = 2

    Activez la prise en charge TT intégrée. Cette version de l’interface inclut les bits LowSpeed et HiSpeed dans un registre HOSTPC distinct. Lorsque le pilote EHCI doit déterminer la vitesse du port, il lit le registre HOSTPC correspondant au port d’intérêt et extrait les informations de vitesse.

Prise en charge d’USB XHCI D3cold

En plus de la suspension sélective, les périphériques USB internes connectés aux contrôleurs XHCI peuvent être placés dans un état D3cold et mis hors tension lorsqu’ils ne sont pas utilisés. Pour plus d’informations, consultez Gestion de l’alimentation des appareils. Tous les pilotes de fonction de périphérique USB doivent s’inscrire à D3cold.

Objets spécifiques au port USB

Windows doit connaître la visibilité et la capacité de connexion des ports USB sur le système. Cela est nécessaire pour fournir à l’utilisateur des informations précises sur les ports et les appareils. Deux objets, l’emplacement du périphérique physique (_PLD) et les fonctionnalités de port USB (_UPC), sont utilisés à cet effet. Pour plus d’informations, consultez les rubriques suivantes :

Contrôleurs et appareils hôtes SD

Les contrôleurs hôtes SD sont utilisés sur les plateformes SoC pour accéder au stockage et aux appareils d’E/S. Windows inclut un pilote de boîte de réception pour le matériel du contrôleur hôte standard SDA. Pour la compatibilité avec ce pilote, un appareil de contrôleur d’hôte SD doit être conforme à la spécification du contrôleur d’hôte SD de l’association SD.

Sur les plateformes SoC, le contrôleur hôte SD peut être énuméré par ACPI. Windows utilise les objets d’espace de noms ACPI suivants lors de l’énumération et de la configuration du matériel SD compatible :

  • ID matériel (_HID) conforme ACPI attribué par le fournisseur.

  • Objet ID unique (_UID), s’il existe plusieurs instance du contrôleur SD dans l’espace de noms (autrement dit, deux nœuds ou plus qui ont des objets d’identification d’appareil identiques).

  • ID compatible (_CID) pour le contrôleur d’hôte SD conforme aux normes SDA (PNP0D40).

  • Paramètres de ressource actuels (_CRS) attribués au contrôleur. Les ressources du contrôleur sont décrites comme suit :

    • Les ressources matérielles pour tous les emplacements implémentés sont incluses. Un emplacement est un point de connexion sur le bus SDIO pour un appareil de mémoire ou d’E/S. Chaque emplacement est associé à un ensemble standard de registres et à une interruption dans le contrôleur hôte SD, qui sont utilisés pour la communication avec l’appareil connecté. Les contrôleurs hôtes SD peuvent implémenter un nombre quelconque d’emplacements, mais sur les plateformes SoC, il n’y en a généralement qu’un seul.

    • Les ressources d’emplacement sont répertoriées ensemble, par ordre de numéro d’emplacement (les ressources de l’emplacement 0 sont les premières, les ressources de l’emplacement 1 sont deuxièmes, et ainsi de suite).

    • Pour chaque emplacement, les ressources sont répertoriées dans l’ordre suivant :

      • Adresse de base du jeu de registre standard SD pour l’emplacement.

      • Interruption standard SD pour l’emplacement.

      • Une ressource d’interruption GPIO pour l’emplacement, pour la signalisation carte insertions et suppressions (si l’interface SD standard carte-detect n’est pas prise en charge pendant tous les états d’alimentation).

      • Ressource d’entrée GPIO pour l’emplacement permettant de déterminer si un carte se trouve actuellement dans l’emplacement (si l’interface SD standard carte-detect n’est pas prise en charge pendant tous les états d’alimentation). Utilise la même broche que l’interruption d’insertion/suppression.

      • Deuxième ressource d’entrée GPIO permettant de déterminer si le carte dans l’emplacement est protégé en écriture (si l’interface de protection en écriture SD standard n’est pas prise en charge pendant tous les états d’alimentation).

Les interruptions doivent être compatibles avec la veille (décrites comme « SharedAndWake » ou « ExclusiveAndWake »).

Appareils SD incorporés

Les appareils connectés à SD sont énumérés par le pilote de bus SD. Les appareils SD intégrés à la plateforme doivent également être répertoriés dans l’espace de noms ACPI en tant qu’enfants du contrôleur hôte SD. Cette exigence permet au système d’exploitation d’associer l’appareil énuméré par le bus aux attributs spécifiques à la plateforme fournis pour l’appareil par les objets ACPI (par exemple, la non-suppression, les états d’alimentation de l’appareil, les ressources GPIO ou SPB consommées, etc.). Pour établir cette association, l’espace de noms d’appareil nécessite l’objet Address (_ADR), qui communique l’adresse de l’appareil sur le bus SDIO. L’objet _ADR retourne un entier.

Pour le bus SDIO, la valeur de cet entier est définie comme suit :

  • Mot élevé – Numéro d’emplacement (0 – premier emplacement)

  • Mot faible : numéro de fonction (voir spécification SD pour les définitions.)

Un espace de noms d’appareil SD incorporé doit également inclure :

  • Objet de méthode Remove (_RMV) qui retourne 0 (pour indiquer que l’appareil ne peut pas être supprimé).

  • Un objet _CRS pour les ressources de bande latérale requises par l’appareil (telles que des broches GPIO ou des connexions SPB), le cas échéant.

Appareils de classe d’imagerie (caméras)

Les appareils photo peuvent être énumérés par le pilote graphique ou par USB. Dans les deux cas, Windows doit connaître l’emplacement physique de la caméra afin que l’interface utilisateur appropriée puisse être affichée. Pour ce faire, les appareils photo intégrés au châssis du système et dont la direction est mécaniquement fixe sont inclus dans l’espace de noms ACPI et fournissent l’objet Emplacement de l’appareil physique (_PLD). Cela implique les opérations suivantes :

  • Appareil photo devant apparaître en tant qu’enfant (appareil imbriqué) de l’appareil énumérateur (le périphérique GPU ou le périphérique USB).

  • Appareil photo permettant de fournir l’objet Address (_ADR) qui contient l’adresse de la caméra sur le bus de l’appareil parent.

    • Pour l’USB, consultez Hiérarchie et _ADR d’espaces de noms ACPI pour les périphériques USB incorporés dans la section suivante ci-dessous.

    • Pour les graphiques, il s’agit de l’identificateur spécifié dans la méthode _DOD fournie sous le périphérique GPU. Pour plus d’informations, consultez l’Annexe B, « Extensions vidéo », de la spécification ACPI 5.0.

  • Appareil photo pour fournir l’objet _PLD.

  • S’il existe des ressources de bande latérale requises par le pilote de caméra (telles que des connexions d’interruption GPIO ou d’E/S, ou une connexion SPB), l’objet _CRS est fourni pour ces ressources.

Dans l’objet _PLD, le champ Panneau (bits 67-69), le champ Lid (bit 66) et le champ Dock (bit 65) sont définis pour corriger les valeurs de la surface sur laquelle la caméra est montée. Tous les autres champs sont facultatifs. Pour les appareils mobiles portables, y compris les tablettes, le panneau avant est celui qui contient l’écran d’affichage, et son origine se trouve dans le coin inférieur gauche lorsque l’affichage est affiché dans l’orientation portrait. À l’aide de cette référence, « Avant » indique que la caméra affiche l’utilisateur (webcam), tandis que « Retour » indique que la caméra est loin de l’utilisateur (caméra fixe ou vidéo). Pour plus d’informations, consultez la section 6.1.8, « _PLD (emplacement physique de l’appareil) », dans la spécification ACPI 5.0.

Hiérarchie et _ADR d’espaces de noms ACPI pour les périphériques USB incorporés

Lors de l’ajout de périphériques USB incorporés à l’espace de noms ACPI, la hiérarchie des nœuds d’appareil doit correspondre exactement à celle des appareils énumérés par le pilote USB Windows. Cela peut être déterminé en examinant windows Gestionnaire de périphériques dans son mode « Affichage par connexion ». L’ensemble de la hiérarchie, à partir du contrôleur hôte USB et s’étendant jusqu’au périphérique incorporé, doit être inclus. La propriété « Address » fournie dans Gestionnaire de périphériques pour chaque appareil est l’adresse que le microprogramme doit signaler dans le _ADR de l’appareil.

La spécification ACPI 5.0 définit les adresses des périphériques USB comme suit :

HUB racine USB : enfant uniquement du contrôleur hôte. Il doit avoir une _ADR de 0. Aucun autre enfant ou valeur de _ADR n’est autorisé.

Ports USB : numéro de port (1-n)

Les périphériques USB connectés à un port particulier partagent l’adresse de ce port.

Si l’appareil connecté à un port est un périphérique USB composite, les fonctions au sein de l’appareil composite doivent utiliser l’adresse suivante :

Fonction USB dans un périphérique USB composite : numéro de port du port auquel le périphérique composite est connecté, PLUS le numéro d’interface de la fonction. (Ajout arithmétique).

Pour plus d’informations, consultez Identification de l’emplacement des caméras internes.

Exemples de code ASL

L’exemple de code ASL suivant décrit une webcam USB connectée directement au port USB 3.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {         // the Root HUB
     Name (_ADR, ZERO)      // Address is always 0.
     Device (CAM0) {          // Camera connected directly to USB
                       //   port number 3 under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
    } // End of Root Hub Device
}  // End of EHCI device

L’exemple de code ASL suivant décrit un périphérique composite USB qui implémente une webcam en tant que fonction 2.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {
     Name (_ADR, ZERO)
     Device (CUSB) {        // Composite USB device
                    //   connected to USB port number 3
                    //   under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Device (CAM0) { // Camera function within the
                    //   Composite USB device.
                Name (_ADR, 5)  // Camera function has a first
                    //   Interface number of 2, so
                    //   Address is 3 + 2  = 5.
                Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
        } // End of Composite USB Device
    } // End of Root Hub Device
}  // End of EHCI device

L’exemple de code ASL suivant décrit une webcam connectée via I2C.

Device (GPU0) {
    ... // Other objects required for graphics devices
    Name (_DOD, Package ()  // Identifies the children of this graphics device.
                // Each integer must be unique within the GPU0 namespace.
                {
                    0x00024321,  // The ID for CAM0. It is a non-VGA
                    //   device, cannot be detected by
                    //   the VGA BIOS, and uses a vendor-
                    //   specific ID format in bits 15:0
                    //   (see the _DOD specification).
                    ...     // Other child device IDs (for
                    //   example, display output ports)
                })
    Device (CAM0) {
        Name (_ADR, 0x00024321) // The identifier for this device
                    //   (Same as in _DOD above)
        Name (_CRS, ResourceTemplate()
            {
            // I2C Resource
            // GPIO interrupt resource(s), if required by
            //   driver
            // GPIO I/O resource(s), if required by driver
                ...
            })
        Method (_PLD, 0, Serialized) {...}
    } // End of CAM0 device
} // End of GPU0 device

Appareils HID-over-I2C

Windows inclut un pilote de classe pour les périphériques d’interface humaine (HID). Ce pilote permet la prise en charge générique d’un large éventail de périphériques d’entrée (tels que les panneaux tactiles, les claviers, les souris et les capteurs). Sur les plateformes SoC, les appareils HID peuvent être connectés à la plateforme via I2C et sont énumérés par ACPI. Pour la compatibilité avec la prise en charge de la classe HID dans Windows, les objets d’espace de noms suivants sont utilisés :

  • Un _HID propre au fournisseur

  • Une _CID de PNP0C50

  • Un _CRS avec :

    • Une ressource I2CSerialBusConnection pour l’accès à l’appareil

    • Une ressource GpioInt pour les interruptions

  • La méthode HIDI2C _DSM pour renvoyer l’adresse hid Descriptor Register dans l’appareil. Pour plus d’informations, consultez Méthode Device-Specific HIDI2C (_DSM).

Périphériques de bouton

Pour les plateformes SoC, Windows prend en charge à la fois le bouton d’alimentation de la méthode de contrôle défini par ACPI, ainsi qu’un tableau à cinq boutons compatible avec Windows. Le bouton d’alimentation, qu’il soit implémenté en tant que bouton d’alimentation de la méthode de contrôle ACPI ou dans le cadre du tableau de boutons compatible windows, effectue les opérations suivantes :

  • Provoque la mise sous tension de la plateforme si elle est désactivée.

  • Génère l’événement Power Button Override lorsqu’il est arrêté. Pour plus d’informations, consultez la section 4.8.2.2.1.3, « Remplacement du bouton d’alimentation », de la spécification ACPI 5.0.

Bouton d’alimentation de la méthode de contrôle

Les conceptions clamshell et d’autres systèmes avec claviers intégrés ou connectés implémentent le bouton d’alimentation de la méthode de contrôle défini par ACPI (section 4.8.2.2.1.2 de la spécification ACPI 5.0) à l’aide de GPIO-Signaled événements ACPI (section 5.6.5 de la spécification ACPI 5.0). Pour prendre en charge le périphérique power button, l’espace de noms :

  • Décrit le code d’interruption GPIO du bouton d’alimentation en tant que ressource d’interruption GPIO non partagée (exclusive).

  • Répertorie la ressource d’interruption GPIO du bouton d’alimentation dans l’objet _AEI du contrôleur GPIO auquel elle est connectée.

  • Fournit la méthode d’événement associée (Lxx/Exx/EVT) sous le périphérique du contrôleur GPIO. Cette méthode d’événement avertit le pilote Control Method Button dans le système d’exploitation que l’événement de bouton s’est produit.

Pour plus d’informations, consultez Boutons matériels pour Windows 8 tablette et les appareils convertibles.

Tableau de boutons compatible windows

Pour les plateformes tactiles (sans clavier), telles que les ardoises, Windows fournit un pilote générique pour un tableau de cinq boutons. Chaque bouton du tableau a sa fonction définie (voir les éléments numérotés dans la liste ci-dessous), et certaines combinaisons de boutons « maintenez et appuyez » ont une signification supplémentaire dans l’interface utilisateur. Aucune combinaison de boutons n’est définie qui nécessite que le bouton d’alimentation soit maintenu enfoncé. Pour la compatibilité avec le pilote de bouton de boîte de réception Windows, l’appareil ACPI du tableau de boutons compatible Windows est implémenté. L’appareil est défini comme suit :

  • Chacun des cinq boutons est connecté à sa propre broche d’interruption dédiée sur la plateforme.

  • Chaque broche d’interruption est configurée en tant que ressource d’interruption non partagée (Exclusive), déclenchée par edge (Edge) qui interrompt les deux arêtes (ActiveBoth).

  • L’espace de noms de l’appareil contient un _HID défini par le fournisseur ainsi qu’un _CID de PNP0C40.

  • Les ressources d’interruption GPIO dans l’objet _CRS sont répertoriées dans l’ordre suivant :

    1. Interruption correspondant au bouton « Marche / Arrêt »

      Le bouton « Alimentation » doit être compatible avec la veille (ExclusiveAndWake).

    2. Interruption correspondant au bouton « Windows »

      Le bouton Windows doit être compatible avec la veille (ExclusiveAndWake).

    3. Interruption correspondant au bouton « Augmenter le volume »

      Le bouton « Augmenter le volume » ne doit pas être compatible avec la veille (doit utiliser Exclusive).

    4. Interruption correspondant au bouton « Volume down »

      Le bouton « Réduire le volume » ne doit pas être compatible avec la veille (doit utiliser Exclusive).

    5. Interruption correspondant au bouton « Verrou de rotation », si pris en charge

      Le bouton « Verrou de rotation » ne doit pas être compatible avec la veille (doit utiliser Exclusive).

Pour plus d’informations, consultez Boutons matériels pour Windows 8 tablette et les appareils convertibles.

Pour prendre en charge l’évolution de l’interface utilisateur du bouton Windows, Windows définit une méthode Device-Specific (_DSM) pour l’appareil Windows Button Array. Pour plus d’informations, consultez Windows Button Array Device-Specific Method (_DSM).

Appareils de détection de PC convertibles et d’ancrage

Windows prend en charge les docks et les convertibles (combinaisons clapet/tablette) en utilisant deux appareils de détection dans l’espace de noms ACPI. Ces appareils sont pris en charge par le pilote de bouton boîte de réception Windows. Notez que les mêmes exigences que celles qui s’appliquent à l’appareil Button Array s’appliquent également à ces appareils :

  • Les interruptions ActiveBoth GPIO doivent être connectées à un contrôleur GPIO sur SoC (et non à un contrôleur GPIO connecté à SPB).

  • Le contrôleur GPIO doit prendre en charge les interruptions en mode de niveau et la reprogrammation de polarité dynamique.

  • Le pilote de contrôleur GPIO doit utiliser l’émulation ActiveBoth fournie par l’extension d’infrastructure GPIO (GpioClx).

  • Si l’état affirmé (« Ancré » ou « Converti ») n’est pas au niveau logique affirmé bas, le contrôleur GPIO _DSM méthode est nécessaire pour remplacer le comportement par défaut de la pile de pilotes GPIO. Pour plus d’informations, consultez la section Appareils de contrôleur GPIO dans la rubrique E/S à usage général (GPIO).

Pour plus d’informations, consultez Boutons matériels pour Windows 8 tablette et les appareils convertibles.

Dispositif de détection de station d’accueil

Un dispositif de détection de station d’accueil interrompt le système lorsqu’une station d’accueil est attachée ou non attachée au système. Ces informations de modification de mode sont utilisées pour mettre à jour l’expérience d’entrée et de sortie de l’utilisateur, selon les besoins. L’espace de noms de l’appareil nécessite :

  • Un _HID propre au fournisseur

  • Une _CID de PNP0C70

  • Une _CRS avec une interruption ActiveBoth

    L’interruption ne peut pas être compatible avec la veille.

Dispositif de détection pc convertible

Un appareil de détection de PC convertible interrompt le système lorsqu’un PC convertible passe d’une tablette à un facteur de forme à clapet. Ces informations de modification de mode sont utilisées pour mettre à jour l’expérience d’entrée et de sortie de l’utilisateur, selon les besoins. L’espace de noms de l’appareil nécessite :

  • Un _HID propre au fournisseur

  • Une _CID de PNP0C60

  • Une _CRS avec une interruption ActiveBoth

    L’interruption ne peut pas être compatible avec la veille.