From: Linus Walleij <linus.walleij@linaro.org>
To: Brian Masney <masneyb@onstation.org>,
Marc Zyngier <marc.zyngier@arm.com>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Thomas Gleixner <tglx@linutronix.de>,
Lina Iyer <ilina@codeaurora.org>,
Jon Hunter <jonathanh@nvidia.com>,
Sowjanya Komatineni <skomatineni@nvidia.com>,
Bitan Biswas <bbiswas@nvidia.com>,
linux-tegra@vger.kernel.org, David Daney <david.daney@cavium.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains
Date: Fri, 23 Aug 2019 10:24:53 +0200 [thread overview]
Message-ID: <CACRpkdbZSJ4ggprUXaBJ07Hz=eryuy5=AmYOigTUmO9z4yahfQ@mail.gmail.com> (raw)
In-Reply-To: <20190816011054.GA1041@onstation.org>
Hi Brian,
I tried to look into this ssbi-gpio problem...
Paging in Marc Z as well.
On Fri, Aug 16, 2019 at 3:10 AM Brian Masney <masneyb@onstation.org> wrote:
> I started to convert ssbi-gpio over to this and pm8xxx_gpio_to_irq() has
> this little snippet that's different from spmi-gpio:
>
> [ fwspec mapping code ]
>
> /*
> * Cache the IRQ since pm8xxx_gpio_get() needs this to get determine the
> * line level.
> */
> pin->irq = ret;
>
> Here's the relevant code in pm8xxx_gpio_get():
>
> if (pin->mode == PM8XXX_GPIO_MODE_OUTPUT) {
> ret = pin->output_value;
> } else if (pin->irq >= 0) {
> ret = irq_get_irqchip_state(pin->irq, IRQCHIP_STATE_LINE_LEVEL, &state);
> ...
> }
It's a bit annoying that this API (irq_get_irqchip_state()) is relying on
the global irq numbers and the internal function using irqdesc
__irq_get_irqchip_state() is not exported.
We should be encouraged to operate on IRQ descriptors rather
than IRQ numbers when doing this kind of deep core work,
right?
> What do you think about using EXPORT_SYMBOL_GPL() for gpiochip_to_irq() so
> that we can call it in pm8xxx_gpio_to_irq()?
I would like to avoid that because people tend to abuse every
API I expose (leasson learnt: APIs shall be narrow and deep).
> Or do you have any other
> suggestions for how we can get rid of that IRQ cache?
So the issue is that moving this to the hierarchical helpers
rids pm8xxx_gpio_to_irq() and we needed that to map this.
I would rather just add a new driver API to wrap the irqchip
API:
ret = gpiochip_get_irq_state(offset, IRQCHIP_STATE_LINE_LEVEL, &state);
Where int gpiochip_get_own_irq_state(int offset, ...) will figure
out the gpio_desc of the offset and then call gpiod_to_irq()
and then use that irq number to call irq_get_irqchip_state()
and the goal is met.
This should work I think, and expose a more precise
API for what this driver wants.
> I don't see any other issues for ssbi-gpio.
That's good news!
Yours,
Linus Walleij
next prev parent reply other threads:[~2019-08-23 8:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 12:32 [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains Linus Walleij
2019-08-08 12:32 ` [PATCH 2/6 v2] gpio: ixp4xx: Convert to hierarchical GPIOLIB_IRQCHIP Linus Walleij
2019-08-08 12:32 ` [PATCH 3/6 v2] qcom: spmi-gpio: convert to hierarchical IRQ helpers in gpio core Linus Walleij
2019-08-14 8:19 ` Linus Walleij
2019-08-08 12:32 ` [PATCH 4/6 v2] RFT: gpio: thunderx: Switch to GPIOLIB_IRQCHIP Linus Walleij
2019-08-14 8:21 ` Linus Walleij
2019-08-08 12:32 ` [PATCH 5/6 v2] RFT: gpio: uniphier: " Linus Walleij
2019-08-08 12:32 ` [PATCH 6/6 v2] RFT: gpio: uniphier: Restrict valid interrupts Linus Walleij
2019-08-14 8:18 ` [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains Linus Walleij
2019-08-16 1:10 ` Brian Masney
2019-08-23 8:24 ` Linus Walleij [this message]
2019-08-23 9:12 ` Marc Zyngier
2019-08-23 10:13 ` Linus Walleij
2019-08-26 16:15 ` Lina Iyer
2019-08-26 18:44 ` Marc Zyngier
2019-08-26 20:14 ` Lina Iyer
2019-08-27 9:00 ` Marc Zyngier
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='CACRpkdbZSJ4ggprUXaBJ07Hz=eryuy5=AmYOigTUmO9z4yahfQ@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=bbiswas@nvidia.com \
--cc=bgolaszewski@baylibre.com \
--cc=david.daney@cavium.com \
--cc=ilina@codeaurora.org \
--cc=jonathanh@nvidia.com \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=masneyb@onstation.org \
--cc=skomatineni@nvidia.com \
--cc=tglx@linutronix.de \
--cc=treding@nvidia.com \
--cc=yamada.masahiro@socionext.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;
as well as URLs for NNTP newsgroup(s).