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)
bamse has quit [Server closed connection]
bamse has joined #aarch64-laptops
bamse is now known as Guest287
_whitelogger has joined #aarch64-laptops
Mathew has quit [Server closed connection]
Mathew has joined #aarch64-laptops
<gwolf> calebccff: That's where I found it at least!
<gwolf> steev: Under pwd/sys/devices/platform/soc@0/8c0000.geniqup/884000.i2c/i2c-1/1-0070/power_supply I have two devices -- yoga-c630-adapter and yoga-c630-battery
rfs613 has quit [Server closed connection]
rfs613 has joined #aarch64-laptops
CosmicPenguin has quit [Server closed connection]
CosmicPenguin has joined #aarch64-laptops
<steev> Ah, so it’s working for you :)
<steev> Also… I figured out my next issue. It doesn’t like efi_zboot
lool has quit [Server closed connection]
lool has joined #aarch64-laptops
ndec has quit [Server closed connection]
ndec has joined #aarch64-laptops
steev has quit [Server closed connection]
steev has joined #aarch64-laptops
pundir has quit [Server closed connection]
pundir has joined #aarch64-laptops
gwolf has quit [Server closed connection]
gwolf has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
swgws_ has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
swgws has quit [Ping timeout: 480 seconds]
swgws has joined #aarch64-laptops
swgws_ has quit [Ping timeout: 480 seconds]
dgilmore has quit [Server closed connection]
dgilmore has joined #aarch64-laptops
<steev> guess i forgot the firmware :( got all excited for a second since the display didn't stay dead lol
shawnguo has quit [Server closed connection]
shawnguo has joined #aarch64-laptops
mcbridematt has joined #aarch64-laptops
Mathew has quit [Ping timeout: 480 seconds]
alpernebbi has quit [Server closed connection]
alpernebbi has joined #aarch64-laptops
robher has quit [Server closed connection]
robher has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
jhugo___ has quit [Server closed connection]
jhugo___ has joined #aarch64-laptops
_alice has quit [Server closed connection]
_alice has joined #aarch64-laptops
ardb has quit [Server closed connection]
ardb has joined #aarch64-laptops
dianders has quit [Server closed connection]
dianders has joined #aarch64-laptops
pbsds0 has quit [Server closed connection]
pbsds0 has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
arnd has quit [Server closed connection]
arnd has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
<HdkR> steev: Almost a GPU? :D
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
cmeerw[m] has quit [Server closed connection]
cmeerw[m] has joined #aarch64-laptops
djakov has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
Leandro[m] has quit [Server closed connection]
Leandro[m] has joined #aarch64-laptops
jenneron[m] has quit [Server closed connection]
jenneron[m] has joined #aarch64-laptops
Lucanis0 has quit [Ping timeout: 480 seconds]
harvestz[m] has quit [Server closed connection]
harvestz[m] has joined #aarch64-laptops
NomadNaomie[m] has quit [Server closed connection]
NomadNaomie[m] has joined #aarch64-laptops
Guest287 is now known as bamse
<steev> HdkR: dunno, could be that when i throw the firmware into place, we're back to no display :D
<HdkR> Would be such a shame
<ardb> steev: does your zboot issue involve grub and a magic number check?
<steev> ardb: yes
<steev> just says invalid magic number
<ardb> yeah that is fixed in upstream grub
<ardb> i'll poke steve to see if we can get it backported
<steev> ah, that may be coming down soon
<steev> there was a 2.06-2 (i think)
<steev> i'm on debian testing (essentially)
<steev> 2.06-5 actually - the flex5g just downloaded it :D
matthias_bgg has quit [Ping timeout: 480 seconds]
<steev> thanks :)
<ardb> it will work if you put the "ARM\x64" magic number in the zboot header
<init> with 6.1-rc7 I don't have a display if my power cord is not plugged in. Haven't had time to debug, but it makes no difference if I boot with or without it. It needs to be plugged in.
<init> on x13s. of course.
<init> X will start with the xf86-video-fbdev driver for now.
<init> battery level is now also missing (from 6.0-rc4), so that might all be related
<init> but like I said, I had about 10 minutes of testing since booting it yesterday
<steev> definitely don't experience that here
<steev> but i'm using wayland, not x, so not sure
<steev> i'd check the xorg log, i'm assuming it's something modesetting related
<steev> iirc, we saw some issues with hyper-v not being able to start x on kali too and it's due to the modesetting not working anymore and having to force fbdev
matthias_bgg has joined #aarch64-laptops
systwi_ has joined #aarch64-laptops
<Caterpillar> I am collecting infos about Thinkpad X13s in this wikipage https://fedoraproject.org/wiki/Thinkpad_X13s
systwi has quit [Ping timeout: 480 seconds]
<krzk> maybe elinux.org?
<steev> tehre's also ironrobin's wiki on it
<steev> also the "wifi working" is a bit of a misnomer - it works because of a hack where we report ourselves as something different
<Caterpillar> steev: thx
matthias_bgg has quit [Quit: Leaving]
<init> quickly looking at it, it's quite weird that X started in fact :>. I have a "wayland conditions error" that seems to prevent wayland from starting
<steev> maybe an llvm change and it dislikes the new llvmpipe/mesa stuff?
<init> dunno. I'll turn on debugging and look at the logs.
<steev> that would be good to get :)
<init> I ran a very custom kernel config, just so I can get to learn a bit more about this platform. I took back a working config from 6.0-rc4 and I'm building a version out of it. Lazyest way to figure out if I messed up something, before digging.
aceridus has joined #aarch64-laptops
<steev> when it would go to start X, would you essentially just have a cursor in the upper left corner?
<init> it just basically skips wayland for some execution conditions reasons, and starts X successfully.
<init> even if I force wayland in every single way i can
<steev> odd
<steev> definitely using wayland here
<init> it ran fine on 6.0-rc4. the chances I've messed up something by myself are very high.
<steev> this is on 6.1.0-rc7 so defnitely possible :)
<init> This is what the pleasure is all about
Mathew has joined #aarch64-laptops
mcbridematt has quit [Ping timeout: 480 seconds]
<steev> truth
aceridus is now known as help
help has quit [Quit: Page closed]
aceridus has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
<init> nice
da_snowbird has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
<calebccff> steev: yeah got battery working!
<steev> Yeah, I have that in my 6.0, need to push
<init> steev: https://imgur.com/a/B5mVyvh back to normal
<init> I had disabled some important features :P
<steev> Forbidden calebccff
<steev> init: good to hear
<init> now back to breaking it with custom patches!
<init> Now what I sort of was forced to try it for a day or two, X11 definitely runs way smoother than Wayland on software rendering.
<init> on that hardware
<init> not that i'm a big fan of the past, but as we're waiting for some sort of gpu support, that's not a bad alternative
<steev> Okay, 6.0.10 pushed, tagged as lenovo-x13s-6.0.10,
<steev> Includes the audio bits
<steev> You’ll need the firmware, and I’m not sure if the ucm2 bits have been pushed out yet
<bamse> steev: not sure if i complained to you about the x13s caps-as-ctrl didn't work properly...booted windows and let it do a few firmware upgrades, now it does work as i want it to
<bamse> steev: problem before was if i hit caps+<c, c> i wouldn't get two ^C, i would get ^C c
<steev> I think I remember something like that
<bamse> should have listened to you and done the upgrade ealier ;)
<steev> :D
<steev> they've done a pretty decent job staying on top of bugs with the x13s
<steev> which makes me happy compared to... other devices bugs in their firmware
<clover[m]> <steev> "Includes the audio bits" <- are you telling me audio works now?!
<clover[m]> is christmas early
<steev> i said it includes them
<steev> i didn't say it works
<steev> it doesn't work for me, but maybe others will, and we can figure out what the difference is
<clover[m]> lol ok, will try after work
<steev> assuming the ucm2 stuff is available somewhere
<steev> but lets see if it even works for people, and doesn't just probe defer :D
<steev> there are new config options needed for it
<steev> bamse: since you're around... if gmu is throwing -13... what did i screw up?
da_snowbird has quit [Quit: Vision[]: i've been blurred!]
<steev> i bet it's something silly like, i left the amd,imageon compatible in the
<bamse> steev: i seem to get the same if mdss probe deferred...
<steev> ilooked, no deferrals here
<steev> do you know if kalle has had any luck tracking down a board file? 25 packets transmitted, 13 received, 48% packet loss, time 28457ms
<javierm> steev: you do have a probe deferral in your log, i.e:
<javierm> [ 2.961650] msm_dpu ae01000.display-controller: [drm:msm_drm_bind] *ERROR* kms hw init failed: -517
<javierm> steev: I would guess that there's some error in the runtime pm usage. Maybe some PM usage count is not properly decremented in the probe deferral path?
<steev> javierm: yes but
<steev> steev@cho:~$ sudo cat /sys/kernel/debug/devices_deferred
<steev> steev@cho:~$
<steev> oh
<steev> maybe
<javierm> steev: that will only show something if the probe deferral timeout didn't expire
<javierm> I really don't like that new probe deferral timeout behaviour :(
<bamse> steev: i've not seen any update on the board file front...did poke the discussion before i went on vacation though
<steev> i would assume it would continueto show as long as the device is deferred
<steev> vacation smh... you europeans and your lack of work ethics :P
<javierm> steev: that was my assumption to. But I learned the other day digging on the display issue that's not the case
<steev> javierm: that gives me something to look around, i didn't notice that earlier, thanks for pointing it out
<javierm> steev: because if timeouts, then the device model assumes that the probe "failed" with a normal errno code...
<steev> javierm: hm, so is there a way to tell if it's actually still deferred?
<javierm> steev: no that I know of
<javierm> steev: in other words, there's no way to distinguish between a driver's probe that failed and one that failed because the probe deferral mechanism just timed out
<bamse> steev: was 8 years since we visisted sweden last, so it was time... :)
<steev> enjoy :)
<steev> javierm: erk
<steev> that's not very good
<bamse> steev: i did enjoy it, got back last night
<steev> ahh
<steev> i miss ostkaka :(
<javierm> steev: what you can do though is boot with deferred_probe_timeout=60 or something and then you will prevent the timeout and see what was deferred and why
<bamse> steev: sweden was kind to remind me how miserable the weather is...even got a couple of inches of snow last weekend...and then back to rain
<steev> javierm: good point, i guess i can try that - i was thinking also just disable runtime pm to see
<steev> javierm: it's still gone
<steev> once it hits 3.11, the deviceis either there?
<javierm> steev: so nothing from /sys/kernel/debug/devices_deferred even without the timeout?
<steev> correct
<bamse> steev: what are you missing?
<bamse> [ 3.104165] msm_dpu ae01000.display-controller: [drm:msm_drm_bind] *ERROR* kms hw init failed: -517
<steev> bamse: dunno, kms defers, then a big later, gmu complains, then gpu is like lol no
<javierm> steev: it seems the last error is "Couldn't register GPU cooling device"
<steev> bamse: indeed, but it's not showing up
<bamse> right, display reprobes nicely, but gpu is bad
<steev> javierm: yeah, but i definitely can't figure that part out :(
<bamse> javierm: that one is "standard"
<javierm> bamse: ah, a red herring then. Not fatal
<steev> i'm thinking...
<bamse> steev: we had another -13 problem not so long ago, where the pm_runtime refcount decremented twice...
<bamse> steev: but i checked and we have the patch for that at least
<bamse> steev: i mean, we had two pm_runtime_put() calls in the probe deferal path of the gpu
<steev> do you recall whe that was?
<steev> where
<javierm> bamse: yeah, I think that this is the problem but that only happens in the error path and that's why the probe deferral exposes it
<javierm> not balanced PM usage count
<steev> ah, there's steve's patch about not doing it in gdsc
<bamse> hmm, i don't find the patch that i was thinking of in the git log...
<steev> clk: qcom: gdsc: Remove direct runtime PM calls maybe?
<bamse> no, it was in drivers/gpu/drm/msm/adreno/*
SSJ_GZ has quit [Ping timeout: 480 seconds]
<steev> hm, so it could just be that it hates my firmware
<javierm> steev: what I did to prevent the probe deferral btw was to have all the CONFIG_SC_*_7180 clk controller drivers built-in
<steev> those alaedy are here
<javierm> steev: ah, Ok
<steev> CONFIG_SC_GCC_8280XP=y
<steev> CONFIG_SC_DISPCC_8280XP=y
<steev> CONFIG_SC_GPUCC_8280XP=y
<steev> if anyone is feeling ambitious, since i won't be around tonight, i pushed it as lenovo-x13s-6.1.0-rc7-notworking-gpu
<steev> it expects/uses the a690 firmware from https://github.com/linux-surface/aarch64-firmware
<bamse> steev: does your interest in this indicate that there has been any updates on the subject?
<bamse> steev: or you just rebased the old patches?
<steev> rebased old patches, hoping that the various other lower level fixes have helped
<steev> but i feel like i'm missing a patch or two somewhere
<steev> my patchsets director(y|ies) have a bit over 3000 patches though, so gotta clean that up to just the stuff i really want
<bamse> you should be able to get away with far fewer patches these days ;)
<steev> oh i know :) it's just stuff like, these were applied to 6.1, then these ones, then these ones
<steev> anywho, i'll be back a bit later
<steev> gotta celebrate the USA win
<bamse> robclark: we seem to have unbalanced pm_runtime in the gpu in the case that mdss probe defers, we had a patch for this a few months back, but i don't see it in the git log...do you remember?
<robclark> bamse: hmm, not off the top of my head