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)
<qzed>
give me a sec, I'll try to test that
zmike has joined #aarch64-laptops
<zmike>
if anyone has any tips for getting wifi working on coachz with arch linux, I've done the modem file rename and started rmtfs but the device doesn't show up and NetworkManager has no wifi options
<qzed>
steev: only have 2mb/s available here, but with that I don't see any lags
<qzed>
neither on the touchpad nor a bluetooth mouse
<qzed>
there's also a bunch of "unknown option", in particular unlink and seek
<qzed>
I'll try to look at that at some point and maybe have a go at implementing that (I assume it's going to be required for the modem), but I'm not sure when I'll get to that
<steev>
bamse: i don't see any difference in wifi when using single-chan-info-per-channel on the firmware-5.bin but kalle probably knows better than i would
<bamse>
steev: kalle is your guy for such specific questions about wifi
<bamse>
steev: on c630, what's actually required on /dev/sda?
<steev>
i don't know; HdkR said they were able to repartition just fine - somewhere around here i have a picture of his partitioning, but any time I tried to fully remove windows, it would simply refuse to boot properly
<HdkR>
Yea, I repartitioned three of the things
<bamse>
in my current installation i just shrunk the windows parition, and have been running in the empty space...but i need moar!
<bamse>
and i don't even have windows in the grub menu on this machine, so i don't think i'll miss it ;)
zmike has left #aarch64-laptops [#aarch64-laptops]
<bamse>
so i presume the two "Basic data partition" is windows and some recovery?
<steev>
yeah
<bamse>
will it boot if i drop those two?
<steev>
"maybe"
<HdkR>
I don't even remember my partition map to remember
<steev>
sda1 should be the EFI stuff, sda2 should be some 128MB microsoft reserved
<steev>
sda3 would be windows itself
<bamse>
i have efi, reserved, 5gb unnamed, windows, linux, 1gb basic data
<steev>
the battery ones are if you want "a" battery
<bamse>
that is really nice to have
<steev>
i need to ask srinik about those wcd ones since they seem to not be upstream at all
<bamse>
i miss that on sc8180x
<bamse>
please do, and let's make sure they get in if they improve thing
<bamse>
things*
<steev>
i'm gonna do a build with all those patches, and one without
<steev>
and thara about those cpufreq patches as well, i don't recall if they're required required, but again, i've been carrying them so long
<steev>
and also ask srinik if he's had a chance to look into the comp pop stuff :(
flowriser has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
SallyAhaj has quit [Ping timeout: 480 seconds]
<steev>
bamse: actually, it seems the defconfig has SCSI_UFS_QCOM=m - but unfortunately, a default setup of initramfs-tools does *not* put that module into the initramfs
<steev>
bamse: good news - the 5.19.0-rc1 defconfig does indeed show the same Runtime PM usage count underflow! spamming of the log - kern.log here is 5.6MB in size... after it was completely emptied. bad news - the log file starts at about 4 seconds, so not sure what all occurs before the bam-dma-engine issue
<steev>
also, unfortunately, with whatever is causing that, the c630's wifi doesnt' seem to load
<steev>
the module is loaded, just not getting an interface
<bamse>
steev: right, i've added this to mkinitcpio.conf: MODULES=(phy_qcom_qmp ufs_qcom i2c_qcom_geni)
<bamse>
steev: but jhovold tells me that if i run "mkinitcpio -M" i'll get an autogenerated list of modules, that looks pretty good
<bamse>
steev: unfortunately i'm not familiar with how it cames up with that list...
<steev>
yeah, that isn't a huge issue, just a change to be made to the configs for initramfs
<steev>
whatever is causing that runtime pm underflow though... i have no idea and sadly, by the time logging happens, it's too late
<qzed>
right, so the problem was that we essentially disable runtime pm in both adreno_ubind() and adreno_gpu_cleanup()
<qzed>
ideally I think we'd check if the runtime is disabled in adreno_gpu_cleanup() and only disable it if it isn't, instead of completely removing that
<bamse>
but the reverted change is almost 2 years old?
<qzed>
yeah, I assume we're hitting it just now due to the EPROBE_DEFER thing
<qzed>
seems that that path might not have been reached without defering
<bamse>
disabling it an extra time if it isn't already disabled sounds a little bit like a hack ;)
<bamse>
but i'd rather take that than live a release without gpu
<bamse>
would you mind posting a patch that does that to start the discussion on the list?
<qzed>
I mean the problem is this: adreno_unbind() calls pm_runtime_force_suspend(), which disables runtime PM
<qzed>
but adreno_gpu_cleanup(), which is called by adreno_unbind() also disables runtime PM
<qzed>
as adreno_gpu_cleanup() is in some parts of the code intended to essentially reverse adreno_gpu_init(), it should call pm_runtime_disable()
<qzed>
on the other hand, it seems like adreno_unbind() relies on the pm_runtime_force_suspend() call, which also disables runtime PM
<robclark>
so, sounds like we probe-defer before adreno_gpu_init() is called, like a6xx_set_supported_hw()? So we end up pm_runtime_disable() without having enabled?
<qzed>
I think we actually have it enabled once
<qzed>
but we disable it twice
<qzed>
essentially, as soon as you're calling adreno_unbind(), you're going to disable it twice
<qzed>
gpu->funcs->destroy() which calls aNxx_destroy(), which calls adreno_gpu_cleanup()
<qzed>
so assumig pm_runtime_force_suspend() is needed I think the way to fix this without restructuring a bunch is to check where adreno_gpu_cleanup() is called from
<robclark>
hmm.. well at any rate, you can protect the pm_runtime_disable() inside an if (pm_runtime_enabled())
<qzed>
yeah, that's what I was suggesting above (checking whether it's already disabled
<qzed>
but not sure if there's a better way
derzahl has joined #aarch64-laptops
<bamse>
let's start there
<bamse>
if nothing else just to get some extra eyes on it
<qzed>
i'll fix that up, improve the commit description a bit and send it in then?
<robclark>
it doesn't sound like a completely unreasonable approach.. the order the init code happens currently is such that you could end up hitting gpu->destroy() either before or after runpm is enabled
<qzed>
bamse: assuming this works for you
derzahl has quit []
<bamse>
robclark: okay, if you're happy... :)
<bamse>
qzed: trying to come up with something to make sure that the edp phy doesn't timeout 75% of the boots
<robclark>
I think the alternative is juggle around initialization order so that enabling runpm is the very *last* thing we do.. but not sure if that actually would work..
<bamse>
the code figures out that dispcc depends on the edp, the edp tries to probe but the power-domain isn't there...and as we're past late_initcall that just fails instead of -EPROBE_DEFER...and then there's no display
<robclark>
I guess we don't (currently) try to read the gpu-id regs for anything, so it might work
derzahl has joined #aarch64-laptops
<bamse>
qzed: wrapping the pm_runtime_disable() in a pm_runtime_enabled() check removes the error when i run modetest at least
<qzed>
neat, I'm just finishing up on the commit message, will then rebase and post the link here
<qzed>
*send it in and post the link
<qzed>
I'll CC you both
<qzed>
drm
<qzed>
oops
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
<minecrell>
steev: the bam_dma driver is broken, for the "controlled remotely" case it skips the pm_runtime_get()s but always does the pm_runtime_put()s, so it underflows to infinity
<minecrell>
This was just not logged so far
<steev>
minecrell: well now that it's logging it seems to break things?
<steev>
or something else broke ath on 5.19-rc1 because i get the interface but... can't actually use it
<steev>
i can't even set the interface to up via ip set dev wlan0 up
<minecrell>
If it spams a lot then it can probably break stuff only by delay introduced by that
<steev>
i just assumed bam dma was the root culprit, since can't actually see what is going on
<steev>
well the kernel log is 5.6MB in size on a fresh boot, it's about 40 seconds of logging
<minecrell>
But don't think bam_dma is involved in wifi
<minecrell>
In your case the bam_dma is probably slimbus, so audio
<steev>
audio works
<steev>
so that's good
<steev>
i'll dig through the ath commits i guess
<minecrell>
Should probably disable the print temporarily just to make sure it's not the spam that's breaking stuff
<steev>
oh, could do that, yeah
flowriser has quit [Ping timeout: 480 seconds]
<steev>
minecrell: good news, it's not the spam that's breaking stuff :D
<steev>
okay, so, i can connect things manually, networkmanager just seems to be... not doing its job anymore
<steev>
ah, seems something with iwd, switching back to wpa_supplicant and things work properly