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

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Wed, May 31, 2023 at 9:53 AM Alexander Stein
<alexander.stein@xxxxxxxxxxxxxxx> wrote:
> Am Sonntag, 16. April 2023, 20:46:43 CEST schrieb Andy Shevchenko:
> > On Sun, Apr 16, 2023 at 2:42 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > On 16/04/2023 13:33, Andy Shevchenko wrote:
> > > > On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > >> On 16/04/2023 13:14, Andy Shevchenko wrote:
> > > >>> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> > > >>> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > >>>> On 16/04/2023 11:36, Andy Shevchenko wrote:
> > > >>>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> > > >>>>> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > >>>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
> > > >>>>>>> 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_.> >>>>>>
> > > >>>>>> I don't think that anything here is related to pin control. Pin
> > > >>>>>> control
> > > >>>>>> is specific function of some device which allows different
> > > >>>>>> properties or
> > > >>>>>> different functions of a pin.
> > > >>>>>
> > > >>>>> Sorry, but from a hardware perspective I have to disagree with you.
> > > >>>>> It's a property of the _pin_ and not of a GPIO. Any pin might have
> > > >>>>> the
> > > >>>>> same property. That's why it's definitely _not_ a property of GPIO,
> > > >>>>> but wider than that.
> > > >>>>
> > > >>>> I did not say this is a property of GPIO. I said this is nothing to
> > > >>>> do
> > > >>>> with pin control, configuration and pinctrl as is.
> > > >>>
> > > >>> Ah, I see. But still is a property of the pin on the PCB level.
> > > >>
> > > >> No, it is property of a circuit, so property of two pins and a wire
> > > >> between them. Not a property of one pin.
> > > >
> > > > Electrically speaking -- yes, software speaking, no, this is the
> > > > property of the one end (platfrom abstraction in the software) and as
> > > > you said, consumer which may be SoC, or the device connected to the
> > > > SoC (depending on the signal direction), or both (like pull-up for
> > > > I2C).
> > > >
> > > >>> That's
> > > >>> why I said that it should be like a "proxy" driver that has to be a
> > > >>> consumer of the pins on one side and provide the pins with this
> > > >>> property on the other.
> > > >>
> > > >> Not sure, why do you need it for anything else than GPIOs? What is the
> > > >> real world use case for proxy driver of non-GPIO lines?
> > > >
> > > > I2C is an example where we have something in between, which both of
> > >
> > > Are you sure you have RC (not just resistor) in I2C?
> >
> > I'm talking about an analogue. In principle the pull-up is part of PCB
> > and not of the SoC.
> >
> > > > the ends are using and this is the property of PCB, but luckily we
> > > > don't need anything special in the software for that, right? But from
> > > > the electrical point of view it's exactly a non-GPIO property. That's
> > > > why "proxy".
> > >
> > > Still I do not see any reason to call it anything else than GPIO. If you
> > > think that there is any other usage, please bring it as an real,
> > > non-theoretical example.
> >
> > The first, which one I found, is time-stretched ADC. The idea is that
> > the portion of the signal is split to the phases and each phase is
> > passed via time stretcher for the low-speed ADC to be digitized. So,
> > if we have an SoC with 4+ ADCs, on the PCB one can add an externally
> > clocked mux and then 4+ time stretching lines and on the SoC side it
> > will be ADC (note, not a GPIO!).
>
> What do I need to do to get progress on this topic? Without this kind of delay
> handling the DSI-LVDS bridge on our hardware cannot be used in mainline.

I have looked into the entire thread and found no replies from Linus W and Bart.
They are GPIO maintainers and should fuel up this discussion.

-- 
With Best Regards,
Andy Shevchenko