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. 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. > 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. -- With Best Regards, Andy Shevchenko
