Prev: Xilinx xapp175, empty + full flag really synchronous?
Next: carrier tracking over zero frequency point
From: Michael S on 3 Jul 2010 14:34
On Jul 2, 9:04 pm, Charles Gardiner <charles.gardi...(a)invalid.invalid>
wrote:
> Hi Frank,
>
>
>
> > I am not sure if we understand each other.
>
> Yes, it certainly sounds like that.
>
> > What do you mean by
> > completing the request with IoCompleteRequest? There is no request
> > from software point of view.
>
> I think this might clear up the reason why your data is missing. (See also below
> about the type of DMA). I don't think the S/G list you are getting is describing
> your application buffer. This is best done by specifying DO_DIRECT_IO as the DMA
> method for your device. If you specify DO_BUFFERED_IO you will get an S/G List
> describing an intermediate buffer in kernel space and this probably never gets
> copied over to your application space buffer unless you terminate the request.
> I've never done the 'neither' method myself and from what I hear, it's a
> complicated beast.
>
> > The FPGA will do a DMA write (data from
> > FPGA to PC memory) at its own initiative. The allocated memory is used
> > as long as the software is running. I do not allocate new memory for
> > each new DMA transfer, but at startup a large piece of memory is
> > allocated and the physical addresses are written to the FPGA by the
> > driver software.
>
> Sounds like you are doing something like a circular buffer in memory which stays
> alive as long as your device does?
>
>
>
> > And yes, we use a DMA adapter in combination with the
> > GetScatterGatherList method. We already used this in another project
> > but that was PCI and DMA read (data from PC memory to FPGA).
>
> > By the way, where can I set the type of DMA?
>
> Typically, you set the DMA buffering method in your AddDevice function after you
> create your device object. Quoting from Oney's book,
>
> NTSTATUS AddDevice(..) {
>    PDEVICE_OBJECT    fdo;
>
>    IoCreateDevice(....., &fdo);
>    fdo->Flags |= DO_BUFFERED_IO;
>             <or>
>    fdo->Flags |= DO_DIRECT_IO;
>             <or>
>    fdo->Flags |= 0;  // i.e. neither Direct nor Buffered
>
> And, you can't change your mind afterwards.
>
> By the way if my assumption about the circular buffer in your design is correct,
> there is a slightly more standard solution (standard in the sense that everybody
> on the microsoft drivers newgroup seems to do it). It however requires two threads
> in your application. The first one requests a buffer (using new or malloc) and
> sets up an I/O Request ReadFile, WriteFile or DeviceIoControl referencing this
> buffer. This is performed as an asynchronous request.
>

There is absolutely no need for a second thread. Just issue "submit
buffer" overlapped I/O request in a first thread and don't wait for
completion.

> The driver recognizes this request and pends it indefinitely, (typically terminate
> it when your driver is shutting down, otherwise windows will probably hang).

That's pretty bad advice. As a minimum, you should install the cancel
handler and complete the request on cancellation. Besides, normally
you should stop all DMA activities and complete the request in CLEANUP
routine.
Also it is always a good idea to have custom "stop DMA and withdraw
circular buffer" IOCTL for a normal user-initiated termination.

> Pending the request has the nice side effect that the buffer now becomes locked
> down permanently.
>
> Assuming you have set up your driver to use DO_DIRECT_IO DMA, you can get the S/G
> list describing the application space buffer as you are currently doing and feed
> this to your FPGA.
>
> Using the second thread in your application you can constantly read data from the
> locked down pages (you app. space buffer) that are being written by your FPGA.
>
> Assuming the DO_DIRECT_IO solves your problem (I think there is a good chance), I
> would however still consider migrating to a KMDF based driver, particularily if
> you are writing a new one. It's much easier to maintain and is probably more
> portable for future MS versions.
>
>
>
> > best regards,
>
> > Frank
>
> best regards,
> Charles

Yes, KMDF MUCH is easier than plain WDM.

From: Charles Gardiner on 3 Jul 2010 20:01
Michael S schrieb:

>
> Anyway, the discussion doesn't belong here. I recommend
> http://groups.google.com/group/microsoft.public.development.device.drivers
>

No it doesn't. It belongs just where it is. If you followed from the beginning,
the OP has two problems/questions

1) How to do 64-Bit addressing in PCIe. This is definitely FPGA related.

2) Why are his data not appearing as expected. It only became clear in the course
of discussion that this may be due to his driver DMA type setting. (He hasn't
confirmed yet)

Nit-picking when everything is (maybe) solved is easy when you haven't really been
contributing constructively.

From: Michael S on 4 Jul 2010 05:08
On Jul 4, 2:01 am, Charles Gardiner <charles.gardi...(a)invalid.invalid>
wrote:
> Michael S schrieb:
>
>
>
> > Anyway, the discussion doesn't belong here. I recommend
> >http://groups.google.com/group/microsoft.public.development.device.dr...
>
> No it doesn't. It belongs just where it is. If you followed from the beginning,
> the OP has two problems/questions
>

I insist that subthread started by Nico Coesel could be discussed in
mpddd with better depth and precision.


> 1) How to do 64-Bit addressing in PCIe. This is definitely FPGA related.

You mean, 32-bit addressing.

>
> 2) Why are his data not appearing as expected. It only became clear in the course
> of discussion that this may be due to his driver DMA type setting. (He hasn't
> confirmed yet)

Microsoft calls them "data buffer access methods". DMA type (or, by
KMDF terminology, profile) is something else.
I hope you realize how important it is to use the same terminology as
the rest of the world.

http://msdn.microsoft.com/en-us/library/ff554436%28v=VS.85%29.aspx

>
> Nit-picking when everything is (maybe) solved is easy when you haven't really been
>  contributing constructively.

If you followed from the beginning, you would realize that I
constructively contributed the answer to the first question 4 minutes
ahead of you ;)
Also, IMHO, pointer to the most appropriate newsgroup is very
constructive.


From: Charles Gardiner on 4 Jul 2010 05:59
Michael S schrieb:

> I insist that subthread started by Nico Coesel could be discussed in
> mpddd with better depth and precision.
>
You insist? Do I care?

>
> If you followed from the beginning, you would realize that I
> constructively contributed the answer to the first question 4 minutes
> ahead of you ;)

4 mins.? WOW. Incredible. Impressive, Awesome.....

What I see in this posting is a terse reply to the easy part of the problem with
not a single thought spent on the more complex part, even though this is really
the OPs show stopper.

For the rest of your postings, I mainly see blowholed personal seals of approval
assigned to what others have said (aka nit-picking). All coming in "posthumously"
(still assuming that specifying DO_DIRECT_IO actually solves the problem)

I really love attending meetings when guys like you are involved, especially in
the last phase when those who havn't contributed much insist on getting a chance
to lift their leg. The german comedian Karl Valentin had perhaps a more literary
way of putting it: "I suppose everything has been said then, but not yet by
everybody".

Oh, don't take my personal aversion too much to heart. I'm sure somebody on this
planet recognises your contribution, even if it's only Dilbert
From: Michael S on 4 Jul 2010 07:17
On Jul 4, 11:59 am, Charles Gardiner
<charles.gardi...(a)invalid.invalid> wrote:
> Michael S schrieb:
>
> > I insist that subthread started by Nico Coesel could be discussed  in
> > mpddd with better depth and precision.
>
> You insist? Do I care?
>
> > If you followed from the beginning, you would realize that I
> > constructively contributed the answer to the first question 4 minutes
> > ahead of you ;)
>
> 4 mins.? WOW. Incredible. Impressive, Awesome.....
>
> What I see in this posting is a terse reply to the easy part of the problem with
> not a single thought spent on the more complex part, even though this is really
> the OPs show stopper.
>
> For the rest of your postings, I mainly see blowholed personal seals of approval
> assigned to what others have said (aka nit-picking). All coming in "posthumously"
> (still assuming that specifying DO_DIRECT_IO actually solves the problem)

And I am 90% sure that 3DW was his only problem.
The following sentence in his original post suggests that he doesn't
use BUFFERED_IO:
"The driver locks the memory". For me it sounds like he is doing
NEITHER I/O.
So it's either 3DW or, less likely, he erroneously too early completes
his ReadFile() request.

>
> I really love attending meetings when guys like you are involved, especially in
> the last phase when those who havn't contributed much insist on getting a chance
> to lift their leg. The german comedian Karl Valentin had perhaps a more literary
> way of putting it: "I suppose everything has been said then, but not yet by
> everybody".
>
> Oh, don't take my personal aversion too much to heart. I'm sure somebody on this
> planet recognises your contribution, even if it's only Dilbert

You are wrong. I never really was obsessed with getting the credit.
More like obsessed with precise formulations, although more so in real
life than on the Web.
Also I am one of those types that don't like to quickly jump to
conclusion.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Xilinx xapp175, empty + full flag really synchronous?
Next: carrier tracking over zero frequency point