Mark,
I’m used to viewing the “map register” as an equivalent of a page table
entry, which is used by a peripheral device rather than a CPU. I can imagine
a 64-bit machine that has more than 4Gb of physical memory and also has map
registers implemented in hardware, to provide a 32-bit virtual address space
for 32-bit bus-master devices, so that Windows doesn’t need to implement map
registers as intermediate buffers in the low 4Gb of physical memory, and
allocate common buffers there, too, for such devices, as would be the case
when the devices are addressing the physical memory directly. In this
machine, map registers can be a limited resource, and common buffers can
consume map registers. I don’t know if such a machine exists or even makes
sense to produce, but Microsoft’s DMA architecture appears to be capable of
handling it.
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
>
> Common buffers, as far as I know, do not consume map registers. They are
an
> abstraction for physically contiguous system memory space that meets the
> alignment, address, and other limitations of the target device and its IO
> bus.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Ivan Bublikov [mailto:xxxxx@yahoo.com]
> > Sent: Monday, October 06, 2003 7:55 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: DMA adapter object, common buffer and
> > mapping registers
> >
> >
> > Let me re-phrase my question. Let’s suppose I call
> > IoGetDmaAdapter and it gives me 4 map registers. Then I call
> > AllocateCommonBuffer on this adapter to allocate 2 pages. I
> > suppose, this will “tie up” 2 map registers. Does that mean
> > that I now have only 2 map registers left for my future
> > “packet-based” DMA transfers using this same adapter?
> >
> >
> > “Maxim S. Shatskih” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > > Setting up common-buffer areas economically, such as
> > using PAGE_SIZE
> > chunks
> > > > or a single allocation, leaves more map registers available for
> > packet-based
> > >
> > > This is because common buffer allocation can be rounded up
> > to a page.
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > >
> >
> >
> > > Hi All,
> >
> > >
> >
> > > I’m pretty confused by the DDK documentation on
> > relationship between a
> >
> > > common buffer associated with an adapter object and the
> > number of map
> >
> > > registers available for “packet-based” DMA transfers using the same
> > adapter
> >
> > > object, when the mapping registers are temporary allocated for the
> > duration
> >
> > > of transfers. I’m using bus-master DMA. When I create an adapter
> > > object,
> >
> > > initially Microsoft seems to promise me that the number of available
> > mapping
> >
> > > registers for my further “packet-based” DMA transfers is what the
> > > adapter
> >
> > > creation function returns. Then, I read the following:
> >
> > >
> >
> > > ---------------------------------------
> >
> > > Using Common-Buffer Bus-Master DMA
> >
> > > Use common-buffer DMA economically. Setting up a common
> > buffer can tie
> > > up
> >
> > > some (or all, depending on the size of the requested buffer) of the
> > > map
> >
> > > registers associated with the adapter object that represents the
> > bus-master
> >
> > > adapter.
> >
> > >
> >
> > > Setting up common-buffer areas economically, such as using PAGE_SIZE
> > chunks
> >
> > > or a single allocation, leaves more map registers available for
> > packet-based
> >
> > > DMA operations. It also leaves more system memory free for other
> > > purposes,
> >
> > > thus yielding better overall driver and system performance.
> >
> > >
> >
> > > ---------------------------------------
> >
> > >
> >
> > > What is this supposed to mean? Does it mean that I should
> > subtract the
> >
> > > number of mapping registers required by the common buffer I
> > allocated,
> > from
> >
> > > the amount I can use for my “packet-based” transfers? Why
> > does it say
> > > “can
> >
> > > tie up” rather than “will tie up”?
> >
> >
> >
> >
> > —
> > 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
>
>