Messages in this thread | | | From | Tim Harvey <> | Date | Fri, 13 Nov 2020 14:06:29 -0800 | Subject | Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack |
| |
On Fri, Nov 13, 2020 at 2:21 AM Lee Jones <lee.jones@linaro.org> wrote: > > On Wed, 11 Nov 2020, Tony Lindgren wrote: > > > With commit 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack > > registers"), the cpcap interrupts are no longer getting acked properly > > leading to a very unresponsive device with CPUs fully loaded spinning > > in the threaded IRQ handlers. > > > > To me it looks like the clear_ack commit above actually fixed a long > > standing bug in regmap_irq_thread() where we unconditionally acked the > > interrupts earlier without considering ack_invert. And the issue with > > cpcap started happening as we now also consider ack_invert. > > > > Tim Harvey <tharvey@gateworks.com> tried to fix this issue earlier with > > "[PATCH v2] regmap: irq: fix ack-invert", but the reading of the ack > > register was considered unnecessary for just ack_invert, and we did not > > have clear_ack available yet. As the cpcap irqs worked both with and > > without ack_invert earlier because of the unconditional ack, the > > problem remained hidden until now. > > > > Also, looks like the earlier v3.0.8 based Motorola Android Linux kernel > > does clear_ack style read-clear-write with "ireg_val & ~mreg_val" instead > > of just ack_invert style write. So let's switch cpcap to use clear_ack > > to fix the issue. > > > > Fixes: 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers") > > Cc: Carl Philipp Klemm <philipp@uvos.xyz> > > Cc: Laxminath Kasam <lkasam@codeaurora.org> > > Cc: Merlijn Wajer <merlijn@wizzup.org> > > Cc: Mark Brown <broonie@kernel.org> > > Cc: Pavel Machek <pavel@ucw.cz> > > Cc: Sebastian Reichel <sre@kernel.org> > > Cc: Tim Harvey <tharvey@gateworks.com> > > It would be nice to have you review this Tim. >
Tony / Lee,
Thanks for keeping me in the loop on this. I still haven't properly resolved the issue with my device/driver interrupts (drivers/mfd/gateworks_gsc.c) which requires ack_invert (writing 0 to clearing interrupt bits).
3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers") appears to not only add the new clear_ack case it also attempts to resolve the long standing ack_invert issue with this change:
- ret = regmap_write(map, reg, data->status_buf[i]); + if (chip->ack_invert) + ret = regmap_write(map, reg, + ~data->status_buf[i]); + else + ret = regmap_write(map, reg, + data->status_buf[i]);
However, this still doesn't resolve the issue I have with my device/driver because it ends up writing 1's to all the other bits in the ack register which keeps my device's interrupt from de-asserting. Perhaps that's a strange behavior of my device that it allows you to 'set' interrupt source bits which causes the interrupt to stay asserted? I'm also wondering if my issue is that I currently have the interrupt registered as such:
ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq, IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, &gsc_irq_chip, &irq_data);
Perhaps this should be IRQF_TRIGGER_LOW as the device will not de-assert its IRQ# until all source bits are cleared.
Tony, I thought that your pcap issue was that it truly did not have an inverted ack and the fact that ack_invert did not work was why you never noticed any issue. If this is true I would think you would want to disable ack_invert but not necessarily enable clear_ack. Did your testing show it needed to toggle the ack to clear it?
Best Regards,
Tim
| |