Descripción de la ruta de acceso de los IRP de espera/reactivación a través de un árbol de dispositivos

Dentro de una sola pila de dispositivos, el propietario de la directiva de energía envía un IRP de espera/reactivación y todos los controladores controlan el IRP de espera/reactivación, como se describe en Información general de la operación de espera/ reactivación y se detalla en Envío de un IRP de espera/ reactivación y recepción de un IRP de espera/reactivación, respectivamente.

Dentro de una rama del árbol de dispositivos (que consta de un nodo hoja y los devnodes de sus elementos primarios, abuelos, etc.), los controladores deben cooperar para garantizar que un IRP de espera/reactivación llegue a un controlador que pueda habilitar todo el hardware necesario para reactivación.

En los equipos ACPI, ACPI es responsable de habilitar el registro del evento de De uso general específico del sistema (GPE) asociado a la señal de reactivación de cada dispositivo hoja. Por lo tanto, los controladores deben solicitar y reenviar IRP de espera/reactivación hasta que uno llegue a un controlador de filtro ACPI (insertado en la pila de dispositivos en el inicio) o al controlador ACPI de Windows subyacente, Acpi.sys. En respuesta, ACPI habilita el registro, mantiene el IRP pendiente hasta que llega la señal y, a continuación, completa el IRP. Dado que ACPI puede responder a la señal de reactivación, no reenvía el IRP a un controlador inferior.

Los controladores de filtro ACPI, como el propio controlador ACPI subyacente, son transparentes para otros controladores. Para proporcionar la máxima flexibilidad en el diseño de hardware, la posición exacta de un controlador de filtro ACPI en cualquier pila de dispositivos es específica del dispositivo y del sistema. Al diseñar un controlador, no se pueden realizar suposiciones sobre la presencia o posición de un filtro ACPI en la pila de dispositivos.

Tenga en cuenta que los controladores que enumeran elementos secundarios crean un PDO para cada dispositivo secundario y un FDO para el dispositivo primario. Por lo tanto, el controlador actúa como controlador de bus para un dispositivo secundario y el propietario de la directiva o controlador de función para un dispositivo primario. Por lo tanto, cada vez que un controlador de autobús recibe un IRP de espera/reactivación para un PDO secundario, debe solicitar otro IRP de espera/reactivación para su PDO primario.

En la ilustración siguiente se muestra una configuración de ejemplo en la que se produce esta situación.

En la configuración de ejemplo, el teclado y el módem son elementos secundarios del concentrador USB, que a su vez es un elemento secundario del controlador de host USB, que se enumera mediante el bus PCI. En la ilustración siguiente se muestran las pilas de dispositivos para el teclado en la configuración de ejemplo.

Como se muestra en la ilustración anterior, leyendo desde la parte inferior hacia arriba:

1. El controlador ACPI de Windows, Acpi.sys, crea el PDO para PCI.

2. El controlador PCI crea el FDO PCI y el controlador de host USB PDO y posee la directiva para la pila de dispositivos PCI.

3. El controlador del controlador de host USB (un par de controladores de puerto/minipuerto del host) crea el FDO del controlador de host USB y el PDO del concentrador USB. Posee la directiva para la pila de dispositivos del controlador de host USB. Tenga en cuenta que Acpi.sys también crea un do de filtro en esta pila.

4. El controlador del concentrador USB crea el FDO del concentrador USB y el PDO del teclado. Este controlador posee la directiva de alimentación para la pila de dispositivos del concentrador USB.

5. El controlador de función para el teclado es el par de controladores o minidriveres de la clase USB HID. Este controlador crea el FDO para el teclado y posee su directiva de energía. Dado que el teclado no tiene dispositivos secundarios, este controlador no crea archivos PDO.

Tenga en cuenta que cada pila de dispositivos puede incluir DO de filtro opcional adicionales que no se muestran.

Para permitir que la entrada del teclado active el sistema, el propietario de la directiva del teclado solicita un IRP_MN_WAIT_WAKE para su PDO. Ese IRP establece una cadena de otros IRP de espera/reactivación, como se muestra en la ilustración siguiente.

Cuando un controlador de bus recibe un IRP_MN_WAIT_WAKE dirigido a un PDO que creó, debe solicitar otro IRP_MN_WAIT_WAKE para la pila de dispositivos para la que posee la directiva de energía y ha creado un FDO.

Como se muestra en la ilustración anterior:

1. El controlador de teclado llama a PoRequestPowerIrp para enviar un IRP de espera/reactivación (IRP1) a su PDO.

   El administrador de energía asigna el IRP y lo envía a través del administrador de E/S a la parte superior de la pila de dispositivos para el teclado. Los controladores establecen rutinas de IoCompletion y pasan el IRP a la pila hasta que llega al PDO del teclado. El controlador del concentrador USB, que actúa como controlador de bus para el teclado, contiene IRP1 pendiente.

2. Dado que el controlador del concentrador USB no puede reactivar el sistema cuando llega la señal de reactivación, el controlador del concentrador USB debe llamar a PoRequestPowerIrp para solicitar un IRP de espera/reactivación (IRP2) para la pila de dispositivos del concentrador USB.

   El administrador de energía envía este IRP a la parte superior de la pila de dispositivos del concentrador USB. Los controladores de esta pila establecen rutinas de IoCompletion y pasan el IRP al controlador del controlador del host USB (que actúa como controlador de bus para el concentrador USB). El controlador del controlador de host USB contiene IRP2 pendiente hasta que el teclado señale un evento de reactivación.

3. Del mismo modo, el controlador del controlador de host USB no puede reactivar el sistema, por lo que el controlador del controlador de host USB llama a PoRequestPowerIrp para enviar un IRP de espera/reactivación (IRP3) a la pila de dispositivos del controlador de host USB.

   El administrador de energía envía este IRP a la parte superior de la pila de dispositivos del controlador de host USB, donde los controladores establecen rutinas de IoCompletion y pasan el IRP al controlador PCI (que actúa como controlador de bus para el concentrador USB). El controlador PCI contiene IRP3 pendiente hasta que el teclado señale un evento de reactivación.

4. El controlador PCI no puede reactivar el sistema, por lo que el controlador PCI llama a PoRequestPowerIrp para enviar un IRP de espera/reactivación (IRP4) a la pila de dispositivos PCI. Su elemento primario es el dispositivo raíz, para el que ACPI es el controlador de autobús.

   El administrador de energía envía el IRP a la parte superior de la pila de dispositivos de bus PCI; sus controladores establecen rutinas de finalización y pasan el IRP al controlador ACPI de Windows, Acpi.sys.

5. Acpi.sys puede reactivar el sistema, por lo que no envía un IRP de espera o reactivación a ningún otro PDO. Acpi.sys contiene IRP4 pendiente hasta que llega una señal de reactivación.

Cuando el teclado afirma la señal de reactivación, Acpi.sys la intercepta. Sin embargo, ACPI no puede determinar que el teclado afirmó la señal, solo que la señal llegó a través del dispositivo raíz. Acpi.sys luego completa IRP4 y el administrador de E/S llama a las rutinas de IoCompletion que viajan de copia de seguridad de la pila de dispositivos PCI. Cuando se completa IRP4 y se ejecutan todas las rutinas de IoCompletion , se invoca la rutina de devolución de llamada del controlador PCI. En su rutina de devolución de llamada, el controlador PCI determina que la señal llegó a través del controlador de host USB. A continuación, el controlador PCI completa IRP3. La misma secuencia se produce a través de la pila del controlador de host USB y la pila del concentrador USB, hasta que el controlador de teclado recibe IRP1. En este momento, el controlador de teclado puede atender el evento de reactivación, según sea necesario.

Cada vez que un controlador envía un IRP de espera o reactivación a un PDO primario, debe establecer una rutina Cancel para su propio IRP. Al establecer una rutina Cancel , el controlador tiene la oportunidad de cancelar el nuevo IRP si el IRP que lo desencadenó se cancela. En el ejemplo USB, si el controlador del teclado cancela su IRP de espera/reactivación (deshabilitando la reactivación del teclado), el concentrador USB, el controlador de host USB y los controladores PCI deben cancelar los IRP que enviaron como consecuencia del IRP del teclado. Para obtener más información, consulte Cancel Routines for Wait/Wake IRPs.

Aunque un controlador primario puede enumerar más de un elemento secundario que se puede habilitar para espera/reactivación, solo un IRP de espera o reactivación puede estar pendiente para un PDO. En tales casos, el controlador primario debe asegurarse de que mantiene un IRP de espera/reactivación pendiente siempre que cualquiera de sus dispositivos esté habilitado para reactivación. Para ello, el controlador incrementa un contador interno cada vez que recibe un IRP de espera/reactivación. Cada vez que el controlador completa un IRP de espera o reactivación, disminuye el recuento y, si el valor resultante es distinto de cero, envía otro IRP de espera/reactivación a su pila de dispositivos.

Por ejemplo, en la configuración USB mostrada anteriormente en la figura Configuración usb de ejemplo, el concentrador USB enumera dos dispositivos, un teclado y un módem. Cuando el controlador del concentrador USB recibe un IRP de espera/reactivación para el PDO del teclado, incrementa un recuento de IRP de espera/reactivación antes de solicitar un IRP para su propio PDO. Si el propietario de la directiva del módem posteriormente habilita la reactivación para el módem, el controlador del concentrador USB lápiz el nuevo IRP para el módem PDO e incrementa su recuento de referencias de espera/reactivación. Sin embargo, dado que el PDO del concentrador USB no puede tener dos IRP de espera/reactivación simultáneamente, el controlador del concentrador USB no solicita un nuevo IRP de espera/reactivación para el PDO del concentrador USB.

Cuando llega una señal de reactivación desde el teclado o módem, el controlador del concentrador USB determina qué dispositivo señala, completa el IRP correspondiente y disminuye su recuento de referencias. Dado que ambos dispositivos se habilitaron para reactivación (y, por lo tanto, su recuento de referencias es distinto de cero), debe enviar su propia pila de dispositivos otra IRP de espera/reactivación a "rearm" su propio PDO para reactivación. (Lo mismo ocurre con el controlador de host USB y el controlador PCI).

Sin embargo, un controlador no envía un IRP para volver a habilitar la espera o reactivación en el mismo dispositivo en el que acaba de llegar una señal de reactivación. Solo el administrador de directivas de energía del dispositivo puede hacerlo. Volver a habilitar la espera o reactivación no es automática.