05:24 <DylanVanAssche> srinik: I managed to get almost everything working on SDM845 with WCD9340 codec. However, when switching between earpiece and headphones, it breaks earpiece audio. Headphones keeps working (but sometimes the audio is cracking). dmesg (with audio cracking, see overcurrent): https://paste.debian.net/1245564/ and dts: https://paste.debian.net/1245565/

05:25 <DylanVanAssche> ALSA UCM confs: https://gitlab.com/sdm845-mainline/alsa-ucm-conf/-/merge_requests/7

09:40 <rawoul> I've rebased WIP support for DPU on msm8998 with HDMI against next-20220624 if anyone is interested: https://github.com/rawoul/linux/commits/next_20220624-msm8998-hdmi

09:40 <rawoul> it's not finished and progressing very slowly since I have little time to work on it unfortunately

09:41 <rawoul> but it works in my setup

10:01 <srinik> DylanVanAssche: Can you check the level of gains, Also thinking about this it is worth implementing .mute_stream call back in wcd934x_dai_ops which should take care of this properly.

10:02 <DylanVanAssche> srinik: I printed the contents with amixer and all gains stay the same between the working and non-working situation.

10:02 <DylanVanAssche> srinik: How do you see .mute_stream? I'm not that familiar with the ALSA driver stuff

10:07 <srinik> DylanVanAssche: okay, one suspect is ordering of dapm widgets which might be creating some artifacts.. https://www.kernel.org/doc/html/latest/sound/soc/pops-clicks.html

10:07 <srinik> DylanVanAssche: so implementing a digital mute would help such situations..

10:09 <DylanVanAssche> srinik: Implementing digital mute, would that also help keeping the earpiece working? It works on boot.

10:09 <DylanVanAssche> Digital mute, would be setting a control I think? I don't have any documentation about the WCD chips

10:11 <calebccff> It would be great to get earpiece/headphone switching working before dealing with other issues

10:11 <srinik> DylanVanAssche: wcd934x does not have mute implemented in the codec driver yet.. its worth a shot to implement this. .I got few things in my plate to finsh off before looking at this..

10:12 <DylanVanAssche> calebccff: Well but the cracking is kinda related to it, it happens after switching (like 50% of the cases)

10:12 <calebccff> ah right

10:13 <srinik> DylanVanAssche: is cracking happening before/after playback or while playback in progress?

10:13 <srinik> DylanVanAssche: digital mute can help the former case.. not the later

10:14 <calebccff> srinik: could you point us to the missing bits for muting? Perhaps the earpiece is getting muted by the chip and we're missing the code that would unmute it

10:15 <srinik> calebccff: downstream code should have most of the bits.. but I can recheck it once again

10:15 <DylanVanAssche> srinik: boot -> play headphones OK -> switch to & play earpiece -> OK -> switch headphones -> cracking in 50% cases + earpiece completely no sound (until rebooted). If you switch directly to earpiece on boot, same behavior.

10:18 <srinik> DylanVanAssche: have you tried to check the register dumps for both working and non-working case?

10:20 <DylanVanAssche> srinik: `amixer -c0 contents` you mean? I checked those

10:20 <srinik> DylanVanAssche: no regmap registers from /sys/kernel/debug/regmap/...

10:21 <DylanVanAssche> srinik: Ah no, I can check those.

10:21 <calebccff> srinik: the hphl/r handling code explicitly disables the mute by writing to WCD934X_CDC_RX[1,2,3...]_RX_PATH_MIX_CTL, but there's no such thing for the earpiece on RX0

10:22 <srinik> DylanVanAssche: that might give some clues.. even tracing reg writes in both the case should help aswell

13:32 <DylanVanAssche> srinik: I compared the regs: https://paste.debian.net/1245600/

13:33 <DylanVanAssche> (Debian paste doesn't like the full reg dump files, they are to big)

13:34 <DylanVanAssche> I also added a mute/unmute as suggested by calebccff here. patch:

13:36 <aka_[m]> shawnguo: any chance you are there?

14:11 <ndec> rawoul: i will share your notes with dmitry. he is out this week, and likely might not see them.. thanks for sharing!

16:02 <lumag> rawoul: thanks a lot for sharing! I'm taking a peek this moment. Three CEC support.... I'm eager to see this on the mailing list!

16:09 <rawoul> lumag: thanks for checking out the patches, I will try to cleanup what already works (proper commit messages), I need to make my db820c boot before then to make sure I don't introduce regressions. I also haven't tested properly without "pd_ignore_unused" and "clk_ignore_unused", but clock trees are hard on qcom chips :)

16:10 <lumag> rawoul: week I should be able to test on 820c and on ifc6410

16:10 <rawoul> my main problem even with those flags is that the extp clock cannot be brought up again after it's brought down (after a mode resolution change), I'm not sure why

16:11 <lumag> This sounds like a gdsc issue. Maybe bamse can comment on this

16:11 <lumag> Is it in 8996 or 8998?

16:11 <lumag> The extp issue

16:14 <calebccff> bamse: do you know why recvfrom would return EAGAIN for qrtr? The same code was working before I put it in it's own thread

16:14 <calebccff> hmm, eagain = no data to read? weird

16:15 <rawoul> lumag: 8998

16:37 <lumag> rawoul: let's see if bamse knows more

16:49 <steev> my understanding is that clk_ignore_unused will be required for a very long time

17:26 <bamse> calebccff: that should be because your socket is non-blocking

17:27 <calebccff> right, thanks, i put the send and receive code in different threads and i think that's causing some issues, sorry for the random ping

17:27 <bamse> rawoul: which clock is that?

17:37 <rawoul> bamse: it is MDSS_EXTPCLK_CLK on msm8998. I might set the wrong power-domains on the hdmi tx controller, as lumag suspected. Currently I have "power-domains = <&rpmpd MSM8998_VDDCX>, <&mmcc MDSS_GDSC>"

17:39 <bamse> two power-domains?

17:41 <rawoul> I have to say I'm completely unaware of what I'm doing when dealing with power domains... I've tried to make it work by looking at the downstream dt bindings but they are splitted very differently

17:41 <bamse> okay, so if you have a single power-domains, it will be turned on/off following the pm_runtime state

17:42 <bamse> if you > 1 then that won't happen automagically, so the driver needs to handle that

17:42 <bamse> i'm not familiar with the hdmi driver, but most likely you specifying both means that neither is requested enabled

17:43 <bamse> i believe MDSS_GDSC is your power domain, and that is likely subdomain of VDDCX...but you probably don't need to bother with VDDCX...it's on

17:44 <rawoul> MDSS_GDSC might also not be needed since it's the power domain of the MDSS block

19:31 <Mis012[m]> bamse: well... "don't need to bother with" doesn't necessarily mean it shouldn't be specified...? I guess in this case ideally the power domain driver knows that MDSS_GDSC depends on VDDCX being enabled, unless the hw handles that by itself

19:32 <Mis012[m]> rawoul: hm, right... it's probably not correct to put it in the HDMI node then

19:34 <Mis012[m]> though maybe there's no devicetree node for the MDSS block as a whole?

19:34 <Mis012[m]> would probably be simple-power-managed-bus

19:43 <rawoul> Mis012[m]: there is a node for mdss, which is the parent for mdp, dsi0, dsi0_phy, ..., hdmi and hdmi_phy

19:44 <Mis012[m]> then I guess it would make sense to have it there

19:45 <Mis012[m]> clocks are indeed fun...

19:46 <rawoul> I'm not sure power domains are the issue for the MDSS_EXTPCLK_CLK clock being stuck because the output of /sys/kernel/debug/pm_genpd//sys/kernel/debug/pm_genpd/pm_genpd_summary is the same on boot (when extpclk_clk_src and mdss_extpclk_clk are enabled) and after hdmi modeswitch

19:48 <Mis012[m]> looks fun

19:49 <Mis012[m]> certainly more minimal than most RCGRs

19:50 <Mis012[m]> oops

19:51 <Mis012[m]> well, looks a bit less minimal when I don't manage to loose one line, but still