Date:   Wed, 15 Feb 2023 23:01:09 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Guenter Roeck <groeck@google.com>
Cc:     David Rau <David.Rau.opensource@dm.renesas.com>,
        support.opensource@diasemi.com, lgirdwood@gmail.com,
        perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org,
        linux-kernel@vger.kernel.org, bailideng@google.com,
        Guenter Roeck <groeck@chromium.org>
Subject: Re: [PATCH] ASoC: da7219: Improve the IRQ process to increase the
 stability
Message-ID: <Y+1kNa8KYCUzgAfo@sirena.org.uk>
References: <20230215101045.21456-1-David.Rau.opensource@dm.renesas.com>
 <Y+zZwKFX1gMC5/ac@sirena.org.uk>
 <CABXOdTdv=+n8+UCgWUvyrZ6R0uAu48bODa3TA_2nUuMbUT7MUg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="e1E9LnR+Ahmxjv3e"
Content-Disposition: inline
In-Reply-To: <CABXOdTdv=+n8+UCgWUvyrZ6R0uAu48bODa3TA_2nUuMbUT7MUg@mail.gmail.com>
Precedence: bulk


--e1E9LnR+Ahmxjv3e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 15, 2023 at 08:06:35AM -0800, Guenter Roeck wrote:
> On Wed, Feb 15, 2023 at 5:10 AM Mark Brown <broonie@kernel.org> wrote:

> > Copying in Guenter given the issues he raised with this, not
> > deleting context for his benefit.  It looks like this should
> > avoid the issues with the interrupt appearing locked up.

> It should since it limits the delay to cases where jack_inserted is
> false, but on the other side it hides the delay in an odd way.
>=20
=2E..

> Effectively this seems to be quite similar to moving the conditional
> sleep to the place where cancel_work_sync() is called. I would assume
> that will fix the problem (after all, the msleep() is no longer called
> unconditionally), but I don't see the benefit of introducing a worker
> to do that. Also, since there is no guarantee that the worker actually
> started by the time cancel_work_sync() is called, I would suspect that
> it may result in unexpected behavior if the worker has not started by
> that time, which I would assume can happen if the system is heavily
> loaded. It also makes the use of the ground switch (i.e., when to set
> and when to drop it) even more of a mystery than it is right now.

> Having said that, I don't really know or understand the code, so maybe
> this all makes sense and my feedback should be ignored.

Yes, I would certainly welcome more clarity especially around the
ground switch.  OTOH it does seem like an improvement over the
current situation so I think I'll go ahead and apply it for now,
hopefully it can be improved upon in future.

--e1E9LnR+Ahmxjv3e
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmPtZDQACgkQJNaLcl1U
h9D+3Qf7B/pdT2c5Gz6fLqeKbf9iXv7oOvDmvUhZUnPiTDyuuQ5fDNg+WDBp/i7K
6Y7Je3c8seM0sdixYFrb3zG52ob3NMmU9a/cdcjpTaRGl7FI+BJDjApQPCY5Usbu
7Sai0SVpv+mMPo5lzsyfAD7E0YjrfvvHWved7r8plXhsVCZK0Su4idwBczw6Axn4
cCV7f0f0Vp2nihlDJQaSeX+j3qgkR4yq8Da33GJQnaapiens51aZDsmQrvuLOxUO
cDr+kcKa5rlvXM77XHqX1N0xI0Ev+pESxSkcCGrOwq3CtgeWdXyeeATNEUn8rKXC
pXmYs3mBaH3o3lywQLh9MITFtHuG/Q==
=LJK/
-----END PGP SIGNATURE-----

--e1E9LnR+Ahmxjv3e--