Hi Andy, 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: > > Hello everyone, > > > > 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 is can be implemented as debounce. Debounce for GPIOs? There is nothing like that yet. > 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. > 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. Best regards, Alexander > P.S. Are we going to have a _driver_ per each subtle feature like this? -- 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/
