Subject: Re: PCI-audio & endianness (eso.c/mulaw.c)
To: Matt Thomas <matt@3am-software.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 10/27/1999 11:34:31
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.

Consider the case of syncing tulip transmit information, I want the 4
32-bit fields of the descriptor byte-swapped, but when I sync the data
buffers, I want those to be left alone!

Ok, now, what if it's 8 16-bit fields?  What if it's 4 16-bit fields
and 2 32-bit fields?

Furthermore, it's possible to program some devices to interpret things
as big-endian or little-endian.  For example, the Tulip can be programmed
to interpret the descriptors and setup packet as big-endian.  (Nevermind
that this doesn't *work* on most devices I've tried this on... :-)

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.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>