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: 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>
* 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