On Sun, 16 Apr 2000, Jason R Thorpe wrote:

> On Sun, Apr 16, 2000 at 01:33:57PM -0700, Eduardo Horvath wrote:
> 
>  > If we're talking about DMA memory then we should add an equivalent set of
>  > bus_dma_{read,write}*() routines rather than use htole()/htobe().  
> 
> What exactly does bus_dma_{read,write}*() *mean*?  You mean for reading
> and writing fields in DMA'd data structures?

Precisely.  

[Expounding on the obvous:]

Some devices (NICs, SCSI HBAs, and audio drivers come to mind) like to
have data structures (like scatter/gather lists, etc.) stored in RAM and
DMA them as required.  The data structures must be laid out in RAM in the
order and endianness that the devices require.

To complicate matters, there may be multiple layers of endianness flipping
between the CPU and the destination device's registers:

	The CPU can do byte flipping
	The memory subsystem can do byte flipping
	The I/O bus can do byte flipping
	The DMA engine can do byte flipping
	The DMA channel can do byte flipping
	The destination device can do byte flipping.

What we should do is provide a new set of BUS_DMA flags, BUS_DMA_BIG and
BUS_DMA_LITTLE which the device driver can use to specify the desired
destination endianness when allocating or mapping in DMA.  This could be
used by the bus_dmamem*() routines to provide the required
bit-flipping.  If neither flag is set then it's either a byte or block
transfer where endianness does not matter and the bus_dmamem*() routines
can do whatever is most efficient.

(The Solaris DDI/DKI provide such access routines that do endianness
flipping for DMA memory mappings.  They allow the same driver binary to
work with both SBus ISP1000 and PCI ISP1040 SCSI controllers.)

If you want I can try to code something up for the sparc64 port, though I
don't know if I have the time to write a decent manpage at the moment.

Eduardo Horvath