> Chris G. Demetriou writes:
> 
> >The 16-bit and 32-bit methods _should not_ be used for streams of
> >bytes.  They are meant to access multi-byte data items, and accessing
> >groups of single byte data items with them is _incorrect_.
> >
> >If you want to access multiple data items "efficiently" (regardless of
> >their size) {read,write}_multi_* are the interfaces to use, and should
> >be used with the correct data item size.
> 
> That is _not_ a technically accurate description of the bus_space
> interface, either as used up to this point, or as documented, either
> for the 1.2 version or for the -current/1.3 version.  If you want to
> change the interface semantics to mean that, go head and do so, but
> please don't lie to us about it being a change.

Uh, that's what the interface semantics have _always_ been, starting
from way back when when i was working on bus_space's predecessor on
the alpha and Jason hadn't even thought about it much.

Feel free to improve the docs.  However, you might try to avoid
telling me what a set of functions which I had a large part in
designing are "supposed" to do.


> I can see why you'd want your claim to be true: If the the bus_space
> interface mandates single-byte-width methods for ``bytestream'' data,
> then multibyte methods could do the byteswapping you want them to do,
> and everything would Just Work.

The multibyte methods could do the byte swapping that they do, OR the
hardware could do the byte swapping.

That's something that hardware DOES do on some systems (indeed, on
many systems i've been exposed to).


> And how *do* you propose to handle the problems of writing drivers for
> PIO devices with wider-than-byte (16 or 32-bit) FIFO registers, using
> only byte-width methods, when the hardware (bus or device) doesn't
> support byte accesses the way it has to for this to work?

Swap the byte order back in the driver.

If you want to add a few functions that do it to the bus_space
interfaces, fine, do so.  I recognized long ago (and stated, to some
people working on the bus_space interfaces) that such interfaces might
be nice to have eventually. However, just as now some big-endian-CPU
systems have to byte swap in the existing methods for multi-byte data
access, others would have to byte swap in the multi-byte-access
byte-stream functions you'd want to add.

I'd say that efficient, machine-independent multi-byte register access
is much more important with modern (DMA-capable, not "broken, PIO")
hardware.  Therefore, at least to my mind, it makes sense to
accomodate that first.


> And even for devices where this does work, how about the efficiency
> problems of a fourfold increase in the number of bus cycles?

You could do the swapping in the driver.  There are really two ways
this all can work:

	(1) bus bridge does swapping on multi-byte accesses, or

	(2) bus bridge does no swapping on multi-byte accesses.

(1) means you don't have to do anything special for the existing
functions, but would for "read byte stream N bytes at a time"
functions.

(2) means the opposite.


"see above" for my notion of what should be optimized, and why.


cgd