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: https://lore.kernel.org/all/20230526113258.1467276-1-quic_mohs@xxxxxxxxxxx/ > > 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 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? 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, Krzysztof
