[v7,2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define

By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are
Little Endian. So add this optional property to help identify
them.

Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.

Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Change in v7:
	- None.

Change in v6:
	- None.

Change in v5:
	- Add 'Reviewed-by: Rob Herring <robh@kernel.org>' to commit message.
	- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
	please see https://lore.kernel.org/patchwork/patch/1101022/

Change in v4:
	- Adjust indectation of 'ls1021a, ls1012a, ls1043a, ls1046a'.

Change in v3:
	- None.

Change in v2:
	- None.

 Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

On Mon, 2019-10-21 at 11:49 +0800, Ran Wang wrote:
> By default, QorIQ SoC's RCPM register block is Big Endian. But
> there are some exceptions, such as LS1088A and LS2088A, are
> Little Endian. So add this optional property to help identify
> them.
> 
> Actually LS2021A and other Layerscapes won't totally follow Chassis
> 2.1, so separate them from powerpc SoC.

Did you mean LS1021A and "don't" instead of "won't", given the change to the
examples?

> Change in v5:
> 	- Add 'Reviewed-by: Rob Herring <robh@kernel.org>' to commit message.
> 	- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-
> cells'.
> 	please see https://lore.kernel.org/patchwork/patch/1101022/

I'm not sure why Rob considers this the "correct form" -- there are other
examples of the current form, such as ibm,#dma-address-cells and ti,#tlb-
entries, and the current form makes more logical sense (# is part of the
property name, not the vendor).  Oh well.

> Required properites:
>    - reg : Offset and length of the register set of the RCPM block.
> -  - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
> +  - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
>  	fsl,rcpm-wakeup property.
>    - compatible : Must contain a chip-specific RCPM block compatible string
>  	and (if applicable) may contain a chassis-version RCPM compatible
> @@ -20,6 +20,7 @@ Required properites:
>  	* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
>  	* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
>  	* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> +	* "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm

Is there something actually called "2.1+"?  It looks a bit like an attempt to
claim compatibility with all future versions.  If the former, is it a name
that comes from the hardware side with an intent for it to describe a stable
interface, or are we later going to see a patch changing some by-then-existing 
device trees from "2.1+" to "2.1++" when some new incompatibility is found?

Perhaps it would be better to bind to the specific chip compatibles.

-Scott

Hi Scott,

On Friday, October 25, 2019 02:34, Scott Wood wrote
> 
> On Mon, 2019-10-21 at 11:49 +0800, Ran Wang wrote:
> > By default, QorIQ SoC's RCPM register block is Big Endian. But there
> > are some exceptions, such as LS1088A and LS2088A, are Little Endian.
> > So add this optional property to help identify them.
> >
> > Actually LS2021A and other Layerscapes won't totally follow Chassis
> > 2.1, so separate them from powerpc SoC.
> 
> Did you mean LS1021A and "don't" instead of "won't", given the change to the
> examples?

OK, I will change it to don't to just tel current situation.
 
> > Change in v5:
> > 	- Add 'Reviewed-by: Rob Herring <robh@kernel.org>' to commit
> message.
> > 	- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-
> > cells'.
> > 	please see https://lore.kernel.org/patchwork/patch/1101022/
> 
> I'm not sure why Rob considers this the "correct form" -- there are other
> examples of the current form, such as ibm,#dma-address-cells and ti,#tlb-
> entries, and the current form makes more logical sense (# is part of the property
> name, not the vendor).  Oh well.
> 
> > Required properites:
> >    - reg : Offset and length of the register set of the RCPM block.
> > -  - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells
> > in the
> > +  - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells
> > + in the
> >  	fsl,rcpm-wakeup property.
> >    - compatible : Must contain a chip-specific RCPM block compatible string
> >  	and (if applicable) may contain a chassis-version RCPM compatible @@
> > -20,6 +20,7 @@ Required properites:
> >  	* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> >  	* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> >  	* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > +	* "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
> 
> Is there something actually called "2.1+"?  It looks a bit like an attempt to claim
> compatibility with all future versions.  If the former, is it a name that comes
> from the hardware side with an intent for it to describe a stable interface, or are
> we later going to see a patch changing some by-then-existing device trees from
> "2.1+" to "2.1++" when some new incompatibility is found?
>
> Perhaps it would be better to bind to the specific chip compatibles.

According to SoC data sheets, powerPC SoC T1040 and current ARM based Layerscape
SoCs (LS1021A, LS1012A, LS1043A, etc)'s arch designs are both basing on Chassis spec 2.1.
However, for Layerscape, their data sheets are also explicitly telling that some minor
changes have been made(basing on Chassis 2.1 spec). And in parallel, the SW arch designs
between T1040 and Layerscape family are also different: For Layerscape, part of RCPM
programming job has been moved from kernel driver to firmware/bootloader (through
PSCI interface). That's why I have to name a new compatible string to distinguish them.
They cannot use the same driver. I don’t think we will add another sting like 2.1++ in the
future. If the Chassis spec keep evolving and requiring different programming logic,
we can add more like 3.0, 4.0, ..., I think.

Regards,
Ran