2022-02-15 08:44:43

by Peng Fan (OSS)

[permalink] [raw]
Subject: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible string

From: Peng Fan <[email protected]>

The lpuart on i.MX93 is derived from i.MX8ULP with some industrial
enhancements, it uses three compatible strings, so update the
compatible string for i.MX93. But for a few instants,
DTR_B, DSR_B, DCD_B and RIN_B pins are supported, so use one compatible
string fsl,imx93-lpuart-v2

Signed-off-by: Peng Fan <[email protected]>
---
Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
index 6e04e3848261..d7805f31ccc2 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
@@ -24,6 +24,8 @@ properties:
- fsl,imxrt1050-lpuart
- items:
- enum:
+ - fsl,imx93-lpuart
+ - fsl,imx93-lpuart-v2
- fsl,imx8qxp-lpuart
- fsl,imx8ulp-lpuart
- const: fsl,imx7ulp-lpuart
--
2.25.1


2022-02-26 02:34:00

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible string

On Tue, Feb 15, 2022 at 04:13:34PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The lpuart on i.MX93 is derived from i.MX8ULP with some industrial
> enhancements, it uses three compatible strings, so update the

Looks like it's 2 compatible strings...

> compatible string for i.MX93. But for a few instants,

s/instants/instances/

> DTR_B, DSR_B, DCD_B and RIN_B pins are supported, so use one compatible
> string fsl,imx93-lpuart-v2

If the differences are just what gets pinned out, then I think the
differences should be handled with separate properties. We probably
already have some.

Plus, while you may have all the above signals, a board design may still
only use a subset.

>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> index 6e04e3848261..d7805f31ccc2 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> @@ -24,6 +24,8 @@ properties:
> - fsl,imxrt1050-lpuart
> - items:
> - enum:
> + - fsl,imx93-lpuart
> + - fsl,imx93-lpuart-v2
> - fsl,imx8qxp-lpuart
> - fsl,imx8ulp-lpuart
> - const: fsl,imx7ulp-lpuart
> --
> 2.25.1
>
>

2022-02-28 02:57:34

by Peng Fan

[permalink] [raw]
Subject: RE: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible string

Hi Rob,

> Subject: Re: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible
> string
>
> On Tue, Feb 15, 2022 at 04:13:34PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > The lpuart on i.MX93 is derived from i.MX8ULP with some industrial
> > enhancements, it uses three compatible strings, so update the
>
> Looks like it's 2 compatible strings...

Oh, yes. i.MX8ULP/7ULP is same uart IP.

>
> > compatible string for i.MX93. But for a few instants,
>
> s/instants/instances/
>
> > DTR_B, DSR_B, DCD_B and RIN_B pins are supported, so use one
> > compatible string fsl,imx93-lpuart-v2
>
> If the differences are just what gets pinned out, then I think the differences
> should be handled with separate properties. We probably already have some.
>
> Plus, while you may have all the above signals, a board design may still only
> use a subset.

It is SoC integration level with above features not support in some instances,
so no such signals connected to SoC pin.

Saying LPUART IP itself support DTR/DSR/DCD/RIN, but instance A has the
feature disabled when doing SoC integration, instance B has the feature enabled
when doing SoC integration. What's your suggestion with such case?

Thanks,
Peng.

>
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > Documentation/devicetree/bindings/serial/fsl-lpuart.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> > b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> > index 6e04e3848261..d7805f31ccc2 100644
> > --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> > +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
> > @@ -24,6 +24,8 @@ properties:
> > - fsl,imxrt1050-lpuart
> > - items:
> > - enum:
> > + - fsl,imx93-lpuart
> > + - fsl,imx93-lpuart-v2
> > - fsl,imx8qxp-lpuart
> > - fsl,imx8ulp-lpuart
> > - const: fsl,imx7ulp-lpuart
> > --
> > 2.25.1
> >
> >

2022-03-03 23:12:11

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible string

On Sun, Feb 27, 2022 at 6:44 PM Peng Fan <[email protected]> wrote:
>
> Hi Rob,
>
> > Subject: Re: [PATCH] dt-bindings: serial: fsl-lpuart: Add imx93 compatible
> > string
> >
> > On Tue, Feb 15, 2022 at 04:13:34PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <[email protected]>
> > >
> > > The lpuart on i.MX93 is derived from i.MX8ULP with some industrial
> > > enhancements, it uses three compatible strings, so update the
> >
> > Looks like it's 2 compatible strings...
>
> Oh, yes. i.MX8ULP/7ULP is same uart IP.
>
> >
> > > compatible string for i.MX93. But for a few instants,
> >
> > s/instants/instances/
> >
> > > DTR_B, DSR_B, DCD_B and RIN_B pins are supported, so use one
> > > compatible string fsl,imx93-lpuart-v2
> >
> > If the differences are just what gets pinned out, then I think the differences
> > should be handled with separate properties. We probably already have some.
> >
> > Plus, while you may have all the above signals, a board design may still only
> > use a subset.
>
> It is SoC integration level with above features not support in some instances,
> so no such signals connected to SoC pin.
>
> Saying LPUART IP itself support DTR/DSR/DCD/RIN, but instance A has the
> feature disabled when doing SoC integration, instance B has the feature enabled
> when doing SoC integration. What's your suggestion with such case?

Unless it changes the register interface in a non-compatible way that
the driver needs to know about, I would not do a different compatible.
For example, register offsets change.

Rob