Condividi tramite

Uso di PEP per i servizi ACPI

In questo argomento vengono fornite informazioni sull'uso di plug-in di estensione della piattaforma (PEP) 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 in tempo reale invece del firmware ACPI che richiede un flash del firmware. Ciò significa che è possibile migliorare il codice di risparmio energia sulle piattaforme già spedite pubblicando un driver aggiornato in Windows Update. Il risparmio energia è stato lo scopo 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 degli spazi dei nomi ACPI perché la gerarchia degli spazi 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.

Fornire la gestione dell'alimentazione tramite il PEP può essere molto più semplice da eseguire il debug rispetto al codice scritto per il firmware ACPI grazie agli strumenti disponibili. Gli strumenti per il debug del firmware ACPI sono sconosciuti alla maggior parte delle persone e le opzioni degli strumenti sono limitate. Al contrario, i PEP vengono sviluppati come driver di Windows in modo che gli sviluppatori possano usare qualsiasi strumento di sviluppo e debug con cui sono più familiari.

Quando si utilizza un PEP al posto di un servizio ACPI, non è necessaria alcuna azione o operazione speciale per rivendicare 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 per i driver di dispositivo. Il driver dovrebbe aspettarsi di poter interagire con i 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 questa è solo una questione di preferenza. Quando si condivide l'handle, lo stato DPM e ACPI possono essere facilmente tracciati per un dispositivo perché l'handle è lo stesso. Tuttavia, la gestione della durata è un po' più complicata. Il PEP dovrà fornire un conteggio di riferimenti per l'handle per garantire che venga eliminato solo dopo che i servizi DPM e ACPI sono stati rimossi per l'handle stesso (ovvero, dopo che entrambi i segnali PEP_DPM_UNREGISTER_DEVICE e PEP_NOTIFY_ACPI_UNREGISTER_DEVICE sono stati ricevuti su tale handle). Quando vengono utilizzati handle diversi, lo stato DPM e ACPI verrà monitorato separatamente, ma la gestione della durata degli handle è più semplice. In questo caso, l'handle può essere eliminato definitivamente 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 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 può essere eseguito 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 avvierà un thread di lavoro, se necessario. È anche possibile che il lavoro debba attendere alcuni eventi esterni (ad esempio l'interrupt del dispositivo) e che verranno elaborati 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 di PEP_DPM_WORK per i PEP che implementano il gestore di notifica DPM (AcceptDeviceNotification) o un PEP_NOTIFY_ACPI_WORK notifica per i PEP che implementano il gestore di notifica solo ACPI (AcceptAcpiNotification).

tabelle di descrizione del sistema ACPI
Notifiche sulla gestione dell'alimentazione dei dispositivi (DPM)
PEP_DPM_UNREGISTER_DEVICEPEP_NOTIFY_ACPI_UNREGISTER_DEVICEPEP_KERNEL_INFORMATION_STRUCT_V3
RequestWorker
AccettaNotificaDispositivo
notifiche ACPI