Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230306044737.862-1-honda@mechatrax.com> <6e1fe1015235ae7d7eb9ef2526fd64b6d6d628d7.camel@gmail.com>
 <CA+Tz-SHQxNzx=eS8ex=3Hps0th5bTY+K1qSWrZqWC8ryv+d0RA@mail.gmail.com>
 <CA+Tz-SFbt2RAz3POMRoTHqz+tNyQOn3UsssZV9EvHUhhR+XJbQ@mail.gmail.com> <2a108acdd79682f47e3ac923fe005b943a4a00c0.camel@gmail.com>
In-Reply-To: <2a108acdd79682f47e3ac923fe005b943a4a00c0.camel@gmail.com>
From:   Masahiro Honda <honda@mechatrax.com>
Date:   Tue, 28 Mar 2023 19:55:02 +0900
Message-ID: <CA+Tz-SHL1ybx37vM_uon+XxYC4FXD_Ci1HTcZyb+5e0iD6t=uA@mail.gmail.com>
Subject: Re: [PATCH] Fix IRQ issue by setting IRQ_DISABLE_UNLAZY flag
To:     =?UTF-8?B?TnVubyBTw6E=?= <noname.nuno@gmail.com>
Cc:     Lars-Peter Clausen <lars@metafoo.de>,
        Michael Hennerich <Michael.Hennerich@analog.com>,
        Jonathan Cameron <jic23@kernel.org>, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Mar 27, 2023 at 9:26=E2=80=AFPM Nuno S=C3=A1 <noname.nuno@gmail.com=
> wrote:
>
> So, my suspicion was right... We are getting stalled data (which is
> obviously not good). AFAIU, when disabling the IRQ, we don't
> immediately mask the IRQ and we only do it in the next time an
> interrupt (sample) comes which means (I think) we'll process (right
> away) that outstanding interrupt next time we enable the IRQ.
>

Thank you. I understand.

> > > > Some research on this also seems to point that we should (need?)
> > > > call
> > > > irq_clear_status_flags(irq, IRQ_DISABLE_UNLAZY) when freeing the
> > > > IRQ.
> >
> > I have understood that I need to call irq_clear_status_flags.
> > However,
> > I cannot find a code to free the IRQ in ad_sigma_delta.c and other
> > Sigma-Delta ADC driver source files. So, I would like to implement
> > only irq_set_status_flags.
>
> Well, that's because we are using devm_request_irq() which is a device
> managed API. So, I can see two options in here...
>
> 1) You do not use devm_request_irq() and use request_irq() +
> devm_add_action_or_reset() and in your release() function you would
> call irq_clear_status_flags() + free_irq().
>
> 2) You add a devm_add_action_or_reset() after devm_request_irq() and
> your release() function would only clear the flag. But in here we would
> likely also have to be careful in the case where devm_request_irq()
> fails. So option 2) seems a bit more "ugly".
>
> I would likely go to option 1) but maybe Jonathan or others have better
> ideas.
>

Thank you very much for letting me know about the API and ideas.
I'll try to implement 1).