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

[Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx>]

Hi everybody,

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.

Best regards,
Alexander
-- 
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/