From: Tony Lindgren <tony@atomide.com>
To: Tim Harvey <tharvey@gateworks.com>
Cc: Lee Jones <lee.jones@linaro.org>,
open list <linux-kernel@vger.kernel.org>,
Carl Philipp Klemm <philipp@uvos.xyz>,
Laxminath Kasam <lkasam@codeaurora.org>,
Merlijn Wajer <merlijn@wizzup.org>,
Mark Brown <broonie@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack
Date: Sun, 15 Nov 2020 10:43:08 +0200 [thread overview]
Message-ID: <20201115084308.GY26857@atomide.com> (raw)
In-Reply-To: <CAJ+vNU0T0qS282MU-FRy8zNLgjnvF=+-5k=XxxXhZw6k2cgASw@mail.gmail.com>
* Tim Harvey <tharvey@gateworks.com> [201113 22:07]:
> 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]);
Yes that's what I noticed too. And that's why cpcap was working for
me with ack_invert and without it earlier.
> 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.
Yes could be. For cpcap, we have IRQ_TYPE_LEVEL_HIGH configured in the
motorola-cpcap-mapphone.dtsi file.
> 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?
Well I looked at the v3.0.8 Motorola Linux Android kernel, it actually
does clear_ack. So I'd rather keep the same logic as we have no proper
documentation for cpcap. I also confirmed still works without ack_invert
too while ack_invert now is broken. But using clear_ack now that we
have it working seems safer.
Regards,
Tony
next prev parent reply other threads:[~2020-11-15 8:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-11 17:06 [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack Tony Lindgren
2020-11-13 10:21 ` Lee Jones
2020-11-13 22:06 ` Tim Harvey
2020-11-15 8:43 ` Tony Lindgren [this message]
2020-11-16 20:45 ` Tim Harvey
2020-11-16 18:59 ` Mark Brown
2020-11-16 20:43 ` Tim Harvey
2020-11-16 21:14 ` Mark Brown
2020-11-15 17:31 ` Pavel Machek
2020-11-17 8:25 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201115084308.GY26857@atomide.com \
--to=tony@atomide.com \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkasam@codeaurora.org \
--cc=merlijn@wizzup.org \
--cc=pavel@ucw.cz \
--cc=philipp@uvos.xyz \
--cc=sre@kernel.org \
--cc=tharvey@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox