I’m now confused about something I thought I understood.
Is WdfDmaTransactionExecute a synchronous call or not? The
documentation does not seem to be entirely clear. If you look at the
MSDN page on “Starting a DMA Transaction”
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff544642.aspx), the
sample code from the PLX9x5x sample seems to imply that it is
asynchronous – that a successful return merely means that the
transaction was STARTED, and that it the responsibility of the DPC to
complete the request when things are actually finished.
The code from our poster with the “DMA transfer size limit” assumes that
the call is synchronous – that it will not return until the request is
complete. I was about to respond with a “THERE’S your problem” reply,
when I decided I should double-check my understanding, and now I’m not
at all sure. There is a quote in the MSDN page on
WdfDmaTransactionExecute that says “The driver can call
WdfDmaTransactionExecute in a non-blocking manner if it has previously
called WdfDmaTransactionSetImmediateExecution.” That implies that the
Execute call is normally blocking. Is it?
That page also says “To determine if the framework successfully sent all
of the transaction’s transfers to the driver’s /EvtProgramDma/
http:
callback function, the driver must call WdfDmaTransactionDmaCompleted
http:,
WdfDmaTransactionDmaCompletedWithLength
http:,
or WdfDmaTransactionDmaCompletedFinal
http:.”
However, that sentence isn’t really accurate, is it? Those are the APIs
that I call to let the FRAMEWORK know that part of the transaction is
complete. I don’t call those to determine whether the transfer is
complete. Do I?
Is it possible the DMA design changed part way through the development
process, and the documentation reflects an earlier version? Or am I
just misreading things?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</http:></http:></http:></http:>
The underlying GetScatterGatherList call is *usually* in-line, so that the callback is called in the original caller’s stack, but in some rare cases (shortage of the bounce buffers), it may complete in different context.
This means you can’t simply assume your callback was called, after this function returned.
xxxxx@broadcom.com wrote:
The underlying GetScatterGatherList call is *usually* in-line, so that the callback is called in the original caller’s stack, but in some rare cases (shortage of the bounce buffers), it may complete in different context.
This means you can’t simply assume your callback was called, after this function returned.
Are you simply interpolating how you think WdmDmaTransactionExecute must
work, based on the behavior of the underlying WDM calls, or are you
saying you understand how the KMDF wrapper actually operates? It would
not surprise me to find, for example, that the KMDF wrapper protects us
from that uncertainty by synchronizing in some way, but that’s never stated.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Kmdf just thinks to the underlying API, which means the async callback can occur with kmdf, just like wdm
d
debt from my phone
From: Tim Roberts
Sent: 7/30/2012 12:47 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DMA Transaction Confusion
xxxxx@broadcom.com wrote:
The underlying GetScatterGatherList call is *usually* in-line, so that the callback is called in the original caller’s stack, but in some rare cases (shortage of the bounce buffers), it may complete in different context.
This means you can’t simply assume your callback was called, after this function returned.
Are you simply interpolating how you think WdmDmaTransactionExecute must
work, based on the behavior of the underlying WDM calls, or are you
saying you understand how the KMDF wrapper actually operates? It would
not surprise me to find, for example, that the KMDF wrapper protects us
from that uncertainty by synchronizing in some way, but that’s never stated.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
Doron Holan wrote:
Kmdf just thinks to the underlying API, which means the async callback
can occur with kmdf, just like wdm
So, does this mean that WdfDmaTransactionExecute can, in fact, return
before the DMA has completed? If so, then I have an answer for Kiran
Kunnath…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes
d
debt from my phone
From: Tim Roberts
Sent: 7/30/2012 1:26 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DMA Transaction Confusion
Doron Holan wrote:
Kmdf just thinks to the underlying API, which means the async callback
can occur with kmdf, just like wdm
So, does this mean that WdfDmaTransactionExecute can, in fact, return
before the DMA has completed? If so, then I have an answer for Kiran
Kunnath…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
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
In any case, it returns *usually* after the callback was called with the SGL address. The callback will normally *start* the DMA. The function will most often return *before* the DMA had a chance to complete. Since GetScatterGatherList function must be called on DISPATCH_LEVEL, the callback can NOT wait for the operation completion.