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)
mcbridematt has quit [Quit: Leaving]
mcbridematt has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
chester_lin has joined #aarch64-laptops
chester_lin has quit [Remote host closed the connection]
chester_lin has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
svarbanov_ has quit [Ping timeout: 480 seconds]
leiflindholm has quit []
leiflindholm has joined #aarch64-laptops
shoragan has quit [Quit: quit]
shoragan has joined #aarch64-laptops
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
laine has quit [Quit: (╯°□°)╯︵ ┻━┻]
laine has joined #aarch64-laptops
jhovold has quit [Quit: WeeChat 3.8]
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
<robclark> in _theory_ display should still work without gpu fw in initrd.. as long as you don't actually need gpu accel in initrd
<steev> 6.4 is out!
<HdkR> woop woop!
<bamse> robclark: fbcon does come up just fine without gpu firmware...but starting a graphical environment fails, as the missing firmware causes mesa to not initialize
<bamse> robclark: but it seems to survive just fine failing to find firmware during boot and then pick it up on the "retry"
<robclark> right, that is how it is supposed to work
<steev> it can't pick it up on the retry when the fs is encrypted tho
<steev> and that's the case the user that clover is talking about has - since they have encyrpted fs, they need the gpu firmware to be in the initrd, or need msm to not be
<robclark> hmm, at least on fedora the disk unlock screen doesn't need gpu.. I think it is just part of plymouth
<javierm> robclark: that's correct, and should work with simpledrm or efifb
<clover[m]> "x13s Gen1. I have full disk encryption and if I wait a moment before entering the passphrase to unlock the disk, the screen goes all black. If I enter the passphrase, then it eventually comes back to normal with the usual login prompt on the console. Weird 😅. Anyways good enough for what I plan to do."
<clover[m]> This... doesn't seem normal
<danielt> "Enjoy" it for long enough and anything starts to seem normal!
<robclark> clover[m]: got clk_ignore_unused pd_ignore_unused? Maybe the kernel is helpfully disabling the "unused" things that efifb needs ;-)
<bamse> clover[m]: that is quite likely because the regulators for your display are being turned off
<konradybcio> or you don't have all of your necessary modules in initrd clover
<bamse> clover[m]: it would be nice if you could try just commenting out the second class_for_each_device(..., regulator_late_cleanup); call in regulator_init_complete_work_functions() in drivers/regulator/core.c
<bamse> konradybcio: you don't necessarily want that, as you then also need all the related firmware
<konradybcio> bamse if drm/msm can't find adreno fw, it will retry on next gpu access
<konradybcio> the display hw will be handled though
<bamse> konradybcio: right, but the problem is defining "all necessary"...and if he where to bring in the adsp remoteproc driver, then that won't retry finding the firmware
<konradybcio> ah right
<bamse> which is wrong...but i don't have a solution for this problem
<robclark> it would be nice if we had _some_ way for efifb to function properly.. but I think that would require some description in dt??
<konradybcio> robclark I already do this on some phone i believe.. simple-framebuffer happily accepts clocks
<bamse> robclark: efifb works just fine, but it doesn't vote for the display power
<konradybcio> bamse doesn't starting pd-mapper toggle (at least some) rprocs?
<robclark> at one point in the past I had some proposal which added some flags for clks/gdscs to indicate "hey display needs this"
<bamse> konradybcio: rmtfs does launch the mpss...but that's because starting mpss without rmtfs is 100% causing a crash
<bamse> robclark: if you don't have all the display modules in the ramfs - and you keep the display and backlight regulators on, then it works fine
<robclark> hmm, ok.. so maybe the regulators need to be marked somehow in dt
<bamse> robclark: the missing thing, where we need that, is if we start binding mdss et al, and then bail...because that point we've started restarting the display...
<konradybcio> bamse drm core takes care of that
<konradybcio> simplefb is removed and drm msm starts clean
<robclark> should be efifb, but same diff..
<bamse> konradybcio: right, but what if you discover late in that process that you don't have all components?
<konradybcio> robclark: what's efifb but a preconfigured simplefb ;)
<bamse> robclark: perhaps add something in dt to make efifb to be aware of the regulators it needs to hold until that handover point
<konradybcio> bamse: in that case you wouldn't have display at all without efi/simplefb anyway
<bamse> konradybcio: right, but what i'm saying is if we probe defer on the edp panel not being there...then the user won't know that
<bamse> konradybcio: and that is a usability issue
<bamse> but we really have two different set of issues...there's keeping efifb/splash functional up until display starts probing...and then how to handle the transition
<bamse> and i'm pretty sure that clover[m]'s issue is in the first category
<bamse> and robclark's efforts where in the second
<robclark> yeah, the _eventual_ goal would be to read back hw state and do a smooth transition.. but I'd be happy to start with if we can just keep efifb from falling over ;-)
<bamse> robclark: right, and from my earlier days of getting display up on sc8280xp...if you just mark the relevant regulators regulator-always-on in dt (and don't disable unused clocks and pds) then efifb works
<bamse> robclark: we really would like to ensure that disable_unused doesn't kick in while we're still booting, _or_ stuck in the ramdisk
<bamse> for regulators, clocks, pds, interconnect etc
<robclark> does regulator-always-on prevent turning it off _after_ drm probes?
<bamse> yes
<robclark> hmm, that probably isn't quite ideal..
<bamse> always == forever
<bamse> but, if efifb could regulator_enable() those, then we'll be good
<robclark> is there some way to mark it as "don't touch until driver takes over"?
<bamse> and i wouldn't surprised if that would happen behind the scene in a acpi system
<robclark> right.. well also kernel controls power via acpi so acpi can keep track of things like that behind the kernel's back
<bamse> robclark: in several other subsystems we rely on the sync_state callback on the provider device to signal that all dt-nodes referencing back to us has been probed
<bamse> robclark: but the regulator framework has a mechansim that predates that, which just starts a timer for 30 seocnds at late init
<bamse> robclark: abelvesa is looking at this stuff for clocks and genpd right now...i'll see if we can get him a jira card to look at regulators as well
<robclark> cool, thx
<clover[m]> steev: headed to Guatemala tomorrow for two weeks, anything we can update today for the new kernel release?
<steev> i can push the 6.4 stuff but i still haven't figured out the mic thing - we already have the dapm jack patch, afaik
<steev> s/mic/headphone jack/
<steev> calebccff: btw, do you have proper audio on your c630? it's not breaking up and such?
<Stirl[m]> does 6.4 boot properly or will you still need to use the archiso with 5.xx on it to get into a live environment
<steev> ?
svarbanov has joined #aarch64-laptops
<Stirl[m]> I am probably misunderstanding. I thought that clover's archiso that I have been using specifically had a 5.xx kernel on it because there was some regression in 6 that broke boot. Like when trying to install fedora arm, the computer would not boot into the live environment.
<calebccff> steev: i just get clicks and pops with pipewire. haven't had a chance to test yet but I'd bet on this wireplumber config fixing things: https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/community/soc-qcom-sdm845/51-qcom-sdm845.lua
<steev> calebccff: hm, that definitely does help and holy shit does that make it louder
<calebccff> lol, louder??
<steev> let me make a vidya
<calebccff> glad to hear it helps, need to give it a spin myself. do you have any other audio changes?
<steev> Nope, I just dropped that into the main.lua.d directory and rebooted
<steev> Lowering the volume to about 10% makes it… better but it’s still rather poppy, and the right speaker still doesn’t seem to output much
<calebccff> steev: made the mistake of playing back that video on my c630... oh lord
<steev> oh double lord, sorry
<steev> now i wonder
<calebccff> lol, no problem
<calebccff> the volume control is definitely hooked up wrong
<steev> the right speaker seems... off/quiet, aside from the occasional high squeak
<steev> hmm
<steev> actually, since that, i'm now getting a popping noise every so often
<steev> it's spamming q6asm-dai remoteproc-adsp:glink-edge:apr:service@7:dais: command[0x10bdb] not expecting rsp
svarbanov has quit [Ping timeout: 480 seconds]
chester_lin has quit [Ping timeout: 480 seconds]
<calebccff> steev: btw .local/state/wireplumber could be making test results unreliable, if you haven't dealt with that already heh
<calebccff> i still get stuck clicking sometimes, not sure why
<steev> do you see the above with the clicking?
<calebccff> yep, any idea what that error means?
<calebccff> also uh, delete the "PlaybackMixerElem "Speaker Digital"" line in /usr/share/alsa/ucm2/Qualcomm/sdm845/HiFi-MM1.conf and it'll use software volume control which works much better (and it loud enough i think)
<calebccff> steev: uhh nevermind
<calebccff> small chance i just killed these poor speakers :grimace:
<robclark> Stirl[m]: I think the boot issue with newer kernels was only about booting from usb (but not sure if that is resolved yet)
* calebccff needs to start cooking dinner, good luck
<robclark> HdkR: that looks more like your GMU ceased to exist
<HdkR> Just a small vacation until the next reboot
<clover[m]> <Stirl[m]> "I am probably misunderstanding..." <- Indeed
<clover[m]> Booting from USB has been broken since, 6.xx on x13s
<steev> inc spam
<steev> 6.4
<steev> * abelvesa's clk sync_state patch set
<steev> * johan's rc7 patch set
<steev> * lumag's dpu hdmi output support patch set (this may not be needed at all)
<steev> * krzk's GIC child node name patch set
<steev> * add wdk2023 to smmu platlist
<steev> * v4 of mani's no advertising pci hotplug
<steev> * konrad's icc bwmon dynamic thresholds
<steev> * konrad's idle state fixups
<steev> * konrad's add in missing gdsc's
<steev> * konrad's add in missing scm interconnect
<steev> * konrad's drop useless compatibles
<steev> * konrad's runtime pm for gcc and gpucc
<steev> * Fix some dwc3 qcom resources/error handling from christophe jaillet
<steev> * laptop defconfig updates to qseecom, add videocc/lpasscc corrections, and add in wwan and pm8008 options
<steev> * hack to generate the nvm name used for bluetooth
<steev> * make it hotter is back (set throttle threshold to skin_temp being 65C and not 55C)
<steev> none of these are really new, except konrad's stuff, but now i'm actually saying them
<krzk> steev: bisect. If you really suspect DTS, not some DWC USB etc, then bisect accepts path argument
<krzk> This could cut few steps...
<steev> krzk: hm?
<steev> oh, this is just announcing what i have applied on top of 6.4
<steev> if you mean the headphone jack not working.... i honestly have no idea where to begin looking
<krzk> ah, I thought you are referring to broken USB from clover[m]
<krzk> Sorry then
<steev> oh... no :)
<steev> at least, not yet, i haven't yet spun up a kali iso to start testing
<steev> my todo list jumps by leaps and bounds every day... like a new golang package bump requiring 29 new dependencies that aren't packaged
<HdkR> robclark: Fun enough I get that HFI error pretty frequently. This time was with `Total War: THREE KINGDOMS`
<HdkR> Previous time, `Police Stories`, Previous time `Mirror's Edge`, Previous time `Art of Rally`, Previous time `FEZ`. That's one that just never recovers
<konradybcio> on a7xx i had to add a "poll the gpu's memory controller ready bit" hack to ensure we don't spam the gmu before the memnoc hw is up.. but that cripples the performance badly
<HdkR> Sounds painful
<konradybcio> check if applying this makes these games playable (not fps-wise)
<steev> longbois lol
<HdkR> Could give it a try
<konradybcio> quite long ;)
<steev> i associate longbois with tallbois
Xyaon has joined #aarch64-laptops
<HdkR> konradybcio: Nope, didn't fix the issue
<bamse> krzk: wow, didn't know git bisect took a path argument, thanks!
agl7 has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
<robclark> oh, I didn't know about git-bisect taking path arg either.. that is pretty useful
svarbanov has quit [Ping timeout: 480 seconds]
agl7 has quit [Quit: bis denne]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
exeat has quit [Read error: Connection reset by peer]
Libre___ has quit [Read error: Connection reset by peer]
Libre___ has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
Lucanis0 has quit [Ping timeout: 480 seconds]