ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
rfs613 has quit [Ping timeout: 480 seconds]
rfs613 has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<steev> shawnguo: does that firmware patch for ipa do the right thing if you're using the split firmware?
<shawnguo> steev: no, I'm afraid not. it only works for single blob.
<shawnguo> or I should have said it was only tested with single blob
<shawnguo> steev: oh, I got your point - .mdt actually means split firmware
<shawnguo> so maybe I should put ipa_fws.mdt or ipa_fws.elf into MODULE_FIRMWARE()?
<shawnguo> or is there a nice way to exclude ipa.ko from initramfs image?
<steev> i don't think there's a nice way to exclude it... i think you'd have to create a blacklist-ipa.conf file and blacklist it and then a modprobe.d config that loads it?
<steev> not sure if that works though
<shawnguo> sounds a bit complex, but I will try out to see if it works, thanks!
<shawnguo> ipa_fws.mbn or ipa_fws.elf into MODULE_FIRMWARE(), I meant
<steev> it's annoying and unfortunate, it would be nice if the module itself had some way of noticing no firmware and probe deferring, but then if the user doesn't actually have the firmware, it would probably just keep spamming the logs
<robclark> steev: sent a patch for you
<steev> ur a patch
<robclark> patches writing patches.. madness!
<steev> pulling it in now, but tbh, that was the first time i think i've ever seen that
<steev> so it'll be a while to know if i can reproduce
<steev> oh wait, that was on next wasn't it
<robclark> yeah, I think the cause was something new in v5.15
<robclark> anything that opens dev file when you don't (yet) have fw will trigger it
<steev> robclark: unrelated, i've upgraded to mesa 21.2.2 here, and when i unblank (not sure the correct term, not sleeping, just blanked screen) the display to log back in, the backlight comes on, but the display itself doesn't wake up? if that makes sense at all
<steev> it's not every time though
<robclark> hmm, I wouldn't *expect* something like that to be related to mesa version
<steev> hm
<steev> i did update to 5.14.8
<robclark> do you get mouse cursor?
<steev> nope
<robclark> what does /sys/kernel/debug/dri/0/state say?
<steev> nothing in dmesg, so i assumed it wasn't dmesg related
<steev> nothing, because nothing is in there
<steev> oh, because i'm an idiot
<steev> turns out, wsl doesn't have a sys/kernel/debug :P
<robclark> heh
<robclark> is that with it in the "no display" state?
<steev> yes
<robclark> it looks like the core drm at least *thinks* there should be something on screen..
<robclark> including a cursor
<robclark> so I'd say display issue.. not sure if dpu or bridge
<robclark> but hmm, I did add some debugfs for the bridge driver..
<steev> this is 5.14 tho
<steev> let me reboot into -next to test your patch
<robclark> `cat /sys/kernel/debug/2-002d/status` (although the `2-002d`, which I guess is an i2c address, might be different)
<steev> can check in a bit
<robclark> fwiw, this is what "normal" should look like roughly:
hightower2 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
iivanov has quit [Remote host closed the connection]
<steev> bamse: shawn is right, i can't figure out what your aux-bus patch is based on either. you being stingy with them patches? :P