09:33 <minecrell> srinik: Do you remember why you did https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5b4a68952a89e7decf4ff5e86406975cc730575d ? Runtime PM is obviously unneeded for the remote case since there is no clock, but the callbacks should just do nothing in that case (reverting this commit seems to work fine)

09:34 <minecrell> The problem in v5.19 is your follow up commit that skips the pm_runtime_get() for the remote case, but still does the pm_runtime_put(), leading to infinite spam about runtime PM count underflow... (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dbad41e7bb5f4b9949ff5ea1d76c20711f326308)

09:34 <minecrell> I just wonder if all these conditionals are worth it or if we can just use no-op runtime PM there

09:57 <srinik> minecrell: for remote controlled bam we can not cut off the clock if dsp is managing it. runtime pm should be mostly done when HLOS is in full control of the IP.

09:58 <srinik> minecrell: dsp might be in middle of accessing the registers while we cut off the clock, Ideally these clocks should be voter clocks where both hlos and dsp can vote on them.. but am not sure how these particular clocks are managed

10:00 <srinik> minecrell: yes, we should not be calling any runtime pm functions for remotely controlled ones

10:00 <srinik> minecrell: I wonder what has changed in 5.19 that showed up this issue. this patch was in from a very long time.

10:01 <srinik> minecrell: I wonder what has changed in 5.19 that showed up this issue. this patch was in from a very long time.

10:10 <Mis012[m]> srinik: lots of clocks should have hw voting but don't... :(

10:10 <Mis012[m]> and then you need RPM MITMing the clocks in order to have voting

10:11 <Mis012[m]> or you just can't touch the clocks from Linux at all

10:47 <minecrell> srinik: 5.19 started logging runtime PM underflows. It was always broken, it just wasn't noticeable so far

10:48 <minecrell> srinik: I don't think remotely controlled ones do have clocks assigned, so shouldn't the runtime PM callbacks be a no-op?

10:49 <minecrell> clk_enable() just returns 0 immediately if the clock is null. So enabling runtime PM is a bit weird but shouldn't make a functional difference and would make the code easier to read

10:51 <Tooniis[m]> what are COPPs in ADM?

10:51 <srinik> minecrell: I was hoping that runtime_pm_disable should take care of it.. which does not look correct.. If you already have patch can you send it to list, we could discuss it with wider audience

10:53 <srinik> Tonniis[m]: COPPs are matrix[like mixers] connecting afe and asm streams

10:57 <minecrell> srinik: The two options are adding pm_runtime_enabled() checks to all pm_runtime_put() calls as well or somehow making use of runtime PM without breaking anything. I'm not really sure myself what is best (that's why I asked)

10:57 <minecrell> But yeah I guess I can make a patch for one of the options

11:00 <srinik> minecrell first one sounds reasonable, lots of the dirvers do something similar,

11:01 <srinik> minecrell add bam_pm_runtime_put... wrapper or something on those lines

11:01 <minecrell> srinik: fair enough, will send it later

11:01 <minecrell> Thanks :)

11:01 <minecrell> Or do you want to?

11:27 <Tooniis[m]> im having trouble understanding multiple channel playback. taking db820c as an example, multimedia2 is connected to slimbus_5_rx mixer for left channel and slimbus_6_rx mixer for right channel, but then only slimbus_6_rx is connected to aif4_pb on wcd9335?

11:28 <Tooniis[m]> and in wcd aif4_pb splits into slim rx5 mux and slim rx6 mux again

11:28 <Tooniis[m]> how does that work exactly?

11:29 <Tooniis[m]> or is the rx5/rx6 split only in the wcd side? im not sure

11:32 <Tooniis[m]> im trying to do something similar for capture with 2 mics connected to one dai, but im not sure how to do it

11:33 <Tooniis[m]> in the wcd9335 driver the capture dais have `channels_max = 4`, but im not sure how i can hook up multiple channels to them

11:34 <Tooniis[m]> unlike pb, there are mixers between the slim tx* muxes and aif* cap dais

16:51 <DylanVanAssche> bamse: Hi! Could it be that this patch was missed? https://lkml.org/lkml/2022/5/12/91

17:13 <bamse> DylanVanAssche: it seems to have been posted after i had to send my v5.19-rc1 pull request, and i've not gotten up to speed on going through the queue again

17:14 <DylanVanAssche> bamse: No problem, I'm not in a hurry. Take your time 🙂

17:16 <bamse> thanks, i will try to get through the queue as soon as possible

17:20 <DylanVanAssche> bamse: sure, I'm a bit inexperienced with patches and kernel mailing lists, this like my 2nd one or something, still have a lot to learn 🙂