On Alpha, a scatter-gather solution is the *only* way to allow all devices
direct access to all of memory. Without it, one is forced to employ bounce
buffers.
> On alpha scatter-gather is simply an address translation scheme that allows
> small granularity (8kb). I don't know how much kernel support beyond
> bus_alloc/virt_to_bus/bus_dealloc would be required to implement bounce
> buffers using the scatter-gather mappings. Perhaps someone who understands
> bounce buffers would care to comment? (I'm still not sure what they are... )
Bounce buffers are buffers in memory at locations that can be accessed
directly by devices, in a system which has additional memory which CANNOT be
directly accessed by those devices because of their addressing limitations.
This has been most commonly encountered with "true" ISA devices, which have
a memory address limitation of 16Mb (24 bits). In a machine which has more
than 16Mb of memory, a device driver could allocate a buffer in the low 16Mb
of the address space, do the device DMA to that buffer, and then copy the
data out of that buffer to a memory location above 16Mb, hence the name
"bounce buffer".
And one would not use SG mapping to implement bounce buffers; SG mapping
eliminates the need for bounce buffers.
> I wonder if it would be possible to take a poll of hardware owners to
> determine which chipsets support scatter-gather. I don't know if this is
> part of the PCI spec, or a hack implemented by Digital and Sun.
It is NOT part of the PCI spec; it is a platform specific feature, implemented
(differently) on the ALPHA and SPARC, and probably others.
> Will Merced chipsets support scatter-gather?
No idea, but this would prolly be covered by an NDA at this time, anyway... ;-}
> At any rate, a generic
> bus_alloc/bus_dealloc should be able to hide whatever memory->bus remapping
> the hardware supports...whether scatter-gather exists on all chipsets or
> not.
If correctly designed.
> Most importantly: if bounce buffers are required to access memory >1GB from
> PCI, can it be done with a simple bus_alloc/virt_to_bus/bus_dealloc? Or
> must we implement a more complex solution that can handle both cases?
Well, let examine it...
Case 1: bus_alloc where direct access is possible without SG mapping, is
simply the equivalent of virt_to_bus now. bus_dealloc is a no-op.
Case 2: bus_alloc where SG mapping must be used to directly access memory,
returns the bus address (in the SG map) for the desired destination.
bus_dealloc will release the SG mapping resources used.
Case 3: bus_alloc where bounce buffers are required, simply returns the
bus address of an allocated bounce buffer. bus_dealloc would copy
the bounce buffer to the desired destination, and free the bounce
buffer.
A bit overly simplistic, but did I miss/overlook anything? Does this seem
reasonable?
--Jay++
-------------------------------------------------------------------------------
American Non Sequitur Society: we don't make sense, but we do like pizza...
Jay A Estabrook Alpha Motherboards - LINUX Project
Compaq Computer Corporation (508) 841-3241 or (DTN) 237-3241
334 South Street, Shrewsbury, MA 01545 Jay.Estabrook@digital.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/