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)
<steev> i blame ubuntu
<HdkR> lol
<HdkR> steev: Can I modify the DT in some way to disable it for now?
<HdkR> Just to make sure it isn't causing some of my problems
<HdkR> Comment out swr{0,1,2} and sound maybe?
<steev> disable sound
<steev> status=disabled instead of status=okay
<HdkR> Looks like it doesn't have a `status=okay` in the sound block
<HdkR> Only in the swr blocks
<steev> tbh, i'd rather figure out why you're getting that
<steev> what's with the + at the end?
<steev> 6.2.0-rc7-next-20230210+
<HdkR> Dunno, git diff doesn't show changes
<steev> i'm guessing that happened when you plugged in headphones?
<HdkR> Oh maybe
<steev> which headphones do you use? you said you have nice ones, and i'll likely not be able to afford them, but i'd like some ideas since, as mentioned, i only have the apple ones
<HdkR> I use AKG K712 headphones
<HdkR> open-backed super flat response curve
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
leezu has joined #aarch64-laptops
<HdkR> Very interesting that the gigabit ethernet over USB can only hit around 41MB/s with the DMA-FQ thing. Definitely still quite a bit of overhead with those softirqs
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
mjeanson_ has joined #aarch64-laptops
mjeanson has quit [Remote host closed the connection]
mjeanson_ is now known as mjeanson
matthias_bgg has joined #aarch64-laptops
<jhovold> or anyone using 6.2 for the X13s (linux-next seems to be in a pretty bad shape), here's an updated branch based on rc8:
<jhovold> Changes include:
<jhovold> - updated patches
<jhovold> - pmic glink v4 (merged)
<jhovold> - pmic glink battery v5
<jhovold> - sbu mux v2
<jhovold> - external display v4
<jhovold> - irqdomain fixes v6 (merged)
<jhovold> - new
<jhovold> - asoc fixes (merged)
<jhovold> - update thermal vadc channel names
<jhovold> - not included
<jhovold> - gpu support due to unresolved runtime PM issue (and missing external deps)
<jhovold> - audio still has issues and is left disabled in johan_defconfig
<ardb> jhovold: i suspect we need to do something for gsmi so it can register its efivar ops even if the generic ones have already been registered
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
javierm has quit [Quit: leaving]
javierm has joined #aarch64-laptops
<jhovold> ardb: ah, so the EFI calls does not return EFI_UNSUPPORTED on those platforms?
<ardb> jhovold: probably not but we cannot assume that
<ardb> that behavior is a fairly recent addition to the spec (along with the RT_PROP table)
<jhovold> ok, I thought returning EFI_UNSUPPORTED had always been there and it was just the RT_PROP table that was the recent addition
<jhovold> as long as all custom efivars implementation register after subsys_init() we can always revert f80f668ed1e7 ("efi: efivars: prevent double registration") to restore the old behaviour
<jhovold> but perhaps that can wait until we know if there really is a problem with keeping it in
<jhovold> or we can add an interface for deregistering the default ops that only gsmi use
<jhovold> i think one of the tee series I have only had time to skip had something along those lines
<jhovold> s/skip/skim/
srinik has quit [Read error: Connection reset by peer]
Cyrinux9 has quit []
srinik has joined #aarch64-laptops
<ardb> yeah i should check internally
Cyrinux9 has joined #aarch64-laptops
<apalos> ardb: Kojima-san's patches export the generic register/unregister machinery
<apalos> So you can just use that. Pick that patch (if needed) until he cleans ups the rest of the op-tee plumbing code
<steev> jhovold: fwiw, i pushed out a 20230210 based tree on sunday, based on your previous wip tree, seems 20220207 and 10 are "fine" but 13 is broken somehow (something about el0, it dies pretty quickly), the only thing i don't think i have is irqdomain fixes v6 possibly (is that interconnect stuff?)
<jhovold> steev: I've rebased on next a couple of times these last two weeks and run into problems both times. One hang during reboot in particular which makes it pretty unusable for me. With 20230213 I also got a bunch of new device link errors.
<jhovold> the irqdomain fixes is separate from the interconnect ones. The former is needed when having both touch
<steev> that started with 0210 - seems to be during cyclic.... fixups?
<steev> i can't think of the word
<steev> cyclic dependencies
<jhovold> touchpads enabled in DT, the latter prevents cpufreq from breaking occasionally.
<jhovold> yes, it looked like something like that.
<steev> doesn't seem to be *broken* just spammy
<jhovold> sure it may fall back to the good old probe deferral, but some device links appeared to be broken
<jhovold> no idea why
<jhovold> but it's mostly the new hang during shutdown that's been there for two weeks, but which I don't have time to investigate right now
<jhovold> has apparently been seen on other qcom platforms as well so hoping someone else can get it sorted
<steev> hm, i haven't seen that here at all
<steev> fwiw, this is my 0210 next branch
<jhovold> interesting, perhaps some interaction with user space (or config) then
<jhovold> been there since next-20230131 at least
<steev> i'm on a debian testing user space, and i use the laptop_defconfig
<steev> gnome 43, mesa is git with rob's 2 patches for gpu on top
<steev> Xorg, not Wayland, because of the mutter crash
<steev> (When using external monitor)
<jhovold> arch and johan_defconfig here, happens also without X started
<steev> I’ll check out your config and see if I see the same thing
<jhovold> and seen on some other qcom platform as well (rb5?), possibly running arch, not sure
<steev> I see a crash on next with the c630 with suspend, but I don’t recall issues with it rebooting
<steev> Not sure what crashes exactly, because there’s nothing in the logs, it just doesn’t resume
<steev> I think… I also have mani’s suspend/resume for pcie, I don’t think that has been submitted yet
<jhovold> yeah, that broke resume on my crd. Not necessarily related, but you can always try reverting that one
<steev> Can do
matthias_bgg has quit [Remote host closed the connection]
mjeanson_ has joined #aarch64-laptops
mjeanson has quit [Remote host closed the connection]
<steev> i have bluetooth for 6.2 around here somewhere since brian's patches won't be in til 6.2
<steev> in til 6.3*
mjeanson_ is now known as mjeanson
<steev> jhovold: since i suck at git, how did you create that emtpy commit for --- lisnux-next ---
<javierm> steev: git commit --allow-empty -m "--- foobar ---" ?
<steev> oh.. silly me
<javierm> steev: it's a nice trick to use commits as markers
<steev> si, i want to do that for the various patches that i have that aren't submitted since ajhalaney[m] likes to look through my stuff and follow them along, for when i am slacking and not following revisions
<javierm> steev: cool
<steev> i always saw... who was it.. jhugo do it in his trees and never thought to ask him
<jhovold> hmmm, has the power consumption gone down dramatically or is something broken with the latest pmic battery driver? :)
<jhovold> 100% charge after 45 minutes or so on battery
<steev> power consumption should have gone down
<jhovold> not that much though :)
* ajhalaney[m] might also have seen ramdump on shutdown pre-PTO on sa8540p-ride with -next + devel patches (which he blamed possibly on devel patches possibly on -next) fwiw jhovold
<ajhalaney[m]> I'll run a clean tree and reboot some later today and see if that happens still
<jhovold> energy_now doesn't seem to change at all, while other values like power_now are updated
<jhovold> bamse, have you seen anything like that before?
<jhovold> thanks, ajhalaney[m]. That makes us three that have seen this then possibly. Happened on every shutdown here though.
<bamse> jhovold: are you asking if i've ever seen it charge that fast? or if i've seen cases where only some values of the power_supply is updated?
<jhovold> i have an uptime of 1h10min now and energy_now is still reported as equal energy_full
<jhovold> oh, now it dropped to 99%
<steev> jhovold: fwiw, here charge_now just shows "no data available" - i recall a comment about it, but afaik, bamse said that charge_now wasn't exposed by the firmware
<jhovold> bamse: both energy_now and energy_full where updates to lower values, and now the former is sligtly smaller than the latter
<jhovold> so should probably blame it on the battery rather than driver
<steev> johan has the magic battery
<steev> pretty sure that means you get to visit qualcomm's factory and then they give it to you after the tour
<jhovold> heh
<bamse> steev: but your comment was about sm8350(?)
<bamse> jhovold: iirc those values are straight off what the firmware gives me...
<steev> i don't have an sm8350, afaik
<bamse> jhovold: i'd love for you to only have lost 1% in >1h :)
<steev> i too would like that to be true
<bamse> steev: no, but the patch has all three...and they differ
<steev> oh
<bamse> jhovold: that said, my battery is currently at 103%
<steev> i missed that part
<jhovold> energy_now/power_now ~= 11.3 hours currently
<steev> the forbidden capri sun
<jhovold> so things have improved
<bamse> doesn't sounds like an improvement to me ;)
<jhovold> what do you get then?
<jhovold> I think I've seen 7-8 h before
alfredo has joined #aarch64-laptops
<bamse> i added "time left" to my i3status a few days i do recognize the desire to revisit this...
<steev> i see 6 1/3 hours at 100% :(
<bamse> now that i disconnected my cable, i got 7h50, then 2h30 and now it settled at 21h00
<jhovold> what?!
<bamse> dancing around 21h00-21h20 now
<bamse> jhovold: it likes me better...
<steev> in b4 is our garbage wifi wasting all our power
<jhovold> bamse: so it seems
<jhovold> and you run waylan, me x
<steev> have we tried saying pretty please to kalle?
<bamse> connected the cable, now it says that it will take 14h to recharge the power i lost during those 2 minutes of testing
<bamse> steev: didn't i complain that i3status just made up numbers in it's calculation before?
<jhovold> heh
<steev> probably
<steev> i use waybar for that reason
<jhovold> i do my own math, from sysfs
<jhovold> perhaps that's why
<steev> at least, in sway
<steev> at the moment i'm in gnome
<steev> and gnome says 6 hours 45 minutes
<steev> i do have external monitor plugged in too though, and Xorg
<steev> i had bluetooth on too (but nothing connected)
<steev> am not looking too much into power usage just yet
<steev> but turning off bluetooth for me jumped up to 7 hours remaining
<jhovold> steev, bamse: what does cat /sys/class/power_supply/qcom-battmgr-bat/power_now say?
<steev> -6571000
<jhovold> -4453000
<jhovold> wonder if bamse really has half of that, or if it's due to i3 math
<steev> i'm in gnome on wayland now
<jhovold> xorg, with gpu
<steev> i hav egpu too yeah
<steev> have gpu*
<steev> not using egpu
<HdkR> Snapdragon, now with thunderbolt and eGPU support :P
<jhovold> bamse: plugged in the cable and the charge went to 100% instantly, something's not right
<steev> i've seen it occasionally jump to 100% as soon as i've plugged it in, but then drop back down a little later
<steev> jhovold: your kernel and config, i just get a blinky cursor
<steev> oh, this is X not starting
<steev> oh right, you don't include gpu
GuildedThorn has quit [Read error: Connection reset by peer]
mjeanson has quit [Remote host closed the connection]
mjeanson has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<steev> bamse: this is what i see in -next for the last while - - seems to be easiest produced by simply compiling a kernel
<steev> actually, when that occurs, is the only time it takes forever to reboot
<bamse> steev: that certainly looks like a generic issue
<bamse> jhovold: my power_now started off at -4256000, then i stopped spotify that was playing in the background (into the pulseaudio dummy device, because i had disconnected my headset)...and it jumped to -5100000 (i.e. the wrong direction...)
<bamse> jhovold: and with power_now of -4181000 i3status claims i have 1h39 minutes left on my battery
<bamse> and now i3status settled at 23h17m again...without any noticable change in power_now
<bamse> steev: seems more likely that i3status relies on some property that we don't report...
<steev> that could very well be
<steev> waybar, afaik, just uses upower
<bamse> but waybar is the bar at the top of the screen right? so not a status replacement?
<steev> no, it's at the bottom
<steev> well, it's wherever you want it to be
<bamse> hmm, maybe i failed at integrating it with my sway then
<bamse> omg, 19 dependencies
<steev> someone didn't get the 1TB storage :P
<steev> (I definitely didn’t)
<bamse> i think i did...
<bamse> i don't have a time to empty in waybar
<bamse> ahh, because my waybar config is no good
<ajhalaney[m]> jhovold: regarding poweroff/reboot hanging, next-20230213 is doing that consistently for me (no ramdump, i think that was me messing something up on an older -next)
<bamse> no that's not does report the percentage...but no time to empty
<steev> ajhalaney[m]: how are you getting it to boot? i get an el0 panic *really* early in boot
<ajhalaney[m]> steev: this is with sa8540p-ride for work (im lucky enough to get to poke that despite not really a priority anymore). I am embarrassed to tell you how old my kernel version is on x13s. I need to take some time to upgrade this week/weekend :D
<steev> :D
<bamse> ajhalaney[m]: except for steev's current status reports...v6.3-rc1 is looking to be quite nice
<steev> fwiw, i just pushed my 6.2.0-rc8 based on johan's... which includes audio and gpu and bluetooth (audio is spotty, but mostly works... gpu works if you have mesa with the 2 patches on top... bluetooth works...ish-ly kinda... if it's wack, try punting the wifi and see if its more stable)
<steev> tim got back and said that we should merge the 2066 and 6855 stuff, but... not sure i fully understand the bid stuff enough to do so, so i told him to go for it
<steev> not to mention, i tried the 2066 patch he submitted, and while it worked, it got our id wrong, but that could be because we force the wrong wifi firmware?
<bamse> steev: the waybar {time} doesn't give me anything...feels pebcak though...
<steev> "format": " {:%H:%M}",
<steev> that's what i use here
<steev> not the x13s, but it's the same config as this
<steev> oh, you mean for battery
<steev> i don't actually have time remaining... mostly because c630 never had to worry that i was gonna run outta battery and that's where i wrote my config ;)
<steev> ajhalaney[m]: if i screwed up the config wrt fedora options... let me know, the seccomp stuff seems to like to do its own thing when i savedefconfig
<ajhalaney[m]> sweet more motivation to upgrade :)
<ajhalaney[m]> I need to review the current patch queue and see if its finally time for me to go try and give a fedora RPM proper a try (and fix configs if there's still a few stragglers, a few things were already enabled). But will do steev!
<bamse> steev: i see
<steev> and yes, i agree, 6.3 rc1 is gonna be awesome
<bamse> steev: haha, how utterly pebcak...%emptytime means "at what time will you run out of battery", not "how much time is it left until that time"
<bamse> stupid userspace
* bamse crawls back into the kernel
<steev> oh wow
miracolix has joined #aarch64-laptops
<steev> jhovold: re: audio glitches, have you tried with the 5 outstanding ones?
<steev> i say outstanding, but i mean, still in flight i guess
<jhovold> steev: yes, i have those locally, but still broken here. srinik figured out what's broken so hoping we'll have it sorted by next week or so
<steev> oh nice
<steev> while he's at it, maybe he can check on the report from HdkR yesterday about plugging in earphones
<jhovold> runtime pm related it seems
<jhovold> yeah, i mentioned that one to him too
<steev> we do seem to have those issues :(
<steev> it works "reliably enough" here
<jhovold> i can't even get it to probe properly
<steev> weird
<jhovold> get that qcom-soundwire 3250000.soundwire-controller: swrm_wait_for_rd_fifo_avail err read underflow
<steev> yeah, i used to get that a lot
<jhovold> and similar errors that HdkR also reported last night
<steev> i wonder if it's because of your firmware revisions
<steev> i'm on october, which lenovo haven't pushed to linux-firmware
<jhovold> possibly, but i'm using the ones from linux-firmware
<steev> or maybe december
<steev> yeah
<steev> there are a lot of them, unfortunately, and they only pushed the one
<jhovold> guess i need to boot windows and try to get my hands on the latest ones at some point
<jhovold> but srinik said he thinks he understood were things goes wrong no so hopefully he can get it to work also with the older fw
<steev> i'm using one with md5sum of 09b899f13e9fe464fcc4a1f9dc3d81bc which relates to Dec 23
<jhovold> ok, i think i confirmed that I had the same checsum that HdkR reported, from linux-firmware
<steev> yeah, that should start with b38
<jhovold> right
<steev> fwiw
<jhovold> ajhalaney[m]: thanks for confirming, guess we'll need to dig into the shutdown hang if it's still there when rc1 is out
<steev> while you can install innoextract, the "audio drivers" on the site don't have the mbn in there, they are in the "Qualcomm Boot Critical Drivers for Windows 11 ARM (Version 22H2) - ThinkPad X13s Gen 1 (Type 21BX, 21BY" download, however, they're the october release, not december
<steev> steev@wintermute:~/Downloads/temp$ md5sum ./code\$GetExtractPath\$/BootCritical/qcsubsys_ext_adsp8280/qcadsp8280.mbn
<steev> 78e762edc17f0915eee3a91f31daf5ff ./code$GetExtractPath$/BootCritical/qcsubsys_ext_adsp8280/qcadsp8280.mbn
<steev> it is very nice of them to include the pdb files though
<steev> but yeah, if the downloads on the site were up to date, you woudln't need to use windows update to get them
iivanov has quit [Ping timeout: 480 seconds]
<steev> The main audio issue I have here is going into a discord voice chat, it does some weird “dut dut dut dut dut” noise
<HdkR> I'm checking a USB DAC with type-c power passthrough today. Guessing that will work fine :)
Evaia6310 has quit [Quit: Hack the Gibson]
<clover[m]> I tried adding those modules and running mkinitcpio but didn't help
Evaia6310 has joined #aarch64-laptops
Evaia6310 has quit []