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)
Lucanis has joined #aarch64-laptops
<steev>
okay, i definitely didn't break anything
<steev>
something else is breaking it because the working initramfs just got rebuilt and now i'm back to no nvme
<szclsya[m]>
finally have time to do some x13s work again
<szclsya[m]>
steev: what branch should I use now?
<steev>
oooof
<steev>
uhhh\
<steev>
sc8280xp-next-20221226 is my most recent push, i think, for thinkpad stuffs
<steev>
might be better to snag johan's stuff? i don't recall if he pushed after 1226 or not
<steev>
i think he did? because iirc it's 6.2-rc2
<steev>
1*
<steev>
6.2 rc1
<steev>
sorry
<szclsya[m]>
jhovold?
<steev>
yeps
<steev>
on github as well
<szclsya[m]>
ah, find it
<szclsya[m]>
github thinks it's 10 months old for some reason though
<steev>
it's based on the date of the latest commit, not when it was added
<szclsya[m]>
ah makes sense
Mr0btain has joined #aarch64-laptops
<steev>
round umpteen against next
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<Mr0btain>
I ran into the same problem before too, iirc in my case on ubuntu it was something to do with the initramfs compression. I keep thinking I was trying zstd but forgot to enable support in the config. I have doubt that it's the same problem, but I had the same Exiting Boot Service... result
<Mr0btain>
highly doubt**
Mr0btain has quit [Read error: Connection reset by peer]
<steev>
hm, well, i can flip back to my config again, after switching gzip, but switching back to johan's config which doesn't include a bunch of stuff does work
Mr0btain has joined #aarch64-laptops
Mr0btain has quit [Read error: Connection reset by peer]
<steev>
huh
<steev>
maybe something changed in zstd then
derzahl has quit [Remote host closed the connection]
<HdkR>
But where's my async zstd compression block? :P
SSJ_GZ has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
djakov has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
djakov has quit [Read error: Connection reset by peer]
djakov has joined #aarch64-laptops
<bamse>
jhovold: i said i was going to let the power-domains be wrong when i submitted the display patches...but as you saw, the itch got to me...and i don't know if you noticed yet, but what we merged doesn't boot 100% of the time
<bamse>
jhovold: should have a couple of patches on the list shortly
<jhovold>
bamse: thanks for the heads-up. Haven't noticed that anything was off yet though.
<bamse>
jhovold: crd booted 9/10 times...thinkpad not so much, probably because ufs isn't there to keep the lights on
<jhovold>
bamse: mostly been using the CRD so that may indeed be why
<bamse>
jhovold: same here, but as i merged your x13s patch i wanted to see if it will all work out of the box...and it didn't...then i tried to figure out the problem on the crd and found it there as well
laine has joined #aarch64-laptops
<jhovold>
bamse: good thing you were able to track it down so quickly
<bamse>
yeah, but it's still not clear why rpmhpd does not carry a link to the dp controller...i thought it should have an indirect link through the mdss_gdsc, preventing the sync_state to happen before it had probed
<bamse>
perhaps it's one of those cases where the dependency loops is just too much so it ends up dropping some of the links
<jhovold>
sounds like something that needs to be fixed
systwi has joined #aarch64-laptops
systwi_ has quit [Ping timeout: 480 seconds]
<abelvesa>
bamse: those dependency loops usually end up in one of the consumer/provider probe deferring
<abelvesa>
bamse: have you tried fw_devlink=permissive ?
<bamse>
abelvesa: i don't intend to play the fw_devlink game :)
<bamse>
abelvesa: but no, the issue here is that there's no link between rpmhpd and the displayport-controller
<bamse>
or maybe i'm confusing the supplier and consumer synlinks...let me try that again
<bamse>
abelvesa: i was convinced that problem was that there's no devlink created when you add a genpd domain as a subdomain to another controller's genpd domain...so the parent doesn't know about the subdomain's child dependencies
<bamse>
abelvesa: but i was told this is not correct...i have however not managed to learn the truth from the code yet
<steev>
well, in a wonderful start to my day, i broke my french press
<javierm>
bamse: it's not a probe deferral timeout, right?
<bamse>
javierm: no, the idea is that once all consumers of a resource has probed successfully, the sync_state callback of the provider driver is called
<bamse>
javierm: so if i have the displayport-controller reference the &rpmhpd, sync_state happens after that has probed
<bamse>
javierm: but apparently this relationship is not inherited...so sync_state is called as soon as dispcc is probed...even though there are genpd subdomains of the rpmhpd resources referenced by yet to be probed devices
<bamse>
abelvesa: i checked, there is a devlink between rpmhpd and dispcc and one between dispcc and the displayport controller, but rpmhpd sync-state doesn't wait for that second devlink...i don't know if that's expected behavior or not
<abelvesa>
bamse: I guess it depends on the type of the links
<abelvesa>
bamse: I mean the relationship between those three
<bamse>
abelvesa: dispcc has a gdsc, which is a subdomain of the rpmhpd resource...which i'm told should result in a dependency between rpmhpd and the dp-controller
<javierm>
bamse: I see, thanks for the explanation
<abelvesa>
bamse: look into /sys/class/devlink
<bamse>
abelvesa: i've reverted back to the working setup, will have to test later
<steev>
bamse: this is unrelated to what you asked me to test yeah?
<jhovold>
steev: it's related
<abelvesa>
bamse: I'm not sure a parent child relashionship between PDs create a devlink
<steev>
ah
<abelvesa>
bamse: therefore, the sync_state will not wait
<jhovold>
steev: but I didn't notice anything wrong here, but I may not have booted my x13s enough times
<steev>
since i have 11 booting again, i'm trying the latest patchset build now
<bamse>
abelvesa: i was expecting the same, and i was told in one of the power-sync meetings that it indeed should do so...
<bamse>
steev: there's two dts-patches from me this morning, you want those
<abelvesa>
bamse: well, looking into the /sys/class/devlink, it sure doesn't seem so
<bamse>
steev: my x13s failed to boot 5/5 times i tried...then i fixed it and it booted
<bamse>
abelvesa: i agree
<steev>
hm
<bamse>
abelvesa: in practice we can trick the system, because when dp-controller is on, it will vote for mdss to be on...so putting mdss in MDSS_GDSC and dp-controller in MMCX, we get both the boot order and MDSS_GDSC on
<steev>
i don't see them on the list, just the gdsc don't hw control
<bamse>
abelvesa: but it doesn't seem correct
<bamse>
steev: 2 minutes before that
<steev>
oh
<steev>
the website default hides accepted :)
<steev>
oh blah, and i only pulled in v6 not v7
<bamse>
steev: traveling light...for speed
<steev>
if you were traveling light, you'd have the c630 not the thinkpad :P
<steev>
okay all the latest revisions
<steev>
i've started poking at the bluetooth driver to add in support
<steev>
the downstairs neighbor having a 1 yr old has facilitated a need to use my bluetooth headset
derzahl has joined #aarch64-laptops
<rfs613>
steev: be thankful it's downstairs ;-) it's like a heard of elephants in my house...
<steev>
lol
derzahl has quit [Remote host closed the connection]
<rfs613>
both my little monsters are at home today, coughing an throwing up (but tested negative). Fun times.
<steev>
ouch, hope they feel better
<steev>
and... i think the mom stomps around more than the 1 year old :P
<rfs613>
kids learn to walk around 1yr, and run soon thereafter... then it's constant little feet for the next few years, except when they finally fall asleep
<rfs613>
all to say: good luck with bluetooth ;-)
<steev>
heh
<steev>
i'm gonna need it :D
derzahl has joined #aarch64-laptops
<steev>
bamse: am i supposed to see pcie_2b_gdsc is stuck at off