13:35 <wv> hello, I'm having this custom rk3288 based board. (based on firefly aio-rk3288c). I'm building an image with yocto kirkstone mainline (so panfrost + hantro). when I don't enable the kernel modules (and so not loading panfrost, it works fine). However, when I load the panfrost module at bootup, it just hangs

13:38 <wv> These are the last messages on the console, ring a bell to anyone?

13:38 <wv> 5.906482] rockchip-vop ff930000.vop: Adding to iommu group 0

13:38 <wv> [ 5.914333] rockchip-vop ff940000.vop: Adding to iommu group 1

13:38 <wv> [ 5.934050] rk808-rtc rk808-rtc: registered as rtc0

13:38 <wv> [ 5.941878] rk808-rtc rk808-rtc: setting system clock to 2013-01-18T08:50:11 UTC (1358499011)

13:38 <wv> [ 5.948648] rockchip-drm display-subsystem: bound ff930000.vop (ops rockchip_drm_fini [rockchipdrm])

13:38 <wv> [ 5.962895] rockchip-drm display-subsystem: bound ff940000.vop (ops rockchip_drm_fini [rockchipdrm])

13:38 <wv> [ 5.964362] panfrost ffa30000.gpu: clock rate = 400000000

13:38 <wv> [ 5.973725] rockchip-drm display-subsystem: bound ff970000.dp (ops rockchip_drm_fini [rockchipdrm])

13:39 <wv> [ 5.979629] panfrost ffa30000.gpu: mali-t760 id 0x750 major 0x1 minor 0x0 status 0x0

13:39 <wv> [ 5.997996] panfrost ffa30000.gpu: features: 00000000,100277bf, issues: 00000000,24040400

13:39 <wv> on the firefly board, it's working fine btw

13:44 <bbrezillon> missing regulator?

13:52 <wv> well, it's indeed a 808 regulator in comparison with the 8846 on the firefly, but I adapted the devicetree, based on the 808 from the ebv design. If I did not, it just got in to a driver loading loop for some kind. (also regarding graphic driver) No it just hangs

14:00 <bbrezillon> can you try to set the mali-supply always-on?

14:01 <robmur01> IIRC you need "regulator-always-on" for the GPU supply else it gets stuck in shenanigans in the power domain code

14:04 <bbrezillon> it's hard to tell, but if it works on the same SoC, but different board, it's likely to be something board specific, and one thing that could cause the platform to hang is if the mali supply is disabled or doesn't have enough juice to power the GPU (could be an opp/devfreq issue too)

14:05 <robmur01> (somewhere there's a register read to check that the power domain is off, except that register is in fact also powered by the domain's supply)

14:05 <wv> vdd_gpu: DCDC_REG2 {

14:05 <wv> regulator-always-on;

14:05 <wv> regulator-boot-on;

14:05 <wv> regulator-min-microvolt = <850000>;

14:05 <wv> regulator-max-microvolt = <1250000>;

14:05 <wv> regulator-name = "vdd_gpu";

14:05 <wv> regulator-state-mem {

14:05 <wv> regulator-on-in-suspend;

14:06 <wv> regulator-suspend-microvolt = <1000000>;

14:06 <wv> };

14:06 <wv> };

14:06 <wv> it is on. I wan play with the min/max voltages? Is that safe?

14:09 <wv> bbrezillon, well, it's not exactly the same board. Power regulator is different, so it is possible we have an issue there

15:41 <wv> sometimes it gets to "[ 6.000746] [drm] Initialized panfrost 1.2.0 20180908 for ffa30000.gpu on minor 1

15:41 <wv> " and then blocks. If it would be a power or clock issue, I guess it would not get that far, would it?

16:48 <wv> now I disabled all vop in dtsi, and now it continues to boot. However I get an error along the way:

16:48 <wv> [5.760552] rockchip-drm display-subsystem: [drm:rockchip_drm_platform_probe [rockchipdrm]] *ERROR* No available vop found for display-subsystem.

16:48 <wv> but not sure what thes vop's are actually

16:50 <bbrezillon> wv: VOP == display controller

18:08 <urja> rockchip's "CRTC" (i mean, fair, controlling _CRTs_ has gotten kinda rare :P)

23:47 <wv> bbrezillon, and can they be a reason it gets stuck?