Re[2]: problems with DMA transfer with size > 4k

> Isn’t a common buffer allocated from the non-paged pool? If so, you have to

be careful with how large a buffer you allocate. Mapping it back to the
user program sounds like a bad idea. I would think you want to copy it to
the users buffer before completing the IRP.

Copying to the users buffer is good for low data rates but not when
data rates are very large.

Rob
xxxxx@telusplanet.net

At 10:06 AM 1/16/2004 -0700, you wrote:

> Isn’t a common buffer allocated from the non-paged pool? If so, you have to
> be careful with how large a buffer you allocate. Mapping it back to the
> user program sounds like a bad idea. I would think you want to copy it to
> the users buffer before completing the IRP.

Copying to the users buffer is good for low data rates but not when
data rates are very large.

True, but if the hardware doesn’t support scatter/gather, you already have
a performance headache to deal with. You could, as previously suggested,
use multiple buffers with a round-robin approach.

If the DMA is large, then using a kernel allocated common buffer for all of
it will run into resource problems anyway.

Russ Poffenberger
NPTest, Inc.
xxxxx@NPTest.com

You can either interrupt in the end of the page and set the next page in
the ISR, or use the double-buffering. The latter will be done automatically by
Windows adapter object, just create it properly.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Daniel Luethi”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, January 16, 2004 3:44 PM
Subject: [ntdev] problems with DMA transfer with size > 4k

> Hi there
>
> I’v got to write a WDM driver for a PCI card which is bus master capable
> but not scatter/gather. I try to follow the DMA suggestions in the
> driver books and I actually could lounge a transfer but just with a size
> less than one page. As soon as the size is bigger then one page the data
> I observe with a PCI snooper is actually sometimes the data which I
> wrote on the last DMA transfer with size under or equal to one page size
> (???). But not just the data on the secound page, oddly the whole data
> package is not the one it should be! I suspect it has to do with the map
> registers. I’m working on a x86 XP system. Could it be that on this
> system I can make no bigger DMA transfer than one page size? Would be a
> shame!
>
> Thanks for help
> Daniel
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> First suggestion is to place the toe of your boot, while moving at a

prodigious speed, firmly in the ass of the “designer” that chose or designed
the card.

BTW - the AC97 sound logic is IIRC the same - a single address/length pair in
their DMA engine.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> Copying to the users buffer is good for low data rates but not when

data rates are very large.

For large data rate, he has no choice but re-design the card.

For lower (like audio) data rates, he can, for instance, use the interrupt in
the end of each chunk and switch to next contiguous chunk in the ISR. From what
I know, AC97 works this way.

Another way is double buffering which is employed by setting ScatterGather to
FALSE at IoGetDmaAdapter time. Then the adapter object will memcpy() the data
for him, and his device will always have a physically contiguous chunk per each
IRP.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com