On Mon, Nov 21, 2005 at 10:16:50AM -0800, Garrett D'Amore wrote:
> mickey wrote:
> 
> >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;
> >  
> >
> Yep.
> 
> >- 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)
> >  
> >
> This one is the problem.  The problem is that I can handle the bus_space
> implementation so that it does the right thing, but that linear mapping
> is screwed up.  I guess I can just punt on this and let devices that
> expect to be able to linear map and get little endian registers break
> when the processor is used in big-endian mode.  (This is a dual mode
> processor.)

well almost all pci drivers expect little endian registers (:
except for those that handle few rare big-endian pci devices.

> >- data that comes or goes from/to device by dma is never swapped.
> >  
> >
> Right, that is not a problem, as I have separate programming for DMA.

cu

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