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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

Hi Laurent,

thanks for the detailed brief!

On Tue, Dec 13, 2022 at 12:45 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:

> The circuit we're looking at is
>
>   +----------+           +-----------+
>   | SoC      |           |    VCC    |
>   |          |           |     |     |
>   |          |           |     _     |
>   |          |           |    | | R  |
>   |          |           |    |_|    |
>   |          |           |     |     |
>   |      [IOx|-----+-----|EN]--+     |
>   |          |     |     |           |
>   |          |     |     | SN65DSI83 |
>   +----------+    --- C  +-----------+
>                   ---
>                    |
>                    -
>                   GND
>
> The IOx pin is an open-drain output, the board has a 470nF capacitor to
> ground, and the SN65DSI83 has an internal pull-up off 200kΩ. This gives
> an RC time constant of 94ms, far from being negligible.
>
> The delay is caused by the combination of the open-drain nature of the
> output (an intrinsic property of the GPIO controller), the pull-up
> resistor (an intrinsic property of the SN65DSI83) and the capacitor on
> the line (a property of the board). DT is notoriously bad at modelling
> this kind of setup.

Yeah :/

It's not like we don't model discrete electronics, we do that a lot,
but as you say, it is really hard to know where to draw the line
in cases like this.

> The alternative I proposed, adding a "GPIO delay" DT node to model this,
> would also offer a centralized solution to the problem, but with
> additional complexity both at probe time and runtime.

I have a slight preference for this, as it will be very explicit in the
device tree and we can just put all the code inside its own file and
depend on GPIO_OF so other HW description systems do not
need to include it.

At the same time it feels a bit overengineered, so maybe just adding
this delay as in the patch with some strings attached like comments
and docs is yet the best. It feels like we need some more input to
reach consensus.

> The regulator delays model the intrinsic delays when enabling or
> disabling a regulator, and they should stay. They address a different
> problem.

OK right. But someone not knowing exactly what they are doing
will end up abusing the delay property on the delay line
also for this delay. The risk of that is lesser with a separate
delay box.

Yours,
Linus Walleij