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/
