On Mon, Nov 21, 2005 at 09:27:16AM -0800, Garrett D'Amore wrote:
> I have a processor which can run in big-endian mode and supports a PCI bus.
> 
> The problem is that this processor likes to auto-swap PCI accesses, so
> that it matches the host CPU endianness.  (Meaning 32-bit reads are
> converted from PCI little endian into native big-endian dwords on the host.)
> 
> This is probably a wonderful thing for performance for most things, but
> I'm worried about two cases:
> 
> 1) streaming reads/writes -- drivers that use these don't want the swap
> -- so I guess I can provide a different bus implementation that swaps
> for streaming accesses (if this sounds backwards it is because it is
> backwards)
> 
> 2) linear mappings.  Some device drivers out there (e.g. framebuffers)
> expect to be able to linear map register or device memory.  (Some of the
> occurrences of linear mappings are probably an error in the driver -- as
> all the accesses occur thru bus_space_XXX routines).  If these drivers
> don't know about the endian swap that automatically happens, it could be
> bad.  (Machfb and igsfb explicity test for this, btw.)
> 
> Questions:
> 
> a) is a custom bus_space implementation the best way to handle this
> nonsense.  The alternative, I suppose, is to just not support stream
> operations on this bus.  (Which means that things like IDE and wi will
> not work.)

Yes, it is. Some ports already handle this for other busses (amiga or atari,
I never remeber which one, has the IDE port wired in the "wrong" order).

> 
> b) should I support linear mappings of the bus space in case 2 (with the
> result that some devices may give "unpredictable" results) or should I
> just not support the linear mapping (which causes these devices to fail
> cleanly in attach, but may exclude some things like machfb/igsfb that
> can cope with this.

PCI is a little-endian bus, if there's no way to provide a little-endian view
of the bus (in this case if the swapping can't be turned off in hardware)
then memory mapping should fail.

> 
> c) for devices that incorrectly use linear mappings but don't actually
> use the linear mapping feature, should I try to fix them?  (examples:
> if_vge.c does no direct accesses, if_ti.c does use them for descriptor
> rings, but doesn't really need to)

Yes, at last for thoses you can test.

> 
> d) should we provide some special bus_space mapping flag to indicate
> that a bus endianness is assumed/required by the driver, which could be
> used to provide for clean failures of bus_space_map when both linear and
> endianness considerations cannot both be met?

Hum, maybe. Or have bus_space provide the needed information to the
drivers. Note that big/little endian isn't the right kind of information
here, what the driver needs to know is if the mapping is byte-swapped and on
which boundary.


-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--