[lkml]   [2013]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)
On 02/05/2013 04:38 PM, Michal Simek wrote:
> 2013/2/5 Benjamin Herrenschmidt <>:
>> On Tue, 2013-02-05 at 11:54 +0100, Michal Simek wrote:
>>> xilinx ppc is big endian
>>> xilinx arm is little endian
>>> xilinx microblaze is little endian and big endian
>> You are talking about the core, why should the xsysace block driver be
>> synthesized with the same endianness as the core ? That's not terribly
>> useful, especially since reverse load/stores on ppc are essentially
>> free...
> It is done by hardware guys and I can do nothing with it.

From this document
( I
can tell that Xilinx System ACE CF solution is a chip manufactured in
silicon, here's an extract:
As shown in Figure 1, the System ACE CompactFlash solution is a chipset,
consisting of a controller device (System
ACE CF controller) and a commercially available CompactFlash storage

and its endianess is fixed which is stated in this document
The Xilinx System ACE Compact Flash chip is a true little-endian device

But in its turn Xilinx System ACE Compact Flash chip is attached to
CPU's interface bus via some bridge. Depending on interface bus used it
could be BVCI-to-MPU (Microprocessor Interface of the System ACE
Compact Flash solution peripheral) for ARC, PLB for MicroBlaze etc.
And this bridge in general may do whatever its (HW) developer wants.

For example for MicroBlaze Xilinx has its XPS Sysace interface
which does bit-swapping from PLB's big-endian bytes to xsysace
CF-controller little-endian bytes (though bytes in words are not swapped):
The Xilinx System ACE Compact Flash chip is a true little-endian device
and the PLB is a big-endian bus. Therefore the XPS System ACE Interface
Controller will do a bit-swap in each byte when connecting the PLB data
bus to the System ACE data bus as shown in Table 2.

Note however, that the XPS System ACE Interface Controller does not
perform the byte swapping necessary to interface to a little-endian
device when configured to use 16-bit mode. Therefore, the software
drivers provided for this core will perform the necessary byte-swapping
to correctly interface to the Xilinx System ACE Compact Flash chip as
shown in Table 3.

So at this point I'd say that data access should be done differently
depending on HW (bridge) used.

Another question is do we know for sure that for particular architecture
only 1 interface bridge is used. If so then we may select proper
accessors per architecture.

>>> It is just sharing the same IP across all platforms. Which is better
>>> than create new devices and new device drivers for it. It means that
>>> all of them are register compatible but require access with native
>>> platform endianness as I listed above.
>> Every attempt at doing "native platform endianness" has always been a
>> misguided attempt turning into a trainwreck (see OHCI USB).
>> Just pick one endian for the device and stick to it.
> It is reality and I can't change it. Arnd mentioned it earlier that USB
>>> It is not a problem to create runtime wrapper and even detect endian
>>> directly in the driver
>>> but the point if this is the proper design.
>>> Also ioread32 and ioread32be shouldn't be used on ARM because there
>>> are missing memory barriers.
>> Then fix them, they shouldn't be, it's a bug, it will break many other
>> drivers. They should be fully equivalent to readl.
> I want to be sure about this. I have parsed this again with closer look and
> seems to me that ioread32 is equal to readl and iowrite32 to writel.
> Arnd: Am I right?
> Thanks,
> Michal


 \ /
  Last update: 2013-02-05 15:41    [W:0.120 / U:2.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site