S
Shailesh Chaudhari
Hi All,
I know that this is not a recommended way - but I am forced to use this
after due deliberation.
Microsoft states: "Do not use MmAllocateContiguousMemorySpecifyCache to
allocate buffers for DMA and then call MmGetPhysicalAddress to translate the
returned virtual address to an address with which to program your DMA
controller. This approach does not work on all hardware, and your device and
driver will not be cross-platform compatible."
My query is what will not work? Any insight into what kind of hardware
specific or cross-platform incompatibilities or issues to expect here?
Is it that the behavior of this function can/has changed? and if yes what
part of behavior can really change across hardware or platforms?
Has anybody used this way of setting up DMA? I would expect this to work
just fine if your physical pages do not need
"map registers". For example for PCI DMA enabled cards on 32 bit machines
can address upto 4GB without needing "double buffering".
Thanks with best regards
ddkuser
I know that this is not a recommended way - but I am forced to use this
after due deliberation.
Microsoft states: "Do not use MmAllocateContiguousMemorySpecifyCache to
allocate buffers for DMA and then call MmGetPhysicalAddress to translate the
returned virtual address to an address with which to program your DMA
controller. This approach does not work on all hardware, and your device and
driver will not be cross-platform compatible."
My query is what will not work? Any insight into what kind of hardware
specific or cross-platform incompatibilities or issues to expect here?
Is it that the behavior of this function can/has changed? and if yes what
part of behavior can really change across hardware or platforms?
Has anybody used this way of setting up DMA? I would expect this to work
just fine if your physical pages do not need
"map registers". For example for PCI DMA enabled cards on 32 bit machines
can address upto 4GB without needing "double buffering".
Thanks with best regards
ddkuser