Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 11 Feb 2014, Izumi Tsutsui wrote:

> mrg@ wrote:
> 
> (now completely off topic)
> 
> > > > FYI:  not all -- sparc64 either maps PCI space as little
> > > > endian or uses little endian accesses, both of which give
> > > > you the byte swapped data directly.
> > > 
> > > Even in that case, the hardware checks access width and
> > > all byte accesses can be done at the same address
> > > as the little endian machines by complicated hardware
> > > (i.e. #if BYTE_ORDER in the patch won't work), right?
> > 
> > right.  i just wanted to point out that sometimes the byte
> > swapping occurs in hardware.
> 
> I also wonder if there is any OS implementation that enables
> that feature for DMA and how the hardware designers considered
> about possible use cases.
> 
> Most bus masters use word access even on fetching byte data, and
> there are also many implementation (memcpy(9) etc) which use word
> access even against stream data (which shouldn't be byte-swapped)
> so access width detection for byteswap won't work as expected.

I think Solaris does, but it's been a while since I looked at the guts of 
DDI.

We really should enhance the bus_dma framework to add bus_space-like 
accessor routines so we can implement something like this.  Using bswap is 
a lousy way to implement byte swapping.  Yes, on x86 you have byte swap 
instructions that allow you to work on register contents.  But most RISC 
CPUs do the byte swapping in the load/store path.  That really doesn't 
map well to the bswap API.  Instead of one load or store operation to 
swap a 64-bit value, you need a load/store plus another dozen shift and 
mask operations.  

I proposed such an extension years ago.  Someone might want to resurrect 
it.

Eduardo