Compartir a través de

Objetos de espacio de nombres de administración de dispositivos

  • Artículo

La especificación ACPI 5.0 define varios tipos de objetos de espacio de nombres que se pueden usar para administrar dispositivos. Por ejemplo, los objetos de identificación de dispositivos contienen información de identificación para los dispositivos que se conectan a los autobuses, como I2C, que no admiten la enumeración de hardware de los dispositivos secundarios. Otros tipos de objetos de espacio de nombres pueden especificar recursos del sistema, describir las dependencias del dispositivo e indicar qué dispositivos se pueden deshabilitar.

Identificación del dispositivo en Windows

Windows Plug and Play busca y carga controladores de dispositivo en función de un identificador de dispositivo proporcionado por el enumerador del dispositivo. Los enumeradores son controladores de autobús que saben cómo extraer información de identificación del dispositivo. Algunos autobuses (como PCI, SD y USB) tienen mecanismos definidos por hardware para realizar esta extracción. Para los autobuses que no lo hacen (como el bus de procesador o un simple bus periférico), ACPI define los objetos de identificación en el espacio de nombres.

El controlador ACPI de Windows, Acpi.sys, ensambla los valores que se encuentran en estos objetos en varias cadenas de identificador de dispositivo que pueden identificar un dispositivo específicamente, o genéricamente, en función de las necesidades del controlador. Algunos de los patrones de cadena creados para identificar los dispositivos enumerados por ACPI son:

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

Puede ver los identificadores de dispositivo que Windows crea para el dispositivo abriendo Administrador de dispositivos e inspeccionando las propiedades Identificadores de hardware e identificadores compatibles del dispositivo enumerado. Cada una de estas cadenas está disponible para especificarse en un archivo INF para identificar el controlador que se va a cargar para el dispositivo. El orden de la coincidencia inf procede del identificador de hardware más específico (controlador más preferido) al identificador menos específico (controlador menos preferido), de modo que los controladores que conozcan más sobre las características específicas del dispositivo pueden reemplazar las que son menos específicas (y, por lo tanto, solo admiten un subconjunto de las características del dispositivo).

Los identificadores de dispositivo se deben usar solo para la coincidencia inf y nunca se deben analizar ni procesar mediante el controlador de dispositivo. Si el controlador de dispositivo tiene la necesidad de identificar el hardware específico para el que se cargó, el método recomendado es hacer que el archivo INF establezca las claves del Registro adecuadas en el momento de la instalación. A continuación, el controlador puede acceder a estas claves durante la inicialización para obtener la información necesaria.

Identificación del dispositivo en ACPI

Id. de hardware (_HID)

El requisito mínimo para identificar un dispositivo en ACPI es el objeto id. de hardware (_HID). _HID devuelve una cadena con el formato "ABC[D]xxxx", donde "ABC[D]" es una cadena de 3 o 4 caracteres que identifica al fabricante del dispositivo (el "Id. de proveedor") y xxxx es un número hexadecimal que identifica el dispositivo específico fabricado por ese proveedor (el "Id. de dispositivo"). Los identificadores de proveedor deben ser únicos en todo el sector. Microsoft asigna estas cadenas para asegurarse de que son únicas. Los identificadores de proveedor se pueden obtener a partir de Plug and Play id. : solicitud PNPID.

ACPI 5.0 también admite el uso de identificadores de proveedor asignados por PCI en _HID y otros objetos de identificación, por lo que es posible que no necesite obtener un identificador de proveedor de Microsoft. Para obtener más información sobre los requisitos de identificación de hardware, consulte la sección 6.1.5, "_HID (Id. de hardware)", de la especificación ACPI 5.0.

Id. compatible (_CID)

Microsoft ha reservado el identificador de proveedor "PNP" para dispositivos compatibles con los controladores de bandeja de entrada enviados con Windows. Windows define un número de identificadores de dispositivo para su uso con este identificador de proveedor que se puede usar para cargar el controlador proporcionado por Windows para un dispositivo. Un objeto independiente, el objeto Id. compatible (_CID), se usa para devolver estos identificadores. Windows siempre prefiere identificadores de hardware (devueltos por _HID) en identificadores compatibles (devueltos por _CID) en la selección de controladores y coincidencias de INF. Esta preferencia permite que el controlador proporcionado por Windows se trate como un controlador predeterminado si un controlador específico del dispositivo proporcionado por el proveedor no está disponible. Los identificadores compatibles de la tabla siguiente se crean recientemente para su uso con plataformas SoC.

Id. compatible Descripción
PNP0C40 Matriz de botones compatible con Windows
PNP0C50 Dispositivo compatible con HID-over-I2C
PNP0C60 Dispositivo de sensor de pantalla portátil convertible
PNP0C70 Acoplar dispositivo de sensor
PNP0D10 Controlador USB compatible con XHCI con depuración estándar
PNP0D15 Controlador USB compatible con XHCI sin depuración estándar
PNP0D20 Controlador USB compatible con EHCI sin depuración estándar
PNP0D25 Controlador USB compatible con EHCI con depuración estándar
PNP0D40 Controlador de host sd compatible con el estándar SDA
PNP0D80 Controlador de administración de energía del sistema compatible con Windows

Identificador del subsistema (_SUB), Revisión de hardware (_HRV) y Clase (_CLS)

ACPI 5.0 define los objetos _SUB, _HRV y _CLS que se pueden usar junto con el _HID para crear identificadores que identifiquen de forma más única una versión específica, integración o revisión de hardware de un dispositivo, o para indicar la pertenencia a una clase de dispositivo definida por PCI. Por lo general, estos objetos son opcionales, pero pueden ser necesarios para determinadas clases de dispositivo en Windows. Para obtener más información sobre estos objetos, vea la sección 6.1, "Objetos de identificación de dispositivos", de la especificación ACPI 5.0.

Para la capacidad de servicio, hay un requisito del Kit de certificación de hardware (HCK) de Windows que los identificadores de dispositivo en los sistemas OEM sean identificadores de "cuatro partes". Las cuatro partes son el identificador del proveedor, el identificador de dispositivo, el identificador del proveedor del subsistema (OEM) y el identificador de dispositivo del subsistema (OEM). Por lo tanto, el objeto Subsystem ID (_SUB) es necesario para las plataformas OEM.

Método Device-Specific (_DSM)

El método _DSM se define en la sección 9.14.1, "_DSM (método específico del dispositivo)", de la especificación ACPI 5.0. Este método proporciona funciones de control y datos individuales específicos del dispositivo a las que puede llamar un controlador de dispositivo sin entrar en conflicto con otros métodos específicos del dispositivo. El _DSM de una clase de dispositivo o dispositivo determinada define un UUID (GUID) que se garantiza que no entre en conflicto con otros UUID. Para cada UUID, hay un conjunto de funciones definidas que el método _DSM puede implementar para proporcionar datos o para realizar funciones de control para el controlador. Los formatos de datos y datos específicos de clase se proporcionan en especificaciones específicas de clase de dispositivo independientes y también se describen en ACPI Device-Specific Métodos.

Dirección (_ADR) e Identificador único (_UID)

Hay tres requisitos adicionales para la identificación del dispositivo:

  • En el caso de los dispositivos que se conectan a un bus primario enumerable de hardware (por ejemplo, SDIO, USB HSIC), pero que tienen características o controles específicos de la plataforma (por ejemplo, interrupción de encendido o reactivación de banda lateral), no se usa el _HID. En su lugar, el controlador de bus primario crea el identificador del dispositivo (como se explicó anteriormente). Sin embargo, en este caso, es necesario que el objeto address (_ADR) esté en el espacio de nombres ACPI del dispositivo. Este objeto permite al sistema operativo asociar el dispositivo enumerado por bus con sus características o controles descritos por ACPI.
  • En las plataformas en las que se usan varias instancias de un bloque IP determinado, para que cada bloque tenga los mismos objetos de identificación de dispositivo, el objeto Identificador único (_UID) es necesario para permitir que el sistema operativo distinga entre bloques.
  • Ningún dos dispositivos de un ámbito de espacio de nombres determinado pueden tener el mismo nombre.

Objetos de configuración de dispositivos

Para cada dispositivo identificado en el espacio de nombres, los recursos del sistema (direcciones de memoria, interrupciones, etc.) consumidos por el dispositivo también deben ser notificados por el objeto Configuración de recursos actual (_CRS). Se admiten informes de varias configuraciones de recursos posibles (_PRS) y controles para cambiar la configuración de recursos de un dispositivo (_SRS), pero es opcional.

Las nuevas para plataformas SoC son recursos gpIO y de bus periférico simple (SPB) que un dispositivo puede consumir. Para obtener más información, consulte De uso general E/S (GPIO) y Simple Peripheral Bus (SPB).

También es nuevo para las plataformas SoC un descriptor DMA fijo de uso general. El descriptor FixedDMA admite el uso compartido del hardware del controlador DMA por varios dispositivos del sistema. Los recursos DMA (registros de línea de solicitud y canal) asignados estáticamente a un dispositivo del sistema determinado se muestran en el descriptor FixedDMA. Para obtener más información, vea la sección 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)", de la especificación ACPI 5.0.

Cambios en el estado del dispositivo

Los dispositivos enumerados por ACPI se pueden deshabilitar o quitar por diversos motivos. Se proporciona el objeto Status (_STA) para permitir que dichos cambios de estado se comuniquen con el sistema operativo. Para obtener una descripción de _STA, consulte la sección 6.3.7 de la especificación ACPI 5.0. Windows usa _STA para determinar si se debe enumerar el dispositivo, que se muestra como deshabilitado o no visible para el usuario. Este control en el firmware es útil para muchas aplicaciones, como acoplamiento y conmutación de host a función usb OTG.

Además, ACPI proporciona un mecanismo de notificación que ASL puede usar para notificar a los controladores de eventos en la plataforma, como un dispositivo que se quita como parte de una base. En general, cuando cambia el estado de un dispositivo ACPI, el firmware debe realizar una notificación de "comprobación de dispositivo" o "comprobación de bus" para que Windows vuelva a enumerar el dispositivo y vuelva a evaluar su _STA. Para obtener información sobre las notificaciones ACPI, consulte la sección 5.6.6, "Notificaciones de objetos de dispositivo", de la especificación ACPI 5.0.

Habilitar o deshabilitar

Como parte de Windows Plug and Play, los controladores deben ser capaces de estar habilitados y deshabilitados dinámicamente por el usuario o por el sistema (por ejemplo, para actualizar un controlador).

Los dispositivos On-SoC se integran en el chip SoC y no se pueden quitar. Los controladores para la mayoría de los dispositivos SoC se pueden excluir de los requisitos para habilitar y deshabilitar. Para aquellos controladores que no están exentos, hay interfaces de controlador para indicar que el controlador admite la eliminación ordenada. Para obtener más información, vea el documento titulado "Reducir los requisitos de PNP para controladores soC" en el sitio web de Microsoft Connect.

Si un controlador admite la eliminación ordenada y el hardware del dispositivo se puede deshabilitar (es decir, el dispositivo se puede configurar para detener el acceso a sus recursos asignados), el nodo de espacio de nombres ACPI para el dispositivo puede incluir el objeto Disable (_DIS). El sistema operativo evaluará este método cada vez que se quite el controlador. El uso de _DIS tiene los siguientes requisitos adicionales:

  • _STA debe borrar el bit "habilitado y descodificar sus recursos" cada vez que el dispositivo está deshabilitado.
  • El dispositivo debe proporcionar el objeto Establecer configuración de recursos (_SRS) para volver a habilitar el hardware del dispositivo y establecer el bit anterior en _STA.

Para obtener más información, vea las secciones 6.2.3 (_DIS), 6.2.15 (_SRS) y 6.3.7 (_STA) de la especificación ACPI 5.0.

Dependencias del dispositivo

Normalmente, hay dependencias de hardware entre dispositivos en una plataforma determinada. Windows requiere que se describan todas estas dependencias para que pueda asegurarse de que todos los dispositivos funcionen correctamente a medida que las cosas cambian dinámicamente en el sistema (se quita la energía del dispositivo, los controladores se detienen e inician, etc.). En ACPI, las dependencias entre dispositivos se describen de las siguientes maneras:

  1. Jerarquía de espacios de nombres. Cualquier dispositivo que sea un dispositivo secundario (enumerado como dispositivo dentro del espacio de nombres de otro dispositivo) depende del dispositivo primario. Por ejemplo, un dispositivo HSIC USB depende del puerto (primario) y del controlador (abuelo) al que está conectado. De forma similar, un dispositivo gpu enumerado en el espacio de nombres de un dispositivo de unidad de administración de memoria del sistema (MMU) depende del dispositivo MMU.

  2. Conexiones de recursos. Los dispositivos conectados a controladores GPIO o SPB dependen de esos controladores. Este tipo de dependencia se describe mediante la inclusión de recursos de conexión en el _CRS del dispositivo.

  3. Dependencias de OpRegion. En el caso de los métodos de control ASL que usan OpRegions para realizar E/S, el sistema operativo no conoce implícitamente las dependencias porque solo se determinan durante la evaluación del método de control. Este problema se aplica a GeneralPurposeIO y GenericSerialBus OpRegions en los que los controladores de Plug and Play proporcionan acceso a la región. Para mitigar este problema, ACPI define el objeto OpRegion Dependency (_DEP). _DEP debe usarse en cualquier espacio de nombres de dispositivo en el que un método de control haga referencia a un opRegion (recurso HW) y ninguno de los dos o 1 anteriores ya se aplica para el recurso de conexión de OpRegion al que se hace referencia. Para obtener más información, vea la sección 6.5.8, "_DEP (Dependencias de la región de operación)", de la especificación ACPI 5.0.

También puede haber dependencias de software entre controladores de dispositivo. Estas dependencias también se deben describir.

Para obtener más información, consulte los siguientes recursos: