All of lore.kernel.org
 help / color / mirror / Atom feed
From: mtk15103 <hailong.fan@mediatek.com>
To: Nicolas Boichat <drinkcat@chromium.org>
Cc: Sean Wang <sean.wang@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	lkml <linux-kernel@vger.kernel.org>, <youlin.pei@mediatek.com>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	Chen-Tsung Hsieh <chentsung@chromium.org>,
	<gtk_pangao@mediatek.com>, Hanks Chen <hanks.chen@mediatek.com>,
	Yong Wu <yong.wu@mediatek.com>
Subject: Re: [PATCH] pinctrl: mediatek: Fix trigger type setting follow for unexpected interrupt
Date: Mon, 25 Jan 2021 12:18:21 +0800	[thread overview]
Message-ID: <1611548301.1248.9.camel@mhfsdcap03> (raw)
In-Reply-To: <CANMq1KCfBy9dRELP-hMjY5FraachcRGHEC9mmaMjJCLQzdu+ZA@mail.gmail.com>

On Mon, 2021-01-25 at 11:24 +0800, Nicolas Boichat wrote:
> On Mon, Jan 25, 2021 at 11:15 AM Hailong Fan <hailong.fan@mediatek.com> wrote:
> >
> > When flipping the polarity will be generated interrupt under certain
> > circumstances, but GPIO external signal has not changed.
> > Then, mask the interrupt before polarity setting, and clear the
> > unexpected interrupt after trigger type setting completed.
> 
> I'd add a short note about why you remove mtk_eint_flip_edge, that is,
> because mtk_eint_unmask already calls it.
Add it on V3, thx.
 
> >
> > Signed-off-by: Hailong Fan <hailong.fan@mediatek.com>
> > ---
> > [V2]
> > ---
> >  drivers/pinctrl/mediatek/mtk-eint.c | 13 +++++++++++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek/mtk-eint.c
> > index 22736f60c16c..0042f32c7e7e 100644
> > --- a/drivers/pinctrl/mediatek/mtk-eint.c
> > +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> > @@ -157,6 +157,7 @@ static void mtk_eint_ack(struct irq_data *d)
> >  static int mtk_eint_set_type(struct irq_data *d, unsigned int type)
> >  {
> >         struct mtk_eint *eint = irq_data_get_irq_chip_data(d);
> > +       bool unmasked;
> 
> Well, this is true if the interrupt has been masked (or, equivalently,
> if we need to unmask it later).
> 
> So I think either "masked" or "unmask" are better as variable names.
Yes, masked is better.
> 
> >         u32 mask = BIT(d->hwirq & 0x1f);
> >         void __iomem *reg;
> >
> > @@ -173,6 +174,13 @@ static int mtk_eint_set_type(struct irq_data *d, unsigned int type)
> >         else
> >                 eint->dual_edge[d->hwirq] = 0;
> >
> > +       if (!mtk_eint_get_mask(eint, d->hwirq)) {
> > +               mtk_eint_mask(d);
> > +               unmasked = true;
> > +       } else {
> > +               unmasked = false;
> > +       }
> > +
> >         if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING)) {
> >                 reg = mtk_eint_get_offset(eint, d->hwirq, eint->regs->pol_clr);
> >                 writel(mask, reg);
> > @@ -189,8 +197,9 @@ static int mtk_eint_set_type(struct irq_data *d, unsigned int type)
> >                 writel(mask, reg);
> >         }
> >
> > -       if (eint->dual_edge[d->hwirq])
> > -               mtk_eint_flip_edge(eint, d->hwirq);
> > +       mtk_eint_ack(d);
> > +       if (unmasked)
> > +               mtk_eint_unmask(d);
> >
> >         return 0;
> >  }
> > --
> > 2.18.0


  reply	other threads:[~2021-01-25  4:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25  3:15 [PATCH] pinctrl: mediatek: Fix trigger type setting follow for unexpected interrupt Hailong Fan
2021-01-25  3:24 ` Nicolas Boichat
2021-01-25  3:24   ` Nicolas Boichat
2021-01-25  3:24   ` Nicolas Boichat
2021-01-25  4:18   ` mtk15103 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-01-21  3:17 Hailong Fan

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=1611548301.1248.9.camel@mhfsdcap03 \
    --to=hailong.fan@mediatek.com \
    --cc=chentsung@chromium.org \
    --cc=drinkcat@chromium.org \
    --cc=gtk_pangao@mediatek.com \
    --cc=hanks.chen@mediatek.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=sean.wang@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=yong.wu@mediatek.com \
    --cc=youlin.pei@mediatek.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.