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: > https://lore.kernel.org/all/20230526113258.1467276-1-quic_mohs@xxxxxxxxxxx/ 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. [0] https://lore.kernel.org/all/20230526113258.1467276-7-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. 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 else. [1] https://github.com/krzk/linux/commits/n/audio-sm8450-sm8550-on-next > > 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? [2] https://lore.kernel.org/linux-arm-msm/20230608125315.11454-5-srinivas.kandagatla@xxxxxxxxxx/ > > > > > 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! Regards Luca > > > > > 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
