linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	Marek Vasut <marex@denx.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v1 0/3] gpio: Add gpio-delay support
Date: Sun, 16 Apr 2023 09:42:16 +0200	[thread overview]
Message-ID: <a79134a3-be9d-7297-15e1-1de4eb4054d0@linaro.org> (raw)
In-Reply-To: <CAHp75VeTFDkaYRfX+9hE7LYE4Z-NpNfP=xfsGt27nm_DrTC_cw@mail.gmail.com>

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.

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

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

Although different problem is calling it v1. This is not v1, but v3 or
v4. Keep proper versioning. After v2 goes v3. RFC does not mean "v-2".

Best regards,
Krzysztof


  reply	other threads:[~2023-04-16  7:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06  9:33 [PATCH v1 0/3] gpio: Add gpio-delay support Alexander Stein
2023-04-06  9:33 ` [PATCH v1 1/3] dt-bindings: gpio: Add gpio-delay binding document Alexander Stein
2023-05-31 16:37   ` Krzysztof Kozlowski
2023-06-02 16:29   ` Bartosz Golaszewski
2023-04-06  9:33 ` [PATCH v1 2/3] gpio: Add gpio delay driver Alexander Stein
2023-06-02 16:31   ` Bartosz Golaszewski
2023-04-06  9:33 ` [PATCH v1 3/3] [DNI] arm64: dts: mba8mx: Use gpio-delay for LVDS bridge Alexander Stein
2023-04-07 18:57 ` [PATCH v1 0/3] gpio: Add gpio-delay support andy.shevchenko
2023-04-11  7:19   ` Alexander Stein
2023-04-11  9:34     ` Andy Shevchenko
2023-04-14  6:37       ` Alexander Stein
2023-04-15 15:06         ` Andy Shevchenko
2023-04-16  7:42           ` Krzysztof Kozlowski [this message]
2023-04-16  9:36             ` Andy Shevchenko
2023-04-16 11:04               ` Krzysztof Kozlowski
2023-04-16 11:14                 ` Andy Shevchenko
2023-04-16 11:21                   ` Krzysztof Kozlowski
2023-04-16 11:33                     ` Andy Shevchenko
2023-04-16 11:42                       ` Krzysztof Kozlowski
2023-04-16 18:46                         ` Andy Shevchenko
2023-05-31  6:53                           ` Alexander Stein
2023-05-31 12:02                             ` Andy Shevchenko
2023-05-31 13:44                             ` Linus Walleij
2023-05-31 14:37                               ` Andy Shevchenko
2023-05-31 16:37                               ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a79134a3-be9d-7297-15e1-1de4eb4054d0@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).