Re: [PATCH 02/11] soc/fsl: Introduce DPAA BMan device management driver

["Horia Geantă" <horia.geanta@freescale.com>]

On 7/10/2015 9:50 PM, scottwood at freescale.com (Scott Wood) wrote:
> On Fri, 2015-07-10 at 13:29 -0500, Pledge Roy-R01356 wrote:
>>>   return in_be32((void *)bm + offset);
>>>>          ^
>>>> [...]/drivers/soc/fsl/qbman/bman.c: In function ‘__bm_out’:
>>>> [...]/drivers/soc/fsl/qbman/bman.c:172:2: error: implicit declaration
>>>> of function ‘out_be32’ [-Werror=implicit-function-declaration]
>>>>   out_be32((void *)bm + offset, val);
>>>
>>> These PPCisms will need to be fixed.  LS1043A is an ARM chip with DPAA 
>>> 1.0.
>>
>> LS1043 (ARM, Little Endian) support is still work in progress.  The patches 
>> for that are being tested now but are based on the SDK version of the 
>> driver and will need to be massaged in order to get them applied here.  Our 
>> plan of record is to add upstream support for this at a later time.
> 
> If you're already reworking this for upstream acceptance, why not fix the 
> more obvious PPCisms now?

Other drivers are facing similar problems wrt. I/O accessors.
How should the problem be solved?

For caam driver (drivers/crypto/caam) we have the following combinations:
ARCH	CORE	CAAM		SoC, options
PPC	BIG	BIG		P4080 etc.
PPC	BIG	LITTLE		N/A
PPC	LITTLE	BIG		P4080 + CONFIG_CPU_LITTLE_ENDIAN
PPC	LITTLE	LITTLE		N/A
ARM	LITTLE	LITTLE		LS1021A, LS2085A etc.
ARM	LITTLE	BIG		LS1043A
ARM	BIG 	LITTLE		LS1021A + CONFIG_CPU_BIG_ENDIAN
ARM	BIG	BIG		LS1043A + CONFIG_CPU_BIG_ENDIAN

Not all need to be supported, but for e.g. we are being requested to run
on ARM in BE mode.

Existing MMIO accessors have one of the following drawbacks:
-readl/writel: on ARM do swapping (cpu <--> le), while on PPC are
bus-specific (for PCI)
-have weak semantics (no barriers / sequence points etc.), like __raw_*

Thus, it looks like drivers have to define their own MMIO accessors,
taking into account:
-core endianness (which is independent of arch)
-device endianness
-already-defined MMIO accessors availability, depending on arch
-semantics will have to match

Unfortunately, the code will look terrible. In each driver.

Thanks,
Horia

P.S. Sorry if the To/Cc list is screwed up, I've taken the message from
the archive.