From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Andrew Bresticker <abrestic@chromium.org>,
James Hogan <james.hogan@imgtec.com>,
Shawn Guo <shawn.guo@linaro.org>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 00/16] gpio: Tight IRQ chip integration and banked infrastructure
Date: Tue, 3 Oct 2017 13:26:38 -0500 [thread overview]
Message-ID: <b583d903-03ea-eb74-e142-02b31ad3ddfb@ti.com> (raw)
In-Reply-To: <CACRpkdagAxotP=VZr1NUvmNmHgACfr4x2aHkh=nyyEhUWWgzPw@mail.gmail.com>
On 10/02/2017 02:55 AM, Linus Walleij wrote:
> On Thu, Sep 28, 2017 at 4:22 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>
>> Sry, but I do not agree with this series.
>> - no prof that it can be re-used by other drivers than tegra
>> (at least I do not see reasons to re-use it for any TI drivers)
>
> This is not necessarily a blocker if it can be shown that others than
> TI/OMAP can reuse it.
sure. My point is - this is big change in gpiolib, which is > 1000 lines,
but current re-usability just 2 drivers (I'm comparing with your work when
gpio irq infra was introduced - you did it bottom-up, by refactoring
existing drivers and moving common code in gpiolib, so re usability is great).
>
> I've looked at things like the imagination pistachio:
>
> pinctrl@18101C00 {
> compatible = "img,pistachio-system-pinctrl";
> reg = <0x18101C00 0x400>;
>
> gpio0: gpio0 {
> interrupts = <GIC_SHARED 71 IRQ_TYPE_LEVEL_HIGH>;
>
> gpio-controller;
> #gpio-cells = <2>;
>
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> ...
>
> gpio5: gpio5 {
> interrupts = <GIC_SHARED 76 IRQ_TYPE_LEVEL_HIGH>;
>
> gpio-controller;
> #gpio-cells = <2>;
>
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> This looks like a clear candidate.
> CC: to Andrew Bresticker, can you look into this?
>
[...]
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
#gpio-cells = <2>;
reg = <0x226000 0x1000>;
interrupts = <42 IRQ_TYPE_EDGE_BOTH
43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
ti,ngpio = <144>;
ti,davinci-gpio-unbanked = <0>;
status = "disabled";
interrupt-controller;
#interrupt-cells = <2>;
};
FYI. Above is gpio-dvinci example which defines the same, but without coding
gpio banks in DT (note 2 IRQ lines per bank, bank 32 pins).
>
> CC to Shawn Guo to look into this.
>
> So in short I think there can be others that can make good use of this
> infrastructure.
>
>> - all GPIO IRQs mapped statically
>
> This really needs to be fixed.
>
>> - irq->map[offset + j] = irq->parents[parent]; holds IRQs for all pins
>> which is waste of memory
>> - DT binding changes not documented and no DT examples
>> - below is ugly ;)
>> + bank = (spec[0] >> gc->of_gpio_bank_mask) & gc->of_gpio_bank_shift;
>> + pin = (spec[0] >> gc->of_gpio_pin_mask) & gc->of_gpio_pin_shift;
>
> These should be fixable quite easily I think. Thierry?
What I'm trying to understand is how GPIO client bindings will look like?
Now it is: gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; (pistachio_marduk.dts)
But as per of_gpio_banked_xlate() it expected to be
gpios = <&gpio [Linear gpio num] GPIO_ACTIVE_LOW>;
Wouldn't this break DT compatibility and prevent re-using of this feature
for pistachio, for example? (or i'm missing smth).
--
regards,
-grygorii
next prev parent reply other threads:[~2017-10-03 18:26 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-28 9:56 [PATCH v2 00/16] gpio: Tight IRQ chip integration and banked infrastructure Thierry Reding
2017-09-28 9:56 ` [PATCH v2 01/16] gpio: Implement tighter IRQ chip integration Thierry Reding
2017-09-28 14:22 ` Grygorii Strashko
2017-10-10 22:56 ` Grygorii Strashko
2017-09-28 9:56 ` [PATCH v2 02/16] gpio: Move irqchip into struct gpio_irq_chip Thierry Reding
2017-09-28 9:56 ` [PATCH v2 03/16] gpio: Move irqdomain " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 04/16] gpio: Move irq_base to " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 05/16] gpio: Move irq_handler " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 06/16] gpio: Move irq_default_type " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 07/16] gpio: Move irq_chained_parent " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 08/16] gpio: Move irq_nested into " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 09/16] gpio: Move irq_valid_mask " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 10/16] gpio: Move lock_key " Thierry Reding
2017-09-28 9:56 ` [PATCH v2 11/16] gpio: Add Tegra186 support Thierry Reding
2017-09-28 9:56 ` [PATCH v2 12/16] gpio: omap: Fix checkpatch warnings Thierry Reding
2017-09-28 9:56 ` [PATCH v2 13/16] gpio: omap: Rename struct gpio_bank to struct omap_gpio_bank Thierry Reding
2017-09-28 9:56 ` [PATCH v2 14/16] gpio: Add support for banked GPIO controllers Thierry Reding
2017-10-09 21:52 ` Grygorii Strashko
2017-10-10 11:00 ` Thierry Reding
2017-10-10 22:12 ` Grygorii Strashko
2017-09-28 9:56 ` [PATCH v2 15/16] gpio: tegra: Use banked GPIO infrastructure Thierry Reding
2017-10-09 21:22 ` Grygorii Strashko
2017-10-10 10:27 ` Thierry Reding
2017-10-10 19:31 ` Grygorii Strashko
2017-09-28 9:56 ` [PATCH v2 16/16] gpio: tegra186: " Thierry Reding
2017-09-28 14:22 ` [PATCH v2 00/16] gpio: Tight IRQ chip integration and banked infrastructure Grygorii Strashko
2017-10-02 7:55 ` Linus Walleij
2017-10-03 18:26 ` Grygorii Strashko [this message]
2017-10-05 11:19 ` Linus Walleij
2017-10-05 11:14 ` Linus Walleij
2017-10-06 11:07 ` Thierry Reding
2017-10-06 11:11 ` Thierry Reding
2017-10-09 21:56 ` Grygorii Strashko
2017-10-10 11:27 ` Thierry Reding
2017-10-10 22:56 ` Grygorii Strashko
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=b583d903-03ea-eb74-e142-02b31ad3ddfb@ti.com \
--to=grygorii.strashko@ti.com \
--cc=abrestic@chromium.org \
--cc=james.hogan@imgtec.com \
--cc=jonathanh@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=shawn.guo@linaro.org \
--cc=thierry.reding@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox