Finding and Mapping Hardware Resources
This topic describes how a Kernel-Mode Driver Framework (KMDF) driver or User-Mode Driver Framework (UMDF) driver starting in version 2 maps a translated memory resource (CmResourceTypeMemory) that it receives in its EvtDevicePrepareHardware callback function.
A UMDF 1.x driver can also receive this type of resource in its IPnpCallbackHardware2::OnPrepareHardware method. For more info, see Finding and Mapping Hardware Resources in UMDF 1.x Drivers.
Your driver receives raw and translated versions of hardware resources in the device's resource list in its EvtDevicePrepareHardware callback function. The driver can save the resource list, which is valid until the framework calls the driver's EvtDeviceReleaseHardware callback function.
Typically, the driver calls WdfCmResourceListGetCount from its EvtDevicePrepareHardware callback function to determine the number of resource descriptors in the translated resource list, and then calls WdfCmResourceListGetDescriptor in a loop to identify memory-mapped registers, I/O ports, and interrupts.
If a driver is assigned a translated memory resource (CmResourceTypeMemory), it must map the physical address into an address through which it can access device registers.
A UMDF driver calls WdfDeviceMapIoSpace to map the physical address to a pseudo base address that it can use in conjunction with WDF Register/Port Access Functions to read and write to registers and ports.
You do not need to map resources in I/O space (CmResourceTypePort, CmResourceTypeInterrupt, CmResourceTypeDma).
If your UMDF driver calls WdfDeviceMapIoSpace, you must set the UmdfDirectHardwareAccess INF directive to AllowDirectHardwareAccess.
For an example that shows how a driver finds and maps memory-mapped register resources, see Reading and Writing to Device Registers.