> 
> On Wed, 27 Oct 1999 11:18:12 -0700 
>  Matt Thomas <matt@3am-software.com> wrote:
> 
>  > But it can be handled by bus_dma(9).  Specifically, bus_dma_sync can
>  > do any required endian conversions.
> 
> But that's not appropriate!  Not only that, it's more expensive.  Consider
> a case where the data has been written to memory, and the bus_dmamap_sync()
> function now needs to load/swap/store ... wereas it could have been swapped
> in a register before being stored to memory in the first place.

Things can get significantly more complicated than this if there is
some hardware along the DMA path that wants to be helpful and does
byte-flipping for you.  A bus driver might need to load/swap/store on
a particular boundary to counteract the effects of such `helpful'
hardware.

Arguably that is broken hardware and you can decide it's not worth
supporting, but if you really want to be general about this you need
to take that into account.

> Basically, the only place where you can really know these things is
> in the device driver.  So, in order to work everywhere, you need to
> allow the device driver to have control.  The device expects little-
> endian data in some fields?  The driver should ensure that the data is
> little-endian.  The device expects big-endian data in some fields?  The
> driver should ensure that the data is big-endian.

Do you really want the driver to use the host's endianness and the
particular bus to decide whether the data needs to be swapped?
Wouldn't you prefer the driver use some bus operation to store this
datum in a form that the device gets it in little-endian order?  

I would prefer in this case to map the page in little-endian and have
the hardware take care of the byte-swapping rather than make use of
the expensive bswap*() routines.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me