Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201111170613.46057-1-tony@atomide.com> <20201113102134.GI3718728@dell>
 <CAJ+vNU0T0qS282MU-FRy8zNLgjnvF=+-5k=XxxXhZw6k2cgASw@mail.gmail.com> <20201115084308.GY26857@atomide.com>
In-Reply-To: <20201115084308.GY26857@atomide.com>
From:   Tim Harvey <tharvey@gateworks.com>
Date:   Mon, 16 Nov 2020 12:45:43 -0800
Message-ID: <CAJ+vNU3uuX1TB+uKQ_YMseA2kJHLGf2Z6SECTwn_M==Gf2=-AQ@mail.gmail.com>
Subject: Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack
To:     Tony Lindgren <tony@atomide.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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Nov 15, 2020 at 12:43 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * 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

Tony,

Ok - sounds like the right thing for your device.

Reviewed-By: Tim Harvey <tharvey@gateworks.com>

Tim