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? > > 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? At the very least this is pin configuration (but external to the SoC), so has to be a _separate_ pin control in my opinion. > > 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? -- With Best Regards, Andy Shevchenko
