Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
<alexander.stein@xxxxxxxxxxxxxxx> wrote:
> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> > On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> > <alexander.stein@xxxxxxxxxxxxxxx> wrote:
...

> > So, taking the above into consideration, why is it GPIO property to
> > begin with? This is PCB property of the certain platform design that
> > needs to be driven by a specific driver, correct?
>
> True this is induced by the PCB, but this property applies to the GPIO,
> neither the GPIO controller output, nor the GPIO consumer is aware of.
> So it has to be added in between. The original idea to add a property for the
> consumer driver is also rejected, because this kind of behavior is not limited
> to this specific driver.
> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>
> > At the very least this is pin configuration (but external to the SoC),
> > so has to be a _separate_ pin control in my opinion.
>
> Sorry, I don't get what you mean by _separate_ pin control.

As you mentioned above this can be applied theoretically to any pin of
the SoC, That pin may or may not be a GPIO or a pin that can be
switched to the GPIO mode. Hence this entire idea shouldn't be part of
the existing _in-SoC_ pin control driver if any. This is a purely
separate entity, but at the same time it adds a property to a pin,
hence pin control.
At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.

> > > > Which part(s) did I got wrong?
> > >
> > > Maybe there needs to be an explicit example in the bindings document
> > > what's
> > > the actual issue to deal with.
> > > Right now if a GPIO is set, it is expected the signal on the receiver side
> > > has changed as well within a negligible time as well. But due to external
> > > reasons (see RC_curcuit above) the change on the receiver side can occur
> > > much later,>
> > > >100ms in my case.
> >
> > I still don't understand why it is a problem. If each signal is
> > delayed then the caller should be aware of the delay, no?
>
> Then we are back to square one, to decide where to take consideration of that
> delay. Up until now there have been several proposals:
> 1. GPIO consumer [3]
> 2. GPIO controller [4]
> 3. GPIO delay node (this series)
>
> 1. and 2. have been rejected, because that delay is taken care of where it is
> not caused.
> 3. explicitly declares the location of that delay. It's less/not intrusive to
> existing parts and purely optional. Given this is a rare case, but not limited
> to us, option 3 seems a good way to go.

All three are for the particular case of the pin. I do not think it's
_solely_ related to GPIO, esp. if the pin can switch modes from GPIO
to some native function. To me it sounds like it has to be a pin
configuration (of pin control) delay node. I.o.w. the #3, but without
tights to the GPIO.

> [1] https://lore.kernel.org/linux-gpio/CAL_JsqLeqpMuRkvpT2-x5q+8e4bHf4oLDML2QqCOgRMAg8=CsA@xxxxxxxxxxxxxx/
> [2] https://lore.kernel.org/linux-gpio/
> CACRpkdYioW1GROHFxA1vuAEiXqHh6fAu5CXNLcTvW_w3mWjSPw@xxxxxxxxxxxxxx/
> [3] https://lore.kernel.org/dri-devel/20221209083339.3780776-1-alexander.stein@xxxxxxxxxxxxxxx/
> [4] https://lore.kernel.org/linux-gpio/20221212103525.231298-1-alexander.stein@xxxxxxxxxxxxxxx/

-- 
With Best Regards,
Andy Shevchenko