03:53 <vkoul> hey sboyd can we get your attention to SPMI patches, now been pending for quite some time

05:48 <DylanVanAssche> srinik: I found a local commit that causes the only-sound-after-second-aplay for the SDM845. Now it works fine by reverting it (prepare/shutdown instead of trigger in wcd934x).

05:49 <DylanVanAssche> srinik: Only problem remains: sometimes aplay gives no sound through e.g. earpiece of the wcd934x. If you wait a bit and turn on the screen again for example, it works again. Is there some power management or clk stuff active?

05:50 <DylanVanAssche> I haven't seen anything in the wcd934x codec driver, I just find it weird that it happens randomly and comes back like nothing happened 🙂

10:13 <Tooniis[m]> srinik: do you know if the SLIM TX muxes are supposed to be able to connect to multiple AIF*_CAP mixers at a time in WCD9335? Because the driver currently has separate controls for each link but only the last control set is effective due to it adding the same `wcd->tx_chs[port_id].list` to `wcd->dai[dai_id].slim_ch_list`, removing it from the list it was in

10:13 <Tooniis[m]> (in `slim_tx_mixer_put`)

17:22 <z3ntu> bamse: Is it okay with you if I send this (rebased) patch from you from 2019? https://github.com/msm8974-mainline/linux/commit/d01e20807a00e78570abf3dd91bea555dff06fa9

17:25 <z3ntu> This is needed for fixing this failure :D https://lore.kernel.org/linux-arm-msm/202206091706.4QP4H2JW-lkp@intel.com/ (or removing the remoteproc supplies from castor)

19:15 <calebccff> just booted 5.19-rc1 and I'm seeing a lot of "bam-dma-engine 17184000.dma-controller: Runtime PM usage count underflow!" spam, anyone else had this?

19:18 <Mis012[m]> pretty sure it was discussed in this very room

19:19 <Mis012[m]> tl;dr it was happening before as well, but now it prints stuff

19:19 <calebccff> ah fun

19:19 <calebccff> oof room history riight

20:12 <Tooniis[m]> <calebccff> "just booted 5.19-rc1 and I'm..." <- ive been having that for a while too

20:18 <calebccff> Tooniis[m]: I posted a patch with a fix, not sure if it's the right approach though - https://lore.kernel.org/linux-arm-msm/20220609195043.1544625-1-caleb.connolly@linaro.org/

20:21 <Tooniis[m]> if it at least silences the spam then its good. for me they come from slimbam which made reading actual sound errors really painful since touching any slimbus mixer controls flooded dmesg with them

20:21 <Tooniis[m]> thanks ill try it

21:06 <minecrell> calebccff: you should probably wrap all the operations then, also the mark last busy

21:10 <minecrell> Other than that it's exactly what I discussed with srini.k above, thanks for making a patch

21:13 <calebccff> minecrell: im not super familiar with pm_runtime, why should the mark_last_busy also be wrapped?

21:14 <calebccff> if pm_runtime is disabled then excluding ref counting everything else should basically noop right?