[v2,1/4] dt-bindings: aspeed-sgpio: Convert txt bindings to yaml.

SGPIO bindings should be converted as yaml format.
In addition to the file conversion, a new property max-ngpios is
added in the yaml file as well.
The new property is required by the enhanced sgpio driver for
making the configuration of the max number of gpio pins more flexible.

Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
---
 .../bindings/gpio/aspeed,sgpio.yaml           | 91 +++++++++++++++++++
 .../devicetree/bindings/gpio/sgpio-aspeed.txt | 46 ----------
 2 files changed, 91 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
 delete mode 100644 Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt

On Thu, May 27, 2021 at 2:55 AM Steven Lee <steven_lee@aspeedtech.com> wrote:

> SGPIO bindings should be converted as yaml format.
> In addition to the file conversion, a new property max-ngpios is
> added in the yaml file as well.
> The new property is required by the enhanced sgpio driver for
> making the configuration of the max number of gpio pins more flexible.
>
> Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
(...)
> +  max-ngpios:
> +    description:
> +      represents the number of actual hardware-supported GPIOs (ie,
> +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> +      device. We also use it to define the split between the inputs and
> +      outputs; the inputs start at line 0, the outputs start at max_ngpios.
> +    minimum: 0
> +    maximum: 128

Why can this not be derived from the compatible value?

Normally there should be one compatible per hardware variant
of the block. And this should be aligned with that, should it not?

If this is not the case, maybe more detailed compatible strings
are needed, maybe double compatibles with compatible per
family and SoC?

Yours,
Linus Walleij

The 05/28/2021 07:51, Linus Walleij wrote:
> On Thu, May 27, 2021 at 2:55 AM Steven Lee <steven_lee@aspeedtech.com> wrote:
> 
> > SGPIO bindings should be converted as yaml format.
> > In addition to the file conversion, a new property max-ngpios is
> > added in the yaml file as well.
> > The new property is required by the enhanced sgpio driver for
> > making the configuration of the max number of gpio pins more flexible.
> >
> > Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
> (...)
> > +  max-ngpios:
> > +    description:
> > +      represents the number of actual hardware-supported GPIOs (ie,
> > +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> > +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> > +      device. We also use it to define the split between the inputs and
> > +      outputs; the inputs start at line 0, the outputs start at max_ngpios.
> > +    minimum: 0
> > +    maximum: 128
> 
> Why can this not be derived from the compatible value?
> 
> Normally there should be one compatible per hardware variant
> of the block. And this should be aligned with that, should it not?
> 
> If this is not the case, maybe more detailed compatible strings
> are needed, maybe double compatibles with compatible per
> family and SoC?
> 

Thanks for your suggestion.
I add max-ngpios in dt-bindings as there is ngpios defined in
dt-bindings, users can get the both max-ngpios and ngpios information
from dtsi without digging sgpio driver.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed-g5.dtsi#n354

If adding more detailed compatibles is better, I will add them to sgpio driver
in V3 patch and remove max-ngpios from dt-bindings.

Since AST2600 has 2 sgpio controller one with 128 pins and another one with 80 pins.
For supporting max-ngpios in compatibles, 2 platform data for each
ast2600 sgpio controller as follows are necessary.

```
static const struct aspeed_sgpio_pdata ast2600_sgpiom1_pdata = {
        .max_ngpios = 128;
};
static const struct aspeed_sgpio_pdata ast2600_sgpiom2_pdata = {
        .max_ngpios = 80;
};

{ .compatible = "aspeed,ast2500-sgpio" , .data = &ast2400_sgpio_pdata, },
{ .compatible = "aspeed,ast2600-sgpiom1", .data = &ast2600_sgpiom1_pdata, },
{ .compatible = "aspeed,ast2600-sgpiom2", .data = &ast2600_sgpiom2_pdata, },
```

Thanks,
Steven

> Yours,
> Linus Walleij

On Fri, May 28, 2021 at 6:10 AM Steven Lee <steven_lee@aspeedtech.com> wrote:
> The 05/28/2021 07:51, Linus Walleij wrote:
> > On Thu, May 27, 2021 at 2:55 AM Steven Lee <steven_lee@aspeedtech.com> wrote:
> >
> > > +  max-ngpios:
> > > +    description:
> > > +      represents the number of actual hardware-supported GPIOs (ie,
> > > +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> > > +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> > > +      device. We also use it to define the split between the inputs and
> > > +      outputs; the inputs start at line 0, the outputs start at max_ngpios.
> > > +    minimum: 0
> > > +    maximum: 128
> >
> > Why can this not be derived from the compatible value?
> >
> > Normally there should be one compatible per hardware variant
> > of the block. And this should be aligned with that, should it not?
> >
> > If this is not the case, maybe more detailed compatible strings
> > are needed, maybe double compatibles with compatible per
> > family and SoC?
> >
>
> Thanks for your suggestion.
> I add max-ngpios in dt-bindings as there is ngpios defined in
> dt-bindings, users can get the both max-ngpios and ngpios information
> from dtsi without digging sgpio driver.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed-g5.dtsi#n354
>
> If adding more detailed compatibles is better, I will add them to sgpio driver
> in V3 patch and remove max-ngpios from dt-bindings.
>
> Since AST2600 has 2 sgpio controller one with 128 pins and another one with 80 pins.
> For supporting max-ngpios in compatibles, 2 platform data for each
> ast2600 sgpio controller as follows are necessary.
>
> ```
> static const struct aspeed_sgpio_pdata ast2600_sgpiom1_pdata = {
>         .max_ngpios = 128;
> };
> static const struct aspeed_sgpio_pdata ast2600_sgpiom2_pdata = {
>         .max_ngpios = 80;
> };
>
> { .compatible = "aspeed,ast2500-sgpio" , .data = &ast2400_sgpio_pdata, },
> { .compatible = "aspeed,ast2600-sgpiom1", .data = &ast2600_sgpiom1_pdata, },
> { .compatible = "aspeed,ast2600-sgpiom2", .data = &ast2600_sgpiom2_pdata, },

There is a soft border between two IP blocks being "compatible"
and parameterized and two IP blocks being different and having
unique compatibles.

For example we know for sure we don't use different compatibles
because of how interrupt lines or DMA channels are connected.

So if this is an external thing, outside of the IP itself, I might back
off on this and say it shall be a parameter.

But max-ngpios? It is confusingly similar to ngpios.

So we need to think about this name.

Something like gpio-hardware-slots or something else that
really describe what this is.

Does this always strictly follow ngpios so that the number
of gpio slots == ngpios * 2? In that case only put ngpios into
the device tree and multiply by 2 in the driver, because ngpios
is exactly for this: parameterizing hardware limitations.

Yours,
Linus Walleij

The 05/28/2021 16:35, Linus Walleij wrote:
> On Fri, May 28, 2021 at 6:10 AM Steven Lee <steven_lee@aspeedtech.com> wrote:
> > The 05/28/2021 07:51, Linus Walleij wrote:
> > > On Thu, May 27, 2021 at 2:55 AM Steven Lee <steven_lee@aspeedtech.com> wrote:
> > >
> > > > +  max-ngpios:
> > > > +    description:
> > > > +      represents the number of actual hardware-supported GPIOs (ie,
> > > > +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> > > > +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> > > > +      device. We also use it to define the split between the inputs and
> > > > +      outputs; the inputs start at line 0, the outputs start at max_ngpios.
> > > > +    minimum: 0
> > > > +    maximum: 128
> > >
> > > Why can this not be derived from the compatible value?
> > >
> > > Normally there should be one compatible per hardware variant
> > > of the block. And this should be aligned with that, should it not?
> > >
> > > If this is not the case, maybe more detailed compatible strings
> > > are needed, maybe double compatibles with compatible per
> > > family and SoC?
> > >
> >
> > Thanks for your suggestion.
> > I add max-ngpios in dt-bindings as there is ngpios defined in
> > dt-bindings, users can get the both max-ngpios and ngpios information
> > from dtsi without digging sgpio driver.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/aspeed-g5.dtsi#n354
> >
> > If adding more detailed compatibles is better, I will add them to sgpio driver
> > in V3 patch and remove max-ngpios from dt-bindings.
> >
> > Since AST2600 has 2 sgpio controller one with 128 pins and another one with 80 pins.
> > For supporting max-ngpios in compatibles, 2 platform data for each
> > ast2600 sgpio controller as follows are necessary.
> >
> > ```
> > static const struct aspeed_sgpio_pdata ast2600_sgpiom1_pdata = {
> >         .max_ngpios = 128;
> > };
> > static const struct aspeed_sgpio_pdata ast2600_sgpiom2_pdata = {
> >         .max_ngpios = 80;
> > };
> >
> > { .compatible = "aspeed,ast2500-sgpio" , .data = &ast2400_sgpio_pdata, },
> > { .compatible = "aspeed,ast2600-sgpiom1", .data = &ast2600_sgpiom1_pdata, },
> > { .compatible = "aspeed,ast2600-sgpiom2", .data = &ast2600_sgpiom2_pdata, },
> 
> There is a soft border between two IP blocks being "compatible"
> and parameterized and two IP blocks being different and having
> unique compatibles.
> 
> For example we know for sure we don't use different compatibles
> because of how interrupt lines or DMA channels are connected.
> 

Thanks for sharing the knowledge and examples.

> So if this is an external thing, outside of the IP itself, I might back
> off on this and say it shall be a parameter.
> 
> But max-ngpios? It is confusingly similar to ngpios.
> 
> So we need to think about this name.
> 
> Something like gpio-hardware-slots or something else that
> really describe what this is.
> 
> Does this always strictly follow ngpios so that the number
> of gpio slots == ngpios * 2? In that case only put ngpios into
> the device tree and multiply by 2 in the driver, because ngpios
> is exactly for this: parameterizing hardware limitations.
> 

The parameter max-ngpios is the maxmum number of gpio pins that SoC supported,
ngpios is the maximum number of gpio pins that sgpio devices(e.g. sgpio cards) supported.

For instance, a sgpio card that supports 64 gpio pins which is connected to
ast2600evb sgpio master interface 2. The dts file should be configured as follows.

```
max-ngpios = <80>
ngpios = <64>

```

About the parameter naming, I was wondering if 'ngpios-of-sgpiom' is more clear
than max-ngpios as it is the maximum number of gpio pins that sgpio master
interfaces supported.

> Yours,
> Linus Walleij

On Mon, May 31, 2021 at 7:23 AM Steven Lee <steven_lee@aspeedtech.com> wrote:

> The parameter max-ngpios is the maxmum number of gpio pins that SoC supported,
> ngpios is the maximum number of gpio pins that sgpio devices(e.g. sgpio cards) supported.

When you put it like that you really make it sound like you already
know, just looking at the compatible string, what max-ngpios is?

I.e. do you know for these three:

aspeed,ast2400-sgpiom
aspeed,ast2500-sgpiom
aspeed,ast2600-sgpiom

the unique number of slots for each? A 1-to-1 correspondance?

Then just add code to set this value from looking at the compatible
in the driver. You can write some text in description in these bindings
about how many slots each SoC has but there is no need to add any
extra parameter if you already know this from the SoC.

Yours,
Linus Walleij

On Thu, May 27, 2021 at 08:54:50AM +0800, Steven Lee wrote:
> SGPIO bindings should be converted as yaml format.
> In addition to the file conversion, a new property max-ngpios is
> added in the yaml file as well.
> The new property is required by the enhanced sgpio driver for
> making the configuration of the max number of gpio pins more flexible.

The rest of the binding looks fine. Make this property a separate patch 
if you don't end up dropping it.

> 
> Signed-off-by: Steven Lee <steven_lee@aspeedtech.com>
> ---
>  .../bindings/gpio/aspeed,sgpio.yaml           | 91 +++++++++++++++++++
>  .../devicetree/bindings/gpio/sgpio-aspeed.txt | 46 ----------
>  2 files changed, 91 insertions(+), 46 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
>  delete mode 100644 Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
> new file mode 100644
> index 000000000000..02eb0c5023e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/aspeed,sgpio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed SGPIO controller
> +
> +maintainers:
> +  - Andrew Jeffery <andrew@aj.id.au>
> +
> +description:
> +  This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC,
> +  AST2600 have two sgpio master one with 128 pins another one with 80 pins,
> +  AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial
> +  GPIO pins can be programmed to support the following options
> +  - Support interrupt option for each input port and various interrupt
> +    sensitivity option (level-high, level-low, edge-high, edge-low)
> +  - Support reset tolerance option for each output port
> +  - Directly connected to APB bus and its shift clock is from APB bus clock
> +    divided by a programmable value.
> +  - Co-work with external signal-chained TTL components (74LV165/74LV595)
> +
> +properties:
> +  compatible:
> +    enum:
> +      - aspeed,ast2400-sgpiom
> +      - aspeed,ast2500-sgpiom
> +      - aspeed,ast2600-sgpiom
> +
> +  reg:
> +    maxItems: 1
> +
> +  gpio-controller: true
> +
> +  '#gpio-cells':
> +    const: 2
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  interrupt-controller: true
> +
> +  clocks:
> +    maxItems: 1
> +
> +  ngpios:
> +    minimum: 0
> +    maximum: 128
> +
> +  max-ngpios:
> +    description:
> +      represents the number of actual hardware-supported GPIOs (ie,
> +      slots within the clocked serial GPIO data). Since each HW GPIO is both an
> +      input and an output, we provide max_ngpios * 2 lines on our gpiochip
> +      device. We also use it to define the split between the inputs and
> +      outputs; the inputs start at line 0, the outputs start at max_ngpios.
> +    minimum: 0
> +    maximum: 128
> +
> +  bus-frequency: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - gpio-controller
> +  - '#gpio-cells'
> +  - interrupts
> +  - interrupt-controller
> +  - ngpios
> +  - max-ngpios
> +  - clocks
> +  - bus-frequency
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/aspeed-clock.h>
> +    sgpio: sgpio@1e780200 {
> +        #gpio-cells = <2>;
> +        compatible = "aspeed,ast2500-sgpiom";
> +        gpio-controller;
> +        interrupts = <40>;
> +        reg = <0x1e780200 0x0100>;
> +        clocks = <&syscon ASPEED_CLK_APB>;
> +        interrupt-controller;
> +        ngpios = <8>;
> +        max-ngpios = <80>;
> +        bus-frequency = <12000000>;
> +    };
> diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> deleted file mode 100644
> index be329ea4794f..000000000000
> --- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> +++ /dev/null
> @@ -1,46 +0,0 @@
> -Aspeed SGPIO controller Device Tree Bindings
> ---------------------------------------------
> -
> -This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full
> -featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to
> -support the following options:
> -- Support interrupt option for each input port and various interrupt
> -  sensitivity option (level-high, level-low, edge-high, edge-low)
> -- Support reset tolerance option for each output port
> -- Directly connected to APB bus and its shift clock is from APB bus clock
> -  divided by a programmable value.
> -- Co-work with external signal-chained TTL components (74LV165/74LV595)
> -
> -Required properties:
> -
> -- compatible : Should be one of
> -  "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
> -- #gpio-cells : Should be 2, see gpio.txt
> -- reg : Address and length of the register set for the device
> -- gpio-controller : Marks the device node as a GPIO controller
> -- interrupts : Interrupt specifier, see interrupt-controller/interrupts.txt
> -- interrupt-controller : Mark the GPIO controller as an interrupt-controller
> -- ngpios : number of *hardware* GPIO lines, see gpio.txt. This will expose
> -  2 software GPIOs per hardware GPIO: one for hardware input, one for hardware
> -  output. Up to 80 pins, must be a multiple of 8.
> -- clocks : A phandle to the APB clock for SGPM clock division
> -- bus-frequency : SGPM CLK frequency
> -
> -The sgpio and interrupt properties are further described in their respective
> -bindings documentation:
> -
> -- Documentation/devicetree/bindings/gpio/gpio.txt
> -- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> -
> -  Example:
> -	sgpio: sgpio@1e780200 {
> -		#gpio-cells = <2>;
> -		compatible = "aspeed,ast2500-sgpio";
> -		gpio-controller;
> -		interrupts = <40>;
> -		reg = <0x1e780200 0x0100>;
> -		clocks = <&syscon ASPEED_CLK_APB>;
> -		interrupt-controller;
> -		ngpios = <8>;
> -		bus-frequency = <12000000>;
> -	};
> -- 
> 2.17.1