Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 16/04/2023 13:14, Andy Shevchenko wrote:
> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 16/04/2023 11:36, Andy Shevchenko wrote:
>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
>>>>> <alexander.stein@ew.tq-group.com> 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@ew.tq-group.com> 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