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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> This has nothing to do with different
> properties/configuration/functions, thus it is not pin control. The pin
> control maintainer also acked the patches.

This series is about GPIO, so the pin control maintainer acked that,
and not reviewed it, so let's take this into account. The GPIO
maintainer has yet to comment on my reply, if he has anything to say.

> The choice was discussed before, so I am surprised why you jump late in
> discussions.

Why? I was not in the initial submission and I jumped as quickly as I
noticed this.

-- 
With Best Regards,
Andy Shevchenko




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux