USB support on mpc5200 broken
Carsten Schlote
c.schlote at konzeptpark.de
Wed Oct 1 19:46:29 EST 2008
Hi Ben,
> Note about the Amiga stuff: it's a bad idea :-) Every attempt
> at "magically" fixing endian in HW is a recipe for tears and
> disasters.
I fully agree. It's one of the problem I encountered with some similiar
approach on some other big-endian Freescale CPU. It is implemented as a
hard-wired 'endian-swap feature' and it simply makes everything much
more complicated for code intended to run on LE and BE CPU by virtually
adding some additional special case.
> Approximately ... always. The only cases that I know that
> have a remote chance of being useful are specifically
> programmable swappers on a given device or per-page endian
> configuration in the processor (like BooKE).
Also agree. There might be use-cases, where hardware-supported
endian-swapping might be useful. But it must be an optional feature.
It's already some PITA to develope and maintain drivers running on LE/BE
CPUs and to properly access word and longword PCI registers
endian-transparent. Byte streams should never be affected by endianess
anyway.
Automatic endian-swapping might speed up some register accesses or e.g.
framebuffer accesses (reverse pixel endianess), but in general it adds
more problems than it's worth.
The framebuffer use-case is currently the only one, where such a
hardware-swapper could be really useful. But still the drivers would
have to know about this feature, it would require query/set macros/fcts
for endian translation modes in the kernel, ... - in short it causes
lots of extra overhead. And for framebuffers the need for such hard-ware
swappers can be eleminated by using the right framebuffer mode.
I fear, that such hard-wired 'magic' swapping is the source and reason
for some of my current problems.
Carsten
More information about the Linuxppc-dev
mailing list