On Thu, Jul 01, 1999 at 07:09:41PM -0400, Christopher T. Lansdown wrote:
...
> I would like to know, though, how much work would be involved in
> adding scatter-gather DMA support to the kernel. Having read the docs I
> have an idea now of what it actually is, so I'm prompted to a few
> questions:
> 1. Can scatter gather dma be done on a system as well as the dma window
> scheme currently in use so that a driver can simply opt to take advantage
> of it rather than needing to be rewritten?
No.
> 2. Would adding support for it for the alphas require implementing a
> platform-independent method of doing scatter-gather dma and then
> implementing it on the alpha?
Yes. Such would make much more sense, than doing #ifdef __alpha__
all over drivers..
> 3. Is there anyone who's currently working on adding scatter-gather dma
> support, or at least in the planning stages and thus the person to talk to
> in terms of helping?
I am open to talk, I bet others would jump in if you
start writing the thing.
> Again, thank you all for your kind help.
> -Chris Lansdown
>
> --
> lansdoct@cs.alfred.edu
Stephen Williams <steve@icarus.com> wrote:
> lindahl@cs.virginia.edu said:
> > The driver isn't allocating the buffer space, except for bounce
> > buffers. In the scheme you have outlined, this device will never be
> > efficiently supported.
>
> ??!
>
> And how are the bounce buffers allocated? I must be missing something.
>
> If the driver doesn't allocate buffer space, the buffer allocation
> won't affect it, right?
>
> If the driver does direct DMA to a user buffer, and the user's page is
> in physical memory out of range of the device addressing capabilities,
> then something is going to have to change. Either the hardware is extended
> by magic motherboard support, or the driver allocates a buffer that the
> device *can* write to.
>
> What else can be done? This is true now and has nothing to do with my
> allocator interface suggestion.
I would like to add a layer of that "magic" motherboard support,
which in case of Alpha systems means IO-bus specific scatter-
gather address mapping from a fairly small window (usually around
8 M to the entire system memory. If the system does not need to
care about ISA-bus things, a much larger window of temporary mappings
can be used. Needed mapping space is about 1/1000 or 1/500 of the
memory window used for the mapping. Maybe management datasets will
need to double the space expenditure, but if you can manage maps to
e.g. 8G memory with mere 32kB datasets, why would you not do it?)
What would it need ?
When a physical address is to be added into a driver pointers,
that address should be mapped either thru a direct-map window,
or a scatter-gather window. (In most chipsets there seem to be
only one scatter-gather window mechanism, even though any of the
usually four address windows can be used for it.)
For ephemeral mappings a fast lookup mechanisms are needed to
find next free entry, and to find possibly existing mapping
already covering given memory address.
Also a fast way to move used (and no longer needed) mapping slot
into a free list is needed.
It is likely that e.g. for skbuf content pointers several skbuffs
will reside in the same 8kB page, and thus a definite 'in use
count' is needed at each mapping slot.
Once the basic mapping machinery exists, the way to modify the
drivers would simply be something like:
busaddr = BUSSGMAPPER(memaddress);
where the macro hides away most of the painfull details..
... for that matter, in fact that 'BUSSGMAPPER()' can be called
'virt_to_bus()', in which case we wont need to touch into most
of the driver source -- except that all SG mapping RELEASES
still need doing at some point, e.g.:
'bus_map_release(busaddr);'
Hmm... but still there is lack of call parameter above, at what
IO-bus the given device is operating must be given above, thus
likely changeing the current:
virt_to_bus(memaddress)
to something like:
virt_to_bus(memaddress,dev->bus)
Admittedly in most cases especially the 'pci_bus' thing refers
to a bridged segment under the same pci/memory controller, but
getting the system to run at e.g. DEC 8400 system requires support
for multiple IO-bus controller modules. Possibly the PCI-bus
index will do it thru some additional mapping. However do note
that we will need quite often also separate bus-entries for all
instances of ISA limited bus-master devices.
> I'm just suggesting that if the driver must allocate buffer space that
> the device can access, the kernel allocator should provide a means for
> the driver to make that request. Currently, there is the GFP_DMA flag,
> but I'm suggesting generalizing that by simply saying to the allocator
> how many bits of address the device has. That's 32 bits in the case of
> most PCI devices. (Many do support DAC that gets one up to 64 at the
> expense of a bus cycle.)
Hmm... Yes, these measures (e.g. GFP_DMAPCI32) may be needed
for systems which don't have 'magic motherboard support'.
(Which covers all of intel systems, I think..)
> --
> Steve Williams "The woods are lovely, dark and deep.
> steve@icarus.com But I have promises to keep,
/Matti Aarnio <matti.aarnio@sonera.fi>