On Wed, 5 Apr 2000, Izumi Tsutsui wrote:

> In <6806.954915188@eterna.com.au>
> mrg@eterna.com.au wrote:
> 
> >    Does PCI isp SCSI support DMA with big endian hosts?
> >    If no, some byte-swap macros are needed in /sys/dev/isp.c
> >    for DMA transfers, but they would break SBUS isp code.
> >    I think hme_pci might have the same problem.
> > 
> > UltraSPARC PCI already does various dances to get accesses
> > performed in the correct manner...
> 
> Well, then does the PCI-host bridge on sparc64 do byte-swapping
> even when the PCI bus-master accesses memory on its host via DMA?
> Other PCI drivers which contain byte-swapping code would not
> work on sparc64?

sparc64 is a complicated  beastie.  The CPU has a multiplexer and the bus
controller has a multiplexer, both of which can be turned on or
off.  Since the hme was originally developed as and SBus device, I presume
its in-memory datastructures are big-endian.  (I really need to find some
time to go through the manuals.)

> BTW, it seems that /sys/dev/ic/hme.c has bus_dmamem_alloc() and
> bus_dmamem_map() but no bus_dmamap_load() nor bus_dmamap_sync()...
> Anyway, does hme pass non byte-stream (like u_int32_t) data via DMA?
> if no, no byte-swapping code is needed even on other big endian archs.

It's beginning to look to me that we need to add some bus_dma accessor
routines that behave like the bus_space accessor functions, but are used
to access DMA mapped memory (hence have different cacheability) and
supply a required endianness for the final device.  That way drivers
aren't being littered with h2le calls all over the place.

Or are the existing bus_space accessors supposed to be used for this too?

Eduardo Horvath