Otros objetos de espacio de nombres ACPI

Para algunas clases específicas de dispositivos, hay requisitos para que los objetos adicionales del espacio de nombres de la Configuración Avanzada e Interfaz de Energía (ACPI) aparezcan bajo esos dispositivos en el 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

Controladores host USB y dispositivos

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, el controlador de host USB puede ser enumerado por ACPI. Windows usa los siguientes objetos de espacio de nombres ACPI al enumerar y configurar hardware USB compatible:

• Un 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 ID compatible (_CID) para el controlador de host USB compatible con el estándar 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 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 TT integrada con el 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á el PORTSC y extraerá la información de velocidad de los 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 poner en un estado de reposo 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 función 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. Se usan dos objetos, ubicación de dispositivo físico (_PLD) y funcionalidades de puerto USB (_UPC) para este propósito. Para obtener más información, consulte lo siguiente:

• Secciones 6.1.6, "Objetos de identificación de dispositivos" y 9.13.1, "Controladores de host USB 2.0 y _UPC y _PLD", en la especificación ACPI 5.0.

• Uso de ACPI para configurar puertos USB en un equipo.

Controladores de host SD y dispositivos

Los controladores de host SD se usan en plataformas SoC para acceder al almacenamiento, así como a dispositivos de E/S. Windows incluye un controlador de bandeja de entrada para hardware de controlador de host estándar 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 puede ser enumerado por ACPI. Windows usa los siguientes objetos de espacio de nombres ACPI al enumerar y configurar hardware SD compatible:

• Un 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 un controlador de host SD conforme al estándar SDA (PNP0D40).

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

  • Se incluyen recursos de hardware para todas las ranuras implementadas. Una ranura es un punto de conexión en el bus SDIO para un dispositivo de E/S o memoria. 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 una.

  • 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 para la ranura SD.

    • Un recurso de interrupción GPIO para la ranura, para la señalización de inserciones y eliminaciones de tarjetas (si la interfaz técnica de detección de tarjetas SD estándar no se admite en 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 de detección de tarjetas SD estándar no se admite durante todos los estados de energía). Usa el mismo pin que la interrupción de inserción o extracción.

    • Un segundo recurso de entrada GPIO para leer si la tarjeta de la ranura está protegida contra escritura (si la interfaz estándar SD de protección contra escritura no se admite en todos los estados de alimentación).

Las interrupciones deben ser capaces de 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 integrados en la plataforma deben listarse también en el espacio de nombres ACPI como elementos secundarios del controlador anfitrión 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 energía del dispositivo, GPIO o SPB consumidos, etc.). Para establecer 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 slot (0 – primer slot)

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

Un espacio de nombres de dispositivo SD incrustado 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 imagen (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 integrados en el chasis del sistema y que 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:

• El dispositivo de cámara aparecerá como un elemento secundario (dispositivo anidado) del dispositivo enumerador (ya sea el dispositivo GPU o el dispositivo USB).

• El dispositivo de cámara está diseñado para proporcionar el objeto Address (_ADR), que contiene la dirección de la cámara en el bus del dispositivo padre.

  • Para USB, consulte jerarquía de espacios de nombres ACPI y _ADR para dispositivos USB incrustados 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 contiene 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 "Posterior" indica que la cámara mira en dirección opuesta al usuario (cámara fotográfica o 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 del espacio de nombres ACPI y _ADR para dispositivos USB embebidos

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 el Administrador de dispositivos de Windows 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 el Administrador de dispositivos para cada dispositivo es la dirección que el firmware debe informar en el _ADR del dispositivo.

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

Hub raíz USB: único hijo del controlador de host. Debe tener un _ADR de 0. No se permiten otros elementos secundarios ni 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. (Adición 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 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 se enumeran mediante ACPI. Para la compatibilidad con la clase HID en Windows, se utilizan los siguientes objetos del espacio de nombres:

• Un _HID específico del proveedor

• Un _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 del 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:

• Causa que la plataforma se encienda si está apagada.

• Genera el evento de anulació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, "Invalidación del botón de encendido", de la especificación ACPI 5.0.

Método de control por botón de encendido

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) mediante GPIO-Signaled eventos ACPI (sección 5.6.5 de la especificación ACPI 5.0). Para admitir el dispositivo de botón de encendido, el espacio de nombres:

• Se describe el pin de interrupción GPIO del botón de encendido como un recurso de interrupción GPIO exclusivo (no compartido).

• 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 del Botón de Método de Control en el sistema operativo que ha ocurrido el evento del botón.

Para obtener más información, consulta Botones de hardware para dispositivos convertibles y tabletas windows 8.

Matriz de botones compatible con Windows

Para plataformas sin teclado, como tabletas, Windows proporciona un controlador genérico para un conjunto 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 suspensión y presión 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 botones integrado en Windows, se implementa el dispositivo ACPI de matriz de botones compatible con Windows. El dispositivo se define de la manera siguiente:

• 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 (Exclusive), desencadenado por flanco (Edge) que interrumpe en ambos flancos (ActiveBoth).

• El espacio de nombres del 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 asociada con el botón de "Encendido"

     El botón "Encendido" debe ser capaz de reactivación (ExclusiveAndWake).

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

     El botón Windows debe ser capaz de despertar (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 es compatible

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

Para obtener más información, consulta Botones de hardware para dispositivos convertibles y tabletas windows 8.

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

Dispositivos de acoplamiento y detección para PC convertibles

Windows admite acoplamientos y convertibles (combinaciones de concha/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 GPIO ActiveBoth 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 la reprogramación dinámica de la polaridad.

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

• Si el estado afirmado ("Acoplado" o "Convertido") no es de nivel lógico bajo, es necesario usar el método _DSM del controlador GPIO 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, consulta Botones de hardware para dispositivos convertibles y tabletas windows 8.

Dispositivo de detección de acoplamiento

Un dispositivo sensor de dock interrumpe el sistema cuando un dock se acopla o desacopla del 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

• Un código de identificación (_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 de PC convertible interrumpe el sistema cuando un PC convertible cambia de tableta a modo 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

• Un _CID de PNP0C60

• Un _CRS con una interrupción de ActiveBoth

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