08:02 <warpme> detlevc3 : great work with vdec. I give it run on 3576 and 3588; h264 and hevc; 8bit and 10bit. On 3588: h264: all perfect. hevc: 90% of mine samples are playing nicely (including all 4k movies i have and 4k tv) :-) ; On 3576: boot hangs on vdec probe - if vdec iommu enabled. Disabling iommu gives it working: h264: any sample gives me pink flashes; hevc: same good as on 3588. All this is on 6.15.2 mainline.

08:29 <warpme> detlevc3 : huh - current code also gives me nice hevc/h264 on 3566. so it looks vdpu381 code is ok on 3566/3588. only 3576 still needs some love. qll work!

08:29 <warpme> (maybe 3576 issue is by iommu?)

10:50 <mmind00> CounterPillow: oooooh, the discussion is getting juicy ... but nice that the Intel person also found a use case :-D

11:56 <CounterPillow> right, I did notice the Intel macro at some point but totally forgot about it until now

12:27 <CounterPillow> I think the unspoken rule is that whenever you do extra work because a maintainer asks you to, the response to the extra work will be another maintainer asking you to undo it, so my frustration levels are well contained behind a curtain of post-ironic "it is what it is"

12:36 <mmind00> When I started readong that sentence my mind was autocompleting as "whenever you do extra work because a maintainer asks you to, the response to the extra work will be another maintainer asking you to do even more work" ;-)

12:43 <CounterPillow> technically also correct ;)

12:43 <CounterPillow> hence "please have mercy" in the cover letter

13:48 <detlevc3> warpme: I didn't see that on 3576, what board are you using ? Also, what branch ?

13:49 <detlevc3> warpme: I merged all the work into the staging rkvdec driver (currently here https://gitlab.collabora.com/detlev/linux/-/tree/add-vdpu381-and-383-to-rkvdec)

13:50 <warpme> detlevc3 : board is nanopi-m5; branch is 6.15.2 + https://gitlab.collabora.com/detlev/linux/-/commits/add-vdpu381-and-383-to-rkvdec

13:51 <warpme> i'm on 6.15 instead of 6.16 as I can't get sd card working with 6.16. so i backported all drivers/media + drivers/staging/rkvdec 6.16 commits to 6.15

13:52 <warpme> i assume backporting is ok as all works well on 3566/3588. issue is only on 3576 and only with h264

13:55 <warpme> also only 3576 gives me hang on rkvdec probe. hang happens when dt has iommu enabled. disabling iommu allows to me play with rkvdec on 3576. maybe 6.15 needs some iommu backports from 6.16?

14:03 <warpme> demsg is like this (aftet manual rkvdec probe): https://termbin.com/df5u

14:04 <detlevc3> warpme: iommu on rk3576 needs the rockchip,disable-mmu-reset flag set in device tree. If it is already there, I don't know what the issue is yet. bu I haven't tried to load it as a module, I wouldn't be surprised if the power management has issues

14:05 <detlevc3> backporting to 6.15 shouldn't be an issue

14:19 <warpme> i just diffed https://gitlab.collabora.com/detlev/linux/-/tree/add-vdpu381-and-383-to-rkvdec (branch you pointed here) with source i used ( https://gitlab.collabora.com/detlev/linux/-/commits/add-vdpu381-and-383-to-rkvdec) and there are diffs in hevc-common.{c,h} & vepu381/vepu383.c. Which branch i sgould use as reference? https://gitlab.collabora.com/detlev/linux/-/tree/add-vdpu381-and-383-to-rkvdec ?

14:20 <warpme> 3576.dtsi i'm using is almost exact the same as yours (from https://gitlab.collabora.com/detlev/linux/-/commits/add-vdpu381-and-383-to-rkvdec) (except i added thermal)

14:27 <warpme> i just rebuild 6.15 with rkvdec code from https://gitlab.collabora.com/detlev/linux/-/tree/add-vdpu381-and-383-to-rkvdec and h264 still pink flashes...

14:28 <detlevc3> I'm still actively working on that branch so it will be forced pushed from time to time

14:29 <warpme> my 3576 rkvdec hang at rkvdec probe tells something....

14:29 <detlevc3> Can you share the source video (or is it all of them ?)

14:29 <detlevc3> oh any sample, got it

14:30 <warpme> if you are referring to "pink flashes" on 3576 h264 - this is on any sample...

14:35 <detlevc3> with the latest branch I get 127/135 h264 fluster score on rock-4d, and no iommu issue, I'll try to get your same setup

14:39 <detlevc3> Ok, I also get a hang with iommu when built as a module

14:40 <warpme> ah "qll" (in a sense this may hint us somehow :-)))))

14:42 <warpme> "I'll try to get your same setup" - fantastic! milion thx as this allows me to quite quick offer hw decode on 3566/3588 for my users (we are on 6.15.2 kernel)

14:46 <warpme> (and of course early test runs on 3576)

14:47 <detlevc3> from what I see, you can either use clk_ignore_unused or have the module built-in (to run your pre-tests)

14:56 <warpme> with clk_ignore no more hangs on probe. h264 playback is now solid green. dmesg now has plenty iommu errors: https://termbin.com/52fi

14:57 <warpme> in dmesg is see: rkvdec 27b00100.rkvdec: No sram node, RCB will be stored in RAM is this expected?

14:58 <robmur01> Hmm, you definitely shouldn't be getting "swiotlb buffer is full" if things are supposed to be using IOMMUs...

15:00 <warpme> i think there is more general q: in respect of rkvdec: does 6.16 have something in iommu what 6.15 don't have?

15:01 <robmur01> "Page fault at 0x0000000000000000 of type read" also points to something being misprogrammed if you're relying on the DMA API, since iommu-dma will never give 0 as a valid DMA address

15:06 <detlevc3> No, there are no changes in iommu for that since 6.16. a read at 0 probably means something is not programmed correctly when starting the decoder

15:08 <detlevc3> and the SRAM, I see it too, need to get to it, it just makes it a bit slower

15:12 <warpme> detlevc3 : "since 6.16" or 6.15?

15:12 <detlevc3> 6.15, but I'll rebase on it to make sure

15:12 <warpme> 'k thx!

15:13 <detlevc3> already fixed sram and clock issue (will have to adapt rockchip iommu dt-bindings though)

15:14 <detlevc3> thanks for your testing !

15:32 <warpme> detlevc3 : should i backport to 6.15 (with hope this will make 3576 h264 working) or rather i need to wait till you confirm h264 works ok for you on 6.15 on 3576?

15:33 <detlevc3> Let me check it first, I did nothing that would solve iommu errors yet

15:38 <warpme> btw: i my repo i have also hevc backend for 33xx rkvdec (nice code by alex+kwiboo). as now new rkvdec uses structs - this code needs some serious rework... Such rework is over my skills. Maybe you have plans to add (at some point in time) rk33xx hevc support?

15:38 <detlevc3> yes, that is in my plan

15:39 <detlevc3> I think Kwiboo mentioned he was waiting for 6.16-rc1 tag to send his hevc patches

15:44 <warpme> fantastic!. your work is really appreciated by my users....some of them were awaiting for hevc on 3566 for years!

15:44 <detlevc3> warpme: still no issues with 6.15.2. Can you run fluster (fluster.py run -d GStreamer-H.264-V4L2SL-Gst1.0 -ts JVT-AVC_V1) and see if it complains still ?

15:45 <detlevc3> warpme: Hehe happy for them ! :) Hopefully it will get upstream soon

15:46 <warpme> sure. let me do this. i'll back to you later as now family screams for me :-/

15:48 <detlevc> detlevc: of course, see you later

15:49 <robmur01> IOMMU bindings> FWIW I'd be inclined to suspect dependent/linked clocks not being modelled correctly in the clk driver before than the IOMMU itself genuinely having more clocks, but I could be wrong

15:52 <robmur01> Um, "before than"? Make that either "before" or "rather than" :)

15:55 <detlevc> robmur01: Yes, that's totally right. The iommu is embedded into the decoder core, so it can depend on more clocks. In this case, it makes sense to add the dependency in the clock driver rather than in the iommu

17:13 <diederik> looking at SRAM (for rkvdec) and I see in rk3588-base.dtsi ``system_sram2: sram@ff001000 {`` but in the RK3588 TRM part 1 on page 19 I see FF000000 ? The address for system_sram1 does match the value in the TRM.

17:21 <diederik> looks like I need to do more research ...

17:33 <detlevc> the downstream dts uses sram@ff001000 too, I'll check if it works with FF000000

17:36 <diederik> AFAICT according to the TRM the sizes are the same, but not according to the dts (hence more research)

17:41 <robmur01> doesn't that just mean that the first 4KB of SRAM2 is being reserved for someone other than Linux?

17:42 <robmur01> (or at least *intended* to be)

17:45 <robmur01> and indeed the last 64KB as well, if the total size is really 1MB

17:47 <CounterPillow> I was hungry and ate those sections of the SRAM, sorry

17:55 <robmur01> yup, there you go: https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/+/refs/heads/master/plat/rockchip/rk3588/drivers/secure/secure.c#124

17:56 <robmur01> Burrrrp!

17:56 <CounterPillow> that was some fast sleuthing, nice

17:57 <diederik> nice :)

18:16 <detlevc> good find

18:34 <mmind00> detlevc: while you're here, could you refresh your vop reset series?

20:11 <detlevc> mmind00: right that was only partially merged

20:15 <detlevc> I need a screen I don't have here to retry it and confirm the issue is still present on latest kernel. I'll have a look at that next week

21:00 <ndufresne4> robmur01: Benjamin Gaignard will send the VSI iommu driver (for the AV1 decoder) next week, hope you can help get this right

23:09 <detlevc> warpme: also, two questions: what is your userspace situation ? (gstreamer or ffmpeg ? which versions ?) and can you send me a file that gives you those iommu errors ?