Re: [RFC PATCH 1/3] dt-bindings: gpio: Add optional ramp-up delay property

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Dec 12, 2022 at 11:35 AM Alexander Stein
<alexander.stein@xxxxxxxxxxxxxxx> wrote:

> This adds a ramp-up delay (in us) for adding a delay after enabling
> GPIO. This is necessary if the ramp-up time is increased by some external
> components. Usually this is quite fast, but certain combinations can
> increase this to grater than 100ms.
>
> Signed-off-by: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx>
(...)
> +gpio-controller@00000000 {
> +       compatible = "foo";
> +       reg = <0x00000000 0x1000>;
> +       gpio-controller;
> +       #gpio-cells = <2>;
> +       gpio-ramp-up-delays-us = <0>, <0>, <0>, <0>,
> +                                <0>, <0>, <120000>, <0>,
> +                                <0>, <0>, <0>, <0>,
> +                                <0>, <0>, <0>, <0>;

Why would this be different per-gpio-line?

If this should be on the GPIO controller, this should be the ramp-up for the
GPIO controller output itself, not for the random electronics that may or may
not be attached to the line.

Otherwise the ramp-up should certainly be on the consumer side. And that
seems very much like what is going on here.

Consider a gpio-regulator:


Documentation/devicetree/bindings/regulator/fixed-regulator.yamlproperties:
  compatible:
    enum:
      - regulator-fixed
      - regulator-fixed-clock
      - regulator-fixed-domain

  regulator-name: true

  gpio:
    description: gpio to use for enable control
    maxItems: 1
(...)
  startup-delay-us:
    description: startup time in microseconds

  off-on-delay-us:
    description: off delay time in microseconds


There is one consumer, and if you add ramp-up and ramp-down delays to the
GPIO lines like this you have just created two ways of doing the same thing.
When there is a ramp-up for a regulator now the used can choose to put it
on the regulator or on the gpio.

This is clearly ambiguous so NAK to this approach. IMO the property goes
on the consumer due to precedence.

[Other context]
> Laurent suggest to add a GPIO delay node in DT. IMHO this increased the DT
> complexity unnecessarily. But comments are welcome.

If the consumer subsystem don't want it, I guess this is where you would
have to go in and add more DT descriptions for the electronics on the
board, which I understand is a bit frustrating, and it is hard to find the
right trade-off. It makes me think about the classical problem "how long is
the coast of Britain?" by Benoit Mandelbrot:
https://en.wikipedia.org/wiki/How_Long_Is_the_Coast_of_Britain%3F_Statistical_Self-Similarity_and_Fractional_Dimension

The DT maintainers will have the final word on it I guess.

Yours,
Linus Walleij