> On Aug 21, Ken Nakata wrote
> > Does this mean the stream ones have to _cancell_ the effect of
> > a byte-swapping bridge between host and I/O buses?

On 20 Aug 1998 16:31:40 -0700, Chris G. Demetriou wrote:
> Yup.

On Fri, 21 Aug 1998 09:55:12 +0200, Manuel Bouyer wrote:
> It's quite possible. Let's say you want to write data to the fifo of
> an ethernet board with 32bit access. You don't want to byteswap the
> ethernet packet you're writing !

Thanks, but I'm confused.

Let us consider the Macintosh IDE interface.  IDE bus is a little
endian bus, whereas host bus is big endian.  And there is a
byte-swapping bus bridge between the two so that bits 0-7 of IDE bus
are wired to bits 24-31 of the host bus, and bits 8-15 to bits 16-23.

When CPU transfers a data block to/from the drive, byte N in host byte
order is also byte N in I/O bus byte order because of the bridge.

Now, wdc.c uses bus_space_{read,write}_multi_stream_[24]() for data
transfer.  If these functions cancell out the effect of the bridge,
byte 2*N in host byte order will be byte 2*N+1 in I/O bus byte order,
and byte 2*N+1 will be 2*N.  This is not desirable.

However, when reading the parameter block from the drive
(WDCC_IDENTIFY), I want the upper bytes of the block being read from
the drive to be the upper bytes of the block read into the host's
memory, the lower bytes to be the lower bytes.  That is, I want to
cancell out the effect of the bridge.  

Wdc.c uses bus_space_read_multi_2() for this, which is supposed to let
the bridge byte-swap (?).

It seems that bus_space_*_stream_*() and bus_space_*_*() do the
opposite of what I want them to do.  What's the source of my
confusion?

Ken