Probe fails on kernel v4.17-rc6

[baruchsiach]

On load of the rk-vcodec module in kernel v4.17-rc6 on the Tinkerboard I get the following error:

[   60.420563] rockchip-pm-domain ff730000.power-management:power-controller: failed to get ack on domain 'pd_video', val=0x8021c
[   60.437160] rk-vcodec ff9a0000.vpu-service: probe device
[   60.443114] rk-vcodec ff9a0000.vpu-service: checking hw id ffff
[   60.449739] rk-vcodec ff9a0000.vpu-service: error: hw info check failed
[   60.457138] rk-vcodec ff9a0000.vpu-service: probe err:-22
[   60.463172] rk-vcodec ff9a0000.vpu-service: init success

The core driver code ignores the PM error, so it goes on to call the rk-vcodec probe routine. Still, I suspect the the probe failure has something to do with the earlier PM failure.

Is there anything I am missing?

Thanks,
baruch

[Miouyouyou]

Well, in order :

1. I don't think I'll maintain this code at the moment, as I'd like to rewrite another, based on the information I got from MPP and the V4L2 drivers.
2. I haven't tested this code since the 4.15 and the only one that "did not crash with MPV" at least was the one in the "retry" branch.
3. As stated by Tomasz Figa in your mail exchange, there's actually a v4l2 implementation of the VPU code, which I intend to salvage and reuse for a new driver.

I spent a lot (too much) time understanding how things worked with the current VPU code, since a lot of things are done using magic indices on a set of registers sent "as-is" by the MPP library, which in turn has the definition of the registers and what they're for.
I also spent too much time trying to understanding what this IOMMU code was doing in the DRM part of driver, while it was just setting up the VPU so that it can read the encoded frame from user memory, and write the decoded one into a buffer allocated by the DRM driver, through DMA operations. A lot of things, like DMA Scatter-Gather tables realignment to satisfy IOMMU alignment restrictions, are currently done manually based on code copy pasted from the kernel, with no real understanding of the issues, as reported to me on the #linux-rockchip IRC channel.

Since a few people, in the Armbian forums, have currently set up a "quick tutorial" on how to set up Armbian to get MPV and the VPU working with 4.4 kernel, I used that opportunity to start recompiling a MPP version with a bunch of logs, providing me the content of the registers sent to the driver, with their interpretation.
I still have to get a copy of the "before" and "after" buffers so that I can use them to generate automated tests, when writing the new driver.
I see that the Chromium team has prepared v4l2 user-space libraries to communicate with their v4l2. That should help testing and doing things "correctly".

The V4L2 driver ported to 4.4 kernel by the Rockchip team is available here :
https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/media/platform/rockchip-vpu

The most useful files being :
https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/platform/rockchip-vpu/rk3288_vpu_regs.h (Registers definitions)
https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/platform/rockchip-vpu/rk3288_vpu_hw_h264d.c (Registers use and setup for H264 decoding)
https://github.com/rockchip-linux/kernel/blob/release-4.4/drivers/media/platform/rockchip-vpu/rk3288_vpu_hw_vp8d.c (Registers use and setup for VP8 decoding)

[Miouyouyou]

Now, for the real issue, I have no idea why it didn't receive any "ack" from the right domain. If you do a dmesg | grep domain, do you get anything ?