there are some parameters here /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu too.
ROCK 5B Debug Party Invitation
thank you so much for your very interesting feedback! it should be considered. we should use the good parameters for everyone.
3 Likes
I was planning to monitor this and npu.
Maybe create a very simple monitor (collect relevant info) and draw a chart in png at the final step, that’s the idea.
@tkaiser, i am following up on your findings, If i come up with something useful i push it to github.
i think @icecream95 started to reverse engineer the npu, maybe he can disclose some additional info about his findings.
I haven’t gotten very far with reversing the NPU, currently I’m still focusing on the GPU and it’s firmware.
(I’ve found that the MCU in the GPU runs at the same speed as the shader cores, so if anyone has a use for a Cortex-M7 clocked at 1 GHz which can access at least 1 GB of RAM through the GPU MMU…)
3 Likes
I think you mean the DMC governor, right? Before we move the PD voltage negotiation to the u-boot, we will have to enable DMC to save power to make sure we have enough power booting to kernel
PD voltage negotiation.
For Radxa (no idea whether they’re following this thread or just have a party in a hidden Discord channel) the results should be obvious especially when sending out review samples to those clueless YouTube clowns who will share performance numbers at least 10% less of what RK3588 is able to deliver.
We did not send any developer edition to any Youtubers, only developers.
Wow that’s insane… before this, the only chip with Cortex-M7 with such frequency I have ever seen is NXP’s i.mx rt1170.
You might get more power savings by CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y (spent a lot of time on this half a decade ago when still contributing to Armbian, ofc the distro then needs to switch back to schedutil or ondemand in a later stage e.g. by configuring cpufrequtils or some radxa-tune-hardware service).
Speaking of schedutil vs. ondemand and I/O performance the choice is rather obvious: https://github.com/radxa/kernel/commit/55f540ce97a3d19330abea8a0afc0052ab2644ef#commitcomment-79484235
I/O performance sucks without either performance or ondemand combined with io_is_busy (and to be honest: Radxa’s (lack of) feedback sucks too).
My older script code rotting unmaintained in some Armbian service won’t do it any more (and they won’t change anything about it since not giving a sh*t about low-level optimisations).
Yeah, but once you send out review samples IMHO you should’ve fixed the performance issues. Both.
Currently the only other RK3588(S) vendor affected by trashed memory performance is Firefly. All the others have not discovered/enabled the dmc device-tree node so far.
The following experiment was performed to test the effect of the “performance” governor in GPU and npu with the latest radxa kernel settings (ondemand without tkaiser’s tweaks) :
the board is idle (no GPU and npu activities):
root@rock5b:/sys# cat ./devices/platform/fdab0000.npu/devfreq/fdab0000.npu/available_frequencies
300000000 400000000 500000000 600000000 700000000 800000000 900000000 1000000000
root@rock5b:/sys# cat ./devices/platform/fdab0000.npu/devfreq/fdab0000.npu/cur_freq
1000000000
root@rock5b:/sys# cat ./devices/platform/fb000000.gpu/devfreq/fb000000.gpu/available_frequencies
1000000000 900000000 800000000 700000000 600000000 500000000 400000000 300000000
root@rock5b:/sys# cat ./devices/platform/fb000000.gpu/devfreq/fb000000.gpu/cur_freq
300000000
cat ./devices/platform/fb000000.gpu/devfreq/fb000000.gpu/governor
simple_ondemand
Running kmscube, glmark2-es-drm and the sdl2-cam (camera + npu +sdl) did not change cur_freq for gpu and npu.
Next:
root@rock5b:/home/rock# cat /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/governor
simple_ondemand
root@rock5b:/home/rock# cat /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/cur_freq
300000000
root@rock5b:/home/rock# echo performance > /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/governor
root@rock5b:/home/rock# cat /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/cur_freq
1000000000
root@rock5b:/home/rock# cat /sys/devices/platform/fdab0000.npu/devfreq/fdab0000.npu/governor
userspace
root@rock5b:/home/rock# echo performance > /sys/devices/platform/fdab0000.npu/devfreq/fdab0000.npu/governor
root@rock5b:/home/rock# cat /sys/devices/platform/fdab0000.npu/devfreq/fdab0000.npu/governor
performance
root@rock5b:/home/rock# cat /sys/devices/platform/fdab0000.npu/devfreq/fdab0000.npu/cur_freq
1000000000
Got a ~10% boost with sdl2-cam demo and i have the feeling that npu became much more responsive.
glmark2-es-drm and testgles2 are capped at 60 fps and kmscube does not report fps. What would be the best way to measure gpu with a possible gain?
I will test with “performance” governor and see what i get.
Applied:
echo 1 > /sys/devices/system/cpu/cpu4/cpufreq/ondemand/io_is_busy
echo 25 > /sys/devices/system/cpu/cpu4/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpu4/cpufreq/ondemand/sampling_down_factor
echo 200000 > /sys/devices/system/cpu/cpu4/cpufreq/ondemand/sampling_rate
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/io_is_busy
echo 25 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_down_factor
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
Got ~20% boost overall.
From 15 FPS to 18 FPS, again, that depends on object being detected, before i had 20 fps peaks, now 24 fps. I think the bottleneck is on opencv.
performance governor:
cat /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
performance
performance
24 fps:
1 Like
Please keep in mind that we’ve 3 cpufreq policies on RK3588: 0, 4 and 6. And please also keep in mind that cpufreq is just one piece of the puzzle if the task is bottlenecked by CPU cores (maybe opencv). The scheduler and maybe also IRQ processing is another piece.
So I would suggest to switch to performance for all those tests [1] and then try to pin the CPU relevant stuff to the A76 cores either by prefixing calls with taskset -c 4-7 or using cgroups.
Also interesting how /proc/interrupts looks like prior and after such tests since if there’s an awful lot of IRQs and those remain on cpu0 this is another area of optimisation.
[1] Not just cpufreq governor but all of them. IMO it makes more sense to optimize for performance now and for powersavings later once max performance is known:
/sys/devices/platform/dmc/devfreq/dmc/governor
/sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/governor
/sys/devices/platform/fdab0000.npu/devfreq/fdab0000.npu/governor
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor
/sys/devices/system/cpu/cpufreq/policy6/scaling_governorBTW: There’s also debugfs to check frequencies:
root@rock-5b:~# cat /sys/kernel/debug/clk/clk_summary | grep scmi_clk_
scmi_clk_npu 0 3 0 200000000 0 0 50000
scmi_clk_gpu 0 2 0 200000000 0 0 50000
scmi_clk_ddr 0 0 0 528000000 0 0 50000
scmi_clk_cpub23 0 0 0 408000000 0 0 50000
scmi_clk_cpub01 0 0 0 408000000 0 0 50000
scmi_clk_dsu 0 0 0 0 0 0 50000
scmi_clk_cpul 0 0 0 408000000 0 0 50000
Now switch DRAM and CPU cores to performance:
root@rock-5b:~# echo performance >/sys/devices/platform/dmc/devfreq/dmc/governor
root@rock-5b:~# echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
root@rock-5b:~# echo performance >/sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
root@rock-5b:~# echo performance >/sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
And confirm:
root@rock-5b:~# cat /sys/kernel/debug/clk/clk_summary | grep scmi_clk_
scmi_clk_npu 0 3 0 200000000 0 0 50000
scmi_clk_gpu 0 2 0 200000000 0 0 50000
scmi_clk_ddr 0 0 0 2112000000 0 0 50000
scmi_clk_cpub23 0 0 0 2400000000 0 0 50000
scmi_clk_cpub01 0 0 0 2400000000 0 0 50000
scmi_clk_dsu 0 0 0 0 0 0 50000
scmi_clk_cpul 0 0 0 1800000000 0 0 50000
For whatever reasons these clocks match the following cpufreq policies:
-
0-3-->cpul -
4-5-->cpub01 -
6-7-->cpub23
For q&d monitoring while running experiments:
#!/bin/bash
renice 19 $BASHPID >/dev/null 2>&1
i=0
printf "%7s %7s %7s %7s %7s %7s %7s\n" $(sed 's/cpul/cpua/' </sys/kernel/debug/clk/clk_summary | sort | awk -F" " '/scmi_clk_/ {print $1}' | sed -e 's/scmi_clk_//' -e 's/000000//' -e 's/cpub01/cpu4-5/' -e 's/cpub23/cpu6-7/' -e 's/cpua/cpu0-3/' | tr "\n" " " | tr '[:lower:]' '[:upper:]')
while true ; do
printf "%7s %7s %7s %7s %7s %7s %7s\n" $(sed 's/cpul/cpua/' </sys/kernel/debug/clk/clk_summary | sort | awk -F" " '/scmi_clk_/ {print $5}' | sed -e 's/000000//' | tr "\n" " ")
sleep 5
((i++))
if [ $i -eq 24 ]; then
i=0
printf "\n%7s %7s %7s %7s %7s %7s %7s\n" $(sed 's/cpul/cpua/' </sys/kernel/debug/clk/clk_summary | sort | awk -F" " '/scmi_clk_/ {print $1}' | sed -e 's/scmi_clk_//' -e 's/000000//' -e 's/cpub01/cpu4-5/' -e 's/cpub23/cpu6-7/' -e 's/cpua/cpu0-3/' | tr "\n" " " | tr '[:lower:]' '[:upper:]')
fi
done
Looks like this then:
root@rock-5b:/home/tk# check-rk3588-clocks
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 600 1200 528 0 200 200
600 816 1200 528 396 200 200
816 1008 408 528 0 200 200
600 816 1416 1068 594 200 200
^CFrom the Cortex-M7 datasheet:
If it can do a gigahertz even at 28nm, then at 8nm it shouldn’t even be a challenge.
I’ve also benchmarked the command-stream interpreter (which is seperate from the MCU), and when using the instructions for loading and storing 64 bytes at a time (similar to AArch32 LDM/STM, but adjusted to work with the 96 available 32-bit registers) it can memcpy at about 310 MB/s. Probably the MCU is faster, but it uses a separate address space so mapping memory is harder.
1 Like
Well, situation with RK3588 and its much more capable memory controller seems to differ 
Using sbc-bench’s -g switch to do consumption measurements with this device: Power monitoring on socket 2 of powerbox-1 (Netio 4KF, FW v3.2.0, XML API v2.4, 233.43V @ 49.98Hz).
We’re talking about ~1740 mW when clocking the LPDDR4 in idle with 528 MHz vs. ~2420 mW when at 2112 MHz. A whopping 680 mW difference at least on my board with 16GB RAM.
All CPU cores and dmc governor set to powersave (only the mW value at the bottom counts since averaged from a few measurements before):
System health while idling for 4 minutes:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp mW
11:57:45: 408/ 408MHz 0.89 7% 0% 6% 0% 0% 0% 37.9°C 20
11:58:15: 408/ 408MHz 0.54 0% 0% 0% 0% 0% 0% 37.9°C 1740
11:58:45: 408/ 408MHz 0.33 0% 0% 0% 0% 0% 0% 37.0°C 1740
11:59:15: 408/ 408MHz 0.20 0% 0% 0% 0% 0% 0% 37.0°C 1750
11:59:45: 408/ 408MHz 0.12 1% 0% 0% 0% 0% 0% 37.0°C 1740
12:00:15: 408/ 408MHz 0.14 1% 0% 0% 0% 0% 0% 36.1°C 1750
12:00:46: 408/ 408MHz 0.08 0% 0% 0% 0% 0% 0% 37.0°C 1740
12:01:16: 408/ 408MHz 0.05 0% 0% 0% 0% 0% 0% 37.0°C 1740
Now only dmc governor set to performance:
System health while idling for 4 minutes:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp mW
12:07:21: 408/ 408MHz 1.02 12% 0% 11% 0% 0% 0% 40.7°C 20
12:07:51: 408/ 408MHz 0.62 0% 0% 0% 0% 0% 0% 39.8°C 2550
12:08:21: 408/ 408MHz 0.37 0% 0% 0% 0% 0% 0% 39.8°C 2480
12:08:51: 408/ 408MHz 0.29 0% 0% 0% 0% 0% 0% 39.8°C 2460
12:09:21: 408/ 408MHz 0.17 0% 0% 0% 0% 0% 0% 39.8°C 2450
12:09:51: 408/ 408MHz 0.10 0% 0% 0% 0% 0% 0% 39.8°C 2440
12:10:22: 408/ 408MHz 0.06 0% 0% 0% 0% 0% 0% 39.8°C 2430
12:10:52: 408/ 408MHz 0.18 0% 0% 0% 0% 0% 0% 39.8°C 2420
Quick check with dmc_ondemand results in numbers slightly above powersave:
System health while idling for 4 minutes:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp mW
12:17:08: 408/ 408MHz 1.03 15% 0% 14% 0% 0% 0% 38.8°C 10
12:17:38: 408/ 408MHz 0.62 0% 0% 0% 0% 0% 0% 37.9°C 1760
12:18:08: 408/ 408MHz 0.38 0% 0% 0% 0% 0% 0% 37.9°C 1800
12:18:38: 408/ 408MHz 0.23 0% 0% 0% 0% 0% 0% 37.9°C 1770
12:19:08: 408/ 408MHz 0.20 0% 0% 0% 0% 0% 0% 37.9°C 1760
12:19:39: 408/ 408MHz 0.12 0% 0% 0% 0% 0% 0% 37.0°C 1760
12:20:09: 408/ 408MHz 0.07 0% 0% 0% 0% 0% 0% 37.0°C 1740
12:20:39: 408/ 408MHz 0.04 0% 0% 0% 0% 0% 0% 37.0°C 1740
Edit: corrected values above from 700mW difference to 680mW. And tried to confirm with another PSU (this time 15W RPi USB-C power brick, before some 24W USB PD charger):
-
powersave/ 528 MHz: 35.2°C, idle consumption: 1280mW -
performance/ 2112 MHz: 37.9°C, idle consumption: 1910mW
A 630mW difference this time (the measurements include all losses by PSU and cable between PSU and board and those PSUs might differ in low load situations).
The only thing i did not change was the dmc/governor .
No visible improvement with (maybe 0.5 fps spikes):
Previous:
root@rock5b:/home/rock# cat /sys/kernel/debug/clk/clk_summary | grep scmi_clk_
scmi_clk_npu 0 3 0 200000000 0 0 50000
scmi_clk_gpu 0 2 0 200000000 0 0 50000
scmi_clk_ddr 0 0 0 528000000 0 0 50000
scmi_clk_cpub23 0 0 0 408000000 0 0 50000
scmi_clk_cpub01 0 0 0 408000000 0 0 50000
scmi_clk_dsu 0 0 0 0 0 0 50000
scmi_clk_cpul 0 0 0 1416000000 0 0 50000
performance:
echo performance >/sys/devices/platform/dmc/devfreq/dmc/governor
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance >/sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo performance >/sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
checking again:
root@rock5b:/home/rock# cat /sys/kernel/debug/clk/clk_summary | grep scmi_clk_
scmi_clk_npu 0 3 0 200000000 0 0 50000
scmi_clk_gpu 0 2 0 200000000 0 0 50000
scmi_clk_ddr 0 0 0 2112000000 0 0 50000
scmi_clk_cpub23 0 0 0 2256000000 0 0 50000
scmi_clk_cpub01 0 0 0 2256000000 0 0 50000
scmi_clk_dsu 0 0 0 0 0 0 50000
scmi_clk_cpul 0 0 0 1800000000 0 0 50000
and monitoring while running the demo:
root@rock5b:/home/rock# ./mon.sh
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 2256 2256 2112 0 200 200
1800 2256 2256 2112 0 200 200
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 300 1000
1800 2256 2256 2112 0 200 1000
Update: forgot gpu and npu (1 fps improvement)
root@rock5b:/home/rock# ./mon.sh
CPU0-3 CPU4-5 CPU6-7 DDR DSU GPU NPU
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000
1800 2256 2256 2112 0 1000 1000So adjusting the cpufreq settings brought the biggest gain. Still interested in SMP/IRQ affinity… do both interrupts and tasks end up on big cores? Can you please post /proc/interrupts contents after such a test run and check with htop/atop where the tasks run and whether there are CPU bottlenecks present?
This may be a naive question, but what kernel are you using to have access to the dmc governor settings ? I pulled the latest one from yesterday on the radxa github repo and am still not seeing the entry under /sys. Did you change any config ? I would have liked to test here to take measurements as well. The debug/clk entries say I’m at 2112 MHz for the DDR, and idling around 1.6W (mesured at the USB plug).
check:
https://github.com/radxa/kernel/commit/4ce9a743b253c0c344686085213de1c4059b9d59
CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ=y
Thanks! So I’m having the right option:
$ zgrep DMC_DEVFREQ /proc/config.gz
CONFIG_ARM_ROCKCHIP_DMC_DEVFREQ=y
I checked the DTB and found the matching dmc node:
$ dtc -I dtb -O dts < /boot/dtbs/5.10.66-21-rockchip-gbbe5dbfb385d/rockchip/rk3588-rock-5b.dtb
dmc {
compatible = "rockchip,rk3588-dmc";
interrupts = <0x00 0x49 0x04>;
interrupt-names = "complete";
devfreq-events = <0x37>;
clocks = <0x0e 0x04>;
clock-names = "dmc_clk";
operating-points-v2 = <0x38>;
upthreshold = <0x28>;
downdifferential = <0x14>;
system-status-level = <0x01 0x04 0x08 0x08 0x02 0x01 0x10 0x04 0x10000 0x04 0x1000 0x08 0x4000 0x08 0x2000 0x08 0xc00 0x08>;
auto-freq-en = <0x01>;
status = "okay";
center-supply = <0x39>;
mem-supply = <0x3a>;
phandle = <0x1d8>;
};
One possibility could be that I’m running on rock5b-v1.1.dtb instead, as it doesn’t have this entry, but I’m seeing regulator-name “vcc3v3_pcie2x1l2” which isn’t in that one, so I’m still digging.
Edit: here’s what I’m seeing there:
$ ll /sys/devices/platform/dmc
ls: cannot access '/sys/devices/platform/dmc': No such file or directory
$ sudo find /sys -name '*dmc*
'
/sys/bus/platform/drivers/rockchip-dmc
/sys/firmware/devicetree/base/dmc
/sys/firmware/devicetree/base/__symbols__/dmc
/sys/firmware/devicetree/base/__symbols__/dmc_opp_table
/sys/firmware/devicetree/base/dmc-opp-table
$ ll /sys/bus/platform/drivers/rockchip-dmc
total 0
drwxr-xr-x 2 root root 0 Sep 4 17:58 .
drwxr-xr-x 180 root root 0 Sep 4 17:58 ..
--w------- 1 root root 4096 Sep 4 18:10 bind
--w------- 1 root root 4096 Sep 4 18:10 uevent
--w------- 1 root root 4096 Sep 4 18:10 unbind
But I do see the opp:
$ ll /sys/firmware/devicetree/base/dmc-opp-table
total 0
drwxr-xr-x 6 root root 0 Sep 4 17:58 .
drwxr-xr-x 373 root root 0 Sep 4 17:58 ..
-r--r--r-- 1 root root 20 Sep 4 18:12 compatible
-r--r--r-- 1 root root 14 Sep 4 18:12 name
-r--r--r-- 1 root root 8 Sep 4 18:12 nvmem-cell-names
-r--r--r-- 1 root root 4 Sep 4 18:12 nvmem-cells
drwxr-xr-x 2 root root 0 Sep 4 17:58 opp-1068000000
drwxr-xr-x 2 root root 0 Sep 4 17:58 opp-1560000000
drwxr-xr-x 2 root root 0 Sep 4 17:58 opp-2750000000
drwxr-xr-x 2 root root 0 Sep 4 17:58 opp-528000000
-r--r--r-- 1 root root 4 Sep 4 18:12 phandle
-r--r--r-- 1 root root 48 Sep 4 18:12 rockchip,leakage-voltage-sel
-r--r--r-- 1 root root 4 Sep 4 18:12 rockchip,low-temp
-r--r--r-- 1 root root 4 Sep 4 18:12 rockchip,low-temp-min-volt
-r--r--r-- 1 root root 4 Sep 4 18:12 rockchip,temp-hysteresis/proc/interrupts and top while running:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
13: 30521 13066 10028 9245 11691 8999 13868 2998 GICv3 26 Level arch_timer
14: 260790 69239 10867 19868 140050 2317 1490 613 GICv3 321 Level rk_timer
15: 0 0 0 0 0 0 0 0 GICv3 23 Level arm-pmu
16: 23 0 0 0 0 0 0 0 GICv3 105 Level dmc
17: 11253 0 0 0 0 0 0 0 GICv3 126 Level fb000000.gpu
18: 1 0 0 0 0 0 0 0 GICv3 125 Level fb000000.gpu
19: 25112 0 0 0 0 0 0 0 GICv3 124 Level fb000000.gpu
20: 232 0 0 0 0 0 0 0 GICv3 247 Level ehci_hcd:usb1
21: 0 0 0 0 0 0 0 0 GICv3 248 Level ohci_hcd:usb3
22: 5319 0 0 0 0 0 0 0 GICv3 250 Level ehci_hcd:usb2
23: 0 0 0 0 0 0 0 0 GICv3 251 Level ohci_hcd:usb4
24: 0 0 0 0 0 0 0 0 GICv3 425 Level rockchip_usb2phy
25: 2 0 0 0 0 0 0 0 GICv3 423 Level rockchip_usb2phy
26: 2 0 0 0 0 0 0 0 GICv3 424 Level rockchip_usb2phy
27: 13858 0 0 0 0 0 0 0 GICv3 349 Level fd880000.i2c
28: 8172 0 0 0 0 0 0 0 GICv3 142 Level fdab9000.iommu, fdab0000.npu
29: 0 0 0 0 0 0 0 0 GICv3 143 Level fdab9000.iommu, fdab0000.npu
30: 0 0 0 0 0 0 0 0 GICv3 144 Level fdab9000.iommu, fdab0000.npu
31: 0 0 0 0 0 0 0 0 GICv3 151 Level fdb50400.vdpu
32: 0 0 0 0 0 0 0 0 GICv3 150 Level fdb50800.iommu
33: 5449 0 0 0 0 0 0 0 GICv3 146 Level fdb60f00.iommu, rga3_core0
34: 0 0 0 0 0 0 0 0 GICv3 147 Level fdb70f00.iommu, rga3_core1
35: 0 0 0 0 0 0 0 0 GICv3 148 Level rga2
36: 0 0 0 0 0 0 0 0 GICv3 161 Level fdb90000.jpegd
37: 0 0 0 0 0 0 0 0 GICv3 162 Level fdb90480.iommu
38: 0 0 0 0 0 0 0 0 GICv3 154 Level fdba0000.jpege-core
39: 0 0 0 0 0 0 0 0 GICv3 153 Level fdba0800.iommu
40: 0 0 0 0 0 0 0 0 GICv3 156 Level fdba4000.jpege-core
41: 0 0 0 0 0 0 0 0 GICv3 155 Level fdba4800.iommu
42: 0 0 0 0 0 0 0 0 GICv3 158 Level fdba8000.jpege-core
43: 0 0 0 0 0 0 0 0 GICv3 157 Level fdba8800.iommu
44: 0 0 0 0 0 0 0 0 GICv3 160 Level fdbac000.jpege-core
45: 0 0 0 0 0 0 0 0 GICv3 159 Level fdbac800.iommu
46: 0 0 0 0 0 0 0 0 GICv3 149 Level fdbb0800.iommu, fdbb0000.iep
47: 0 0 0 0 0 0 0 0 GICv3 133 Level fdbd0000.rkvenc-core
48: 0 0 0 0 0 0 0 0 GICv3 131 Level fdbdf000.iommu
49: 0 0 0 0 0 0 0 0 GICv3 132 Level fdbdf000.iommu
50: 0 0 0 0 0 0 0 0 GICv3 136 Level fdbe0000.rkvenc-core
51: 0 0 0 0 0 0 0 0 GICv3 134 Level fdbef000.iommu
52: 0 0 0 0 0 0 0 0 GICv3 135 Level fdbef000.iommu
53: 0 0 0 0 0 0 0 0 GICv3 127 Level fdc38100.rkvdec-core
54: 0 0 0 0 0 0 0 0 GICv3 128 Level fdc38700.iommu
55: 0 0 0 0 0 0 0 0 GICv3 129 Level fdc48100.rkvdec-core
56: 0 0 0 0 0 0 0 0 GICv3 130 Level fdc48700.iommu
57: 8199 0 0 0 0 0 0 0 GICv3 163 Level rkisp_hw
58: 4102 0 0 0 0 0 0 0 GICv3 165 Level rkisp_hw
59: 0 0 0 0 0 0 0 0 GICv3 166 Level rkisp_hw
60: 0 0 0 0 0 0 0 0 GICv3 164 Level fdcb7f00.iommu
61: 2 0 0 0 0 0 0 0 GICv3 187 Level rkcifhw
62: 0 0 0 0 0 0 0 0 GICv3 145 Level fdce0800.iommu
63: 0 0 0 0 0 0 0 0 GICv3 179 Level rockchip-mipi-csi2
64: 0 0 0 0 0 0 0 0 GICv3 180 Level rockchip-mipi-csi2
65: 9667 0 0 0 0 0 0 0 GICv3 188 Level fdd97e00.iommu, fdd90000.vop
67: 0 0 0 0 0 0 0 0 GICv3 201 Level fde80000.hdmi
68: 0 0 0 0 0 0 0 0 GICv3 202 Level dw-hdmi-qp-cec
69: 0 0 0 0 0 0 0 0 GICv3 203 Level fde80000.hdmi
70: 771 0 0 0 0 0 0 0 GICv3 204 Level fde80000.hdmi
71: 1 0 0 0 0 0 0 0 GICv3 392 Level dw-hdmi-qp-hpd
72: 0 0 0 0 0 0 0 0 GICv3 285 Level pcie-sys
77: 14515 0 0 0 0 0 0 0 GICv3 235 Level dw-mci
78: 8 0 0 0 0 0 0 0 GICv3 237 Level mmc1
81: 10 0 0 0 0 0 0 0 GICv3 118 Level fea10000.dma-controller
82: 0 0 0 0 0 0 0 0 GICv3 119 Level fea10000.dma-controller
83: 0 0 0 0 0 0 0 0 GICv3 120 Level fea30000.dma-controller
84: 0 0 0 0 0 0 0 0 GICv3 121 Level fea30000.dma-controller
85: 73 0 0 0 0 0 0 0 GICv3 350 Level fea90000.i2c
86: 759 0 0 0 0 0 0 0 GICv3 352 Level feab0000.i2c
87: 195 0 0 0 0 0 0 0 GICv3 353 Level feac0000.i2c
88: 19920 0 0 0 0 0 0 0 GICv3 360 Level feb20000.spi
89: 0 0 0 0 0 0 0 0 GICv3 429 Level rockchip_thermal
90: 0 0 0 0 0 0 0 0 GICv3 430 Level fec10000.saradc
91: 128 0 0 0 0 0 0 0 GICv3 355 Level fec80000.i2c
92: 442 0 0 0 0 0 0 0 GICv3 356 Level fec90000.i2c
93: 10 0 0 0 0 0 0 0 GICv3 122 Level fed10000.dma-controller
94: 0 0 0 0 0 0 0 0 GICv3 123 Level fed10000.dma-controller
100: 0 0 0 0 0 0 0 0 GICv3 426 Level rockchip_usb2phy
103: 0 0 0 0 0 0 0 0 GICv3 205 Level fdea0000.hdmi
104: 0 0 0 0 0 0 0 0 GICv3 206 Level dw-hdmi-qp-cec
105: 0 0 0 0 0 0 0 0 GICv3 207 Level fdea0000.hdmi
106: 1799 0 0 0 0 0 0 0 GICv3 208 Level fdea0000.hdmi
107: 1 0 0 0 0 0 0 0 GICv3 393 Level dw-hdmi-qp-hpd
108: 0 0 0 0 0 0 0 0 GICv3 209 Level rk_hdmirx_cec
109: 0 0 0 0 2 0 0 0 GICv3 468 Level rk_hdmirx-hdmi
110: 0 0 0 0 0 0 0 0 GICv3 211 Level rk_hdmirx-dma
121: 0 0 0 0 0 0 0 0 GICv3 455 Edge debug-signal
122: 0 0 0 0 0 0 0 0 GICv3 365 Level debug
123: 0 0 0 0 0 0 0 0 GICv3 140 Level av1d-master
124: 0 0 0 0 0 0 0 0 GICv3 139 Level irq_cache
126: 0 0 0 0 0 0 0 0 rockchip_gpio_irq 7 Level rk806
127: 0 0 0 0 0 0 0 0 rk806 0 Edge rk805_pwrkey_fall
128: 0 0 0 0 0 0 0 0 rk806 1 Edge rk805_pwrkey_rise
129: 0 0 0 0 0 0 0 0 rk806 7 Level rk806_vb_low
131: 0 0 0 0 0 0 0 0 GICv3 254 Level xhci-hcd:usb5
132: 0 0 0 0 0 0 0 0 GICv3 253 Level xhci-hcd:usb7
133: 8 0 0 0 0 0 0 0 rockchip_gpio_irq 12 Level fsc_interrupt_int_n
134: 0 0 0 0 0 0 0 0 rockchip_gpio_irq 8 Level hym8563
135: 0 0 0 0 0 0 0 0 rockchip_gpio_irq 22 Edge rk_hdmirx-5v
136: 0 0 0 0 0 0 0 0 rockchip_gpio_irq 29 Level headset_input
146: 0 0 0 0 0 0 0 0 ITS-MSI 570425352 Edge PCIe PME
147: 0 8489 0 0 0 0 0 0 ITS-MSI 570949632 Edge enP4p65s0-0
148: 0 0 0 0 0 0 0 0 ITS-MSI 570949633 Edge enP4p65s0-1
149: 0 0 0 0 0 0 0 0 ITS-MSI 570949634 Edge enP4p65s0-2
150: 0 0 0 0 0 0 0 0 ITS-MSI 570949635 Edge enP4p65s0-3
151: 0 0 0 0 0 0 0 0 ITS-MSI 570949636 Edge enP4p65s0-4
152: 0 0 0 0 0 0 0 0 ITS-MSI 570949637 Edge enP4p65s0-5
153: 0 0 0 0 0 0 0 0 ITS-MSI 570949638 Edge enP4p65s0-6
154: 0 0 0 0 0 0 0 0 ITS-MSI 570949639 Edge enP4p65s0-7
155: 0 0 0 0 0 0 0 0 ITS-MSI 570949640 Edge enP4p65s0-8
156: 0 0 0 0 0 0 0 0 ITS-MSI 570949641 Edge enP4p65s0-9
157: 0 0 0 0 0 0 0 0 ITS-MSI 570949642 Edge enP4p65s0-10
158: 0 0 0 0 0 0 0 0 ITS-MSI 570949643 Edge enP4p65s0-11
159: 0 0 0 0 0 0 0 0 ITS-MSI 570949644 Edge enP4p65s0-12
160: 0 0 0 0 0 0 0 0 ITS-MSI 570949645 Edge enP4p65s0-13
161: 0 0 0 0 0 0 0 0 ITS-MSI 570949646 Edge enP4p65s0-14
162: 0 0 0 0 0 0 0 0 ITS-MSI 570949647 Edge enP4p65s0-15
163: 0 5204 0 0 0 0 0 0 ITS-MSI 570949648 Edge enP4p65s0-16
164: 0 0 0 0 0 0 0 0 ITS-MSI 570949649 Edge enP4p65s0-17
165: 0 0 0 2816 0 0 0 0 ITS-MSI 570949650 Edge enP4p65s0-18
166: 0 0 0 0 0 0 0 0 ITS-MSI 570949651 Edge enP4p65s0-19
167: 0 0 0 0 0 0 0 0 ITS-MSI 570949652 Edge enP4p65s0-20
168: 0 0 0 0 0 0 1 0 ITS-MSI 570949653 Edge enP4p65s0-21
169: 0 0 0 0 0 0 0 0 ITS-MSI 570949654 Edge enP4p65s0-22
170: 0 0 0 0 0 0 0 0 ITS-MSI 570949655 Edge enP4p65s0-23
171: 0 0 0 0 0 0 0 0 ITS-MSI 570949656 Edge enP4p65s0-24
172: 0 0 0 0 0 0 0 0 ITS-MSI 570949657 Edge enP4p65s0-25
173: 0 0 0 0 0 0 0 0 ITS-MSI 570949658 Edge enP4p65s0-26
174: 0 0 0 0 0 0 0 0 ITS-MSI 570949659 Edge enP4p65s0-27
175: 0 0 0 0 0 0 0 0 ITS-MSI 570949660 Edge enP4p65s0-28
176: 0 0 0 0 0 0 0 0 ITS-MSI 570949661 Edge enP4p65s0-29
177: 0 0 0 0 0 0 0 0 ITS-MSI 570949662 Edge enP4p65s0-30
178: 0 0 0 0 0 0 0 0 ITS-MSI 570949663 Edge enP4p65s0-31
IPI0: 23874 32924 35537 30001 3000 3622 848 1528 Rescheduling interrupts
IPI1: 67590 9725 6223 7860 27526 17384 24073 22052 Function call interrupts
IPI2: 0 0 0 0 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 14154 22057 11678 10418 8117 2917 4299 1336 Timer broadcast interrupts
IPI5: 237063 18620 6360 2514 183085 1552 2639 737 IRQ work interrupts
IPI6: 0 0 0 0 0 0 0 0 CPU wake-up interrupts
Err: 0