Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 dispositivos que se conectan a buses de datos, como I2C, que no admiten la enumeración de dispositivos secundarios por hardware. 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 de hardware definidos para llevar a cabo esta extracción. Para los buses que no los tienen (como el bus del procesador o un bus periférico simple), ACPI define como 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
Para ver los identificadores de dispositivo que Windows crea para el dispositivo, abra el Administrador de dispositivos e inspeccione 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 coincidencia de 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 los que son menos específicos (y, por lo tanto, solo admiten un subconjunto de las características del dispositivo).
Los identificadores de dispositivo solo deben usarse para la coincidencia de INF y nunca se deben analizar ni procesar mediante el controlador de dispositivo. Si el controlador de dispositivo tiene una necesidad de identificar el hardware específico para el que se cargó, el método recomendado es que el archivo INF establezca las claves del Registro adecuadas en tiempo de 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
Identificador 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 caracteres 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 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 que son compatibles con los controladores de bandeja de entrada enviados con Windows. Windows define varios identificadores de dispositivo para usarlos 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 los identificadores de hardware (devueltos por _HID) sobre los identificadores compatibles (devueltos por _CID) en la coincidencia de INF y selección de controladores. 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.
| Identificación 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 | Dispositivo de sensor de acoplamiento |
| 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 |
Identificación 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, integración o revisión de hardware específica de un dispositivo, o para indicar la pertenencia a una clase de dispositivo definida por PCI. Estos objetos son generalmente opcionales, pero es posible que sea necesario 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 mantenibilidad, hay un requisito del Kit de Certificación de Hardware (HCK) de Windows de que los identificadores de dispositivo en los sistemas OEM sean identificadores de "cuatro partes". Las cuatro partes son el identificador de 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 para un dispositivo determinado o clase de dispositivo define un UUID (GUID) que está garantizado para no entrar 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 y datos específicos de clase se proporcionan en especificaciones separadas para la clase de dispositivo y también se describen en ACPI Device-Specific Métodos.
Address (_ADR) y Identificador Único (_UID)
Hay tres requisitos adicionales para la identificación del dispositivo:
- Para los dispositivos que se conectan a un bus principal detectable por hardware (por ejemplo, SDIO, USB HSIC), pero que tienen características o controles específicos de la plataforma (por ejemplo, alimentación de banda lateral o interrupción de activación), _HID no se utiliza. En su lugar, el controlador primario de bus 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 para el 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, de modo que cada bloque tenga los mismos objetos de identificación del dispositivo, el objeto Identificador único (_UID) es necesario para permitir que el sistema operativo distinga entre bloques.
- Ningún dispositivo de un ámbito de espacio de nombres determinado puede tener el mismo nombre.
Objetos de configuración del dispositivo
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 admite la capacidad de informar sobre varias configuraciones de recursos posibles (_PRS) y los controles para cambiar la configuración de recursos de un dispositivo (_SRS) están soportados pero son opcionales.
Las nuevas incorporaciones a las plataformas SoC son los recursos GPIO y del bus periférico simple (SPB) que un dispositivo puede consumir. Para obtener más información, consulte E/S de uso general (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 (Macro de descriptor de recursos DMA)", de la especificación ACPI 5.0.
Cambios de estado del dispositivo
Los dispositivos enumerados por ACPI se pueden deshabilitar o quitar por diversos motivos. El objeto Status (_STA) se proporciona para permitir que dichos cambios de estado se comuniquen al 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 método de aviso que ASL puede usar para notificar a los controladores sobre eventos en la plataforma, como un dispositivo que se elimina como parte del acoplamiento 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 hacer que Windows vuelva a enumerar el dispositivo y vuelva a evaluar su _STA. Para obtener información sobre las notificaciones ACPI, vea 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 activación y desactivación. 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 "Reducción de 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 dejar de acceder 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, consulte las secciones 6.2.3 (_DIS), 6.2.15 (_SRS) y 6.3.7 (_STA) de la especificación ACPI 5.0.
Dependencias de dispositivos
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 alimentación del dispositivo, los controladores se detienen e inician, etc.). En ACPI, las dependencias entre dispositivos se describen de las maneras siguientes:
Jerarquía de espacios de nombres. Cualquier dispositivo que sea un dispositivo secundario (enumerado como un 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. Del mismo modo, un dispositivo gpu que aparece en el espacio de nombres de un dispositivo de unidad de administración de memoria del sistema (MMU) depende del dispositivo MMU.
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.
Dependencias de OpRegion. Para 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 es aplicable a GeneralPurposeIO y GenericSerialBus OpRegions en los que los controladores 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 ni el 1 ni el 2 anteriores ya se apliquen para el recurso de conexión del 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 deben describirse.
Para obtener más información, consulte los siguientes recursos:
Para ver las dependencias del orden de carga del controlador, consulte Especificación del orden de carga del controlador.
Para conocer las dependencias de relaciones de poder, consulte:
IoInvalidateDeviceRelations (para desencadenar el establecimiento de relaciones de potencia, llame a la rutina IoInvalidateDeviceRelations con el valor de enumeración DEVICE_RELATION_TYPEPowerRelations).