Supporting DMA confusion..

NTDEV
1

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently
being developed by our hardware engineers which will have a DMA controller
which supports scatter gather. now I have noticed that the windows xp ddk
has DMA routines, am I right to assume that these DMA routines will only
support the system DMA and bus master DMA controller on the system
motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could someone
please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by
obtaining the DMA control and status registers, and the PRD control register
from the PCI configuration, so I can build my own scatter gather list.

Regards
James
This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

2

You use the scatter gather dma routines in the ddk to obtain the
addresses that you feed to your pci device dma logic. Controlling your
device dma operations is of course your responsibility. Obviously, as
you have figured out, the system cannot program your device’s dma
controller for you, that is your responsibility.

I am not sure what exactly you mean by “obtaining the DMA control and
status registers, and the PRD control register from the PCI
configuration”. The control registers for your pci device ought to be
arranged within the Base Address Registers defined in your device config
space. You ought to never be accessing PCI config space directly.
Instead you are handed the set of negotiated BAR regions for your device
in your StartDevice routines, and you use those addresses for
communication with your device.

=====================
Mark Roddy

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is
currently being developed by our hardware engineers which will have a
DMA controller which supports scatter gather. now I have noticed that
the windows xp ddk has DMA routines, am I right to assume that these DMA
routines will only support the system DMA and bus master DMA controller
on the system motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could
someone please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually
by obtaining the DMA control and status registers, and the PRD control
register from the PCI configuration, so I can build my own scatter
gather list.

Regards
James

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they
are addressed. If you are not the intended recipient, please be advised
that you have received this email in error and action should be taken to
inform the originator and this email should be deleted immediately and
any copies made should be destroyed. If you are not the intended
recipient, any form of disclosure, distribution, printing, copying or
any other use of this email or the information in it or in any
attachments is strictly prohibited and may be unlawful. Any views,
opinions or other information expressed in the email and any attachments
are those of the originator and not given or endorsed by General
Dynamics UK Ltd.In compliance with the various Regulations and Acts,
please be aware that General Dynamics UK Ltd reserves the right to
monitor all emails and email attachments, both inbound and outbound,
allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free
of errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

3

As has been discussed here before (fairly recently also), there is no such
thing as system DMA when it comes to PCI devices. If you are going to do
DMA to/from a PCI device, it has to be implemented as bus master DMA on the
PCI device.

The idea of a system DMA was an old ISA bus thing.

Rather than rehash the subject, I suggest you check the archives at
http://www.osronline.com/page.cfm?name=search. Look for all posts with the
subject “DMA + common buffer ARC”, I think this will answer your questions.

Russ Poffenberger
Credence Systems Corp.
xxxxx@credence.com

At 06:34 AM 6/6/2005, you wrote:

Hi all,

I have been asked to develop a PCI driver for a PCI card which is
currently being developed by our hardware engineers which will have a DMA
controller which supports scatter gather. now I have noticed that the
windows xp ddk has DMA routines, am I right to assume that these DMA
routines will only support the system DMA and bus master DMA controller on
the system motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could
someone please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually
by obtaining the DMA control and status registers, and the PRD control
register from the PCI configuration, so I can build my own scatter gather
list.

4

Thanks for that, I actually meant that the DMA control registers which are
needed to drive the device DMA operations from the DMA control registers
will be arranged within the Base Address Registers defined in the device
config space, sorry for the confusion.

so based on your reply, I can still use the scatter gather DMA routines in
the ddk to construct the PRD tables or scatter gather tables, even though I
still need to drive the device DMA operations manually?

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 06 June 2005 14:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You use the scatter gather dma routines in the ddk to obtain the addresses
that you feed to your pci device dma logic. Controlling your device dma
operations is of course your responsibility. Obviously, as you have figured
out, the system cannot program your device’s dma controller for you, that is
your responsibility.

I am not sure what exactly you mean by “obtaining the DMA control and status
registers, and the PRD control register from the PCI configuration”. The
control registers for your pci device ought to be arranged within the Base
Address Registers defined in your device config space. You ought to never be
accessing PCI config space directly. Instead you are handed the set of
negotiated BAR regions for your device in your StartDevice routines, and you
use those addresses for communication with your device.

=====================
Mark Roddy

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently
being developed by our hardware engineers which will have a DMA controller
which supports scatter gather. now I have noticed that the windows xp ddk
has DMA routines, am I right to assume that these DMA routines will only
support the system DMA and bus master DMA controller on the system
motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could someone
please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by
obtaining the DMA control and status registers, and the PRD control register
from the PCI configuration, so I can build my own scatter gather list.

Regards
James

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

5

right. And you should google for all the discussions and hints and links
here and in the newsgroups about how to do this correctly and
efficiently.

=====================
Mark Roddy

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

Thanks for that, I actually meant that the DMA control registers which
are needed to drive the device DMA operations from the DMA control
registers will be arranged within the Base Address Registers defined in
the device config space, sorry for the confusion.

so based on your reply, I can still use the scatter gather DMA routines
in the ddk to construct the PRD tables or scatter gather tables, even
though I still need to drive the device DMA operations manually?

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 06 June 2005 14:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You use the scatter gather dma routines in the ddk to obtain the
addresses that you feed to your pci device dma logic. Controlling your
device dma operations is of course your responsibility. Obviously, as
you have figured out, the system cannot program your device’s dma
controller for you, that is your responsibility.

I am not sure what exactly you mean by “obtaining the DMA
control and status registers, and the PRD control register from the PCI
configuration”. The control registers for your pci device ought to be
arranged within the Base Address Registers defined in your device config
space. You ought to never be accessing PCI config space directly.
Instead you are handed the set of negotiated BAR regions for your device
in your StartDevice routines, and you use those addresses for
communication with your device.

=====================
Mark Roddy

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which
is currently being developed by our hardware engineers which will have a
DMA controller which supports scatter gather. now I have noticed that
the windows xp ddk has DMA routines, am I right to assume that these DMA
routines will only support the system DMA and bus master DMA controller
on the system motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the
DMA controller on the actual PCI card but now I am having doubts, could
someone please clarify?

I am assuming that I will need to drive the DMA on the PCI card
manually by obtaining the DMA control and status registers, and the PRD
control register from the PCI configuration, so I can build my own
scatter gather list.

Regards
James

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

This email and any files attached to it are of a confidential
nature and intended for the exclusive use of the individual or entity to
whom they are addressed. If you are not the intended recipient, please
be advised that you have received this email in error and action should
be taken to inform the originator and this email should be deleted
immediately and any copies made should be destroyed. If you are not the
intended recipient, any form of disclosure, distribution, printing,
copying or any other use of this email or the information in it or in
any attachments is strictly prohibited and may be unlawful. Any views,
opinions or other information expressed in the email and any attachments
are those of the originator and not given or endorsed by General
Dynamics UK Ltd.In compliance with the various Regulations and Acts,
please be aware that General Dynamics UK Ltd reserves the right to
monitor all emails and email attachments, both inbound and outbound,
allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free
of errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they
are addressed. If you are not the intended recipient, please be advised
that you have received this email in error and action should be taken to
inform the originator and this email should be deleted immediately and
any copies made should be destroyed. If you are not the intended
recipient, any form of disclosure, distribution, printing, copying or
any other use of this email or the information in it or in any
attachments is strictly prohibited and may be unlawful. Any views,
opinions or other information expressed in the email and any attachments
are those of the originator and not given or endorsed by General
Dynamics UK Ltd.In compliance with the various Regulations and Acts,
please be aware that General Dynamics UK Ltd reserves the right to
monitor all emails and email attachments, both inbound and out! bound,
allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free
of errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

6

Busmaster DMA controller is within the PCI card itself. The Windows DMA routines in this case do the things like software scatter-gather and crossing 4GB boundary on PAE systems.

System DMA is not supported on PCI (aside the strange thing named Distributed DMA and invented for soundcards only).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: James Dunning
To: Windows System Software Devs Interest List
Sent: Monday, June 06, 2005 5:34 PM
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently being developed by our hardware engineers which will have a DMA controller which supports scatter gather. now I have noticed that the windows xp ddk has DMA routines, am I right to assume that these DMA routines will only support the system DMA and bus master DMA controller on the system motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA controller on the actual PCI card but now I am having doubts, could someone please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by obtaining the DMA control and status registers, and the PRD control register from the PCI configuration, so I can build my own scatter gather list.

Regards
James

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached to it are of a confidential nature and intended for the exclusive use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that you have received this email in error and action should be taken to inform the originator and this email should be deleted immediately and any copies made should be destroyed. If you are not the intended recipient, any form of disclosure, distribution, printing, copying or any other use of this email or the information in it or in any attachments is strictly prohibited and may be unlawful. Any views, opinions or other information expressed in the email and any attachments are those of the originator and not given or endorsed by General Dynamics UK Ltd.In compliance with the various Regulations and Acts, please be aware that General Dynamics UK Ltd reserves the right to monitor all emails and email attachments, both inbound and outbound, allowing legitimate business practice to continue.In addition to monitoring, General Dynamics UK Ltd also provides appropriate Antivirus measures scanning all incoming and outgoing email and email attachments. However, email communications cannot be guaranteed to be secure or free of errors as information may be intercepted, corrupted, amended, lost, destroyed or contain viruses. General Dynamics UK Ltd do not accept liability or responsibility for any such matters or the consequences thereof.

7

Yes. The Windows routines a) convert MDL to SGL b) create the necessary bounce buffers for 32bit card without the Dual Address Cycle feature on the machine with > 4GB RAM.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: James Dunning
To: Windows System Software Devs Interest List
Sent: Monday, June 06, 2005 6:34 PM
Subject: RE: [ntdev] Supporting DMA confusion…

Thanks for that, I actually meant that the DMA control registers which are needed to drive the device DMA operations from the DMA control registers will be arranged within the Base Address Registers defined in the device config space, sorry for the confusion.

so based on your reply, I can still use the scatter gather DMA routines in the ddk to construct the PRD tables or scatter gather tables, even though I still need to drive the device DMA operations manually?

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 06 June 2005 14:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You use the scatter gather dma routines in the ddk to obtain the addresses that you feed to your pci device dma logic. Controlling your device dma operations is of course your responsibility. Obviously, as you have figured out, the system cannot program your device’s dma controller for you, that is your responsibility.

I am not sure what exactly you mean by “obtaining the DMA control and status registers, and the PRD control register from the PCI configuration”. The control registers for your pci device ought to be arranged within the Base Address Registers defined in your device config space. You ought to never be accessing PCI config space directly. Instead you are handed the set of negotiated BAR regions for your device in your StartDevice routines, and you use those addresses for communication with your device.

=====================
Mark Roddy

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently being developed by our hardware engineers which will have a DMA controller which supports scatter gather. now I have noticed that the windows xp ddk has DMA routines, am I right to assume that these DMA routines will only support the system DMA and bus master DMA controller on the system motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA controller on the actual PCI card but now I am having doubts, could someone please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by obtaining the DMA control and status registers, and the PRD control register from the PCI configuration, so I can build my own scatter gather list.

Regards
James

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached to it are of a confidential nature and intended for the exclusive use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that you have received this email in error and action should be taken to inform the originator and this email should be deleted immediately and any copies made should be destroyed. If you are not the intended recipient, any form of disclosure, distribution, printing, copying or any other use of this email or the information in it or in any attachments is strictly prohibited and may be unlawful. Any views, opinions or other information expressed in the email and any attachments are those of the originator and not given or endorsed by General Dynamics UK Ltd.In compliance with the various Regulations and Acts, please be aware that General Dynamics UK Ltd reserves the right to monitor all emails and email attachments, both inbound and outbound, allowing legitimate business practice to continue.In addition to monitoring, General Dynamics UK Ltd also provides appropriate Antivirus measures scanning all incoming and outgoing email and email attachments. However, email communications cannot be guaranteed to be secure or free of errors as information may be intercepted, corrupted, amended, lost, destroyed or contain viruses. General Dynamics UK Ltd do not accept liability or responsibility for any such matters or the consequences thereof.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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
This email and any files attached to it are of a confidential nature and intended for the exclusive use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that you have received this email in error and action should be taken to inform the originator and this email should be deleted immediately and any copies made should be destroyed. If you are not the intended recipient, any form of disclosure, distribution, printing, copying or any other use of this email or the information in it or in any attachments is strictly prohibited and may be unlawful. Any views, opinions or other information expressed in the email and any attachments are those of the originator and not given or endorsed by General Dynamics UK Ltd.In compliance with the various Regulations and Acts, please be aware that General Dynamics UK Ltd reserves the right to monitor all emails and email attachments, both inbound and outbound, allowing legitimate business practice to continue.In addition to monitoring, General Dynamics UK Ltd also provides appropriate Antivirus measures scanning all incoming and outgoing email and email attachments. However, email communications cannot be guaranteed to be secure or free of errors as information may be intercepted, corrupted, amended, lost, destroyed or contain viruses. General Dynamics UK Ltd do not accept liability or responsibility for any such matters or the consequences thereof.

8

Thanks for pointing me in the right direction guys.

Just out of interest, when is the OSR search database usually updated? it
seems like it was last updated in December 2004? as I am having trouble
searching for the posts

“DMA + common buffer ARC” recommended by Russ Poffenberger

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: 06 June 2005 17:44
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Supporting DMA confusion…

Yes. The Windows routines a) convert MDL to SGL b) create the necessary
bounce buffers for 32bit card without the Dual Address Cycle feature on the
machine with > 4GB RAM.

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

----- Original Message -----
From: James Dunning mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List

Sent: Monday, June 06, 2005 6:34 PM
Subject: RE: [ntdev] Supporting DMA confusion…

Thanks for that, I actually meant that the DMA control registers which are
needed to drive the device DMA operations from the DMA control registers
will be arranged within the Base Address Registers defined in the device
config space, sorry for the confusion.

so based on your reply, I can still use the scatter gather DMA routines in
the ddk to construct the PRD tables or scatter gather tables, even though I
still need to drive the device DMA operations manually?

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 06 June 2005 14:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You use the scatter gather dma routines in the ddk to obtain the addresses
that you feed to your pci device dma logic. Controlling your device dma
operations is of course your responsibility. Obviously, as you have figured
out, the system cannot program your device’s dma controller for you, that is
your responsibility.

I am not sure what exactly you mean by “obtaining the DMA control and status
registers, and the PRD control register from the PCI configuration”. The
control registers for your pci device ought to be arranged within the Base
Address Registers defined in your device config space. You ought to never be
accessing PCI config space directly. Instead you are handed the set of
negotiated BAR regions for your device in your StartDevice routines, and you
use those addresses for communication with your device.

=====================
Mark Roddy

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently
being developed by our hardware engineers which will have a DMA controller
which supports scatter gather. now I have noticed that the windows xp ddk
has DMA routines, am I right to assume that these DMA routines will only
support the system DMA and bus master DMA controller on the system
motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could someone
please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by
obtaining the DMA control and status registers, and the PRD control register
from the PCI configuration, so I can build my own scatter gather list.

Regards
James
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
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

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.</mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>

9

From the research I have done over the last couple of days, I think I may
have got my head around using DMA and scatter gather list, unfortunately the
PCI card is still under development so I can not put this into practice.

From the device StartDevice routine, I will need to read the PCI device
configuration space, store the BAR regions for my device, and create a DMA
bus master adapter using IoGetDmaAdapter, then allocate the Common Buffer
for DMA read operations. Finally register the device driver’s interrupt
service routine to acknowledge when the PCI device DMA data transfer has
completed.

Assuming that my device is using Direct I/O for data transfers, during a
dispatched read request I will get an MDL describing the user’s buffer.
using this MDL I will need to call GetScatterGatherList from the DMA adapter
allocated from the Start Device routine. this will convert the MDL to a NT
scatter gather list, which can then be mapped to my PCI device DMA scatter
gather list.

At this point I should be at a stage where I can manually program my PCI
device DMA to start the data transfer from the PCI device DMA to my mapped
scatter gather list. (Is this correct?)

In the interrupt service routine I will need to detect when the PCI device
DMA data transfer has completed, and acknowledge the interrupt and queue for
DPC

In the DPC routine return the scatter gather list by calling
PutScatterGatherList from the adapter dmaoperations which will flush the
buffers and then complete the request.

Now the question is am I on the right track here? any advice or suggestions
would be most appreciated

Regards
James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of James Dunning
Sent: 07 June 2005 10:02
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

Thanks for pointing me in the right direction guys.

Just out of interest, when is the OSR search database usually updated? it
seems like it was last updated in December 2004? as I am having trouble
searching for the posts

“DMA + common buffer ARC” recommended by Russ Poffenberger

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: 06 June 2005 17:44
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Supporting DMA confusion…

Yes. The Windows routines a) convert MDL to SGL b) create the necessary
bounce buffers for 32bit card without the Dual Address Cycle feature on the
machine with > 4GB RAM.

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

----- Original Message -----
From: James Dunning mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List

Sent: Monday, June 06, 2005 6:34 PM
Subject: RE: [ntdev] Supporting DMA confusion…

Thanks for that, I actually meant that the DMA control registers which are
needed to drive the device DMA operations from the DMA control registers
will be arranged within the Base Address Registers defined in the device
config space, sorry for the confusion.

so based on your reply, I can still use the scatter gather DMA routines in
the ddk to construct the PRD tables or scatter gather tables, even though I
still need to drive the device DMA operations manually?

James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 06 June 2005 14:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You use the scatter gather dma routines in the ddk to obtain the addresses
that you feed to your pci device dma logic. Controlling your device dma
operations is of course your responsibility. Obviously, as you have figured
out, the system cannot program your device’s dma controller for you, that is
your responsibility.

I am not sure what exactly you mean by “obtaining the DMA control and status
registers, and the PRD control register from the PCI configuration”. The
control registers for your pci device ought to be arranged within the Base
Address Registers defined in your device config space. You ought to never be
accessing PCI config space directly. Instead you are handed the set of
negotiated BAR regions for your device in your StartDevice routines, and you
use those addresses for communication with your device.

=====================
Mark Roddy

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Monday, June 06, 2005 9:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Supporting DMA confusion…

Hi all,

I have been asked to develop a PCI driver for a PCI card which is currently
being developed by our hardware engineers which will have a DMA controller
which supports scatter gather. now I have noticed that the windows xp ddk
has DMA routines, am I right to assume that these DMA routines will only
support the system DMA and bus master DMA controller on the system
motherboard and not on the PCI card itself?

Originally I thought these DMA routines will interact with the DMA
controller on the actual PCI card but now I am having doubts, could someone
please clarify?

I am assuming that I will need to drive the DMA on the PCI card manually by
obtaining the DMA control and status registers, and the PRD control register
from the PCI configuration, so I can build my own scatter gather list.

Regards
James
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
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

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.</mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx>

10

“From the device StartDevice routine, I will need to read the PCI device
configuration space, store the BAR regions for my device, and create a
DMA bus master adapter using IoGetDmaAdapter, then allocate the Common
Buffer for DMA read operations. Finally register the device driver’s
interrupt service routine to acknowledge when the PCI device DMA data
transfer has completed.”

Your description here is wrong. In your start device routine (actually
in the completion phase of your start device routine) you will use the
IO and interrupt resources provided to you by the IRP, you will not be
reading config space directly. The IO resources represent the BAR
regions configured for your device. You will perform the appropriate
mapping of these logical addresses and store them in your device
extension for later use. I have no idea why you need a common buffer for
dma read operations, but if you really need one this would be the right
time to acquire it.

=====================
Mark Roddy

11

You are right again! apologies, my desk is an organised mess covered with
hardware engineering notes about the PCI card under development. I cant get
the device config space or bar regions out of my head!

but you are right, I will need to enumerate through the partial resource
descriptor’s in the start device routine to obtain the BAR info and map them
to my device extension.

I’ve no idea what the concept is behind the common buffer at this stage, I
just assumed I will need to use one based on post’s I’ve searched on goggle
and on the OSR list. it seems if u do a search for DMA and scatter gather,
common buffers get a mention.

I would be interested to hear why you think that a common buffer would be
unnecessary for DMA read operations.

Regards
James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 07 June 2005 14:31
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

“From the device StartDevice routine, I will need to read the PCI device
configuration space, store the BAR regions for my device, and create a
DMA bus master adapter using IoGetDmaAdapter, then allocate the Common
Buffer for DMA read operations. Finally register the device driver’s
interrupt service routine to acknowledge when the PCI device DMA data
transfer has completed.”

Your description here is wrong. In your start device routine (actually
in the completion phase of your start device routine) you will use the
IO and interrupt resources provided to you by the IRP, you will not be
reading config space directly. The IO resources represent the BAR
regions configured for your device. You will perform the appropriate
mapping of these logical addresses and store them in your device
extension for later use. I have no idea why you need a common buffer for
dma read operations, but if you really need one this would be the right
time to acquire it.

=====================
Mark Roddy

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

12

We have a custom inhouse designed PCI card that does S/G DMA, and do not
use a common buffer. The DMA operation is initiated by a call for user mode
application (ReadFile/WriteFile). The user mode buffer is passed in the
IRP, and the scatter/gather list is constructed directly from the UM
buffer. So basically the DMA is done directly into the UM buffer. The use
of scatter/gather is what typically enables you to NOT have to use a common
buffer, since you don’t need a physically contiguous memory buffer.

At 06:47 AM 6/7/2005, you wrote:

You are right again! apologies, my desk is an organised mess covered with
hardware engineering notes about the PCI card under development. I cant get
the device config space or bar regions out of my head!

but you are right, I will need to enumerate through the partial resource
descriptor’s in the start device routine to obtain the BAR info and map them
to my device extension.

I’ve no idea what the concept is behind the common buffer at this stage, I
just assumed I will need to use one based on post’s I’ve searched on goggle
and on the OSR list. it seems if u do a search for DMA and scatter gather,
common buffers get a mention.

I would be interested to hear why you think that a common buffer would be
unnecessary for DMA read operations.

Russ Poffenberger
Credence Systems Corp.
xxxxx@credence.com

13

Generally you need a common buffer for continuous transfers between
device memory and system memory, for example you might end up with a
design where your device dma scatter gather lists are actually
constructed in system memory using a common buffer. Call that type of
arrangement ‘common buffers for shared control structures’. I have no
problem with that sort of arrangement. Less typical would be a need for
a common buffer for data IO transfer in either direction, particularly
when your device does scatter gather bus master dma. If you need a
system memory region for shared control structures, use a common buffer.
If you think you need a common buffer for data IO transfers, rethink
your design.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Dunning
Sent: Tuesday, June 07, 2005 9:47 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

You are right again! apologies, my desk is an organised mess covered
with hardware engineering notes about the PCI card under development. I
cant get the device config space or bar regions out of my head!

but you are right, I will need to enumerate through the partial resource
descriptor’s in the start device routine to obtain the BAR info and map
them to my device extension.

I’ve no idea what the concept is behind the common buffer at this stage,
I just assumed I will need to use one based on post’s I’ve searched on
goggle and on the OSR list. it seems if u do a search for DMA and
scatter gather, common buffers get a mention.

I would be interested to hear why you think that a common buffer would
be unnecessary for DMA read operations.

Regards
James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: 07 June 2005 14:31
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

“From the device StartDevice routine, I will need to read the PCI device
configuration space, store the BAR regions for my device, and create a
DMA bus master adapter using IoGetDmaAdapter, then allocate the Common
Buffer for DMA read operations. Finally register the device driver’s
interrupt service routine to acknowledge when the PCI device DMA data
transfer has completed.”

Your description here is wrong. In your start device routine (actually
in the completion phase of your start device routine) you will use the
IO and interrupt resources provided to you by the IRP, you will not be
reading config space directly. The IO resources represent the BAR
regions configured for your device. You will perform the appropriate
mapping of these logical addresses and store them in your device
extension for later use. I have no idea why you need a common buffer for
dma read operations, but if you really need one this would be the right
time to acquire it.

=====================
Mark Roddy

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they
are addressed. If you are not the intended recipient, please be advised
that you have received this email in error and action should be taken to
inform the originator and this email should be deleted immediately and
any copies made should be destroyed. If you are not the intended
recipient, any form of disclosure, distribution, printing, copying or
any other use of this email or the information in it or in any
attachments is strictly prohibited and may be unlawful. Any views,
opinions or other information expressed in the email and any attachments
are those of the originator and not given or endorsed by General
Dynamics UK Ltd.In compliance with the various Regulations and Acts,
please be aware that General Dynamics UK Ltd reserves the right to
monitor all emails and email attachments, both inbound and outbound,
allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free
of errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

14

I am assuming you are using Buffered IO and not Neither IO, either way
surely you would have to map this buffer to an MDL eventually so that it
will be safe to use your user buffer depending on what thread context you
access your buffer.

When an ReadFile operation is called from a user mode application, you will
be called at PASSIVE_LEVEL, I am assuming at this stage you process your IRP
straight away, or do you insert your IRP into a read queue and return
STATUS_PENDING? so that your DMA data transfers is done <= DISPATCH_LEVEL?

Regards
James

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Russell
Poffenberger
Sent: 07 June 2005 15:00
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Supporting DMA confusion…

We have a custom inhouse designed PCI card that does S/G DMA, and do not
use a common buffer. The DMA operation is initiated by a call for user mode
application (ReadFile/WriteFile). The user mode buffer is passed in the
IRP, and the scatter/gather list is constructed directly from the UM
buffer. So basically the DMA is done directly into the UM buffer. The use
of scatter/gather is what typically enables you to NOT have to use a common
buffer, since you don’t need a physically contiguous memory buffer.

At 06:47 AM 6/7/2005, you wrote:

You are right again! apologies, my desk is an organised mess covered with
hardware engineering notes about the PCI card under development. I cant
get
the device config space or bar regions out of my head!

but you are right, I will need to enumerate through the partial resource
descriptor’s in the start device routine to obtain the BAR info and map
them
to my device extension.

I’ve no idea what the concept is behind the common buffer at this stage, I
just assumed I will need to use one based on post’s I’ve searched on goggle
and on the OSR list. it seems if u do a search for DMA and scatter gather,
common buffers get a mention.

I would be interested to hear why you think that a common buffer would be
unnecessary for DMA read operations.

Russ Poffenberger
Credence Systems Corp.
xxxxx@credence.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached to it are of a confidential nature and
intended for the exclusive use of the individual or entity to whom they are
addressed. If you are not the intended recipient, please be advised that you
have received this email in error and action should be taken to inform the
originator and this email should be deleted immediately and any copies made
should be destroyed. If you are not the intended recipient, any form of
disclosure, distribution, printing, copying or any other use of this email
or the information in it or in any attachments is strictly prohibited and
may be unlawful. Any views, opinions or other information expressed in the
email and any attachments are those of the originator and not given or
endorsed by General Dynamics UK Ltd.In compliance with the various
Regulations and Acts, please be aware that General Dynamics UK Ltd reserves
the right to monitor all emails and email attachments, both inbound and
outbound, allowing legitimate business practice to continue.In addition to
monitoring, General Dynamics UK Ltd also provides appropriate Antivirus
measures scanning all incoming and outgoing email and email attachments.
However, email communications cannot be guaranteed to be secure or free of
errors as information may be intercepted, corrupted, amended, lost,
destroyed or contain viruses. General Dynamics UK Ltd do not accept
liability or responsibility for any such matters or the consequences
thereof.

15

I actually use Compuwares DriverWorks for the driver, so the architecture
and specific calls are encapsulated in C++ classes. Some people frown on
using DriverWorks, but it has served us well for this application.

The request is queued and STATUS_PENDING is returned. The IRP is completed
when the DMA completes and the PCI device interrupts.

At 07:28 AM 6/7/2005, you wrote:

When an ReadFile operation is called from a user mode application, you will
be called at PASSIVE_LEVEL, I am assuming at this stage you process your IRP
straight away, or do you insert your IRP into a read queue and return
STATUS_PENDING? so that your DMA data transfers is done <= DISPATCH_LEVEL?

Russ Poffenberger
Credence Systems Corp.
xxxxx@credence.com

16

>At this point I should be at a stage where I can manually program my PCI
device DMA to

start the data transfer from the PCI device DMA to my mapped scatter gather
list. (Is this
correct?)

Correct.

Now the question is am I on the right track here?

Correct. BTW - common buffer is not necessary for this. It is only necessary if
your device can interpret the SGLs in the host memory (in some format) by its
hardware. This is called “chain DMA”. In this case, you need to create the
common buffer for these SGLs and manually convert the Windows’s SGL to your
hardware SGL.

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

17

Roddy, Mark wrote:

Generally you need a common buffer for continuous transfers between
device memory and system memory, for example you might end up with a
design where your device dma scatter gather lists are actually
constructed in system memory using a common buffer. Call that type of
arrangement ‘common buffers for shared control structures’. I have no
problem with that sort of arrangement. Less typical would be a need for
a common buffer for data IO transfer in either direction, particularly
when your device does scatter gather bus master dma. If you need a
system memory region for shared control structures, use a common buffer.
If you think you need a common buffer for data IO transfers, rethink
your design.

I’d like to explore this just a bit, if you don’t mind. This issue
doesn’t seem quite so clear-cut to me. Common buffer DMA has some clear
advantages in simplicity of design and survivability in extreme
situations, and at this point in my career, I have come to place a lot
of weight on design simplicity.

We created an AVStream TV capture driver for a PCIExpress device. The
device has a very small buffer (a few K bytes), and relies on bus
mastering to keep the data streaming. The device can do
scatter/gather. It uses a chain of buffers, one per video field. It
signals an interrupt at the end of each field, and then moves on to the
next buffer in the chain.

The device cannot stop transferring, unless I stop it. When it finishes
a field, it’s going to move on to the next field buffer, whether I’m
ready or not. I eventually decided to implement this using a common
buffer approach: I allocate four field-sized buffers at some point
during initialization, lock them down, and chain them together in a
ring. Now, if user-mode should happen to get behind, at least the
device won’t go writing into empty space. If the delay is bad enough,
the buffers might wrap, but I can detect that in the interrupt routine.

Knowing DirectShow, I was just not confident enough that I could stay
far enough ahead of the buffer process to guarantee that there would
always be a buffer ready. The price I pay, of course, is an extra
copy. However, even at full pressure (two uncompressed NTSC video
streams with audio), CPU usage is only about 20%.

Would you have called this a bad design decision? In your opinion,
should I have locked and chained the user-mode buffers, and maybe added
a padding buffer as insurance to the end of the chain?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

18

Tim Roberts wrote:

Would you have called this a bad design decision? In your opinion,
should I have locked and chained the user-mode buffers, and maybe added
a padding buffer as insurance to the end of the chain?

Your design works for me. Seems infinitely sensible.

While Mr. Roddy’s statement:

> If you think you need a common buffer for data IO transfers, rethink
>> your design.

is correct for many common cases it’s surely not an absolute.

Consider a driver that I wrote a while back, where the data buffers were
organized into linked pools of blocks of small, medium, and long size.
These buffers were all located within a single common buffer area, and
were linked together by “pointers” that were actually offses from the
beginning of the common buffer area.

The device returned its data by allocating some number of small, medium,
and large buffers (according to the size of the data it was returning)
and placing “pointers” to these data blocks into a ring-structure, that
was also located in the common buffer area. Again, the “pointers” in
question were offsets from the beginning of the common buffer area.

On an interrupt indicating a read complete, the driver ran the ring,
copying the completed data packets back to the appropriate user buffers.
Yes, this required an additional copy operation, much like that
required by Mr. Roberts’ design.

So, there are surely reasonable examples where data IO transfers using a
common buffer approach are valid and may, in fact, be the only way a
particular device can be supported (as was the case for the driver I wrote).

Peter
OSR

19

Would I have called this a bad design?

Not at all. Looks to me like you compensated for the inadequate
buffering in the hardware in your driver, at the cost of the extra copy.
Perhaps I forgot to put sufficient warnings around admonitions to do
such and such this way, that there are exceptions, and good engineers,
knowing what they are doing, are there precisely to break ‘the rules’
when that is the right thing to do.

On the other hand, for people just starting out, the rules are where one
starts. Too often we see people here starting out by doing everything
wrong and asking why they are surrounded by a pile of rubble.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, June 07, 2005 1:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Supporting DMA confusion…

Roddy, Mark wrote:

Generally you need a common buffer for continuous transfers between
device memory and system memory, for example you might end up with a
design where your device dma scatter gather lists are actually
constructed in system memory using a common buffer. Call that type of
arrangement ‘common buffers for shared control structures’. I have no
problem with that sort of arrangement. Less typical would be a need for

a common buffer for data IO transfer in either direction, particularly
when your device does scatter gather bus master dma. If you need a
system memory region for shared control structures, use a common
buffer.
If you think you need a common buffer for data IO transfers, rethink
your design.

I’d like to explore this just a bit, if you don’t mind. This issue
doesn’t seem quite so clear-cut to me. Common buffer DMA has some clear
advantages in simplicity of design and survivability in extreme
situations, and at this point in my career, I have come to place a lot
of weight on design simplicity.

We created an AVStream TV capture driver for a PCIExpress device. The
device has a very small buffer (a few K bytes), and relies on bus
mastering to keep the data streaming. The device can do scatter/gather.
It uses a chain of buffers, one per video field. It signals an
interrupt at the end of each field, and then moves on to the next buffer
in the chain.

The device cannot stop transferring, unless I stop it. When it finishes
a field, it’s going to move on to the next field buffer, whether I’m
ready or not. I eventually decided to implement this using a common
buffer approach: I allocate four field-sized buffers at some point
during initialization, lock them down, and chain them together in a
ring. Now, if user-mode should happen to get behind, at least the
device won’t go writing into empty space. If the delay is bad enough,
the buffers might wrap, but I can detect that in the interrupt routine.

Knowing DirectShow, I was just not confident enough that I could stay
far enough ahead of the buffer process to guarantee that there would
always be a buffer ready. The price I pay, of course, is an extra copy.
However, even at full pressure (two uncompressed NTSC video streams with
audio), CPU usage is only about 20%.

Would you have called this a bad design decision? In your opinion,
should I have locked and chained the user-mode buffers, and maybe added
a padding buffer as insurance to the end of the chain?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com