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

[Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx>]

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:
> > Am Freitag, 7. April 2023, 20:57:32 CEST schrieb 
andy.shevchenko@xxxxxxxxx:
> > > Thu, Apr 06, 2023 at 11:33:41AM +0200, Alexander Stein kirjoitti:
> ...
> 
> > > > thanks for the feedback I've received. This is the first non-RFC
> > > > series
> > > > for
> > > > adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> > > > 
> > > > Changes compared to RFC v2 are mentioned in each patch.
> > > 
> > > Reading the (poor?) documentation does not clarify the use case.
> > > Looking at them I think that this can be implemented as debounce.
> > 
> > Debounce for GPIOs? There is nothing like that yet.
> 
> At least that what we have already done in the code, you can just
> provide a similar feature to the output pins, no?

Adding this kind of property to outputs (GPIO chips) has been rejected 
already, both on DT side as well as libgpio side, see [1] and [2].

> > > Also I have no clue why it's so important that we _need_ to have a
> > > driver for this. We have plenty of consumer drivers that implement
> > > delays on ramping up or down or whatever if they need.
> > 
> > But this delay I am dealing with is actually not consumer dependent, e.g.
> > a
> > power-on delay specified in a datasheet. Instead this driver deals with a
> > platform-specific curiosity, e.g. RC-circuit on an open-drain output. So
> > this is something which sits inbetween ICs.
> > In the RFC we came to the conclusion to not adjust (each) consumer to deal
> > with this, given this will be rarely used. Instead provide a generic way
> > for specifying this delay.
> 
> 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.

> > > 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.

Best regards,
Alexander

[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/

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/