From: Brian Masney <masneyb@onstation.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
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/4 v1] gpio: Add support for hierarchical IRQ domains
Date: Fri, 28 Jun 2019 06:43:31 -0400 [thread overview]
Message-ID: <20190628104331.GB17335@onstation.org> (raw)
In-Reply-To: <20190624132531.6184-1-linus.walleij@linaro.org>
On Mon, Jun 24, 2019 at 03:25:28PM +0200, Linus Walleij wrote:
> +static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
> + unsigned int irq,
> + unsigned int nr_irqs,
> + void *data)
> +{
> + struct gpio_chip *gc = d->host_data;
> + irq_hw_number_t hwirq;
> + unsigned int type = IRQ_TYPE_NONE;
> + struct irq_fwspec *fwspec = data;
> + int ret;
> + int i;
> +
> + chip_info(gc, "called %s\n", __func__);
> +
> + ret = gpiochip_hierarchy_irq_domain_translate(d, fwspec, &hwirq, &type);
> + if (ret)
> + return ret;
> +
> + chip_info(gc, "allocate IRQ %d..%d, hwirq %lu..%lu\n",
> + irq, irq + nr_irqs - 1,
> + hwirq, hwirq + nr_irqs - 1);
> +
> + for (i = 0; i < nr_irqs; i++) {
> + struct irq_fwspec parent_fwspec;
> + unsigned int parent_hwirq;
> + unsigned int parent_type;
> + struct gpio_irq_chip *girq = &gc->irq;
> +
> + ret = girq->child_to_parent_hwirq(gc, hwirq, type,
> + &parent_hwirq, &parent_type);
> + if (ret) {
> + chip_err(gc, "can't look up hwirq %lu\n", hwirq);
> + return ret;
> + }
> + chip_info(gc, "found parent hwirq %u\n", parent_hwirq);
> +
> + /*
> + * We set handle_bad_irq because the .set_type() should
> + * always be invoked and set the right type of handler.
> + */
> + irq_domain_set_info(d,
> + irq + i,
> + hwirq + i,
> + gc->irq.chip,
> + gc,
> + handle_bad_irq,
> + NULL, NULL);
> + irq_set_probe(irq + i);
> +
> + /*
> + * Create a IRQ fwspec to send up to the parent irqdomain:
> + * specify the hwirq we address on the parent and tie it
> + * all together up the chain.
> + */
> + parent_fwspec.fwnode = d->parent->fwnode;
> + parent_fwspec.param_count = 2;
> + parent_fwspec.param[0] = parent_hwirq;
> + /* This parent only handles asserted level IRQs */
> + parent_fwspec.param[1] = parent_type;
> + chip_info(gc, "alloc_irqs_parent for %d parent hwirq %d\n",
> + irq + i, parent_hwirq);
> + ret = irq_domain_alloc_irqs_parent(d, irq + i, 1,
> + &parent_fwspec);
I started to convert qcom's spmi-gpio over to this new API. I'm not done
yet but I noticed that this new API assumes two cells for the parent,
however spmi-gpio's parent (drivers/spmi/spmi-pmic-arb.c) expects four
cells. See pmic_gpio_domain_alloc() in
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c for more details.
What do you think about adding a function pointer to struct
gpio_irq_chip that is used to populate the parent_fwspec?
Brian
next prev parent reply other threads:[~2019-06-28 10:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 13:25 [PATCH 1/4 v1] gpio: Add support for hierarchical IRQ domains Linus Walleij
2019-06-24 13:25 ` [PATCH 2/4 v1] gpio: ixp4xx: Convert to hieararchical GPIOLIB_IRQCHIP Linus Walleij
2019-06-24 13:25 ` [PATCH 3/4 v1] RFT: gpio: thunderx: Switch to GPIOLIB_IRQCHIP Linus Walleij
2019-06-24 13:25 ` [PATCH 4/4 v1] RFT: gpio: uniphier: " Linus Walleij
2019-07-18 11:09 ` Masahiro Yamada
2019-08-08 11:57 ` Linus Walleij
2019-06-26 21:09 ` [PATCH 1/4 v1] gpio: Add support for hierarchical IRQ domains Lina Iyer
2019-06-28 9:14 ` Linus Walleij
2019-06-28 15:58 ` Lina Iyer
2019-07-03 6:33 ` Linus Walleij
2019-06-27 20:44 ` Lina Iyer
2019-06-28 10:43 ` Brian Masney [this message]
2019-06-28 11:11 ` Linus Walleij
2019-07-03 9:22 ` Brian Masney
2019-07-03 12:39 ` Linus Walleij
2019-07-07 1:46 ` Brian Masney
2019-07-07 8:09 ` Linus Walleij
2019-07-09 2:37 ` Brian Masney
2019-07-18 11:12 ` Masahiro Yamada
2019-08-07 14:43 ` Linus Walleij
2019-08-07 15: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=20190628104331.GB17335@onstation.org \
--to=masneyb@onstation.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=marc.zyngier@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.