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)
sri has joined #aarch64-laptops
<steev> jenneron[m]: testing your kernel here, no gpu, but that's not too surprising, i'll go through my older stuff and see whats what some time this week. i pushed out the bluetooth patches and hopefully someone can take that base and figure out whats going wrong there
<steev> bluetooth for the thinkpad*
<steev> additionally, that frame enc timeout also happens/happened with 5.19.0 rc8 or whatever i was running previously, so it's definitely not something new
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
GuildedThorn has joined #aarch64-laptops
<jenneron[m]> steev: do you mean no GPU on flex 5g?
janrinze has quit [Ping timeout: 480 seconds]
janrinze has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo1 is now known as alfredo
pierro78 has joined #aarch64-laptops
<pierro78> <jenneron[m]> pierro78: hi, does battery work when you boot galaxy book s with ACPI? => I reported on https://github.com/aarch64-laptops/debian-cdimage/issues/16#issuecomment-1231898585 : battery charging doesn't work (but I am not sure if I use acpi)
<jenneron[m]> pierro78: no need to keep usb sticks in usb ports <- means it is DT booting
<jenneron[m]> iirc you tried acpi on 5.11
<jenneron[m]> i'm just curious if we have ACPI driver for battery (would be good to find someone with i5 version of this laptop to check it)
<jenneron[m]> if we don't, i'm not sure it is doable without reverse-engineering windows drivers and that's a thing i'm not interested in at all
<jenneron[m]> i'm not expert at ACPI, but reading it i see that it has some EC sitting on five i2c buses and it probably controls charging
<jenneron[m]> given that flex 5g patches for battery don't give working battery, i bet charging is controlled by EC
<jenneron[m]> pierro78: if you still have installation with 5.11 kernel, please boot it, check whether battery works and send dmesg and lsmod
alfredo has quit [Ping timeout: 480 seconds]
<jenneron[m]> qzed: btw, can we put some efforts to have common tree until everything is upstreamed? it is a bit inconvenient to have 3 branches for 3 devices
<pierro78> jenneron[m] : https://github.com/aarch64-laptops/debian-cdimage/issues/16#issuecomment-1231898585 is with your kernel (I believe it was 5.19 at that time)
<pierro78> It's still working if you want me to check stuff
<jenneron[m]> pierro78: sorry, I didn't explain it well
<jenneron[m]> I'm asking whether battery worked for you on 5.11 without device tree
<pierro78> I believe I still have 5.11 but this needs 2 usb sticks to boot ... do you want me to check stuff in this configuration ?
<jenneron[m]> yes please
<pierro78> OK I ll try to do it today as I am busy now
<pierro78> (later today)
<jenneron[m]> that's fine
iivanov has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
kettenis has quit [Remote host closed the connection]
kettenis has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov_ has quit []
iivanov_ has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov_ has quit []
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
akaWolf0 has quit [Read error: Connection reset by peer]
akaWolf0 has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
juergh[m][m] is now known as tmp[m]
tmp[m] is now known as juergh[m]
<qzed> jenneron: If you want to create/manage a repo I can send patches or PRs your way
alfredo has quit [Ping timeout: 480 seconds]
<pierro78> <jenneron[m]> pierro78: if you still have installation with 5.11 kernel, please boot it, check whether battery works and send dmesg and lsmod => apparently battery is not working (drawing 0 Watt of Power from my charger, battery was about 60% and draws 34W when charging) ... here are the pastebins anyway https://paste.debian.net/1268976 https://paste.debian.net/1268977
alfredo has joined #aarch64-laptops
<jenneron[m]> ok, thanks
<jenneron[m]> <qzed> "jenneron: If you want to create..." <- the problem is that your patches are based on an outdated patchset
<jenneron[m]> if you rebase it over https://gitlab.com/jenneron/linux/-/commits/139928d87bfed40c4e77a0911818b6aff68e6be5/, i can take your rebased branch and put galaxy book s and additional flex 5g patches over it
<jenneron[m]> link above is basicaly sc8180x-next-20220728 patchset from andersson + replaced glink patches with a newer one from lkml
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
Vectorboost has joined #aarch64-laptops
Vectorboost has quit []
alfredo has quit [Read error: Connection reset by peer]
pierro78 has quit [Quit: Page closed]
<qzed> jenneron: I've updated my spx/v6.1 tree: https://github.com/linux-surface/kernel/commits/spx/v6.1
<qzed> the patches for UEFI vars are
<qzed> that should work with your 6.1.7-based one
<jenneron[m]> qzed: sorry, i probably was not clear
<jenneron[m]> these are actually different patches
<jenneron[m]> and the patch in your tree seems to be older, so there are conflicts when trying to apply something over it
<qzed> ah, I haven't touched anything that isn't used on the spx in ages...
<jenneron[m]> i mean this https://gitlab.com/jenneron/linux/-/commits/139928d87bfed40c4e77a0911818b6aff68e6be5/ should be good enough to rebase on
<qzed> you could "git cherry-pick" anything beyond the base patches from bamse
<jenneron[m]> i will push it separately
<qzed> I'll have a look at those, but I'd prefer to keep the linux-surface tree to the minimum on SPX (preferably with some justifications why which patch is required)
<qzed> but I'll try to update the commits I already have (like the flex dts)
<steev> i suppose we could always submit the stuff to upstream... i've seen people do that? seems like you do From: <original author> at the start of it?
<qzed> for example I'm not sure whether the type-c stuff is necessary on the SPX since it uses something that is integrated with its EC
<steev> it would be nice to get things flowing into upstream but i do think the rpmhpd stuff needs to be looked at closer (if it's still needed)
<qzed> yeah, the problem is that I don't know whether half of the stuff I have is still required or not :/
<jenneron[m]> qzed: in this case it may be good enough for you to rebase on https://gitlab.com/jenneron/linux/-/commits/ad50dd73ca1a178039e0af441aea00d800a4acc6/, and i should be able to merge everything else above your rebased branch
<jenneron[m]> and then i will just keep rebasing on your branches in the future
<steev> jenneron[m]: and yeah, the gpu isn't working for me with your branch, i haven't had a chance to dig deeper though; https://paste.debian.net/hidden/bcaa4ab2
<qzed> jenneron: depending on what specifically you want, you could just do something like
<steev> i have some patches around here somewhere that i should try to dig up
<qzed> git cherry-pick "ad89bc0c82c359600fd1a8d2131d682839569eeb^..c5ece1fa62ae5fa42c621fc980fd61724b587b9c"
<qzed> assuming you've added https://github.com/linux-surface as remote and updated it with git fetch
<jenneron[m]> definitely works for me^
<jenneron[m]> qzed: yes, that's what results in merge conflicts
<steev> jenneron[m]: hm, are you just using the defconfig?
<jenneron[m]> because your patches are based on another version of sc8180x.dtsi
<jenneron[m]> steev: no, i use my own config, but it's DT-only
<qzed> huh, sc8180x.dtsi also had an update?
<steev> i don't acpi boot either, not sure what you mean by dt only
<jenneron[m]> maybe the typo was fixed
<jenneron[m]> didn't look there, because there may be many things to resolve and i can mess up it
<jenneron[m]> steev: i mean if you're asking for my config, it is not going to work with ACPI in case you need it
<jenneron[m]> but according to your kmsg gpu should work
<steev> i haven't done an acpi boot of the flex since the installer ran :)
<bamse> jenneron[m]: the linux gpu/display/video driver does not know how to run off those acpi tables
<qzed> urgh... so trying to rebase on bamse's wip/sc8180x-next-20220728 causes a deferred probe timeout for the edp stuff
<qzed> any ideas?
<ajhalaney[m]> absolute blind stab in the dark but depending on your config (and my loose understanding of things) could be this qzed https://lore.kernel.org/linux-arm-msm/20221116115348.517599-1-javierm@redhat.com/
<ajhalaney[m]> the last patch explains a bit which may or may not help you :)
<qzed> I'll give that series a try but I'm not too hopeful, the difference must be in a small set of patches that I've updated
<qzed> essentially between
<qzed> and
<qzed> but the issue was more or less present before, it just occurred only sometimes and now it's every time...
Mathew has joined #aarch64-laptops
mcbridematt has quit [Read error: Connection reset by peer]
<javierm> qzed: may be worth to test with deferred_probe_timeout=30
<qzed> tried that already, but I think I've found the culprit:
<qzed> sc8180.dtsi got updated, which set dispcc to be disabled by default
<qzed> naturally my surface-pro-x.dts doesn't enable that...
<steev> that would do it
<javierm> indeed
<qzed> yep.... that was it...
<selmer443[m]> Is gpu working on x13s yet by chance? I haven’t had a chance to keep up with what’s been goin on
<steev> no
<selmer443[m]> Dang, I thought I saw that some progress had been made though?
<qzed> hmm, so things on 6.1.8 mostly work... except that every time the display goes off it complains about "disp_cc_mdss_edp_aux_clk status stuck at 'on'"
<qzed> and suspend somehow breaks drm
<qzed> [dpu error]enc31 intf5 ctl 3 reset failure: -22
<qzed> but those things might have been an issue before
<qzed> okay... maybe a couple more issues regarding drm stuff...
<qzed> (related to turning the panel off)
<steev> it's being worked on, but i don't know if we're any closer or not
<steev> the last i knew, gmu was refusing to power up
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<qzed> this seems to fix the display-off warning and subsequent DRM failures: https://github.com/linux-surface/kernel/commit/8ce4203425f2bbd2fdcc6807bb946dbe8a856b4a
<qzed> but no idea whether that's a good idea...
<qzed> hmm... I think with that change suspend also works fine, at least once
<qzed> the second time it doesn't want to resume...
<qzed> but enough for today on that...
<steev> anyone running next? i am seeing an odd issue and i have... nfi
<steev> if i try to run firefox, i just get zsh: bus error: firefox; as soon as i switch back to a 6.2 rc... it's fine?
<qzed> today's next seems to work fine on my SPX
<qzed> at least I can run firefox...
<steev> it's the only thing i can't run, and i don't have any idea why
<steev> nothing in dmesg to indicate why
<qzed> weird
<steev> http://sprunge.us/dBDZjc is the strace (i haven't looked closely yet)