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
