[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87ilkyvc1q.wl-tiwai@suse.de>
Date: Wed, 05 Oct 2022 11:45:37 +0200
From: Takashi Iwai <tiwai@...e.de>
To: "Lu, Brent" <brent.lu@...el.com>
Cc: "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"Jaroslav Kysela" <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Mohan Kumar <mkumard@...dia.com>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>, "Zhi, Yong" <yong.zhi@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ALSA: hda/hdmi: run eld notify in delay work
On Wed, 05 Oct 2022 10:14:19 +0200,
Lu, Brent wrote:
>
> >
> > ... and on the further consideration, I believe the best solution is to just get rid of
> > the whole check.
> >
> > It was introduced by the commit eb399d3c99d8 along with the 8ae743e82f0b
> > that checks the suspend state. The latter is still meaningful (we should skip the
> > bogus notification at suspend).
> > However, the former -- the code path we're dealing with -- doesn't help much in
> > the recent code. That fix was required because the driver probed the ELD bits
> > via HD-audio verb at the time of the fix commit; that is, the driver had to wake
> > up the codec for updating the ELD. OTOH, now ELD is read directly from the
> > graphics chip without the codec wakeup. So the skip makes little sense.
> Hi Takashi,
>
> I've got the test result from ODM which is positive. During 60 test runs, the elf notify
> running in suspend happened 10 times and the audio is normal. The patch is looking
> good.
Thanks for confirmation. The fix will be included in 6.1-rc1.
Takashi
Powered by blists - more mailing lists