robclark 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
hightower3 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
KhazAkar has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hightower2 has quit [Read error: Connection reset by peer]
hightower2 has joined #aarch64-laptops
hightower2 has quit [Read error: Connection reset by peer]
hightower3 has joined #aarch64-laptops
hightower3 has quit [Remote host closed the connection]
hightower3 has joined #aarch64-laptops
hightower3 has quit [Remote host closed the connection]
hightower3 has joined #aarch64-laptops
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
<enyalios>
so alsa-ucm-conf isnt safe with which kernels on x13s?
hightower2 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
bluerise has quit [Ping timeout: 480 seconds]
<steev>
that's gonna depend on backports
<steev>
but most distros that don't have those backports aren't gonna be having 1.2.11
<enyalios>
which kernels in your tree have the safety stuff
bluerise has joined #aarch64-laptops
<steev>
i *believe* 6.7.1 and higher
martiert has quit [Remote host closed the connection]
martiert has joined #aarch64-laptops
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
KREYREN_ has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<enyalios>
steev: cool, thanks
KREYREN_ has quit []
bluerise_ has joined #aarch64-laptops
bluerise- has joined #aarch64-laptops
bluerise has quit [Ping timeout: 480 seconds]
bluerise_ has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<dgilmore>
steev: fedora has built 1.2.11 for F38, 39, and rawhide.
<dgilmore>
I guess I should maybe test some patches and add Tested-By
<steev>
on x13s, just make sure the volume is turned down if the kernel support isn't there
jglathe has joined #aarch64-laptops
jglathe__ has joined #aarch64-laptops
jglathe_ has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<steev>
who has that pic of the 2280 in the thinkpad?
<Jasper[m]>
Me, but I'm going to work rn
<Jasper[m]>
Will send it when I get there
<steev>
thanks :D
* travmurav[m]
casually uses file upload search in matrix
* travmurav[m]
's first thought was to reply to that old message but then he remembered the original message won't actually get to irc
<steev>
some day i'll start using matrix. i have it, pretty sure i even have it in this room
<steev>
i just... don't like any of the clients
martin has joined #aarch64-laptops
martin is now known as Guest1060
<albsen[m]>
<travmurav[m]> "steev: https://oftc.irclog...." <- that works? :D
<albsen[m]>
looks like the person used a single sided nvme
<albsen[m]>
interesting, I had a 2240 available, so I used that, but those are slow and not that reliable from what I can tell, and you can get larger 2280 nvmes
<jhovold>
dgilmore: my audio fixes have been merged, just waiting for them to reach linus (and stable) now
mcbridematt has quit [Read error: Connection reset by peer]
<Jasper[m]>
Please don't
<_[m]123>
<steev> "i just... don't like any of..." <- search is b0rked at least for me mm I wouldn't advise it if you're in a lot of 5k+ rooms
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<jhovold>
dgilmore: any progress on tracking down the immediate wakeup from suspend you were seeing?
<jhovold>
was unloading ath11k sufficient to prevent this (i.e. no need to unload the modem driver)?
<jhovold>
odd that you seem to be the only one seeing this, so would be good to figure out if it's related to some configuration or AP compatibility issue in your setup
<dgilmore>
jhovold: not had a chance to dig into it more.
<jhovold>
dgilmore: ok, could you just try only unloading ath11k and see if that is sufficient to prevent the wakeup, so we have at least narrowed this down the wifi?
<dgilmore>
Sure, will do so today
<jhovold>
thanks
Caterpillar has quit [Quit: Konversation terminated!]
<ema>
hey, so I'm still trying to find out more about thermal throttling on the x13s. Assuming I'm looking in the right place, and please let me know if I'm not, it seems that on my device there's no throttling happening? If I look at /sys/class/thermal/cooling_device*/stats/time_in_state_ms all my cooling devices are constantly in state0, even though all cores are maxed out for a while and the laptop is
<ema>
running quite hot
<ema>
all cores are > 80C right now for example
<ema>
I also tried tracing the various thermal tracepoints with bpftrace, and the only one firing up is tracepoint:thermal:thermal_temperature
<dgilmore>
jhovold: it does not suspend with the ath11k module removed
<jhovold>
dgilmore: ok, thanks for testing, and if you only unload the modem driver?
<dgilmore>
will test after meetings
<Jasper[m]>
<ema> "all cores are > 80C right now..." <- Is debian carrying the make it hotter patch?
<ema>
we don't have that one, but from what I understand it should only be a 5 degrees difference (55 C vs 60 C) and I'm well beyond that
<travmurav[m]>
skin temp is not cpu but chassis I'd think though
<Jasper[m]>
travmurav[m]: Yes
<ema>
ah interesting
<Jasper[m]>
ema: Wasn't sure about the specifics either
<ema>
still, if anything without the patch I should see throttling happening *more* often :-)
<Jasper[m]>
But maybe probing those temp sensors may give some insight
<Jasper[m]>
(not sure what the throttling behaviour is connected to sensorwise, that may be a smarter first step)
<ema>
does anyone have time spent out of state0 in any of the files under /sys/class/thermal/cooling_device*/stats/time_in_state_ms ?
<exeat>
BTW, if the skin temp sensor is accurate (which it seemed to be when I measured the lower chassis temp), then 55C is already in the danger zone for a device used as an actual laptop ;)
<ema>
exeat: ah so what you're saying is that perhaps I'm not seeing any throttling because the system is just not hot enough
<ema>
as an experiment I suppose I could lower trip-point0's temperature in the dts and see if it's triggered
<Jasper[m]>
<ema> "as an experiment I suppose I..." <- Yes
<Jasper[m]>
Or just check what temp it reads ahahaha
<exeat>
ema: my comment was an observation that the skin temp sensor reading is real, and that the chassis does get hot enough to give blisters, and so you may not want to raise that threshold for all debian users
<ema>
exeat: definitely, if anything I think it may need to be lowered
<ema>
steev: you have CONFIG_QCOM_TSENS=y, I've got =m
<steev>
iirc, there's something that has to match up there, jglathe and i discussed it at some point and i haven't had a chance to figure out what the difference is (via email)
<ema>
steev: oh, I've got CONFIG_QCOM_LMH not set
<ema>
> LMh allows for hardware-enforced mitigation for cpus based on input from temperature and current sensors
<ema>
it also says "On many newer Qualcomm SoCs LMh is configured in the firmware and this feature need not be enabled" though
<steev>
i use the same config on multiple devices - the c630 uses it, afaik, the x13s does not
<ema>
CONFIG_QCOM_SPMI_ADC_TM5 seems useful too and I don't have it enabled, let's give it a try
kishkovert has quit [Quit: Leaving]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<steev>
i do see it loaded as a module here, but i'm not sure it's actually in use (tm5)
<jhovold>
adc_tm5 is definitely needed for thermal throttling
<steev>
ah :)
<steev>
ema: ^^ there we go
<steev>
poor ema been burning his fingertips off :(
hightower2 has joined #aarch64-laptops
<clover[m]>
ema ready to commit the perfect crime
<craftyguy>
so to commit the perfect crime, step 1 is to compile gcc? XD
<steev>
you gotta disable QCOM_SPMI_ADC_TM5 first
Guest621 is now known as qzed
<dgilmore>
jhovold: I removed "qrtr_mhi mhi_wwan_mbim mhi_wwan_ctrl mhi_pci_generic ath11k_pci ath11k mhi" and tried to suspend. It failed. Though I wonder if it is usb keeping it awake
<ema>
so essentially up till now I've enjoyed excellent performance at the risk of burning my knees. Thanks folks!
<steev>
ema: glad we got it sorted though - i need to, once i figure out why i'm gettin rcu stalls when enabling ipa, submit the c630 stuff at some point
<jglathe>
On X13s you don't have a fan, but I got it to crash when QCOM_TSENS wasn't present. Therefore, all three are needed.
<jglathe>
There's also a dependency on the ESP as created by Windows. The EFI partition needs to be mounted, or the thermal management on Volterra will go into emergency blasts only. And stay there until you start it with windows again and get the ESP "repaired" from the ACPI EC point of view. This might be an issue specific to Volterra, as it's very Microsoft-y
<Jasper[m]>
Wait what
<zdykstra>
what does Windows do to the ESP to 'repair' it ?
<Jasper[m]>
Better question is, what is happenig to the fan curve that it needs something on the ESP?
<jglathe>
I can't tell you, youst observation (and pulling some hair out). Maybe @qzed can shed some light on this
<Jasper[m]>
Don't think they're here under that username
<jglathe>
I was happy to debug it to the point where I can repair it with a boot to Windows instead of doing a complete recovery of the SSD with *lots* of PITA when you have Linux on the SSD, too
<jglathe>
he changed to it today?
<Jasper[m]>
Okay I looked around the linux-surface repo, it seems to be PEP thing on Windows
<Jasper[m]>
But they already are upstreaming a hwmon driver to make it work
<Jasper[m]>
Ah wait that's only monitoring
<Jasper[m]>
Fan control is in PR 145 on that repo
<jglathe>
yep, @qzed pointed me to it. I hope to get fan speed from it. If the other issue gets fixed by it, too, all the better
<qzed>
my current theory is: EC has some internal state that saves the fan curve
<qzed>
messing around with ESP somehow causes it to reset the state
<qzed>
booting into windows makes windows set the fan curve
<Jasper[m]>
Interesting
<qzed>
if you've got the base SAM/EC stuff set up, you can try to manually send commands to the EC
<Jasper[m]>
qzed: Oh so controlling the EC that controls the fan is possible?
<Jasper[m]>
I'm guessing the modes signify the aggressiveness of the fan ramp up?
<Jasper[m]>
(since they refer to the performance modes and not the fan speed itself)
<qzed>
with some caveats (like only on fairly recent generations)
<qzed>
ivor did some great testing for that, so yeah it looks like different fan profiles
<Jasper[m]>
Oh wow
<Jasper[m]>
So what are the caveats? Seems like it's fairly cut and dry
<qzed>
mostly that there's also another performance profile which I don't know what that does and how that affects things
<qzed>
that one is older and at least on my SB2 controls the fan for the discrete GPU (which is the only fan in that device)
<qzed>
so no idea how they play with each other
<qzed>
and ivor also mentioned that it might be possible to tune the curve somehow or set a manual one, but that doesn't seem to have worked so far
<qzed>
so for now you can basically switch between some profiles
<qzed>
(and unfortunately I can't test any of this myself because non of my devices support that interface...)
<qzed>
I assume right now that windows uses those fan profiles and some more dynamic CPU throttling (like what you can do with thermald) to keep things in check
jglathe has quit [Remote host closed the connection]
jglathe_x13s has quit [Remote host closed the connection]
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
Mathew has quit [Quit: Leaving]
mcbridematt has joined #aarch64-laptops
<zdykstra>
I'm working on bringing up Void Linux on the x13s. I've merged the aarch64 kernel config with the 6.7.y johan_defconfig - rebuilt 6.7.2 and attempted to boot it. I get to here: https://i.imgur.com/zQfpDWU.jpg then after a few seconds the screen blanks, and after a bit more the backlight turns off. What's a good place to start checking where I've messed up?
<zdykstra>
I have 'clk_ignore_unused pd_ignore_unused arm64.nopauth loglevel=7' set on my kcl
<Jasper[m]>
Are you using a setup with disk encryption?
<zdykstra>
Nope, going for super minimal off the bat. ext4 on a 64gb partition on the nvme
<zdykstra>
Ubuntu + ESP are on the same drive
<Jasper[m]>
hm, weird then
<zdykstra>
Grub (for now) should be loading the 6.7.2 dtb
<zdykstra>
what does the backlight turning off typically indicate?
anonjohn488 has joined #aarch64-laptops
<steev>
check what johan's defconfig commit says you need in the initramfs
anonjohn488 has quit [Quit: Leaving]
<zdykstra>
ahh, thank you for the tip steev
<steev>
i *think* bamse said that its sorted in 6.8rc but my memory sucks ass
* zdykstra
cross-compiles a new kernel
<dgilmore>
jhovold: I suspended while logged in via ssh, the session was not active so some things suspended. the keyboard backlight still stayed on, the screen turned off. It fully work up just by touching the touchpad, which afaik should not be a wakup device