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;
Message-ID: <2a108acdd79682f47e3ac923fe005b943a4a00c0.camel@gmail.com>
Subject: Re: [PATCH] Fix IRQ issue by setting IRQ_DISABLE_UNLAZY flag
From:   Nuno =?ISO-8859-1?Q?S=E1?= <noname.nuno@gmail.com>
To:     Masahiro Honda <honda@mechatrax.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
Date:   Mon, 27 Mar 2023 14:28:02 +0200
In-Reply-To: <CA+Tz-SFbt2RAz3POMRoTHqz+tNyQOn3UsssZV9EvHUhhR+XJbQ@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 
MIME-Version: 1.0
Precedence: bulk

On Mon, 2023-03-27 at 18:01 +0900, Masahiro Honda wrote:

Hi Masahiro,

Thanks for looking in more detail into this...

> Hi, Nuno
>=20
> > On Mon, Mar 6, 2023 at 10:30=E2=80=AFPM Nuno S=C3=A1 <noname.nuno@gmail=
.com>
> > wrote:
> > > Another thing that came to my mind is if the data is totally
> > > garbage/wrong or is it just some outstanding sample?
>=20
> I'm sorry for not answering your question. The data is the same as
> the previous conversion even if the input voltage is changed. At this
> time, a logic analyzer shows that the read operation is performed
> immediately after the conversion is performed. The read operation
> returns the previous conversion result because it is performed before
> the completion of the conversion.
>=20

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.

> > > 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.
>=20
> 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...=C2=A0

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.

- Nuno S=C3=A1