Subject: Re: ncr53cxxx driver design issues
To: Jason R Thorpe <>
From: Eduardo Horvath <>
List: tech-kern
Date: 04/18/2000 09:09:00
On Mon, 17 Apr 2000, Jason R Thorpe wrote:

> While I completely understand where Eduardo is coming from, we already have
> some ways to deal with the byte-order problem in DMA'd data structures, of
> sorts...
> If you'll take a look at the SMC 83c170 Ethernet driver, you'll note that
> it does:
> 	... put the device into "data structures are big-endian" mode ...
> #else
> 	... put the device into "data structures are little-endian" mode ...
> #endif
> This can pretty easily handle at least the 720 case.
> As far as handling both 720 and 810 in the same driver, making the
> byte-order decision at runtime:
> 	<example 810 front-end code>
> 	sc->sc_byteorder = LITTLE_ENDIAN;
> 	<example common back-end code>
> static __inline u_int32_t
> LOAD_4(struct siop_softc *sc, __volatile u_int32_t *ptr)
> {
> 	if (sc->sc_byteorder == BYTE_ORDER)
> 		return (*ptr);
> 	return (bswap32(*ptr));
> }
> static __inline void
> STORE_4(struct siop_softc *sc, __volatile u_int32_t *ptr, u_int32_t val)
> {
> 	if (sc->sc_byteorder == BYTE_ORDER)
> 		*ptr = val;
> 	else
> 		*ptr = bswap32(val);
> }
> This just doesn't seem that difficult a problem to me :-)
> I acknowledge that Eduardo would like some sort of generic bus_dma
> enhancement for this, but it seems to me like we're then adding a lot
> of overhead (like the function calls, comparisons, etc.) in places
> where we *KNOW* we won't need it (e.g. any PCI device which is
> hardwired as little-endian).

I prefer to see this in the bus_dma* framework because:

1) It moves complexity from the device driver to the bus_dma*() framework
where I think it belongs.

2) The need for these operations are machine dependent therefore it is
pre-processor tricks can be used (as they are currently used for
bus_space_{read,write}*() routines) so the comparisons are optimized away.

3) The same driver can be used on two devices of different endianness on
the same machine.  (ISP1000/ISP1040).

[ Looking at the code, it seems that HME is big-endian in all cases.  I
don't see any indication that the PCI HME driver does any endian
flipping. Is that right matthew? 

ISP is a completely different kettle of fish.  The ISP1000 is a big-endian
device, hence its DMA structures are big-endian.  The ISP1040 is a
little-endian device.  Its structures are little-endian.  For a driver to 
work with both devices it needs to do byteswapping for one and not the
other.  And yes, I have had machines with at least one of each of these
chips installed. ]

4) The device driver may know what the final device's byte order is, but
does it know whether the bus controller does byte-swapping in the DMA

In other words the device driver can know what the device's desired
endianness is.  But I'm not sure it knows the best way or any way to get
the data to the device in the appropriate endianness.

Eduardo Horvath