On 25 Jun 2000, Chris G. Demetriou wrote:

> eeh@turbolinux.com (Eduardo Horvath) writes:
> > Two new flags will be added to bus_dmamap_create(), which will be used to tag
> > the bus_dmamap_t:
> > 
> > BUS_DMA_LITTLE_ENDIAN		The device expects data in little-endian
> > 				format.
> > BUS_DMA_BIG_ENDIAN		The device expects data in big-endian
> > 				format.
> 
> what are the semantics of these?
> 
> specifically, what is the unit of translation from one endianness to
> another, and how can these be used properly by hardware (i.e. bus
> bridges, not the devices themselves) which support automatic
> byte-swapping of DMA transfers in certain regions?

The unit of translation is a bus access, and using these properly is
dependent on proper setup of the hardware. 8^)

Seriously, there are very many different ways to design hardware, and many
ways to use software to work around those issues.  When properly designed,
the destination device will issue DMA accesses in the units that require
swapping.  If that is not the case then there is little option than to
handle swapping in the CPU when writing the data to RAM.

In the case of PCI HME, which is a big-endian device, the DMA engine
automatically does whatever swapping is required so all its accesses are
converted to little-endian format.  The way I would implement this on
sparc64 is bus_dmamem_map() would map the DMA pages int to
the CPU in little-endian layout so the bus_dmamem* accessors would be
simple loads and stores.  The PCI bus DMA engine would read the data,
which is already in little-endian format, directly and pass it
down.  HME's DMA engine would then convert it back to big-endian format as
HME recieves the data.

OTOH, machines that cannot set up inverse-endian mappings will need to
handle byte-swapping as needed in the bus_dmamem*() accessors the same way
it's currently done with bus_space*() accessors.

Does that answer your question?


Eduardo Horvath