00:12 <steev> X13s users, i could be wrong, but i'm pretty sure https://patches.linaro.org/project/linux-bluetooth/patch/20240821091340.424248-1-quic_chejiang@quicinc.com/ gets rid of the unexpected event for opcode 0xfc48 (probably more than just X13s but i haven't tried the other devices)

00:39 <abby> is this a known issue with the gpu on x13s? https://0x0.st/8xDp.txt I'm seeing it on 6.12.28+ and 6.14.8 (6.12.20 is fine)

00:41 <abby> i use the dtb that matches each kernel version, and it's happening with linux-firmware both 20250410 and 20250311. easy way to trigger it is doing something that needs the gpu, like launching kitty or sway

00:59 <steev> abby: im on 6.12.30 and do not see it (in sway)

01:00 <abby> yeah, zdykstra couldn't reproduce with kde wayland

01:00 <abby> so there might be another variable

01:00 <abby> nevermind zdykstra is seeing it

01:00 <steev> what did they do to trigger it

01:01 <abby> have there been any new necessary modules added recently?

01:01 <steev> not that i am aware of

01:01 <abby> i think it was just launching kde, but it was falling back to sw rendering

01:02 <steev> i've been using gnome for a while on 6.14 (admittedly my kernel, not the debian one) and haven't seen it at all (gnome on wayland, not xorg)

01:02 <steev> just switched back to 6.12 to test the bluetooth patch

01:03 <abby> new data point: 6.13.12 works with sway

01:32 <abby> and i can confirm 6.13.12 works with kitty

02:45 <steev> was it launching kitty on kde?

02:47 <abby> it's 3 different cases: kitty on i3 (me), kde wayland (zdykstra), sway (someone else), all on void

02:49 <steev> what version of mesa?

02:50 <abby> 24.3.3

02:50 <abby> .4*

02:50 <steev> 25.0.5 here

02:50 <steev> and not seeing it

02:50 <steev> have tried sway, gnome on wayland

02:50 <abby> ok, will have to check that later

02:51 <abby> i guess that makes sense if it is

04:22 <abby> no dice with mesa 25.1.1, and here's a grep for msm of the full dmesg: https://0x0.st/8xdp.txt

04:43 <HdkR> `*ERROR* Unable to load qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn` That's a pretty damning log. Mesa versions wouldn't resolve that

04:47 <abby> not the problem, as that's been happening for a while, even on working versions

04:49 <abby> that's just saying that firmware isn't in the initramfs, iirc

04:51 <HdkR> Ah, early message. Cool

05:31 <steev> is the sqe firmware in there?

05:32 <steev> in the initramfs

05:32 <abby> no

05:33 <abby> I've tried adding it before but it didn't change iirc

06:02 <steev> and nothing in /sys/kernel/debug/devices_deferred ?

06:46 <abby> will have to check tomorrow

06:49 <steev> I know at one point I was running into the gpu locking up, but i haven't seen it not power up. I know that robclark said that it can get funky if you have the sqe firmware but not the zap? in the initramfs, but you say you don't have that

06:52 <abby> which firmware is sqe? i assumed that was a typo of the

07:05 <JensGlathe[m]> I usually have all 3 of them, .gmu, .sqe and zap in the initramfs.

07:11 <valpackett> pmos has none of those in initramfs, no gpu driver either so it doesn't even try anything before mounting the actual rootfs

07:32 <steev> weird, then it shouldn't error out at being unable to load the firmware?

07:32 <steev> oh wait, you said pmos, abby is using void

07:34 <steev> jhovold: btw, i found https://patches.linaro.org/project/linux-bluetooth/patch/20240821091340.424248-1-quic_chejiang@quicinc.com/ from around 9 months ago, since applying it, i cannot reproduce the unexpected event message. I sent a reply (thought gse seemed to butcher it and there's no subject now) to ask if it just fell through the cracks because bluetooth's patchwork has it marked as superseded but i can't find what replaced it

08:09 <jhovold> steev: ok, let's see what the authour replies, sounds like it's mostly benign but one less random error is always good

08:12 <jhovold> valpackett, steev: that's not good at all, seeking sounds like a pretty standard operation

08:12 <jhovold> I would expect there to be more bugs in the new iris driver, but one would hope something like this would have been fixed in venus long ago

08:13 <steev> jhovold: bryanodonoghue said something about sending an email to the list, but i dunno if he did (and not trying to call him out if he didn't) but no idea, i *think* i saw him say something about them tracking it internally in linaro

08:13 <jhovold> then again, we are only just now starting to enable video acceleration in mainline on machines that people actually use

08:14 <JensGlathe[m]> What an odd thing to say

08:15 <jhovold> yeah, there are issues like that all over, hopefully more users hitting and reporting this will add some pressure but someone still needs to find time to work on it

08:15 <jhovold> JensGlathe[m]: which part?

08:24 <JensGlathe[m]> Actually all of it

08:26 <JensGlathe[m]> But also no offense

08:31 <jhovold> I'm lost about what your point is, I'm afraid

08:32 <jhovold> are you referring to what I said or what steev mentioned bryan may have said?

08:33 <steev> i'll be honest, i'm also lost but i never take offense, i was around when the internet was new

08:35 <jhovold> just want to clear out any misunderstanding if something I said was unclear

08:38 <JensGlathe[m]> No, sorry for the confusion. I meant your statement about just now mainlining video acceleration on hardware people actually use. That sounds at least interesting, all things considered (that i know)

08:41 <jhovold> I was referring to qcom hw

08:42 <jhovold> as in enabling it on qcom based laptops running mainline, and not just on the odd demo devboard

08:48 <JensGlathe[m]> jhovold and I guess we’re on the same page. Appreciate what you’re doing.

09:19 <JensGlathe[m]> The PS8830 on the HP X14 has gone AWOL btw

09:38 <dgilmore> steev: are you saying you are old?

10:27 <travmurav[m]> best attempt could decode h264 for about 2hrs, at which point i realized it was decoding live feed below real-time speed and my phone crashed with about a hour of feed gone xD

10:29 <travmurav[m]> I have no idea how it did it but given the input feed was streamed in and output was streamed out over the network, I guess ram just filled with unprocessed h264 and it died xD

10:29 <travmurav[m]> Ever since then I dont fully believe Venus works even though the decode part seems to work completely fine on 7c1, yet to see encode ever work tho xD

10:31 <travmurav[m]> So i guess i also kinda have an impression it seldom tested until very recently

10:53 <Jasper[m]> I don't think anyone ever upstreamed the firmware for it so no one officially tested if it worked

10:54 <Jasper[m]> The msm8916 stuff (save for the dragonboard maybe) was all pulled out of random vendor repo's

10:54 <travmurav[m]> Not like it wasn't the same blob with different signature attached anyway xD

10:55 <Jasper[m]> Oh yeah absolutely hahahaha

13:02 <bryanodonoghue> steev jhovold not following your conversation - iris bug is about all i got here

13:04 <jhovold> bryanodonoghue: iiuc, iris breaks when seeking with gstreamer, steev says venus suffers from same problem

13:04 <jhovold> and you are supposedly aware of it :)

13:04 <bryanodonoghue> ah yes i recall steev ? probably reporting breakage on venus too

13:04 <bryanodonoghue> we do have a bug in the db to track

14:04 <lumag> alexVinarskis[m]: HdkR, DSC for DP is not wired yet. One of my colleagues posted a patchset some time ago, but unfortunately he never followed up after a feedback.

14:54 <HdkR> lumag: nice nice

15:55 <alexVinarskis[m]> lumag: thanks for the clarification. Any plans to have it resurrected, if you know?

16:09 <abby> steev: turns out i made a typo in my dracut conf and adding that firmware does fix it

16:12 <HdkR> woo

17:37 <steev> abby: :) at least you sorted it

20:01 <alexVinarskis[m]> konradybcio: I tried your re-spinned series from Niels + DT change for mux-switch; and 4 DP lanes on Asus Zenbook A14, PS8833. Tested with: USB3.0 pendrive, Type-C to DP cable (x4 DP lanes, no USB3) and dongle (USB3+DP mode). It appears to work just fine, all three modes, in both orientations. No need to double plug the USB stick after any other mode.

20:14 <alexVinarskis[m]> I still do not understand, why it works/doesn't crash during suspend/resume? `qmp_combo_runtime_suspend` will attempt to disable `qmp->pipe_clk`, which in case of x4 lane DP was already powered off by `qmp_combo_usb_power_off` during either switch or mux notification call. Resume will try to power it up, which won't work if USB phy is not being used. When developing my series, without safeguarding suspend/resume functions to

20:14 <alexVinarskis[m]> of course, just trying to understand out of curiousity what did I miss and why your series works with a simpler change.

20:14 <alexVinarskis[m]> only touch `pipe_clk` if USB mode is being used, I would get dmesg errors on suspend, and weird screen artifacts on resume. With your/Neils series I don't get anything in dmesg. During suspend internal screen did flash blue (which is a bit untypical) but otherwise it just worked. As it seems the official implementation was both up much earlier and is more complete, it makes no sense for me to keep developing and testing mine

20:23 <alexVinarskis[m]> Edit: just retested few more times, blue screen on suspend seems unrelated.

22:18 <konradybcio> i agree it's not easy to read this driver

22:20 <konradybcio> that said the hardware behind it is loaded too.. although in a technical marvel sense

23:29 <valpackett> um, are those power up/down ops not refcount based?