From patchwork Thu Apr 20 09:13:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 97727 Delivered-To: patch@linaro.org Received: by 10.182.246.10 with SMTP id xs10csp629061obc; Thu, 20 Apr 2017 02:14:18 -0700 (PDT) X-Received: by 10.99.94.66 with SMTP id s63mr7011085pgb.34.1492679658173; Thu, 20 Apr 2017 02:14:18 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5si5738018pfc.403.2017.04.20.02.14.17; Thu, 20 Apr 2017 02:14:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-samsung-soc-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-samsung-soc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-samsung-soc-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943756AbdDTJOR (ORCPT + 4 others); Thu, 20 Apr 2017 05:14:17 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:13896 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942399AbdDTJOK (ORCPT ); Thu, 20 Apr 2017 05:14:10 -0400 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OOP00FYMAZJ5X20@mailout3.w1.samsung.com> for linux-samsung-soc@vger.kernel.org; Thu, 20 Apr 2017 10:14:07 +0100 (BST) Received: from eusmges5.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170420091407eucas1p1d01457bd605007af3a3d6f8688d0b7cf~3EDsH-3M10633806338eucas1p1Y; Thu, 20 Apr 2017 09:14:07 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges5.samsung.com (EUCPMTA) with SMTP id 5B.F2.25577.EDB78F85; Thu, 20 Apr 2017 10:14:06 +0100 (BST) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20170420091406eucas1p24c50a0015545105081257d880727386c~3EDrHdUrL1181311813eucas1p2h; Thu, 20 Apr 2017 09:14:06 +0000 (GMT) X-AuditID: cbfec7f5-f792f6d0000063e9-9b-58f87bdef6f4 Received: from eusync2.samsung.com ( [203.254.199.212]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id FC.69.17452.06C78F85; Thu, 20 Apr 2017 10:16:16 +0100 (BST) Received: from AMDC2765.digital.local ([106.116.147.25]) by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OOP00DTXAZACLB0@eusync2.samsung.com>; Thu, 20 Apr 2017 10:14:06 +0100 (BST) From: Marek Szyprowski To: dri-devel@lists.freedesktop.org, linux-samsung-soc@vger.kernel.org Cc: Marek Szyprowski , Inki Dae , Seung-Woo Kim , Andrzej Hajda , Bartlomiej Zolnierkiewicz , Tobias Jakobi , Rob Clark , Daniel Vetter Subject: [RFC 0/4] Exynos DRM: add Picture Processor extension Date: Thu, 20 Apr 2017 11:13:36 +0200 Message-id: <1492679620-12792-1-git-send-email-m.szyprowski@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsWy7djPc7r3qn9EGOzosbS4te4cq8XGGetZ Lf5vm8hsceXrezaLSfcnsFjMOL+PyWLtkbvsFs8X/mC2mDH5JZtF2+oPrA5cHnu/LWDx2Dnr LrvH/e7jTB7/jrF79G1ZxejxeZNcAFsUl01Kak5mWWqRvl0CV8ar9duZC6boVaztvc3cwLhG tYuRk0NCwERi8sU2FghbTOLCvfVsXYxcHEICSxklTq57yQThfGaUuN13kA2mY+rNa8wQiWWM Eg2HHrFAOA1MEovPPmcGqWITMJToetsF1iEi4CbRdHgmK0gRs8AZJok9v7uZQBLCAnYSby8t Aurm4GARUJW4uSAeJMwr4CEx7XILM8Q2OYmTxyazQtif2ST2L3YGKZcQkJXYdACqxEXixNEF jBC2sMSr41vYIWwZic6Og0wQdj+jRFOrNoQ9g1Hi3FteCNta4vDxi2DjmQX4JCZtm84MMZ5X oqNNCKLEQ+Lg4odQFzhK9G2YyA5SIiQQK7F2sdAERukFjAyrGEVSS4tz01OLTfWKE3OLS/PS 9ZLzczcxAiP59L/jX3cwLj1mdYhRgINRiYc3Iu17hBBrYllxZe4hRgkOZiURXsXyHxFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeblOXYsQEkhPLEnNTk0tSC2CyTJxcEo1MO7Oup93Ljyd4dtp 6WmMHgKdqVYimxxigmaGteX6i3OkM+TPCmDU2tn+xF9N2N0l4Rifw0mTXIMFkqFL2u9L3JOc pu2bc+FeibP3BI5P5Z0rDmy8nnt+1p07d/RYfqzL2r8nJOOldROL7VnOcqmbTCaJ7isj74W5 RW/dkD35pp92/IOcAwaPlViKMxINtZiLihMBQfPLyOACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsVy+t/xK7oJNT8iDHqn8lrcWneO1WLjjPWs Fv+3TWS2uPL1PZvFpPsTWCxmnN/HZLH2yF12i+cLfzBbzJj8ks2ibfUHVgcuj73fFrB47Jx1 l93jfvdxJo9/x9g9+rasYvT4vEkugC3KzSYjNTEltUghNS85PyUzL91WKTTETddCSSEvMTfV VilC1zckSEmhLDGnFMgzMkADDs4B7sFK+nYJbhmv1m9nLpiiV7G29zZzA+Ma1S5GTg4JAROJ qTevMUPYYhIX7q1n62Lk4hASWMIo0TH1ASuE08Qk8Xjjf7AqNgFDia63XWwgtoiAm0TT4Zms IDazwDkmiXuLfUFsYQE7ibeXFrF0MXJwsAioStxcEA8S5hXwkJh2uQVqmZzEyWOTWScwci9g ZFjFKJJaWpybnltsqFecmFtcmpeul5yfu4kRGMDbjv3cvIPx0sbgQ4wCHIxKPLwRad8jhFgT y4orcw8xSnAwK4nwKpb/iBDiTUmsrEotyo8vKs1JLT7EaAq0eyKzlGhyPjC68kriDU0MzS0N jYwtLMyNjJTEeUs+XAkXEkhPLEnNTk0tSC2C6WPi4JRqYGTrV2Rl+pw831vpVJrNrrBD4TP6 PZPetzkwz5tW/9ggdJv8V5NjxVcaF04Ny2bc9WObdVzMD6nvDsI/Xp7zCd/s89jFqnHBTUsR mwknJMsFpeKnavrtT1ysp8Cv2Lp+29K7W25Iqmiztm9YrejedZ0nYL7S74P7foZuWD3B/erd 3sPpMg0SQkosxRmJhlrMRcWJAB/Hp/h2AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170420091406eucas1p24c50a0015545105081257d880727386c X-Msg-Generator: CA X-Sender-IP: 182.198.249.179 X-Local-Sender: =?utf-8?q?Marek_Szyprowski=1BSRPOL-Kernel_=28TP=29=1B?= =?utf-8?b?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?utf-8?q?Marek_Szyprowski=1BSRPOL-Kernel_=28TP=29=1BSam?= =?utf-8?q?sung_Electronics=1BSenior_Software_Engineer?= X-Sender-Code: =?utf-8?q?C10=1BEHQ=1BC10CD02CD027392?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170420091406eucas1p24c50a0015545105081257d880727386c X-RootMTR: 20170420091406eucas1p24c50a0015545105081257d880727386c References: Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org Dear all, This is an updated proposal for extending EXYNOS DRM API with generic support for hardware modules, which can be used for processing image data from the one memory buffer to another. Typical memory-to-memory operations are: rotation, scaling, colour space conversion or mix of them. This is a follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer processors", which has been rejected as "not really needed in the DRM core": http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html In this proposal I moved all the code to Exynos DRM driver, so now this will be specific only to Exynos DRM. I've also changed the name from framebuffer processor (fbproc) to picture processor (pp) to avoid confusion with fbdev API. Here is a bit more information what picture processors are: Embedded SoCs are known to have a number of hardware blocks, which perform such operations. They can be used in paralel to the main GPU module to offload CPU from processing grapics or video data. One of example use of such modules is implementing video overlay, which usually requires color space conversion from NV12 (or similar) to RGB32 color space and scaling to target window size. The proposed API is heavily inspired by atomic KMS approach - it is also based on DRM objects and their properties. A new DRM object is introduced: picture processor (called pp for convenience). Such objects have a set of standard DRM properties, which describes the operation to be performed by respective hardware module. In typical case those properties are a source fb id and rectangle (x, y, width, height) and destination fb id and rectangle. Optionally a rotation property can be also specified if supported by the given hardware. To perform an operation on image data, userspace provides a set of properties and their values for given fbproc object in a similar way as object and properties are provided for performing atomic page flip / mode setting. The proposed API consists of the 3 new ioctls: - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture processors, - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture processor, - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given property set. The proposed API is extensible. Drivers can attach their own, custom properties to add support for more advanced picture processing (for example blending). This proposal aims to replace Exynos DRM IPP (Image Post Processing) subsystem. IPP API is over-engineered in general, but not really extensible on the other side. It is also buggy, with significant design flaws - the biggest issue is the fact that the API covers memory-2-memory picture operations together with CRTC writeback and duplicating features, which belongs to video plane. Comparing with IPP subsystem, the PP framework is smaller (1807 vs 778 lines) and allows driver simplification (Exynos rotator driver smaller by over 200 lines). Open questions: - How to expose pp capabilities and supported formats? Currently this is done with a drm_exynos_pp_get structure and DRM_IOCTL_EXYNOS_PP_GET ioctl. However one can try to use IMMUTABLE properties for capabilities and src/dst format set. Rationale: recently Rob Clark proposed to create a DRM property with supported pixelformats and modifiers: http://www.spinics.net/lists/dri-devel/msg137380.html - Is it okay to use DRM objects and properties API (DRM_IOCTL_MODE_GETPROPERTY and DRM_IOCTL_MODE_OBJ_GETPROPERTIES ioctls) for this purpose? TODO: - convert remaining Exynos DRM IPP drivers (FIMC, GScaller) - remove Exynos DRM IPP subsystem - (optional) provide virtual V4L2 mem2mem device on top of Exynos PP framework Patches were tested on Exynos 4412-based Odroid U3 board, on top of Linux next-20170420 kernel. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v1: - moved this feature from DRM core to Exynos DRM driver - changed name from framebuffer processor to picture processor - simplified code to cover only things needed by Exynos drivers - implemented simple fifo task scheduler - cleaned up rotator driver conversion (removed IPP remainings) v0: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html - initial post of "[RFC 0/2] New feature: Framebuffer processors" - generic approach implemented in DRM core, rejected Patch summary: Marek Szyprowski (4): drm: Export functions to create custom DRM objects drm: Add support for vendor specific DRM objects with custom properties drm/exynos: Add Picture Processor framework drm/exynos: Convert Exynos Rotator driver to Picture Processor interface drivers/gpu/drm/drm_crtc_internal.h | 4 - drivers/gpu/drm/drm_mode_object.c | 11 +- drivers/gpu/drm/drm_property.c | 2 +- drivers/gpu/drm/exynos/Kconfig | 1 - drivers/gpu/drm/exynos/Makefile | 3 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 9 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 15 + drivers/gpu/drm/exynos/exynos_drm_pp.c | 775 ++++++++++++++++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_pp.h | 155 ++++++ drivers/gpu/drm/exynos/exynos_drm_rotator.c | 513 +++++------------- drivers/gpu/drm/exynos/exynos_drm_rotator.h | 19 - include/drm/drm_mode_object.h | 6 + include/drm/drm_property.h | 7 + include/uapi/drm/drm_mode.h | 1 + include/uapi/drm/exynos_drm.h | 62 +++ 15 files changed, 1166 insertions(+), 417 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm_pp.c create mode 100644 drivers/gpu/drm/exynos/exynos_drm_pp.h delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html