From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: andy.shevchenko@gmail.com
Cc: sudeep.holla@arm.com, cristian.marussi@arm.com,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, linus.walleij@linaro.org,
Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org
Subject: Re: [RFC v2 0/5] gpio: add pinctrl based generic gpio driver
Date: Fri, 20 Oct 2023 09:21:02 +0900 [thread overview]
Message-ID: <ZTHH7vwG7hRneZls@octopus> (raw)
In-Reply-To: <ZTGfXsLc_Z6yj_HB@surfacebook.localdomain>
Hi Andy,
On Fri, Oct 20, 2023 at 12:27:58AM +0300, andy.shevchenko@gmail.com wrote:
> Thu, Oct 05, 2023 at 11:58:38AM +0900, AKASHI Takahiro kirjoitti:
> > This is a revised version of my previous RFC[1]. Although I modified
> > the commits to make them look SCMI-independent, they are still posted
> > as RFC because I have never tested them on real hardware.
> >
> > (background)
> > I'm currently working on implementing SCMI pinctrl/gpio drivers
> > on U-Boot[2]. Although the pinctrl driver for the kernel[3] was submitted
> > by EPAM, it doesn't contain the gpio driver and I believe that we should
> > discuss a couple of points on the kernel side to finalize my design for
> > U-Boot.
> >
> > So this RFC is intended for reviews, especially to raise some issues.
> >
> > 1) how to obtain a value on an input pin
> > All the existing gpio drivers are set to obtain a value on an input
> > pin by accessing the hardware directly. In SCMI case, however, this is
> > just impossible in its nature and must be supported via a protocol
> > using "Input-value" configuration type. (See the spec[4], table-23.)
> >
> > The current pinconf framework is missing the feature (the pinconf
> > parameter and a helper function). See patch#1, #2 and #3.
> >
> > Please note that there is an issue around the pin configuration in
> > EPAM's current pinctrl driver as I commented[5].
> >
> > 2) DT bindings
> > I would like to propose a generic binding for pinctrl based gpio driver.
> > This allows a "consumer" driver to handle gpio pins like as other
> > normal gpio controllers support. (patch#5)
> >
> > 3) generic GPIO driver
> > Based on (2), I tried to prototype a generic driver in patch#4.
> > Thanks to a set of existing pinctrl_gpio helper functions, except (1),
> > It seems that the driver can be implemented not relying on pin controller
> > specific code, at least for SCMI pinctrl.
> >
> > I will appreciate any comments.
>
> Any comment here: I'm listed as a designated reviewer of GPIO patches, why am I
> not Cc'ed on this?
My apologies. I will add you in Cc.
> I definitely have some comments against the code (no DT,
> though). Please, use (up-to-date) MAINTAINERS in your v3.
Please don't hesitate to make comments here on v2 so that I can
include your reviews in v3.
Thanks,
-Takahiro Akashi
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: andy.shevchenko@gmail.com
Cc: sudeep.holla@arm.com, cristian.marussi@arm.com,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, linus.walleij@linaro.org,
Oleksii_Moisieiev@epam.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org
Subject: Re: [RFC v2 0/5] gpio: add pinctrl based generic gpio driver
Date: Fri, 20 Oct 2023 09:21:02 +0900 [thread overview]
Message-ID: <ZTHH7vwG7hRneZls@octopus> (raw)
In-Reply-To: <ZTGfXsLc_Z6yj_HB@surfacebook.localdomain>
Hi Andy,
On Fri, Oct 20, 2023 at 12:27:58AM +0300, andy.shevchenko@gmail.com wrote:
> Thu, Oct 05, 2023 at 11:58:38AM +0900, AKASHI Takahiro kirjoitti:
> > This is a revised version of my previous RFC[1]. Although I modified
> > the commits to make them look SCMI-independent, they are still posted
> > as RFC because I have never tested them on real hardware.
> >
> > (background)
> > I'm currently working on implementing SCMI pinctrl/gpio drivers
> > on U-Boot[2]. Although the pinctrl driver for the kernel[3] was submitted
> > by EPAM, it doesn't contain the gpio driver and I believe that we should
> > discuss a couple of points on the kernel side to finalize my design for
> > U-Boot.
> >
> > So this RFC is intended for reviews, especially to raise some issues.
> >
> > 1) how to obtain a value on an input pin
> > All the existing gpio drivers are set to obtain a value on an input
> > pin by accessing the hardware directly. In SCMI case, however, this is
> > just impossible in its nature and must be supported via a protocol
> > using "Input-value" configuration type. (See the spec[4], table-23.)
> >
> > The current pinconf framework is missing the feature (the pinconf
> > parameter and a helper function). See patch#1, #2 and #3.
> >
> > Please note that there is an issue around the pin configuration in
> > EPAM's current pinctrl driver as I commented[5].
> >
> > 2) DT bindings
> > I would like to propose a generic binding for pinctrl based gpio driver.
> > This allows a "consumer" driver to handle gpio pins like as other
> > normal gpio controllers support. (patch#5)
> >
> > 3) generic GPIO driver
> > Based on (2), I tried to prototype a generic driver in patch#4.
> > Thanks to a set of existing pinctrl_gpio helper functions, except (1),
> > It seems that the driver can be implemented not relying on pin controller
> > specific code, at least for SCMI pinctrl.
> >
> > I will appreciate any comments.
>
> Any comment here: I'm listed as a designated reviewer of GPIO patches, why am I
> not Cc'ed on this?
My apologies. I will add you in Cc.
> I definitely have some comments against the code (no DT,
> though). Please, use (up-to-date) MAINTAINERS in your v3.
Please don't hesitate to make comments here on v2 so that I can
include your reviews in v3.
Thanks,
-Takahiro Akashi
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-20 0:21 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 2:58 [RFC v2 0/5] gpio: add pinctrl based generic gpio driver AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-05 2:58 ` [RFC v2 1/5] pinctrl: define PIN_CONFIG_INPUT AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-10 11:53 ` Linus Walleij
2023-10-10 11:53 ` Linus Walleij
2023-10-05 2:58 ` [RFC v2 2/5] pinctrl: always export pin_config_get_for_pin() AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-10 11:54 ` Linus Walleij
2023-10-10 11:54 ` Linus Walleij
2023-10-05 2:58 ` [RFC v2 3/5] pinctrl: add pinctrl_gpio_get_config() AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-05 2:58 ` [RFC v2 4/5] gpio: add pinctrl based generic gpio driver AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-10 12:00 ` Linus Walleij
2023-10-10 12:00 ` Linus Walleij
2023-10-12 1:08 ` AKASHI Takahiro
2023-10-12 1:08 ` AKASHI Takahiro
2023-10-05 2:58 ` [RFC v2 5/5] dt-bindings: gpio: Add bindings for " AKASHI Takahiro
2023-10-05 2:58 ` AKASHI Takahiro
2023-10-05 19:48 ` Krzysztof Kozlowski
2023-10-05 19:48 ` Krzysztof Kozlowski
2023-10-12 1:15 ` AKASHI Takahiro
2023-10-12 1:15 ` AKASHI Takahiro
2023-10-12 7:27 ` Krzysztof Kozlowski
2023-10-12 7:27 ` Krzysztof Kozlowski
2023-10-06 13:18 ` Rob Herring
2023-10-06 13:18 ` Rob Herring
2023-10-06 13:23 ` Rob Herring
2023-10-06 13:23 ` Rob Herring
2023-10-09 7:49 ` Linus Walleij
2023-10-09 7:49 ` Linus Walleij
2023-10-09 9:08 ` Cristian Marussi
2023-10-09 9:08 ` Cristian Marussi
2023-10-09 13:13 ` Linus Walleij
2023-10-09 13:13 ` Linus Walleij
2023-10-09 15:08 ` Cristian Marussi
2023-10-09 15:08 ` Cristian Marussi
2023-10-10 5:14 ` AKASHI Takahiro
2023-10-10 5:14 ` AKASHI Takahiro
2023-10-10 5:25 ` AKASHI Takahiro
2023-10-10 5:25 ` AKASHI Takahiro
2023-10-12 7:25 ` Linus Walleij
2023-10-12 7:25 ` Linus Walleij
2023-10-17 2:32 ` AKASHI Takahiro
2023-10-17 2:32 ` AKASHI Takahiro
2023-10-23 8:12 ` Linus Walleij
2023-10-23 8:12 ` Linus Walleij
2023-10-24 7:12 ` AKASHI Takahiro
2023-10-24 7:12 ` AKASHI Takahiro
2023-10-24 9:40 ` Linus Walleij
2023-10-24 9:40 ` Linus Walleij
2023-10-24 10:55 ` Cristian Marussi
2023-10-24 10:55 ` Cristian Marussi
2023-10-24 13:01 ` Linus Walleij
2023-10-24 13:01 ` Linus Walleij
2023-10-24 11:09 ` AKASHI Takahiro
2023-10-24 11:09 ` AKASHI Takahiro
2023-10-24 13:12 ` Linus Walleij
2023-10-24 13:12 ` Linus Walleij
2023-10-24 13:42 ` AKASHI Takahiro
2023-10-24 13:42 ` AKASHI Takahiro
2023-11-05 22:15 ` Linus Walleij
2023-11-05 22:15 ` Linus Walleij
2023-10-19 21:27 ` [RFC v2 0/5] gpio: add " andy.shevchenko
2023-10-19 21:27 ` andy.shevchenko
2023-10-20 0:21 ` AKASHI Takahiro [this message]
2023-10-20 0:21 ` AKASHI Takahiro
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=ZTHH7vwG7hRneZls@octopus \
--to=takahiro.akashi@linaro.org \
--cc=Oleksii_Moisieiev@epam.com \
--cc=andy.shevchenko@gmail.com \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sudeep.holla@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.