On Aug 21, Ken Nakata wrote
> 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.

So it does byte-swap of 32-bits, where IDE access are all 8 or 16bits
(32bits access to the data port is a controller's feature: it turns this
out to 2 16bits access to the disk).
This may cause some problems, yes.

This also means that you have to do all the access with 32bits I/O ?

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

I'm not sure why you say it's not desireable.
The ATARI mainbus IDE controller also does byte-swap.
Unless the bus_space_{read,write}_multi_stream_[24]() functions byte-swap
so that raw access are really raw access, you can't use ATAPI devices.
Also, suppose that you have a disk made on an i386 (LE FFS format).
If you put it in your mac, you want to have the raw data, and let the
filesystem do the byte-swap only where needed.

Now, for the IDE drive, it may not be desirable to undo the bridge byte-swap,
because the bios doesn't do it, so this will prevent the drive from being
bootable. This is why stream/non-stream data port access for ata is
conditionned by the 'WDC_CAPABILITY_ATA_NOSTREAM' flag in the bouyer-ide branch
(the stock -current ATA/ATAPI driver doesn't work properly with the on-board
controller on the atari). For atapi, you always want to use the stream
functions for the data port access.

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

In your case, yes. But you're supposed to do 16 bit byte access, so your
bridge should swap byte N with N+1 (not N with N+4 and N+1 with N+3).
Then, look at the function wdc_get_parms(): it will restore the byte order
for the strings.
In theory, whe should use stream access here, and then byte-swap the
numeric fields. But as all the fields in sc_params are 16bit quantities,
exept the strings, it's simpler to do 16-bit byte-swapping access and
restore byte-order of the strings.


> 
> 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?

1) the WDCC_IDENTIFY command for ATA is a bit hacky
2) the bride byte-swapping is needed for ATA only because of the BIOS,
   and it breaks filesystem compatibility with other architectures.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--