mbox series

[v3,0/4] NXP S32G3 SoC initial bring-up

Message ID 20240321154108.146223-1-wafgo01@gmail.com
Headers show
Series NXP S32G3 SoC initial bring-up | expand

Message

Wadim Mueller March 21, 2024, 3:41 p.m. UTC 
This series brings up initial support for the NXP S32G3 SoC,
used on the S32G-VNP-RDB3 board [1].

The following features are supported in this initial port:

  * Devicetree for the S32G-VNP-RDB3 
  * UART (fsl-linflexuart) with earlycon support
  * SDHC: fsl-imx-esdhc (SD/eMMC)

== Changes since v2 ==:

  * split each dt schema doc change into a seperate patch
  * removed unnedeed IRQ from SCMI node
  * add mmc bus-width to S32G-VNP-RDB3 board dts file
  * fixed comments in arm-v8 timer interrupt mappings
 

[1] https://www.nxp.com/design/design-center/designs/s32g3-vehicle-networking-reference-design:S32G-VNP-RDB3

Wadim Mueller (4):
  dt-bindings: arm: fsl: Document NXP S32G3 board
  dt-bindings: serial: fsl-linflexuart: add compatible for S32G3
  dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
  arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3

 .../devicetree/bindings/arm/fsl.yaml          |   6 +
 .../bindings/mmc/fsl-imx-esdhc.yaml           |   4 +
 .../bindings/serial/fsl,s32-linflexuart.yaml  |   3 +
 arch/arm64/boot/dts/freescale/Makefile        |   1 +
 arch/arm64/boot/dts/freescale/s32g3.dtsi      | 237 ++++++++++++++++++
 .../boot/dts/freescale/s32g399a-rdb3.dts      |  45 ++++
 6 files changed, 296 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/s32g3.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts

Comments

Wadim Mueller March 22, 2024, 9:45 a.m. UTC | #1 
On Thu, Mar 21, 2024 at 06:53:34PM +0100, Krzysztof Kozlowski wrote:
> On 21/03/2024 16:41, Wadim Mueller wrote:
> > Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
> > we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
> > driver works also on S32G3 platforms.
> > 
> > Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > index 82eb7a24c857..b42b4368fa4e 100644
> > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > @@ -35,6 +35,7 @@ properties:
> >            - fsl,imx8mm-usdhc
> >            - fsl,imxrt1050-usdhc
> >            - nxp,s32g2-usdhc
> > +          - nxp,s32g3-usdhc
> >        - items:
> >            - const: fsl,imx50-esdhc
> >            - const: fsl,imx53-esdhc
> > @@ -90,6 +91,9 @@ properties:
> >            - enum:
> >                - fsl,imxrt1170-usdhc
> >            - const: fsl,imxrt1050-usdhc
> > +      - items:
> > +          - const: nxp,s32g3-usdhc
> > +          - const: nxp,s32g2-usdhc
> 
> No, that's just wrong. G3 is not and is compatible with G2? There is no
> dualism here. Either it is or it is not. Not both.
>

I am trying to understand your statement but I am not sure whether I get
it right.

Let me try to explain what I understand is wrong with this patch. 

Having nxp,s32g2-usdhc and nxp,s32g2-usdhc in one enum

> >            - nxp,s32g2-usdhc
> > +          - nxp,s32g3-usdhc

would mean that those are 
__not__ compatible with each other, whereas the anouther item

> > +      - items:
> > +          - const: nxp,s32g3-usdhc
> > +          - const: nxp,s32g2-usdhc
> 

where both const entries are side by side means that those are compatible. Which is
paradox. Is this undersanding correct?

So if I want to have the follwing im my DTS for the mmc node

usdhc0: mmc@402f0000 {
			compatible = "nxp,s32g3-usdhc",
				     "nxp,s32g2-usdhc";
				     ...
}

The schema update should contain just this part?

i@@ -90,6 +90,9 @@ properties:
           - enum:
               - fsl,imxrt1170-usdhc
           - const: fsl,imxrt1050-usdhc
+      - items:
+          - const: nxp,s32g3-usdhc
+          - const: nxp,s32g2-usdhc
 
   reg:
     maxItems: 1


Is this correct?

With this patch in place I dont see any issues with an 

"make CHECK_DTBS=y freescale/s32g399a-rdb3.dtb"

as well as "make dt_binding_check dtbs_check" seems to be OK with this.


Thanks for your guidence so far, much appreciated!

Best Regard
Wadim



> Best regards,
> Krzysztof
>
Krzysztof Kozlowski March 22, 2024, 3:02 p.m. UTC | #2 
On 22/03/2024 10:45, Wadim Mueller wrote:
> On Thu, Mar 21, 2024 at 06:53:34PM +0100, Krzysztof Kozlowski wrote:
>> On 21/03/2024 16:41, Wadim Mueller wrote:
>>> Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
>>> we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
>>> driver works also on S32G3 platforms.
>>>
>>> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
>>> ---
>>>  Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> index 82eb7a24c857..b42b4368fa4e 100644
>>> --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
>>> @@ -35,6 +35,7 @@ properties:
>>>            - fsl,imx8mm-usdhc
>>>            - fsl,imxrt1050-usdhc
>>>            - nxp,s32g2-usdhc
>>> +          - nxp,s32g3-usdhc
>>>        - items:
>>>            - const: fsl,imx50-esdhc
>>>            - const: fsl,imx53-esdhc
>>> @@ -90,6 +91,9 @@ properties:
>>>            - enum:
>>>                - fsl,imxrt1170-usdhc
>>>            - const: fsl,imxrt1050-usdhc
>>> +      - items:
>>> +          - const: nxp,s32g3-usdhc
>>> +          - const: nxp,s32g2-usdhc
>>
>> No, that's just wrong. G3 is not and is compatible with G2? There is no
>> dualism here. Either it is or it is not. Not both.
>>
> 
> I am trying to understand your statement but I am not sure whether I get
> it right.
> 
> Let me try to explain what I understand is wrong with this patch. 
> 
> Having nxp,s32g2-usdhc and nxp,s32g2-usdhc in one enum
> 
>>>            - nxp,s32g2-usdhc
>>> +          - nxp,s32g3-usdhc
> 
> would mean that those are 
> __not__ compatible with each other, whereas the anouther item
> 
>>> +      - items:
>>> +          - const: nxp,s32g3-usdhc
>>> +          - const: nxp,s32g2-usdhc
>>
> 
> where both const entries are side by side means that those are compatible. Which is
> paradox. Is this undersanding correct?

Yes, you placed the same compatible in two separate places. It has two
separate meanings.

> 
> So if I want to have the follwing im my DTS for the mmc node
> 
> usdhc0: mmc@402f0000 {
> 			compatible = "nxp,s32g3-usdhc",
> 				     "nxp,s32g2-usdhc";
> 				     ...
> }
> 
> The schema update should contain just this part?
> 
> i@@ -90,6 +90,9 @@ properties:
>            - enum:
>                - fsl,imxrt1170-usdhc
>            - const: fsl,imxrt1050-usdhc
> +      - items:
> +          - const: nxp,s32g3-usdhc
> +          - const: nxp,s32g2-usdhc
>  
>    reg:
>      maxItems: 1
> 
> 
> Is this correct?

Yes.



Best regards,
Krzysztof