Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1947987imu; Sat, 5 Jan 2019 10:34:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/VTQP1iXIZqfGZNEqRb1DrkaHeBQkdYYAPbUgBqjCJSItNko2s/wmKSLkO9dEwgzf9Flhsx X-Received: by 2002:a62:cd1:: with SMTP id 78mr56958267pfm.219.1546713256429; Sat, 05 Jan 2019 10:34:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546713256; cv=none; d=google.com; s=arc-20160816; b=ZRioUA5TJBcMHKhJVcv4pHUGScAYEmF+C8uoItwunAxKx/Irfdx3WO7gshfD5zxOZk oXKPNTr87rYFPEr5WPsu5rlQOLhLq9NQWADiy+tqUhZp5vSSuClODe2lPqYGlO6CahMW AkzM2ajfU8PabHfcFLAK+ysHoW4y2AV7fP+hUabEirLbYQOV6VcRvohluluKg2FFWXrN +xoEOUEKrHV1iiYeKNP/0gbyLnWGL+7LtFiag4Hrt3jvteMTqK0kuctj3bXHHzLq6GWV q96t0gecXUojzTVGQzOvjrZjO/ly8zMzClKAOhLjIMueeR5i/d3AGEKbcXJpWnZVRYmm 1p8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=ImA8Peqkr+nN1av3YlAs6RNpvtj5Y5ZE/wJ+/me73hI=; b=F7S0mSZAAqwPoiDS93mWI9qEcBsjgQPS2vzLNs/QeqitDCqNEuQqnYLtkEvrQBgzWk xCxcdY+00bUYhOeqfgTXvSz1+RYRyuZLFZ7zdk3f4UVK1L0DUuay2qH3tOCxGGmHAipE ge7F3O/6tqvmJlwhtW/RGZ4WA0vTQZH7OoMSBIUH8dpIbsQv1y1MIBMTz6VgnQ3FnO5P kGeRf72ITnlhqEsSh4zp0gUaSFweLDeQdSak75JXV/SkDvDm2u5UjIQ1VhMH7eIgKh+D BsoG8MwRRG6w0IDyzpzN6te9EC1XrRZED58Vv1jP8wwMUU+hM0FdZIH/XMwTsbKkGueK g7jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n19si7782302pgd.271.2019.01.05.10.34.01; Sat, 05 Jan 2019 10:34:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726481AbfAEScA (ORCPT + 99 others); Sat, 5 Jan 2019 13:32:00 -0500 Received: from kozue.soulik.info ([108.61.200.231]:40212 "EHLO kozue.soulik.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726355AbfAEScA (ORCPT ); Sat, 5 Jan 2019 13:32:00 -0500 Received: from misaki.sumomo.pri (unknown [IPv6:2001:470:b30d:2:c604:15ff:0:a00]) by kozue.soulik.info (Postfix) with ESMTPA id EBDDB100F5C; Sun, 6 Jan 2019 03:32:35 +0900 (JST) From: Randy Li To: linux-rockchip@lists.infradead.org Cc: Randy Li , nicolas.dufresne@collabora.com, myy@miouyouyou.fr, paul.kocialkowski@bootlin.com, mchehab@kernel.org, linux-media@vger.kernel.org, hverkuil@xs4all.nl, heiko@sntech.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/4] Rockchip: the vendor video codec for reference Date: Sun, 6 Jan 2019 02:31:46 +0800 Message-Id: <20190105183150.20266-1-ayaka@soulik.info> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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