| Message ID | 20190624132531.6184-1-linus.walleij@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4,v1] gpio: Add support for hierarchical IRQ domains | expand |
Thanks for the patch Linus. I was running into the warning in gpiochip_set_irq_hooks(), because it was called from two places. Hopefully, this will fix that as well. I will give it a try. On Mon, Jun 24 2019 at 07:29 -0600, Linus Walleij wrote: >Hierarchical IRQ domains can be used to stack different IRQ >controllers on top of each other. > >Bring hierarchical IRQ domains into the GPIOLIB core with the >following basic idea: > >Drivers that need their interrupts handled hierarchically >specify a callback to translate the child hardware IRQ and >IRQ type for each GPIO offset to a parent hardware IRQ and >parent hardware IRQ type. > >Users have to pass the callback, fwnode, and parent irqdomain >before calling gpiochip_irqchip_add(). > >We use the new method of just filling in the struct >gpio_irq_chip before adding the gpiochip for all hierarchical >irqchips of this type. > >The code path for device tree is pretty straight-forward, >while the code path for old boardfiles or anything else will >be more convoluted requireing upfront allocation of the >interrupts when adding the chip. > >One specific use-case where this can be useful is if a power >management controller has top-level controls for wakeup >interrupts. In such cases, the power management controller can >be a parent to other interrupt controllers and program >additional registers when an IRQ has its wake capability >enabled or disabled. > >The hierarchical irqchip helper code will only be available >when IRQ_DOMAIN_HIERARCHY is selected to GPIO chips using >this should select or depend on that symbol. When using >hierarchical IRQs, the parent interrupt controller must >also be hierarchical all the way up to the top interrupt >controller wireing directly into the CPU, so on systems >that do not have this we can get rid of all the extra >code for supporting hierarchical irqs. > >Cc: Thomas Gleixner <tglx@linutronix.de> >Cc: Marc Zyngier <marc.zyngier@arm.com> >Cc: Lina Iyer <ilina@codeaurora.org> >Cc: Jon Hunter <jonathanh@nvidia.com> >Cc: Sowjanya Komatineni <skomatineni@nvidia.com> >Cc: Bitan Biswas <bbiswas@nvidia.com> >Cc: linux-tegra@vger.kernel.org >Cc: David Daney <david.daney@cavium.com> >Cc: Masahiro Yamada <yamada.masahiro@socionext.com> >Cc: Brian Masney <masneyb@onstation.org> >Signed-off-by: Thierry Reding <treding@nvidia.com> >Signed-off-by: Linus Walleij <linus.walleij@linaro.org> >--- >ChangeLog RFC->v1: >- Tested on real hardware >- Incorporate Thierry's idea to have a translation callback. > He was right about this approach, I was wrong in insisting > on IRQ maps. >--- > Documentation/driver-api/gpio/driver.rst | 120 ++++++++-- > drivers/gpio/gpiolib.c | 285 ++++++++++++++++++++++- > include/linux/gpio/driver.h | 46 ++++ > 3 files changed, 426 insertions(+), 25 deletions(-) > >diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst >index 1ce7fcd0f989..3099c7fbefdb 100644 >--- a/Documentation/driver-api/gpio/driver.rst >+++ b/Documentation/driver-api/gpio/driver.rst >@@ -259,7 +259,7 @@ most often cascaded off a parent interrupt controller, and in some special > cases the GPIO logic is melded with a SoC's primary interrupt controller. > > The IRQ portions of the GPIO block are implemented using an irq_chip, using >-the header <linux/irq.h>. So basically such a driver is utilizing two sub- >+the header <linux/irq.h>. So this combined driver is utilizing two sub- > systems simultaneously: gpio and irq. > > It is legal for any IRQ consumer to request an IRQ from any irqchip even if it >@@ -391,14 +391,108 @@ Infrastructure helpers for GPIO irqchips > ---------------------------------------- > > To help out in handling the set-up and management of GPIO irqchips and the >-associated irqdomain and resource allocation callbacks, the gpiolib has >-some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig >-symbol: >- >-- gpiochip_irqchip_add(): adds a chained cascaded irqchip to a gpiochip. It >- will pass the struct gpio_chip* for the chip to all IRQ callbacks, so the >- callbacks need to embed the gpio_chip in its state container and obtain a >- pointer to the container using container_of(). >+associated irqdomain and resource allocation callbacks. These are activated >+by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol >+IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be >+provided. A big portion of overhead code will be managed by gpiolib, >+under the assumption that your interrupts are 1-to-1-mapped to the >+GPIO line index: >+ >+ GPIO line offset Hardware IRQ >+ 0 0 >+ 1 1 >+ 2 2 >+ ... ... >+ ngpio-1 ngpio-1 >+ >+If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask >+and the flag need_valid_mask in gpio_irq_chip can be used to mask off some >+lines as invalid for associating with IRQs. >+ >+The preferred way to set up the helpers is to fill in the >+struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. >+If you do this, the additional irq_chip will be set up by gpiolib at the >+same time as setting up the rest of the GPIO functionality. The following >+is a typical example of a cascaded interrupt handler using gpio_irq_chip: >+ >+ /* Typical state container with dynamic irqchip */ >+ struct my_gpio { >+ struct gpio_chip gc; >+ struct irq_chip irq; >+ }; >+ >+ int irq; /* from platform etc */ >+ struct my_gpio *g; >+ struct gpio_irq_chip *girq >+ >+ /* Set up the irqchip dynamically */ >+ g->irq.name = "my_gpio_irq"; >+ g->irq.irq_ack = my_gpio_ack_irq; >+ g->irq.irq_mask = my_gpio_mask_irq; >+ g->irq.irq_unmask = my_gpio_unmask_irq; >+ g->irq.irq_set_type = my_gpio_set_irq_type; >+ >+ /* Get a pointer to the gpio_irq_chip */ >+ girq = &g->gc.irq; >+ girq->chip = &g->irq; >+ girq->parent_handler = ftgpio_gpio_irq_handler; >+ girq->num_parents = 1; >+ girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), >+ GFP_KERNEL); Could this be folded into the gpiolib? >+ if (!girq->parents) >+ return -ENOMEM; >+ girq->default_type = IRQ_TYPE_NONE; >+ girq->handler = handle_bad_irq; >+ girq->parents[0] = irq; >+ >+ return devm_gpiochip_add_data(dev, &g->gc, g); >+ >+The helper support using hierarchical interrupt controllers as well. >+In this case the typical set-up will look like this: >+ >+ /* Typical state container with dynamic irqchip */ >+ struct my_gpio { >+ struct gpio_chip gc; >+ struct irq_chip irq; >+ struct fwnode_handle *fwnode; >+ }; >+ >+ int irq; /* from platform etc */ >+ struct my_gpio *g; >+ struct gpio_irq_chip *girq >+ >+ /* Set up the irqchip dynamically */ >+ g->irq.name = "my_gpio_irq"; >+ g->irq.irq_ack = my_gpio_ack_irq; >+ g->irq.irq_mask = my_gpio_mask_irq; >+ g->irq.irq_unmask = my_gpio_unmask_irq; >+ g->irq.irq_set_type = my_gpio_set_irq_type; >+ >+ /* Get a pointer to the gpio_irq_chip */ >+ girq = &g->gc.irq; >+ girq->chip = &g->irq; >+ girq->default_type = IRQ_TYPE_NONE; >+ girq->handler = handle_bad_irq; >+ girq->fwnode = g->fwnode; >+ girq->parent_domain = parent; >+ girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; >+ Should be the necessary, if the driver implements it's own .alloc? >+ return devm_gpiochip_add_data(dev, &g->gc, g); >+ >+As you can see pretty similar, but you do not supply a parent handler for >+the IRQ, instead a parent irqdomain, an fwnode for the hardware and >+a funcion .child_to_parent_hwirq() that has the purpose of looking up >+the parent hardware irq from a child (i.e. this gpio chip) hardware irq. >+As always it is good to look at examples in the kernel tree for advice >+on how to find the required pieces. >+ >+The old way of adding irqchips to gpiochips after registration is also still >+available but we try to move away from this: >+ >+- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a >+ gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ >+ callbacks, so the callbacks need to embed the gpio_chip in its state >+ container and obtain a pointer to the container using container_of(). > (See Documentation/driver-model/design-patterns.txt) > > - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, >@@ -406,10 +500,10 @@ symbol: > cascaded irq has to be handled by a threaded interrupt handler. > Apart from that it works exactly like the chained irqchip. > >-- gpiochip_set_chained_irqchip(): sets up a chained cascaded irq handler for a >- gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler >- data. Notice that we pass is as the handler data, since the irqchip data is >- likely used by the parent irqchip. >+- DEPRECATED: gpiochip_set_chained_irqchip(): sets up a chained cascaded irq >+ handler for a gpio_chip from a parent IRQ and passes the struct gpio_chip* >+ as handler data. Notice that we pass is as the handler data, since the >+ irqchip data is likely used by the parent irqchip. > > - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a > gpio_chip from a parent IRQ. As the parent IRQ has usually been >diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c >index e013d417a936..af72ffa02963 100644 >--- a/drivers/gpio/gpiolib.c >+++ b/drivers/gpio/gpiolib.c >@@ -1718,6 +1718,240 @@ void gpiochip_set_nested_irqchip(struct gpio_chip *gpiochip, > } > EXPORT_SYMBOL_GPL(gpiochip_set_nested_irqchip); > >+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY >+ >+/** >+ * gpiochip_set_hierarchical_irqchip() - connects a hierarchical irqchip >+ * to a gpiochip >+ * @gc: the gpiochip to set the irqchip hierarchical handler to >+ * @irqchip: the irqchip to handle this level of the hierarchy, the interrupt >+ * will then percolate up to the parent >+ */ >+static void gpiochip_set_hierarchical_irqchip(struct gpio_chip *gc, >+ struct irq_chip *irqchip) >+{ >+ /* DT will deal with mapping each IRQ as we go along */ >+ if (is_of_node(gc->irq.fwnode)) >+ return; >+ >+ /* >+ * This is for legacy and boardfile "irqchip" fwnodes: allocate >+ * irqs upfront instead of dynamically since we don't have the >+ * dynamic type of allocation that hardware description languages >+ * provide. Once all GPIO drivers using board files are gone from >+ * the kernel we can delete this code, but for a transitional period >+ * it is necessary to keep this around. >+ */ >+ if (is_fwnode_irqchip(gc->irq.fwnode)) { >+ int i; >+ int ret; >+ >+ for (i = 0; i < gc->ngpio; i++) { >+ struct irq_fwspec fwspec; >+ unsigned int parent_hwirq; >+ unsigned int parent_type; >+ struct gpio_irq_chip *girq = &gc->irq; >+ >+ /* >+ * We call the child to parent translation function >+ * only to check if the child IRQ is valid or not. >+ * Just pick the rising edge type here as that is what >+ * we likely need to support. >+ */ >+ ret = girq->child_to_parent_hwirq(gc, i, >+ IRQ_TYPE_EDGE_RISING, >+ &parent_hwirq, >+ &parent_type); >+ if (ret) { >+ chip_err(gc, "skip set-up on hwirq %d\n", >+ i); >+ continue; >+ } >+ >+ fwspec.fwnode = gc->irq.fwnode; >+ /* This is the hwirq for the GPIO line side of things */ >+ fwspec.param[0] = i; >+ /* Just pick something */ >+ fwspec.param[1] = IRQ_TYPE_EDGE_RISING; >+ fwspec.param_count = 2; >+ ret = __irq_domain_alloc_irqs(gc->irq.domain, >+ /* just pick something */ >+ -1, >+ 1, >+ NUMA_NO_NODE, >+ &fwspec, >+ false, >+ NULL); >+ if (ret < 0) { >+ chip_err(gc, >+ "can not allocate irq for GPIO line %d parent hwirq %d in hierarchy domain: %d\n", >+ i, parent_hwirq, >+ ret); >+ } >+ } >+ } >+ >+ chip_err(gc, "%s unknown fwnode type proceed anyway\n", __func__); >+ >+ return; >+} >+ >+static int gpiochip_hierarchy_irq_domain_translate(struct irq_domain *d, >+ struct irq_fwspec *fwspec, >+ unsigned long *hwirq, >+ unsigned int *type) >+{ >+ /* We support standard DT translation */ >+ if (is_of_node(fwspec->fwnode) && fwspec->param_count == 2) { >+ return irq_domain_translate_twocell(d, fwspec, hwirq, type); >+ } >+ >+ /* This is for board files and others not using DT */ >+ if (is_fwnode_irqchip(fwspec->fwnode)) { >+ int ret; >+ >+ ret = irq_domain_translate_twocell(d, fwspec, hwirq, type); >+ if (ret) >+ return ret; >+ WARN_ON(*type == IRQ_TYPE_NONE); >+ return 0; >+ } >+ return -EINVAL; >+} >+ >+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); >+ if (ret) >+ chip_err(gc, >+ "failed to allocate parent hwirq %d for hwirq %lu\n", >+ parent_hwirq, hwirq); >+ } >+ >+ return 0; >+} >+ >+static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { >+ .activate = gpiochip_irq_domain_activate, >+ .deactivate = gpiochip_irq_domain_deactivate, >+ .translate = gpiochip_hierarchy_irq_domain_translate, >+ .alloc = gpiochip_hierarchy_irq_domain_alloc, >+ .free = irq_domain_free_irqs_common, >+}; >+ >+static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) >+{ >+ if (!gc->irq.parent_domain) { >+ chip_err(gc, "missing parent irqdomain\n"); >+ return -EINVAL; >+ } >+ >+ if (!gc->irq.parent_domain || >+ !gc->irq.child_to_parent_hwirq || This should probably be validated if the .ops have not been set. >+ !gc->irq.fwnode) { >+ chip_err(gc, "missing irqdomain vital data\n"); >+ return -EINVAL; >+ } >+ >+ gc->irq.domain = irq_domain_create_hierarchy( >+ gc->irq.parent_domain, >+ IRQ_DOMAIN_FLAG_HIERARCHY, >+ gc->ngpio, >+ gc->irq.fwnode, >+ &gpiochip_hierarchy_domain_ops, >+ gc); >+ >+ if (!gc->irq.domain) { >+ chip_err(gc, "failed to add hierarchical domain\n"); >+ return -EINVAL; >+ } >+ >+ gpiochip_set_hierarchical_irqchip(gc, gc->irq.chip); >+ >+ chip_info(gc, "set up hierarchical irqdomain\n"); >+ >+ return 0; >+} >+ >+static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) >+{ >+ return !!gc->irq.parent_domain; >+} >+ >+#else >+ >+static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) >+{ >+ return -EINVAL; >+} >+ >+static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) >+{ >+ return false; >+} >+ >+#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */ >+ > /** > * gpiochip_irq_map() - maps an IRQ into a GPIO irqchip > * @d: the irqdomain used by this irqchip >@@ -1786,6 +2020,11 @@ static const struct irq_domain_ops gpiochip_domain_ops = { > .xlate = irq_domain_xlate_twocell, > }; > >+/* >+ * TODO: move these activate/deactivate in under the hierarchicial >+ * irqchip implementation as static once SPMI and SSBI (all external >+ * users) are phased over. >+ */ > /** > * gpiochip_irq_domain_activate() - Lock a GPIO to be used as an IRQ > * @domain: The IRQ domain used by this IRQ chip >@@ -1825,10 +2064,23 @@ EXPORT_SYMBOL_GPL(gpiochip_irq_domain_deactivate); > > static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) > { >+ struct irq_domain *domain = chip->irq.domain; >+ > if (!gpiochip_irqchip_irq_valid(chip, offset)) > return -ENXIO; > >- return irq_create_mapping(chip->irq.domain, offset); >+ if (irq_domain_is_hierarchy(domain)) { >+ struct irq_fwspec spec; >+ >+ spec.fwnode = domain->fwnode; >+ spec.param_count = 2; >+ spec.param[0] = offset; >+ spec.param[1] = IRQ_TYPE_NONE; >+ >+ return irq_create_fwspec_mapping(&spec); >+ } >+ >+ return irq_create_mapping(domain, offset); > } > > static int gpiochip_irq_reqres(struct irq_data *d) >@@ -1905,7 +2157,7 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, > struct lock_class_key *request_key) > { > struct irq_chip *irqchip = gpiochip->irq.chip; >- const struct irq_domain_ops *ops; >+ const struct irq_domain_ops *ops = NULL; > struct device_node *np; > unsigned int type; > unsigned int i; >@@ -1941,16 +2193,25 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, > gpiochip->irq.lock_key = lock_key; > gpiochip->irq.request_key = request_key; > >- if (gpiochip->irq.domain_ops) >- ops = gpiochip->irq.domain_ops; >- else >- ops = &gpiochip_domain_ops; >- >- gpiochip->irq.domain = irq_domain_add_simple(np, gpiochip->ngpio, >- gpiochip->irq.first, >- ops, gpiochip); >- if (!gpiochip->irq.domain) >- return -EINVAL; >+ /* If a parent irqdomain is provided, let's build a hierarchy */ >+ if (gpiochip_hierarchy_is_hierarchical(gpiochip)) { >+ int ret = gpiochip_hierarchy_add_domain(gpiochip); >+ if (ret) >+ return ret; >+ } else { >+ /* Some drivers provide custom irqdomain ops */ >+ if (gpiochip->irq.domain_ops) >+ ops = gpiochip->irq.domain_ops; >+ >+ if (!ops) >+ ops = &gpiochip_domain_ops; >+ gpiochip->irq.domain = irq_domain_add_simple(np, >+ gpiochip->ngpio, >+ gpiochip->irq.first, >+ ops, gpiochip); >+ if (!gpiochip->irq.domain) >+ return -EINVAL; >+ } > > if (gpiochip->irq.parent_handler) { > void *data = gpiochip->irq.parent_handler_data ?: gpiochip; >diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h >index a1d273c96016..e32d02cb2d08 100644 >--- a/include/linux/gpio/driver.h >+++ b/include/linux/gpio/driver.h >@@ -22,6 +22,9 @@ enum gpiod_flags; > #ifdef CONFIG_GPIOLIB > > #ifdef CONFIG_GPIOLIB_IRQCHIP >+ >+struct gpio_chip; >+ > /** > * struct gpio_irq_chip - GPIO interrupt controller > */ >@@ -48,6 +51,49 @@ struct gpio_irq_chip { > */ > const struct irq_domain_ops *domain_ops; > >+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY >+ /** >+ * @fwnode: >+ * >+ * Firmware node corresponding to this gpiochip/irqchip, necessary >+ * for hierarchical irqdomain support. >+ */ >+ struct fwnode_handle *fwnode; >+ >+ /** >+ * @parent_domain: >+ * >+ * If non-NULL, will be set as the parent of this GPIO interrupt >+ * controller's IRQ domain to establish a hierarchical interrupt >+ * domain. The presence of this will activate the hierarchical >+ * interrupt support. >+ */ >+ struct irq_domain *parent_domain; >+ >+ /** >+ * @child_to_parent_hwirq: >+ * >+ * This callback translates a child hardware IRQ offset to a parent >+ * hardware IRQ offset on a hierarchical interrupt chip. The child >+ * hardware IRQs correspond to the GPIO index 0..ngpio-1 (see the >+ * ngpio field of struct gpio_chip) and the corresponding parent >+ * hardware IRQ and type (such as IRQ_TYPE_*) shall be returned by >+ * the driver. The driver can calculate this from an offset or using >+ * a lookup table or whatever method is best for this chip. Return >+ * 0 on successful translation in the driver. >+ * >+ * If some ranges of hardware IRQs do not have a corresponding parent >+ * HWIRQ, return -EINVAL, but also make sure to fill in @valid_mask and >+ * @need_valid_mask to make these GPIO lines unavailable for >+ * translation. >+ */ >+ int (*child_to_parent_hwirq)(struct gpio_chip *chip, >+ unsigned int child_hwirq, >+ unsigned int child_type, >+ unsigned int *parent_hwirq, >+ unsigned int *parent_type); Would irq_fwspec(s) be better than passing all these arguments around? Thanks, Lina >+#endif >+ > /** > * @handler: > * >-- >2.21.0 >
On Mon, Jun 24 2019 at 07:29 -0600, Linus Walleij wrote: >+static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { >+ .activate = gpiochip_irq_domain_activate, >+ .deactivate = gpiochip_irq_domain_deactivate, >+ .translate = gpiochip_hierarchy_irq_domain_translate, >+ .alloc = gpiochip_hierarchy_irq_domain_alloc, >+ .free = irq_domain_free_irqs_common, >+}; >+ >+static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) >+{ >+ if (!gc->irq.parent_domain) { >+ chip_err(gc, "missing parent irqdomain\n"); >+ return -EINVAL; >+ } >+ >+ if (!gc->irq.parent_domain || >+ !gc->irq.child_to_parent_hwirq || >+ !gc->irq.fwnode) { >+ chip_err(gc, "missing irqdomain vital data\n"); >+ return -EINVAL; >+ } >+ >+ gc->irq.domain = irq_domain_create_hierarchy( >+ gc->irq.parent_domain, >+ IRQ_DOMAIN_FLAG_HIERARCHY, >+ gc->ngpio, >+ gc->irq.fwnode, >+ &gpiochip_hierarchy_domain_ops, This should probably be used only if gc->irq.domain_ops is not set. >+ gc); >+ >+ if (!gc->irq.domain) { >+ chip_err(gc, "failed to add hierarchical domain\n"); >+ return -EINVAL; >+ } >+ >+ gpiochip_set_hierarchical_irqchip(gc, gc->irq.chip); >+ >+ chip_info(gc, "set up hierarchical irqdomain\n"); >+ >+ return 0; >+} >+ Thanks, Lina
Hi Lina, thanks for your comments! On Wed, Jun 26, 2019 at 10:09 PM Lina Iyer <ilina@codeaurora.org> wrote: > Thanks for the patch Linus. I was running into the warning in > gpiochip_set_irq_hooks(), because it was called from two places. > Hopefully, this will fix that as well. I will give it a try. That's usually when creating two irqchips from a static config. The most common solution is to put struct irq_chip into the driver state container and assign all functions dynamically so the irqchip is a "live" struct if you see how I mean. This is needed because the gpiolib irqchip core will augment some of the pointers in the irqchip, so if that is done twice, it feels a bit shaky. > On Mon, Jun 24 2019 at 07:29 -0600, Linus Walleij wrote: > >+ girq->num_parents = 1; > >+ girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), > >+ GFP_KERNEL); > > Could this be folded into the gpiolib? It is part of the existing API for providing an irq_chip along with the gpio_chip but you are right, it's kludgy. I do have a patch like this, making the parents a static sized field simply: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel-gpio-irqchip So I might go on this approach. (In a separate patch.) > >+ /* Get a pointer to the gpio_irq_chip */ > >+ girq = &g->gc.irq; > >+ girq->chip = &g->irq; > >+ girq->default_type = IRQ_TYPE_NONE; > >+ girq->handler = handle_bad_irq; > >+ girq->fwnode = g->fwnode; > >+ girq->parent_domain = parent; > >+ girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; > >+ > Should be the necessary, if the driver implements it's own .alloc? The idea is that when using GPIOLIB_IRQCHIP and IRQ_DOMAIN_HIERARCHY together, the drivers utilizing GPIOLIB_IRQCHIP will rely on the .alloc() and .translate() implementations in gpiolib so the ambition is that these should cover all hierarchical use cases. > >+static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) > >+{ > >+ if (!gc->irq.parent_domain) { > >+ chip_err(gc, "missing parent irqdomain\n"); > >+ return -EINVAL; > >+ } > >+ > >+ if (!gc->irq.parent_domain || > >+ !gc->irq.child_to_parent_hwirq || > > This should probably be validated if the .ops have not been set. Yeah the idea here is a pretty imperialistic one: the gpiolib always provide the ops for hierarchical IRQ. The library implementation should cover all needs of all consumers, for the hierarchical case. I might be wrong, but then I need to see some example of hierarchies that need something more than what the gpiolib core is providing and idiomatic enough that it can't be rewritten and absolutely must have its own ops. > >+ int (*child_to_parent_hwirq)(struct gpio_chip *chip, > >+ unsigned int child_hwirq, > >+ unsigned int child_type, > >+ unsigned int *parent_hwirq, > >+ unsigned int *parent_type); > > Would irq_fwspec(s) be better than passing all these arguments around? I looked over these three drivers that I patched in the series and they all seemed to need pretty much these arguments, so wrapping it into fwspec would probably just make all drivers have to unwrap them to get child (I guess not parent) back out. But we can patch it later if it proves this is too much arguments for some drivers. Its the right amount for those I changed, AFAICT. Yours, Linus Walleij
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
On Fri, Jun 28, 2019 at 11:43 AM Brian Masney <masneyb@onstation.org> wrote: > 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? I discussed this before with Lina and I naïvely thought we would have only twocell irqchips... OK I was wrong and Lina is right. And I agree, let's put a function pointer for this in gpio_irq_chip and add code so we default to twocell if it is not specified. You can hack something up if you like and I will just put that on top of my patch. Yours, Linus Walleij
Hi Linus, On Fri, Jun 28 2019 at 03:15 -0600, Linus Walleij wrote: >Hi Lina, > >thanks for your comments! > >On Wed, Jun 26, 2019 at 10:09 PM Lina Iyer <ilina@codeaurora.org> wrote: > >> Thanks for the patch Linus. I was running into the warning in >> gpiochip_set_irq_hooks(), because it was called from two places. >> Hopefully, this will fix that as well. I will give it a try. > >That's usually when creating two irqchips from a static config. >The most common solution is to put struct irq_chip into the >driver state container and assign all functions dynamically so >the irqchip is a "live" struct if you see how I mean. This is >needed because the gpiolib irqchip core will augment some >of the pointers in the irqchip, so if that is done twice, it feels >a bit shaky. > Yeah, I realized what was happening. I have fixed it in my drivers. >> On Mon, Jun 24 2019 at 07:29 -0600, Linus Walleij wrote: > >> >+ girq->num_parents = 1; >> >+ girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), >> >+ GFP_KERNEL); >> >> Could this be folded into the gpiolib? > >It is part of the existing API for providing an irq_chip along >with the gpio_chip but you are right, it's kludgy. I do have >a patch like this, making the parents a static sized field >simply: >https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel-gpio-irqchip > >So I might go on this approach. (In a separate patch.) > >> >+ /* Get a pointer to the gpio_irq_chip */ >> >+ girq = &g->gc.irq; >> >+ girq->chip = &g->irq; >> >+ girq->default_type = IRQ_TYPE_NONE; >> >+ girq->handler = handle_bad_irq; >> >+ girq->fwnode = g->fwnode; >> >+ girq->parent_domain = parent; >> >+ girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; >> >+ >> Should be the necessary, if the driver implements it's own .alloc? > >The idea is that when using GPIOLIB_IRQCHIP and >IRQ_DOMAIN_HIERARCHY together, the drivers utilizing >GPIOLIB_IRQCHIP will rely on the .alloc() and .translate() >implementations in gpiolib so the ambition is that these should >cover all hierarchical use cases. > >> >+static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) >> >+{ >> >+ if (!gc->irq.parent_domain) { >> >+ chip_err(gc, "missing parent irqdomain\n"); >> >+ return -EINVAL; >> >+ } >> >+ >> >+ if (!gc->irq.parent_domain || >> >+ !gc->irq.child_to_parent_hwirq || >> >> This should probably be validated if the .ops have not been set. > >Yeah the idea here is a pretty imperialistic one: the gpiolib >always provide the ops for hierarchical IRQ. The library >implementation should cover all needs of all consumers, >for the hierarchical case. > >I might be wrong, but then I need to see some example >of hierarchies that need something more than what the >gpiolib core is providing and idiomatic enough that it can't >be rewritten and absolutely must have its own ops. > Here is an example of what I am working on [1]. The series is based on this patch. What I want to point out is the .alloc function. The TLMM irqchip's parent could be a PDC or a MPM depending on the QCOM SoC architecture. They behave differently. The PDC takes over for the GPIO and handles the monitoring etc, while the MPM comes into play only after the SoC is in low power therefore TLMM needs to do its job. The way to cleanly support both of themis to have our own .alloc functions to help understand the the wakeup-parent irqchip's behavior. Since I need my own .ops, it makes the function below irrelevant to gpiolib. While I would still need a function to translate to parent hwirq, I don't see it any beneficial to gpiolib. thanks, Lina >> >+ int (*child_to_parent_hwirq)(struct gpio_chip *chip, >> >+ unsigned int child_hwirq, >> >+ unsigned int child_type, >> >+ unsigned int *parent_hwirq, >> >+ unsigned int *parent_type); >> >> Would irq_fwspec(s) be better than passing all these arguments around? > >I looked over these three drivers that I patched in the series >and they all seemed to need pretty much these arguments, >so wrapping it into fwspec would probably just make all >drivers have to unwrap them to get child (I guess not parent) >back out. > >But we can patch it later if it proves this is too much arguments >for some drivers. Its the right amount for those I changed, >AFAICT. > >Yours, >Linus Walleij [1]. https://github.com/i-lina/linux/commits/gpio2-2
On Fri, Jun 28, 2019 at 5:58 PM Lina Iyer <ilina@codeaurora.org> wrote: > >I might be wrong, but then I need to see some example > >of hierarchies that need something more than what the > >gpiolib core is providing and idiomatic enough that it can't > >be rewritten and absolutely must have its own ops. > > Here is an example of what I am working on [1]. The series is based on > this patch. What I want to point out is the .alloc function. The TLMM > irqchip's parent could be a PDC or a MPM depending on the QCOM SoC > architecture. They behave differently. The PDC takes over for the GPIO > and handles the monitoring etc, while the MPM comes into play only after > the SoC is in low power therefore TLMM needs to do its job. The way to > cleanly support both of themis to have our own .alloc functions to help > understand the the wakeup-parent irqchip's behavior. > > Since I need my own .ops, it makes the function below irrelevant to > gpiolib. While I would still need a function to translate to parent > hwirq, I don't see it any beneficial to gpiolib. OK I see, I am holding the patch set back for v5.4 so we can make sure that yours and also Brian Masney's drivers will be able to work with this. Let's try to get this in shape for the next kernel. Yours, Linus Walleij
Hi Linus, On Mon, Jun 24, 2019 at 03:25:28PM +0200, Linus Walleij wrote: > static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) > { > + struct irq_domain *domain = chip->irq.domain; > + > if (!gpiochip_irqchip_irq_valid(chip, offset)) > return -ENXIO; > > - return irq_create_mapping(chip->irq.domain, offset); > + if (irq_domain_is_hierarchy(domain)) { > + struct irq_fwspec spec; > + > + spec.fwnode = domain->fwnode; > + spec.param_count = 2; > + spec.param[0] = offset; > + spec.param[1] = IRQ_TYPE_NONE; > + > + return irq_create_fwspec_mapping(&spec); > + } spmi-gpio's to_irq() needs to add one to the offset: static int pmic_gpio_to_irq(struct gpio_chip *chip, unsigned pin) { struct pmic_gpio_state *state = gpiochip_get_data(chip); struct irq_fwspec fwspec; fwspec.fwnode = state->fwnode; fwspec.param_count = 2; fwspec.param[0] = pin + PMIC_GPIO_PHYSICAL_OFFSET; /* * Set the type to a safe value temporarily. This will be overwritten * later with the proper value by irq_set_type. */ fwspec.param[1] = IRQ_TYPE_EDGE_RISING; return irq_create_fwspec_mapping(&fwspec); } ssbi-gpio will have the same problem as well. What do you think about adding a new field to the struct gpio_irq_chip inside the CONFIG_IRQ_DOMAIN_HIERARCHY ifdef called something like to_irq_offset? (I'm bad at naming things.) Also, instead of hardcoding IRQ_TYPE_NONE, what do you think about using the default_type field that's available? Brian
On Wed, Jul 3, 2019 at 11:22 AM Brian Masney <masneyb@onstation.org> wrote: > On Mon, Jun 24, 2019 at 03:25:28PM +0200, Linus Walleij wrote: > > static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) > > { > > + struct irq_domain *domain = chip->irq.domain; > > + > > if (!gpiochip_irqchip_irq_valid(chip, offset)) > > return -ENXIO; > > > > - return irq_create_mapping(chip->irq.domain, offset); > > + if (irq_domain_is_hierarchy(domain)) { > > + struct irq_fwspec spec; > > + > > + spec.fwnode = domain->fwnode; > > + spec.param_count = 2; > > + spec.param[0] = offset; > > + spec.param[1] = IRQ_TYPE_NONE; > > + > > + return irq_create_fwspec_mapping(&spec); > > + } > > spmi-gpio's to_irq() needs to add one to the offset: > > static int pmic_gpio_to_irq(struct gpio_chip *chip, unsigned pin) > { > struct pmic_gpio_state *state = gpiochip_get_data(chip); > struct irq_fwspec fwspec; > > fwspec.fwnode = state->fwnode; > fwspec.param_count = 2; > fwspec.param[0] = pin + PMIC_GPIO_PHYSICAL_OFFSET; > /* > * Set the type to a safe value temporarily. This will be overwritten > * later with the proper value by irq_set_type. > */ > fwspec.param[1] = IRQ_TYPE_EDGE_RISING; > > return irq_create_fwspec_mapping(&fwspec); > } > > ssbi-gpio will have the same problem as well. > > What do you think about adding a new field to the struct gpio_irq_chip > inside the CONFIG_IRQ_DOMAIN_HIERARCHY ifdef called something like > to_irq_offset? (I'm bad at naming things.) I think to cover Lina's need and following the direction set out by Thierry's desire to have callback so we can control the parent-to-child translation with code, it might be best to have an optional callback for translating fwspec.param[0]. Thierry seems to need exactly this for the Tegra driver to, I think that is why it has custom ops today. > Also, instead of hardcoding IRQ_TYPE_NONE, what do you think about using > the default_type field that's available? I want to get rid of the .default_type in the long run, it is nominally only for board files where the .set_type() isn't ever getting called. For anything modern, the .set_type() callback is always called before any irq is used. Yours, Linus Walleij
Hi Linus, On Mon, Jun 24, 2019 at 03:25:28PM +0200, Linus Walleij wrote: > Hierarchical IRQ domains can be used to stack different IRQ > controllers on top of each other. > > Bring hierarchical IRQ domains into the GPIOLIB core with the > following basic idea: I got this working with spmi-gpio with two additional changes. See below for details. Hopefully I'll have time tomorrow evening (GMT-4) to finish cleaning up what I have so I can send out my series. > +static int gpiochip_hierarchy_irq_domain_translate(struct irq_domain *d, > + struct irq_fwspec *fwspec, > + unsigned long *hwirq, > + unsigned int *type) > +{ > + /* We support standard DT translation */ > + if (is_of_node(fwspec->fwnode) && fwspec->param_count == 2) { > + return irq_domain_translate_twocell(d, fwspec, hwirq, type); > + } > + > + /* This is for board files and others not using DT */ > + if (is_fwnode_irqchip(fwspec->fwnode)) { > + int ret; > + > + ret = irq_domain_translate_twocell(d, fwspec, hwirq, type); > + if (ret) > + return ret; > + WARN_ON(*type == IRQ_TYPE_NONE); > + return 0; > + } > + return -EINVAL; > +} > > [ snip ] > > +static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { > + .activate = gpiochip_irq_domain_activate, > + .deactivate = gpiochip_irq_domain_deactivate, > + .translate = gpiochip_hierarchy_irq_domain_translate, > + .alloc = gpiochip_hierarchy_irq_domain_alloc, > + .free = irq_domain_free_irqs_common, > +}; spmi and ssbi gpio both need to subtract one from the hwirq in the translate function. https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c#L956 I'm going to optionally allow overriding the translate() function pointer as well. > +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, ^^^^^^^^^^ In order to get this working, I had to change handle_bad_irq to handle_level_irq otherwise I get this attempted NULL pointer dereference: [ 2.260256] Unable to handle kernel NULL pointer dereference at virtual address 00000018 [ 2.263388] pgd = (ptrval) [ 2.271624] [00000018] *pgd=00000000 [ 2.274149] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2.277877] Modules linked in: [ 2.283174] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc7-next-20190701-00017-g58c27736c3cb-dirty #34 [ 2.286043] Hardware name: Generic DT based system [ 2.295687] PC is at irq_chip_ack_parent+0x8/0x10 [ 2.300540] LR is at __irq_do_set_handler+0x1b4/0x1bc [ 2.305309] pc : [<c0372af4>] lr : [<c0373f6c>] psr: a0000093 [ 2.310343] sp : de899be0 ip : c100f06c fp : 00000001 [ 2.316420] r10: 0000004e r9 : 00000000 r8 : 00000000 [ 2.321626] r7 : 00000000 r6 : 00000000 r5 : c036eea4 r4 : c4e7a600 [ 2.326839] r3 : 00000000 r2 : 00000000 r1 : c0372aec r0 : c4e7d5c0 [ 2.333438] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 2.339947] Control: 10c5787d Table: 0020406a DAC: 00000051 [ 2.347152] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [ 2.352967] Stack: (0xde899be0 to 0xde89a000) [ 2.359063] 9be0: 00000000 00000000 c1004c48 c4e7a600 c036eea4 c0373fc0 60000013 921471da [ 2.363322] 9c00: 0000004e 00000000 c036eea4 00000000 00000000 c0375d44 c4df124c 921471da [ 2.371480] 9c20: c4df124c c4df124c 0000004e 00000000 c4de8900 c06cf28c c4df124c c036eea4 [ 2.379640] 9c40: 00000000 00000000 c1004c48 c0da5e28 c036eea4 c0da5e48 de899c7c 00000001 [ 2.387800] 9c60: 00000000 000000c1 00000000 00000001 c4e7a600 c036e394 c0d74960 00000000 [ 2.395959] 9c80: 0000004f c0af60b0 00000000 00000000 00000002 0000004e c4df0600 00000001 [ 2.404120] 9ca0: 00000000 ffffffff 00000000 c4de8900 c4e7d5c0 921471da c4e27940 c06cf120 [ 2.412278] 9cc0: 00000001 0000004e 0000004e c4de8900 c0e172b4 00000001 c4e7d5c0 c0376bac [ 2.420438] 9ce0: 00000000 c0834274 00000000 c1004c48 c4de8900 de899d4c 00000000 de9d9c10 [ 2.428598] 9d00: 00000001 00000000 c4e27940 c03771d4 de899d4c 00000000 00000000 c06ca5b0 [ 2.436759] 9d20: de9d9db8 00000001 00000000 921471da c1004c48 c4df124c c4de8900 00000001 [ 2.444919] 9d40: de9d9c10 c06c90b8 c27065bc def6e270 00000002 00000002 00000000 c10a2374 [ 2.453077] 9d60: c4d6f810 de9d9c10 de899d80 6f697067 de9d0073 a0000013 c1004c48 00000000 [ 2.461237] 9d80: a0000013 c098977c c4e27940 921471da c4e27940 921471da c4d6f810 c4e6ec8c [ 2.469399] 9da0: c4e2795c 00000000 c27065bc c06c8624 c4e6ec8c c092b1b8 00000001 c27065bc [ 2.477558] 9dc0: c10c59b8 c4e6ec60 00000000 c4e81000 00000000 def757d4 c4e2795c c4e6ec40 [ 2.485717] 9de0: de9d9c00 c092ab44 c092aac8 c092ab60 00000000 de9d9c10 00000000 c10a2608 [ 2.493876] 9e00: 00000000 c10c59b8 00000000 c10a2608 0000000e c0817c00 c110dcf4 de9d9c10 [ 2.502037] 9e20: c110dcf8 c0815738 c10a2608 de9d9c10 c0f004a4 de9d9c10 c10a2608 c10a2608 [ 2.510197] 9e40: c0815fa4 00000000 c0f56838 c0f56858 c0f004a4 c0815bf4 c0f56858 c0989428 [ 2.518355] 9e60: c0bbf5c8 de9d9c10 00000000 c10a2608 c0815fa4 00000000 c0f56838 c0f56858 [ 2.526515] 9e80: c0f004a4 c0815f9c 00000000 c10a2608 de9d9c10 c0816058 de9dab34 c1004c48 [ 2.534677] 9ea0: c10a2608 c0813908 c1095780 de825858 de9dab34 921471da de82586c c10a2608 [ 2.542835] 9ec0: c4e96780 c1095780 00000000 c0814aa0 c0df2cac c1004c48 ffffe000 c10a2608 [ 2.550994] 9ee0: c1004c48 ffffe000 c0f39074 c0816be4 c10b97c0 c1004c48 ffffe000 c0302f7c [ 2.559153] 9f00: 00000000 c0f004a4 c10be278 00000000 00000007 c0d59294 c0dd2fe4 00000000 [ 2.567314] 9f20: 00000000 c1004c48 c0d69934 c0d5934c 00002cc0 dffffbf8 dffffc0d 921471da [ 2.575475] 9f40: 00000000 c10b97c0 dffffa80 921471da c10b97c0 c0f6414c 00000008 c10d2cc0 [ 2.583633] 9f60: c10d2cc0 c0f01204 00000007 00000007 00000000 c0f004a4 000000db 00000000 [ 2.591793] 9f80: c0af5ba8 00000000 c0af5ba8 00000000 00000000 00000000 00000000 00000000 [ 2.599951] 9fa0: 00000000 c0af5bb0 00000000 c03010e8 00000000 00000000 00000000 00000000 [ 2.608111] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.616271] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 2.624430] [<c0372af4>] (irq_chip_ack_parent) from [<c0373f6c>] (__irq_do_set_handler+0x1b4/0x1bc) [ 2.632584] [<c0373f6c>] (__irq_do_set_handler) from [<c0373fc0>] (__irq_set_handler+0x4c/0x78) [ 2.641441] [<c0373fc0>] (__irq_set_handler) from [<c0375d44>] (irq_domain_set_info+0x38/0x4c) [ 2.650126] [<c0375d44>] (irq_domain_set_info) from [<c06cf28c>] (gpiochip_hierarchy_irq_domain_alloc+0x16c/0x22c) [ 2.658808] [<c06cf28c>] (gpiochip_hierarchy_irq_domain_alloc) from [<c0376bac>] (__irq_domain_alloc_irqs+0x12c/0x320) [ 2.669134] [<c0376bac>] (__irq_domain_alloc_irqs) from [<c03771d4>] (irq_create_fwspec_mapping+0x27c/0x344) [ 2.679808] [<c03771d4>] (irq_create_fwspec_mapping) from [<c06c90b8>] (gpiochip_to_irq+0x6c/0xa0) [ 2.689793] [<c06c90b8>] (gpiochip_to_irq) from [<c06c8624>] (gpiod_to_irq+0x48/0x64) [ 2.698558] [<c06c8624>] (gpiod_to_irq) from [<c092b1b8>] (gpio_keys_probe+0x4b4/0x8e8) [ 2.706461] [<c092b1b8>] (gpio_keys_probe) from [<c0817c00>] (platform_drv_probe+0x48/0x98) [ 2.714272] [<c0817c00>] (platform_drv_probe) from [<c0815738>] (really_probe+0x108/0x40c) [ 2.722599] [<c0815738>] (really_probe) from [<c0815bf4>] (driver_probe_device+0x78/0x1c4) [ 2.730934] [<c0815bf4>] (driver_probe_device) from [<c0815f9c>] (device_driver_attach+0x58/0x60) [ 2.739182] [<c0815f9c>] (device_driver_attach) from [<c0816058>] (__driver_attach+0xb4/0x154) [ 2.748121] [<c0816058>] (__driver_attach) from [<c0813908>] (bus_for_each_dev+0x74/0xb4) [ 2.756628] [<c0813908>] (bus_for_each_dev) from [<c0814aa0>] (bus_add_driver+0x1c0/0x200) [ 2.764875] [<c0814aa0>] (bus_add_driver) from [<c0816be4>] (driver_register+0x7c/0x114) [ 2.773035] [<c0816be4>] (driver_register) from [<c0302f7c>] (do_one_initcall+0x54/0x2a0) [ 2.781284] [<c0302f7c>] (do_one_initcall) from [<c0f01204>] (kernel_init_freeable+0x2d4/0x36c) [ 2.789357] [<c0f01204>] (kernel_init_freeable) from [<c0af5bb0>] (kernel_init+0x8/0x110) [ 2.797860] [<c0af5bb0>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c) [ 2.806181] Exception stack(0xde899fb0 to 0xde899ff8) [ 2.813653] 9fa0: 00000000 00000000 00000000 00000000 [ 2.818788] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.826943] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.835102] Code: 0592301c e12fff13 e5900018 e5903010 (e5933018) [ 2.841513] ---[ end trace e31675e4bfb4e93f ]--- The parent's irq_chip struct isn't populated yet and the error occurs here: void irq_chip_ack_parent(struct irq_data *data) { data = data->parent_data; data->chip->irq_ack(data); ^^^^ We haven't called irq_domain_alloc_irqs_parent() yet, which is fine. __irq_do_set_handler() has a special check for handle_bad_irq(): https://elixir.bootlin.com/linux/latest/source/kernel/irq/chip.c#L974 I'm not sure what the proper fix is here and not going to dig into this anymore this evening. > diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst > index 1ce7fcd0f989..3099c7fbefdb 100644 > --- a/Documentation/driver-api/gpio/driver.rst > +++ b/Documentation/driver-api/gpio/driver.rst I'm still on linux next-20190701. Does this patch series of yours require any other patches? I get a merge conflict against driver.rst. Everything else applies cleanly. I honestly haven't looked in detail about the conflicts. Brian
On Sun, Jul 7, 2019 at 3:46 AM Brian Masney <masneyb@onstation.org> wrote: > I got this working with spmi-gpio with two additional changes. See below > for details. Hopefully I'll have time tomorrow evening (GMT-4) to finish > cleaning up what I have so I can send out my series. Awesome! No hurry because it is v5.4 material at this point but I'm hoping to get to something you, Lina and Thierry can all use for early merge and smoke test. > > +static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { > > + .activate = gpiochip_irq_domain_activate, > > + .deactivate = gpiochip_irq_domain_deactivate, > > + .translate = gpiochip_hierarchy_irq_domain_translate, > > + .alloc = gpiochip_hierarchy_irq_domain_alloc, > > + .free = irq_domain_free_irqs_common, > > +}; > > spmi and ssbi gpio both need to subtract one from the hwirq in the > translate function. > > https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c#L956 > > I'm going to optionally allow overriding the translate() function > pointer as well. Hm was more thinking to let gpiolib call out to an optional translate function (on top of the template) but this is maybe cleaner. > > + /* > > + * 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, > ^^^^^^^^^^ > In order to get this working, I had to change handle_bad_irq to > handle_level_irq otherwise I get this attempted NULL pointer > dereference: Hmmmmmmmm that should not happen, we need to get to the bottom of this. > [ 2.624430] [<c0372af4>] (irq_chip_ack_parent) from [<c0373f6c>] (__irq_do_set_handler+0x1b4/0x1bc) > [ 2.632584] [<c0373f6c>] (__irq_do_set_handler) from [<c0373fc0>] (__irq_set_handler+0x4c/0x78) > [ 2.641441] [<c0373fc0>] (__irq_set_handler) from [<c0375d44>] (irq_domain_set_info+0x38/0x4c) > [ 2.650126] [<c0375d44>] (irq_domain_set_info) from [<c06cf28c>] (gpiochip_hierarchy_irq_domain_alloc+0x16c/0x22c) > [ 2.658808] [<c06cf28c>] (gpiochip_hierarchy_irq_domain_alloc) from [<c0376bac>] (__irq_domain_alloc_irqs+0x12c/0x320) I wonder why irq_chip_ack_parent() is called there. Like there is some pending IRQ or something. > The parent's irq_chip struct isn't populated yet and the error occurs > here: > > void irq_chip_ack_parent(struct irq_data *data) > { > data = data->parent_data; > data->chip->irq_ack(data); > ^^^^ > > We haven't called irq_domain_alloc_irqs_parent() yet, which is fine. > > __irq_do_set_handler() has a special check for handle_bad_irq(): > > https://elixir.bootlin.com/linux/latest/source/kernel/irq/chip.c#L974 > > I'm not sure what the proper fix is here and not going to dig into this > anymore this evening. I'm a bit puzzled too. :/ > > diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst > > index 1ce7fcd0f989..3099c7fbefdb 100644 > > --- a/Documentation/driver-api/gpio/driver.rst > > +++ b/Documentation/driver-api/gpio/driver.rst > > I'm still on linux next-20190701. Does this patch series of yours > require any other patches? I get a merge conflict against driver.rst. > Everything else applies cleanly. I honestly haven't looked in detail > about the conflicts. I have some pending documentation patch I think. Sorry about that. Yours, Linus Walleij
Hi Linus, On Mon, Jun 24, 2019 at 03:25:28PM +0200, Linus Walleij wrote: > +associated irqdomain and resource allocation callbacks. These are activated > +by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol > +IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be > +provided. A big portion of overhead code will be managed by gpiolib, > +under the assumption that your interrupts are 1-to-1-mapped to the > +GPIO line index: > + > + GPIO line offset Hardware IRQ > + 0 0 > + 1 1 > + 2 2 > + ... ... > + ngpio-1 ngpio-1 > + > +If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask > +and the flag need_valid_mask in gpio_irq_chip can be used to mask off some > +lines as invalid for associating with IRQs. I forgot to call out in my patch series that the GPIOs are numbered 1..ngpio on Qualcomm and the existing to_irq and translate callbacks in mainline take care of adding and subtracting one to / from the offset. I was under the (false?) assumption that GPIO numbering on all platforms start at one. Is that not the case? Brian
On Mon, Jun 24, 2019 at 10:25 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > Hierarchical IRQ domains can be used to stack different IRQ > controllers on top of each other. > > Bring hierarchical IRQ domains into the GPIOLIB core with the > following basic idea: > > Drivers that need their interrupts handled hierarchically > specify a callback to translate the child hardware IRQ and > IRQ type for each GPIO offset to a parent hardware IRQ and > parent hardware IRQ type. > > Users have to pass the callback, fwnode, and parent irqdomain > before calling gpiochip_irqchip_add(). > > We use the new method of just filling in the struct > gpio_irq_chip before adding the gpiochip for all hierarchical > irqchips of this type. > > The code path for device tree is pretty straight-forward, > while the code path for old boardfiles or anything else will > be more convoluted requireing upfront allocation of the > interrupts when adding the chip. > > One specific use-case where this can be useful is if a power > management controller has top-level controls for wakeup > interrupts. In such cases, the power management controller can > be a parent to other interrupt controllers and program > additional registers when an IRQ has its wake capability > enabled or disabled. > > The hierarchical irqchip helper code will only be available > when IRQ_DOMAIN_HIERARCHY is selected to GPIO chips using > this should select or depend on that symbol. When using > hierarchical IRQs, the parent interrupt controller must > also be hierarchical all the way up to the top interrupt > controller wireing directly into the CPU, so on systems > that do not have this we can get rid of all the extra > code for supporting hierarchical irqs. > > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Marc Zyngier <marc.zyngier@arm.com> > Cc: Lina Iyer <ilina@codeaurora.org> > Cc: Jon Hunter <jonathanh@nvidia.com> > Cc: Sowjanya Komatineni <skomatineni@nvidia.com> > Cc: Bitan Biswas <bbiswas@nvidia.com> > Cc: linux-tegra@vger.kernel.org > Cc: David Daney <david.daney@cavium.com> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Brian Masney <masneyb@onstation.org> > Signed-off-by: Thierry Reding <treding@nvidia.com> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > ChangeLog RFC->v1: > - Tested on real hardware > - Incorporate Thierry's idea to have a translation callback. > He was right about this approach, I was wrong in insisting > on IRQ maps. > --- > Documentation/driver-api/gpio/driver.rst | 120 ++++++++-- > drivers/gpio/gpiolib.c | 285 ++++++++++++++++++++++- > include/linux/gpio/driver.h | 46 ++++ > 3 files changed, 426 insertions(+), 25 deletions(-) > > diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst > index 1ce7fcd0f989..3099c7fbefdb 100644 > --- a/Documentation/driver-api/gpio/driver.rst > +++ b/Documentation/driver-api/gpio/driver.rst > @@ -259,7 +259,7 @@ most often cascaded off a parent interrupt controller, and in some special > cases the GPIO logic is melded with a SoC's primary interrupt controller. > > The IRQ portions of the GPIO block are implemented using an irq_chip, using > -the header <linux/irq.h>. So basically such a driver is utilizing two sub- > +the header <linux/irq.h>. So this combined driver is utilizing two sub- > systems simultaneously: gpio and irq. > > It is legal for any IRQ consumer to request an IRQ from any irqchip even if it > @@ -391,14 +391,108 @@ Infrastructure helpers for GPIO irqchips > ---------------------------------------- > > To help out in handling the set-up and management of GPIO irqchips and the > -associated irqdomain and resource allocation callbacks, the gpiolib has > -some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig > -symbol: > - > -- gpiochip_irqchip_add(): adds a chained cascaded irqchip to a gpiochip. It > - will pass the struct gpio_chip* for the chip to all IRQ callbacks, so the > - callbacks need to embed the gpio_chip in its state container and obtain a > - pointer to the container using container_of(). > +associated irqdomain and resource allocation callbacks. These are activated > +by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol > +IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be > +provided. A big portion of overhead code will be managed by gpiolib, > +under the assumption that your interrupts are 1-to-1-mapped to the > +GPIO line index: > + > + GPIO line offset Hardware IRQ > + 0 0 > + 1 1 > + 2 2 > + ... ... > + ngpio-1 ngpio-1 > + > +If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask > +and the flag need_valid_mask in gpio_irq_chip can be used to mask off some > +lines as invalid for associating with IRQs. > + > +The preferred way to set up the helpers is to fill in the > +struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. > +If you do this, the additional irq_chip will be set up by gpiolib at the > +same time as setting up the rest of the GPIO functionality. The following > +is a typical example of a cascaded interrupt handler using gpio_irq_chip: > + > + /* Typical state container with dynamic irqchip */ > + struct my_gpio { > + struct gpio_chip gc; > + struct irq_chip irq; > + }; > + > + int irq; /* from platform etc */ > + struct my_gpio *g; > + struct gpio_irq_chip *girq > + > + /* Set up the irqchip dynamically */ > + g->irq.name = "my_gpio_irq"; > + g->irq.irq_ack = my_gpio_ack_irq; > + g->irq.irq_mask = my_gpio_mask_irq; > + g->irq.irq_unmask = my_gpio_unmask_irq; > + g->irq.irq_set_type = my_gpio_set_irq_type; > + > + /* Get a pointer to the gpio_irq_chip */ > + girq = &g->gc.irq; > + girq->chip = &g->irq; > + girq->parent_handler = ftgpio_gpio_irq_handler; > + girq->num_parents = 1; > + girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), > + GFP_KERNEL); > + if (!girq->parents) > + return -ENOMEM; > + girq->default_type = IRQ_TYPE_NONE; > + girq->handler = handle_bad_irq; > + girq->parents[0] = irq; > + > + return devm_gpiochip_add_data(dev, &g->gc, g); > + > +The helper support using hierarchical interrupt controllers as well. > +In this case the typical set-up will look like this: > + > + /* Typical state container with dynamic irqchip */ > + struct my_gpio { > + struct gpio_chip gc; > + struct irq_chip irq; > + struct fwnode_handle *fwnode; > + }; > + > + int irq; /* from platform etc */ > + struct my_gpio *g; > + struct gpio_irq_chip *girq > + > + /* Set up the irqchip dynamically */ > + g->irq.name = "my_gpio_irq"; > + g->irq.irq_ack = my_gpio_ack_irq; > + g->irq.irq_mask = my_gpio_mask_irq; > + g->irq.irq_unmask = my_gpio_unmask_irq; > + g->irq.irq_set_type = my_gpio_set_irq_type; > + > + /* Get a pointer to the gpio_irq_chip */ > + girq = &g->gc.irq; > + girq->chip = &g->irq; > + girq->default_type = IRQ_TYPE_NONE; > + girq->handler = handle_bad_irq; > + girq->fwnode = g->fwnode; > + girq->parent_domain = parent; > + girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; > + > + return devm_gpiochip_add_data(dev, &g->gc, g); > + > +As you can see pretty similar, but you do not supply a parent handler for > +the IRQ, instead a parent irqdomain, an fwnode for the hardware and > +a funcion .child_to_parent_hwirq() that has the purpose of looking up > +the parent hardware irq from a child (i.e. this gpio chip) hardware irq. > +As always it is good to look at examples in the kernel tree for advice > +on how to find the required pieces. > + > +The old way of adding irqchips to gpiochips after registration is also still > +available but we try to move away from this: > + > +- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a > + gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ > + callbacks, so the callbacks need to embed the gpio_chip in its state > + container and obtain a pointer to the container using container_of(). > (See Documentation/driver-model/design-patterns.txt) > > - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, > @@ -406,10 +500,10 @@ symbol: > cascaded irq has to be handled by a threaded interrupt handler. > Apart from that it works exactly like the chained irqchip. > > -- gpiochip_set_chained_irqchip(): sets up a chained cascaded irq handler for a > - gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler > - data. Notice that we pass is as the handler data, since the irqchip data is > - likely used by the parent irqchip. > +- DEPRECATED: gpiochip_set_chained_irqchip(): sets up a chained cascaded irq > + handler for a gpio_chip from a parent IRQ and passes the struct gpio_chip* > + as handler data. Notice that we pass is as the handler data, since the > + irqchip data is likely used by the parent irqchip. > > - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a > gpio_chip from a parent IRQ. As the parent IRQ has usually been > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index e013d417a936..af72ffa02963 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1718,6 +1718,240 @@ void gpiochip_set_nested_irqchip(struct gpio_chip *gpiochip, > } > EXPORT_SYMBOL_GPL(gpiochip_set_nested_irqchip); > > +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY > + > +/** > + * gpiochip_set_hierarchical_irqchip() - connects a hierarchical irqchip > + * to a gpiochip > + * @gc: the gpiochip to set the irqchip hierarchical handler to > + * @irqchip: the irqchip to handle this level of the hierarchy, the interrupt > + * will then percolate up to the parent > + */ > +static void gpiochip_set_hierarchical_irqchip(struct gpio_chip *gc, > + struct irq_chip *irqchip) > +{ > + /* DT will deal with mapping each IRQ as we go along */ > + if (is_of_node(gc->irq.fwnode)) > + return; > + > + /* > + * This is for legacy and boardfile "irqchip" fwnodes: allocate > + * irqs upfront instead of dynamically since we don't have the > + * dynamic type of allocation that hardware description languages > + * provide. Once all GPIO drivers using board files are gone from > + * the kernel we can delete this code, but for a transitional period > + * it is necessary to keep this around. > + */ > + if (is_fwnode_irqchip(gc->irq.fwnode)) { > + int i; > + int ret; > + > + for (i = 0; i < gc->ngpio; i++) { > + struct irq_fwspec fwspec; > + unsigned int parent_hwirq; > + unsigned int parent_type; > + struct gpio_irq_chip *girq = &gc->irq; > + > + /* > + * We call the child to parent translation function > + * only to check if the child IRQ is valid or not. > + * Just pick the rising edge type here as that is what > + * we likely need to support. > + */ > + ret = girq->child_to_parent_hwirq(gc, i, > + IRQ_TYPE_EDGE_RISING, > + &parent_hwirq, > + &parent_type); > + if (ret) { > + chip_err(gc, "skip set-up on hwirq %d\n", > + i); > + continue; > + } > + > + fwspec.fwnode = gc->irq.fwnode; > + /* This is the hwirq for the GPIO line side of things */ > + fwspec.param[0] = i; > + /* Just pick something */ > + fwspec.param[1] = IRQ_TYPE_EDGE_RISING; > + fwspec.param_count = 2; > + ret = __irq_domain_alloc_irqs(gc->irq.domain, > + /* just pick something */ > + -1, > + 1, > + NUMA_NO_NODE, > + &fwspec, > + false, > + NULL); > + if (ret < 0) { > + chip_err(gc, > + "can not allocate irq for GPIO line %d parent hwirq %d in hierarchy domain: %d\n", > + i, parent_hwirq, > + ret); > + } > + } > + } > + > + chip_err(gc, "%s unknown fwnode type proceed anyway\n", __func__); > + > + return; > +} > + > +static int gpiochip_hierarchy_irq_domain_translate(struct irq_domain *d, > + struct irq_fwspec *fwspec, > + unsigned long *hwirq, > + unsigned int *type) > +{ > + /* We support standard DT translation */ > + if (is_of_node(fwspec->fwnode) && fwspec->param_count == 2) { > + return irq_domain_translate_twocell(d, fwspec, hwirq, type); > + } > + > + /* This is for board files and others not using DT */ > + if (is_fwnode_irqchip(fwspec->fwnode)) { > + int ret; > + > + ret = irq_domain_translate_twocell(d, fwspec, hwirq, type); > + if (ret) > + return ret; > + WARN_ON(*type == IRQ_TYPE_NONE); > + return 0; > + } > + return -EINVAL; > +} > + > +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; We always expect nr_irqs is 1. As gpio-uniphier.c, you can error out with WARN_ON if nr_irqs != 1 > + chip_info(gc, "called %s\n", __func__); Is this a debug message? > + > + 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); Ditto. > + > + for (i = 0; i < nr_irqs; i++) { This for-loop is unneeded because nr_irqs is 1. > + 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); > + if (ret) > + chip_err(gc, > + "failed to allocate parent hwirq %d for hwirq %lu\n", > + parent_hwirq, hwirq); > + } > + > + return 0; > +} > + > +static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { > + .activate = gpiochip_irq_domain_activate, > + .deactivate = gpiochip_irq_domain_deactivate, > + .translate = gpiochip_hierarchy_irq_domain_translate, > + .alloc = gpiochip_hierarchy_irq_domain_alloc, > + .free = irq_domain_free_irqs_common, > +}; > + > +static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) > +{ > + if (!gc->irq.parent_domain) { > + chip_err(gc, "missing parent irqdomain\n"); > + return -EINVAL; > + } Is this check needed? gpiochip_hierarchy_is_hierarchical() has already checked this. > + if (!gc->irq.parent_domain || Redundant check second time. > + !gc->irq.child_to_parent_hwirq || > + !gc->irq.fwnode) { > + chip_err(gc, "missing irqdomain vital data\n"); > + return -EINVAL; > + } > + > + gc->irq.domain = irq_domain_create_hierarchy( > + gc->irq.parent_domain, > + IRQ_DOMAIN_FLAG_HIERARCHY, You do not need to pass IRQ_DOMAIN_FLAG_HIERARCHY. This is set by irq_domain_check_hierarchy(). > + gc->ngpio, > + gc->irq.fwnode, > + &gpiochip_hierarchy_domain_ops, > + gc); > + > + if (!gc->irq.domain) { > + chip_err(gc, "failed to add hierarchical domain\n"); > + return -EINVAL; This should be ... return -ENOMEM; because __irq_domain_add() fails when memory allocation fails. Obviously, this also means you should drop chip_err() above since we do not print error message for ENOMEM. > + } > + > + gpiochip_set_hierarchical_irqchip(gc, gc->irq.chip); > + > + chip_info(gc, "set up hierarchical irqdomain\n"); I see so many chip_info(). I think they should be chip_dbg() or removed entirely. > + return 0; > +} > + > +static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) > +{ > + return !!gc->irq.parent_domain; > +} > + > +#else > + > +static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) > +{ > + return -EINVAL; > +} > + > +static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) > +{ > + return false; > +} > + > +#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */ > + > /** > * gpiochip_irq_map() - maps an IRQ into a GPIO irqchip > * @d: the irqdomain used by this irqchip > @@ -1786,6 +2020,11 @@ static const struct irq_domain_ops gpiochip_domain_ops = { > .xlate = irq_domain_xlate_twocell, > }; > > +/* > + * TODO: move these activate/deactivate in under the hierarchicial > + * irqchip implementation as static once SPMI and SSBI (all external > + * users) are phased over. > + */ > /** > * gpiochip_irq_domain_activate() - Lock a GPIO to be used as an IRQ > * @domain: The IRQ domain used by this IRQ chip > @@ -1825,10 +2064,23 @@ EXPORT_SYMBOL_GPL(gpiochip_irq_domain_deactivate); > > static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) > { > + struct irq_domain *domain = chip->irq.domain; > + > if (!gpiochip_irqchip_irq_valid(chip, offset)) > return -ENXIO; > > - return irq_create_mapping(chip->irq.domain, offset); > + if (irq_domain_is_hierarchy(domain)) { > + struct irq_fwspec spec; > + > + spec.fwnode = domain->fwnode; > + spec.param_count = 2; > + spec.param[0] = offset; > + spec.param[1] = IRQ_TYPE_NONE; > + > + return irq_create_fwspec_mapping(&spec); > + } > + > + return irq_create_mapping(domain, offset); > } > > static int gpiochip_irq_reqres(struct irq_data *d) > @@ -1905,7 +2157,7 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, > struct lock_class_key *request_key) > { > struct irq_chip *irqchip = gpiochip->irq.chip; > - const struct irq_domain_ops *ops; > + const struct irq_domain_ops *ops = NULL; > struct device_node *np; > unsigned int type; > unsigned int i; > @@ -1941,16 +2193,25 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, > gpiochip->irq.lock_key = lock_key; > gpiochip->irq.request_key = request_key; > > - if (gpiochip->irq.domain_ops) > - ops = gpiochip->irq.domain_ops; > - else > - ops = &gpiochip_domain_ops; > - > - gpiochip->irq.domain = irq_domain_add_simple(np, gpiochip->ngpio, > - gpiochip->irq.first, > - ops, gpiochip); > - if (!gpiochip->irq.domain) > - return -EINVAL; > + /* If a parent irqdomain is provided, let's build a hierarchy */ > + if (gpiochip_hierarchy_is_hierarchical(gpiochip)) { > + int ret = gpiochip_hierarchy_add_domain(gpiochip); > + if (ret) > + return ret; > + } else { > + /* Some drivers provide custom irqdomain ops */ > + if (gpiochip->irq.domain_ops) > + ops = gpiochip->irq.domain_ops; > + > + if (!ops) > + ops = &gpiochip_domain_ops; > + gpiochip->irq.domain = irq_domain_add_simple(np, > + gpiochip->ngpio, > + gpiochip->irq.first, > + ops, gpiochip); > + if (!gpiochip->irq.domain) > + return -EINVAL; > + } > > if (gpiochip->irq.parent_handler) { > void *data = gpiochip->irq.parent_handler_data ?: gpiochip; > diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h > index a1d273c96016..e32d02cb2d08 100644 > --- a/include/linux/gpio/driver.h > +++ b/include/linux/gpio/driver.h > @@ -22,6 +22,9 @@ enum gpiod_flags; > #ifdef CONFIG_GPIOLIB > > #ifdef CONFIG_GPIOLIB_IRQCHIP > + > +struct gpio_chip; > + > /** > * struct gpio_irq_chip - GPIO interrupt controller > */ > @@ -48,6 +51,49 @@ struct gpio_irq_chip { > */ > const struct irq_domain_ops *domain_ops; > > +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY > + /** > + * @fwnode: > + * > + * Firmware node corresponding to this gpiochip/irqchip, necessary > + * for hierarchical irqdomain support. > + */ > + struct fwnode_handle *fwnode; > + > + /** > + * @parent_domain: > + * > + * If non-NULL, will be set as the parent of this GPIO interrupt > + * controller's IRQ domain to establish a hierarchical interrupt > + * domain. The presence of this will activate the hierarchical > + * interrupt support. > + */ > + struct irq_domain *parent_domain; > + > + /** > + * @child_to_parent_hwirq: > + * > + * This callback translates a child hardware IRQ offset to a parent > + * hardware IRQ offset on a hierarchical interrupt chip. The child > + * hardware IRQs correspond to the GPIO index 0..ngpio-1 (see the > + * ngpio field of struct gpio_chip) and the corresponding parent > + * hardware IRQ and type (such as IRQ_TYPE_*) shall be returned by > + * the driver. The driver can calculate this from an offset or using > + * a lookup table or whatever method is best for this chip. Return > + * 0 on successful translation in the driver. > + * > + * If some ranges of hardware IRQs do not have a corresponding parent > + * HWIRQ, return -EINVAL, but also make sure to fill in @valid_mask and > + * @need_valid_mask to make these GPIO lines unavailable for > + * translation. > + */ > + int (*child_to_parent_hwirq)(struct gpio_chip *chip, > + unsigned int child_hwirq, > + unsigned int child_type, > + unsigned int *parent_hwirq, > + unsigned int *parent_type); > +#endif > + > /** > * @handler: > * > -- > 2.21.0 > -- Best Regards Masahiro Yamada
Hi Masahiro, On Thu, Jul 18, 2019 at 1:12 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > On Mon, Jun 24, 2019 at 10:25 PM Linus Walleij <linus.walleij@linaro.org> 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; > > We always expect nr_irqs is 1. > > As gpio-uniphier.c, you can error out with WARN_ON > if nr_irqs != 1 Hm, yes I am pretty sure it is always 1. But I'd like to defer changing this until/if Marc changes the signature of the function to not pass nr_irqs anymore. I try to design for the current prototype because I don't know how e.g. ACPI works with respect to this. > I see so many chip_info(). > I think they should be chip_dbg() or removed entirely. I am keeping that right now as we're testing on several different systems, so some extra debug prints should be OK in a transitional period. We might change it into dbg with a separate patch before the merge window. The rest of your comments are addressed! Yours, Linus Walleij
On 07/08/2019 15:43, Linus Walleij wrote: > Hi Masahiro, > > On Thu, Jul 18, 2019 at 1:12 PM Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: >> On Mon, Jun 24, 2019 at 10:25 PM Linus Walleij <linus.walleij@linaro.org> 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; >> >> We always expect nr_irqs is 1. >> >> As gpio-uniphier.c, you can error out with WARN_ON >> if nr_irqs != 1 > > Hm, yes I am pretty sure it is always 1. > > But I'd like to defer changing this until/if Marc changes > the signature of the function to not pass nr_irqs anymore. > I try to design for the current prototype because I don't > know how e.g. ACPI works with respect to this. nr_irqs is only here for one single case: PCI Multi-MSI, where we have to allocate a bunch of contiguous hwirqs. In all other cases, nr_irqs is always 1. So yes, you can safely assume nr_irqs == 1, and WARN_ON otherwise. Thanks, M. -- Jazz is not dead. It just smells funny...
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 1ce7fcd0f989..3099c7fbefdb 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -259,7 +259,7 @@ most often cascaded off a parent interrupt controller, and in some special cases the GPIO logic is melded with a SoC's primary interrupt controller. The IRQ portions of the GPIO block are implemented using an irq_chip, using -the header <linux/irq.h>. So basically such a driver is utilizing two sub- +the header <linux/irq.h>. So this combined driver is utilizing two sub- systems simultaneously: gpio and irq. It is legal for any IRQ consumer to request an IRQ from any irqchip even if it @@ -391,14 +391,108 @@ Infrastructure helpers for GPIO irqchips ---------------------------------------- To help out in handling the set-up and management of GPIO irqchips and the -associated irqdomain and resource allocation callbacks, the gpiolib has -some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig -symbol: - -- gpiochip_irqchip_add(): adds a chained cascaded irqchip to a gpiochip. It - will pass the struct gpio_chip* for the chip to all IRQ callbacks, so the - callbacks need to embed the gpio_chip in its state container and obtain a - pointer to the container using container_of(). +associated irqdomain and resource allocation callbacks. These are activated +by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol +IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be +provided. A big portion of overhead code will be managed by gpiolib, +under the assumption that your interrupts are 1-to-1-mapped to the +GPIO line index: + + GPIO line offset Hardware IRQ + 0 0 + 1 1 + 2 2 + ... ... + ngpio-1 ngpio-1 + +If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask +and the flag need_valid_mask in gpio_irq_chip can be used to mask off some +lines as invalid for associating with IRQs. + +The preferred way to set up the helpers is to fill in the +struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. +If you do this, the additional irq_chip will be set up by gpiolib at the +same time as setting up the rest of the GPIO functionality. The following +is a typical example of a cascaded interrupt handler using gpio_irq_chip: + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + girq->parent_handler = ftgpio_gpio_irq_handler; + girq->num_parents = 1; + girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), + GFP_KERNEL); + if (!girq->parents) + return -ENOMEM; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + girq->parents[0] = irq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +The helper support using hierarchical interrupt controllers as well. +In this case the typical set-up will look like this: + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + struct fwnode_handle *fwnode; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + girq->fwnode = g->fwnode; + girq->parent_domain = parent; + girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +As you can see pretty similar, but you do not supply a parent handler for +the IRQ, instead a parent irqdomain, an fwnode for the hardware and +a funcion .child_to_parent_hwirq() that has the purpose of looking up +the parent hardware irq from a child (i.e. this gpio chip) hardware irq. +As always it is good to look at examples in the kernel tree for advice +on how to find the required pieces. + +The old way of adding irqchips to gpiochips after registration is also still +available but we try to move away from this: + +- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a + gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ + callbacks, so the callbacks need to embed the gpio_chip in its state + container and obtain a pointer to the container using container_of(). (See Documentation/driver-model/design-patterns.txt) - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, @@ -406,10 +500,10 @@ symbol: cascaded irq has to be handled by a threaded interrupt handler. Apart from that it works exactly like the chained irqchip. -- gpiochip_set_chained_irqchip(): sets up a chained cascaded irq handler for a - gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler - data. Notice that we pass is as the handler data, since the irqchip data is - likely used by the parent irqchip. +- DEPRECATED: gpiochip_set_chained_irqchip(): sets up a chained cascaded irq + handler for a gpio_chip from a parent IRQ and passes the struct gpio_chip* + as handler data. Notice that we pass is as the handler data, since the + irqchip data is likely used by the parent irqchip. - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a gpio_chip from a parent IRQ. As the parent IRQ has usually been diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index e013d417a936..af72ffa02963 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1718,6 +1718,240 @@ void gpiochip_set_nested_irqchip(struct gpio_chip *gpiochip, } EXPORT_SYMBOL_GPL(gpiochip_set_nested_irqchip); +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY + +/** + * gpiochip_set_hierarchical_irqchip() - connects a hierarchical irqchip + * to a gpiochip + * @gc: the gpiochip to set the irqchip hierarchical handler to + * @irqchip: the irqchip to handle this level of the hierarchy, the interrupt + * will then percolate up to the parent + */ +static void gpiochip_set_hierarchical_irqchip(struct gpio_chip *gc, + struct irq_chip *irqchip) +{ + /* DT will deal with mapping each IRQ as we go along */ + if (is_of_node(gc->irq.fwnode)) + return; + + /* + * This is for legacy and boardfile "irqchip" fwnodes: allocate + * irqs upfront instead of dynamically since we don't have the + * dynamic type of allocation that hardware description languages + * provide. Once all GPIO drivers using board files are gone from + * the kernel we can delete this code, but for a transitional period + * it is necessary to keep this around. + */ + if (is_fwnode_irqchip(gc->irq.fwnode)) { + int i; + int ret; + + for (i = 0; i < gc->ngpio; i++) { + struct irq_fwspec fwspec; + unsigned int parent_hwirq; + unsigned int parent_type; + struct gpio_irq_chip *girq = &gc->irq; + + /* + * We call the child to parent translation function + * only to check if the child IRQ is valid or not. + * Just pick the rising edge type here as that is what + * we likely need to support. + */ + ret = girq->child_to_parent_hwirq(gc, i, + IRQ_TYPE_EDGE_RISING, + &parent_hwirq, + &parent_type); + if (ret) { + chip_err(gc, "skip set-up on hwirq %d\n", + i); + continue; + } + + fwspec.fwnode = gc->irq.fwnode; + /* This is the hwirq for the GPIO line side of things */ + fwspec.param[0] = i; + /* Just pick something */ + fwspec.param[1] = IRQ_TYPE_EDGE_RISING; + fwspec.param_count = 2; + ret = __irq_domain_alloc_irqs(gc->irq.domain, + /* just pick something */ + -1, + 1, + NUMA_NO_NODE, + &fwspec, + false, + NULL); + if (ret < 0) { + chip_err(gc, + "can not allocate irq for GPIO line %d parent hwirq %d in hierarchy domain: %d\n", + i, parent_hwirq, + ret); + } + } + } + + chip_err(gc, "%s unknown fwnode type proceed anyway\n", __func__); + + return; +} + +static int gpiochip_hierarchy_irq_domain_translate(struct irq_domain *d, + struct irq_fwspec *fwspec, + unsigned long *hwirq, + unsigned int *type) +{ + /* We support standard DT translation */ + if (is_of_node(fwspec->fwnode) && fwspec->param_count == 2) { + return irq_domain_translate_twocell(d, fwspec, hwirq, type); + } + + /* This is for board files and others not using DT */ + if (is_fwnode_irqchip(fwspec->fwnode)) { + int ret; + + ret = irq_domain_translate_twocell(d, fwspec, hwirq, type); + if (ret) + return ret; + WARN_ON(*type == IRQ_TYPE_NONE); + return 0; + } + return -EINVAL; +} + +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); + if (ret) + chip_err(gc, + "failed to allocate parent hwirq %d for hwirq %lu\n", + parent_hwirq, hwirq); + } + + return 0; +} + +static const struct irq_domain_ops gpiochip_hierarchy_domain_ops = { + .activate = gpiochip_irq_domain_activate, + .deactivate = gpiochip_irq_domain_deactivate, + .translate = gpiochip_hierarchy_irq_domain_translate, + .alloc = gpiochip_hierarchy_irq_domain_alloc, + .free = irq_domain_free_irqs_common, +}; + +static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) +{ + if (!gc->irq.parent_domain) { + chip_err(gc, "missing parent irqdomain\n"); + return -EINVAL; + } + + if (!gc->irq.parent_domain || + !gc->irq.child_to_parent_hwirq || + !gc->irq.fwnode) { + chip_err(gc, "missing irqdomain vital data\n"); + return -EINVAL; + } + + gc->irq.domain = irq_domain_create_hierarchy( + gc->irq.parent_domain, + IRQ_DOMAIN_FLAG_HIERARCHY, + gc->ngpio, + gc->irq.fwnode, + &gpiochip_hierarchy_domain_ops, + gc); + + if (!gc->irq.domain) { + chip_err(gc, "failed to add hierarchical domain\n"); + return -EINVAL; + } + + gpiochip_set_hierarchical_irqchip(gc, gc->irq.chip); + + chip_info(gc, "set up hierarchical irqdomain\n"); + + return 0; +} + +static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) +{ + return !!gc->irq.parent_domain; +} + +#else + +static int gpiochip_hierarchy_add_domain(struct gpio_chip *gc) +{ + return -EINVAL; +} + +static bool gpiochip_hierarchy_is_hierarchical(struct gpio_chip *gc) +{ + return false; +} + +#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */ + /** * gpiochip_irq_map() - maps an IRQ into a GPIO irqchip * @d: the irqdomain used by this irqchip @@ -1786,6 +2020,11 @@ static const struct irq_domain_ops gpiochip_domain_ops = { .xlate = irq_domain_xlate_twocell, }; +/* + * TODO: move these activate/deactivate in under the hierarchicial + * irqchip implementation as static once SPMI and SSBI (all external + * users) are phased over. + */ /** * gpiochip_irq_domain_activate() - Lock a GPIO to be used as an IRQ * @domain: The IRQ domain used by this IRQ chip @@ -1825,10 +2064,23 @@ EXPORT_SYMBOL_GPL(gpiochip_irq_domain_deactivate); static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset) { + struct irq_domain *domain = chip->irq.domain; + if (!gpiochip_irqchip_irq_valid(chip, offset)) return -ENXIO; - return irq_create_mapping(chip->irq.domain, offset); + if (irq_domain_is_hierarchy(domain)) { + struct irq_fwspec spec; + + spec.fwnode = domain->fwnode; + spec.param_count = 2; + spec.param[0] = offset; + spec.param[1] = IRQ_TYPE_NONE; + + return irq_create_fwspec_mapping(&spec); + } + + return irq_create_mapping(domain, offset); } static int gpiochip_irq_reqres(struct irq_data *d) @@ -1905,7 +2157,7 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, struct lock_class_key *request_key) { struct irq_chip *irqchip = gpiochip->irq.chip; - const struct irq_domain_ops *ops; + const struct irq_domain_ops *ops = NULL; struct device_node *np; unsigned int type; unsigned int i; @@ -1941,16 +2193,25 @@ static int gpiochip_add_irqchip(struct gpio_chip *gpiochip, gpiochip->irq.lock_key = lock_key; gpiochip->irq.request_key = request_key; - if (gpiochip->irq.domain_ops) - ops = gpiochip->irq.domain_ops; - else - ops = &gpiochip_domain_ops; - - gpiochip->irq.domain = irq_domain_add_simple(np, gpiochip->ngpio, - gpiochip->irq.first, - ops, gpiochip); - if (!gpiochip->irq.domain) - return -EINVAL; + /* If a parent irqdomain is provided, let's build a hierarchy */ + if (gpiochip_hierarchy_is_hierarchical(gpiochip)) { + int ret = gpiochip_hierarchy_add_domain(gpiochip); + if (ret) + return ret; + } else { + /* Some drivers provide custom irqdomain ops */ + if (gpiochip->irq.domain_ops) + ops = gpiochip->irq.domain_ops; + + if (!ops) + ops = &gpiochip_domain_ops; + gpiochip->irq.domain = irq_domain_add_simple(np, + gpiochip->ngpio, + gpiochip->irq.first, + ops, gpiochip); + if (!gpiochip->irq.domain) + return -EINVAL; + } if (gpiochip->irq.parent_handler) { void *data = gpiochip->irq.parent_handler_data ?: gpiochip; diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h index a1d273c96016..e32d02cb2d08 100644 --- a/include/linux/gpio/driver.h +++ b/include/linux/gpio/driver.h @@ -22,6 +22,9 @@ enum gpiod_flags; #ifdef CONFIG_GPIOLIB #ifdef CONFIG_GPIOLIB_IRQCHIP + +struct gpio_chip; + /** * struct gpio_irq_chip - GPIO interrupt controller */ @@ -48,6 +51,49 @@ struct gpio_irq_chip { */ const struct irq_domain_ops *domain_ops; +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY + /** + * @fwnode: + * + * Firmware node corresponding to this gpiochip/irqchip, necessary + * for hierarchical irqdomain support. + */ + struct fwnode_handle *fwnode; + + /** + * @parent_domain: + * + * If non-NULL, will be set as the parent of this GPIO interrupt + * controller's IRQ domain to establish a hierarchical interrupt + * domain. The presence of this will activate the hierarchical + * interrupt support. + */ + struct irq_domain *parent_domain; + + /** + * @child_to_parent_hwirq: + * + * This callback translates a child hardware IRQ offset to a parent + * hardware IRQ offset on a hierarchical interrupt chip. The child + * hardware IRQs correspond to the GPIO index 0..ngpio-1 (see the + * ngpio field of struct gpio_chip) and the corresponding parent + * hardware IRQ and type (such as IRQ_TYPE_*) shall be returned by + * the driver. The driver can calculate this from an offset or using + * a lookup table or whatever method is best for this chip. Return + * 0 on successful translation in the driver. + * + * If some ranges of hardware IRQs do not have a corresponding parent + * HWIRQ, return -EINVAL, but also make sure to fill in @valid_mask and + * @need_valid_mask to make these GPIO lines unavailable for + * translation. + */ + int (*child_to_parent_hwirq)(struct gpio_chip *chip, + unsigned int child_hwirq, + unsigned int child_type, + unsigned int *parent_hwirq, + unsigned int *parent_type); +#endif + /** * @handler: *