Re: Recently removed io accessors

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2006-10-13 at 08:56 +0200, Peter Korsgaard wrote:
> >>>>> "BH" == Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> 
> Hi,
> 
> >> Any chance of getting them back or should I implement a (slower)
> >> loop myself before submitting the patch?
> 
> BH> Well, a "packet buffer" should have no endian. When streaming in
> BH> our out a fifo, you basically stream bytes that happen to come out
> BH> 2 at a time.  So unless somebody wired the hardware backward, you
> BH> should do no swapping when using the fifo.
> 
> I agree in principle, but the issue gets complicated by the fact that
> the chip works in chunks of 32bit, but the 911{5..7} chips only have a
> 16bit interface to lower costs, and that the chip has a builtin endian
> swap feature (which works for all direct registers, but apparently not
> for the packet buffers).
> 
> The memory controller automatically translates a 32bit access to two
> 16 bit accesses.

Well, that is not necessarily broken :)

> You could be right that the hw people screwed something up, but that
> doesn't help much once there's units in the field :/

Well, I still don't see it. It all depends how the HW has been wired I
suppose but you should not need byteswap regardless of the 32 bits being
broken in packs of 2x16 bits or whatever... If the chip has a HW
byteswap for registers and not for the packet buffer, that makes it even
more clear that such swapping should not be necessary.

Unless the chip has been wired backward on the processor bus (in which
case, btw, DMA will not work either unless you have one of those
magically swapping dma controllers)..

So I still claim that you should not need them and if you do, then the
chip has probably been incorrect wired to your CPU bus. In which case,
you can either grab an old copy of the functions and put them in your
driver for your platform or add a cpu_to_leXX() loop to byteswap the
data in/out, but it's probably not the right thing to do in the generic
driver since it would be a problem specific to your board.

Unless I'm missing something ... It would be useful to have more details
about your setup.

Cheers.
Ben.