On Fri Dec 1, 2023 at 1:38 PM CET, Luca Weiss wrote: > 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/ Hi, Quick update. Re-adding qcom,sc7280-lpassaudiocc (and hacking out all the non-reset bits from that driver) seems to make things quite a bit better. I'll check more in the coming week(s). But I haven't gotten actual audio out of the microphone yet. Looking back, I shouldn've just discarded these resets, but I wasn't aware that this driver was touching both forbidden registers but also some registers that were still needed. Regards Luca > > > > > > > > > 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
