Autres objets d’espace de noms ACPI

Pour certaines classes d'appareils spécifiques, il y a des exigences pour que des objets supplémentaires d'espace de noms ACPI (Advanced Configuration and Power Interface) apparaissent sous ces appareils dans la hiérarchie de l'espace de noms. Cette section répertorie les objets supplémentaires requis pour les plateformes 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 « Device », comme avec d’autres appareils sur la plateforme. Les appareils 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.

Configurations requises de l’objet Display-Specific

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 conformes aux spécifications EHCI ou XHCI.

Sur les plateformes 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 :

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

• Objet ID unique (_UID), s’il existe plusieurs instances du contrôleur USB 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 hôte USB compatible EHCI ou XHCI Standard (EHCI : PNP0D20), (XHCI : PNP0D10).

• Paramètres de ressource actuels (_CRS) affecté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 spécifique au périphérique USB (_DSM)

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

Support du traducteur de transactions intégré USB (TT) (_HRV)

Les contrôleurs hôtes EHCI standard prennent uniquement en charge les périphériques USB haute vitesse. Sur les plateformes SoC, Windows prend en charge deux conceptions courantes de contrôleurs hôtes compatibles EHCI qui implémentent un traducteur de transaction intégré pour les périphériques USB à faible vitesse et à vitesse totale. L'objet Hardware Revision (_HRV) indique le type de support technique TT intégré au pilote du contrôleur hôte USB.

Le _HRV est défini en fonction des 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 de _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 positions de décalage 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 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 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 désactivés lorsqu’ils ne sont pas utilisés. Pour plus d’informations, consultez Gestion de l’alimentation des appareils. Tous les pilotes de fonctions des périphériques USB doivent opter pour 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 des informations précises à l’utilisateur sur les ports et les appareils. Deux objets, l’emplacement des appareils physiques (_PLD) et les fonctionnalités de port USB (_UPC), sont utilisés à cet effet. Pour plus d’informations, consultez les rubriques suivantes :

• Sections 6.1.6, « Objets d’identification des appareils » et 9.13.1, « Contrôleurs hôtes USB 2.0 et _UPC et _PLD », dans la spécification ACPI 5.0.

• Utilisation d’ACPI pour configurer des ports USB sur un ordinateur.

Contrôleurs hôtes SD et dispositifs SD

Les contrôleurs hôtes SD sont utilisés sur les plateformes SoC pour accéder au stockage ainsi qu’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 contrôleur hôte SD doit se conformer à la spécification du contrôleur 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 compatible ACPI attribué par le fournisseur (_HID).

• Objet ID unique (_UID), s’il existe plusieurs instances 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 hôte SD conforme aux normes SDA (PNP0D40).

• Paramètres de ressource actuels (_CRS) affecté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 une mémoire ou un appareil 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 n’importe quel nombre 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, dans l’ordre du numéro d’emplacement (les ressources de l’emplacement 0 sont d’abord, les ressources de l’emplacement 1 sont deuxièmes, etc.).

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

    • Adresse de base du registre standard SD défini pour l’emplacement.

    • L'interruption standard SD pour le slot.

    • Ressource d’interruption GPIO pour l’emplacement, destinée aux insertions et retraits de cartes (si l’interface de détection de carte SD standard n’est pas prise en charge pendant tous les états d’alimentation).

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

    • Une deuxième ressource d'entrée GPIO permettant de vérifier si la carte présente dans l'emplacement est protégée en écriture (si l'interface standard de protection en écriture SD n'est pas prise en charge durant tous les états de puissance).

Les interruptions doivent être compatibles avec le réveil (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 bus aux attributs spécifiques à la plateforme fournis pour l’appareil par des objets ACPI (par exemple, non-suppression, états d’alimentation des appareils, ressources GPIO ou SPB consommées, etc.). Pour créer cette association, l’espace de noms de l’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 Remove (_RMV) qui retourne 0 (pour indiquer que l’appareil ne peut pas être supprimé).

• Objet _CRS pour les ressources de bande latérale requises par l’appareil (par exemple, les broches GPIO ou les 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 qui ont une direction mécaniquement fixe sont inclus dans l’espace de noms ACPI et fournissent l’objet Physical Device Location (_PLD). Cela nécessite les éléments suivants :

• L'appareil photo doit apparaître en tant qu'élément enfant (appareil imbriqué) de l'appareil énumérateur (soit le périphérique GPU, soit le périphérique USB).

• L'appareil photo doit fournir l'objet Address (_ADR) qui contient l'adresse de la caméra sur le bus de l'appareil parent.

  • Pour USB, consultez la hiérarchie d’espaces de noms ACPI et _ADR 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 l’appareil 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 auxiliaires requises par le pilote de caméra (comme les interruptions GPIO ou les connexions d'E/S, ou une connexion SPB), l'objet _CRS est fourni pour ces ressources.

Dans l’objet _PLD, le champ Panel (bits 67-69), le champ de couvercle (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 tient 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, « Front » indique que la caméra filme l’utilisateur (webcam), tandis que « Back » indique que la caméra est orientée vers l’extérieur de l’utilisateur (appareil photo ou caméra 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 d’espaces de noms ACPI et _ADR pour les périphériques USB incorporés

Lors de l’ajout d’appareils 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 le Gestionnaire de périphériques Windows en mode « Affichage par connexion ». La hiérarchie entière, à partir du contrôleur hôte USB jusqu'à l'appareil embarqué, doit être incluse. La propriété « Address » fournie dans Device Manager 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 : seul élément du contrôleur hôte. Elle 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 l’appareil composite est connecté, PLUS le premier numéro d’interface de la fonction. (addition 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 appareils d’interface humaine (HID). Ce pilote permet la prise en charge générique d’un large éventail d’appareils 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 sur 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 spécifique au fournisseur

• Un _CID de PNP0C50

• Un _CRS avec :

  • Ressource I2CSerialBusConnection pour l’accès à l’appareil

  • Ressource GpioInt pour les interruptions

• La méthode _DSM HIDI2C pour retourner l’adresse de registre du descripteur HID dans l’appareil. Pour plus d’informations, consultez la méthode Device-Specific HIDI2C (_DSM).

Appareils à boutons

Pour les plateformes SoC, Windows prend en charge le Control Method Power Button défini par l’ACPI, ainsi qu’un ensemble de cinq boutons compatible 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 l'allumage de la plateforme si elle est éteinte.

• Génère l’événement Power Button Override en cas de suspension. 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.

Méthode de contrôle du bouton d'alimentation

Les designs à clapet et d'autres systèmes avec claviers intégrés ou connectés implémentent le bouton d'alimentation de méthode de contrôle défini par l'ACPI (section 4.8.2.2.1.2 de la spécification ACPI 5.0) en utilisant les événements ACPI GPIO-Signaled (section 5.6.5 de la spécification ACPI 5.0). Pour prendre en charge le dispositif du bouton d’alimentation, utilisez l'espace de noms :

• Décrit la broche 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 il est connecté.

• Fournit la méthode d’événement associée (Lxx/Exx/EVT) sous le dispositif 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 Button s’est produit.

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

Tableau de boutons compatible avec Windows

Pour les plateformes tactiles (sans clavier), telles que les tablettes, Windows fournit un pilote générique pour un ensemble 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 « hold-and-press » ont une signification supplémentaire dans l’interface utilisateur. Aucune combinaison de boutons n’est définie pour exiger que le bouton d’alimentation soit enfoncé. Pour la compatibilité avec le pilote du bouton boîte de réception Windows, l’appareil ACPI de 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 la périphérie (Edge) qui interrompt les deux bords (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 « Alimentation »

     Le bouton « Power » doit être compatible avec le réveil (ExclusiveAndWake).

  2. Interruption correspondant au bouton « Windows »

     Le bouton Windows doit être compatible avec le réveil (ExclusiveAndWake).

  3. Interruption correspondant au bouton « Monter le volume »

     Le bouton « Volume vers le haut » ne doit pas être compatible avec le réveil (doit utiliser Exclusif).

  4. Interruption correspondant au bouton « Volume bas »

     Le bouton « Volume Down » ne doit pas être compatible avec le réveil (doit utiliser Exclusif).

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

     Le bouton « Verrouillage de rotation » ne doit pas être compatible avec le réveil (doit utiliser Exclusif).

Pour plus d’informations, consultez boutons matériels pour les tablettes Windows 8 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).

Station d'accueil et capteurs de PC convertibles

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

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

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

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

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

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

Appareil de détection d’ancrage

Un dispositif de détection de station d'accueil interrompt le système lorsqu'un dock est attaché ou retiré du 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 les éléments suivants :

• Un _HID spécifique au fournisseur

• Un _CID de PNP0C70

• Un _CRS avec une interruption ActiveBoth

  L’interruption ne peut pas être compatible avec le réveil.

Appareil de détection de PC convertible

Un dispositif de détection pour PC convertible interrompt le système lorsqu'un PC convertible passe du mode tablette au mode ordinateur portable. 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 les éléments suivants :

• Un _HID spécifique au fournisseur

• Un _CID de PNP0C60

• Un _CRS avec une interruption de type ActiveBoth

  L’interruption ne peut pas être compatible avec le réveil.