From: Brian Masney <masneyb@onstation.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: linus.walleij@linaro.org, sboyd@kernel.org,
bjorn.andersson@linaro.org, andy.gross@linaro.org,
shawnguo@kernel.org, dianders@chromium.org,
linux-gpio@vger.kernel.org, nicolas.dechesne@linaro.org,
niklas.cassel@linaro.org, david.brown@linaro.org,
robh+dt@kernel.org, mark.rutland@arm.com,
thierry.reding@gmail.com, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v5 07/14] qcom: spmi-gpio: add support for hierarchical IRQ chip
Date: Fri, 18 Jan 2019 07:42:21 -0500 [thread overview]
Message-ID: <20190118124221.GB32143@basecamp> (raw)
In-Reply-To: <e9234c48-9fce-1ec4-48f1-dff134559eed@arm.com>
Hi Marc,
On Thu, Jan 17, 2019 at 11:32:01AM +0000, Marc Zyngier wrote:
> > static int pmic_gpio_to_irq(struct gpio_chip *chip, unsigned pin)
> > {
> > struct pmic_gpio_state *state = gpiochip_get_data(chip);
> > - struct pmic_gpio_pad *pad;
> > + struct irq_fwspec fwspec;
> >
> > - pad = state->ctrl->desc->pins[pin].drv_data;
> > + fwspec.fwnode = state->fwnode;
> > + fwspec.param_count = 2;
> > + fwspec.param[0] = pin + PMIC_GPIO_PHYSICAL_OFFSET;
> > + fwspec.param[1] = IRQ_TYPE_NONE;
>
> In my experience, IRQ_TYPE_NONE is rarely a good thing, unless you
> expect the trigger information to be found by some other mean. I guess
> that's one of the reasons why everything falls back to level in the SPMI
> driver...
I'm not sure how to determine what trigger to put here. I thought that
it would be up to the caller of request_any_context_irq() to explicitly
set the expected trigger type when a GPIO is used, which will overwrite
IRQ_TYPE_NONE with the proper trigger type.
For example, I've tested the hierarchical IRQ domains with gpio-keys and
when the gpio property is used, devm_request_any_context_irq() is called
with the flags IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING. This calls
__setup_irq(), which will call irq_set_type() and overwrite the trigger
type.
irq_set_type() is only called when the IRQ is not shared, so I'm not
sure if this would work as expected with a shared IRQ.
Brian
next prev parent reply other threads:[~2019-01-18 12:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 0:32 [PATCH v5 00/14] qcom: spmi: add support for hierarchical IRQ chip Brian Masney
2019-01-17 0:32 ` [PATCH v5 01/14] dt-bindings: pinctrl: qcom-pmic-gpio: add qcom,pmi8998-gpio binding Brian Masney
2019-01-17 0:32 ` [PATCH v5 02/14] pinctrl: qcom: spmi-gpio: add support for three new variants Brian Masney
2019-01-17 0:32 ` [PATCH v5 03/14] pinctrl: qcom: spmi-gpio: hardcode IRQ counts Brian Masney
2019-01-17 0:32 ` [PATCH v5 04/14] spmi: pmic-arb: convert to v2 irq interfaces to support hierarchical IRQ chips Brian Masney
2019-01-17 11:22 ` Marc Zyngier
2019-01-18 12:27 ` Brian Masney
2019-01-18 13:12 ` Marc Zyngier
2019-01-17 0:32 ` [PATCH v5 05/14] gpio: add irq domain activate/deactivate functions Brian Masney
2019-01-17 0:32 ` [PATCH v5 06/14] spmi: pmic-arb: disassociate old virq if hwirq mapping already exists Brian Masney
2019-01-17 0:32 ` [PATCH v5 07/14] qcom: spmi-gpio: add support for hierarchical IRQ chip Brian Masney
2019-01-17 11:32 ` Marc Zyngier
2019-01-18 12:42 ` Brian Masney [this message]
2019-01-18 13:21 ` Marc Zyngier
2019-01-17 0:32 ` [PATCH v5 08/14] ARM: dts: qcom: pm8941: add interrupt controller properties Brian Masney
2019-01-17 0:32 ` [PATCH v5 09/14] ARM: dts: qcom: pma8084: " Brian Masney
2019-01-17 0:32 ` [PATCH v5 10/14] arm64: dts: qcom: pm8005: " Brian Masney
2019-01-17 0:32 ` [PATCH v5 11/14] arm64: dts: qcom: pm8998: " Brian Masney
2019-01-17 0:32 ` [PATCH v5 12/14] arm64: dts: qcom: pmi8994: " Brian Masney
2019-01-17 0:32 ` [PATCH v5 13/14] arm64: dts: qcom: pmi8998: " Brian Masney
2019-01-17 0:32 ` [PATCH v5 14/14] spmi: pmic-arb: revert "disassociate old virq if hwirq mapping already exists" Brian Masney
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=20190118124221.GB32143@basecamp \
--to=masneyb@onstation.org \
--cc=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=nicolas.dechesne@linaro.org \
--cc=niklas.cassel@linaro.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.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;
as well as URLs for NNTP newsgroup(s).