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 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". > >> Otherwise bindings would be in directory matching the real hardware... > >> but they are not. So you can of course call it as you wish, but from > >> hardware perspective this is not pin control. This is RC circuit, not > >> pin related thingy. > > > > Yep, I put it as a pin configuration which is part of pin control in > > the Linux kernel right now. But I agree with your above explanation > > and it seems that we lack a, let's say, "pin modification" framework > > that stacks additional (PCB level or why not even some special in-SoC > > ones) properties and adds them to the given pins. > > It's nothing to do with modification of properties of some pin. It's a > separate circuit which has an effect on how two connected pins behave. > If you look from an effect point of view, only one side is more > interested in the effect - consumer. But still this sits in the middle. Yes, see above. And we are programming only one side of this scenario. For us it's a property of one side of the equation. -- With Best Regards, Andy Shevchenko
