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)
systwi has quit [Ping timeout: 480 seconds]
<bluerise> steev: yeah, yeah...
<bluerise> and a lot of stuff is hardcoded in windows drivers
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
pbsds0 has quit []
pbsds0 has joined #aarch64-laptops
pbsds0 has quit []
pbsds0 has joined #aarch64-laptops
SSJ_GZ has quit [Ping timeout: 480 seconds]
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
<steev> i've no idea what this thing is doing
<steev> it just sits there at nvme for a while... and then the screen turns off
<steev> definitely not booted though because the remote procs aren't up - unplugging and plugging it back in doesn't give me the 3 blinking lights
derzahl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
derzahl has joined #aarch64-laptops
aceridus has quit [Quit: Page closed]
derzahl has quit [Ping timeout: 480 seconds]
<jhovold> steev: very odd, haven't noticed any issues with -next here since I rebased.
<ndec> bluerise: do you have a link to the patchset for the RTC?
<ndec> or a link to a dev branch
<jhovold> steev: is that with further patches on top of my branch btw?
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
malvi[m]1 has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
ndec is now known as ndec-thelounge
ndec-thelounge is now known as ndec
miracolix has quit []
krzk has quit [Quit: leaving]
krzk has joined #aarch64-laptops
krzk has quit []
krzk has joined #aarch64-laptops
krzk is now known as Guest2101
Guest2101 has quit []
krzk3 has joined #aarch64-laptops
krzk3 is now known as krzk
matthias_bgg has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
<jhovold> steev: I guess you don't reach the point were you could change thermal trip points through sysfs, but if you do you'd hit a deadlock due to regressions in the thermal subsystem.
<jhovold> The changes had not been included in linux-next until this week and the morning I rebased by next branch so that I could share it with you.
echanude has joined #aarch64-laptops
laine has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<steev> jhovold: no, it's your branch entirely, with kernel config
<jhovold> steev: and it locks up in the same way on every boot?
iivanov has quit [Quit: Leaving...]
<jhovold> steev: do you have everything needed in your initramfs? pcie-qcom, nvme, phy drivers etc? Perhaps you used to rely on something being compiled in when using te laptop_defconfig?
<jhovold> what exactly does it it say when it appears to be waiting for the nvme?
<steev> It doesn’t seem to be waiting, but I may not be having everything in it - I’ll look closer later
<steev> There’s no error message at all, as far as I could tell, it just sorta, sits there for a bit and then the display turns off
<jhovold> steev: what's the last message on the console?
<jhovold> the backlight regulator may be disabled before the kernel gives up on waiting for the rootfs deps
<jhovold> do you see any messages from when probing the pcie buses at all?
<init> steev I had this exact same behavior days ago when I tried to take one of the provided def config , I had to revert back to my working rc7 one. Not saying it's exactly our problem, but if you have a working config on a previous version, maybe just try it.
<init> I have yet to figure out what was the difference that made it behave like that
<rfs613> anybody else find themselves trying to plug the USB-C charger into the kensington lock connector?
miracolix has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<init> rfs613: haha. I can understand. I've been living with a x390 for a while now with the same port/power configuration, but I definitely had this issue for a while.
<init> jhovold: does your own github branch for -next20221213 contains the thermal related patches?
<init> ill try to help and build two clean version, one with your own defconfig and one with my working rc8. to see if there's a minor difference
echanude_ has joined #aarch64-laptops
echanude has quit [Ping timeout: 480 seconds]
<jhovold> init: it does now
<init> thx, ill fetch it right now and start a build
<jhovold> init: my guess is that it's just one of the nvme deps that are missing in your initramfs (e.g. nvme, phy_qcom_qmp_pcie or pcie_qcom)
<steev> it says something like nvme 0000->0002
<jhovold> steev: ok, guess I guessed wronged then...
<init> might be, like I said, I don't have steev's problem, but I had them a while ago. Ill try to help by figuring out why, and in the meanwhile, build a new kernel for fun.
<steev> nvme 0002:01:00.0: enabling device (0000 -> 0002)
<jhovold> you should have: nvme nvme0: allocated 64 MiB host memory buffer.
<jhovold> after that
<steev> i do not, it sits there for about 15-20 seconds and then display goes off
<steev> i'll check my initramfs
<steev> oh, let me pull in your latest
<steev> nvme is in there as well
<jhovold> yeah, it was missing in the link you sent
<steev> yeah i missed that in my copying, i'd checked for pcie, then nvme, and then qcom, and the things mentioned in the commit message are definitely there
<steev> i'm using johan_defconfig and just doing make bindeb-pkg and installing the resulting deb
<steev> https://paste.debian.net/1264049/ latest build before i boot into it
<jhovold> steev: it seems something goes awry when initialising the nvme. I'm running the exact same config and kernel here now and still can't reproduce it, though.
<steev> with the latest, the display goes off much faster
<steev> i do not have a wwan card, could that be the difference?
<jhovold> I don't have the modem either
<jhovold> steev: can you try marking the two edp regulators as always-on in DT and see if you get some error message after a timeout?
<jhovold> that's: vreg_edp_3p3 and vreg_edp_bl (regulator-always-on;)
<steev> sure
<steev> wtf
<steev> that makes it go poof even faster?
<steev> i do notice in the video playback... we're trying to start at like 200mhz?
<steev> CPU0 running at unlinisted initial frequency: 200mhz, changing to 300mhz
<jhovold> so still no backlight? can you disable the backlight node as well?
<steev> no, the backlight is on
<steev> the display isn't
<steev> e.g. it's just a bright black screen
<jhovold> we need to figure out how to have a working display in the initramfs...
<steev> The best I can come up with for final messages befor the text goes away and it’s just backlight
<steev> for that, don't we just allyesconfig? :P
<jhovold> heh, yeah, that may work
echanude_ has quit [Ping timeout: 480 seconds]
<jhovold> steev: can you try using the big hammer and just comment out regulator_init_complete initcall regulator core?
<jhovold> /late_initcall_sync(regulator_init_complete);
matthias_bgg has quit [Ping timeout: 480 seconds]
<steev> I’ll try that hammer once the allyesconfig finishes in a few hours
<steev> Gives me time to get some work done
<jhovold> heh, sounds good. I'll call it a day soon too
echanude_ has joined #aarch64-laptops
<steev> Just for curiosity, do you have a 21BX, or a 21BY?
<jhovold> 21BY
<steev> i know srinik has a 21BY and audio works fine for him, but those of us with a 21BX it doesn't
<jhovold> steev: just compile in DRM_MSM so that it doesn't mess up the framebuffer (CONFIG_DRM_MSM=y)
<jhovold> works fine here without any regulator hacks (booting with init=/bin/sh)
<steev> DRM_MSM is y already with your config
<jhovold> getting tired, meant =m
<jhovold> or just revert my 8a1a3bb9a3f3 ("johan_defconfig: compile in DRM")
<steev> i made the swap will build that instead of allyes
<steev> and give it a whirl
echanude_ is now known as echanude
<jhovold> steev: you may still need to mark the edp regs are always-on...
<steev> if just makign it m doesn't help, i'll make that swap too
<steev> okay, not building in msm does help, at least a little bit
<steev> eventually it does seem to disable so will try the regs on
<steev> but essentially what i see here is that nvme messageg i mentioned, and then the initramfs say that local-bottom done
<jhovold> try marking the regs always on as well in case something shows up after 30s
<steev> yeah, that's the plan :)
aceridus has joined #aarch64-laptops
<init> best I can still do is -j2 before the thing becomes so hot i'm sure it'll melt.
<init> but it's building
<steev> um... with reg always on... the screen goes blank
<steev> init: are you not using the 6.1.0? thermals should be fine with it
<jhovold> what...
<steev> yeah
<init> i'm on 6.1-rc8 for now. but make -j8 brings it to a point where it's so hot i can't touch the plastic anymore for a long time.
<init> trip points are way too high
<steev> that... doesn't seem right, the trip points were too low imo - they're set to like 55
init-x13s has joined #aarch64-laptops
<steev> jhovold: my command line is root=uuid=<uuid> ro pd_ignore_unused clk_ignore_unused net.ifnames=0 verbose video=efifb earlycon=efifb
<steev> which rc8 are you on?
<init> a mix of yours and some other patches
<init> so for now, ill just stick to -j2 and see what I get on jhovold's next.
<jhovold> init: do you have all the thermal options enabled?
<steev> actually i don't think the thermal stuff was in my rc8
<init> not worth figuring out for now, as i'm adopting a fresh new config on a fresh new version. but if it's still the same after it, ill try to figure out what's hapenning.
<init> -j2 keeps it around 56, max 60. so it's alright.
<init> this log is in the middle of the build, won't get hotter.
<init> is there anything I should update in the boot config with that version? I'm still booting with a fairly large kernel parameter list.
<init-x13s> options dtb=/sc8280xp-lenovo-thinkpad-x13s.dtb efi=novamap,noruntime luks.name=84f0aeb9-3f83-446d-9474-e9b8aedacb1d=root root=/dev/mapper/root clk_ignore_unused pd_ignore_unused net.ifnames=0
<steev> gonna large hammer it and disable the regulator initcall
echanude has quit [Ping timeout: 480 seconds]
<steev> that isn't a large amount, i don't use the efi=novamap,noruntime here at all
<steev> but other than that, it looks like what mine does
<init> it's a leftover from 6.0-rcX
<steev> which thermal patches are you using? i don't show those at all - you have an older patchset
<steev> skin_temp is the important one, and is what is considered the laptop's external temp
<jhovold> steev: big hammer seems to work, wasn't needed on the CRD. seems we have more issue in -next...
<init> steev: at this point, nevermind, i'm in the process of aligning myself to the latest available kernel from jhovold git.
<init> as long as I don't melt it, i'm fine.
<steev> just put a fan on it ;)
<steev> jhovold: it... doesn't here?
<steev> that's assuming i even commented out the correct thing in core.c, which was the last line
<jhovold> right
<init> steev: in fact I did! My diy soldering fume extractor has a very directional fan exhaust due to it's diy nature. it works perfectly. https://imgur.com/a/jkTDaDD
<steev> hah
<steev> it worked that one time.. .and not since
<steev> well, worked as in, showed the initramfs local-bottom line a few times
<jhovold> gonna have to call it a day. will take another look fresh eyes tomorrow.
<steev> no worries, appreciate the pointers - maybe someone at linaro could poke people at lenovo about possibly getting you guys some 21BX's ?
<jhovold> heh, yeah, a modem too would be nice. ;)
init-x13s has quit [Remote host closed the connection]
<init> alright
<jhovold> steev: bah, i just realised what's different from crd. you need to mark also vreg_l6b as always on
<init> building on a fresh clone of jhovold next, with jhovold defconfig. I get the same behaviour as steev
<init> boots to a dark screen
<init> nothing changed from my working rc8 build system.
<init> on a 21BX
<jhovold> but the big hammer should still work, even better to just do:
<jhovold> - if (have_full_constraints()) {
<jhovold> + if (false && have_full_constraints()) {
<jhovold> in regulator_late_cleanup()
<jhovold> big hammer deluxe
<init> will try
<jhovold> mark both l3b and l6b as always-on
<jhovold> for the phy
<jhovold> or use the above (if (false &&...
<init> wait, i might be slighly less used to that. for l3b and l6b is it in the dtb or in the code
<jhovold> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
<jhovold> vreg_edp_bl, vreg_misc_3p3, vreg_l3b, vreg_l6b: add regulator-always-on;
<jhovold> or edit regulator_late_cleanup() so that it never powers of any seemingly unused regulators
echanude has joined #aarch64-laptops
<init> ill go the regulator-always-on route so I can figure out which one's causing the issue
<jhovold> init: all are needed for display in initramfs
<init> editing..
<jhovold> init: but you must also compile DRM_MSM as a module I think
<init> one problem at the time
<init> haha
<steev> jhovold: to be clear.. add regulator-always-on? don't jus tchange regulator-boot-on to regulator-always-on?
<steev> alright, one final attempt before getting back to work
<init> I added the regulator-always-on, it's not helping for now. but I might have a clue.
<steev> i did the reg a o and the deluxe hammer and it still goes off
<init> same here, i will try something and report.
<steev> sure, i need to continue hunting down things that don't wanna be found elsewhere
<init> ill start with the lazy path, just building with my working rc8 config.
derzahl has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
solsTiCe has joined #aarch64-laptops
solsTiCe has left #aarch64-laptops [#aarch64-laptops]
<jhovold> steev: yes, adding always-on and keeping boot-on should be fine
<broonie> always-on means what it sounds like. boot-on is for use with regulators where it's not possible to read the initial state from hardware.
miracolix has quit [Remote host closed the connection]
<steev> This is what I get with always on, and the big deluxe hammer - notice at the end that the display is flickering
<steev> no
<steev> that's just the big deluxe hammer, but boot on, i had reverted the always-on changes, let me add those back again
<steev> okay, so, regulators always on, the false, the late init call timed out, drm_msm=m and we get... kernel command line is verbose rootwait earlycon=efifb video=efifb boot_delay=300
<steev> gonna try, for giggles, going back to msm built in
derzahl has quit [Ping timeout: 480 seconds]
<steev> Ayy, it is the nvme
<steev> and it's true... i only have /dev/nvme0, i do not have /dev/nvme0n1*
<steev> A picture since irc cloud compresses the shit out of the video and it’s unreadable
SSJ_GZ has quit [Ping timeout: 480 seconds]
echanude has quit [Ping timeout: 480 seconds]
<HdkR> huh, nvme problems?
<steev> they probably changed some kernel config things around, again
<steev> alksjdf;laksjdfl;aksjdf;laksjdf;laksjdf
<steev> only changes was turning on some options under nvme and it's back to turning off the display
<steev> but, it's okay, i'm an idiot and had my phone set to photo not video, so i didn't even record it
<steev> i give up, this is bullshit
mcbridematt has joined #aarch64-laptops