Subject: Re: PCI-audio & endianness (eso.c/mulaw.c)
To: Eduardo E. Horvath <firstname.lastname@example.org>
From: Leo Weppelman <email@example.com>
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 <firstname.lastname@example.org> 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'
> 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
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.