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.

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.

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).


So, given that, I think i strongly object to these interfaces as
proposed; i don't see them as having general utility.

I'd say before we attempt to adopt them as "standard" to be
implemented by lots of ports on pain of driver incompatibility:

(1) several drivers should be converted over to using interfaces like
them, and

(2) some demonstration of hardware ability to enhance the result
should be shown for the 'not native endian' case.  i.e. if in that
case it always ends up degenerating to simple byte swaps in the MD
code, it's not worthwhile, at least in the "bus_dmamem*" code.


(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.)


cgd