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)
<rfs613>
derzahl: i'm not aware of one for the c630
<derzahl>
oh i thought there was
<derzahl>
btw, does the cellular modem work on the c630 in linux?
<rfs613>
last time I looked, the answer was no, but this might have changed - it's not how I use mine so I dunno really ;-)
<rfs613>
derzahl: regarding pen, you might be thinking of the Flex 5G, which is the c630's bigger cousin. It apparently has a pen.
<rfs613>
hmm, actually, some googling does turn up evidence of a pen for the c630...
<steev>
derzahl: with 5.13 it should. i at least get the device, but haven't plugged a sim in to check
<steev>
rfs613: if a pen came with the flex 5g, i didn't notice it
<steev>
definitely not in the box
<steev>
bamse: since i'm pretty dumb... i looked around in /sys/kernel/debug/clk/disp_cc_mdss_pclk0_clk_src - on 5.12 where i don't see that rcg issue, clk_possible_parents lists "bi_tcxo dsi_phy_pll_out_dsiclk dis1_phy_pll_out_dsiclk core_bi_pll_test_se" - but on 5.13, core_bi_pll_test_se is not listed
<steev>
ah, 35e4368fa3ea9638cb467bd79ed085e254cd93fd removes it
<bamse>
steev: yeah, core_bi_pll_test_se is something the hardware engineers are using early on during verification...
<bamse>
steev: iirc we were lacking proper representation in the DT binding and as we tried to add that it was concluded that we should just remove the whole thing instead
<steev>
everything else matches between 5.12 and 5.13 :( and now i'm at my limit of knowledge or even ideas of what to look for
<bamse>
so the difference would be the probe order and timing?
<steev>
maybe?
<steev>
how would i go about even printing out the probe orders?
<bamse>
steev: "git diff v5.12 v5.13 -- drivers/clk/qcom/*845*" does give me a bunch of things
<bamse>
steev: e.g. the transition from resolving clock parents by global name to fw_name
<steev>
but also, why the hell don't you or shawn see this when i see it on both of mine?
<bamse>
perhaps i haven't paid enough attention and have played mosty with sc8180x lately...
<bamse>
and looking at sc8180x i have: [ 19.046553] disp_cc_mdss_edp_pixel_clk_src: rcg didn't update its configuration.
<steev>
woo, it's not just me
<steev>
33 patches if i wanted to attempt to revert that :/
<bamse>
meh, my 845 devboard is down because i was shuffling things in my lab...so i can't just give it a quick spin there
<bamse>
will have to get that setup again tomorrow and will try to take a look
<bamse>
obviously for me that warning still results in a clock that ticks at some acceptable rate, but i think it might result in some unexpected output and hence we should look at it further
<bamse>
steev: there's changes in v5.12..v5.13 in the dsi pll code as well, i.e. the parent of your clk_src
<steev>
bamse: i'd like to make sure that that clock goign wonky isn't causing other issues (like that frame encoder issue that only i seem to run into :D )
<bamse>
the bluescreen until suspend/resume issue?
<steev>
no
<steev>
basically the interface slows down and that dpu frameenc timeout message spams the shit out of the logs
<steev>
i don't run into the blue screen issue as often because i don't put the firmware into the initrd
<bamse>
hmm, so that helps?
<bamse>
i don't see the interconnect issue btw...
<steev>
it seems to here, yeah
<steev>
i think rob might have said that fw_devlink=off also helps
<bamse>
yeah, we have a report about that...but i wasn't able to confirm it
<bamse>
and if it helps we need to figure out why that is
<steev>
something about sboyd's component patchset should make that go away, iirc
<bamse>
steev: okay, so rather than speculating, i need to add some prints to see what the rcg update actually entails, and take a look at the documentation to see if i can measure the PLL clock coming from the dsi phy...
<steev>
but i can't use 5.14 yet :P
<bamse>
i was just hoping to squash the bug i have at hand, perhaps you want to trade? ;)
<steev>
i don't believe i'm even remotely smart enough to do that
<bamse>
a few hours after going idle, my flex 5g suddenly reboots
<steev>
kernel panic?
<bamse>
well...i don't know...because the panel is off due to dpms
<steev>
i suppose i could reinstall on the 5g... i've kinda put it off to the side at the moment
<bamse>
i have posted most of my patches for review, need to respin some stuff and then work with shawnguo to get things integrated into a kernel build
<steev>
si, i saw all of them come in
<bamse>
but i have display, backlight, displayport, bluetooth, wifi etc working now, so i'm using it as my desktop now
<steev>
Oh wow
<bamse>
but every now and then after being afk i face the login prompt
<bamse>
and there should be "gpu" in that list as well :)
<steev>
I can definitely let a machine sit there idle
<bamse>
which certainly needs some more testing, i've only been running webgl aquarium and glxgears
<bamse>
let me push my latest branch, in case you find some time to play with it
<steev>
I’ll try to spin mine back up this weekend
<steev>
I should have free time. No more visits to Austin in the near future
<steev>
And pain killers are done and I’m almost caught up on the ~3 weeks of work that I was fairly useless for
<bamse>
also picked up a usb-c pd sniffer, in hope that i can figure out what's going on wrt external display on the c630
<bamse>
and it becomes relevant because the battery driver we have is actually the driver for the EC, which also deals with usb type-c handling
<bamse>
so in order to finish up the battery driver i think it would be good to at least understand how the typec driver needs to look like
<steev>
Makes sense
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov_ has quit [Ping timeout: 480 seconds]
<shawnguo>
steev: It seems that I did not run into "rcg not update configuration" is because that I have `fw_devlink=off` on kernel cmdline. I can see it now if I drop that kernel parameter.
<shawnguo>
Nice! LMhv4 works fine with deb-pkg build, no lockup anymore!
<shawnguo>
So picked LMh-v4 up for laptops-5.13.
<steev>
nice :) glad to hear confirmation
<steev>
shawnguo: also, at least here, i still get the rcg didn't update its config even with fw_devlink=off in my command line
<steev>
oh spiffy, for whatever reason, the component patches (at least v1, i haven't checked if there is a v2 yet) apply to 5.13.6
<steev>
well i'll give those a spin
<rfs613>
yesterday I tried laptops-5.13 branch with distro_defconfig, but my c630 didn't like it... a bit of kernel spew from geni_i2c and i2c_hid_of, then it resets itself.
<steev>
i've occasionally seen the i2c device not accepting reset, but a couple reboots usually fixes it
<steev>
without using dtbloader, at a minimum `efi=novamap clk_ignore_unused pd_ignore_unused`
<rfs613>
i also tried 5.14-rc3 vanilla (eg. not the laptops.git) using an older defconfig from 5.9.something... this one actually booted to the GDM login screen, but had no keyboard/mouse.
<steev>
the config option changed between 5.11 and 5.12 iirc
<steev>
and it's the i2c_hid_of or whatever now
<rfs613>
when I added CONFIG_I2C_HID_OF to that config, I started getting the I2C timeout errors, and it reboots itself
<steev>
could be something broken in the RC itself
<rfs613>
possible, yes. But also crashing for me with laptops-5.13 branch.
<steev>
not sure on the i2c, i haven't seen that here except like i said, occasionally it saying it can't reset the device and usually works next boot or the boot after
<rfs613>
i'm just "special" :-)
<rfs613>
the dtb symlinks seem reasonable as well:
<steev>
was kinda hoping that would give me some ideas to what was going on with the clocks but... obviously i was very wrong
iivanov has quit []
<bamse>
steev: i think we need to bring that stuff in, in order to drop clk_ignore_unused without too many surprises...but in its current state i'm worried that it causes unwanted side effects
<steev>
that's fair, i was just hoping to get some insight... and i didn't :)
<macc24>
did anyone get minecraft java edition to be playable on aarch64 laptop?
<robclark>
GL_QUAD emulation for java edition isn't great unfortunately.. when I looked at a trace of it for dianders it was spending a lot of time reading back from WC index buffers.. dianders did send a MR (merged) to optimize that some but there is only so much you can do
<robclark>
android version should be somewhat better written
<macc24>
quads...... do malis have it?
<HdkR>
Some
<macc24>
also bedrock edition runs /really/ well on krane, haven't checked on lazor yet
<robclark>
some desktop gpu's don't even have GL_QUAD
<robclark>
I suppose we could do some sort of driconf quirk to not upload index buffers to gpu buffers until after they've been re-written to emulate quads.. not something I'll have time to do for a few weeks
<dianders>
It would be nice to go back and try this again. IIRC perf was terrible for me but I was running it through crostini (Linux VM in Chrome OS). ...so I had the VM overhead / lack of graphics optimizations. ...and, at the time, the VM didn't have knowledge of big.LITTLE.
<robclark>
yeah, virgl brings it's own pain
<macc24>
hmm
<macc24>
are y'all going to eat me if i pirate minecraft :v
<dianders>
...but you ran the trace I took w/out all the VM overhead, right? That's when the Quad optimization made a big difference...
* robclark
is vegetarian, so no.. unless you are a vegetable :-P
<HdkR>
Piracy is illegal!
<robclark>
dianders: right.. although that was on a630 (c630) since I didn't have a linux setup on one of my lazor's at the time
<robclark>
honestly, I don't think the performance would be different between a618 and a630, since it isn't gpu limited
<macc24>
*glances at line 1117 src/gallium/drivers/panfrost/pan_context.c * uh i think this means that malis do have quads
<dianders>
robclark: Yeah, so it's be interesting to try putting it all together on a system without all the overhead problems. Maybe limiting it to the big cores only.
<robclark>
a more productive thing would be to make the src index buffer regular malloc memory
<robclark>
technically, adreno does actually have quad's.. just not GL_QUADs
<dianders>
I think in the end the Quad emulation was down to a few percent after all the optimizations, so unless the malloc memory change was going to affect more than just quads it might not be that huge?
<robclark>
hmm, maybe the end result was better than I remember.. let me see if I still have the trace
<dianders>
I'm curious if Microsoft ever made it less of a pain to get Minecraft running on aarch64 Linux. I remember I had to jump through a bunch of extra hoops because they tried to download some native library and it was the wrong version / architecture, so I had to trap in just the right place to drop the right library in.
<dianders>
macc24: I think it was just vanilla minecraft for me. I just used what microsoft provided but then hacked in my own version of `liblwjgl.so`. I was running 1.8.9
<dianders>
Maybe one of these days I'll get back to it and try the MultiMC5 version. I was a bit leery of downloading random binaries hosted on dropbox which is what a lot of the instructions I found said to do back when I tried it last.
<robclark>
dianders: actually, on lazor, replaying the trace is 45.8fps.. I suppose the big cores on sc7180 are a bit newer/faster compared to sdm845..
<macc24>
dianders: try with optifine and on 1.15. i remember hearing that in some versions they did something with rendering
<dianders>
robclark: that's super odd. sc7180 big cores should be slower (slightly) than sdm845 IIRC.
<dianders>
macc24: you gotta play on 1.8.9 though! That's the best version. :-P
<macc24>
dianders: i like the new combat system and i'm tired of pretending i don't
<robclark>
this is on sc7180, still would be some wins for getting the app's index buffer into malloc'd memory, maybe it could hit 60fps that way..
<macc24>
i'm fairly confident anything faster than mali t760 can hit 60fps in minecraft...
<dianders>
I think the trace I took for Rob was in the Hypixel lobby which was pretty heavy. ...maybe a worst case scenario?
<robclark>
dianders: it is a newer cortex on sc7180.. and tbf the kernel I'm using atm on sc7180 has some devfreq optimizations that I'm working on... but clearly the translate_quads_uint2uint_last2last_prdisable() part got a lot faster
<robclark>
macc24: oh, the gpu is far from the bottleneck here
<macc24>
robclark: *shrug* without optifine benchmarking minecraft is kinda pointless imo
<dianders>
robclark: I think it is slightly newer, but I think cpu-bound benchmarks all ran slightly slower. Maybe it just happens that this hits one particular path that's faster, though. ...or maybe something else about interconnect drivers or something was never quite finished / optimized on sdm845 or something?
<robclark>
could be.. actually c630 is sdm850 (but I'm not sure if there were ever dts updates for the higher opp's)
<bamse>
robclark: we have sdm850.dtsi that inherits sdm845.dtsi and adds the 2.8 and 2.9GHz (turbo) frequencies
<bamse>
robclark: but from recent experiences we've learned that we're bound by memory bandwidth and hardware throttling cpus to 70C
<robclark>
ahh, I guess that is more recent than last time I looked (which was a while ago)
<bamse>
robclark: with the lmh driver in place we no longer have the hardware throttle us that early, and by that i'm beating the windows scroe in geekbench
<robclark>
nice
<robclark>
I guess once lmh is dialed in, I should move my c630 to a newer kernel
<robclark>
been kinda slacking on that since it is so much easier to test upstream work on lazor ;-)
* robclark
<3 suzyq :-P
<macc24>
robclark: just do all your development on the laptop itself B-)
<bamse>
macc24: i do that, but i test it on a separate device with uart
<bamse>
and now finally i'm not bound to my 13.3" screen ;)
<macc24>
i'll start doing literally everything on arm devices after they release arm chromebook with support for 3 external displays xD
<steev>
i would if they'd ditch the keyboard
<steev>
c630 and flex are both good, so is the m1, but the m1 can't do 32bit
<HdkR>
Sounds like you need Tango on M1 then ;)
<macc24>
steev: why do you need 32bit support
<steev>
macc24: because i have to support rpis and other misc arm boards that are 32bit
<macc24>
ah
<bamse>
macc24: looking at the 8cx hardware i'm inclined to believe that it should be possible there
<macc24>
bamse: i wish there was 8cx chromebook
<steev>
rfs613: fwiw, i haven't tested 5.13 on my ubuntu-ish c630 recently, but when i did, it "worked". until the clk thing gets figured out, i'm sticking with 5.12 on it
<dianders>
bamse: The "hardware throttling cpus to 70C" could explain why sdm845 is slow for Rob. sc7180 runs _much_ cooler.
<steev>
but again, not sure why but something is funky with that and i have to use my config, not the distro_defconfig; an initial 5.13 test showed it at least booted up with the distro_defconfig so that would be nice to move away from building it twice to test things
<bamse>
dianders: looking at the benchmark numbers it seems we're hitting that limit rather quickly...so bumping it gave us about 30% increase in various benchmarks
<steev>
hm
<steev>
just got the blue screen on 5.12
<bamse>
hmm, running geekbench on the 8cx doesn't bring the cpu temperature above 37C...so i guess that i have some other problem there
<dianders>
bamse: yeah, I remember sdm845 getting hot easily. I think on sc7180 I had a hard time getting it hot even by trying to stress the system out and even without a heatsink. Of course we also have LMH absurdly high because we decided we'd rather have Linux manage the cpu speed rather than some hardware that we had zero visibility into. I think on sc7180 we configure it in firmware so LMH hardly does anything.
<dianders>
I think it runs after we'd expect the OS to shutdown but before the hardware fault value trips.
<bamse>
dianders: i think we're only making it high, not crazy high...but yeah it feels like it should be used primarily as a failsafe
<dianders>
bamse: On sdm845 I think it was important for it to be slightly lower if you weren't running with a heatsink and you were running the thermal in polling mode. Otherwise I think it could heat up so fast that the 100 ms polling period would miss it otherwise. With the heatsink and/or interrupt based thermal trips it's probably OK to go higher.
<robclark>
the c630 was always a bit inconsistent when it came to gpu benchmarking in the summer, but if lmh was kicking in, that could be why
<rfs613>
ok, i'll try it after the little people are asleep ...
derzahl has quit [Remote host closed the connection]
derzahl has joined #aarch64-laptops
<rfs613>
steev: 5.12 with your config is more verbose during boot, text scrolls off the screen in fact, but it hard-resets around 20s into the boot, just like 5.13 and 5.14-rc3.