On Thu, Jul 22, 2004 at 03:13:10PM +0200, Jochen Kunz wrote:
> Hi.
> 
> Is this a valid use of bus_dma(9)?
> 
> 	bus_dmamem_alloc(x_segs)
> 	bus_dmamem_map(x_segs)
> 	bus_dmamap_create(x_map)
> 	bus_dmamap_load(x_map)
> I.e. the usual way to get some DMA memory and later...
> 	y_segs[0] = x_segs[0]
> 	y_segs[0].ds_addr += sizeof(some_thing);
> 	y_segs[0].ds_len = sizeof(some_other_thing);
> 	bus_dmamem_map(y_segs)
> 	bus_dmamap_create(y_map)
> 	bus_dmamap_load(y_map)
> 
> Thus resulting in a double mapping of the previously allocated and maped
> "x" DMA memory. The physical "y" memory is subregion of the physical "x"
> memory mapped at a different KVA.
> 
> To me this looks wrong. The "y" memory should be handled as an offset of
> the "x" memory and a driver should never modify or "self create" a DMA
> segment / map. (At least that is the way I understand bus_dma(9).)

bus_dmamem_alloc(9) says:
            The mapping of this memory is machine-dependent (or "opaque");
	    machine-independent code is not to assume that the addresses
	    returned are valid in kernel virtual address space, or that the
	    addresses returned are system physical addresses.  The address

To me, this means that we can't make any assumptions about the values returned
by bus_dmamem_alloc(), and especially it's wrong to assume we can do
memory-related operations on ds_addr/ds_len.
If this is really needed, we may need a bus_dmamem_submap(), or something
like this.
But I have the feeling that this could be handled in some other ways,
maybe with device-dependant macros or functions, like siop/esiop does.

> 
> Background: fpa(4) does the above. It fails on hp700 for this reason.
> I now need to decide if the hp700 bus_dma(9) code needs fixing (my
> problem) or if fpa(4) needs fixing (not my problem ;-) ). 

My guess is that fpa(4) needs fixing. I suspect it may have problems on
platforms like sparc64 for the same reason.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--