12:12 <warpme_> guys: can somebody hint me how to rise vdec clock on 3328? Currently v4l2_request decode speed is like 1.1x framerate and I think issue is v.low clocked vdec (i.e. on H6 the same test gives 4.5x speed)

12:33 <robmur01> warpme_: figure out the relevant clocks, hack "assigned_clock_rates" appropriately into your DT

12:33 <robmur01> (s/_/-/, derp)

12:35 <robmur01> many folks are already doing that for the GPU clock, since that defaults to a measly 164MHz

12:36 <warpme_> robmur01: I already tired to play with this in dts. Issue is that i'm not receiving feedback from system :-( (my changes are not changing speed of decoding nor are visible in SoC clock summary). Here is relevant fragment:

12:36 <warpme_> https://www.irccloud.com/pastebin/ePlMYkRJ/

12:36 <warpme_> i simply don't know which one is about vdec clock....

12:37 <warpme_> for GPU/CPU i already managed. issue is video decoder....

12:39 <robmur01> https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L855

12:40 <robmur01> hclk shouldn't matter much, aclk *might* if by default it's low enough to limit memory access bandwidth

12:44 <robmur01> that said, looking at mainline rkvdec it already has clock support, so maybe just hacking in some more clk_set_rate() calls there might be more robust

13:13 <warpme_> https://www.irccloud.com/pastebin/IFWWM2qo/

13:14 <warpme_> https://www.irccloud.com/pastebin/SqwA5jBz/

13:14 <warpme_> and nothing. no any change in deceasing speed....

13:15 <warpme_> deceasing->decoding

16:27 <warpme_> heh - there must be something other limiting decoding speed. I increase clock in rk3399_vpu_hw.c from 400 to 600MHz and decoding speed is exactly the same. So maybe there is another clock having impact on data throughput feeding decoder or setting decoder clock in rk3399_vpu_hw.c has bug and decoder isn't set properly. change from 400->600 is seen in clk_summary:

16:27 <warpme_> https://www.irccloud.com/pastebin/H0rMFcGR/

16:27 <warpme_> i'm out of ideas...

19:13 <Esmil> I have arm64 .configs here for both rk3399-gru-keven and rk3399-rock-pi-4 that won't load modules unless I revert 5c3a7db0c7ec4bbd5bd3f48af9be859a8fa3e532

19:13 <Esmil> have anyone else seen that?

19:19 <robmur01> Esmil: yup, apparently it's down to a toolchain bug, but workarounds are pending - https://lore.kernel.org/lkml/20200808101222.5103093e@coco.lan/

19:20 <Esmil> robmur01: cool, thanks

19:21 <Esmil> i was actually going to say it probably had something to do with using rawhides latest aarch64-linux-gnu-

19:22 <robmur01> yeah, it's a bad time to be updating toolchains right now - GCC 10.2 also has a bug that prevents building some of the arm64 crypto code

19:27 <mps> Esmil: what is kernel version?

19:28 <Esmil> 5.8.6, but that patch entered in 5.8-rc1

19:29 <mps> 5.8.{1-5} works fine on my gru-kevin

19:30 <mps> lets try 5.8.6

19:30 <Esmil> right, then you're probably using an older toolchain without the bug

19:31 <Esmil> so you should be fine

19:31 <mps> CONFIG_CC_VERSION_TEXT="gcc (Alpine 10.2.0) 10.2.0"

19:32 <mps> that is for testing 5.9-rc series

19:32 <robmur01> actually, it looks like a fix is already in linux-next, commit e0328feda79d

19:33 <mps> and also for 5.8.5 => CONFIG_CC_VERSION_TEXT="gcc (Alpine 10.2.0) 10.2.0"

19:37 <robmur01> FWIW it's binutils that matters in this case, not GCC, and it's slightly dependent on kernel config too

19:41 <mps> hmm, that can explain why my arm32 boards don't boot with 5.8 series

19:42 <mps> just rebuild kernel without modules and it boots on one of the arm32

19:43 <mps> robmur01: thanks for explaining problem I'm contemplating about one week

20:13 <Esmil> cool, and now the latest master 5.9-rc3+ works too with the revert and vicencb's saradc fix

20:18 <mps> so, binutils-2.34 is safe for now