Windows WDM设备驱动电源管理参考代码

需积分: 9 84 浏览量更新于2024-07-15 收藏 166KB PDF 举报

"驱动程序电源管理处理完整参考代码.pdf" 本文档主要介绍Windows WDM（Windows Driver Model）设备驱动程序中的电源管理，并提供了一个详细的、完整的源代码示例，适用于处理电源事件。WDM电源管理是Windows操作系统中管理硬件设备能耗的关键机制，尤其在USB（通用串行总线）设备中显得尤为重要。它涉及到IRP（I/O请求包）的特定类型，如IRP_MJ_POWER和IRP_MN_SET_POWER，这些IRP用于控制设备的电源状态。首先，WDM架构下的电源管理目标是确保系统在节能和性能之间找到平衡。驱动程序需要能够响应系统的电源状态变化，例如当系统进入休眠模式时，降低设备功耗，或者在系统恢复时迅速恢复正常工作状态。这通常涉及到处理电源策略，包括设备的D0（全功率）到D3（最小功率）的不同电源状态。文档作者Kosta Koeman强调，理解WDM电源管理要求读者具备编写WDM USB驱动程序的经验，并熟悉USB总线分析工具，如CATC的CTM产品线。文档中可能涵盖了如何使用这些工具来调试和优化电源管理代码。在USB设备的上下文中，电源管理特别关键，因为USB设备通常需要在主机系统中进行动态电源切换，以节省能源。例如，当设备不活动时，驱动程序应能将设备设置为低功耗模式（如D2或D3状态），并在需要时快速恢复到工作状态（D0）。这涉及到处理IRP_MN_SET_POWER请求，该请求指示驱动程序改变设备的电源状态。文档的贡献者包括来自Intel、Cypress Semiconductor、Lexar Media Inc.和Walter Oney Software的专家，他们的反馈和信息改进了文档的内容。文档的1.1版还包含了针对Windows 98 Millennium Edition的更新和代码增强，以确保兼容性和性能。在实际开发过程中，开发者需要理解如何正确处理电源IRP，包括正确设置设备的电源状态、处理中断和同步问题，以及遵循系统电源策略。此外，为了确保设备在不同电源状态下行为一致，还需要进行详尽的测试。这份"Understanding WDM Power Management"白皮书为驱动程序开发者提供了一份宝贵的资源，帮助他们实现高效且合规的电源管理代码，从而在保持设备功能的同时最大限度地减少能源消耗。通过深入理解和应用文中的概念和示例代码，开发者可以构建更稳定、更节能的WDM驱动程序。

Kosta Koeman 13

Intel Architecture Labs

The Four Power IRP Minor Functions

There are four power IRP codes, as shown in the table below, may be generated by either

the power manager [10], the device driver [11] or both. Only the device driver may generate the

two optional IRPs, power sequence [12] and wait/wake [13]. The device driver may also

generate set power and query power IRPs, but only of with of device type, not system. The

power manager will generally generate only the system query power and set system power IRPs

to control system power. However, if a driver registers for idle detection via the

PoRegisterDeviceForIdleDetection()

[14], then the power manager will issue a set device power

IRP if the device has not called

PoSetDeviceBusy()

[15] within the maximum idle time.

Minor IRP Code Optional/Required Generated By

IRP_MN_POWER_SEQUENCE Optional Device

IRP_MN_QUERY_POWER (System) Required Power Manager

IRP_MN_QUERY_POWER (Device) Required Both

IRP_MN_SET_POWER (Device) Required Both

IRP_MN_SET_POWER (System) Required Power Manager

IRP_MN_WAIT_WAKE Optional Device

Table 4.

Minor Function Power IRP Codes

IRP_MN_POWER_SEQUENCE

This optional IRP is used for optimizing device state change processing. The device

driver generates this IRP to determine the number of times the device has entered the different

device power states, possibly keeping track by storing this information in the device extension.

This paper defers to reader to [12] for more information.

IRP_MN_QUERY_POWER

In general, the power manager is the policy owner of this minor IRP code [16].

However, a device driver may generate this IRP as well. The power manager uses this IRP to

request approval from all device drivers for the system to enter a specific sleep state. This IRP is

not sent when powering up the system (always to

) or under critical situations where system

power is about to be lost. If the system wishes to change sleep states, the system will first power

up to

, and then go into the other low power state.

The rest of this section focuses on advising on the driver’s policy for handling suspend to

through

requests. All devices must accept system power requests to

and

. It should

be noted that when a system is shut down, the OS might not issue a query IRP before a set

system power IRP.

When the operating systems issues a query IRP to enter

, the device driver has

two options when transmitting data: reject the IRP, thus preventing the system from entering that

sleep state; or stop all data transmissions, queue up further data transmitting IRPs, and pass down

Kosta Koeman 14

Intel Architecture Labs

the query IRP down the stack. If idle, the device driver must perform the latter option to allow

the system to enter the sleep state.

In some cases, the vendor may wish to provide the consumer the option of which choice

the driver makes whenever the preferred option is not obvious. This can be done by the device

driver’s corresponding application toggling a registry value that is read by the device driver.

Cases in which the vendor may wish to grant the consumer this option may include

scanners, video cameras, even mass storage devices, and other devices transmitting non-critical

data. Upon system resume, a well-written device driver would be capable of completing a file

transfer, completing the scan, resume video transfer, or whatever task it had before the system

entered the sleep state.

Cases in which the device driver should reject the system’s request enter a sleep state are

those in which data would be lost or corrupted. The best examples of this case are printers (print

job may be ruined by stopping/resuming) and communication devices, such as modems, that are

transmitting data (as opposed to maintaining a connection). Communication devices that are

simply maintaining a connection should allow the system to enter a suspend state and cause a

remote wakeup event whenever actual data is received.

Ultimately, vendors know their customers best and must decide what is the

suspend-

while-transmitting

policy and if it is appropriate to provide their customers the option of

changing that policy. The following source code provides the flexibility of having consumer

preferences dictate the policy regarding suspend while the device is transmitting data.

NTSTATUS

DispatchPower(

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp

)

{

PDEVICE_EXTENSION deviceExtension = DeviceObject->DeviceExtension;

PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);

NTSTATUS ntStatus = STATUS_SUCCESS;

KdPrint(("DispatchPower() IRP_MJ_POWER\n"));

switch (irpStack->MinorFunction)

{

case IRP_MN_QUERY_POWER:

if (irpStack->Parameters.Power.Type == SystemPowerState)

{

HandleSystemQueryIrp(DeviceObject, Irp);

}

else if (irpStack->Parameters.Power.Type == DevicePowerState)

{

HandleDeviceQueryIrp(DeviceObject, Irp);

}

break;

Sample Code 4.

IRP_MN_QUERY_POWER

Kosta Koeman 15

Intel Architecture Labs

NTSTATUS

HandleSystemQueryIrp(

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp

)

{

PDEVICE_EXTENSION deviceExtension = DeviceObject->DeviceExtension;

PIO_STACK_LOCATION irpStack = IoGetCurrentIrpStackLocation(Irp);

NTSTATUS ntStatus = STATUS_SUCCESS;

BOOLEAN fNoCompletionRoutine = FALSE;

BOOLEAN fPassDownIrp = TRUE;

KdPrint(("==========================================\n"));

KdPrint(("Power() IRP_MN_QUERY_POWER to %s\n",

SystemPowerStateString[irpStack->Parameters.Power.State.SystemState]));

// first determine if we are transmitting data

if (deviceExtension->ulOutStandingIrps > 0)

{

BOOLEAN fOptionDetermined = FALSE;

ULONG ulStopDataTransmissionOnSuspend = 1;

BOOLEAN fTransmittingCritialData = FALSE;

// determine if driver should stop transmitting data

fOptionDetermined = (BOOLEAN)GetRegistryDword(&gRegistryPath,

L"StopDataTransmissionOnSuspend",

&ulStopDataTransmissionOnSuspend);

// Note COMPANY_X_PRODUCT_Y_REGISTRY_PATH is the absolute registry path

// which would be defined as: L"\\REGISTRY\\Machine\\System…

// …\\CurrentControlSet\\Services\\COMPANY_X\\PRODUCT_Y and corresponds

// to the following section in the registry (created by an .inf file or

// installation routine): HKLM\\System\\CurrentControlSet\\Services…

// …\\COMPANY_X\\PRODUCT_Y which would contain the DWORD entry

// StopDataTransmissionOnSuspend

if (ulStopDataTransmissionOnSuspend ||

!fOptionDetermined ||

irpStack->Parameters.Power.State.SystemState == PowerSystemShutdown)

// stop data transmission if the option was set to do so or if the

// option could not be read or if the system is entering S5

{

// Set a flag used to queue up incoming irps

deviceExtension->PowerTransitionPending = TRUE;

// attach a completion routine to wait for

IoCopyCurrentIrpStackLocationToNext(Irp);

IoSetCompletionRoutine(Irp,

PoSystemQueryCompletionRoutine,

DeviceObject,

TRUE,

TRUE);

fNoCompletionRoutine = FALSE;

}

else

fPassDownIrp = FALSE;

}

ntStatus = PassDownPowerIrp(DeviceObject, Irp, fPassDownIrp, fNoCompletionRoutine);

return ntStatus;

}

Sample Code 5.

Handle System Query Irps routine

Kosta Koeman 16

Intel Architecture Labs

The following section of code provides a generic routine that reads the specified

DWORD value from the designated registry path.

BOOLEAN

Usb_GetRegistryDword(

IN PWCHAR RegPath,

IN PWCHAR ValueName,

IN OUT PULONG Value

)

{

UNICODE_STRING path;

RTL_QUERY_REGISTRY_TABLE paramTable[2]; //zero'd second table terminates parms

ULONG lDef = *Value; // default

NTSTATUS status;

BOOLEAN fres;

WCHAR wbuf[ MAXIMUM_FILENAME_LENGTH ];

path.Length = 0;

path.MaximumLength = MAXIMUM_FILENAME_LENGTH * sizeof( WCHAR );

// MAXIMUM_FILENAME_LENGTH defined in wdm.h

path.Buffer = wbuf;

RtlZeroMemory(path.Buffer, path.MaximumLength);

RtlMoveMemory(path.Buffer, RegPath, wcslen( RegPath) * sizeof( WCHAR ));

RtlZeroMemory(paramTable, sizeof(paramTable));

paramTable[0].Flags = RTL_QUERY_REGISTRY_DIRECT;

paramTable[0].Name = ValueName;

paramTable[0].EntryContext = Value;

paramTable[0].DefaultType = REG_DWORD;

paramTable[0].DefaultData = &lDef;

paramTable[0].DefaultLength = sizeof(ULONG);

status = RtlQueryRegistryValues(RTL_REGISTRY_ABSOLUTE | RTL_REGISTRY_OPTIONAL,

path.Buffer, paramTable, NULL, NULL);

fres = (NT_SUCCESS(status)) ? TRUE : FALSE;

return fres;

}

Sample Code 6.

Reading a DWORD entry from the registry

The author has noted in some driver writing books the reader is instructed to set the IRP

status to STATUS_SUCCESS, call

PoStartNexPowerIRP

(), and then complete the IRP with a

call to

IoCompleteRequest

(). This is incorrect since this does not allow other devices in the stack

to respond to this IRP.

According to the DDK documentation [17], the driver has the option of failing this IRP if

one of the following conditions is true:

•

The device is enabled for remote wakeup (i.e., has a wait/wake IRP pending), but the

system state is lower in which the device supports remote wakeup (as indicated in the

device capabilities). For this reason, the author recommends canceling pending

wait/wake IRPs on system resume, and for system suspend, generate a fresh wait/wake

IRP only if the device is capable of waking the system from that suspend state.

•

Going into the sleep state will cause a loss of data (DDK example: modem loses

connection). The application often will handle this situation.

剩余75页未读，继续阅读

danxuezx

粉丝: 273
资源: 82

Windows WDM设备驱动电源管理参考代码

Windows 驱动程序示例.pdf

ucosWiFi网卡驱动程序的开发.pdf

stm8l15x中文参考手册.pdf

imx6ull中文参考手册.pdf

linux设备驱动程序 第三版 pdf

acpi_6_0_errata_a.pdf

dwc_pcie_ctl_ep_reference.pdf

rockchip_developer_guide_linux_wifi_bt_cn.pdf

t630_usb3.0超高速控制器技术手册.pdf

rk808-d 开发指pdf

最新资源

linux设备驱动程序第三版 pdf