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)
<robclark>
HdkR: yeah, I didn't try to port gen4 support to tu yet, since didn't have a good way to test.. I'll push a branch for you to try later today
<HdkR>
Nice
<HdkR>
robclark: If you need me to walk you through setting up FEX, it's pretty easy :)
<robclark>
I don't have a gen4 setup running normal linux atm.. just one with android and one with CrOS..
<HdkR>
ah
<HdkR>
I guess you'll have to make do with the gfxreconstruct for testing then
<robclark>
I suppose it is easy enough to make that run surfaceless, without actually seeing the result.. but probably also means making .ebuild's or something like that
<HdkR>
Yea, those are something that I never want to get associated with
<steev>
ebuilds are easy
<robclark>
that and porting gfxreconstruct are probably all things that are not super hard.. but more work than the needed mesa patches so doesn't really meet the threshold to justify ;-)
<HdkR>
oh hey
<HdkR>
I hacked in the compute shader patch and it fixed the game
<robclark>
yeah, I was guessing that was the most likely issue
<HdkR>
What was the application for seeing GPU boundedness?
<HdkR>
Looks like the game is spinning a bit on its sync objects so might be interesting to see how much it is bounded there
<robclark>
in vk.. maybe ask danylo on #freedreno .. he's been playing steam store games with different hacks (like piping vk captures from x86 to a650 thing)
<HdkR>
Actually, I Just resized the window to half 1080p and it bumped it up to 60fps. Likely bounded because SLC isn't enabled atm
<bamse>
steev: ohh my...i would say follow the most common prefix on your $subject...but
<steev>
also... woo, our release is out, free time \o/
<bamse>
steev: well, just do that and it'll be fine..."funny" to see that the worst offender is my last patch
<bamse>
steev: that said, i wouldn't go all pwrseq just yet, it just means you have to carry more patches
<steev>
oh i know, i'll drop them at some point
<steev>
but for testing purposes..
<steev>
i basically just put the same numbers in that regulator that the db845c has
<steev>
since it's empty in the c630's dts
<steev>
i should probably do a better job about naming the testing trees, but i'm lazy
<bamse>
steev: the db845c patch applies to the c630 as well, will you send a patch?
<steev>
want me to do one that adds that regulator and adds it in to bt/wifi and then a second one for the pwrseq to do it the pwrseq way?
<steev>
gwolf: thanks :)
<steev>
though our seedbox is broken, apparently it was using a python2 script to do its things, so need to port that to pyhon3
<bamse>
steev: i would like a patch that adds ch1 to the &wifi node in the current dts
<bamse>
steev: didn't see that Dmitry's patch is for the pwrseq, would have been nice to get that in first and then move to pwrseq...
<bamse>
steev: not sure about the bt node, it seems reasonable that it should be there as well, but the binding and driver doesn't care about ch1
<steev>
will do!
<steev>
i reset my tree to apply that
<steev>
bamse: well the pwrseq is still RFC, so i sent one that adds the regulator and then i'll just redo the pwrseq one once that's past rfc
<bamse>
steev: right, that's why i said that you should ignore the pwrseq for now
<steev>
ah okay :)
<steev>
i only did the wifi, since you said bt doesn't seem to care
<bamse>
steev: i think that's reasonable
<steev>
i just hope i sent it right, never actually used git send-email before
<bamse>
steev: looks good
<steev>
bamse: so, the only thing i notice that is different between dmitry's pwrseq and without pwrseq, is that 5240 MHz without pwrseq seems to be no IR, and with pwrseq it seems it is? maybe I am not applying it correctly
<steev>
sorry, i meant, it has no IR without pwrseq, and with pwrseq it's not no IR
<steev>
no IR meaning it can't initiate
<steev>
for giggles, i'm adding it to bluetooth as well, just to see
<bamse>
IR?
<bamse>
the bt driver doesn't touch ch1, maybe it should(?)...but for now it's a nop
<steev>
it can't initiate a connection on that channel unless it sees something on it first? something along those lines
<bamse>
but what you're saying is that with the pwrseq (i.e. adding ch1) you get 5240 as well?
<steev>
well, we have 5240 both ways, just can't initiate on it without pwrseq, which doesn't make sense to me
<steev>
unless i did it wrong
<steev>
which, i mean, it's me
<steev>
adding it to bluetooth gets rid of no IR
<steev>
that seems... odd?
<steev>
i asked in the linux-wireless channel because i have no idea if that's a bad thing
<steev>
and i may have sent it wrong because i don't see it on the msm patchwork
hexdump01 has left #aarch64-laptops [#aarch64-laptops]
<steev>
bamse: i sent a v2 with the bluetooth part added, screw it
iivanov_ has quit []
<bamse>
steev: :)
<steev>
i honestly haven't looked at my wifi network in ages
<steev>
don't even know if i'm using 5240, and can't do any kinda monitor mode stuff or the firmware gets *very* angry on the c630