On 02/07/2013 08:44 PM, Grant Likely wrote:
Then that data needs to be stored into memory. This is where things
are different with native 16 bit stores:
On a BE memory system. MSB in byte address 0 and LSB in byte address 1.
On a LE memory system. MSB in byte address 1 and LSB in byte address 0.
The block subsystem deals with byte oriented buffers; so given the way
data is arranged in the data port we want to always make sure the LSB
goes into address 0. The cause of problems isn't the BE vs LE bus
attachment. It is the different memory system orientation. Using
ioread16/iowrite16 has the right behaviour, but it's kind of a
backwards way to go about it.... It isn't that we want a be16_to_cpu()
or le16_to_cpu() on the data port read, but rather a cpu_to_le16() on
the store to memory regardless of the endianess of the platform.
So, if I'm correct that means that for the data port (specifically
copying between RAM and the data port) using ioread16/iowrite16 on the
data port results in the correct behaviour. It also means that LE
support in the current driver is broken.
That matches my earlier note when I wrote that for correct work on LE
(note I'm on ARC, not PPC/MB) I needed to use "io{read|write}16" in
"ace_data{in|out}_le16".
With original "io{read|write}16be" instead data was corrupted.
-Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
