Informazioni sul percorso dei runtime di integrazione di attesa/riattivazione tramite un albero dei dispositivi
All'interno di un singolo stack di dispositivi, il proprietario dei criteri di alimentazione invia un IRP di attesa/riattivazione e tutti i driver gestiscono rispettivamente l'IRP di attesa/riattivazione, come descritto in Panoramica dell'operazione di attesa/riattivazione e in Dettaglio in Invio di un IRP di attesa/riattivazione e ricezione di un IRP di attesa/riattivazione.
All'interno di un ramo dell'albero dei dispositivi (che comprende un nodo devnode foglia e gli sviluppatori dei genitori, dei nonni e così via), i driver devono collaborare per garantire che un IRP di attesa/riattivazione raggiunga un driver in grado di abilitare tutto l'hardware necessario per la riattivazione.
Nei computer ACPI, ACPI è responsabile dell'abilitazione del registro per utilizzo generico Event (GPE) specifico del sistema associato al segnale di riattivazione da ogni dispositivo foglia. Di conseguenza, i driver devono richiedere e inoltrare irP di attesa/riattivazione fino a quando uno raggiunge un driver di filtro ACPI (inserito nello stack di dispositivi all'avvio) o il driver ACPI di Windows sottostante, Acpi.sys. In risposta, ACPI abilita il registro, mantiene l'IRP in sospeso fino all'arrivo del segnale e quindi completa l'IRP. Poiché ACPI può rispondere al segnale di riattivazione, non inoltra l'IRP a un driver inferiore.
I driver di filtro ACPI, come il driver ACPI sottostante stesso, sono trasparenti per altri driver. Per garantire la massima flessibilità nella progettazione hardware, la posizione esatta di un driver di filtro ACPI in qualsiasi stack di dispositivi è specifica del dispositivo e del sistema. Nella progettazione di un driver non è possibile fare ipotesi sulla presenza o sulla posizione di un filtro ACPI nello stack di dispositivi.
Tenere presente che i driver che enumerare gli elementi figlio creano un PDO per ogni dispositivo figlio e un fdO per il dispositivo padre. Il driver funge quindi da driver del bus per un dispositivo figlio e il proprietario di driver/criteri della funzione per un dispositivo padre. Pertanto, ogni volta che un autista riceve un IRP di attesa/riattivazione per un PDO figlio, deve richiedere un altro IRP di attesa/riattivazione per il pdO padre.
Nella figura seguente viene illustrata una configurazione di esempio in cui si verifica una situazione di questo tipo.
Nella configurazione di esempio, la tastiera e il modem sono elementi figlio dell'hub USB, che a sua volta è un figlio del controller host USB, che viene enumerato dal bus PCI. La figura seguente mostra gli stack di dispositivi per la tastiera nella configurazione di esempio.
Come illustrato nella figura precedente, leggere dal basso verso l'alto:
Il driver ACPI di Windows, Acpi.sys, crea il PDO per PCI.
Il driver PCI crea il PDO pci e il controller host USB PDO e possiede i criteri per lo stack di dispositivi PCI.
Il driver del controller host USB (una coppia di driver porta host/miniport) crea il controller host USB FDO e l'hub USB PDO. È proprietario dei criteri per lo stack di dispositivi del controller host USB. Si noti che Acpi.sys crea anche un'operazione di filtro in questo stack.
Il driver hub USB crea il fdO dell'hub USB e il PDO della tastiera. Questo driver è proprietario dei criteri di alimentazione per lo stack di dispositivi dell'hub USB.
Il driver di funzione per la tastiera è la coppia driver/minidriver di classe USB HID. Questo driver crea l'fdO per la tastiera e possiede i propri criteri di alimentazione. Poiché la tastiera non ha dispositivi figlio, questo driver non crea pdo.
Si noti che ogni stack di dispositivi potrebbe includere oggetti DO di filtro facoltativi aggiuntivi non visualizzati.
Per consentire all'input della tastiera di risvegliare il sistema, il proprietario dei criteri per la tastiera richiede un IRP_MN_WAIT_WAKE per il proprio PDO. Che IRP imposta una catena di altri IRP di attesa/riattivazione, come illustrato nella figura seguente.
Quando un driver del bus riceve un IRP_MN_WAIT_WAKE destinato a un PDO creato, deve richiedere un altro IRP_MN_WAIT_WAKE per lo stack di dispositivi per il quale è proprietario dei criteri di alimentazione e ha creato un fdO.
Come illustrato nella figura precedente:
Il driver della tastiera chiama PoRequestPowerIrp per inviare un IRP di attesa/riattivazione (IRP1) al proprio PDO.
Il risparmio energia alloca l'IRP e lo invia tramite il gestore di I/O all'inizio dello stack di dispositivi per la tastiera. I driver impostano routine IoCompletion e passano l'IRP verso il basso lo stack fino a raggiungere il PDO della tastiera. Il driver dell'hub USB, che funge da driver del bus per la tastiera, contiene IRP1 in sospeso.
Poiché il driver dell'hub USB non può riattivare il sistema quando arriva il segnale di riattivazione, il driver dell'hub USB deve chiamare PoRequestPowerIrp per richiedere un IRP di attesa/riattivazione (IRP2) per lo stack di dispositivi dell'hub USB.
Il risparmio energia invia questo IRP all'inizio dello stack di dispositivi dell'hub USB. I driver in questo stack impostano routine IoCompletion e passano l'IRP al driver del controller host USB (che funge da driver bus per l'hub USB). Il driver del controller host USB contiene IRP2 in sospeso fino a quando la tastiera non segnala un evento di riattivazione.
Analogamente, il driver del controller host USB non può riattivare il sistema, quindi il driver del controller host USB chiama PoRequestPowerIrp per inviare un IRP di attesa/riattivazione (IRP3) allo stack di dispositivi del controller host USB.
Il risparmio energia invia questo IRP all'inizio dello stack di dispositivi del controller host USB, in cui i driver impostano routine IoCompletion e passano l'IRP al driver PCI (che funge da driver bus per l'hub USB). Il driver PCI contiene IRP3 in sospeso finché la tastiera non segnala un evento di riattivazione.
Il driver PCI non può riattivare il sistema, quindi il driver PCI chiama PoRequestPowerIrp per inviare un IRP di attesa/riattivazione (IRP4) allo stack di dispositivi PCI. Il padre è il dispositivo radice, per il quale ACPI è il driver del bus.
Il risparmio energia invia l'IRP all'inizio dello stack di dispositivi del bus PCI; i relativi driver impostano routine di completamento e passano l'IRP verso il basso al driver ACPI di Windows, Acpi.sys.
Acpi.sys possibile riattivare il sistema, quindi non invia un IRP di attesa/riattivazione a qualsiasi altro PDO. Acpi.sys contiene IRP4 in sospeso fino all'arrivo di un segnale di riattivazione.
Quando la tastiera asserisce il segnale di riattivazione, Acpi.sys intercetta. ACPI, tuttavia, non può determinare che la tastiera ha asserito il segnale, solo che il segnale è venuto attraverso il dispositivo radice. Acpi.sys completa quindi IRP4 e il gestore di I/O chiama routine IoCompletion che eseziona il backup dello stack di dispositivi PCI. Quando IRP4 è completo e tutte le routine IoCompletion sono state eseguite, viene richiamata la routine di callback del driver PCI. Nella routine di callback, il driver PCI determina che il segnale proviene dal controller host USB. Il driver PCI completa quindi IRP3. La stessa sequenza avviene tramite lo stack del controller host USB e lo stack dell'hub USB, fino a quando il driver della tastiera non riceve IRP1. A questo punto, il driver della tastiera può eseguire l'evento di riattivazione, se necessario.
Ogni volta che un driver invia un IRP di attesa/riattivazione a un PDO padre, deve impostare una routine Cancel per il proprio IRP. L'impostazione di una routine Cancel consente al driver di annullare il nuovo IRP se l'IRP che lo ha attivato viene annullato. Nell'esempio USB, se il driver della tastiera annulla l'IRP di attesa/riattivazione (disabilitando così la riattivazione della tastiera), l'hub USB, il controller host USB e i driver PCI devono annullare i provider di integrazione inviati come conseguenza dell'IRP della tastiera. Per altre informazioni, vedere Cancel Routines for Wait/Wake IRPs.For more information, see Cancel Routines for Wait/Wake IRPs.
Anche se un driver padre potrebbe enumerare più di un elemento figlio che può essere abilitato per l'attesa/riattivazione, è possibile che un solo IRP di attesa/riattivazione sia in sospeso per un PDO. In questi casi, il driver padre deve assicurarsi che mantenga un IRP di attesa/riattivazione in sospeso ogni volta che uno dei dispositivi è abilitato per la riattivazione. A tale scopo, il driver incrementa un contatore interno ogni volta che riceve un IRP di attesa/riattivazione. Ogni volta che il driver completa un IRP di attesa/riattivazione, decrementa il conteggio e, se il valore risultante è diverso da zero, invia un altro IRP di attesa/riattivazione allo stack di dispositivi.
Ad esempio, nella configurazione USB illustrata in precedenza nella figura Configurazione USB di esempio, l'hub USB enumera due dispositivi, una tastiera e un modem. Quando il driver dell'hub USB riceve un IRP di attesa/riattivazione per il PDO della tastiera, incrementa un numero di irp di attesa/riattivazione prima di richiedere un IRP per il proprio PDO. Se il proprietario dei criteri del modem abilita successivamente la riattivazione per il modem, il driver dell'hub USB esegue la penna del nuovo IRP per il PDO del modem e incrementa il numero di riferimenti di attesa/riattivazione. Tuttavia, poiché il PDO dell'hub USB non può avere due irP di attesa/riattivazione simultanei in sospeso, il driver dell'hub USB non richiede un nuovo IRP di attesa/riattivazione per il PDO dell'hub USB.
Quando arriva un segnale di riattivazione dalla tastiera o dal modem, il driver dell'hub USB determina il dispositivo segnalato, completa l'IRP corrispondente e ne decrementa il conteggio dei riferimenti. Poiché entrambi i dispositivi sono stati abilitati per la riattivazione (e quindi il numero di riferimenti è diverso da zero), deve inviare un altro IRP di attesa/riattivazione a "riprovare" il proprio PDO per la riattivazione. Lo stesso vale per il controller host USB e il driver PCI.
Un driver non invia tuttavia un IRP per riattivare l'attesa/riattivazione sullo stesso dispositivo in cui è appena arrivato un segnale di riattivazione. Solo il gestore di Power Policy del dispositivo può farlo. La riattivazione dell'attesa/riattivazione non è automatica.