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

normally the following rules are used for byte swapping on
the pci host bridges (not to mistake for pci-pci bridges):

- pci config space is always swapped into cpu native byte order;
- device registers/memory (both io- or mem-mapped) either never
  swapped in the bridge and always handled by the bus_space
  functions or swapping is disabled for *_raw_* functions
  (or done manually for those if cannot be disabled)
- data that comes or goes from/to device by dma is never swapped.

cu
-- 
    paranoic mickey       (my employers have changed but, the name has remained)