Uso di PEP per i servizi ACPI

Questo argomento fornisce informazioni sull'uso dei plug-in di estensione della piattaforma per i servizi ACPI.

I PEP forniscono metodi ACPI dinamici e di runtime. Le tabelle statiche (FADT, MADT, DBG2 e così via) devono essere implementate nel firmware ACPI, nonché nella gerarchia dei dispositivi DSDT/SSDT.

I PEP devono essere usati per i metodi di risparmio energia off-SoC. Poiché sono file binari installabili, possono essere aggiornati sul volo anziché il firmware ACPI che richiede un flash del firmware. Ciò significa che è possibile migliorare il codice di risparmio energia nelle piattaforme già inviate pubblicando un driver aggiornato in Windows Update. Gestione energia era la finalità originale per i PEP, ma possono essere usati per fornire o eseguire l'override di qualsiasi metodo di runtime ACPI arbitrario.

I PEP non svolgono alcun ruolo nella costruzione della gerarchia dello spazio dei nomi ACPI perché la gerarchia dello spazio dei nomi deve essere fornita nel firmware DSDT. Quando il driver ACPI valuta un metodo in fase di esecuzione, verificherà i metodi implementati dal PEP per il dispositivo in questione e, se presente, eseguirà il PEP e ignorerà la versione del firmware. Tuttavia, il dispositivo stesso deve essere definito nel firmware.

La fornitura di risparmio energia tramite IPS può risultare molto più semplice rispetto al codice scritto per il firmware ACPI a causa degli strumenti disponibili. Gli strumenti per il debug del firmware ACPI non sono familiari con la maggior parte delle opzioni degli strumenti e sono limitati. Al contrario, i PEP vengono sviluppati come driver Windows in modo che gli sviluppatori possano usare qualsiasi strumento di sviluppo e debug con cui sono più comodi.

Quando si usa un PEP al posto di un servizio ACPI, non è necessaria alcuna azione o operazione speciale per richiedere il ruolo del servizio. Quando un metodo viene implementato nel PEP, Windows lo userà automaticamente. Se viene fornita una versione del firmware dello stesso metodo nello stesso dispositivo, verrà ignorata.

I PEP vengono caricati molto presto in modo che i loro servizi siano disponibili per il driver di dispositivo. Inoltre, il livello di astrazione tramite Windows è progettato per essere trasparente ai driver di dispositivo. Il driver dovrebbe essere in grado di interagire con i relativi metodi ACPI come se un PEP non fosse in uso.

Quando si usa PEP per entrambi i servizi DPM (Device Power Management) e ACPI, è consigliabile usare handle PEP separati, ma si tratta solo di una questione di preferenza. Quando si condivide lo stato DPM e ACPI, è possibile tenere traccia facilmente per un dispositivo perché l'handle è lo stesso. Tuttavia, gestire la gestione della durata è un po 'più complicato. Il PEP dovrà fornire il conteggio dei riferimenti per l'handle per assicurarsi che sia eliminato solo dopo che i servizi DPM e ACPI sono stati rimossi per tale handle (ad esempio, sia PEP_DPM_UNREGISTER_DEVICE che PEP_NOTIFY_ACPI_UNREGISTER_DEVICE sono stati ricevuti su tale handle). Quando vengono usati handle diversi, lo stato DPM e ACPI verranno monitorati separatamente, ma la gestione della durata dell'handle è più semplice. In questo caso, l'handle può essere eliminato quando viene inviata la notifica di annullamento della registrazione corrispondente.

Per semplificare il processo di utilizzo delle risorse ACPI, il framework di risparmio energia (PoFx) fornisce la routine helper di PEP_REQUEST_COMMON_ACPI_CONVERT_TO_BIOS_RESOURCES per convertire le risorse ACPI in risorse BIOS.

I PEP sono responsabili della pianificazione del lavoro che non possono essere eseguiti in modo sincrono in risposta a una notifica ACPI da PoFx, ma il metodo usato è determinato dallo sviluppatore PEP. In genere, il PEP accoderà il lavoro in una coda interna e quindi avvia un thread di lavoro se necessario. È anche possibile che il lavoro debba attendere un evento esterno (ad esempio l'interruzione del dispositivo) e verrà elaborato nel contesto di tale evento. Al termine del lavoro, un PEP può richiedere a PoFx di eseguire una query per il lavoro richiamando PEP_KERNEL_INFORMATION_STRUCT_V3-RequestWorker>(). In risposta, PoFx invierà una notifica PEP_DPM_WORK per i PEP che implementano il gestore di notifica DPM (AcceptDeviceNotification) o una notifica PEP_NOTIFY_ACPI_WORK per i PEP che implementano il gestore di notifica solo ACPI (AcceptAcpiNotification).

Argomenti correlati

Tabelle di descrizione del sistema ACPI
PEP_DPM_UNREGISTER_DEVICE
PEP_NOTIFY_ACPI_UNREGISTER_DEVICE
PEP_KERNEL_INFORMATION_STRUCT_V3
PEP_DPM_WORK
PEP_NOTIFY_ACPI_WORK
RequestWorker
AcceptDeviceNotification
Notifiche ACPI