Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Tue, Jul 31, 2012 at 05:18:36PM -0600, Stephen Warren wrote: > I don't think it's appropriate to put this support into the IRQ core. > The main issue is that all the handlers for any shared wired-or > interrupt line have to be registered before the IRQ is enabled, to avoid > some initially active interrupt continually firing before the IRQ is > enabled. Co-ordinating this when the wired-or line is on a board outside > a device driver rather than internal to a chip and one device driver is > a bit more than the IRQ core should probably be doing, hence I imagine > why it doesn't support it. No, that's not the issue at all - none of the above is at all different to any other shared interrupt and obviously we support shared IRQs quite happily (we wouldn't run on a good chunk of PCs if we didn't). Shared interrupts do require the hardware design not be insane but generally hardware engineers do manage to get that right. We don't support this for threaded IRQs due to thorny synchronisation issues in fast paths. > Co-ordinating this setup where all the sources of the wired-or are in > one chip seems to belong to the chip driver, which is where my patch did > this. Well, no. It did this by having a piece of framework code add a round robin irq_chip (essentially a shared threaded IRQ) layered on top of the existing regmap-irq code which had nothing to do with the rest of that code. There's nothing at all about that framework code which is at all specific to regmap-irq, it just calls a series of sub IRQs every time the primary IRQ goes off. This isn't the chip driver that's doing things, it's the regmap-irq code. With the current round robin implementation there's no reason for regmap to implement it, other things can quite happily do the same thing. Having a regmap helper which used a generic facility would be reasonable but the actual demux is a generic thing. [Suggestion to not bounce back into the IRQ core] > but it seems a little hokey to short-circuit the IRQ core; it would > prevent execution of any statistics gathering or stuck interrupt > handling that handle_nested_irq() might do for example. This seems like a better approach if doing things entirely in regmap. I can't see any impact on any of the IRQ core features here, we're always going to call each of the sub IRQs exactly once for each call to the IRQ handler and the stuck IRQ code is still going to identify the same set of real IRQs as stuck. > Now, if we made each child regmap_irq not be its own IRQ domain or > irq_chip, but simply had one top-level domain/chip that aggregated them, > that argument would be moot. However, that top-level domain/chip would > become rather complex and just end up doing a bunch of demultiplexing > code that's not needed if we do it like in my patch... That demultiplexing seems excessively complex, yes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Tue, Jul 31, 2012 at 05:18:36PM -0600, Stephen Warren wrote: I don't think it's appropriate to put this support into the IRQ core. The main issue is that all the handlers for any shared wired-or interrupt line have to be registered before the IRQ is enabled, to avoid some initially active interrupt continually firing before the IRQ is enabled. Co-ordinating this when the wired-or line is on a board outside a device driver rather than internal to a chip and one device driver is a bit more than the IRQ core should probably be doing, hence I imagine why it doesn't support it. No, that's not the issue at all - none of the above is at all different to any other shared interrupt and obviously we support shared IRQs quite happily (we wouldn't run on a good chunk of PCs if we didn't). Shared interrupts do require the hardware design not be insane but generally hardware engineers do manage to get that right. We don't support this for threaded IRQs due to thorny synchronisation issues in fast paths. Co-ordinating this setup where all the sources of the wired-or are in one chip seems to belong to the chip driver, which is where my patch did this. Well, no. It did this by having a piece of framework code add a round robin irq_chip (essentially a shared threaded IRQ) layered on top of the existing regmap-irq code which had nothing to do with the rest of that code. There's nothing at all about that framework code which is at all specific to regmap-irq, it just calls a series of sub IRQs every time the primary IRQ goes off. This isn't the chip driver that's doing things, it's the regmap-irq code. With the current round robin implementation there's no reason for regmap to implement it, other things can quite happily do the same thing. Having a regmap helper which used a generic facility would be reasonable but the actual demux is a generic thing. [Suggestion to not bounce back into the IRQ core] but it seems a little hokey to short-circuit the IRQ core; it would prevent execution of any statistics gathering or stuck interrupt handling that handle_nested_irq() might do for example. This seems like a better approach if doing things entirely in regmap. I can't see any impact on any of the IRQ core features here, we're always going to call each of the sub IRQs exactly once for each call to the IRQ handler and the stuck IRQ code is still going to identify the same set of real IRQs as stuck. Now, if we made each child regmap_irq not be its own IRQ domain or irq_chip, but simply had one top-level domain/chip that aggregated them, that argument would be moot. However, that top-level domain/chip would become rather complex and just end up doing a bunch of demultiplexing code that's not needed if we do it like in my patch... That demultiplexing seems excessively complex, yes. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On 07/30/2012 11:25 AM, Mark Brown wrote: > On Mon, Jul 30, 2012 at 11:00:04AM -0600, Stephen Warren wrote: >> On 07/29/2012 02:36 PM, Mark Brown wrote: >>> On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote: > >> I had implemented this in regmap since you'd specifically mentioned >> doing that. If I convert the code not to use separate IRQ domains for > > I think what I'd said was that we should factor it out rather than that > it should be specifically done in regmap. > >> this, would that be acceptable? > > Probably. The more I think about this, the more I prefer the way the way it is in the patch I posted. I don't think it's appropriate to put this support into the IRQ core. The main issue is that all the handlers for any shared wired-or interrupt line have to be registered before the IRQ is enabled, to avoid some initially active interrupt continually firing before the IRQ is enabled. Co-ordinating this when the wired-or line is on a board outside a device driver rather than internal to a chip and one device driver is a bit more than the IRQ core should probably be doing, hence I imagine why it doesn't support it. Co-ordinating this setup where all the sources of the wired-or are in one chip seems to belong to the chip driver, which is where my patch did this. I guess I could modify regmaps_irq_thread() so that instead of: for (i = 0; i < d->nchips; i++) handle_nested_irq(irq_find_mapping(d->irqdom, i)); ... it short-circuited and instead did something like: for (i = 0; i < d->nchips; i++) regmap_irq_thread(irq_find_mapping(d->irqdom, i), d->datas[i]); but it seems a little hokey to short-circuit the IRQ core; it would prevent execution of any statistics gathering or stuck interrupt handling that handle_nested_irq() might do for example. Now, if we made each child regmap_irq not be its own IRQ domain or irq_chip, but simply had one top-level domain/chip that aggregated them, that argument would be moot. However, that top-level domain/chip would become rather complex and just end up doing a bunch of demultiplexing code that's not needed if we do it like in my patch... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On 07/30/2012 11:25 AM, Mark Brown wrote: On Mon, Jul 30, 2012 at 11:00:04AM -0600, Stephen Warren wrote: On 07/29/2012 02:36 PM, Mark Brown wrote: On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote: I had implemented this in regmap since you'd specifically mentioned doing that. If I convert the code not to use separate IRQ domains for I think what I'd said was that we should factor it out rather than that it should be specifically done in regmap. this, would that be acceptable? Probably. The more I think about this, the more I prefer the way the way it is in the patch I posted. I don't think it's appropriate to put this support into the IRQ core. The main issue is that all the handlers for any shared wired-or interrupt line have to be registered before the IRQ is enabled, to avoid some initially active interrupt continually firing before the IRQ is enabled. Co-ordinating this when the wired-or line is on a board outside a device driver rather than internal to a chip and one device driver is a bit more than the IRQ core should probably be doing, hence I imagine why it doesn't support it. Co-ordinating this setup where all the sources of the wired-or are in one chip seems to belong to the chip driver, which is where my patch did this. I guess I could modify regmaps_irq_thread() so that instead of: for (i = 0; i d-nchips; i++) handle_nested_irq(irq_find_mapping(d-irqdom, i)); ... it short-circuited and instead did something like: for (i = 0; i d-nchips; i++) regmap_irq_thread(irq_find_mapping(d-irqdom, i), d-datas[i]); but it seems a little hokey to short-circuit the IRQ core; it would prevent execution of any statistics gathering or stuck interrupt handling that handle_nested_irq() might do for example. Now, if we made each child regmap_irq not be its own IRQ domain or irq_chip, but simply had one top-level domain/chip that aggregated them, that argument would be moot. However, that top-level domain/chip would become rather complex and just end up doing a bunch of demultiplexing code that's not needed if we do it like in my patch... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Mon, Jul 30, 2012 at 11:00:04AM -0600, Stephen Warren wrote:
> On 07/29/2012 02:36 PM, Mark Brown wrote:
> > On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
> I had implemented this in regmap since you'd specifically mentioned
> doing that. If I convert the code not to use separate IRQ domains for
I think what I'd said was that we should factor it out rather than that
it should be specifically done in regmap.
> this, would that be acceptable?
Probably.
> >> + ret = pm_runtime_get_sync(d->dev);
> >> + if (ret < 0) {
> > This is conditional in the core regmap runtime PM support, it may be
> > actively harmful if the device doesn't need it.
> Hmmm. I actually don't see any pm_*() usage in regmap right now. I
> assume this /is/ needed to convert arizona.c, since it's making these
> calls today. I don't need it for max8907.c. Should I add another flag to
> regmap_add_irq_chips() indicating whether this is needed, or ...?
It's not in -next yet due to the merge window. There's already a flag
for it in the irq chip data.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On 07/29/2012 02:36 PM, Mark Brown wrote:
> On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> Some devices contain a single interrupt output, and multiple separate
>> interrupt controllers that all trigger that interrupt output, yet provide
>> no top-level interrupt controller/registers to allow determination of
>> which child interrupt controller caused the interrupt.
>
> This isn't really anything to do with regmap, it's about implementing
> shared IRQ support for threaded interrupts. This is generally useful
> and shouldn't be tied to regmap, it's common enough for hardware
> designers to want to use wired or interrupts and it's a limitation of
> Linux that it can't cope currently.
>
> If are were going to implement it in regmap we shouldn't be faffing
> around setting up the virtual interrupts, we should just do the right
> thing and call round all the chips without bouncing it through the IRQ
> core.
OK, so more like how the max8907.c patch I posted did it than the
pre-existing arizona.c that I converted did it.
I had implemented this in regmap since you'd specifically mentioned
doing that. If I convert the code not to use separate IRQ domains for
this, would that be acceptable?
>> +static irqreturn_t regmaps_irq_thread(int irq, void *data)
>> +{
>> +struct regmap_irq_chips_data *d = data;
>> +int ret, i;
>> +
>> +ret = pm_runtime_get_sync(d->dev);
>> +if (ret < 0) {
>
> This is conditional in the core regmap runtime PM support, it may be
> actively harmful if the device doesn't need it.
Hmmm. I actually don't see any pm_*() usage in regmap right now. I
assume this /is/ needed to convert arizona.c, since it's making these
calls today. I don't need it for max8907.c. Should I add another flag to
regmap_add_irq_chips() indicating whether this is needed, or ...?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On 07/29/2012 02:36 PM, Mark Brown wrote:
On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Some devices contain a single interrupt output, and multiple separate
interrupt controllers that all trigger that interrupt output, yet provide
no top-level interrupt controller/registers to allow determination of
which child interrupt controller caused the interrupt.
This isn't really anything to do with regmap, it's about implementing
shared IRQ support for threaded interrupts. This is generally useful
and shouldn't be tied to regmap, it's common enough for hardware
designers to want to use wired or interrupts and it's a limitation of
Linux that it can't cope currently.
If are were going to implement it in regmap we shouldn't be faffing
around setting up the virtual interrupts, we should just do the right
thing and call round all the chips without bouncing it through the IRQ
core.
OK, so more like how the max8907.c patch I posted did it than the
pre-existing arizona.c that I converted did it.
I had implemented this in regmap since you'd specifically mentioned
doing that. If I convert the code not to use separate IRQ domains for
this, would that be acceptable?
+static irqreturn_t regmaps_irq_thread(int irq, void *data)
+{
+struct regmap_irq_chips_data *d = data;
+int ret, i;
+
+ret = pm_runtime_get_sync(d-dev);
+if (ret 0) {
This is conditional in the core regmap runtime PM support, it may be
actively harmful if the device doesn't need it.
Hmmm. I actually don't see any pm_*() usage in regmap right now. I
assume this /is/ needed to convert arizona.c, since it's making these
calls today. I don't need it for max8907.c. Should I add another flag to
regmap_add_irq_chips() indicating whether this is needed, or ...?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Mon, Jul 30, 2012 at 11:00:04AM -0600, Stephen Warren wrote:
On 07/29/2012 02:36 PM, Mark Brown wrote:
On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
I had implemented this in regmap since you'd specifically mentioned
doing that. If I convert the code not to use separate IRQ domains for
I think what I'd said was that we should factor it out rather than that
it should be specifically done in regmap.
this, would that be acceptable?
Probably.
+ ret = pm_runtime_get_sync(d-dev);
+ if (ret 0) {
This is conditional in the core regmap runtime PM support, it may be
actively harmful if the device doesn't need it.
Hmmm. I actually don't see any pm_*() usage in regmap right now. I
assume this /is/ needed to convert arizona.c, since it's making these
calls today. I don't need it for max8907.c. Should I add another flag to
regmap_add_irq_chips() indicating whether this is needed, or ...?
It's not in -next yet due to the merge window. There's already a flag
for it in the irq chip data.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> Some devices contain a single interrupt output, and multiple separate
> interrupt controllers that all trigger that interrupt output, yet provide
> no top-level interrupt controller/registers to allow determination of
> which child interrupt controller caused the interrupt.
This isn't really anything to do with regmap, it's about implementing
shared IRQ support for threaded interrupts. This is generally useful
and shouldn't be tied to regmap, it's common enough for hardware
designers to want to use wired or interrupts and it's a limitation of
Linux that it can't cope currently.
If are were going to implement it in regmap we shouldn't be faffing
around setting up the virtual interrupts, we should just do the right
thing and call round all the chips without bouncing it through the IRQ
core.
> * Copyright 2011 Wolfson Microelectronics plc
> + * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
All rights reserved? Hrm...
> +static irqreturn_t regmaps_irq_thread(int irq, void *data)
> +{
> + struct regmap_irq_chips_data *d = data;
> + int ret, i;
> +
> + ret = pm_runtime_get_sync(d->dev);
> + if (ret < 0) {
This is conditional in the core regmap runtime PM support, it may be
actively harmful if the device doesn't need it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Some devices contain a single interrupt output, and multiple separate
interrupt controllers that all trigger that interrupt output, yet provide
no top-level interrupt controller/registers to allow determination of
which child interrupt controller caused the interrupt.
This isn't really anything to do with regmap, it's about implementing
shared IRQ support for threaded interrupts. This is generally useful
and shouldn't be tied to regmap, it's common enough for hardware
designers to want to use wired or interrupts and it's a limitation of
Linux that it can't cope currently.
If are were going to implement it in regmap we shouldn't be faffing
around setting up the virtual interrupts, we should just do the right
thing and call round all the chips without bouncing it through the IRQ
core.
* Copyright 2011 Wolfson Microelectronics plc
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
All rights reserved? Hrm...
+static irqreturn_t regmaps_irq_thread(int irq, void *data)
+{
+ struct regmap_irq_chips_data *d = data;
+ int ret, i;
+
+ ret = pm_runtime_get_sync(d-dev);
+ if (ret 0) {
This is conditional in the core regmap runtime PM support, it may be
actively harmful if the device doesn't need it.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
From: Stephen Warren
Some devices contain a single interrupt output, and multiple separate
interrupt controllers that all trigger that interrupt output, yet provide
no top-level interrupt controller/registers to allow determination of
which child interrupt controller caused the interrupt.
In this case, a regmap irq_chip can be created for each of the individual
"child" interrupt controllers, alongside some infra-structure to hook the
interrupt and distribute it to each "child". This patch introduces
regmap_add_irq_chips() which sets up such infra-structure, and creates
a number of child regmap irq_chips.
Signed-off-by: Stephen Warren
---
drivers/base/regmap/regmap-irq.c | 187 ++
include/linux/regmap.h |9 ++
2 files changed, 196 insertions(+), 0 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 6bb4364..9d7894c 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -2,6 +2,7 @@
* regmap based irq_chip
*
* Copyright 2011 Wolfson Microelectronics plc
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
*
* Author: Mark Brown
*
@@ -16,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -40,6 +42,14 @@ struct regmap_irq_chip_data {
unsigned int irq_reg_stride;
};
+struct regmap_irq_chips_data {
+ struct device *dev;
+ int irq;
+ int nchips;
+ struct irq_domain *irqdom;
+ struct regmap_irq_chip_data **datas;
+};
+
static inline const
struct regmap_irq *irq_to_regmap_irq(struct regmap_irq_chip_data *data,
int irq)
@@ -463,3 +473,180 @@ int regmap_irq_get_virq(struct regmap_irq_chip_data
*data, int irq)
return irq_create_mapping(data->domain, irq);
}
EXPORT_SYMBOL_GPL(regmap_irq_get_virq);
+
+static void regmaps_irq_enable(struct irq_data *data)
+{
+}
+
+static void regmaps_irq_disable(struct irq_data *data)
+{
+}
+
+static struct irq_chip regmaps_irq_chip = {
+ .name = "regmaps",
+ .irq_disable= regmaps_irq_disable,
+ .irq_enable = regmaps_irq_enable,
+};
+
+static int regmaps_irq_map(struct irq_domain *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct regmap_irq_chips_data *data = h->host_data;
+
+ irq_set_chip_data(virq, data);
+ irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+
+ /* ARM needs us to explicitly flag the IRQ as valid
+* and will set them noprobe when we do so. */
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ irq_set_noprobe(virq);
+#endif
+
+ return 0;
+}
+
+static struct irq_domain_ops regmaps_domain_ops = {
+ .map= regmaps_irq_map,
+};
+
+static irqreturn_t regmaps_irq_thread(int irq, void *data)
+{
+ struct regmap_irq_chips_data *d = data;
+ int ret, i;
+
+ ret = pm_runtime_get_sync(d->dev);
+ if (ret < 0) {
+ dev_err(d->dev, "Failed to resume device: %d\n", ret);
+ return IRQ_NONE;
+ }
+
+ for (i = 0; i < d->nchips; i++)
+ handle_nested_irq(irq_find_mapping(d->irqdom, i));
+
+ pm_runtime_mark_last_busy(d->dev);
+ pm_runtime_put_autosuspend(d->dev);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * regmap_add_irq_chips(): Call regmap_add_irq_chip for n chips on one IRQ
+ *
+ * @irq: Primary IRQ for the device
+ * @irq_flags: The IRQF_ flags to use for the primary interrupt.
+ * @nchips:The number of IRQ chips attached to the interrupt.
+ * @maps: The regmap for each IRQ chip.
+ * @irq_bases The base Linux IRQ number for each chip, or NULL.
+ * @chips: Configuration for each interrupt controller.
+ * @data: Runtime data structure set of controllers, allocated on success
+ *
+ * Some devices contain a single interrupt output, and multiple separate
+ * interrupt controllers that all trigger that interrupt output, yet provide
+ * no top-level interrupt controller to allow determination of which child
+ * interrupt controller caused the interrupt. regmap_add_irq_chips() creates
+ * the required N regmap irq_chips, and handles demultiplexing this virtual
+ * top-level interrupt.
+ *
+ * Returns 0 on success or an errno on failure.
+ *
+ * In order for this to be efficient the chip really should use a
+ * register cache. The chip driver is responsible for restoring the
+ * register values used by the IRQ controller over suspend and resume.
+ */
+int regmap_add_irq_chips(int irq, int irq_flags, int nchips,
+struct regmap **maps, int *irq_bases,
+const struct regmap_irq_chip **chips,
+struct regmap_irq_chips_data **data)
+{
+ int ret = -ENOMEM;
+ struct regmap_irq_chips_data *d;
+ int i;
+
+ d =
[PATCH 3/3] regmap: enhance regmap-irq to handle 1 IRQ feeding n chips
From: Stephen Warren swar...@nvidia.com
Some devices contain a single interrupt output, and multiple separate
interrupt controllers that all trigger that interrupt output, yet provide
no top-level interrupt controller/registers to allow determination of
which child interrupt controller caused the interrupt.
In this case, a regmap irq_chip can be created for each of the individual
child interrupt controllers, alongside some infra-structure to hook the
interrupt and distribute it to each child. This patch introduces
regmap_add_irq_chips() which sets up such infra-structure, and creates
a number of child regmap irq_chips.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/base/regmap/regmap-irq.c | 187 ++
include/linux/regmap.h |9 ++
2 files changed, 196 insertions(+), 0 deletions(-)
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 6bb4364..9d7894c 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -2,6 +2,7 @@
* regmap based irq_chip
*
* Copyright 2011 Wolfson Microelectronics plc
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
*
* Author: Mark Brown broo...@opensource.wolfsonmicro.com
*
@@ -16,6 +17,7 @@
#include linux/irq.h
#include linux/interrupt.h
#include linux/irqdomain.h
+#include linux/pm_runtime.h
#include linux/slab.h
#include internal.h
@@ -40,6 +42,14 @@ struct regmap_irq_chip_data {
unsigned int irq_reg_stride;
};
+struct regmap_irq_chips_data {
+ struct device *dev;
+ int irq;
+ int nchips;
+ struct irq_domain *irqdom;
+ struct regmap_irq_chip_data **datas;
+};
+
static inline const
struct regmap_irq *irq_to_regmap_irq(struct regmap_irq_chip_data *data,
int irq)
@@ -463,3 +473,180 @@ int regmap_irq_get_virq(struct regmap_irq_chip_data
*data, int irq)
return irq_create_mapping(data-domain, irq);
}
EXPORT_SYMBOL_GPL(regmap_irq_get_virq);
+
+static void regmaps_irq_enable(struct irq_data *data)
+{
+}
+
+static void regmaps_irq_disable(struct irq_data *data)
+{
+}
+
+static struct irq_chip regmaps_irq_chip = {
+ .name = regmaps,
+ .irq_disable= regmaps_irq_disable,
+ .irq_enable = regmaps_irq_enable,
+};
+
+static int regmaps_irq_map(struct irq_domain *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct regmap_irq_chips_data *data = h-host_data;
+
+ irq_set_chip_data(virq, data);
+ irq_set_chip_and_handler(virq, regmaps_irq_chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+
+ /* ARM needs us to explicitly flag the IRQ as valid
+* and will set them noprobe when we do so. */
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ irq_set_noprobe(virq);
+#endif
+
+ return 0;
+}
+
+static struct irq_domain_ops regmaps_domain_ops = {
+ .map= regmaps_irq_map,
+};
+
+static irqreturn_t regmaps_irq_thread(int irq, void *data)
+{
+ struct regmap_irq_chips_data *d = data;
+ int ret, i;
+
+ ret = pm_runtime_get_sync(d-dev);
+ if (ret 0) {
+ dev_err(d-dev, Failed to resume device: %d\n, ret);
+ return IRQ_NONE;
+ }
+
+ for (i = 0; i d-nchips; i++)
+ handle_nested_irq(irq_find_mapping(d-irqdom, i));
+
+ pm_runtime_mark_last_busy(d-dev);
+ pm_runtime_put_autosuspend(d-dev);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * regmap_add_irq_chips(): Call regmap_add_irq_chip for n chips on one IRQ
+ *
+ * @irq: Primary IRQ for the device
+ * @irq_flags: The IRQF_ flags to use for the primary interrupt.
+ * @nchips:The number of IRQ chips attached to the interrupt.
+ * @maps: The regmap for each IRQ chip.
+ * @irq_bases The base Linux IRQ number for each chip, or NULL.
+ * @chips: Configuration for each interrupt controller.
+ * @data: Runtime data structure set of controllers, allocated on success
+ *
+ * Some devices contain a single interrupt output, and multiple separate
+ * interrupt controllers that all trigger that interrupt output, yet provide
+ * no top-level interrupt controller to allow determination of which child
+ * interrupt controller caused the interrupt. regmap_add_irq_chips() creates
+ * the required N regmap irq_chips, and handles demultiplexing this virtual
+ * top-level interrupt.
+ *
+ * Returns 0 on success or an errno on failure.
+ *
+ * In order for this to be efficient the chip really should use a
+ * register cache. The chip driver is responsible for restoring the
+ * register values used by the IRQ controller over suspend and resume.
+ */
+int regmap_add_irq_chips(int irq, int irq_flags, int nchips,
+struct regmap **maps, int *irq_bases,
+const struct regmap_irq_chip **chips,
+struct
