Subject: Re: PCI-audio & endianness (eso.c/mulaw.c)
To: Eduardo E. Horvath <eeh@one-o.com>
From: Leo Weppelman <leo@wau.mis.ah.nl>
List: tech-kern
Date: 10/28/1999 08:53:49
On Wed, Oct 27, 1999 at 12:23:00PM -0700, Eduardo E. Horvath wrote:
> > 
> > On Wed, 27 Oct 1999 11:18:12 -0700 
> >  Matt Thomas <matt@3am-software.com> wrote:
> > 
> >  > But it can be handled by bus_dma(9).  Specifically, bus_dma_sync can
> >  > do any required endian conversions.
> > 

The paragraph below was from Jason I believe...

> > But that's not appropriate!  Not only that, it's more expensive.  Consider
> > a case where the data has been written to memory, and the bus_dmamap_sync()
> > function now needs to load/swap/store ... wereas it could have been swapped
> > in a register before being stored to memory in the first place.
> 
> Things can get significantly more complicated than this if there is
> some hardware along the DMA path that wants to be helpful and does
> byte-flipping for you.  A bus driver might need to load/swap/store on
> a particular boundary to counteract the effects of such `helpful'
> hardware.
> 
> Arguably that is broken hardware and you can decide it's not worth
> supporting, but if you really want to be general about this you need
> to take that into account.

From the bus_space point of view, endiannes is a bus property. I should
probably plaster this on the wall since it seems I keep forgetting this.
So, if the bus hardware is doing byteswaps, it is a special kind a pci-bus.
From this fact, you can conclude that in this case, the driver would have
been attached to be-pci instead of pci. 
I expect there will be very few big-endian only PCI-devices (though I'm
not sure).

Now from the above, I think I can draw the conclusion that the driver
is able to decide how it should setup the DMA data for proper endianness.

Leo.