I do not know exactly the KMDF’s DMA profiles, but I think they are direct
wrappers around the old NT DEVICE_DESCRIPTION structure.
The same DEVICE_DESCRIPTION can be used for all OSes, you do not need to
query the OS capabilities or even use #ifdefs for 64bit compile when you fill
DEVICE_DESCRIPTION.
DEVICE_DESCRIPTION is filled before asking the OS/driver below you to
create a DMA adapter object for you, and describes the limitations your driver
wants to be imposed on this DMA adapter object.
The DEVICE_DESCRIPTION::Dma64BitAddresses field governs whether the DMA
adapter will be allowed to provide your driver with PHYSICAL_ADDRESS values >=
4GB.
If Dma64BitAddresses is FALSE - then the DMA adapter is prohibited from
presenting your driver with PHYSICAL_ADDRESS >= 4GB. All PHYSICAL_ADDRESS
values will be < 4GB, and your driver may rely on this and, say, use 32 bits
for them. But this has its cost - namely, the bounce buffer is used if the
actual PHYSICAL_ADDRESS of some pages of some MDL is >= 4GB.
If Dma64BitAddresses is TRUE - then the DMA adapter is allowed to present
your driver with PHYSICAL_ADDRESS >= 4GB, and your driver - and also your
hardware - must support this, which means support for PHYSICAL_ADDRESS not
fitting to 32 bits.
On some OSes, Dma64BitAddresses can have no effect at all.
First, 32bit OSes without PAE - all physical addresses are 32bit there.
Second, 32bit client OSes with PAE - MS added an artificial limitation to them
to enforce all physical addresses to fit 32bit, at the cost of not seeing the
RAM > 3.2GB or so (4GB minus the chipset aperture for 32bit PCI devices). So,
on these OSes, all physical addresses are 32bit.
But on 64bit OSes, Dma64BitAddresses really works. Anyway it is filled
based on your driver and hardware capabilities (can your DMA hardware work with
addresses not fitting to 32bit or not?), and not based on the OS - the OS will
ignore it if all physical addresses fit to 32bit.
So, if your driver and your hardware feel OK about 64bit physical addresses
in common buffers and scatter-gather lists, addresses not fitting 32 bits -
then set Dma64BitAddresses to TRUE on any OS. If the OS itself supports such
addresses - then it will provide you with them.
As about the transaction length limits. This seems to be the limit on
bounce buffer size, and I expect that, if Dma64BitAddresses is TRUE, there will
be no bounce buffers and thus the size limit will be relaxed a lot.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> We’re now developing a driver for an accleration card using KMDF. The device
uses the DMA to transfer data.It is capable of 64-bit addressing, but it
supports only one DMA transfer per transaction.
>
> We found that on a specific platform intel 5000P, the maximum data size for a
single trasnfer is limited to 0xF000 bytes which is much less than we
required(We got this number by calling the WdfDmaEnablerGetFragmentLength()).
We also found that if we use the WdfDmaProfileScatterGather64 instead of
WdfDmaProfileScatterGather on that platform, the maximum transfer length would
be much larger(meets our requirement).
>
> So would anyone please tell me can I use the 64-bit addressing DMA(or using
the WdfDmaProfileScatterGather64 profile) on a 32-bit windows? (p.s. our device
support 64-bit addressing).
>
> Thank you!
>