linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).