On Fri, May 19, 2000 at 12:51:25PM +0200, Paul Kranenburg wrote:

 > The particular problem for DVMA archs like sun3 and sparc[64] is in
 > dealing with the alignment and boundary arguments to bus_dmamem_alloc().

The same issue exists on the Alpha, actually.  Alphas have SGMAP
hardware that is very much like Sun DVMA (more like Sun4m IOMMU,
really, in that it's not in the CPU's virtual address space).

As I said before, the bus_dmamap_load() routine also needs to deal
with memory that does not meet the boundary/alignment constraints
by breaking up into multiple segments, if possible, or failing.  Things
like e.g. PCI IDE DMA rely on this, as buffer cache pages aren't
allocated by the bus_dma(9) facility.

The reason that you can specify the alignment and boundary constraints
in bus_dmamem_alloc() and bus_dmamap_create() is specifically to accommodate
architectures which DO NOT have SGMAP/IOMMU/DVMA hardware to map the
pages into DMA space according to the constraints.  If bus_dmamem_alloc()
did not provide a way to specify the constraints, much DMA would be
quite impossible on e.g. a PC.

 > Unlike other archs, these arguments do not apply to the physical
 > memory allocated, but to the DVMA addresses allocated at `dma map load'
 > time.  One way of resolving this issue is to apply more rigour to the

Right, this is why I specified in the API definition that memory allocated
with bus_dmamem_alloc() is guaranteed to map into DMA space according
to the constraints specified.  In the case of the Avalon A12, it can be
any page in memory, because DMA on that system is always bounced via a
special SRAM buffer.  On the SPARC, it can be any page, because you can
remap it with the IOMMU/DVMA facilities.  On the PC and on some Alphas,
the memory allocated actually has to match those constraints.

What I'm saying is that the interface was very carefully defined to allow
for this kind of opaque behavior underneath.

I don't see any reason why the current API definition can't be correctly
implemented on the SPARC.

 > A related semantics issue that remains unresolved in bus_dma(9):
 > both dmamap_create() and dmamem_alloc() take a `boundary' parameter.
 > It is not clear what relationship needs to exist between the two
 > if both are present. Note that on DVMA archs both come into view when
 > loading a dma map. Probably, the strictest boundary needs to be applied
 > at that time.

This is a feature -- explained above.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>