Subject: bus_dma enhancement needed? (was Re: netbooting an OF 1.0.5 macppc
To: Jason R Thorpe <email@example.com>
From: Eduardo Horvath <firstname.lastname@example.org>
Date: 04/05/2000 08:53:40
On Wed, 5 Apr 2000, Izumi Tsutsui wrote:
> In <email@example.com>
> firstname.lastname@example.org 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?