From: Marc Zyngier <maz@kernel.org>
To: Lina Iyer <ilina@codeaurora.org>
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: Tue, 27 Aug 2019 10:00:47 +0100 [thread overview]
Message-ID: <c812668e-0caf-4169-9990-9a7760adbb4e@kernel.org> (raw)
In-Reply-To: <20190826201400.GC26639@codeaurora.org>
On 26/08/2019 21:14, Lina Iyer wrote:
> On Mon, Aug 26 2019 at 13:02 -0600, Marc Zyngier wrote:
>> On Mon, 26 Aug 2019 10:15:26 -0600
>> Lina Iyer <ilina@codeaurora.org> wrote:
>>
>>> 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?
>>
>> [desperately trying to switch to my korg address...]
>>
>> I'm not sure I fully get the question: if this is whether it is worth
>> implementing it, it usually is a good idea if the HW supports is. But I
>> have the feeling that this isn't your question, so maybe explaining
>> your use-case would help.
>>
>> Do you mean using irq_set_irqchip_state from within an irqchip driver?
>> That'd be quite odd, as this function is usually used when something
>> *outside* of the irqchip driver needs to poke at some internal state
>> because "it knows best" (see for example what KVM does with the active
>> state).
>>
> Yeah, I meant to say, when invoked on a parent irqchip from a child
> irqchip.
>
> In my case when GPIO is used as an interrupt. Even though the interrupt
> is not enabled, the GPIO could cause the GIC_ISPEND to be set at GIC. We
> were wondering if we could use the irq_set_irqchip_state to clear
> pending state at GPIO's irqchip parent and all the way to GIC, when the
> GPIO is enabled as an interrupt.
You can of course chain the call from one level to its parent. It's a
bit odd to have to clear a pending bit in this context, but I guess
that's a HW-specific limitation.
M.
--
Jazz is not dead, it just smells funny...
prev parent reply other threads:[~2019-08-27 9:00 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
2019-08-26 18:44 ` Marc Zyngier
2019-08-26 20:14 ` Lina Iyer
2019-08-27 9:00 ` Marc Zyngier [this message]
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=c812668e-0caf-4169-9990-9a7760adbb4e@kernel.org \
--to=maz@kernel.org \
--cc=bbiswas@nvidia.com \
--cc=bgolaszewski@baylibre.com \
--cc=david.daney@cavium.com \
--cc=ilina@codeaurora.org \
--cc=jonathanh@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--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).