Hi Mark,
Am Montag, den 22.07.2013, 11:08 +0100 schrieb Mark Brown:
> On Mon, Jul 22, 2013 at 11:24:52AM +0200, Philipp Zabel wrote:
> > In case the hardware interrupt mask register does not prevent the chip level
> > irq from being asserted by the corresponding interrupt status bit, stray
> > masked interrupts should to be acknowledged, too.
>
> > Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
> > ---
> > I have seen GPI interrupts trigger on DA9063 trigger after being masked
> > during
> > initialization, and once the status bits are set, the interrupt handler
> > routine
> > never clears them, which keeps the chip irq line asserted forever.
>
> This can't be the standard behaviour since it breaks expectations as to
> what happens for masked interrupts. Though based on your description of
> the problem it sounds like a quirk to ack interrupts immediately after
> masking them might do the trick instead of the full on always ack
> behaviour.
thanks, this seems to work, too:
diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index 1643e88..4c99ed8 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -418,6 +418,24 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int
irq_flags,
reg, ret);
goto err_alloc;
}
+
+ /* Ack masked but set interrupts */
+ reg = chip->status_base +
+ (i * map->reg_stride * d->irq_reg_stride);
+ ret = regmap_read(map, reg, &d->status_buf[i]);
+ if (ret != 0) {
+ dev_err(map->dev, "Failed to read IRQ status: %d\n",
+ ret);
+ goto err_alloc;
+ }
+
+ reg = chip->ack_base +
+ (i * map->reg_stride * d->irq_reg_stride);
+ ret = regmap_write(map, reg, d->status_buf[i] & d->mask_buf[i]);
+ if (ret != 0) {
+ dev_err(map->dev, "Failed to ack 0x%x: %d\n", reg, ret);
+ goto err_alloc;
+ }
}
/* Wake is disabled by default */
--
1.8.3.2
Can something like this be done unconditionally, or should I add a quirk
flag to regmap_irq_chip?
regards
Philipp
--
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/
