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
