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
<Dantheman825[m]> so for kernels 6.7.2 and newer, do I need to update alsa-ucm to a git version?
<_[m]123> if your sound is not working I think
<steev> i believe 1.2.11 is released, so as long as you're using that, you should be okay
<Dantheman825[m]> well there's my problem, Ubuntu-23.10 for the X13s has 1.2.9-1ubuntu3.2
<steev> fwiw, it's not correct (because i didn't add myself to uploaders, mostly because i can't actually upload), https://salsa.debian.org/steev/alsa-ucm-conf
<steev> but that should give you a 1.2.11 that works until you get a tagged version
<steev> s/tagged/signed
<enyalios> i tried 6.7.2 with git alsa-ucm-conf and still had no sound
<steev> dmesg output?
<enyalios> ill upload that later, im booted into a kernel with working sound at the moment so i can use the laptop for now
<steev> if it works in that kernel, then it sounds like your alsa-ucm-conf isn't correct; because it's not backwards compatible
<enyalios> i downgraded back to 1.2.10 with pull 335
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<travmurav[m]> HdkR: Jasper aspire1 (sc7180) has two DP lanes physically but I only need to drive 2k80 (2k60 forced) however the problem was that the DP link doesn't train with only two lanes and I can't even know if it's the HMD itself or the optical cable even that gets upset
<travmurav[m]> ah and that's 2k "portrait" so it's very lean wrt 7c hw limits, only pixel clock at 80 I guess
<travmurav[m]> but speaking of, robclark , I think you explained to me that there is a line width limit and px clock limit, could you hint where I can find the exact max value for px clock for sc7180?
<HdkR> Makes sense, the 7180 is quite a bit more limited
<travmurav[m]> well thankfully I don't have to emulate the x86 version of the game too :D
<HdkR> :D
KhazAkar has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
<Dantheman825[m]> I manually updated ucm-conf myself (copying ucm and ucm2 to /usr/share/alsa). Audio still doesn't work on 6.7.2
<Dantheman825[m]> Since it seems we're both having the same issue, here's my dmesg output
<jhovold> Dantheman825[m]: I assume you use steev's branches; if audio worked with his 6.7.1 and breaks with 6.7.2 something is clearly wrong with steev's 6.7.2 branch
<jhovold> it seems he included some known broken headphone codec pathches, that may be it, maybe not
<jhovold> yes, confirmed: steev's 6.7.2 is broken:
<jhovold> [ 9.771888] snd-sc8280xp sound: ASoC: Failed to add route ADC2_OUTPUT -> TX SWR_ADC1(*)
<jhovold> revert to his his 6.7.1, switch to my wip branches or use mainline
<jhovold> the upcoming mainline/stable 6.7.4 will hopefully have all the required audio fixes, which were merged into Linus's tree yesterday
<jhovold> enyalios: ^
<jhovold> dgilmore, jglathe_: so we concluded that the v36 fw appears to fix the ath11k firmware suspend issue dgilmore had yesterday
<jhovold> I skimmed the ath11k bugzilla and found this issue: https://bugzilla.kernel.org/show_bug.cgi?id=217239
<jhovold> I'd actually seen it before when I saw the resume crash once or twice some half a year ago, but there wasn't a suggested firmware fix until December
<jhovold> There seems to be more than one bug at play here, but essentially there was a regression in the .23 release from early last year
<jhovold> The .36 December released fixed the issue for some folks, but some also needed .37 which is now also in linux-firmware
<jhovold> linux-firmware-20240115 has the .36 fw which helped dgilmore, the next release with .37 should hopefully address any remaining issues
<jhovold> this may also help with the spurious wakeups you'd noticed, robclark ^
<jhovold> jglathe_: did you confirm that .36 or .37 makes the issues you had with the volterra go away?
<jhovold> steev, jglathe_: there was also an open issue for the "msdu_done bit" warning:
<jhovold> apparently depends on the network (AP)
<jhovold> perhaps you can chime in there if it bothers you
KhazAkar has quit [Quit: Connection closed for inactivity]
vkoul| has quit [Write error: connection closed]
mani_s has quit [Remote host closed the connection]
pneuhardt has quit [Read error: Connection reset by peer]
shawnguo has quit [Read error: Connection reset by peer]
apalos has quit [Remote host closed the connection]
shawnguo has joined #aarch64-laptops
pneuhardt has joined #aarch64-laptops
apalos has joined #aarch64-laptops
apalos has quit []
pneuhardt has quit []
bryanodonoghue has quit [Quit: The Lounge - https://thelounge.chat]
shawnguo has quit []
bryanodonoghue has joined #aarch64-laptops
mani_s has joined #aarch64-laptops
apalos has joined #aarch64-laptops
vkoul has joined #aarch64-laptops
<jglathe_> my devices have linux-firmware 20230919.git3672ccab-0ubuntu2.5 . Installed the .37 firmware on all of them now, no issues so far.
<Jasper[m]> Hm, I might have been unknowingly using .37 too then
<Jasper[m]> As dgilmore said, rawhide updates quickly
<Jasper[m]> Haven't had any issues other than iwd being slightly unwieldy to me
<Jasper[m]> Haven't had autoconnect function for example
shawnguo has joined #aarch64-laptops
<jglathe_> the Volterras had .30 (?) and the X13s had .23, both had the issue with wrong frame length and generally acting up after a while. I would suspect some kind of mismatch somewhere. X13s and Volterras didn't act up either when I used the amss.bin / m3.bin files matching the reported version from Kalle'S repo. so there's that
<jhovold> Jasper[m]: fedora should be on .36 until the next linux-firmware release
<jhovold> jglathe_: you seem to confuse the fw version with some kind of hw version, the printout you see from ath11k during boot is just reporting which firmware version you loaded
<jhovold> that is, what happens to be in your /lib/firmware/ath11k/ when you boot
<jhovold> a bit depending on your distro, everyone should most likely have been using .23 up until january 15 when linux-firmware with .36 was released
<Jasper[m]> jhovold: Even rawhide? The regular fedora releases update by linux-firmware release yes, but I'm not sure about the rolling stuff
<jhovold> I would be suprised if they pull in linux-firmware daily, but that is just an assumption on my end
<jhovold> the frame length issue, is most likely distinct from the suspend issue. but who knows, maybe qualcomm fixed that too in their proprietary fw
<jhovold> they don't even provide changelogs IIUC
<jhovold> Jasper[m]: and either way, there was no updated fw for ath11k until December last year (later included in linux-firmware-20240115)
<jhovold> Jasper[m]: looks like they mostly follow the linux-firmware releases: https://src.fedoraproject.org/rpms/linux-firmware/commits/rawhide
<Jasper[m]> I stand corrected then
<Dantheman825[m]> <jhovold> "revert to his his 6.7.1, switch..." <- for your branches, would the johan_defconfig work okay? Or could I probably get away with copying laptop_defconfg I use on steev's branches?
<jhovold> johan_deconfig is what I use on my X13s so that should work (and builds in 2.5 minutes), but you can also copy and use a laptop_defconfig from steev's tree
<jhovold> Dantheman825[m]: ^
<Dantheman825[m]> alright, good to know, thanks
<jhovold> danielt, bamse, steev: I took a closer look at the bluetooth firmware situation today
<jhovold> There was an update in linux-firmware-20240115 which appears to have made thing much worse
<jhovold> distorion, glitches and extremely limited range (e.g. 2 m)
<jhovold> The windows NVM file from 9 months ago works much better here, range is much better than I expected
<jhovold> but even the previous hpnv21.bin works much better
<jhovold> even if not as good
<jhovold> As I suspected though, the windows nvm file appears to be intended to use with the Windows firmware
<jhovold> As with the the ath11k fw, there's a version string in the file that indicates that
<jhovold> hpnv21.b8c: BTFW.HSP.2.1.0-00538-WOS_PATCHZ-1
<jhovold> hpnv21.bin: BTFW.HSP.2.1.0-00538-VER_PATCHZ-1
<jhovold> hpnv21.bin: BTFW.HSP.2.1.0-00629-VER_PATCHZ-1 (linux-firmware-20240115)
<jhovold> WOS is the Windows On Snapdragon suffix
<jhovold> as for the ath11k fw
<_[m]123> how do you resolve the resume issue fastest? I usually just do ifdown / ifup
<jhovold> Now the firmware itself was also updated along with the NVM file, so by reverting to the older NVM file we'd be introducing a potential version mismmatch there too
<jhovold> So, bamse, we want qualcomm to provide a NVM configuration for boards with id 0x8c which can be used with the 2.1.0-00629 firmware that is currently in linux-firmware
<_[m]123> don't upgrade to new linux-firmware package then, but maybe put ath11k firmware files manually?
<jhovold> _[m]123: try using the ath11k fw from linux-firmware-2024015, that fixed the issue dgilmmore was seeing
<_[m]123> yeah debian isn't that quick 😄
<jhovold> if you still have problem, you can try installing the latest version .37 which is the linux-firmware main branch now
<_[m]123> is qualcomm unresponsive about such fw requests?
<jhovold> I've been trying to get them to release this fw for a year now...
<jhovold> that is, to tell us what we should be using and to release that fw
<_[m]123> it's corporate bureaucracy or just not caring
<jhovold> a bit of both it seems
<_[m]123> but if it works well with the windows one, why care more?
<_[m]123> it has to match other references?
<jhovold> just because it mostly works now, does not mean it will continue working the next time the fw is updated
<_[m]123> yeah
<jhovold> there are multiple components to the fw (e.g. rom, rampatch, nvm config) and there's a driver, and we simply don't know what happens when they get out of sync
<_[m]123> nvm is the bluetooth fw binary?
<_[m]123> so we just got lucky now 😄
<jhovold> and we want to have all fw in linux-firmware so that any distribution just works on the x13s, without the user having to install anything manually
<jhovold> nvm is one part of the fw
<_[m]123> linux-firmware-nonfree that is on debian huh
<_[m]123> oh
<jhovold> there's a rampatch file as well (hpbtfw21.tlv)
<_[m]123> are you referring to minorminor version here? https://mirrors.edge.kernel.org/pub/linux/kernel/projects/backports/stable/ .37 ?
<jhovold> no, the .37 is the version of the ath11k wifi fw
<jhovold> The latest one is called "WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37"
<jhovold> .37 is the version suffix
<_[m]123> derp
<_[m]123> I understand very much why endusers shouldn't be doing this stuff haha
<_[m]123> I don't have any such file though
<jhovold> which file?
<jhovold> the ath11k fw is called 'amss.bin' and 'm3.bin' if that's what you meant
<_[m]123> I ran locate on WLAN.HSP nothing returend
<_[m]123> oh ok it's the name of the folder
<jhovold> "WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37" is the build id
<_[m]123> ok
<jhovold> and the name of the folder in ath11k-firmware (not linux-firmware)
<_[m]123> I put those two files and made backup of the old and rebooted - still have wifi so all good?! 🙂
<jhovold> should be (and it seems you only need to update amss.bin, the other on hasn't been updated for a long time)
<jhovold> _[m]123: try 'dmesg| grep WLAN' to see what version the driver reports
heapify has joined #aarch64-laptops
heapify has quit [Remote host closed the connection]
halvor has joined #aarch64-laptops
<halvor> hello
<halvor> is there a way to enable the X55 modem on Ubuntu 23.10.1 (X13s)?
<halvor> I get the invalid transition error when trying to enable it using mmcli
<halvor> I made the symlinks for the fcc-enable script
<dgilmore> Jasper[m]: linux-firmware gets updated on all Fedora releases at the same time
<jhovold> halvor: should just work, you may be missing the qmicli tool which is packaged separately on debian (and ubuntu I assume)
<jhovold> you need MM 1.20, no idea what that version of ubuntu has
<halvor> jhovold: I have installed qmicli
<halvor> mm is 1.20.x
<halvor> mmcli 1.20.6
<jhovold> you may need to create the fcc unlock link manually, if you didn't already, with mm 1.20 and 1.21, see: https://github.com/jhovold/linux/wiki/X13s#known-issues
<halvor> oh, I did that wrong
<halvor> jhovold: thanks for the link!
<halvor> i didn't escape the :
<halvor> now it works :D
<halvor> silly me
peter has joined #aarch64-laptops
peter is now known as Guest1475
halvor has quit [Ping timeout: 480 seconds]
Guest1475 has quit [Quit: Guest1475]
peter_ has joined #aarch64-laptops
peter_ is now known as halvor
halvor has quit [Quit: halvor]
halvor has joined #aarch64-laptops
halvor has quit [Quit: halvor]
halvor has joined #aarch64-laptops
halvor has quit []
jhovold has quit [Quit: WeeChat 4.1.2]
<enyalios> jhovold: huh my dmesg doesnt have that error https://bpa.st/TVUEE
<robclark> travmurav[m]: the edp bridge might also impose limits, but in general https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h?ref_type=heads is the place to look
<travmurav[m]> robclark: I'm using two DP lanes routed to type-c so no bridge, does the dpu header still apply there?
<robclark> yes
<travmurav[m]> ah I guess it's dpu->DP and dpu->dsi
jhovold has joined #aarch64-laptops
<travmurav[m]> Thanks!
<jhovold> enyalios: that message was in Dantheman825[m] log (and the broken patch was in steev's branch), but you don't even get that far as your sound card never even probes
<jhovold> enyalios: here's your problem:
<jhovold> [ 3.508919] remoteproc remoteproc0: Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn failed with error -2
<jhovold> [ 3.508923] remoteproc remoteproc0: request_firmware failed: -2
<jhovold> looks like your setup (distro) is missing the adsp fw
hightower2 has quit [Ping timeout: 480 seconds]
<enyalios> $ ls -lh /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn
<enyalios> -rw-r--r-- 1 root root 14M Jan 29 09:17 /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn
<enyalios> huh, its definitely there, why would it be failing to load?
<jglathe_> hmm seen this with the wrong ones. Maybe not matching to BIOS?
<jglathe_> -rwxr-xr-x 1 root root 14561644 Jan 14 09:26 qcadsp8280.mbn*
hightower2 has joined #aarch64-laptops
<_[m]123> > [ 19.449206] ath11k_pci 0006:01:00.0: fw_version 0x1106196e fw_build_timestamp 2024-01-12 11:30 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37
<_[m]123> yeeep
<jglathe_> enyalios why is yours newer
<jhovold> enyalios: the fw is probably missing in your initramfs where your setup seems to need it
<jhovold> those '[ 4.916135] debugfs: File 'uA_load' in directory '/' already present!' warnings you have don't look healty either btw
<jhovold> healthy*
<jglathe_> I have them too, need to investigate
<jhovold> audio fixes now queued up for 6.7.4 and 6.6.16
<_[m]123> noise
<_[m]123> from 6.7.4 onwards we can track mainline for x13s right?
<bamse> _[m]123: with v6.6 mainline turned good enough for me...
<jhovold> _[m]123: yes, unless you really crave support for the fingerprint reader or video acceleration
<jhovold> and the touchscreen
<jhovold> I'll try to get that bluetooth address endiann fix backported too
<bamse> jhovold: where are we on the touchscreen? will you be able to give me compatibles for the i2c-hid devices?
<jhovold> heh, me? I thought it was your series? ;)
<jhovold> haven't had time to look at or reply to that mail yet
<jhovold> guess you can still have touchscreen with the manual rebinding, so scratch that one
<bamse> jhovold: i said "here's a prestine set of patches" rob said "next time you add a delay i want a device-specific compatible" and then you read that as "this time"...and i don't know what device we have there, so i asked you
<bamse> jhovold: and btw, don't we have reset pins etc on all 4 hid devices? so i presume we need compatibles for all 4 now?
<bamse> it's rather nice how acpi hides this stuff and just presents a generic i2c hid device to the os...
<bamse> jhovold: i presume the keyboard compatible is lenovo,thinkpad-x13s-keyboard? as that should just be firmware running on the ec...
<jhovold> bamse: heading out for a bit, will check in / reply later
jglathe_ has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<jglathe_x13s> up on 6.7.3 (rebased on steev's branch, ignored 2 commits, though) and sound works without additional changes
iivanov has joined #aarch64-laptops
<_[m]123> booted 8.0rc2 now
<_[m]123> video acceleration sounds nice though
<_[m]123> @bamse oh ok good to know 🙂
<jglathe_x13s> is the file in the initramfs?
<dgilmore> to enable the fingerprint reader you can just build the dtb with the patches. at least with 6.8-rc2
<dgilmore> same for touchscreen
<jhovold> dgilmore: what do you mean, the support for the fingerprint reader and touchscreen are in my wip branches
<jhovold> there are multiple patches needed to enable the usb multiport controller, the dts patch is just the last one
<dgilmore> jhovold: yes, but if you build a dtb from your tree and use that with another kernel, such as the Fedora one, the touchscreen and fingerprint reader work
<dgilmore> at least it works for me
<jhovold> no, as I said, the multiport patches are not in mainline yet, maybe fedora has backported them as well
<dgilmore> probably not
<dgilmore> but it does work for me
<jhovold> must be by chance then as some stuff may have been left enabled by the bootloader, would definitly NOT recommend this
<dgilmore> That is fair
<jglathe> [60601.939973] ath11k_pci 0006:01:00.0: msdu_done bit in attention is not set
<jhovold> jglathe: i linked to a bugzilla entry for that above
<jhovold> i'm done for today, and this weekend probably, talk later
<jglathe> this is on the WAC124, seems to happen independent of AP ^
<jhovold> not seeing it here
<steev> i too have never seen that ADC message; steev@wintermute:~/git/neovim$ dmesg | grep ADC
<steev> steev@wintermute:~/git/neovim$
<jglathe> jhovold: thanks
<jhovold> steev: you would see that without this patch:
<jhovold> so apparently it was missing from your branch at some point (or from whatever kernel Dantheman825[m] is using, I'm getting lost of all this random downstream trees, people should start moving towards mainline)
<jhovold> later!
<steev> ohh, yep, that's my fault :(
martiert has quit [Quit: WeeChat 4.2.1]
martiert has joined #aarch64-laptops
<jglathe_x13s> I got the ADC line as conflict on my rebase, current lenovo-x13s-linux-6.7.y doesn't have it.
jglathe has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
<enyalios> jglathe_volterra: that is just the date that i installed the linux-firmware package
<enyalios> jhovold: i unpacked my initrds for both 6.7.0 and 6.7.2 and they include identical firmware files
<enyalios> neither one includes qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn
<dgilmore> jglathe_x13s: do you plan to upstream your devkit work?
<jglathe_volterra> konradybcio is on it
<jglathe_volterra> But afaik we're waiting on a signed-off from the original creator I based my work on, Merck Hung https://github.com/merckhung/linux_ms_dev_kit
<dgilmore> cool, looks like he has not been active in awhile
<steev> jglathe_x13s: because the 6.7.3 that i pushed has the patch that fixes the issue
<steev> i thought i had pushed the patch to 6.7.2 but apparently i hadn't :(
<jglathe_volterra> yeah. my rebase on your 6.7.y head showed 4 commits that were not from me, sort of always a warning sign. I ended up dropping all 4.
<jglathe_volterra> dgilmore he answered sorta promptly when he got a mail from kernel.org, but that effect seems to have waned
<steev> ah, when there are issues in patches in my patchsets, only i get an email now instead of people on the lists
<steev> at least from the bot that builds my repos
<jglathe_volterra> anyway. it's out in the world and you can get an (odd) live image, too. Will do a new one in a few days(?) I guess. Played around with the X13s Ubuntu iso, got it to boot with Volterra, too, but not up until install. Volterra is a wip supported target on armbian, though
<jglathe_volterra> but armbian (great as it is) is a PITA in itself
<dgilmore> I am going to try pxe boot the fedora installer with the dtb from your tree.
jhovold has quit [Ping timeout: 480 seconds]
<jglathe_volterra> have fun
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<dgilmore> I guess I should figure out USB booting. it failed to pull the installer image from the internet due to time being off
<jglathe_volterra> hmm. Need to boot with mhi as modules. The images boot nicely from USB, its 6.6.0, though
<jglathe_volterra> the time can be set, probably. But yes, time is f'ed on Volterra when booting
<Jasper[m]> <dgilmore> "I guess I should figure out..." <- Afaik there aren't any real quirks
<jglathe_volterra> Oh it took me 2 months and the purchase of an X13s to figure out USB booting. Anyway, happy user
<dgilmore> When I have tried using the USB button it's only pxe booted
<Jasper[m]> dgilmore: You can set the bootorder in UEFI
<Jasper[m]> And the trick is to hold the button until you see things on the screen
<Jasper[m]> Power button can be pressed to turn it on
<enyalios> so adding qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn and qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn to my initrd makes sound work in 6.7.3
<enyalios> no clue why that wasnt necessary in 6.7.1, but suddenly is in 6.7.2 and 6.7.3
<jglathe_volterra> yay
<enyalios> i was building the kernel and the initrd with exactly the same script, so i know it wasnt like i was just forgetting something
<steev> probably because of new patches
<steev> but glad its working, i didn't give a changelog this time, unfortunately when i pushed
<enyalios> i guess other distros may have already included those firmware files
<enyalios> maybe thats why it only broke for me
rmsilva- has joined #aarch64-laptops
rmsilva has quit [Read error: Connection reset by peer]
rmsilva has joined #aarch64-laptops
rmsilva- has quit [Ping timeout: 480 seconds]