wzyy2
commented
6 years ago It might be kernel driver problem and morty branch is not maintained, you could checkout to pyro.
Open teseo-sw opened 6 years ago
wzyy2
commented
6 years ago It might be kernel driver problem and morty branch is not maintained, you could checkout to pyro.
wzyy2
commented
6 years ago " Boardcon-RK3288", oh, so is it your own board? You could try to increase gpu voltage, it might be hardware problem.
teseo-sw
commented
6 years ago Yes, it is a custom board based on EM3288 from Boardcon.
I switched to pyro (libmali-midgard-r9p0-r0p0.so) but nothing changed.
Voltage settings:
vdd_gpu: syr828@41 {
compatible = "silergy,syr828";
fcs,suspend-voltage-selector = <1>;
reg = <0x41>;
regulator-name = "vdd_gpu";
regulator-min-microvolt = <850000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-ramp-delay = <6000>;
vin-supply = <&vcc_sys>;
};Are there any particular values you recommend?
wzyy2
commented
6 years ago Search "gpu" "opp" in rk3288.dtsi.
teseo-sw
commented
6 years ago rk3288.dtsi:
gpu: gpu@ffa30000 {
compatible = "arm,malit764",
"arm,malit76x",
"arm,malit7xx",
"arm,mali-midgard";
reg = <0xffa30000 0x10000>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "JOB", "MMU", "GPU";
clocks = <&cru ACLK_GPU>;
clock-names = "clk_mali";
operating-points = <
/* KHz uV */
600000 1250000
/* 500000 1200000 - See crosbug.com/p/33857 */
400000 1100000
300000 1000000
200000 950000
100000 950000
>;
#cooling-cells = <2>; /* min followed by max */
power-domains = <&power RK3288_PD_GPU>;
status = "disabled";
};Does this mean I should set regulator-[min,max]-microvolt to 950000 and 1250000 respectively?
teseo-sw
commented
6 years ago I upgraded to current release-4.4 and latest user-space mali drivers (r14-p0) but the problem persists. Here is the relevant dmesg output (note that the messages are the same regardless of whether mali fails to initialize or not:
root@ptam8:~# dmesg | grep mali
[ 1.403601] mali ffa30000.gpu: Failed to get regulator
[ 1.409452] mali ffa30000.gpu: Power control initialization failed
[ 4.868433] W : [File] : drivers/gpu/arm/midgard/platform/rk/mali_kbase_config_rk.c; [Line] : 135; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.
[ 4.891492] mali ffa30000.gpu: GPU identified as 0x0750 r0p0 status 1
[ 4.902349] I : [File] : drivers/gpu/arm/midgard/backend/gpu/mali_kbase_devfreq.c; [Line] : 284; [Func] : kbase_devfreq_init(); success initing power_model_simple.
[ 4.925636] mali ffa30000.gpu: Probed as mali0I built mali driver as module and the messages about "regulator" and "power control" disappeared. It seems now that the driver never fails, probably because initialization happens at a later time:
root@ptam8:~# dmesg | grep mali
[ 7.035345] W : [File] : drivers/gpu/arm/midgard/platform/rk/mali_kbase_config_rk.c; [Line] : 135; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.
[ 7.064590] mali ffa30000.gpu: GPU identified as 0x0750 r0p0 status 1
[ 7.086305] I : [File] : drivers/gpu/arm/midgard/backend/gpu/mali_kbase_devfreq.c; [Line] : 284; [Func] : kbase_devfreq_init(); success initing power_model_simple.
[ 7.119409] mali ffa30000.gpu: Probed as mali0I don't think that is intended behavior though, isn't it?
alandingbc
commented
6 years ago Hi, teseo-sw. I have the same problem. The error of regulator error in mali initialization actually is due to the order of modules loading. Generally, the regulator devices attached to the i2c bus. So the mali driver easily gets loading earlier than i2c slave devices. You can just modify the file 'mali_kbase_core_linux.c' and modify the function 'module_init()' to 'late_initcall()'. I have tested it and worked. But it seems the regulator doesn't actually cause the problem about the mali driver & libmali & egl. It's so weird that I have the correct userspace libmali which matching the kernel driver, however get eglinitialize error with 0x3001 too. If I use the xserver build by rockchip, it's okay. Maybe the glamor 2d acceleration influence the egl? All of these really confuse me. Hope Rockchip could provide instructions.
ydirson
commented
4 years ago FWIW, I start getting this error when migrating a yocto build from sumo to warrior, without changing kernel and with minimal meta-rockchip changes.
ydirson
commented
4 years ago In my case, if I use the exact same glmark2 version from sumo in my warrior build, use ltrace -S on glmark2-es2 and compare the results, what stands out is:
-eglInitialize(0x24b4680, 0x7ffc284788, 0x7ffc28478c, 0xffffffff <unfinished ...>
+eglInitialize(0x5598e03e50, 0x7fe7bc2c00, 0x7fe7bc2c04, 0xffffffff <unfinished ...>
...
-openat@SYS(AT_FDCWD, "/dev/dri/card0", 0x2, 00) = 8
...
-<... eglInitialize resumed> ) = 1
...
+openat@SYS(AT_FDCWD, "", 0x2, 00) = -2
+<... eglInitialize resumed> ) = 0
+eglGetError(0, 0, 0x5598e03e68, 0) = 0x3001For some reason libMali tries to open the driver with an empty string!
Often the mali driver stack fails to initialize:
The only thing I can do at that point is to repeatedly reboot until driver starts up correctly and I'm able to access the GPU again.
I'm using the
mortybranch of meta-rockchip.