On Tue, Apr 18, 2000 at 09:09:00AM -0700, Eduardo Horvath wrote:

For the record, I think this discussion should continue on its own, because
it will be a while before this is all fully worked out.  Manuel should
go ahead and make the new SIOP driver work using hacks that I suggested.

We can convert everything later.

 > I prefer to see this in the bus_dma* framework because:
 > 
 > 1) It moves complexity from the device driver to the bus_dma*() framework
 > where I think it belongs.

Ok, I give, and I'm now trying to come up with an API for it.

 > 2) The need for these operations are machine dependent therefore it is
 > pre-processor tricks can be used (as they are currently used for
 > bus_space_{read,write}*() routines) so the comparisons are optimized away.

Right.

 > 4) The device driver may know what the final device's byte order is, but
 > does it know whether the bus controller does byte-swapping in the DMA
 > path?

Okay.

So, I have a few questions/concerns.

First of all, I'm concerned that simply byte-lane flipping in the bus
controller simply isn't going to handle all devices.

What about the device that works like this:

struct foo_desc {
	u_int16_t control;
	u_int16_t status;
	u_int32_t addr;
};

In native little-endian order, it looks like this:

	c0 c1 s0 s1 a0 a1 a2 a3

With bus-controller byte flipping, the result would be:

	s1 s0 c1 c0 a3 a2 a1 a0

which is WRONG.  The result SHOULD be:

	c1 c0 s1 s0 a3 a2 a1 a0

Secondly.. more of a sanity check..

You would specify byte-order at DMA map creation time, right?  i.e. like:

	error = bus_dmamap_create(sc->sc_dmat, sizeof(struct control), 1,
	    sizeof(struct control), 0, BUS_DMA_LITTLE, &sc->sc_cdmap);

...and then you would have to pass the DMA map to bus_dma_read_4() to
read a value:

	val = bus_dma_read_4(sc->sc_dmat, sc->sc_cdmap, &desc->addr);

?

What if you want to have swapped data and octet-stream data in the same
data structure mapped by the same DMA map?  There are real-world devices
where this is necessary (Intel i82557 Ethernet).

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