ACX-Energieverwaltung

Artikel
06/25/2024

In diesem Thema wird die ACX-Energieverwaltung erläutert. Informationen zur ACX-Geräteenumeration, zum Starten und Herunterfahren sowie zur Geräteneuausgleich finden Sie unter ACX-Geräteenumeration. Eine allgemeine Übersicht über ACX finden Sie in der Übersicht über ACX-Audioklassenerweiterungen.

ACX nutzt das WDF-PnP-Leistungsverhalten. Weitere Informationen zu KMDF-Energieverwaltungssequenzen finden Sie unter Rückrufsequenzen für PnP- und Energieverwaltung.

Es wird empfohlen, dass ACX-Treiber die WDF-Energieverwaltung vollständig implementieren, z. B. durch Implementieren der WDF_PNPPOWER_EVENT_CALLBACKS-Struktur. Weitere Informationen finden Sie unter Unterstützen von PnP und Energieverwaltung in Ihrem Treiber.

Überraschendes Entfernen von ACX-Geräten

Das WDF-Framework kann evtDeviceSurpriseRemoval jederzeit aufrufen, was bedeutet, dass dieser Rückruf nicht mit der Sequenz zum Herunterfahren serialisiert wird. Der WDF-Treiber sollte beim Empfang dieses Rückrufs nichts weiter tun, als zur Kenntnis zu nehmen, dass das Gerät überraschend entfernt wurde.

Die Rückrufsequenz für das überraschende Entfernen beim Herunterfahren ist identisch mit den Fällen für das Herunterfahren von Dx und Entfernen. WDF ruft die folgenden Rückrufe nicht auf dem Pfad des überraschenden Entfernens auf:

EvtDeviceArmWakeFrom*, wie EvtDeviceArmWakeFromS0
EvtIoStop (Löschen von energieverwalteten Warteschlangen) EvtWdfIoQueueIoStop
EvtDeviceSelfManagedIoFlush (E/A-Puffer leeren)

Weitere Informationen finden Sie unter PnP- und Energieverwaltungs-Rückrufsequenzen und Verwenden von energieverwalteten E/A-Warteschlangen.

Hochfahren/Start des ACX-Schaltkreises

Ein „dynamischer“ AcxCircuit kann jederzeit hinzugefügt werden. Der Treiber erstellt ein neues untergeordnetes PDO-Gerät und ordnet den neuen AcxCircuit bei der Behandlung des WDF-PrepareHardware-Rückrufs für dieses PDO-Gerät zu. Die Lebensdauer eines „dynamischen“ Schaltkreises ist nicht an die Lebensdauer des FDO gebunden.

Ein „statischer“ AcxCircuit kann nur hinzugefügt werden, wenn der Treiber den WDF-PrepareHardware-Rückruf für sein FDO-Gerät verarbeitet. Die Lebensdauer eines „statischen“ Schaltkreises ist an die Lebensdauer des FDO gebunden.

Ein ACX-Treiber kann auch AcxFactoryCircuit-Objekte (Schaltkreisanbieter) während der Sequenz zum Hochfahren mithilfe der AcxFactoryCircuitCreate-Funktion erstellen. Ein AcxFactoryCircuit-Objekt verwendet dynamische Schaltkreiserstellung zum Hinzufügen von ACXCIRCUITS, wenn von ACX angefordert. Dieses Feature ist sehr nützlich beim Erstellen zusammengesetzter Endpunkte, d. h. des Audioendpunkts, der aus zwei oder mehr ACXCIRCUITs besteht.

Der ACX-Schaltkreis definiert die folgenden Rückrufe, die während der AcxCircuit/Audio-Endpunktinitialisierung aufgerufen werden:

EvtAcxCircuitPrepareHardware: ACX ruft diesen Rückruf auf, kurz nachdem WDFseinen WDF-PrepareHardware-Rückruf abgesetzt hat. Dadurch hat der Treiber die Möglichkeit, alle für den Schaltkreis spezifischen Hardwarevorbereitungsvorgänge durchzuführen. Dieser Aufruf wird von ACX serialisiert. Das Gerät befindet sich nicht in D0, wenn dieser Aufruf aufgerufen wird.
EvtAcxCircuitPowerUp: ACX ruft diesen Rückruf direkt nach dem Zurückkehren von Dx auf. Dieser Aufruf wird von ACX serialisiert. Das Gerät befindet sich in D0.

Für zusammengesetzte Endpunkte kann sich AcxCircuits optional für diese Rückrufe registrieren:

EvtAcxCircuitCompositeCircuitInitialize, wird aufgerufen, wenn ACX erstmalig erkennt, dass dieses ACXCIRCUIT sichtbar ist, d. h., das zugeordnete Gerät wechselte in D0 und machte diesen Schaltkreis für Entitäten außerhalb seines eigenen Stapels sichtbar. Die Audioschnittstellen des Schaltkreises befinden sich weiterhin im OFF-Zustand.
EvtAcxCircuitCompositeInitialize, wird jedes Mal aufgerufen, wenn ACX den Init eines zusammengesetzten Endpunkts beendet. Nach diesem Rückruf aktiviert ACX die Audioschnittstellen dieses Schaltkreises.
EvtAcxCircuitCompositeDeinitialize, wird jedes Mal aufgerufen, wenn ACX einen zusammengesetzten Endpunkt beendet. Treiber erhalten diesen Rückruf möglicherweise nicht, wenn ihr eigener Stack überraschend entfernt wurde oder E/A nicht verarbeitet werden kann.

Falls vorhanden, werden Datenstrominstanzen in ihren Zuständen vor dem Herunterfahren wiederhergestellt.

Herunterfahren und Entfernen des ACX-Schaltkreises

Ein „dynamischer“ AcxCircuit kann jederzeit entfernt werden, indem die Gültigkeit des dem Schaltkreis zugeordneten Geräteobjekts aufgehoben wird und es entfernt wird. Der zugeordnete Schaltkreis kann vom entfernten Gerät entfernt/getrennt werden, wenn der Treiber die WDF-PrepareHardware/ReleaseHardware-Rückrufe für dieses PDO-Gerät verarbeitet. Wie bereits erwähnt, ist die Lebensdauer eines „dynamischen“ Schaltkreises nicht an die Lebensdauer des FDO gebunden.

Ein „statischer“ AcxCircuit kann nur entfernt werden, wenn der Treiber die WDF-PrepareHardware/ReleaseHardware-Rückrufe für sein FDO-Gerät verarbeitet. Die Lebensdauer eines „statischen“ Schaltkreises ist an die Lebensdauer des FDO gebunden.

Der Treiber kann einen AcxFactoryCircuit (Schaltkreisanbieter) in seinen WDF-PrepareHardware/ReleaseHardware-Rückrufen entfernen. Durch das Entfernen eines AcxFactoryCircuit werden auch alle zugehörigen „dynamischen“ AcxCircuit(s) entfernt. AcxCircuit(s) können auch entfernt werden, wenn der ACX-Manager eine Schaltkreis-Factory anweist, einen bestimmten Schaltkreis zu entfernen, oder wenn der ACX-Manager seine AcxFactoryCircuit-Handles schließt. In diesem Szenario schließt ACX alle mit diesem Handle verbundenen Schaltkreise.

Die ACX_CIRCUIT_PNPPOWER_CALLBACKS-Struktur beschreibt die folgenden Rückrufe, die von einem ACX-Treiber verwendet werden können.

EvtAcxCircuitPowerDown: ACX ruft diesen Rückruf direkt vor dem Wechsel in Sx/Dx/Stop/Removal/SurpriseRemoval auf und wenn der Treiber den Schaltkreis entfernt. Dieser Aufruf wird von ACX serialisiert. Das Gerät befindet sich in D0, bedenken Sie jedoch, dass das Gerät jederzeit überraschend entfernt werden könnte (was bedeutet, dass die zugeordnete Hardware nicht mehr vorhanden ist).
EvtAcxCircuitReleaseHardware: ACX ruft diesen Rückruf direkt vor dem WDF-Release-Hardwarerückruf auf. Es gibt dem Treiber die Möglichkeit, alle Bereinigungsvorgänge auszuführen, während der Schaltkreis noch aktiv ist. Dieser Aufruf wird von ACX serialisiert. Das Gerät befindet sich nicht in D0, wenn dieser Aufruf aufgerufen wird.
EvtWdfObjectContextCleanup: WDF ruft diesen Rückruf auf, wenn das WDF/ACX-Objekt gelöscht wird. Dieser Aufruf ist synchron mit dem Löschen des WDF-Objektaufrufs. Das Gerät befindet sich möglicherweise nicht in D0, wenn dieser Aufruf aufgerufen wird. Der Rückruf wird auf passiver Ebene ausgeführt.
EvtWdfObjectContextDestory: WDF ruft diesen Rückruf nach dem letzten Verweis für dieses Objekt auf. Dieser Aufruf ist asynchron mit dem Löschen des WDF-Objektaufrufs. Das Gerät befindet sich möglicherweise nicht in D0, wenn dieser Aufruf aufgerufen wird. Dieser Rückruf wird erst aufgerufen, nachdem der letzte Verweis auf das Objekt entfernt wurde. Der Rückruf wird auf der <= DPC-Ebene ausgeführt. Die genaue IRQL hängt von der IRQL des Threads ab, der die letzte Referenz veröffentlicht.

Verwaltung von ACX-Geräten im Leerlauf

ACX nutzt die WDF-Leerlauf-Verwaltungsinfrastruktur. ACX-Treiber verwenden die folgenden WDF-DDIs, um die Leerlaufverwaltung zu aktivieren:

WdfDeviceAssignS0Idle Einstellungen: Dieser Aufruf gibt den Typ der Leerlauftimeout- und Leerlaufverwaltung an. Der ACX-Treiber kann die entsprechende Einstellung für sein Gerät verwenden.
WdfDeviceStopIdle: Dieser Aufruf verhindert, dass das Gerät in den Leerlauf wechselt. Beachten Sie, dass durch seinen Aufruf die Sx-Anforderungen nicht blockiert werden. Das heißt, das Gerät geht unabhängig von der Anzahl der aktiven Leistungsreferenzen in Dx, wenn das System in einen niedrigeren Leistungszustand übergeht.
WdfDeviceResumeIdle: Mit diesem Aufruf kann das Gerät das Leerlauftimeout neu starten.

In einem Szenario mit mehreren Stacks/Schaltkreisen können verschiedene Stacks unterschiedliche Leerlauftimeouts aufweisen. Dies liegt an den unterschiedlichen Energieeinstellungen/Anforderungen jedes Stapels, sodass unterschiedliche Leerlauftimeouts geeignet sind. Allgemeine Informationen zum Multistapel finden Sie unter Treiberübergreifende ACX Multi-Stack-Kommunikationen.

ACX-Treiber und energieverwaltete Warteschlangen

WDF unterstützt energieverwaltete E/A-Warteschlangen. Diese Art von Warteschlange ist vollständig in die WDF-Energieverwaltung integriert. WDF ruft die Rückrufe der Warteschlange bei verschiedenen Schritten in der WDF-Sequenz zum Hochfahren/Herunterfahren der Warteschlange auf. Weitere Informationen finden Sie unter Verwenden von energieverwalteten E/A-Warteschlangen.

ACX-Treiber können diese Art von Warteschlange nur verwenden, wenn der Treiber nicht die Einzel-/Multikomponente mit dem Multi-State-Feature (Fx) verwendet.

ACX-Treiber und D3Hot /D3Cold (D3)-Zustände

Audiotreiber wissen, wann sie in D3Hot oder D3Cold wechseln, basierend auf den Informationen, die in der ACX_DX_EXIT_LATENCY Enumeration verfügbar sind.

typedef enum _ACX_DX_EXIT_LATENCY { 
  AcxDxExitLatencyInstant     = 0,
  AcxDxExitLatencyFast,
  AcxDxExitLatencyResponsive
} ACX_DX_EXIT_LATENCY;

AcxDxExitLatencyFast entspricht D3Hot (DSP on) und AcxDxExitLatencyResponsive entspricht D3Cold (DSP off).

Audiotreiber können den ACX_DX_EXIT_LATENCY-Wert abrufen, indem die AcxDeviceGetCurrentDxExitLatency-Funktion aufgerufen wird.

WDF kennt die D3Cold-Funktionen des Treibers über das ExcludeD3Cold-Feld des WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS. Der Treiber übergibt diese Struktur als Eingabe an die WdfDeviceAssignS0IdleSettings.

WDF-Treiber können die WdfDeviceAssignS0IdleSettings mehrmals aufrufen, um D3Cold abhängig von der Systemumgebung, d. h. als Reaktion auf ACX, zu aktivieren oder zu deaktivieren. Weitere Informationen finden Sie unter WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS-Struktur.

Energieverwaltungs-Framework (PoFx) und vom Treiber verwalteter Leerlauftimeout

Energieverwaltung auf Komponentenebene

Beachten Sie, dass WDF Fx-Geräte-/Komponentenzustände nicht direkt unterstützt. Um diese Zustände zu verwenden, muss der Treiber ein vom Treiber verwaltetes Leerlauftimeout verwenden. Weitere Informationen zur Verwendung von Fx-Gerätekomponentenzuständen und vom Treiber verwalteten Leerlauftimeouts finden Sie in den folgenden Themen.

Energieverwaltungs-Framework (PoFx)

Windows bietet ein Laufzeit-Energieverwaltungs-Framework (PoFx), das die Energieverwaltung auf Komponentenebene unterstützt. Eine Komponente oder ein Untergerät ist eine funktionale Hardwareeinheit in einem Gerät, die unabhängig von den anderen Komponenten desselben Geräts eingeschaltet oder in einen Energiesparzustand versetzt werden kann. Weitere Informationen finden Sie unter Übersicht über das Power Management Framework.