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

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


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134