On Fri, May 30, 2014 at 3:30 AM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > Hm... that doesn't sound right. Please see this thread on lkml[1], and > also this video from Ben H.[2] But Benji is talking about the *PCI BUS*, and this is raw register access. He just says that "This is how a BE CPU is normally wired to a LE bus" we have no idea whether that is actually the case on any existing system with this peripheral. Such things have to be tested. > My understanding is that this is a fifo > so I would think we want to use the ioread32_rep() function here (or > other "string" io functionality). Otherwise we're going to byteswap the > data that we're trying to interpret as a buffer and big endian CPUs > won't work. You don't know that until you have tested on real BE ARM hardware with this PrimeCell. How do you know the SoC designers will have been smart enough to insert byte swap logic? >> You are right. readsl() or ioread32_rep() isn't used for this reason. > > We could always use a size of 1 right? What do you mean? Do you mean using: ioread32_rep(io, buf, 1)? Notice this is totally equivalent to readsl() in arm/include/asm/io.h: #define readsl(p,d,l) __raw_readsl(p,d,l) #define ioread32_rep(p,d,c) __raw_readsl(p,d,c) The semantic effect is switching from readl() -> readsl() or conversely ioread32 -> ioread32_rep() which will use __raw accessors in native endianness rather than LE access. Which is what you want if the bus will do byte swapping. Which we don't know if it does, because noone has such a system and can verify. If the native bus is not byte swapping this will just force you to use cpu_to_le32() on the result. That is not helpful at all. We need to experiment with real BE hardware with this PrimeCell to determine whether to do this, and until that is done just don't try to outsmart the hardware by thinking ahead and designing for the unknown, that will just fail. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
