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
<steev>
huh. just ran into the wifi crash on 6.7.6 here for the first time
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
vkoul- is now known as vkoul
jglathe_volterra has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
Guest416 has quit [Quit: WeeChat 4.2.1]
martin has joined #aarch64-laptops
martin is now known as Guest1021
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold>
Jasper[m]: that hard lock up on suspend you saw with the fedora kernel looks scary
<jhovold>
first time I see anything like that, let's hope it's due to something in the distro kernel...
<jhovold>
I assume you've only seen it once, and only with the fedora rc5 kernel?
<Jasper[m]>
jhovold: Yes, though I haven't checked dmesg in a while, I just remembered to check that time since wifi disconnected
<Jasper[m]>
without recovering
<jhovold>
i'll try to find some time to look closer at the logs at some point, but there's too much going on right now
<jhovold>
steev: which ath11k fw version did you see the resume crash with?
<jhovold>
you were using an older version before from before the suspend regression that .36 and .37 were supposed to fix IIRC
<Jasper[m]>
<jhovold> "i'll try to find some time to..." <- Yeah np, not having any general issues atm anyways
jglathe_ has quit [Quit: Leaving]
<steveej[m]>
regarding x13s kernel: i'm back on jhovold's 6.7.0 coming from 6.8-rc5 and my docking issues have improved significantly. i'm happy i've got a set up that is a feasible daily driver :-) if there's a promising fix on newer kernels please ping me and i can test and report back. i can also send a spare dock to someone for testing if that's helpful.
alpernebbi has quit [Ping timeout: 480 seconds]
<jhovold>
steveej[m]: thanks for confirming, i'm trying to get the drm developers to fix the remaining regressions they introduced in 6.8-rc1 (e.g. the random hard resets and DP hotplug)
<jhovold>
but since we're at rc6, and they still haven't come up with any solutions, it seems we may need to revert
<steveej[m]>
jhovold: great. thanks for your work! i highly appreciate it. i'm really excited to work on an arm64 laptop and will be even more so when it has full stable support
<jhovold>
steveej[m]: thanks, glad to hear that
<steveej[m]>
btw. does lenovo sponsor any of this? once everything works you'll have done them a huge favor IMO
<jhovold>
steveej[m]: lenovo is not funding any of this (Arm is), but they have provided some hardware and help with getting firmware released, etc
<jhovold>
there's some more background and details about the project in my kernel recipes talk:
<_[m]123>
sad to read they're not supporting this more though, as if they're unaware of the linux enthusiasts buying thinkpads
<jhovold>
_[m]123: but by proving that it's possible to run mainline on one of these machines as we're doing here, hopefully they and other OEMs (and Qualcomm) will eventually change their minds
<_[m]123>
are we that few that the business doesn't care? or is it just corpo stuck-in-our-ways
<_[m]123>
tbh, in our DCs we have energy issues and electricity got way more expensive, when I try to push for e.g. running container orchestration on arm I get total fckng apathy lol - like yeah who would want to spend less on recurring costs
<jhovold>
don't know, but with support mostly already upstream, the answer to such questions may change
<_[m]123>
so I cna imagine very well it's corpo humans
<_[m]123>
maybe we could en masse send such requests?
<_[m]123>
ofc we should've done this december lol
alpernebbi has joined #aarch64-laptops
<_[m]123>
* ofc we should've done this q4 23 lol
<Jasper[m]>
<jhovold> "don't know, but with support..." <- not to mention x1e0800 support pre-release
<jhovold>
yeah, that's a step in the right direction, at least as long as the code they push is up to par from the start
<jhovold>
but a lot of the work we do on the X13s will benefit later platforms directly
<_[m]123>
that's nice to read, it's hard to gauge how enabling this all is from my side 🙂
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
<jglathe__>
one could assume a shift in strategy. The effort to create these devices was ginormous, you would wand as big a market as possible
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
echanude has joined #aarch64-laptops
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #aarch64-laptops
<steev>
jhovold: .37
<jhovold>
as dgilmore and other have reported, there still appears to be some issues in the .37 release
<jhovold>
but since you've updated your fw, that probably explains why you're now seeing the resume issue for the first time
<steev>
yeah, looks like debian testing still has .23 which is what has been solid for me (aside from the msdu unset bit when connected to my at&t wifi router)
<steev>
but i don't think that's firmware side
jglathe__ has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<jhovold>
steev: ok, why not? I guess you never did described the symptoms you were seeing.
<steev>
jhovold: it's not a symptom, it's the bug on bugzilla - `ath11k_pci 0006:01:00.0: msdu_done bit in attention is not set` spam - but it only happens here at home that i've noticed, it doesn't happen at my sister's place with a different ISP/router (and i haven't set up a new router because of knowing i was gonna move)
<jglathe_x13s>
X13s is on v6.8-rc6 now. With pd_ignore_unused clk_ignore_unused arm64.nopauth efi=noruntime drm.debug=0x100 "dyndbg=file drivers/base/firmware_loader/main.c +fmp"
<jhovold>
steev: ah, ok, i thought you were referring to the crash on resume
<steev>
ah, no, sorry, i only just saw it last night for the first time
<jglathe_x13s>
Still shows some odd [drm:dp_power_clk_enable [msm]] enable clocks for DP_CORE_PM, [drm:dp_power_clk_enable [msm]] disable clocks for DP_CORE_PM pattern, with [drm:drm_dp_dpcd_probe [drm_display_helper]] dpu_dp_aux: 0x00000 AUX -> (ret=-110) eventually
<jglathe_x13s>
Only internal display, it's on the whole time
<steev>
jglathe_x13s: maybe poke around in #freedreno ? lumag and abhinav hang out there
<jglathe_x13s>
will do
jhovold has quit [Read error: Connection reset by peer]
jhovold has joined #aarch64-laptops
push has quit [Read error: Connection reset by peer]
push has joined #aarch64-laptops
martiert has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
krei-se- has quit [charon.oftc.net helix.oftc.net]
xnox has quit [charon.oftc.net helix.oftc.net]
f_ has quit [charon.oftc.net helix.oftc.net]
Caterpillar has quit [charon.oftc.net helix.oftc.net]
minecrell has quit [charon.oftc.net helix.oftc.net]
svarbanov has quit [charon.oftc.net helix.oftc.net]
baspar[m] has quit [charon.oftc.net helix.oftc.net]
ema has quit [charon.oftc.net helix.oftc.net]
konradybcio has quit [charon.oftc.net helix.oftc.net]
sporos11[m] has quit [charon.oftc.net helix.oftc.net]
harvests[m] has quit [charon.oftc.net helix.oftc.net]
danielt has quit [charon.oftc.net helix.oftc.net]
Bioxvirizm-x13s[m] has quit [charon.oftc.net helix.oftc.net]
dcavalca has quit [charon.oftc.net helix.oftc.net]
harvestz[m] has quit [charon.oftc.net helix.oftc.net]
mynery[m] has quit [charon.oftc.net helix.oftc.net]
matthew[m]12 has quit [charon.oftc.net helix.oftc.net]
LoganLeland[m] has quit [charon.oftc.net helix.oftc.net]
exeat has quit [charon.oftc.net helix.oftc.net]
krei-se has joined #aarch64-laptops
LoganLeland[m] has joined #aarch64-laptops
exeat has joined #aarch64-laptops
xnox has joined #aarch64-laptops
minecrell has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
baspar[m] has joined #aarch64-laptops
f_ has joined #aarch64-laptops
ema has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
sporos11[m] has joined #aarch64-laptops
harvests[m] has joined #aarch64-laptops
danielt has joined #aarch64-laptops
Bioxvirizm-x13s[m] has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
harvestz[m] has joined #aarch64-laptops
mynery[m] has joined #aarch64-laptops
matthew[m]12 has joined #aarch64-laptops
minecrell2 has joined #aarch64-laptops
f__ has joined #aarch64-laptops
f__ is now known as funderscore
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
ungeskriptet is now known as Guest1106
ungeskriptet has joined #aarch64-laptops
f_ has quit [Ping timeout: 480 seconds]
minecrell has quit [Ping timeout: 480 seconds]
Guest1106 has quit [Ping timeout: 480 seconds]
funderscore is now known as f_
iivanov has quit [Quit: Leaving...]
<Jasper[m]>
Huh, that screen corruption issue seems to be gone
<Jasper[m]>
though I'm not too sure yet, I've seen it pop up before
jglathe_sdbox2 has joined #aarch64-laptops
<jglathe_sdbox2>
Volterra EL2 box has display again, and PCIe (WLAN, nvme)
<Jasper[m]>
WLAN doesn't have the remoteproc issue?
<jglathe_sdbox2>
what remoteproc do you mean
<Jasper[m]>
Isn't WLAN also a remoteproc? Isn't it affected by the lack of hyp?
<jglathe_sdbox2>
the remoteprocs are not booted up
<jglathe_sdbox2>
WLAN is ath11k_pci
<Jasper[m]>
Or rather, the lack of a stock setup
<jglathe_sdbox2>
you need the arm-smmuv3 to be active
<Jasper[m]>
jglathe_sdbox2: Ah, well I thought it'd still technically be one, my bad
<jglathe_sdbox2>
for mhi to work
<jglathe_sdbox2>
and dma
jglathe_ has joined #aarch64-laptops
jglathe_sdbox2 has quit [Ping timeout: 480 seconds]
<steev>
oh i do recall seeing that email, and meant to; i'll also test on the c630, but it'll be 6.7 if thats okay?
jglathe_sdbox2 has joined #aarch64-laptops
<javierm>
dianders: I didn't test it because only have a Chromebook and a eizan already did there
<javierm>
steev: yeah, I think is OK. AFAIU folks just want to make sure that won't cause issues on other platforms
<dianders>
javierm: No worries, thanks. Somehow I was under the impression that you had other eDP hardware that you worked with but I guess I was mistaken.
<dianders>
steev: Yeah, I think it'll be fine, thanks!
<steev>
i do have display on the x13s
<javierm>
dianders: yeah, I don't have a x13s yet
<javierm>
steev: cool, I think that would be enough to make Neal happy :)
<javierm>
if you can answer with your t-b
<steev>
huh, for some reason, i don't have any of the followups, just the original. btw, is there any specific reason why my built in display is aux2 not 1 or 0?
<steev>
oh, because you sent it not doug
<steev>
javierm: so, assuming i'm reading this correctly, i should get edid when the display is on, and dev/resource busy if off?
<javierm>
steev: that's my understanding, yes
<steev>
sent :)
<javierm>
and without dianders' patch it should take some time to timeout
<steev>
it's about 24 seconds to run the hexdump on /dev/drm_dp_aux2 (internal display), 8 seconds on 0/1 (which don't have anything); 0.01s to d/r busy with display off
<dianders>
steev: Thanks! Yeah, without my patch it should be a long timeout to try to access the AUX bus when the display is off. ...or it's possible that it might have actually "worked" to do a transfer on the AUX bus when the display was off if something else (like a touchscreen) was keeping power onto the screen.
<javierm>
steev: thanks but it was Doug who posted, not me :)
<javierm>
dianders: people also usually boot with "clk_ignore_unused pd_ignore_unsed" which may be made it work due luck
<dianders>
javierm: It's a regulator though, not a clock.
<dianders>
...and not a PD either
<javierm>
dianders: ah, pd_ignore_unused then :)
<javierm>
err, regulator_ignore_unused I meant
<dianders>
javierm: Ah, OK. Even then I don't _think_ that would make it work due to luck. ...because the eDP should grab the regulator and it won't be unused anymore.
<javierm>
dianders: gotcha
<dianders>
javierm: I could see the transfers work w/ the screen off on trogdor devices that have a touchscreen if they aren't using the "panel follower" code. Right now _some_ lazor-limozeen devices are like that since I didn't add panel follower support for "elan,ekth3500" style touchscreens...
<javierm>
dianders: I see. I have a trogdor and probably why didn't experience that issue then
<dianders>
javierm: Which model trogdor device do you have again? I don't think anyone actually has the reference board.
<dianders>
javierm: ...ah, from the email thread looks like coachz
<javierm>
dianders: yes, rev3
<javierm>
I think you already dropped rev0 dts ?
<javierm>
dianders: it's working nicely with Fedora, we even support Wifi now :)
<dianders>
javierm: So coachz _does_ have panel follower, but that's somewhat recent (dts landed in 6.7?). So on 6.6 coachz will never really get the slow timeouts because it has a touchscreen and _didn't_ have panel follower, so the touchscreen would always keep things powered.
<dianders>
javierm: On 6.7 coachz will start seeing the timeouts if you try an AUX transfer with the screen off.
<dianders>
javierm: ...but trogdor devices that don't have a touchscreen would _always_ have had the timeouts if you did AUX transfers w/ the screen off...