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>
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>
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:
<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)
<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
<_[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)
<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>
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
<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?
<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]