[PATCH 0/4] Rockchip: the vendor video codec for reference

[Randy Li <ayaka@soulik.info>]

Those patches are not for merging, I won't dream on it. As I said in
previous email, this driver is used for checking the status of the other
drivers. I have checked this driver would memory dump, its output looks
well. The reason I didn't use the video output is VOP driver doesn't
work well.

Also I want to offer a reference for those people who want to develop
the V4L2 request API driver for Rockchip and you can use this driver to
comparing the result as well. I should said either the one for sunxi nor
chromium have not reached the vendor production level.

I want to point out the obvious problem of the current V4L2 driver, I
think that is the one I developed years ago and refresh it in the last
year, then it is merged now.

That driver won't aware the parallel problem between the devices. The
video codec in Rockchip is very complex, the decoder and encoder are
NOT paired in some platforms. Also a decoder or encoder can share some
resource with the other decoder or encoder, requesting a mux in the GRF
device. We call those devices sharing resource a combo, they may or may
not having a individual IOMMU for each of its child devices. Also any of
those devies allowing support less codecs than its full state.

The RK3328 is a good example of that,
---------------------------------------------
| Video decoder for H264, VP8, JPEG, MPEG-4 Part 2
| Video decoder for AVS+
|--------------------------------------------
| Video decoder for H265, H265, VP9
|--------------------------------------------
| Video encoder for H265,
---------------------------------------------
| Video encoder for H264, JPEG
---------------------------------------------
that is why I rewrote the device tree files in these patches, the current
device tree is not suitable for the other platforms.

Besides, the V4L2 driver don't support the error correction and tolerance or
status recovery. That is more about the parser in the userspace but a
common parser won't be able to do that, different video codec vendor
would request a different method, also V4L2 request API is not suitable
to feedback status.

Anyway, the current developing for decoder is at lease acceptable for
those simple situations. But I think encoder would become a big issue,
lucky, it seems that nobody care about encoder. If you have ever looked
the video encoder for chromium, you would feel disgusted, it is not
Google's fault, just not suitable for V4L2.

I don't want to talk much about encoder here, basially the encoder is
much simpler than decoder requesting less dynamic settings, but those
dynamic settings request a more real time feedback or related.

I don't see much advantage the V4L2 brings, only the compatibility left.
The previous vendor driver would have DMA buffer problem but it is
solved in this one. Ndufresne told me about buffer fencing, but I don't
think it is useful only complication. That is why I didn't develop the
V4L2 for a long time.

I would attend the FOSDEM 2019, if you have any problem, I think you can
catch me easily there.

Randy Li (4):
  staging: video: rockchip: video codec for vendor API
  staging: video: rockchip: fixup for upstream
  staging: video: rockchip: add video codec
  arm64: dts: rockchip: add video codec for rk3399

 .../boot/dts/rockchip/rk3399-sapphire.dtsi    |  29 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi      |  68 +-
 drivers/staging/Kconfig                       |   2 +
 drivers/staging/Makefile                      |   1 +
 drivers/staging/rockchip-mpp/Kconfig          |  52 +
 drivers/staging/rockchip-mpp/Makefile         |  16 +
 drivers/staging/rockchip-mpp/mpp_debug.h      |  87 ++
 drivers/staging/rockchip-mpp/mpp_dev_common.c | 971 ++++++++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_common.h | 219 ++++
 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 855 +++++++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c  | 614 +++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c  | 576 +++++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vepu1.c  | 480 +++++++++
 drivers/staging/rockchip-mpp/mpp_dev_vepu2.c  | 477 +++++++++
 drivers/staging/rockchip-mpp/mpp_iommu_dma.c  | 292 ++++++
 drivers/staging/rockchip-mpp/mpp_iommu_dma.h  |  42 +
 drivers/staging/rockchip-mpp/mpp_service.c    | 197 ++++
 drivers/staging/rockchip-mpp/mpp_service.h    |  38 +
 include/uapi/video/rk_vpu_service.h           | 101 ++
 19 files changed, 5110 insertions(+), 7 deletions(-)
 create mode 100644 drivers/staging/rockchip-mpp/Kconfig
 create mode 100644 drivers/staging/rockchip-mpp/Makefile
 create mode 100644 drivers/staging/rockchip-mpp/mpp_debug.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_common.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu1.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vepu1.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_dev_vepu2.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_iommu_dma.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_iommu_dma.h
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.c
 create mode 100644 drivers/staging/rockchip-mpp/mpp_service.h
 create mode 100644 include/uapi/video/rk_vpu_service.h

-- 
2.20.1