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
KREYREN_oftc has quit [Remote host closed the connection]
<jhovold>
dgilmore: no, i'm afraid it looks like dp hotplug will be broken in 6.8 and 6.9 unless we revert the dp runtime pm series that triggered these regressions completely next week
<jhovold>
one patch has already been reverted, and I'm still hoping the drm guys will come up with some temporary band-aid, but we are running out of time
hightower2 has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
hightower3 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
Guest1021 has quit [Quit: WeeChat 4.2.1]
martin has joined #aarch64-laptops
martin is now known as Guest1470
<steveej[m]>
jhovold: were you able to confirm whether the regression was backported to 6.7 patch releases? if not it'd be nice to get those while waiting for the fix in newer kernels
<jhovold>
steveej[m]: the series that triggered these regression should not have been backported as it was not marked for stable (even if I haven't verified that)
<jhovold>
that said, the msm drm hotplug implementation is known to be buggy, so 6.7 was not working perfectly either
<jhovold>
just much better than 6.8-rc...
<steveej[m]>
for me the difference is like night and day. since switching back to your 6.7 branch hotplug has worked every time. i did notice that the external display sometimes turns of shortly when 100% charge has reached but it comes back on so it's not a big deal.
<jhovold>
steveej[m]: yeah, it's definitely broken in 6.8 (even if connecting an external display *once* appears to work somewhat reliably for me, but bamse has not been able to use his external displays at all since rc1)
<jhovold>
maybe depends on the external display, differences in timing, and such
<_[m]123>
x13s is back - it's a different type of touchpad w t f
<_[m]123>
they replaced the WHOLE cover lol not just the back
<_[m]123>
somehow the speaker holes are now 80% closed !?
<_[m]123>
this touchpad is more solid, the physical buttons have less travel time and are lower
<_[m]123>
it also has a different feel, seems to be glass now
<_[m]123>
even the keyboard keys have a different feel wtf
<_[m]123>
they sell beta hardware first or what
<travmurav[m]>
Did you check it's not a completely different laptop? :D
<_[m]123>
the screen was still dirty lol 😄
<_[m]123>
hard to tell but possible yes, they replaced the whole shebang because of no stock of such touchpads
<_[m]123>
so neat, new laptop
<travmurav[m]>
who knows if they put your x13s top on an x13 bottom xD
<_[m]123>
the cover says x13s 😅
<_[m]123>
so should we compile 6.6 then for DP?
<_[m]123>
haven't been able to boot linux so far wtf
<_[m]123>
aaaah the bios setting -> so it's a new laptop - let me check
<danielt>
Can't say anything about the keyboard feel but my X13s is a retail model from late 2022. It has glass-feeling trackpad and 80% closed speaker holes.
<konradybcio>
are you sure it's still 8280 under the hood at least :P
<_[m]123>
wth I ordered march 23
<danielt>
Which country?
<_[m]123>
Belgium
<danielt>
I think some countries were build-to-order and some where from stock.
<_[m]123>
wtf it's doing bios update for track point ??
<danielt>
Never really figured out how that worked. In UK we used to have loads of build-to-order options and there's almost nothing now.
<_[m]123>
how many new bios' do I need loo
<_[m]123>
it's full bios update seems
<_[m]123>
it only mentioned elantech track point
<_[m]123>
> BIOS Model name: Snapdragon (TM) 8cx Gen 3 @ 3.0 GHz 428 CPU @ 1.5GHz
<_[m]123>
secureboot was off still but linux option too 😧
<_[m]123>
how could I boot ubuntu before, with linux bios option off
<_[m]123>
touchpad scrolling WAY smoother waw - but I liked the other keyboard better, more travel time and needed more pressure
<travmurav[m]>
lacks the .dtb file perhaps?
<travmurav[m]>
though I guess it'd be provided by the bootloader with linux-mode=off
<HdkR>
Definitely will take awhile for M1/M2 to pick up all the SoC blocks since there isn't any vendor support for Linux
<HdkR>
Slowly but surely it is coming
<_[m]123>
sure
<bamse>
jhovold: i figured out how to get display fairly reliably on my x13s...i sit in wayland, connect my display, switch to a VT and then back (this causes the display to be connected, but inactive according to wlroots), i then issue "swaymsg output DP-2 enable"
<bamse>
jhovold: this with linux-next though...
<_[m]123>
what's VT?
<jhovold>
virtual terminal
<Segfault[m]>
<_[m]123> "the touchpad generally is..." <- not great how? it seems really nice afaict
<travmurav[m]>
for anyone interested, I've updated dtbhack.efi to be able to apply overlays and made some overlays for sc7180 (enables venus) and sc8280xp (enables pcie iommu for el2); didn't test anything for sc8280xp but I guess I hope it works given what jglathe_ says
<travmurav[m]>
for sc8280xp need linux 6.8
<Segfault[m]>
oh does it need any kernel updates?
<Segfault[m]>
i'm still on 6.8-rc4 lol
<travmurav[m]>
well rc6 is the last one
<Jasper[m]>
travmurav[m]: Nice, will take a look tonight
<Segfault[m]>
yeah i'll give it a go now, if pcie works i should be able to test it
<_[m]123>
<Segfault[m]> "not great how? it seems really..." <- a bit insensitive?
<Segfault[m]>
hmm, still no pcie with a fresh slbounce/dtbhack build, i guess i need 6.8-rc5 or 6.8-rc6
<travmurav[m]>
did you use the overlays?
<travmurav[m]>
dtbhack.efi your-dtb sc8280xp-symbols.dtbo sc8280xp-el2.dtbo using the files built with make dtbs
<travmurav[m]>
(in the slbounce repo)
<Segfault[m]>
no i just ran dtbhack.efi [dtb]
<travmurav[m]>
the pcie specific bits are in the dt overlays, not in code
<Segfault[m]>
ah
<Segfault[m]>
aha pcie works now
<travmurav[m]>
nice
<Segfault[m]>
yep so no battery info or anything but kvm does appear to be working
<travmurav[m]>
can now poke konradybcio and bamse with Tested-by's for the iommu patch ;)
<Segfault[m]>
maybe soon the remoteprocs will work and we can finally get some logs out of venus :P
<bamse>
travmurav[m]: can you point me to "the iommu patch"?
<travmurav[m]>
still need it to be reserved to boot in el1 but the hardware exists and I think it's easier to drop the status in an overlay/dtsi later
<travmurav[m]>
(as well as we can't just put iommu-map to pcie for now as I assume it would defer without the iommu)
<bamse>
travmurav[m]: ahh, i might have kicked that off the merge queue, as i didn't expect to see a use for that...so please ping me if you/someone do send a tested-by
<Segfault[m]>
kvm seems to work as expected, that's nice
<Segfault[m]>
hey qemu even seems to have fixed its big.little handling since i last used it
<_[m]123>
damn still amazed how well it's working all, no words for the appreciation I feel for everyone that make this possible one step at at time ❤️
<bamse>
Segfault[m]: out of curiousity, do you have a path forward for booting the remoteprocs?
nscnt[m] has joined #aarch64-laptops
<Segfault[m]>
oh no i'm not doing x13s development, i'm just testing things :P
<Segfault[m]>
i'm busy with some other devices and the people doing x13s stuff are far more skilled than i am lol
<_[m]123>
it crashes and falls back (maybe after vt change)
<jglathe_>
I can also give a tested by
<robclark>
bamse, travmurav[m]: oh, interesting, qcom us starting to use smmuv3?
<travmurav[m]>
well, hardware exists and works at least :D
<jglathe_>
tested-by /me
<travmurav[m]>
"use" definition is bendable
<travmurav[m]>
since I have a feeling hyp fw just sets it to identity when you use linux in el1
<travmurav[m]>
which has a funny implication of making pluton/ftpm almost as useless as dtpm I guess
Guest819 is now known as adamcstephens
<robclark>
my impression at least is that smmuv3 would be easier to "virtualize" when using hyp, so I was expecting qc to switch years ago
adamcstephens is now known as Guest1516
Guest1516 is now known as adamcstephens
jglathe_ has quit []
jglathe_ has joined #aarch64-laptops
jglathe_ has quit []
jglathe_ has joined #aarch64-laptops
<jhovold>
dgilmore, steveej[m], danielt: I did some quick hotplug testing earlier today just before heading out and could no longer reproduce the hotplug detect issue I had earlier
<jhovold>
it coult be that the revert that fixed the VT console hotplug issue also fixes the issues I saw with Xorg
<jhovold>
you can try my rc6 wip branch which has that revert and see if things improve
<jglathe_volterra>
oh interesting
<jhovold>
or just revert e467e0bde881 ("drm/msm/dp: use drm_bridge_hpd_notify() to report HPD status changes") yourself
<jhovold>
that revert will be in rc7, so waiting til monday is also an option
<jhovold>
I still hit a hard reset on disconnect with the whole runtime pm series reverted, however, so that issue still remains unfortunately
<adamcstephens>
i'll test my x13s on rc6 once i get it to actually boot
<adamcstephens>
(with hotplugging my dock)
<adamcstephens>
unfortunately i'd apparently drained the battery completely and it's not wanting to actually start
<_[m]123>
hotplug same shit for me
<_[m]123>
on rc6
<_[m]123>
building 6.5
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_ has quit [Read error: Connection reset by peer]
jglathe_sdbox2 has joined #aarch64-laptops
apalos- is now known as apalos
<_[m]123>
why I built 6.5 lol it's 6.6 right last good one
<jglathe_sdbox2>
6.7.1 is nice, too
<_[m]123>
maybe I'll boot the one of debian experimental
<_[m]123>
```
<_[m]123>
6.7.5+
<_[m]123>
# uname -r
jglathe_sdbox2 has quit [Remote host closed the connection]
<jhovold>
_[m]123: you shouldn't need to go further back than 6.7 (to avoid the dp regressions in 6.8-rc1)
<jhovold>
if your external display doesn't work with 6.7 then that's some other issue
jglathe_sdbox2 has joined #aarch64-laptops
<_[m]123>
yeah my brain is in Friday-mode though I thought I read of some issues on 6.7 too, can't clearly remember, let's see - I'm also now connected directly with hdmi and usb c adapter to rule out the docking
<_[m]123>
it works on all, just randomly fails, maybe micro disconnect because of usage of the usb c extension cable - I might order another
jhovold has quit [Ping timeout: 480 seconds]
<steev>
there was a v2 of the pd mapper in kernel implementation sent, however, dmitry already noticed a few issues after he submitted, and said a v3 would be coming, so i'll wait for that to apply it
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
<jglathe_volterra>
@jhovold I tested the 6.8-rc6 branch: my bluescreen issue is there, so a little dangerous to use, still on 6.7.1 on this Volterra. X13s is on 6.8-rc6 including the patch you reverted, no real issues but its only internal display. sdbox2 is on 6.8-rc6 on EL2, no issues with display on DP. Working fine. All boxes on rc6 se the clk on / clk off dance on some events, USB-C plug, DP hotplug, update of firefox (what)
jglathe_ has joined #aarch64-laptops
rfs613 has quit [Ping timeout: 480 seconds]
rfs613 has joined #aarch64-laptops
<_[m]123>
```
<_[m]123>
[ 6385.012990] [drm:dp_ctrl_link_train [msm]] *ERROR* max v_level reached
<_[m]123>
[ 6385.013067] [drm:dp_ctrl_link_train [msm]] *ERROR* link training #1 failed. ret=-11
<_[m]123>
with the dock
<_[m]123>
hotplug works with direct connection seems
<bamse>
robclark: sc8280xp has the pcie controllers behind a dedicated smmuv3 instance
<jglathe_>
yep
jglathe_volterra has quit [Remote host closed the connection]