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
<tobhe> I take that back, didn't update the dtb correctly... the screen stays black unless I remove those two
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
enyalios_ is now known as enyalios
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<gabertron> Ok thanks!
itsme5n has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
itsme5n has quit [Ping timeout: 480 seconds]
<steev> konradybcio: i finally got the time to reboot the c630 a few times... 8 reboots tested - reboots 1 and 5 gave a blue screen (no qr code, just the screen was blue) and rebooted. boots 2 and 6 gave a blue screen (no qr code, just the screen was blue) but did NOT reboot. boots 3 and 8 were a black screen with a reboot. boot 4 and 7 were the same smmu message as before, but ended up at a busybox prompt (but no usb)
<steev> that is with the .reset patch added on top of the dtsi patchset
<steev> gwolf: BATTERY_LENOVO_YOGA_C630 is the option in 6.11; and i'm like 90% positive i saw lumag submit a merge request for it to the kernel repo (i thought it was merged, maybe it isn't?)
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
itsme5n has joined #aarch64-laptops
itsme5n has quit [Remote host closed the connection]
itsme5n has joined #aarch64-laptops
MattSuiche[m] has joined #aarch64-laptops
<MattSuiche[m]> Hi everyone! Anyone has had any luck with the latest T14S?
<Jasper[m]> <MattSuiche[m]> "Hi everyone! Anyone has had..." <- There should already be a device tree upstream iirc
<Jasper[m]> There are people with out of tree patches here and there
<MattSuiche[m]> https://lore.kernel.org/lkml/20240719-topic-t14s_upstream-v1-0-d7d97fdebb28@linaro.org/ I saw this so I assume there is a pre-built image somewhere
<Jasper[m]> MattSuiche[m]: Maybe someone has made one, but I think no one has built in support (yet)
<Jasper[m]> officially I mean
<JensGlathe[m]> If its not the 64GB OLED variant you could try https://drive.google.com/file/d/1bPXgUqtUhq0oT8sSy-Z66VMhkxSYeStE/view?usp=sharing
<JensGlathe[m]> It should boot T14s too
<MattSuiche[m]> Let's see
<JensGlathe[m]> use type-c to boot
<steev> really need to figure out the c630 audio thing because with 6.11 it doing the null pointer deref causes suspend to break
<MattSuiche[m]> Jens Glathe: is this a build you built btw
<JensGlathe[m]> yes
Lucanis has quit [Read error: Connection reset by peer]
itsme5n has quit [Ping timeout: 480 seconds]
<lumag> steev: if that's for tqftpserv, I didn't have time yet
<steev> lumag: no, it's not tqftpserv related, but i'll let gwolf look if he wants, i'd rather try to figure out wtf is going on with audio
<lumag> Ah. Yeah. I have been pinging srinik, but got no response up to now.
<lumag> Maybe I should take a look on my own
Lucanis has joined #aarch64-laptops
<steev> i don't *think* it's in the codec, i think it's in soundwire, because we used to be able to short circuit it by putting hte qcom.c from 6.6 into place
macc24 has joined #aarch64-laptops
<MattSuiche[m]> Jens Glathe: After the grub menu when I select `Ubuntu (Lenovo Thiknpad T14s)` the screen freezes
<MattSuiche[m]> ah damn I've the OLED I guess
<MattSuiche[m]> Jens Glathe: What's the difference with OLED btw?
svarbanov__ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
macc24 has quit [Ping timeout: 480 seconds]
<steev> lumag: actually speaking of the c630... one thing i've noticed is that it doesn't export/report charge_* which seems to break anything not using upower (so e.g. waybar)
iivanov has joined #aarch64-laptops
<JensGlathe[m]> Matt Suiche: there appears to different i2c wiring, different panel data. For my own case, hp Omnibook X14, I get a dark screen as soon as I try to enable the USB4 retimers. Maybe similar there.
<JensGlathe[m]> From what I read from tobhe he got his working by removing some commits. I can put this in V7.
_xav_ has quit [Ping timeout: 480 seconds]
<lumag> steev, that's an ACPI thing. It's either charge or power
<lumag> If you take a look at the ACPI battery code, it will also export only one set of attributes
_xav_ has joined #aarch64-laptops
<JensGlathe[m]> Matt Suiche: as I suspected, its the USB4 retimer stuff for t14s
<MattSuiche[m]> How did you troubleshoot this
<JensGlathe[m]> Oh I just looked into the commits tobhe was referencing, and I had the same issue here with my hp X14. So no real troubleshooting with physical hardware
<MattSuiche[m]> Oh I see
<JensGlathe[m]> Don't have a t14s here I'm afraid
<JensGlathe[m]> same issue I guess
<travmurav[m]> steev: fwiw there are many (non acpi) fuelgauges that don't report either and only report "capacity" (%) so I'd say those tools are just wrong to assume it's provided by acpi
<travmurav[m]> And then you have extra sad ones that don't even have that...
alpernebbi has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
<steev> travmurav[m]: yeah it probably is, it used to work, so it's probably some assumption in a change
srinik has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Quit: Leaving...]
enyalios_ has joined #aarch64-laptops
enyalios has quit [Read error: Connection reset by peer]
<bamse> whiskey9_: no, got caught up in linux plumbers...but planning to test the patch from alex today on my xps
<macc24> kuruczgy: huh weird, what's your uefi version? mine's still on nhcn36ww and refusing to update :/
enyalios_ is now known as enyalios
<kuruczgy[m]> macc24: nhcn44ww
<macc24> ugh maybe that's why :/
<konradybcio> steev: thanks.. i'll try to catch some 845 here, but it seems like it may miss out..
<konradybcio> HdkR: what if you remove the gpio= from retimer fixed regulators
<JensGlathe[m]> what I've seen is that the PS8830 gets registered on whatever bus it will be defined
<HdkR> konradybcio: As a non-kernel developer I don't even know what that is :)
<konradybcio> dts hunk
<JensGlathe[m]> that's the USB4 retimer, one per type-c connector, will be controlled via i2c bus
<JensGlathe[m]> if I add them to my definition (for hp omnibook x14) i end up with a dark screen, box is up and you can ssh in
<JensGlathe[m]> but no display
<JensGlathe[m]> and no interesting error messages
<JensGlathe[m]> crd has 3 of them, hp x14 has 2 - but on which i2c bus?
<HdkR> Guess that would be the two `gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;` lines in the dts?
<JensGlathe[m]> removing the gpios from the rtmr regulators may be a good idea
<JensGlathe[m]> as debu
<JensGlathe[m]> g
<HdkR> One in edp, one in nvme it looks like
<HdkR> I'll need to change my setup before I try again, ripping the NVMe drive out of the T14s isn't very fun
SpieringsAE has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
<SpieringsAE> you should be able to use i2cdetect to see where they are if you know the i2c address
<JensGlathe[m]> thx, will try
srinik has joined #aarch64-laptops
<JensGlathe[m]> for this its regulatorr-always-on for all vreg_rtmr regulators
alfredo has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
ektor5 has joined #aarch64-laptops
<MattSuiche[m]> In case anyone is struggling with the T14s Gen6, I managed to install Debian 12 with this version from Abel: https://people.linaro.org/~abel.vesa/debian-12.0-arm64.iso
shawnguo has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
macc24 has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
<abelvesa> JensGlathe[m]: have you enabled the rest of the mdss_dp nodes ?
fparent has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
fparent has joined #aarch64-laptops
<JensGlathe[m]> yes I thought so
iivanov has quit [Quit: Leaving...]
<JensGlathe[m]> The only thing is that mdss_dp2 is not connected (or shouldn't be)
<macc24> why is *something* eating my gpio-keys node? i'm trying to add lid switch to lenovo-yoga-slim7x.dtb and no matter what, the added gpio-keys node itself doesn't make it to bootede linux system - it's there in the esp partition
<macc24> there's just no trace of it in /sys/firmware/fdt, or dmesg
<JensGlathe[m]> hmm I have copied the one from crd and it worked ootb on the hp X14 https://pastebin.com/1LjrH19r
<MrCatfood[m]> do i need to install something other than vulkan tools? Im having issues running vkcube: https://pastebin.com/B0i0LWNq
<robclark> MrCatfood[m]: what does `dmesg | grep drm` say? It sounds kinda like the gpu is not loading
<gwolf> FWIW I filed the bug in question -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082675
srinik has quit [Ping timeout: 480 seconds]
<MrCatfood[m]> <robclark> "Mr.Catfood: what does `dmesg..." <- https://pastebin.com/3wuQkHYU
<JensGlathe[m]> abelvesa:@tobhe had to revert the USB4-retimer patch to get his T14s up with display
<gwolf> I tried to find what can be causing the issue, but couldn't. I suppose it's something between lines ~692--757 of the diff, that's where the firmware upload is handled, but TBH have no further clue.
<robclark> MrCatfood[m]: what .dts are you using? Maybe it doesn't re-enable the gpu node?
<MrCatfood[m]> robclark: I'm using the Ubuntu_Desktop_24.04_x1e_6.11rc_v6.img.xz image from the google drive
<robclark> hmm, no idea what that is
<robclark> I'd rather see a kernel git tree ;-)
<robclark> Looking at "arm64: dts: qcom: Add device tree for ASUS Vivobook S 15" patch from list, I don't see a GPU node
<robclark> what does `dmesg | grep DMI` say on the vivobook?
<MrCatfood[m]> [ 0.559730] DMI: ASUSTeK COMPUTER INC. ASUS Vivobook S 15 S5507QA_S5507QAD/S5507QAD, BIOS S5507QAD.312 08/01/2024
<MrCatfood[m]> [ 0.559742] DMI: Memory slots populated: 1/1
<robclark> I think you want something like:
<robclark> err..
<robclark> idk if that is the exact path we want, IIRC there were multiple vivobook variants, and if so I'm not sure if they have the zap fw signed the same way
<robclark> qcdxkmsuc8380.mbn would have to be copied from windows partition, to /lib/firmware/qcom/x1e80100/vivobook/qcdxkmsuc8380.mbn
<robclark> you probably don't need to rebuild kernel, just the dtb
<MrCatfood[m]> i'm new to this can you link me some guide how to do that? i'm new to this advanced level stuff
<macc24> MrCatfood[m]: this code snippet should put required firmware files into hopefully right locaations just remove last line: https://github.com/Maccraft123/Cadmium/blob/master/baseboard/x1e80100-woa/postinstall
<robclark> what is /sys/class/dmi/id/board_vendor and /sys/class/dmi/id/product_name on the vivobook? I guess we should use that for the fw path
<macc24> idk, those were the ones that matched what i saw on my yoga slim 7x
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> i put them here for the one i had: qcom/x1e80100/ASUSTeK/vivobook-s15/qcdxkmsuc8380.mbn
<SpieringsAE> but I didnt check the dmi names, didnt know about that
<SpieringsAE> but jeah, I dont have it anymore so cant check
<macc24> what you *should* check is either firmware-name in dts file, or what path does msm driver
<SpieringsAE> jeah i put it in the dts hahaha
<SpieringsAE> like that
<SpieringsAE> I think ASUSTeK is correct, but I doubt vivobook-s15
* macc24 prays there's a vivobook-s15 in dmi product_name
<robclark> for non dev-mode devices you defn need firmware-name in dts file
<robclark> crd and possibly devkit could use the test-signed zap fw, but not production laptops
<SpieringsAE> for some reason, the only place the asus vivobook MA0001W with 32gb of ram is only available in europe in the baltic states lol, estonia and lithuania, its pricier than I hoped though 1500 eur compared to 1300, was hoping for a price bump of only 100 eur
<MrCatfood[m]> <macc24> "Mr.Catfood: this code snippet..." <- i had to change the script a bit but ran it, what should i do next? simple reboot?
<macc24> MrCatfood[m]: sure why not
<macc24> oh right i hope you're not booting from usb
SpieringsAE has quit [Remote host closed the connection]
<JensGlathe[m]> abelvesa: thank you for pointing out the patch. I have removed mdss_dp2 from my dts, and now it boots with display. Will check if these retimers do something now.
<JensGlathe[m]> Do you have a tplg file per chance to work from?
srinik has joined #aarch64-laptops
<MrCatfood[m]> <macc24> "oh right i hope you're not..." <- i am
<MrCatfood[m]> but its not live boot
<macc24> ok if you see filesystem errors after boot then remove either adsp or cdsp firmware, for me having them caused usb devices to re-enumerate
<JensGlathe[m]> adsp
<steev> gwolf: that *probably* correlates with https://github.com/linux-msm/tqftpserv/commit/a4c755db17eeb9e49d8585689a1ef1f399b2be48 but it *should* be falling back to the FIRMWARE_BASE if the firmware path from sysfs fails (which it would on debian as it's empty there)
<JensGlathe[m]> should only be in initramfs to ensure no reload attempts fro the rootfs
macc24 has quit [Quit: adios]
<steev> lumag: gwolf: konradybcio: so, i poked at it; reverting just https://github.com/linux-msm/tqftpserv/commit/98d162c9ff5327331cec7fb92ca375073adfa617#diff-3829fc2cbf63c2eed6e766b97100fccc5b1593a9977bc43e32b7f42c921d33cfL154 this hunk seems to fix it on debian; why doing dirname twice there, i'm not sure
<steev> note: debian seems to have an additional patch from fairphone that might be the issue (not sure); could be why others don't see it?
<steev> oh wait no, i misread, fairphone is the upstream patch, sorry
<lumag> Well, if they still have it then it wasn't upstreamed
<steev> it's not from fairphone (afaik); it seems it's from debianonmobile - but basically changing line 41 of the debian patch to `strcat(path, dirname(firmware_value));` fixes loading the firmware here
tobhe_ is now known as tobhe
<steev> in 2 hours i can test if removing their patch (it's supposed to be to also look in updates) works
<steev> unless gwolf wants to remove the debian patch, build the package and test
<steev> gwolf: actually could you please test that as well? just comment out the patch in the series file and build the package? should take ~30 seconds
mcbridematt has quit [Quit: Leaving]
<steev> gwolf: also, fwiw, with 6.11, this version of battery_status works for me on the c630 - https://paste.debian.net/hidden/13aa67ae/
chrisl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<kuruczgy> macc24: FYI I already tried to get the lid switch working on the yoga 7x a while ago, here is what I learned:
<kuruczgy> Looking at `/sys/kernel/debug/gpio` over SSH I could not see gpio92 change when closing the lid
<kuruczgy> I then dumped the gpio registers in windows using Konrad's "poor man's JTAG" method (https://konradybcio.pl/windbg/), and saw that gpio92 WAS changing with the lid state in windows
<kuruczgy> I then went and dumped all other GPIOs on windows, and tried to manually toggle the ones set to output in windows but not in linux (the theory being that maybe some other gpio is needed to "enable" the sensor), but no luck
<kuruczgy> I am not confident that my search was exhaustive, but I think I tested most such gpios
<kuruczgy> But it would be awesome if you wanted to drill deeper, I find that not having the lid switch working is a pretty big usability pain point
srinik has quit [Ping timeout: 480 seconds]
<anonymix007[m]> sibis: have you had a chance to check it already?
kettenis_ has quit [Remote host closed the connection]
kettenis has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #aarch64-laptops
<whiskey9_> ls
mcbridematt has joined #aarch64-laptops