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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.