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.
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.
<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
<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...
<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.
<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>
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