Re: Issues bringing up WCD9385 codec on SC7280/QCM6490

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


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:

> 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.

> 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

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?

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

> 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.

> 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,

[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