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)
<steev>
nope, no luck there either
<steev>
but interestingly, when making that a module, the message about ufs being probe deferred came back
<steev>
bamse: any ideas why i'm getting a power controller probe deferred? :(
<steev>
looks like that's aoss_qmp
<bamse>
qzed: yeah, i don't suspend hard enough for that to be a problem yet...but that's going to be a problem
<bamse>
steev, qzed: after deferred_probe_timeout driver_deferred_probe_check_state() will return ETIMEDOUT instead of EPROBE_DEFER
<bamse>
so if any of your power-domains ends up not probing before that timeout, chances are high that things will break
<steev>
hmm
<bamse>
so the problem we have is that the devlink stuff figures out that dispcc depends on the phy, and thereby postpone the probing...until it's too late
<qzed>
bamse: at the moment I have only s2idle available, and somehow even that crashes...
<steev>
bamse: okay so with fw_devlink=permissive i can boot, and it looks like no deferred devices, however i lose video
<steev>
oh, i think i ran into this before at some point - it doesn't want to probe msm
<bamse>
qzed: i gave s2idle a try and ran into the problem that one of the pcie gdscs was stuck on (iirc)
<bamse>
qzed: perhaps that's on sc8280xp though, might be that i haven't tried sc8180x in a long while
<bamse>
steev: can you boot with deferred_probe_timeout=30 as well?
<bamse>
steev: without fw_devlink
<steev>
let me try that
<bamse>
steev: and abelvesa is looking into an fw_devlink issue spotted on rb3 (sdm845) where dispcc will be not probe until dsi-phy has probed...which won't happen until mdss has probed, which will fail because dispcc isn't there...
<steev>
bamse: oh hm, i think i know someone else who runs into that
<steev>
that one guy who always insists on emailing me instead of coming onto irc
<qzed>
bamse: is there an easy way to check that?
<bamse>
qzed: check what?
<qzed>
gdscs being on/off
<qzed>
also it came back a while ago with a bunch of PCIe errors... now it's stuck with display off
<bamse>
i get a big splat on the uart
<qzed>
ah yeah... guess I might want to try with usb-serial...
<bamse>
debugging that without uart is a even bigger nightmare
<qzed>
yeah... but I think usb-serial might not cut it here...
<bamse>
might be able to get something out of it, but usb is probably going to interfere
<steev>
long story short... it gets to a login prompt but, i'm assuming the timeout expires... and then the screen blanks, however i can't ssh in
<steev>
bamse: okay, yeah - with deferred_probe_timeout=XX as soon as the timeout happens, the display goes away (backlight is on) and based on a 60 second timeout, i can login and the devices are still deferred according to /sys/kernel/debug/devices_deferred
<steev>
so whatever si supposed to happen to make msm kick in, just isn't happening
<bamse>
steev: c630?
<bamse>
or flex?
<steev>
flex
<steev>
the c630 works great
<steev>
not sure what i might be missing
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
derzahl has quit [Remote host closed the connection]
<steev>
qzed: re your config fragment, if UCSI_GLINK is built in, QCOM_PDR_HELPERS needs to be too, or else it has to be module
<steev>
bamse: something else i noticed - with fw_devlink=permissive i see "[ 0.320735] PM: genpd: Not disabling unused power domains" - however, on the boots without where things are deferred - [ 7.122292] PM: Image not found (code -22)
<qzed>
most of the time it doesn't wake up (or maybe never properly enters suspend)
<qzed>
from the log it seems that its getting stuck somewhere, so maybe something doesn't get turned back on?
carmen has quit []
<steev>
qzed: ah, i missed that commit as i was looking through things
<steev>
qzed: oh, that reminds me - so with the fresh install of linux on the flex5g, i was actually able to copy across the firmware using the flex5g firmware script that we install; and i do see a bunch of the bdwlan files now
<qzed>
I haven't really had any troubles with the one I'm using right now... still not sure if it's the correct one but it seems to work
<steev>
i was just looking because i saw the out of bounds messages again, and remembered our previous convo about modifying the firmware
<qzed>
it's for the SPX, but I guess most of it applies to the flex too
<steev>
oh nice, yeah i need to submit some merge requests to the build repo to document this stuff too but using wiki would probably be better
<steev>
also, i'm *so* used to copying the kernel debs across to my c630, i keep copying them to the c630 then looking for it on the flex5g and wondering why it's not there....
<qzed>
muscle memory and/or excessive use of command line history is hell of a thing...
<steev>
muscle memory, sadly, i don't use zsh on my build box, but on all my other systems i do with autosuggestions on
<steev>
hm
<steev>
drm doesn't seem to actually ever kick in here
<steev>
drm_debug=0xff shows... absolutely no drm messages
<steev>
hm, no definitely gets further than that here :D
<qzed>
may also be some kernel version thing... haven't re-tested that on any other kernel than the one I created the fragment on...
<qzed>
and that was some linux-next IIRC
<steev>
the weird thing is, with drm_debug=0xff which i would expect, well, all drm messages to show up, modprobe msm shows, literally no messages at all
<robclark>
hmm, ok.. that should be something bamse has working but not sure what, if any, patches needed on top of upstream
<steev>
i have (afaik) everything he's posted publicly
<robclark>
if you don't have the dpu device in dt, you wouldn't get as far as even trying to probe.. otherwise, I think gdsc/genpd and perhaps iommu dependencies are handled in driver core before even trying to probe (but would have assumed things would show up in devices_deferred in that case)
<steev>
it looks like the sc8180x should just inherit it from the dtsi
<steev>
or am i completely wrong and this has just never worked?
<robclark>
you could add a pr_err() in dpu_dev_probe() to see if it at least gets far enough as trying to probe..
<qzed>
i have honestly no idea.. I mean GPU stuff works on the SPX, which doesn't seem to be that different from the flex...
<qzed>
the only thing I haven't included in the DT for the SPX is the external display-port stuff
<qzed>
but I think that shouldn't really matter here...
<steev>
robclark: what's the "proper" way to look at the clk_summary? i've got one from booting with fw_devlink=permissive (no video, but no deferred devices), and one from default (i assume is fw_devlink=strict) (video but remote procs are deferred) - but as far as i can tell, strict has *more* clocks enabled?
<steev>
but i'm just doing a diff of the 2 and then sorting
<robclark>
looks like I've been using fw_devlink=on for past few kernel versions (I assme that is the default).. clk differences can just be a bunch of noise if some drivers didn't probe
<steev>
with whatever the default is, and with fw_devlink=on, i get display, just no remote procs, with permissive, no display but remote procs
<robclark>
huh
<steev>
i'm assuming it's still efifb since msm loads but says its in use by 0
<steev>
and there is nothing about drm in the log
<steev>
asude from systemd's drm service
<robclark>
if you have /dev/dri/* it is not efifb, otherwise it is
<steev>
no such file or directory, so i guess it is :D
<steev>
qzed: oh, you know what - i think i remember something, not sure if it's entirely helpful, re: high cpu usage - i'd noticed that i had a TON of interrupts on one of the hid over i2c devices - 161: 26887116 0 0 0 0 0 0 0 msmgpio 37 Level hid-over-i2c