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>
woo, rc1
<steev>
will push out what i have going here shortly-ish...
<steev>
only real changes are latest versions of patchsets and found a patch on asoc that fixes a clock (no noticable difference on the user side of things)
irctian1 has joined #aarch64-laptops
irctian12 has quit [Ping timeout: 480 seconds]
irctian12 has joined #aarch64-laptops
irctian1 has quit [Ping timeout: 480 seconds]
irctian1 has joined #aarch64-laptops
irctian12 has quit [Ping timeout: 480 seconds]
Erisa has quit [Ping timeout: 480 seconds]
Erisa has joined #aarch64-laptops
<init>
sound working with 6.2.y and ucm patch
<init>
some crackling here and there, but it's working.
<init>
thank steev for the repo
Erisa has quit [Read error: No route to host]
Erisa has joined #aarch64-laptops
Erisa has quit [Read error: No route to host]
<steev>
pushed out the rc1 stuff... guess we're gonna need to sort out these devicelinks things?
<clover[m]>
ooo
Erisa has joined #aarch64-laptops
<clover[m]>
is the microphone DMic01?
<clover[m]>
is that supposed to be working now?
<clover[m]>
it kinda works, but on a zoom call it sounds like a demon
<steev>
haven't tested it at all, but i think so?
<clover[m]>
also steev is this expected?
<clover[m]>
> $ dmesg | grep bluetooth
<clover[m]>
[ 7.345436] bluetooth hci0: Direct firmware load for qca/hpbtfw21.tlv failed with error -2
<steev>
if you don't have the /lib/firmware/qca/hpbtfw21.tlv installed, yeah
<steev>
that comes from linux-firmware
<steev>
seems odd that you don't have it now though?
<steev>
didn't you have working bluetooth before?
<clover[m]>
things seemed to work okish except my bt mic
<clover[m]>
was it recently added?
<steev>
no, that should have been a thing for as long as i've said "here's my bluetooth stuffs"
<steev>
bluetooth firmware does seem to be part of the newest system hardware drivers package
<steev>
new bt firmware*
<steev>
oh, the 6.3 bluetooth patches aren't updated, i should do that... tomorrow
<HdkR>
Looks like that caused a kernel abort in qca_download_firmware with a page fault
<HdkR>
...
<HdkR>
wget fail
<steev>
lol
<HdkR>
Looks like it worked, let's see if I can connect something
<steev>
i don't think anything LE will work
<steev>
my airpods don't quite work right... but they don't quite work right in windows either... but that's also not specific to the thinkpad, the asus rog desktop system i have also has issues with the airpods
<jhovold>
abelvesa: I've acked it now. I was hoping for some more details on the actual impact but this should do.
<abelvesa>
jhovold: the only thing I have access to is the LLCC SC table and the fix takes the values from that table, that's it
<jhovold>
javierm: I'm afraid my series should not have any impact on that bug you're hitting as it happens during early unbind
<javierm>
jhovold: got it. I can dig deeper later then, I just didn't want to spend time if was something you were already addressing in your series
<abelvesa>
jhovold: the impact is explain by the overflow value
<abelvesa>
*explained
<jhovold>
javierm: i was focusing the bind error paths, haven't really tried unloading driver once its bound, i'm sure there are many more issues lurking there
<javierm>
jhovold: yeah
<jhovold>
abelvesa: my point was that saying that the slice ids overflow the 32 bit registers is only explaining the first part of the consequences, it doesn't say what that leads to (e.g. corrupting some other settings, reduced performance, etc)
<abelvesa>
jhovold: right, well, I don't think it is corrupting other settings, but the performance will obviously be reduced as all the settings for that specific slice will not be written accordingly
<abelvesa>
jhovold: let me know if you want me to add that to the commit message as well
<jhovold>
abelvesa: well, if you've got an understanding aready that you could amend the commit message with, that'd be great.
<jhovold>
judging from a a quick look it may overwrite adjacent registers as well though
<jhovold>
e.g. when determining register offsets using macros like LLCC_TRP_ATTR0_CFGn
<abelvesa>
jhovold: so I remembered I checked this a couple of weeks ago and it wasn't the case, but I forgot exactly why
svarbanov_ has quit [Ping timeout: 480 seconds]
<abelvesa>
ok, so there is no ATTR2_CFG (which would be at 0x21100) on sc8280xp and next thing after ATTR[12]_CFG (0x2100[04]) is the SCID_DIS_CAP_ALLOC (at 0x21f00)
svarbanov has joined #aarch64-laptops
<abelvesa>
correct me if I'm wrong here, but ATTR1_CFGn goes up to 0x210f8 and ATTR2_CFGn goes up to 0x210fc, where n=0..31
<jhovold>
yeah, sure, there may not be anything important there currently, but it's still overwriting random registers
<abelvesa>
ok then, will reword and resend
<jhovold>
i only looked at one of these macros and sees that ends up pointing outside of the expected 32 register range
<jhovold>
saw*
hightower2 has quit [Remote host closed the connection]
echanude has joined #aarch64-laptops
<HdkR>
Does Displayport/HDMI audio not work on the X13s or is my adapter bunk?
<gwolf>
HdkR: It doesn't show up in the C630, and if the code is in any way related...
<gwolf>
i'd expect not to show in the X13S either
<HdkR>
hmmm
<gwolf>
FWIW, even though my C630 is still mute, BT-audio works quite well (as expected! But still, worth mentioning IMO)
<gwolf>
(well, not mute, but its cracks are hardly classifiable as "audio works OK")
<HdkR>
Maybe related to all the qcom-soundwire errors that dmesg spams
<HdkR>
"Failed to get cgcr reset ctrl required for SW gating"
<init>
did a full morning office work on the x13s this morning. I have to say that it's pretty good in term of responsiveness, way less sluggish than windows on a almost-all-emulated ecosystem.
<init>
not sure TLP is excessively effective, but I did see an improvement on battery drain after installing it.
<init>
i use a BT mouse, which works quite well, I had some episode of slowdown but it resolved itself, with no specific error in the console
<init>
wifi went down only once and went back up by itself
<init>
no gpu crash
<init>
most recent gnome and X11. I have a weird problem of console focus with firefox on Wayland for now.
<init>
I think it's liveable to work with.
<init>
which is great.
<HdkR>
Looking at how this soundwire controller initializes, looks like v1.6 has a clock gate, which for some reason even though it is described in the DT, it isn't able to pick up on
<HdkR>
and then skips initialization which explains why it can't be seen
<HdkR>
Looks like sc7280 and sc8280xp are the only two that use this currently
<HdkR>
oh, might help to enable LPASSCSR_8280XP
hightower2 has joined #aarch64-laptops
<steev>
yeah you need the LPASSCSR...
<HdkR>
Three controllers register, wsa883x-codec spins up. No audio device, I guess this is some alsa ucm thing now?
<HdkR>
Is that necessary for DP audio though? I thought that was for internal and headset?
<steev>
oh
<steev>
i don't know about hdmi/dp audio
<steev>
that might be an option that isn't enabled in the kernel config under audio
<HdkR>
hmm
<travmurav[m]>
Is there some MultiMedaX to dispayport swithch magic that has to be tickled in the ucm maybe? (assuming adsp audio)
<travmurav[m]>
I think I saw something like that the last time I looked at it on my device
<steev>
could look at what 7180 or whatever does it then
<travmurav[m]>
does x13s use lpass directly tho?
<travmurav[m]>
that is, compared to booting the adsp and talking to it
<HdkR>
Looks like Trogdor does some dai-link thing in the audio dts section
<HdkR>
Which has a link to some hdmi node
<init>
hey steev, is lenovo-x13s-v6.3.0-rc1 as stable as 6.2.y ?
<init>
"from what you know so far"
<steev>
in my current testing (which isn't heavily), yeah, mostly?
<steev>
i'm about to push out a new bit though, once i rebuild
<steev>
grabbed the latest interconnect changes, and jhovold's drm patches
<steev>
also abel's latest slice
<steev>
freaking europeans and their working and posting stuff while i'm asleep :(
<steev>
(and other places that aren't america)
<steev>
ooh, mhi changes too
<steev>
(not in, just noticed mani posted them)
<mani_s>
steev, those are just cleanup patches, and a debugfs patch to monitor pcie link transitions
<mani_s>
doesn't necessarily be included in any release branch
<steev>
si
<steev>
i was just excited to see them :)
<mani_s>
steev, :)
<mani_s>
you can still use watch how the link transitions during runtime
<mani_s>
steev, it'd be interesting to enable ASPM powersupersave and check how it saves power
<mani_s>
I can confirm that link enters L1SS state and now we should see some improvement in powersaving
<steev>
init: if you wanna give it a try... you can try now, i just pushed out, it's mostly just re-arranging some things, i dropped 1 bt patch, but it didn't seem to affect anything anyway, and will come in time
<steev>
i moved my patches to the end so they're easier for me to update/punt
<steev>
init: the big thing with 6.3 is... (and i don't fully understand it) devicelinks don't seem to be working properl, according ot jhovold, thats why even though things appear to work, we get the messages in dmesg about not being able to create them
<init>
interesting
<init>
what does it affects ? external dp or something more fundamental?
<clover[m]>
<anarchron> "clover: are you getting video on..." <- no but that's expected. cam doesnt work yet
<clover[m]>
latest box64 emulates zoom just fine, messes up internal mic though so im using a headset with a usb dongle. bt headset mic doesnt work, possibly due to BLE
<steev>
actually it looks like it only currently affects pmic_glink