07:57 <warpme> detlevc : i tried with kernel build exactly from yours branch (+ 1 patch for my board dt); vanilla ffmpeg+ my v4l2 patches; diederik mpv+ debian 2paches and still have artefacts on h264-Sat sample. Artefacts are ~8-9 plays for 10. ~1 in 10 plays is ok however. Maybe you can provide me your .deb packages for kernel, ffmpeg and mpv? I can try use your blobs and see how it goes?

11:46 <diederik> I just discovered a weird ... and an (bit) emberassing kernel warning on my rk3328-rock64: spi-nor spi0.0: supply vcc not found, using dummy regulator

11:46 <diederik> Which is surprising since I made this commit: 2339bc6b42a6 ("arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3328-rock64")

11:48 <diederik> And I have a very hard time believing that didn't test/validate that fix before sending. I also don't understand the warning as it *is* defined in the dts

12:06 <CounterPillow> I'd double-check that you're booting with the right DT, you can use `dtc -I fs -O dts /proc/device-tree` to read a decompilation of the currently booted tree

12:13 <diederik> Thanks! That 'dtc' command does indeed show the property is not there ...

12:17 <diederik> ah, this Rock64 has a separate /boot partition, which is different from what I normally use. So I'm 95%+ sure that's where the issues lies. phew :)

13:06 <diederik> That took WAY longer then it should have, but it's fixed now \o/ Thanks CounterPillow :)

15:21 <CounterPillow> https://overviewer.org/~pillow/up/7280cc11f7/rock4d-radeon-2.mp4 https://overviewer.org/~pillow/up/471ddd4de4/IMG_20250621_164655.jpg

18:49 <mmind00> Kwiboo: in some recent mail you were named the rk3576 clock expert :-D ... have you seen any quirky difference between vendor firmware and upstream wrt. something like the SPLL? I did the DSI things for rk3576 and similar to rk3588 have no output, yet Andy could just pick my patches and got DSI output with vendor firmware beneath his kernel

18:53 <mmind00> The clock driver (vendor and mainline) does set up the SPLL in SPL, and it did look like the rate should match the expected 702MHz, but something still seems to be fishy

19:17 <CounterPillow> that was my recent mail ;)

19:19 <CounterPillow> mainline RK3576 clock tree seems incomplete (more so than the vendor clcok tree is), I noticed some clock gates missing, including some that were even missing from vendor, when I got started on DFI. Worth a look there. There other important thing I've noticed in the vendor kernel is that it'll add a I think 10us delay to the PD power on for some PDs, namely VOP and NPU.

19:20 <CounterPillow> though if that delay was a problem it'd probably cause a full SoC hang, see https://gitlab.collabora.com/fratti/linux/-/commit/9ca028ae52554e4c841f4c65ea1d2b24fbbd22e5

19:32 <mmind00> CounterPillow: Andy was able to just cherrypick my dsi patches, and got DSI working on mainline ... just by switching to vendor-firmware ... so that thing does seem to do "something"

19:33 <mmind00> I already did try vendor TF-A ... with no change ... so it does seem to hang on either u-boot (or maybe optee?)

19:39 <CounterPillow> https://github.com/rockchip-linux/u-boot/tree/next-dev/ the official gh repo seems to have rk3576 stuff in it

19:44 <CounterPillow> https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/clk/rockchip/clk_rk3576.c#L2537-L2637 could play battleships guessing which register write it is if that's the difference ;)

19:51 <mmind00> CounterPillow: diffing that to mainline does not show differences at least in that part ... so I seem to have "stolen" the correct parts

21:35 <Kwiboo> mmind00, CounterPillow: agree, there is not much that should be different in u-boot related to clocks to my knowledge, however vendor u-boot could have some driver for e.g. the display that inits something that mainline u-boot does not