ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
ellyq_ has joined #aarch64-laptops
ellyq_ has quit []
ellyq has quit [Ping timeout: 480 seconds]
<enyalios>
steev: ooh, the webcam stuff is going to make it into 6.11? thats exciting
eac has joined #aarch64-laptops
<dgilmore>
I think the dtb changes for the camera is the main thing missing in 6.11
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jiegec>
Thanks for all the upstreaming effort of bringing Surface Laptop 7 support to mainline kernel, hopefully we can use unmodified Linux 6.12 kernel on it
<kuruczgy[m]>
I seem to have found a workaround for my screen resume issue. I figured out that the resume failure is caused by the writeback conenctor (`dpu_writeback.c`).
<kuruczgy[m]>
robclark: What `drm.debug` bits should I turn on for the log? Any other debug flags that I should enable? What other info should I include?
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<robclark>
kuruczgy[m]: don't worry about a log initially, if the display team needs one they can ask
<kuruczgy[m]>
lumag: Ah, I will try the patch, thanks!
<kuruczgy[m]>
Do you still want me to file the issue? I guess in this case not.
<robclark>
try the patch first
<kuruczgy[m]>
robclark, lumag: the patch seems to be working, the screen resumes properly and the error message is gone
<robclark>
\o/
<lumag>
kuruczgy[m], would you be able to respond to that email (you can download the mbox from lore.kernel.org and import into your email client)
<kuruczgy[m]>
lumag: I can try
<lumag>
kuruczgy[m], please try. I'd appreciate Tested-by and some details of the issue you have faced.
<hogliux>
Hi everyone here. I created an IRC account today specifically to thank everyone on here (but specifically kuruczgy and jhovold) for doing such great work in bringing linux to the Snapdragon Elite X. I bought a new Lenovo Yoga Slim 7x and it's now running Ubuntu 22.04 almost flawlessly!! USB, GPU acceleration, trackpad, touchpad, keyboard, WiFi everything is working super good. Thank you so much for all your
<hogliux>
work!!!
<hogliux>
Oh yes, brightness control and battery indicator is also working great for me!
<robclark>
\o/
<kuruczgy[m]>
lumag: I am still a noob when it comes to the email based workflow, could you please double check that this looks correct before I send it?
<hogliux>
Yeah suspend/resume doesn't work for me. Also hibernation doesn't work
<kuruczgy[m]>
hogliux: Yes, that's also my repo, I think I already posted it here a couple times.
<hogliux>
When I try to suspend I see `psci: CPU1 killed (polled 4 ms)` kernel messages how it's stoping all the CPUs, but immiedetely resumes them again 'Enabling non-boot CPUs ...'. It seems like it never tells the hardware to actually go to sleep. It's strange. I don't see any obvious errors. From the logs, it looks like I immiedetely woke up the machine again.
<hogliux>
kuruczgy[m]: I basically just followed your nix scripts manually to get the right kernel version (with patches) and to build the correct initrd.gz. It also helped figure out that I needed pd-mapper for the battery indicator.
<hogliux>
I basically like a human computer following your nix scripts to the dot, but then used debootstrap to install Ubuntu instead of nix
<kuruczgy[m]>
> I basically like a human computer following your nix scripts to the dot
<kuruczgy[m]>
Ah nice, tbh most non-nix users find reading nix code difficult, I didn't think it would be useful for any non-NixOS users, I am glad it helped.
<hogliux>
> Yes, I was thinking the same, but from all I can tell, the clock just stops, the machine really does go to sleep.
<hogliux>
Hmm if I look at my kernel messages https://pastebin.com/cBsBYs1N and the point it goes to sleep according to the logs (i put in a bunch of ============= where I think that is), no time went by between sleep and wake-up
<hogliux>
Both show "Aug 30 11:30:26" but I waited at least 5 minutes before I pushed any button
<hogliux>
Is it because there is no RTC clock and it needs to sync the time first so it thinks the wake-up was right away?
<hogliux>
Also when I wake-up from hibernation, it loads the state from swap succesfully, but then hard-reboots just after 100% restore
<hogliux>
I think I need to unload some modules to make hibernation work. Because it does work if I hibernate early in the boot process when only the initramfs modules had loaded (basically just keyboard and nvme)
<hogliux>
Also do you know where I can get X1E80100-LENOVO-Yoga-Slim7x-tplg.bin from to get sound working?
<hogliux>
And did you have any luck with the webcam?
<kuruczgy[m]>
Well I have something even weirder for you regarding sleep, I added the attached patch to print the elapsed time during sleep, and the deepest one (which is actually called in a place where the driver is suspended, so you are not supposed to call ktime_get) reports the correct elapsed real time (~10s), while none of the others do.
<steev>
please remember that matrix is bridged with irc, and using matrix only things look a bit odd on irc
<kuruczgy[m]>
steev: Yeah I am trying, I am checking how my messages look on IRC, there was one was cut off with a "(full message at ..." link, but all the others seem to look fine to me?
<kuruczgy[m]>
hogliux: Regarding sound and webcam: sound is not working, have not tried webcam yet.
<kuruczgy[m]>
My top priority right now is suspend/resume, I might even try to look into what's responsible for the excess power consumption during sleep if I can. I also want to figure out what's wrong with the lid switch and the power button LED.
<hogliux>
kuruczgy[m]: OK that's strange. So you could alternatively just use arm64's cntvct register. You can convert that to nanos via the cntfrq_el0 and then the result will be identical to CLOCK_MONOTONIC_RAW. The register continues counting in sleep
<hogliux>
Yeah don't care much about sound/webcam either. I also actually prefer hibernation over suspend.
<hogliux>
I think I'll get hibernation working soon. Just need to figure out which module is causing the issue.
<hogliux>
Interestingly, linux does detect the power button press on the side. Is the lid switch even in the dtb currently.
<hogliux>
?
<hogliux>
Maybe I just need to look at the ACPI tables again and see how the lid switch is actually routed
<hogliux>
Actually, I take that back what I just said: cntvct **does** actually stop counting during suspend
<hogliux>
So wouldn't really help here
<kuruczgy[m]>
AFAICT the prink timings are supposed to just be based on the cntvct registers, so it clearly is frozen during sleep. But you can try patching the kernel with that asm block to double check.
<kuruczgy[m]>
Though I wonder if this could perhaps be related to the EL1/EL2 booting difference? E.g. the virtualized timer might stop during suspend.
<hogliux>
No all the cntvct timers stop during suspend. I'm just reading the arm reference manual.
<kuruczgy[m]>
Regarding hibernation: I never use hibernation, so we are on the opposite sides here. But at least both will be well tested then :)
<kuruczgy[m]>
Could you perhaps link the exact spot where it says that? Just for future reference.
<hogliux>
Is there an RTC that llinux can use? I don't think so because I always see the wrong incorrect time in boot messages in early boot (just like on a rasp pi). Only when systemd-timesyncd runs does it update to the correct time. But if the network is the only source for linux to figure out how much time actually elapsed in sleep, I wouldn't expect anything to continue counting during sleep. This is really odd.
<kuruczgy[m]>
I already tested that, I disabled Wi-Fi, the RTC stays correct after suspend/resume, it does not get skewed by the amount of the sleep duration. So the RTC (whichever hardware component it is) does keep counting during sleep. (It does get lost on reboot though.)
mrkajetanp has joined #aarch64-laptops
<robclark>
IIRC someone mentioned that we need to apply some offset to the RTC.. so probably it is not lost on reboot, but that offset is
<steev>
probably similar to how we do it on x13s (at least until someone figures out the EC stuff for these machines)
<steev>
i *thought* there was a patch for that though
<travmurav[m]>
yeah qcom historically has read-only time on the rtc (unless you can run in EL3 and not lock it) so firmware just stores the offset and treats the actual rtc as a simple monotonic counter
<travmurav[m]>
I suspect that with the funny mailbox stuff we saw in acpi, it goes into PEP which applies the offset in the efivar, iirc this stuff was indeed implemented in linux at some point
<hogliux>
OK I was wrong again about the cntvct register. I misread the arm reference manual. Not sure if it's paused or not during suspend.
<travmurav[m]>
the pmic rtc that is
iivanov has quit [Remote host closed the connection]
<kuruczgy[m]>
"until someone figures out the EC stuff" what is known about the EC so far?
<kuruczgy[m]>
E.g. where is it implemented (EL3 or a coprocessor or a separate chip), and what does it control?
<hogliux>
Strange, I can't get the lenovo to sleep at all anymore. It just instantly wakes again without me pusing any buttons. It definitely worked this morning.
<travmurav[m]>
ec == embedded controller, a classical thing for x86 machines, a separate chip that does keyboard scanning + random funny features like leds on power button and few power management bits sometimes
<travmurav[m]>
on arm, especially on newer things it seems to do a bit less compared to older qcom and x86, i.e. doesn't handle charging anymroe it seems
<kuruczgy[m]>
Is the EC lenovo specific? If I understand correctly, at least for the keyboard, the EC is what we are talking hid-over-i2c to?
<kuruczgy[m]>
What other interfaces does it have? E.g. I don't understand how the power button works, for me Linux shuts down when I press the power button for ~1 sec, how does it detect that?
<travmurav[m]>
the ec as a concept is common, but implementation is vendor/board specific
<travmurav[m]>
there is usually one or few i2c (sometimes spi, uart) links to the AP yeah, one of which is hid-over-i2c indeed
<travmurav[m]>
depending on how it's wried, I'd guess the power button holding would result in ec also holding PON line of the pmic, which would make it kill the power
<kuruczgy>
I meant that Linux shuts down cleanly, not that power is cut. I guess the power cut case is for the ~10s hold
<travmurav[m]>
i.e. on aspire1 the ec has two dedicated i2c ports, one for hid keyboard and one for all other features like battery monitoring, lid sensor, type-c DP HPD...
<travmurav[m]>
I'd guess EC passes it straight to PON (which is accessible to linux as a button) or it's wired straight to PON, not touching the EC entirely
<travmurav[m]>
and the pmic has 7 (iirc) second long press in hardware which would cause a power kill
<travmurav[m]>
yeah seems like pon is enabled on x1e pmic
<hogliux>
kuruzgy: the power button is detected as a regular input on my machine: for it's at /sys/class/input/input7
<travmurav[m]>
but I think you're lucky and the ec doesn't do much on new things
<travmurav[m]>
i.e. afaik the boards are more sane than i.e. aspire1 and you get a simple gpio for the lid switch
<travmurav[m]>
and hpd is handled by soc as well since you have real multi-role ports on the soc side compared to the old 7c
<travmurav[m]>
battery is handled by the adsp firmware as well (whether it's a good idea or not)
<kuruczgy[m]>
hogliux: Yeah, if the power button is routed through the PMIC as an input device then it makes sense that it works.
<kuruczgy[m]>
But the lid switch is not in the device tree yet, right? I don't see it. So even if we are lucky and it's a gpio we still need to figure out which one.
<travmurav[m]>
it would've been trivial to know which things ec is responsible for if one had board schematics to refer to but I think those things are still too new to get them
<travmurav[m]>
which device are you referring to btw?
<kuruczgy[m]>
Yoga Slim 7x, that's the only one I own
<travmurav[m]>
tbh you can probably ssh into it, watch -n 0.1 cat /sys/kernel/debug/gpio and open/close the lid and see which gpio changes xD
<travmurav[m]>
there is a highlight changes param to watch but idr the flag
<kuruczgy[m]>
Seems like it. But I don't know anything about ACPI, so not sure how to parse this.
<kuruczgy[m]>
But maybe I should learn a bit about ACPI, seems like it might answer a lot of my hardware questions.
iivanov has joined #aarch64-laptops
<hogliux>
A few years back I reverse engineered a tiny section to get battery information working correctly on an old Dell laptop
<hogliux>
It was really painful
<travmurav[m]>
hm 0x340
<kuruczgy[m]>
travmurav: Regarding schematics & datasheets since you mentioned it, what's the usual timeline for their availability? My top 2 wishlist would be the X1E SoC datasheet, and the yoga schematics. But AFAIK qualcomm is pretty secretive with their datasheets, is there a chance of ever seeing these documents?
<travmurav[m]>
no idea, whenever some repair people get them leaked
<travmurav[m]>
if you're lucky
<travmurav[m]>
no datasheets for any qcom part ever to see the light of day
<travmurav[m]>
board schematics from oems may
<travmurav[m]>
I was pretty lucky with aspire1 so could work off from schematics
<kuruczgy[m]>
But I assume at least the Linaro people have access to the datasheet, under some hefty NDAs? At least I don't see how they would have developed all these drivers so quickly without it.
<travmurav[m]>
probably
<travmurav[m]>
<travmurav[m]> "hm 0x340" <- my guess: tlmm gpio 92
<travmurav[m]>
is your lid
iivanov has quit [Ping timeout: 480 seconds]
<steev>
travmurav[m]: out of curiosity, how does 0x340 become gpio 92? that was the one thing that always confused me
<kuruczgy[m]>
Okay, I will have dinner, then after that maybe try the gpio watch command you sent, and gpio 92 if that fails
<travmurav[m]>
I was burdened with knowledge of understanding how gpio numbers in acpi work, sadly
<travmurav[m]>
steev: I'd not put 100% confidence to it but magic number // 64 == interrupt number on GIO0 and then it can be traced back to a tlmm gpio via known-in-linux lookup/translation tables
<travmurav[m]>
like need to take 3 offsets
<travmurav[m]>
(if magic number <= amount of gpio lines, then the number == gpio and there is no interrupts)
<travmurav[m]>
kuruczgy: well theoretically the gpio watch command will show you the gpio92 changing when you close/open the lid
<travmurav[m]>
but also allegedly gpio handling on x1e is "even more messy" than on previous platforms
<travmurav[m]>
as allegedly oems can customize the qcgpio driver in windows in funny weird ways
<travmurav[m]>
s/as/and/
ellyq has joined #aarch64-laptops
<hogliux>
I tried `while true; do gpioget gpiochip0 92; sleep 1; done`: it doesn't change when I close the lid
<hogliux>
gpiochip0 is the only one that has 92 gpios
<hogliux>
but gpiochip0 is not connected to the pmic
<travmurav[m]>
sad, perhaps guessed wrong
<travmurav[m]>
but no, it would've been a soc pin
<travmurav[m]>
tlmm is soc
<travmurav[m]>
well "guessed", calculated
<travmurav[m]>
or the alleged mess is true
<travmurav[m]>
but a lot of things suggest that it /is/ tlmm gpio 92 in the yoga 7x acpi
<travmurav[m]>
I just saw there is another non-interrupt version of the same gpio which uses direct numbering and says 92
<hogliux>
Hmm I tried the following: while true; do cp /sys/kernel/debug/gpio ${I}; echo ${I}; I=`expr ${I} + 1`; sleep 5; done
<hogliux>
Which creates a copy of all the gpios every five seconds
<hogliux>
And then check the changes with diff
<hogliux>
I only got a change on gpiochip7 gpio 7
<travmurav[m]>
actually
<hogliux>
But it didn't go back when I opened the lid again
<travmurav[m]>
is gpio92 set to input even?
<travmurav[m]>
could you share the gpio92's line from the debugfs here?
<hogliux>
Yup: gpio92 : in high func0 2mA no pull
<travmurav[m]>
hm sounds correct
<travmurav[m]>
hm
<travmurav[m]>
this sounds correct indeed, sad
<travmurav[m]>
weird
<travmurav[m]>
does the screen backlight turn off when you close the lid? or I guess it's oled version?
<hogliux>
oled stays on
<hogliux>
also I tried the same ```while true; do cp /sys/kernel/debug/gpio ${I}; echo ${I}; I=`expr ${I} + 1`; sleep 5; done``` with the power button on the side
<travmurav[m]>
right I guess oled wont' ahve a dedicated bl enable line
<hogliux>
And that didn't work
<hogliux>
So maybe my one liner is incorrect
<travmurav[m]>
power button PON line is not gpio
<hogliux>
OK
<travmurav[m]>
but a dedicated "button" device in the pmic
<travmurav[m]>
since it handles the long press too
<travmurav[m]>
in hardware that is
<hogliux>
i'm wondering if it's edge triggered and immeditely goes back to the original value
<hogliux>
Then doing ````while true; do gpioget gpiochip0 92; sleep 1; done``` would never detect it
<travmurav[m]>
the hall sensor is usually just on/off switch
<travmurav[m]>
so i.e. yes magnet, no magnet
<hogliux>
Maybe it needs to be enabled by ec somehow
<travmurav[m]>
not impossible sadly
<hogliux>
So gpio is wired up but the hall sensor is disabled
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
I also went through the output of watch -n 0.1 cat /sys/kernel/debug/gpio as suggested, but unfortunately cannot find any GPIO that would correlate with the lid state :/
<steev>
jhovold: something i noticed, in the sc8280xp dtsi, the pmu interrupts are IRQ_TYPE_LEVEL_HIGH and it seems like every other board is LOW - is the sc8280xp really the odd one out?
mjeanson has quit [Remote host closed the connection]
mjeanson has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<konradybcio>
kuruczgy: note that without the pdc fix no interrutps will ever fire..