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]
<dianders> jhovold, steev, bamse, konradybcio: Any of you able to give a Tested-By for Neil in response to https://lore.kernel.org/r/6acd8776-cc59-496a-ad80-47613a8283a3@linaro.org
<steev> dianders: 845?
<steev> oh, x13s, sure give me a few
<steev> my build server is currently taking 8 hours to build arm64 images so i have "some free time"
<dianders> steev: I think that would work. Basically he's looking to make sure my patch didn't break anything "on the X13s or other Laptop using eDP"
<dianders> steev: In https://lore.kernel.org/r/CAD=FV=WwfB=u2DVE0ux9cD3OCCccgcWCdJBxW2-9gg4qSFSv+A@mail.gmail.com I included some commands you could do if you wanted to do more than just "hey, my panel still lights up". :-)
<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...
<javierm> dianders: ah, I see
<javierm> bamse: speaking of which, did you ever find time to think about https://github.com/andersson/rmtfs/pull/19 ?
jglathe_sdbox2 has quit [Remote host closed the connection]
jglathe_ has quit [Remote host closed the connection]
jglathe_sdbox2 has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
<steev> javierm: dianders: c630 looks fine too
<dianders> steev: Much appreciated, as always!
f_ has quit [Read error: Connection reset by peer]
f_ has joined #aarch64-laptops
hexdump0815 has quit [Read error: Connection reset by peer]
hexdump0815 has joined #aarch64-laptops
rz has quit [Ping timeout: 480 seconds]
rz has joined #aarch64-laptops