00:25 <stdint> Myy, which VPU

00:25 <stdint> or you can just tell me the address you want to access

00:25 <stdint> Myy, you can decode a single H264 frame as long as it is the I frame

00:26 <stdint> But the SPS and PPS is still necessary

00:26 <stdint> s/is/are/

01:08 <Myy> Yeah, well, I'm just feeding registers prepared by RKMPP to the VPU. It seems that RKMPP already does all the preparation required. On my little test, I just change the file descriptors by preset DMA addresses and launch the decoding. The IRQ is triggered correctly however the output address looks untouched so I'm wondering what I'm missing.

01:09 <Myy> I'm using the very first frame of an H264 movie as data. It doesn't seem to have any references beside itself. On the RKMPP side, all the "reference" registers are set to the output file descriptor.

01:10 <Myy> There's only one register that bothers me, it's the DIR MV register, which purpose I don't understand.

01:11 <Myy> Anyway, the code is here : https://github.com/Miouyouyou/Mainline-Rockchip-VPU/blob/dev/test-devicetree-dma-to-from-user.c . It runs on a mainline kernel... However it doesn't produce any result in the end, so it's not very useful.

01:16 <Myy> The static data is here : https://github.com/Miouyouyou/Mainline-Rockchip-VPU/blob/dev/test_static_data.h It's the registers state, the encoded frame and the "qtable" dumped using a modified version of RKMPP (modified to perform the dumps).

01:18 <Myy> I'm wondering if there's some timing/tempo to respect between setting up registers and launching a decode operation.

02:03 <stdint> Myy, you may contact me on your time, I don't understand what you are doing

02:03 <stdint> maybe after sleep, you would feel better

02:18 <Myy> Alright

02:26 <Myy> Technically, I'm just trying to decode a single static frame using the VPU, on mainline kernels. I used a 4.4 kernel with a modified version of RKMPP to dump the very first frame of an H264 movie, along with the registers sent to the VPU and the "QTable" which is the CABAC table with a few additional settings. I converted all these data (Encoded frame, Registers, Qtable) into C arrays. Then I created a driver for a 4.18 kernel

02:26 <Myy> that allocate 3 DMA buffers for the encoded frame, the decoded output and the QTable, since the VPU needs the DMA addresses of these 3 elements to perform its work. I then used the dumped registers, changed the file descriptors references RKMPP used, to these DMA addresses accordingly. And then I'm executing a decoding pass. The thing is, the IRQ handler setup to the VPU is triggered but the DMA buffer allocated for the decoded

02:26 <Myy> frame remains untouched.

02:27 <Myy> I'll send you an email tonight (it's 4:30AM here) describing my current code and the issues I'm encountering.

02:27 <Myy> If I could decode a single static frame correctly, I could then use this as a base to start porting the RKMPP service driver to 4.19 kernels.

08:40 <hunderteins> hello

13:40 <eballetbo> Myy, ezequiel is also doing some h264 decoding work, maybe will be good for you to talk :)

13:42 <ezequielg> what was the question? :-)

13:48 <ezequielg> eballetbo: seems Myy is not here.

14:03 <eballetbo> oh right, seems he left, maybe he will join again

14:05 <Myy> Meow

14:07 <eballetbo> Myy, ezequielg is also doing some h264 decoding work, maybe will be good for you to talk :)

14:08 <ezequielg> Myy: \o hey, I am looking at your repo https://github.com/Miouyouyou/Mainline-Rockchip-VPU/

14:08 <ezequielg> fwiw, I'm also working on h264 decoding. Have a driver that uses the Request API and I'm testing it with https://github.com/bootlin/v4l2-request-test

14:08 <ezequielg> currently, i'm debugging why there is no frame rdy IRQ

14:09 <ezequielg> i'll push this driver today/monday if you want to take a look and debug as well :-)

14:17 <Myy> Hey !

14:17 <Myy> Nice :3

14:17 <Myy> Do you get the result of the decoding though ?

14:20 <ezequielg> nope, decoding is not working. Seems I'm getting a "buffer empty" IRQ :(

14:26 <Myy> Hmm, interesting. I got the same issue. The IRQ handler is triggered but the output buffer is untouched.

14:27 <Myy> I'll try to review the old V4L2 driver once more. https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/platform/rockchip-vpu/rk3288_vpu_hw_h264d.c

14:27 <ezequielg> the IRQ is triggered and what's the value of interrupt register?

14:27 <ezequielg> btw, i'm using rk3399, but I could try rk3288 as well.

14:28 <Myy> The interrupt register is set at 0x00010100

14:28 <Myy> The IRQ number is 60

14:29 <Myy> But that doesn't help me much. According to the registers definition I have, this state means "IRQ" and "IRQ Disable" at the same time.

14:29 <ezequielg> lol

14:30 <Myy> I'm starting to wonder if I'm not missing some clocks definitions

14:30 <ezequielg> well, i'll push some code soon and point you at it. it's mainline based :-)

14:30 <Myy> The mainline kernel DTS node of the VPU MMU didn't have a "Power" property, which made it unusable at first

14:31 <Myy> So I think I'll do another "search the differences" game with the 4.4 and 4.18 RK3288 DTSI

14:31 <ezequielg> hm, good catch. I missed that missing property!

14:33 <Myy> https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.18/DTS/0026-ARM-DTSI-rk3288-Set-the-VPU-MMU-power-domains.patch

18:05 <Myy> Well, at least, it's not a page fault since even after setting the IOMMU fault handler with a logging function, I get no additional logs.