Re: Issues bringing up WCD9385 codec on SC7280/QCM6490

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Fri Dec 1, 2023 at 1:02 PM CET, Krzysztof Kozlowski wrote:
> On 01/12/2023 11:35, Luca Weiss wrote:
> > Hi all,
> > 
> > I'm trying to get audio working on qcm6490-fairphone-fp5 (the SoC is
> > sc7280.dtsi-based).
> > Unfortunately the current sc7280.dtsi only supports directly interfacing
> > with the hw blocks (lpass_aon/lpass_hm/lpass_audiocc) and not using
> > q6afecc, but I think I've done this "conversion" correctly, based on
> > other mainline SoCs and downstream dts.
> Eh, you probably duplicated a lot of existing work. Here it is:

Well, at least this patch[0] seems to be reasonably helpful, but even
this one uses q6prmcc and not q6afecc but apart from that I will double
check if it matches what I have, but looks rather similar.


> > 
> > So, to the problem: I've added the nodes for the WCD9385 codec found on
> > this device which is handling the microphones (and analog audio over
> > USB-C). But I can't get it to work. I believe the first problem I saw
> > was the error "soundwire device init timeout" where I saw that the wcd
> > tx & rx devices (on the soundwire bus) only appeared after the timeout
> > of 2 seconds expired and wcd938x driver probe failed. After bumping this
> > to something higher (20 seconds) this was resolved.
> Please describe the tree you are working on. This was fixed some time ago.

Currently v6.7-rc2 plus some patches for general device support.
Unfortunately the fix you had for v6.6 or something and mentioned on IRC
is already in there..

> > 
> > But now I'm having these errors in the initialization of the wcd
> > devices.
> > 
> > [   45.651156] qcom-soundwire 3230000.soundwire: swrm_wait_for_rd_fifo_avail err read underflow
> > [   45.651173] soundwire sdw-master-1: trf on Slave 1 failed:-5 read addr 41 count 1
> > [   45.651182] wcd9380-codec sdw:0:0217:010d:00:3: SDW_SCP_INTMASK1 write failed:-5
> > [   45.651186] wcd9380-codec sdw:0:0217:010d:00:3: Slave 1 initialization failed: -5
> > 
> > After some more debugging and changing some timeouts I'm noticing that
> > the swr devices appear immediately after pm_runtime puts the driver to
> > sleep, qcom_swrm_irq_handler is called and then we get this:
> > 
> > [   45.531863] qcom-soundwire 3230000.soundwire: SWR new slave attached
> > 
> > The same also happens for the other soundwire controller
> > 
> > [   47.581067] qcom-soundwire 3210000.soundwire: SWR new slave attached
> There were similar reports on the IRC, so I wonder if this is the same
> issue?
> Maybe wrong interrupt flag (like falling instead of rising)? I collected
> over time also several ideas of fixes from Srini, not always ready to
> upstream, but maybe they fix your issue? Did you try some of my audio
> branches like n/audio-sm8450-sm8550-on-next?

I didn't yet. I'll check out[1] then and dig around if I see anything


> Or maybe sc7280 needs to toggle the same CSR reset/clock bits as
> sc8280xp (lpass-csr-sc8280xp.c)?

Assuming you mean lpasscc-sc8280xp.c the resets defined in [2] do seem
to be represented in my downstream yupik-audio-overlay.dtsi. There's
* qcom,swrm-hctl-reg = <0x032a90a8>; for TX macro SWR
* qcom,swrm-hctl-reg = <0x032a90a0>; for RX macro SWR
* qcom,swrm-hctl-reg = <0x032a90b0>; for WSA macro SWR

And the latter two have the same value as in the sc8280xp patch. And the
property is used in techpack/audio in some runtime_resume code under a
lot of if's but also with "SW workaround to gate hw_ctl for SWR
version >=1.6" and this SoC has controller v1.6.0.

This might be promising, I think?


> > 
> > And this is currently where I'm stuck and can't really think of why this
> > is happening.. I've double checked nearly all of the properties I've
> > added/modified incl. wcd reset GPIO, wcd *-supply, lpi pinctrl settings.
> > I believe the "read underflow" error here is because the whole driver
> > stack is already trying to suspend so then communication fails. The real
> > question for me is why the swr 'slaves' only appear exactly when
> > pm_runtime is suspending everything.
> Yeah, good question.

Too bad you don't have an amazing idea why this is happening ;)

Thanks for your advise, let's see if it gets me any further!


> > 
> > The only thing I've not really checked yet is qcom,rx-port-mapping &
> > qcom,tx-port-mapping, there I've just tried the two different values
> > found on the various devices but I don't think this is causing these
> > issues. I will try to look further into this property at some point but
> > with msm-5.4 downstream it's quite tricky to find where these values are
> > represented (I got some hints from Krzysztof though where to look so
> > I'll try to do that soon)
> > 
> > I'm attaching my current diff to the email, just note that it's based on
> > one of my dev branches and is manually edited to remove some debug
> > prints etc so it will probably not apply anywhere. I can also push the
> > git tree somewhere in case that's helpful.
> > 
> > Regards
> > Luca
> > 
> Best regards,
> Krzysztof

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux