DMA common buffer and KMDF

NTDEV
1

Hi all.

I’m working on a driver that uses DMA with the common buffer approach (it’s
actually a number of common buffers).

The technique is more or less the one described in this blog entry

http://blogs.msdn.com/peterwie/archive/2006/03/09/546961.aspx

(section “Using Common Buffer to setup a continuous transfer”).

I’ve done it in the past in a couple WDM drivers (following the Oney’s). The
key point there was that I didn’t need to call MapTransfer and stuff because
I had the virtual address and physical address of the common buffer (the
devices were DMA bus-master capable).
With KMDF there’s something that worries me. The WDF book (page 568, chapter
17, “Example: Driver DMA initialization”) says “The driver now creates a
common buffer. It does this by calling WdfCommonBufferCreate, passing the
length in bytes of the required common buffer. The allocated common buffer
area is not necessary physically contiguous.”

Maybe I’m stupid, but I see a contradiction in this…

Thanks again
GV

2

Looking at the code it makes one call to WDM’s AllocateCommonBuffer under the covers so the buffer is contiguous.

Perhaps the book was trying to say that the buffer is logically contiguous, in that it occupies a contiguous address range within the device address space but that there may be systems in the world where that isn’t actually physically contiguous.

Still it seems confusing and perhaps over detailed. I’ll poke the writers about it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 2:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DMA common buffer and KMDF

Hi all.

I’m working on a driver that uses DMA with the common buffer approach (it’s
actually a number of common buffers).

The technique is more or less the one described in this blog entry

http://blogs.msdn.com/peterwie/archive/2006/03/09/546961.aspx

(section “Using Common Buffer to setup a continuous transfer”).

I’ve done it in the past in a couple WDM drivers (following the Oney’s). The
key point there was that I didn’t need to call MapTransfer and stuff because
I had the virtual address and physical address of the common buffer (the
devices were DMA bus-master capable).
With KMDF there’s something that worries me. The WDF book (page 568, chapter
17, “Example: Driver DMA initialization”) says “The driver now creates a
common buffer. It does this by calling WdfCommonBufferCreate, passing the
length in bytes of the required common buffer. The allocated common buffer
area is not necessary physically contiguous.”

Maybe I’m stupid, but I see a contradiction in this…

Thanks again
GV

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

This also means that I can safely use the virtual address returned by
WdfCommonBufferGetAlignedVirtualAddress and use it without the need to
create DMA transactions with WdfDmaTransactionCreate and so on (in the
continuous transfer approach you don’t really have such transactions from
the software point of view). Right?

Have a nice day
GV

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 22, 2007 3:56 PM
Subject: RE: [ntdev] DMA common buffer and KMDF

Looking at the code it makes one call to WDM’s AllocateCommonBuffer under
the covers so the buffer is contiguous.

Perhaps the book was trying to say that the buffer is logically contiguous,
in that it occupies a contiguous address range within the device address
space but that there may be systems in the world where that isn’t actually
physically contiguous.

Still it seems confusing and perhaps over detailed. I’ll poke the writers
about it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 2:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DMA common buffer and KMDF

Hi all.

I’m working on a driver that uses DMA with the common buffer approach (it’s
actually a number of common buffers).

The technique is more or less the one described in this blog entry

http://blogs.msdn.com/peterwie/archive/2006/03/09/546961.aspx

(section “Using Common Buffer to setup a continuous transfer”).

I’ve done it in the past in a couple WDM drivers (following the Oney’s). The
key point there was that I didn’t need to call MapTransfer and stuff because
I had the virtual address and physical address of the common buffer (the
devices were DMA bus-master capable).
With KMDF there’s something that worries me. The WDF book (page 568, chapter
17, “Example: Driver DMA initialization”) says “The driver now creates a
common buffer. It does this by calling WdfCommonBufferCreate, passing the
length in bytes of the required common buffer. The allocated common buffer
area is not necessary physically contiguous.”

Maybe I’m stupid, but I see a contradiction in this…

Thanks again
GV

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Yes. There aren’t any bounce buffers involved, so you can write to the VA and it should show up in the page the device sees (modulo caching, processor pipeline flushing, etc…)

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 4:27 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DMA common buffer and KMDF

This also means that I can safely use the virtual address returned by
WdfCommonBufferGetAlignedVirtualAddress and use it without the need to
create DMA transactions with WdfDmaTransactionCreate and so on (in the
continuous transfer approach you don’t really have such transactions from
the software point of view). Right?

Have a nice day
GV

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 22, 2007 3:56 PM
Subject: RE: [ntdev] DMA common buffer and KMDF

Looking at the code it makes one call to WDM’s AllocateCommonBuffer under
the covers so the buffer is contiguous.

Perhaps the book was trying to say that the buffer is logically contiguous,
in that it occupies a contiguous address range within the device address
space but that there may be systems in the world where that isn’t actually
physically contiguous.

Still it seems confusing and perhaps over detailed. I’ll poke the writers
about it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 2:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DMA common buffer and KMDF

Hi all.

I’m working on a driver that uses DMA with the common buffer approach (it’s
actually a number of common buffers).

The technique is more or less the one described in this blog entry

http://blogs.msdn.com/peterwie/archive/2006/03/09/546961.aspx

(section “Using Common Buffer to setup a continuous transfer”).

I’ve done it in the past in a couple WDM drivers (following the Oney’s). The
key point there was that I didn’t need to call MapTransfer and stuff because
I had the virtual address and physical address of the common buffer (the
devices were DMA bus-master capable).
With KMDF there’s something that worries me. The WDF book (page 568, chapter
17, “Example: Driver DMA initialization”) says “The driver now creates a
common buffer. It does this by calling WdfCommonBufferCreate, passing the
length in bytes of the required common buffer. The allocated common buffer
area is not necessary physically contiguous.”

Maybe I’m stupid, but I see a contradiction in this…

Thanks again
GV

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Nice, thanks Peter!

Have a nice day
GV

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 22, 2007 4:45 PM
Subject: RE: [ntdev] DMA common buffer and KMDF

Yes. There aren’t any bounce buffers involved, so you can write to the VA
and it should show up in the page the device sees (modulo caching, processor
pipeline flushing, etc…)

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 4:27 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DMA common buffer and KMDF

This also means that I can safely use the virtual address returned by
WdfCommonBufferGetAlignedVirtualAddress and use it without the need to
create DMA transactions with WdfDmaTransactionCreate and so on (in the
continuous transfer approach you don’t really have such transactions from
the software point of view). Right?

Have a nice day
GV

----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 22, 2007 3:56 PM
Subject: RE: [ntdev] DMA common buffer and KMDF

Looking at the code it makes one call to WDM’s AllocateCommonBuffer under
the covers so the buffer is contiguous.

Perhaps the book was trying to say that the buffer is logically contiguous,
in that it occupies a contiguous address range within the device address
space but that there may be systems in the world where that isn’t actually
physically contiguous.

Still it seems confusing and perhaps over detailed. I’ll poke the writers
about it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, October 22, 2007 2:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DMA common buffer and KMDF

Hi all.

I’m working on a driver that uses DMA with the common buffer approach (it’s
actually a number of common buffers).

The technique is more or less the one described in this blog entry

http://blogs.msdn.com/peterwie/archive/2006/03/09/546961.aspx

(section “Using Common Buffer to setup a continuous transfer”).

I’ve done it in the past in a couple WDM drivers (following the Oney’s). The
key point there was that I didn’t need to call MapTransfer and stuff because
I had the virtual address and physical address of the common buffer (the
devices were DMA bus-master capable).
With KMDF there’s something that worries me. The WDF book (page 568, chapter
17, “Example: Driver DMA initialization”) says “The driver now creates a
common buffer. It does this by calling WdfCommonBufferCreate, passing the
length in bytes of the required common buffer. The allocated common buffer
area is not necessary physically contiguous.”

Maybe I’m stupid, but I see a contradiction in this…

Thanks again
GV

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer