<kinkinkijkin>
i managed to screw the live system hard enough that the heartbeat blink takes 15 seconds to cycle through oop it just started going full speed again
<macc24>
kinkinkijkin: how ._.
<kinkinkijkin>
im not quite sure
<kinkinkijkin>
just loaded sway with a new dtb and it did it
<bschiett>
@macc24 meson complains about needing dri for EGL, not sure what to do about that as I cannot find a panfrost specific DRI option in buildroot menuconfig?
<bschiett>
also not sure if swrast is something i need to enable or not.
<macc24>
i run mesa without swrast on my rk3288 laptop
<bschiett>
@macc24 ok, so all I need for -Dgallium-drivers=... is panfrost and kmsro?
<macc24>
and i use custom compiling script for mesa
<macc24>
yeah, and -Ddri-drivers can be empty
<bschiett>
@macc24 actually, that mesa3d.mk is fine. my bad.
<bschiett>
@macc24 is it required to have (build) X for mesa/gallium/panfrost? I assume not?
alyssa has left #panfrost [#panfrost]
<macc24>
bschiett: some headers are required to build mesa if -Dplatform has x11
<bschiett>
@macc24 I don't actually need/want x11 for my use case
<macc24>
yeah then you can probably remove it
<bschiett>
@macc24 just checked my logs, I can see -Dgallium-drivers=freedreno,kmsro,panfrost in the build logs for buildroot. so kmsro has been passe.
<bschiett>
passed
<bschiett>
@macc24 ok, i rebuild everything and now I am finally making progress. see this pastebin - https://pastebin.com/bxrqyaSc
<bschiett>
now I see panfrost, but then I get Using modifier ffffffffffffff
<bschiett>
so maybe kmscube tries to set CRTC and rockhip drm doesn't support that or whatever
archetech has quit [Quit: Leaving]
archetech has joined #panfrost
<HdkR>
Could be
<HdkR>
modetest might help
<HdkR>
If it is trying to set some mode that is reported as working but then it gets rejected?
<bschiett>
@HdkR glmark2-es2-drm works perfectly
<bschiett>
@HdkR so there must be something wrong with kmscube
<HdkR>
Seems likely
<bschiett>
when glmark2 gets to this point, FPS drops from 56 to 0, and I have a bunch of white pixels in the top left of the screen, so not sure if that is normal or if it's a bug ... [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 0 FrameTime: inf ms
<bschiett>
the demos thereafter all show FPS = 0 and screen doesn't update anymore.
<bschiett>
so until the [desktop] demo all is well.
urjaman has quit [Read error: Connection reset by peer]
<bschiett>
@HdkR ok, so glmark2-es2-drm -b jellyfish will crash panfrost
<HdkR>
That might be an old kernel issue, but someone other than I would know better
<icecream95>
bschiett: That could be from the GPU voltage being too low at higher clock rates
<bschiett>
@icecream95 yeah, I noticed the min/max microvolt for cpu/gpu was reduced in rk3288.dtsi going from kernel 4.11 to 5.9.12 so i'm wondering if that could be the problem
<bschiett>
(i'm using 5.9.12)
<icecream95>
bschiett: GPU voltage scaling is completely broken in 5.9, I think it got fixed again in 5.10
<bschiett>
@icecream95 OK, i will try to go to 5.10 tomorrow and see what happens
<icecream95>
You could try lowering the maximum frequency in /sys/class/devfreq/* to see if that is what the problem is
<bschiett>
I have cpu frequency scaling disabled for my application
<bschiett>
not sure if that matters
<icecream95>
Panfrost hardcodes SIMPLE_ONDEMAND scaling by default for the GPU
<bschiett>
you mean change /sys/class/devfreq/ffa30000.gpu/governor to performance?
icecream95 has quit [Ping timeout: 258 seconds]
<bschiett>
@icecream95 I changed max_freq to the value from cur_freq and now the jellyfish demo seems to run without crashing... so you are probably right regarding the voltage/frequency stuff
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #panfrost
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
camus is now known as kaspter
<kinkinkijkin>
kernel 5.7.10 can confirm function
<kinkinkijkin>
still get a hang, going to check that out now
<kinkinkijkin>
not related to the same thing as the old hangs seemingly
<kinkinkijkin>
kmscube now runs without flickering with my fix, sway has reduced flickering and i couldnt launch es2gears
<archetech>
kinkinkijkin: can't you use a 5.9.x kerenl?
<archetech>
got better drm support I'd think
<kinkinkijkin>
if you were following this trail of testing you'd know im testing various kernels right now
<kinkinkijkin>
5.4 is a non-launch of panfrost, 5.8 onwards has massive devfreq issues on this device preventing basic function
<kinkinkijkin>
time to test x lol
<kinkinkijkin>
oh it actually successfully launches x
<chewitt>
^ that's what I'm using. It's probably a bit too minimal for Armbian use
<chewitt>
I know Igorpec was using my 5.7 branch with Armbian
<chewitt>
5.10 broke more of memeka's old hack patches (from 5.4) which prob. impacts on media use
<chewitt>
but I'll figure out a path forwards on that if/once panfrost runs
<bbrezillon>
kinkinkijkin: 'git log --oneline v5.7..v5.8 -- drivers/gpu/drm/panfrost' says nothing changed between 5.7 and 5.8, so if something broke, it's not in the panfrost driver :P
<bbrezillon>
hm, I get some commits between 5.7.10 and 5.8.18 though
<bbrezillon>
one of them is PM related
<bbrezillon>
3ea4204a722a ("drm/panfrost: Fix inbalance of devfreq record_busy/idle()")
camus has joined #panfrost
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
raster has joined #panfrost
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
camus has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
<robmur01>
kinkinkijkin: 5.5 to 5.9 inclusive will fail to scale the voltage correctly (i.e. at all) for DVFS. It's a long story...
<robmur01>
it was sorted in 5.10 with a significant rework of regulator handling that wasn't practical to consider backporting
cyrozap has quit [Remote host closed the connection]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
stikonas has joined #panfrost
sphalerite has quit [Quit: brb rebooting]
<chewitt>
^ I have those changes in my branch AFAIK
sphalerite has joined #panfrost
Elpaulo has quit [Quit: Elpaulo]
<macc24>
robmur01: this, was broken?
<macc24>
did my gpu not reclock between 5.5 and 5.9?
<robmur01>
oh it would have reclocked alright, it just never changed the voltage to match - hence problems if whatever the initial voltage was wasn't enough for higher OPPs
<macc24>
huh
<macc24>
5.10-rc4 includes this too?
<macc24>
and it's time to upgrade my c100pa from 5.8.1 lol
<robmur01>
most (non-chromebook) rk3399 boards seem to be able to hit max clock at the default voltage, and other SoCs don't do voltage scaling at all (or hide it in firmware behind the clock rate changes), so it was too easy to miss
<robmur01>
s/other/some other/
<macc24>
huh
<macc24>
does "other SoCs" include mt8183?
<robmur01>
yup, Clément's patches landed in 5.10-rc1
<macc24>
uh-huh
<robmur01>
unaffected SoCs are the ones without any regulators/voltages in DT, or where the OPPs all have the same voltage anyway (mostly Amlogics, I believe)
<macc24>
oh so probably not mt8183
<robmur01>
right, isn't MT8183 the one responsible for churning up the devfreq code in the first place such that the regulator fix couldn't be split out to backport? :P
<macc24>
uhhhhhhhhhhhhh
<macc24>
honestly, i don't know
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #panfrost
<macc24>
why does it look to me when there is some hack used/needed, it's always amlogic?
nlhowell has quit [Ping timeout: 264 seconds]
kaspter has quit [Quit: kaspter]
stikonas_ has joined #panfrost
stikonas has quit [Remote host closed the connection]
alpernebbi has joined #panfrost
chewitt has quit [Quit: Adios!]
paulk-leonov has quit [Ping timeout: 246 seconds]
paulk-leonov has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #panfrost
chewitt has joined #panfrost
<narmstrong>
macc24: keep in mind, avoiding hacks is impossible when integrating IPs
<bschiett>
@robmur01 so does this mean I should go to 5.10 to avoid problems? I'm on 5.9.12 now, i'm wondering if 5.10 has any issues i'm unaware of as @kinkinkijkin mentioned he had some problems with 5.10.
<robmur01>
bschiett: if you've got stability issues with the GPU crapping out when it scales up in frequency, probably
<bschiett>
@robmur01 I actually don't want the gpu to scale as I don't have a batter powered device. I want consistent performance on the CPU and GPU so I already disabled cpu freq scaling, but I can't seem to disable the scaling for the gpu in the kernel, it's either * or M
<robmur01>
I think you should be able to pull all the panfrost patches from 5.10-rc on top of 5.9 without too much bother - it's going back beyond that that gets harder
<bschiett>
batter=>battery
<robmur01>
you can always force devfreq to do what you want by either removing OPPs from the DT, or just adjusting scaling_{min,max}_freq in sysfs at runtime
<bschiett>
@robmur01 you mean cat a value to scaling_min_freq? I was also wondering if I should change the ondemand to performance or something like that.
<robmur01>
I don't think you can switch the devfreq governor without actual driver changes
<robmur01>
but since SIMPLE_ONDEMAND just scales between the given min and max, it's trivial to hold it steady by making them equal :)
<bschiett>
@robmur01 good point
<robmur01>
`cat scaling_max_freq > scaling_min_freq` is trivial turbo mode :D
<robmur01>
or vice-versa for powersave
<bschiett>
@robmur01 I guess I could put that in an init script somewhere or have my app write to those files... hmmmmmmmm maybe it's better to comment out OPPs in the DTs
<bschiett>
the question is if 5.9 has other stability issues that remain even if I apply this hack for the gpu
<robmur01>
last time I tried to boot my RK3288 something seemed dicky with the eMMC, but I don't recall anything else of note
<robmur01>
further back there was the VDSO clock bug, but that should be fixed in any recent stable release
<robmur01>
(and may have been before 5.9 anyway - I forget now)
<bschiett>
@robmur01 5.10 is mainline right now and mainline is not really stable, right? so i'm nervous about going from a stable to mainline kernel.
<robmur01>
we're at rc7 now so it should be pretty much ironed out (going to an rc8 is fairly rare)
<robmur01>
but yeah, if you want to play it safe I'd suggest just cherry-picking panfrost patches up to at least fd587ff01d59 "drm/panfrost: add regulators to devfreq"
<macc24>
bschiett: wtf
<macc24>
disabling all frequency scaling ≠ making it run at max clock speed
<macc24>
if linux doesn't change frequency of cpu or gpu, the boot frequency is used, not fastest one
<bschiett>
@macc24 hmmm... with freq scaling switched off in the kernel how do I verify the current freq of the cpu?
<macc24>
i don't know
<bschiett>
@macc24 I guess I could set the governor to performance but I read online that even if you do that the frequency can still be scaled back, and I don't want that
<macc24>
¯\_(ツ)_/¯
<macc24>
it's not the best idea to run it at 100% speed all the time
<bschiett>
@macc24 appreciate the reminder and input though, I thought turning off cpu freq scaling would force the cpu to max speed all the time. maybe that was stupid of me to assume that.
<robmur01>
yeah, if you don't have any scaling driver at all, nothing should ever touch the clocks - generally bootloaders set things up at pretty conservative speeds to avoid having to mess with board-specific regulators
<robmur01>
if you use a performance governor (or any other with its range forced to max speed only), it won't scale back due to load, but may still do so if you start running into thermal limits - and really you *do* want that
Elpaulo has joined #panfrost
<robmur01>
because being able to run really fast into a hard reset once the hardware OTP kicks in (or worse, a permanent reset if the chip dies) isn't all that useful ;)
<macc24>
"hardware OTP kicks in" ?
<bschiett>
ok, this is a mystery... rk3288 can run at 1.8Ghz yet there is no 1.8GHz opp in rk3288.dtsi ???? this is what I see in dmesg
<bschiett>
[ 3.949298] cpu cpu0: dev_pm_opp_set_rate: failed to find current OPP for freq 1800000000 (-34)
<bschiett>
[ 4.013061] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1800000 KHz, changing to: 1608000 KHz
<robmur01>
macc24: lots of SoCs have hardware over-temperature protection that will power down or reset the whole chip if it reaches a critical junction temperature
<macc24>
robmur01: oh, that OTP
<macc24>
i was thinking about one-time-programmable something
<robmur01>
bschiett: RK3288C and some of the later industrial versions are rated for 1.8GHz, original RK3288 only 1.6
stikonas_ is now known as stikonas
<bschiett>
@robmur01 ok got it, thanks
<robmur01>
in the Linux DTs the OPPs for the "C" variant are overridden in rk3288-veyron.dtsi
<macc24>
but rk3288-veyron.dtsi contains a bunch of other stuff, don't just #include italove
<bschiett>
where do i find the current and min/max gpu freq again ?
<macc24>
robmur01: any ideas? i'm too sleepy to think lul
<bschiett>
@macc24 everything works fine on my side now, thanks for your help and also thanks to @robmur01
<kinkinkijkin>
finally got my xu4 online to download xinit to say: x works, instead of flickering the rendering of every panel is literally just cut down the middle
<kinkinkijkin>
text in terminator cuts off midway through each block of it
<kinkinkijkin>
this is WITH my fix, which pads the cache with 0s to double size
<kinkinkijkin>
well
<kinkinkijkin>
parts of it
<kinkinkijkin>
glxgears in x11 hangs the system, same with es2gears_x11
<kinkinkijkin>
surprised x11 works at all tbh
<macc24>
does sway work?
<kinkinkijkin>
yes
<kinkinkijkin>
sway works, its what has been my testing platform this whole time
<kinkinkijkin>
macc24 im not talking about cadmium btw, my duet is still on chromeos
<macc24>
kinkinkijkin: yeah i know
<macc24>
even i can mread srtuff from context lol
<macc24>
also it may not be impossible to convert chromeos installation into cadmium in future
<kinkinkijkin>
yeah i was thinking about that one macc24
<kinkinkijkin>
debranding linux distros is a well-documented process, though can be complex, and that's all chromeos really is
<macc24>
well i don't trust myself to say that any script that i made would be good enough to use without requiring external storage
<macc24>
i was thinking more of using minimal rootfs with enough dependencies to use debootstrap as initramfs after rewriting kernel partition with kernel that supports kexec
<kinkinkijkin>
what i was thinking was a system takeover, you can fully replace an OS while it's running if you can get it to preload all of the files needed for the process into ram, or you can do it in multiple boots
<macc24>
have you seen chromeos' partition layout?
<kinkinkijkin>
yes, it's actually made for this process, since that's how chromeos updates itself
<macc24>
oh can you dump dtb before yeeting chromeos off your duet?
<kinkinkijkin>
it just plops in the entire new system into a secondary root partition, plops the new kernel into a secondary kernel partition, then reboots into a state that only requires files separate from the system, then plops everything over, and if you can manipulate that process to load your own code (which is possible in dev mode), you can do whatever you want
<kinkinkijkin>
yeah i can
<macc24>
cool
<macc24>
what i was thinking is: 1. write and verify chromeos kernel with kexec enabled kernel that is confirmed working to kernel partition 2. load cadmium kernel with 2-3GB initramfs of debian 3. repartition internal emmc and install cadmium
<macc24>
this doesn't touch internal emmc except kernel
<macc24>
i need to investigate this on my kevin while it has chromeos
<kinkinkijkin>
that would work too
<kinkinkijkin>
or could
tgall_foo has quit [Read error: Connection reset by peer]
tgall_foo has joined #panfrost
<kinkinkijkin>
im thinking it might be possible to make a fake chromeos update that, instead of installing chromeos, installs a minimal ram-loaded environ, which on booting installs cadmium
<macc24>
ill just go to sleep and think about this