On Sun, Feb 09, 2025 at 12:57:21PM +0100, Frank Oltmanns wrote:
> On 2025-02-06 at 07:44:49 +0100, Frank Oltmanns <frank@xxxxxxxxxxxx> wrote:
> Hi Bjorn,
>
> > Hi again,
> >
> > On 2025-02-06 at 06:57:46 +0100, Frank Oltmanns <frank@xxxxxxxxxxxx> wrote:
> >> On 2025-02-05 at 20:54:53 -0600, Bjorn Andersson <andersson@xxxxxxxxxx> wrote:
> >>> On Wed, Feb 05, 2025 at 10:57:11PM +0100, Frank Oltmanns wrote:
> >>>> On xiaomi-beryllium and oneplus-enchilada audio does not work reliably
> >>>> with the in-kernel pd-mapper. Deferring the probe solves these issues.
> >>>> Specifically, audio only works reliably with the in-kernel pd-mapper, if
> >>>> the probe succeeds when remoteproc3 triggers the first successful probe.
> >>>> I.e., probes from remoteproc0, 1, and 2 need to be deferred until
> >>>> remoteproc3 has been probed.
> >>>>
> >>>> Introduce a device specific quirk that lists the first auxdev for which
> >>>> the probe must be executed. Until then, defer probes from other auxdevs.
> >>>>
> >>>> Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
> >>>> Cc: stable@xxxxxxxxxxxxxxx
> >>>> Signed-off-by: Frank Oltmanns <frank@xxxxxxxxxxxx>
> >>>> ---
> >>>> The in-kernel pd-mapper has been causing audio issues on sdm845
> >>>> devices (specifically, xiaomi-beryllium and oneplus-enchilada). I
> >>>> observed that Stephan’s approach [1] - which defers module probing by
> >>>> blocklisting the module and triggering a later probe - works reliably.
> >>>>
> >>>> Inspired by this, I experimented with delaying the probe within the
> >>>> module itself by returning -EPROBE_DEFER in qcom_pdm_probe() until a
> >>>> certain time (13.9 seconds after boot, based on ktime_get()) had
> >>>> elapsed. This method also restored audio functionality.
> >>>>
> >>>> Further logging of auxdev->id in qcom_pdm_probe() led to an interesting
> >>>> discovery: audio only works reliably with the in-kernel pd-mapper when
> >>>> the first successful probe is triggered by remoteproc3. In other words,
> >>>> probes from remoteproc0, 1, and 2 must be deferred until remoteproc3 has
> >>>> been probed.
> >>>>
> >>>
> >>> The remoteproc numbering is assigned at the time of registering each
> >>> remoteproc driver, and does not necessarily relate to the order in which
> >>> they are launched. That said, it sounds like what you're saying is that
> >>> is that audio only works if we launch the pd-mapper after the
> >>> remoteprocs has started?
> >>
> >> Almost, but not quite. You are right, that remoteproc3 in my setup is
> >> always the last one that probes the pd-mapper.
> >>
> >> However, when experimenting with different timings I saw that the
> >> pd-mapper really do has to respond to the probe from remoteproc3 (I'm
> >> not sure I'm using the right terminology here, but I hope my intent
> >> comes across). If the pd-mapper responds to remoteproc3's probe with
> >> -EPROBE_DEFER there will again be subsequent probes from the other
> >> remoteprocs. If we act on those probes, there is a chance that audio
> >> (mic in my case) does not work. So, my conclusion was that remoteproc3's
> >> probe has to be answered first before responding to the other probes.
> >>
> >> Further note that in my experiments remoteproc1 was always the first to
> >> do the probing, followed by either remoteproc0 or remoteproc2.
> >> remoteproc3 was always the last.
> >>
> >>> Can you please confirm which remoteproc is which in your numbering? (In
> >>> particular, which remoteproc instance is the audio DSP?)
> >>
> >> remoteproc0: adsp
> >> remoteproc1: cdsp
> >> remoteproc2: slpi
> >> remoteproc3: 4080000.remoteproc
> >
> > I'm sorry but there's one additional thing that I really should have
> > mentioned earlier: My issue is specifically with *call* audio.
> >
> > Call audio is only available using out-of-tree patches. The ones I'm
> > currently using are here:
> > https://gitlab.com/sdm845-mainline/linux/-/commits/sdm845-6.13-rc2-r2?ref_type=tags
>
> Just wanted to let you know that I've tested Mukesh Ojha's and Saranya
> R's patch [1]. Thanks, Bjorn for cc'ing me in your response.
>
> Unfortunately, it seems to fix a different issue than the one I'm
> experiencing. The phone's mic still doesn't work. As I wrote elsewhere
> [2], I don't see the PDR error messages on xiaomi-beryllium, so, as
> Johan expected, the issue I'm experiencing is indeed a different one.
>
Yes, it sounds like you have another race following this. [1] resolves
an issue where we get a timeout as we're trying to learn about which PDs
exist - which results in no notification about the adsp coming up, which
in turn means no audio services.
Do you have the userspace pd-mapper still running btw?
Regards,
Bjorn
