00:19 <bamse> gwolf: it should be supported, it was supported previously

00:20 <gwolf> bamse: just sitting at the C630 now, so I'll check :-)

00:20 <bamse> i talked with Srini about the ucm file earlier today, so we should make a new attempt at fixing the review comments and try to get the patches merged

00:21 <robclark> speaking of UCM, I think audio on sc7180 should be all in place, so I assume all we need for audio there is for someone who grok's UCM to wave their magic wand?

00:22 <gwolf> Output devices has only "Speaker playback" (using pulseaudio tools)

00:22 <bamse> robclark: here there be dragons...

00:22 <bamse> robclark: nice talk btw, like your demo :)

00:23 <robclark> of the snapping variety?

00:23 <robclark> :-P

00:23 <gwolf> (am using steev's 5.12)

00:23 <bamse> robclark: and yes, usb mic is what i've been using all along...as we never got the mic on the c630 to work and swiching my headset to headset profile does give me working mic but i just get garbage in the ears

00:23 <robclark> small secret, I was also using a MR I have posted to enable cached-coherent staging buffers so readpix from screen to x264 wasn't using cached instead of writecombine

00:25 <bamse> robclark: a few pending patches doesn't hurt :)

00:25 <bamse> but it's really nice to see that we can do these things on the upstream kernel/userspace

00:25 <robclark> indeed

00:26 <robclark> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11176 fwiw.. in case you have any other presentations to record in the near future.. that helped obs-studio somewhat

00:26 <bamse> glad we were foolish enough to continue hacking on this 5-6 years ago :)

00:26 <robclark> heheh

00:27 <bamse> robclark: speaking of hackings, i'm continuing to dig around at qualcomm to find someone who can tell me more about the frequency scaling on the a630 gmu...

00:28 <robclark> oh, right

00:28 <robclark> I guess the question is, "who is responsible for waiting for voltage to stabilize"?

00:29 <bamse> well, given that it's all hidden inside the gmu...it should be off our hands

00:29 <bamse> but i did teach linux about the voltage scaling just to verify that, and it didn't help

00:30 <robclark> right.. I mean if we were using linux frameworks directly then I'd expect it to be the responsibility of the providing driver to delay if needed.. with GMU voting directly.. I just have no clue

00:30 <bamse> right, the rpmh request is sync on the way up, so it should be taken care of

00:30 <robclark> I have been meaning to work on something to use a timer to defer slightly (maybe ~1ms) clamping down the freq which might help (but might just be papering over the issue.. but there are other reasons to do that)

00:30 <bamse> but as i said, it didn't help...

00:30 <robclark> yeah

00:31 <bamse> right, we had the hypothesis that it was jumping from lowest to highest that was the issue...but disabling the highest frequency didn't help

00:32 <robclark> oh, ok

00:33 <bamse> seems though that if we take intermediate steps things do look better

00:33 <bamse> question is if i'm just hiding the problem...and what the problem actually is...

00:34 <robclark> right.. that is kinda the boat I'm in.. if there are constraints, what exactly are they?

00:34 <bamse> yeah, and as i said...i was able to reproduce it prior to your change...by just using the userspace governor

00:35 <robclark> yeah, it was mostly just luck that we didn't hit it before

00:35 <bamse> so i guess if one is unlucky and switches between performance and powersave for fun and profit one might hit the issue as well

00:35 <bamse> yeah, seems like it

00:35 <bamse> or we actually ended up switching frequencies stepwise and that's what's expected

00:35 <bamse> but if so we need to know which adreno versions that requires that

00:36 <robclark> for v5.15 I could ofc push the hack to just disable the new behavior on a630 (or perhaps !=a618).. I guess that will be my fallback if we don't figure out what exactly the limits are in time

00:37 <bamse> i had some other issue on the a680 last week, let me rebase that and see if we have a problem there

00:37 <bamse> otherwise i think we should just hack around it for a630

00:37 <robclark> I mean, an issue that you "probably" won't hit, is better than one you defn will

01:27 <steev> gwolf: let me double check, but 5.14 should be usable (i haven't tested ear phones)

01:27 <steev> and by double check, i mean, i haven't pushed the wrong thing

01:28 <steev> yeah, my 5.14 should be usable

01:28 <steev> i use it, i mean

01:30 <steev> i also only see speaker playback in pulse

03:11 <gwolf> Will update/check later. FWIW, you don't upload your kernels to the linaro apt repo, right?

03:11 <gwolf> (I mean, I'll have to download it from $other_site and manually install)

14:09 <steev> i do not

14:32 <steev> i am not a member of linaro :)

14:33 <steev> you'll have to clone and build the kernel with the bindeb-pkg target. i've been trying to get the debian kernel patched and adding support for the c630 into it (experimental since it's 5.14) but so far, i haven't had much success

15:04 <ndec> if pushing a kernel package into the linaro debian repo would help in any way, we could try it.. i think we've tried at some point, but never really completed the task. at least I have permission to push there..

15:21 <steev> i don't know what all is involved there

15:21 <steev> and if we were to use my sources... i need to get a lot better at not bringing in random testing things :D

15:21 <steev> or get even better at bringing in testing things, so more people test them ;)

16:28 <gwolf> OK. Cannot set to do it right now, but I'll later bug you for the URL

16:28 <gwolf> (right now I'm not at that machine)