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. > 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? > >> 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. Best regards, Krzysztof
