Compartir a través de


Otros objetos de espacio de nombres ACPI

Para algunas clases específicas de dispositivo, hay requisitos para que otros objetos de espacio de nombres de Advanced Configuration y Power Interface (ACPI) aparezcan en esos dispositivos del espacio de nombres. En esta sección se enumeran los objetos adicionales necesarios para las plataformas basadas en SoC.

Objetos de identificación del procesador

Los procesadores deben enumerarse en el espacio de nombres ACPI. Los procesadores se declaran en \_SB mediante la instrucción "Device", como con otros dispositivos de la plataforma. Los dispositivos de procesador deben contener los siguientes objetos:

  • _HID: ACPI0007
  • _UID: número único que coincide con la entrada del procesador en MADT.

Mostrar objetos específicos

Para obtener más información sobre los objetos específicos de la pantalla, vea el Apéndice B, "Extensiones de vídeo", de la especificación ACPI 5.0.

requisitos de objetos de Display-Specific

Método Descripción Requisito
_DOS Habilite o deshabilite la conmutación de salida. Obligatorio si el sistema admite el cambio de pantalla o los niveles de brillo LCD.
_DOD Enumerar todos los dispositivos conectados al adaptador de pantalla. Obligatorio si el controlador integrado admite el cambio de salida.
_ROM Obtener datos de ROM. Obligatorio si la imagen rom se almacena en formato propietario.
_GPD Obtener dispositivo POST. Obligatorio si se implementa _VPO.
_SPD Establezca DISPOSITIVO POST. Obligatorio si se implementa _VPO.
_VPO Opciones post de vídeo. Obligatorio si el sistema admite el cambio de dispositivo VGA posterior.
_ADR Devuelve el identificador único de este dispositivo. Necesario.
_BCL Lista de consultas de los niveles de control de brillo admitidos. Obligatorio si la PANTALLA LCD incrustada admite el control de brillo.
_BCM Establezca el nivel de brillo. Obligatorio si se implementa _BCL.
_DDC Devuelve el EDID de este dispositivo. Obligatorio si la PANTALLA LCD incrustada no admite la devolución de EDID a través de la interfaz estándar.
_DCS Devuelve el estado del dispositivo de salida. Obligatorio si el sistema admite el cambio de pantalla (a través de la tecla de acceso rápido).
_DGS Consulta del estado de gráficos. Obligatorio si el sistema admite el cambio de pantalla (a través de la tecla de acceso rápido).
_DSS Conjunto de estado del dispositivo. Obligatorio si el sistema admite el cambio de pantalla (a través de la tecla de acceso rápido).

Dispositivos y controladores de host USB

Los controladores de host USB se usan en plataformas SoC para conectar dispositivos internos y externos. Windows incluye controladores de bandeja de entrada para controladores de host USB estándar que son compatibles con las especificaciones EHCI o XHCI.

En las plataformas basadas en SoC, acpI puede enumerar el controlador de host USB. Windows usa los siguientes objetos de espacio de nombres ACPI al enumerar y configurar hardware USB compatible:

  • Identificador de hardware compatible con ACPI asignado por el proveedor (_HID).

  • Objeto Id. único (_UID), si hay más de una instancia del controlador USB en el espacio de nombres (es decir, dos o más nodos que tienen objetos de identificación de dispositivo idénticos).

  • Un identificador compatible (_CID) para el controlador de host USB compatible con EHCI o XHCI (EHCI: PNP0D20), (XHCI: PNP0D10).

  • Configuración de recursos actuales (_CRS) asignada al controlador USB. Los recursos del controlador se describen en la especificación de interfaz de hardware adecuada (EHCI o XHCI).

Método Device-Specific USB (_DSM)

Windows define un método Device-Specific (_DSM) para admitir la configuración específica de la clase del dispositivo del subsistema USB. Para obtener más información, vea USB Device-Specific Method.

Compatibilidad con el traductor de transacciones integrado (TT) USB (_HRV)

Los controladores de host EHCI estándar solo admiten dispositivos USB de alta velocidad. En las plataformas SoC, Windows admite dos diseños comunes de controladores de host compatibles con EHCI que implementan un traductor de transacciones integrado para dispositivos USB de baja velocidad y de velocidad completa. El objeto Revisión de hardware (_HRV) indica el tipo de compatibilidad integrada de TT con el controlador del controlador de host USB.

El _HRV se establece según los criterios siguientes:

  • NoIntegratedTT - _HRV = 0

    Los controladores de host EHCI estándar no implementan traductores de transacciones integrados y un valor de _HRV de 0 solo es válido para estos controladores. No es necesario incluir el objeto _HRV para estos controladores.

  • IntegratedTTSpeedInPortSc - _HRV = 1

    Habilite la compatibilidad integrada con TT. Este tipo de interfaz incluye los bits LowSpeed y HiSpeed en el propio registro PORTSC. Estos bits están en desplazamientos de bits 26 y 27, respectivamente. Al determinar la velocidad, el controlador EHCI leerá portsc y extraerá la información de velocidad de estos bits.

  • IntegratedTTSpeedInHostPc - _HRV = 2

    Habilite la compatibilidad integrada con TT. Este tipo de interfaz incluye los bits LowSpeed y HiSpeed en un registro HOSTPC independiente. Cuando el controlador EHCI necesita determinar la velocidad del puerto, leerá el registro HOSTPC correspondiente al puerto de interés y extraerá la información de velocidad.

Compatibilidad con USB XHCI D3cold

Además de la suspensión selectiva, los dispositivos USB internos conectados a los controladores XHCI se pueden colocar en un estado D3cold y apagarse cuando no están en uso. Para obtener más información, consulte Administración de energía de dispositivos. Todos los controladores de funciones del dispositivo USB deben participar en D3cold.

Objetos específicos del puerto USB

Windows debe conocer la visibilidad y la capacidad de conexión de los puertos USB en el sistema. Esto es necesario para proporcionar información precisa al usuario sobre los puertos y dispositivos. Dos objetos, Ubicación de dispositivo físico (_PLD) y Funcionalidades de puerto USB (_UPC), se usan para este propósito. Para obtener más información, vea lo siguiente:

Dispositivos y controladores de host SD

Los controladores de host SD se usan en plataformas SoC para el acceso al almacenamiento, así como a los dispositivos de E/S. Windows incluye un controlador de bandeja de entrada para hardware de controlador de host estándar de SDA. Para la compatibilidad con este controlador, un dispositivo de controlador de host SD debe cumplir con la especificación del controlador de host SD de la asociación SD.

En las plataformas SoC, el controlador de host SD se puede enumerar mediante ACPI. Windows usa los siguientes objetos de espacio de nombres ACPI al enumerar y configurar hardware SD compatible:

  • Identificador de hardware compatible con ACPI asignado por el proveedor (_HID).

  • Objeto Id. único (_UID), si hay más de una instancia del controlador SD en el espacio de nombres (es decir, dos o más nodos que tienen objetos de identificación de dispositivo idénticos).

  • Un identificador compatible (_CID) para el controlador de host SD compatible con el estándar SDA (PNP0D40).

  • Configuración de recursos actual (_CRS) asignada al controlador. Los recursos del controlador se describen de la siguiente manera:

    • Se incluyen recursos de hardware para todas las ranuras implementadas. Una ranura es un punto de conexión en el bus SDIO para una memoria o dispositivo de E/S. Cada ranura está asociada a un conjunto estándar de registros y una interrupción en el controlador de host SD, que se usan para la comunicación con el dispositivo conectado. Los controladores de host SD pueden implementar cualquier número de ranuras, pero en las plataformas SoC, normalmente solo hay uno.

    • Los recursos de ranura se enumeran juntos, en orden de número de ranura (los recursos de la ranura 0 son primero, los recursos de la ranura 1 son segundos, etc.).

    • Para cada ranura, los recursos se muestran en el orden siguiente:

      • Dirección base del conjunto de registros estándar sd para la ranura.

      • Interrupción estándar sd para la ranura.

      • Un recurso de interrupción GPIO para la ranura, para las inserciones y eliminaciones de tarjetas de señalización (si la interfaz estándar de detección de tarjetas SD no se admite durante todos los estados de energía).

      • Un recurso de entrada GPIO para la ranura para leer si una tarjeta está actualmente en la ranura (si la interfaz estándar de detección de tarjeta SD no se admite durante todos los estados de energía). Usa el mismo pin que la interrupción de inserción o eliminación.

      • Segundo recurso de entrada GPIO para leer si la tarjeta de la ranura está protegida por escritura (si la interfaz estándar sd write-protect no se admite durante todos los estados de energía).

Las interrupciones deben ser compatibles con reactivación (descritas como "SharedAndWake" o "ExclusiveAndWake").

Dispositivos SD insertados

Los dispositivos conectados a SD se enumeran mediante el controlador de bus SD. Los dispositivos SD que están integrados en la plataforma también deben aparecer en el espacio de nombres ACPI como elementos secundarios del controlador de host SD. Este requisito permite al sistema operativo asociar el dispositivo enumerado por bus con los atributos específicos de la plataforma proporcionados para el dispositivo por objetos ACPI (por ejemplo, no removibilidad, estados de alimentación del dispositivo, GPIO o SPB recursos consumidos, etc.). Para realizar esta asociación, el espacio de nombres del dispositivo requiere el objeto Address (_ADR), que comunica la dirección del dispositivo en el bus SDIO. El objeto _ADR devuelve un entero.

Para el bus SDIO, el valor de este entero se define de la siguiente manera:

  • Palabra alta: número de ranura (0 – primera ranura)

  • Palabra baja: número de función (consulte la especificación SD para las definiciones).

Un espacio de nombres de dispositivo SD insertado también debe incluir:

  • Objeto Remove (_RMV) que devuelve 0 (para indicar que no se puede quitar el dispositivo).

  • Un objeto _CRS para los recursos de banda lateral que requiere el dispositivo (como patillas GPIO o conexiones SPB), si es necesario.

Dispositivos de clase de creación de imágenes (cámaras)

Los dispositivos de cámara pueden enumerarse mediante el controlador gráfico o usb. En cualquier caso, Windows debe conocer la ubicación física de la cámara para que se pueda mostrar la interfaz de usuario adecuada. Para ello, los dispositivos de cámara que están integrados en el chasis del sistema y tienen una dirección mecánicamente fija se incluyen en el espacio de nombres ACPI y proporcionan el objeto Ubicación del dispositivo físico (_PLD). Esto requiere lo siguiente:

  • El dispositivo de cámara que se va a mostrar como un elemento secundario (dispositivo anidado) del dispositivo enumerador (ya sea el dispositivo gpu o el dispositivo USB).

  • Dispositivo de cámara para proporcionar el objeto Address (_ADR) que contiene la dirección de la cámara en el bus del dispositivo primario.

    • Para USB, consulte jerarquía de espacios de nombres ACPI y _ADR para dispositivos USB insertados en la sección siguiente.

    • En el caso de los gráficos, este es el identificador especificado en el método _DOD proporcionado en el dispositivo gpu. Para obtener más información, vea el Apéndice B, "Extensiones de vídeo", de la especificación ACPI 5.0.

  • Dispositivo de cámara para proporcionar el objeto _PLD.

  • Si hay algún recurso de banda lateral requerido por el controlador de cámara (como las conexiones de interrupción o E/S de GPIO o una conexión SPB), se proporciona el objeto _CRS para estos recursos.

En el objeto _PLD, el campo Panel (bits 67-69), el campo Lid (bit 66) y el campo Dock (bit 65) se establecen en valores correctos para la superficie en la que se monta la cámara. Todos los demás campos son opcionales. En el caso de los dispositivos móviles portátiles, incluidas las tabletas, el panel frontal es el que mantiene la pantalla de visualización y su origen está en la esquina inferior izquierda cuando la pantalla se ve en la orientación vertical. Con esta referencia, "Front" indica que la cámara ve al usuario (cámara web), mientras que "Atrás" indica que las vistas de la cámara lejos del usuario (todavía o cámara de vídeo). Para obtener más información, consulte la sección 6.1.8, "_PLD (ubicación física del dispositivo)", en la especificación ACPI 5.0.

Jerarquía de espacios de nombres ACPI y _ADR para dispositivos USB insertados

Al agregar dispositivos USB insertados al espacio de nombres ACPI, la jerarquía de los nodos de dispositivo debe coincidir exactamente con la de los dispositivos enumerados por el controlador USB de Windows. Esto se puede determinar examinando Windows Administrador de dispositivos en su modo "Ver por conexión". Se debe incluir toda la jerarquía, empezando por el controlador de host USB y extendiéndose hacia abajo hasta el dispositivo incrustado. La propiedad "Address" proporcionada en Administrador de dispositivos para cada dispositivo es la dirección que el firmware debe notificar en el _ADR del dispositivo.

La especificación ACPI 5.0 define las direcciones de los dispositivos USB de la siguiente manera:

CONCENTRADOR raíz USB: solo elemento secundario del controlador de host. Debe tener un _ADR de 0. No se permiten otros elementos secundarios o valores de _ADR.

Puertos USB: número de puerto (1-n)

Los dispositivos USB conectados a un puerto determinado comparten la dirección de ese puerto.

Si el dispositivo conectado a un puerto es un dispositivo USB compuesto, las funciones del dispositivo compuesto deben usar la siguiente dirección:

Función USB dentro de un dispositivo USB compuesto: número de puerto del puerto al que está conectado el dispositivo compuesto, MÁS el primer número de interfaz de la función. (Suma aritmética).

Para obtener más información, consulte Identificación de la ubicación de las cámaras internas.

Ejemplos de código de ASL

En el siguiente ejemplo de código ASL se describe una cámara web USB que está conectada directamente al puerto 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

En el siguiente ejemplo de código ASL se describe un dispositivo compuesto USB que implementa una cámara web como función 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

En el siguiente ejemplo de código ASL se describe una cámara web conectada a través de 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

Dispositivos HID a través de I2C

Windows incluye un controlador de clase para dispositivos de interfaz humana (HID). Este controlador permite la compatibilidad genérica con una amplia gama de dispositivos de entrada (como paneles táctiles, teclados, ratones y sensores). En las plataformas SoC, los dispositivos HID se pueden conectar a la plataforma a través de I2C y son enumerados por ACPI. Para la compatibilidad con la compatibilidad con la clase HID en Windows, se usan los siguientes objetos de espacio de nombres:

  • Un _HID específico del proveedor

  • Una _CID de PNP0C50

  • Un _CRS con:

    • Un recurso I2CSerialBusConnection para acceder al dispositivo

    • Un recurso GpioInt para interrupciones

  • El método HIDI2C _DSM para devolver la dirección de registro del descriptor HID en el dispositivo. Para obtener más información, vea HIDI2C Device-Specific Method (_DSM)).

Dispositivos de botón

En el caso de las plataformas SoC, Windows admite el botón de encendido del método de control definido por ACPI, así como una matriz de cinco botones compatible con Windows. El botón de encendido, ya sea implementado como un botón de encendido del método de control ACPI o como parte de la matriz de botones compatible con Windows, hace lo siguiente:

  • Hace que la plataforma se apague si está apagada.

  • Genera el evento De invalidación del botón de encendido cuando se mantiene presionado. Para obtener más información, vea la sección 4.8.2.2.1.3, "Power Button Override", de la especificación ACPI 5.0.

Botón de encendido del método de control

Los diseños de Clamshell y otros sistemas con teclados integrados o conectados implementan el botón de encendido del método de control definido por ACPI (sección 4.8.2.2.1.2 de la especificación ACPI 5.0) utilizando GPIO-Signaled eventos ACPI (sección 5.6.5 de la especificación ACPI 5.0). Para admitir el dispositivo con el botón de encendido, el espacio de nombres :

  • Describe la patilla de interrupción GPIO del botón de encendido como un recurso de interrupción GPIO no compartido (exclusivo).

  • Enumera el recurso de interrupción GPIO del botón de encendido en el objeto _AEI del controlador GPIO al que está conectado.

  • Proporciona el método de evento asociado (Lxx/Exx/EVT) en el dispositivo del controlador GPIO. Este método de evento notifica al controlador Botón de método de control en el sistema operativo que se ha producido el evento de botón.

Para obtener más información, consulte Botones de hardware para Windows 8 tableta y dispositivos convertibles.

Matriz de botones compatible con Windows

En el caso de las plataformas táctiles (sin teclado), como pizarras, Windows proporciona un controlador genérico para una matriz de cinco botones. Cada botón de la matriz tiene su función definida (vea los elementos numerados de la lista siguiente) y ciertas combinaciones de botones de "mantener y presionar" tienen un significado adicional en la interfaz de usuario. No se definen combinaciones de botones que requieran que se mantenga presionado el botón de encendido. Para la compatibilidad con el controlador de botón bandeja de entrada de Windows, se implementa el dispositivo ACPI compatible con Windows. El dispositivo se define de la siguiente manera:

  • Cada uno de los cinco botones está conectado a su propio pin de interrupción dedicado en la plataforma.

  • Cada patilla de interrupción se configura como un recurso de interrupción no compartido (exclusivo), desencadenado por el borde (Edge) que interrumpe en ambos bordes (ActiveBoth).

  • El espacio de nombres de dispositivo contiene un _HID definido por el proveedor, así como un _CID de PNP0C40.

  • Los recursos de interrupción de GPIO en el objeto _CRS se enumeran en el orden siguiente:

    1. Interrupción correspondiente al botón "Encendido"

      El botón "Power" debe ser compatible con reactivación (ExclusiveAndWake).

    2. Interrupción correspondiente al botón "Windows"

      El botón de Windows debe ser compatible con reactivación (ExclusiveAndWake).

    3. Interrupción correspondiente al botón "Subir volumen"

      El botón "Subir volumen" no debe ser compatible con reactivación (debe usar Exclusivo).

    4. Interrupción correspondiente al botón "Bajar volumen"

      El botón "Bajar volumen" no debe ser compatible con reactivación (debe usar Exclusivo).

    5. Interrupción correspondiente al botón "Bloqueo de rotación", si se admite

      El botón "Bloqueo de rotación" no debe ser compatible con reactivación (debe usar Exclusivo).

Para obtener más información, consulte Botones de hardware para Windows 8 tableta y dispositivos convertibles.

Para admitir la evolución de la interfaz de usuario del botón de Windows, Windows define un método Device-Specific (_DSM) para el dispositivo De matriz de botones de Windows. Para obtener más información, vea Windows Button Array Device-Specific Method (_DSM).

Acoplar y convertir dispositivos de detección de PC

Windows admite acoplamientos y convertibles (combinaciones de clamshell/tableta) mediante el uso de dos dispositivos de detección en el espacio de nombres ACPI. Estos dispositivos son compatibles con el controlador de botón de bandeja de entrada de Windows. Tenga en cuenta que los mismos requisitos que se aplican al dispositivo Button Array también se aplican a estos dispositivos:

  • Las interrupciones activeBoth de GPIO deben estar conectadas a un controlador GPIO en SoC (no a un controlador GPIO conectado a SPB).

  • El controlador GPIO debe admitir interrupciones en modo de nivel y reprogramación dinámica de polaridad.

  • El controlador del controlador GPIO debe usar la emulación ActiveBoth proporcionada por la extensión del marco gpIO (GpioClx).

  • Si el estado asercionado ("Acoplado" o "Convertido") no es bajo en el nivel de lógica, el controlador GPIO _DSM método es necesario para invalidar el comportamiento predeterminado de la pila de controladores GPIO. Para obtener más información, consulte la sección Dispositivos de controlador GPIO en el tema E/S de uso general (GPIO).

Para obtener más información, consulte Botones de hardware para Windows 8 tableta y dispositivos convertibles.

Dispositivo de detección de acoplamiento

Un dispositivo de detección de acoplamiento interrumpe el sistema cuando una base está conectada o desconectada desde el sistema. Esta información de cambio de modo se usa para actualizar la experiencia de entrada y salida del usuario, según sea necesario. El espacio de nombres del dispositivo requiere:

  • Un _HID específico del proveedor

  • Una _CID de PNP0C70

  • Un _CRS con una interrupción de ActiveBoth

    La interrupción no puede ser compatible con reactivación.

Dispositivo de detección de PC convertible

Un dispositivo de detección convertible-PC interrumpe el sistema cuando un PC convertible cambia de tableta a factor de forma de clamshell. Esta información de cambio de modo se usa para actualizar la experiencia de entrada y salida del usuario, según sea necesario. El espacio de nombres del dispositivo requiere:

  • Un _HID específico del proveedor

  • Una _CID de PNP0C60

  • Un _CRS con una interrupción de ActiveBoth

    La interrupción no puede ser compatible con reactivación.