On 31 Jul 2000, Chris G. Demetriou wrote:

> Eduardo Horvath <eeh@turbolinux.com> writes:
> > > * HBA which can support byte swapping, and does byte swapping on PCI
> > > "word" (4-byte naturally aligned) boundaries.  i.e., it's willing to
> > > do:
> > > 
> > > 	(BE) mem addr 0:	1
> > > 	(BE) mem addr 1:	2
> > > 	(BE) mem addr 2:	3
> > > 	(BE) mem addr 3:	4
> > > 
> > > 	->
> > > 
> > > 	PCI byte 0 (BE#[0]):	1
> > > 	PCI byte 1 (BE#[0]):	2
> > > 	PCI byte 2 (BE#[0]):	3
> > > 	PCI byte 3 (BE#[0]):	4
> > 
> > Looks like you're allways reading the same location there 8^).
> 
> yeah, yeah, you know what i meant.
> 
> 
> > > I'd argue that that's highly bogus.  8-)
> > 
> > That is not `highly bogus'.  The swapping must be done on the "unit of
> > access".  Anything else is broken.  Your so-called `swapping' device's
> > unit of access is 4.  Hence, if you insist on taking advantage of that
> > `swapping' you need to always do rmw accesses through
> > bus_dmamem_{read,write}_4.
> 
> Right, so, what you'd saying is, your interface _only_ addresses
> device capabilities, and has nothing to do with the bus capabilities.

The bus framework should be using bus capabilities to optimize
communication to devices.  If the bus has a capability to do byte swapping
properly and using it can improve performance then it should be used.

> Fundamentally, it seems that what you're asking for, in these misnamed
> bus_dmamem_*() macros, is for MD code to provide 'bus' macros to to
> access memory in device-specific ways.

And the distinction is?  The point of the macros is to make the cpu access
memory in the same manner as the device that will DMA it.  The precise
wiring can vary depending on CPU, bus controller, and device.  The device
driver should be able to explain to the bus_dma framework how it wants
that set up and not have to worry about byte swapping itself.

> bus_* exists to abstract the features of busses in ways that drivers
> can use.  Device-specific code belongs in device drivers, generic bus
> feature abstractions belong in the bus_* code.
> 
> I don't see why you can't just as easily make do with
> per-device-driver macros (and that makes sense to me since you also
> need to tweak an LE/BE switch on the device anyway for the vast
> majority of devices -- i dunno about yours specifically).

Why should every device be forced to use macros and pay the cost of
byte-swap code if the MMU/DMA setup/whatever can be can be configured to
do away with any explicit byte swapping?  Especially if there are no byte
swap instructions so byte swapping is an expensive multi-cycle process?

> (BTW, based on my knowledge of what hardware's out there, and its
> capabilities, i'd say that my model of operation would provide
> improved operation to more drivers, by virtue of using byte-swapping
> bus interfaces where available.)

The problem with your implementation, especially your hardware
implementation, is that while you get rid of the byteswaps for structured
data types, you require byteswaps for stream data, so if you want to write
a page of data to disk you need to byte-swap the page first.  Doesn't look
like a win to me.

Eduardo Horvath