From: Lina Iyer <ilina@codeaurora.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Brian Masney <masneyb@onstation.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Thomas Gleixner <tglx@linutronix.de>,
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: Mon, 26 Aug 2019 10:15:26 -0600 [thread overview]
Message-ID: <20190826161526.GB26639@codeaurora.org> (raw)
In-Reply-To: <63f2d086-eb71-4153-071e-71102fe24a14@arm.com>
On Fri, Aug 23 2019 at 03:12 -0600, Marc Zyngier wrote:
>On 23/08/2019 09:24, Linus Walleij wrote:
>> 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?
>
>Certainly, I'd like to gradually move over from the IRQ number to an
>irq_desc. In interrupt-heavy contexts, this ends up being quite time
>consuming. I have an old patch series somewhere changing irq domains to
>use irq_descs internally instead of IRQ numbers, which I should maybe
>revive.
>
>As for __irq_get_irqchip_state, the main issue is that it doesn't
>perform any locking on its own, so you'd have to either provide your
>own, or wrap it with something else.
>
Marc, on a related note, What are your thoughts on a
irq_set_irqchip_state? We are running into an issue where chip state
clear is required as well as clearing out that of the parent. Do you see
problems in doing that from an irqchip driver?
--Lina
next prev parent reply other threads:[~2019-08-26 16:15 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
2019-08-23 9:12 ` Marc Zyngier
2019-08-23 10:13 ` Linus Walleij
2019-08-26 16:15 ` Lina Iyer [this message]
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=20190826161526.GB26639@codeaurora.org \
--to=ilina@codeaurora.org \
--cc=bbiswas@nvidia.com \
--cc=bgolaszewski@baylibre.com \
--cc=david.daney@cavium.com \
--cc=jonathanh@nvidia.com \
--cc=linus.walleij@linaro.org \
--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).