[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z36Gag6XhOrsIXqK@hovoldconsulting.com>
Date: Wed, 8 Jan 2025 15:06:34 +0100
From: Johan Hovold <johan@...nel.org>
To: Frank Oltmanns <frank@...manns.dev>,
Bjorn Andersson <andersson@...nel.org>,
Chris Lew <quic_clew@...cinc.com>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
Johan Hovold <johan+linaro@...nel.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Abel Vesa <abel.vesa@...aro.org>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, regressions@...ts.linux.dev,
stable@...r.kernel.org
Subject: Re: [PATCH] soc: qcom: mark pd-mapper as broken
On Tue, Jan 07, 2025 at 11:02:24AM +0100, Johan Hovold wrote:
> On Mon, Jan 06, 2025 at 08:10:52PM +0100, Frank Oltmanns wrote:
> > Thank you so much for this idea. I'm currently using this workaround on
> > my sdm845 device (where the in-kernel pd-mapper is breaking the
> > out-of-tree call audio functionality).
>
> Thanks for letting us know that the audio issue affects sdm845 as well
> (I don't seem to hit it on sc8280xp and the X13s).
And today I also hit this on the sc8280xp CRD reference design, so as
expected, there is nothing SoC specific about the audio service
regression either:
[ 11.235564] PDR: avs/audio get domain list txn wait failed: -110
[ 11.241976] PDR: service lookup for avs/audio failed: -110
even if it may be masked by random changes in timing.
These means it affects also machines like the X13s which already have
audio enabled.
> > Is there any work going on on making the timing of the in-kernel
> > pd-mapper more reliable?
>
> The ECANCELLED regression has now been fixed, but the audio issue
> remains to be addressed (I think Bjorn has done some preliminary
> investigation).
Hopefully Bjorn or Chris have some plan on how to address the audio
regression.
Johan
Powered by blists - more mailing lists