From patchwork Mon May 8 09:11:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 98816 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp1230508qge; Mon, 8 May 2017 02:12:12 -0700 (PDT) X-Received: by 10.98.141.16 with SMTP id z16mr31496757pfd.91.1494234732265; Mon, 08 May 2017 02:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1494234732; cv=none; d=google.com; s=arc-20160816; b=DJvZaCGQKP/k1ABsLHTHISF/pejefBY03378tWJN5gBpuZo5rYNsa/jUUaTPMZNjhD HJG5CxUXSufkYq0K8AIz33cwNfVYCx46YLJrW03nCrs0Re374LrxjT2Cd5+a46gKqlwL DGwSFLyziEIsAUjiBXmhdfmwXopqjUxgS5meK2QuVLtaRRA5FA7dOfBJ4I1rFmpEVwYI UoiRdlklM8alXtLKdJvZU6Dc5lzY/X9zr+EIFvGvlTDtA63mP3ZB2S1liCk2teA3A3hP vEOV6kmTBeMSZ00GEmQWvC+MdjKTwoC2ATkmOq+RFnZ427vSNKVkhxFUYRy64jpmZRud LD9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:cms-type:message-id:date :subject:cc:to:from:arc-authentication-results; bh=DbQiV/Y1ukWLc3Cu5toKuL4QUTU6Iec/CbKgzDCOXSY=; b=xMENqROchBd5+D8/y2ZaY0hUOcBo+z2pyMd/PnG7MCDS4Om8pePRWJZmRT7w7lmq8a TP0ZbkHarDEkIU+XF+FinRqeTOMn9APIsO7uVdkfKzn29uLnBEcY+7JDMxpZJ0Z+GITd u3bBaYDzGFvaLRkY/w7aJ3gPqtYQecqWYXMAGj8ozDM3TlPoyviPTGb0o2JaW5UxVYl9 mGgFsgo5kOWepfB5tFztcjaw372xEoGcP7XhA8U4wssf+nN1ykOvvNNsNV3KPtuY3AVj BIhd7+4TicZW5xg7kq87keNTgryUiNqYrwD1Kgs62kitEq5XPU+UoKgHe+aBTFg342Ee 5KVQ== ARC-Authentication-Results: i=1; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s16si13074540plk.213.2017.05.08.02.12.12; Mon, 08 May 2017 02:12:12 -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 S1753857AbdEHJML (ORCPT + 4 others); Mon, 8 May 2017 05:12:11 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:33660 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753712AbdEHJMK (ORCPT ); Mon, 8 May 2017 05:12:10 -0400 Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OPM002O9MW7GF70@mailout2.w1.samsung.com> for linux-samsung-soc@vger.kernel.org; Mon, 08 May 2017 10:12:07 +0100 (BST) Received: from eusmges2.samsung.com (unknown [203.254.199.241]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170508091206eucas1p172e5e8d1c9f80417eadefd2190d82a22~8lpEinkfy2093620936eucas1p1c; Mon, 8 May 2017 09:12:06 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2.samsung.com (EUCPMTA) with SMTP id 3E.E0.04459.66630195; Mon, 8 May 2017 10:12:06 +0100 (BST) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20170508091205eucas1p277086174c1d02695555200fab0e20211~8lpD8DlnB0544205442eucas1p2P; Mon, 8 May 2017 09:12:05 +0000 (GMT) X-AuditID: cbfec7f1-f796e6d00000116b-cc-591036661e20 Received: from eusync3.samsung.com ( [203.254.199.213]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id E2.14.20206.48630195; Mon, 8 May 2017 10:12:36 +0100 (BST) Received: from AMDC2765.digital.local ([106.116.147.25]) by eusync3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OPM00BIGMVPHD40@eusync3.samsung.com>; Mon, 08 May 2017 10:12:05 +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 , Dave Airlie , Laurent Pinchart , Sakari Ailus Subject: [RFC v2 0/2] Exynos DRM: add Picture Processor extension Date: Mon, 08 May 2017 11:11:37 +0200 Message-id: <1494234699-23843-1-git-send-email-m.szyprowski@samsung.com> X-Mailer: git-send-email 1.9.1 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsWy7djP87ppZgKRBl2/eCxurTvHanHi+iIm i40z1rNa/N82kdniytf3bBaT7k9gseicuITdYsb5fUwWa4/cZbd4vvAHs8WZ/SvZLGZMfslm 0bb6A6sDr8febwtYPHbOusvuMbtjJqvH4a8LWTzudx9n8vh3jN2jb8sqRo/Pm+QCOKK4bFJS czLLUov07RK4MqZeqy/Yqlmx68lZ1gbGT4pdjJwcEgImEtuXvGGEsMUkLtxbz9bFyMUhJLCU UeLky/WsEM5nRokVuy4wwnQc//wFqmoZo8S5C2dZQRJCAg1MEl//8oLYbAKGEl1vu9hAbBEB N4mmwzPBJjELnGaW2H7/IzNIQljAUWL1klagBDsHi4CqRGscSJRXwENi5cVWNohdchInj00G a5UQmMwusbRxM5DDAeTISmw6wAxR4yIxcedjqHphiVfHt7BD2DISlyd3s0DY/YwSTa3aEPYM oJvf8kLY1hKHj18EO59ZgE9i0rbpzBDjeSU62oQgSjwkHv7/DLXKUeLq2k0sEN/GSnR9Occ0 gVF6ASPDKkaR1NLi3PTUYiO94sTc4tK8dL3k/NxNjMDIP/3v+McdjO9PWB1iFOBgVOLh3VHK HynEmlhWXJl7iFGCg1lJhPe1oUCkEG9KYmVValF+fFFpTmrxIUZpDhYlcV6uU9cihATSE0tS s1NTC1KLYLJMHJxSDYzH5sYrZe7ON1Q/U39BnHdm6vTq+N5Z/Ll5ky+3FqjfOjjRuDy58kHI +jfLQ6ILEoMPxxUuWSi44sxjY0e9frcw98d745r6Jz7tPLZP/rTPqvucG5elnWOIao6fvk9j zfo41xndQk2n49drhwTw62lsfqU8bdPDHq5ioZwlmjWqV2LnOQt0SimxFGckGmoxFxUnAgCR zJ4a+AIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsVy+t/xq7otZgKRBp3vRCxurTvHanHi+iIm i40z1rNa/N82kdniytf3bBaT7k9gseicuITdYsb5fUwWa4/cZbd4vvAHs8WZ/SvZLGZMfslm 0bb6A6sDr8febwtYPHbOusvuMbtjJqvH4a8LWTzudx9n8vh3jN2jb8sqRo/Pm+QCOKLcbDJS E1NSixRS85LzUzLz0m2VQkPcdC2UFPISc1NtlSJ0fUOClBTKEnNKgTwjAzTg4BzgHqykb5fg ljH1Wn3BVs2KXU/OsjYwflLsYuTkkBAwkTj++QsbhC0mceHeeiCbi0NIYAmjxI6Xv5ggnCYm iZW/v7OAVLEJGEp0ve0C6xARcJNoOjyTFaSIWeA8s8SdxoNgRcICjhKrl7QCJdg5WARUJVrj QKK8Ah4SKy+2Qi2Tkzh5bDLrBEbuBYwMqxhFUkuLc9Nzi430ihNzi0vz0vWS83M3MQIDftux n1t2MHa9Cz7EKMDBqMTDu6OUP1KINbGsuDL3EKMEB7OSCO9rQ4FIId6UxMqq1KL8+KLSnNTi Q4ymQKsnMkuJJucDozGvJN7QxNDc0tDI2MLC3MhISZx36ocr4UIC6YklqdmpqQWpRTB9TByc Ug2MV9t2Hl7DK/Jg/muvWkdhZ7vpBa97vp56wSfec+rgu3V3PnueP1F+NjfwwtQlvzf95dz+ Q8vt6C+dc8VTrkgJdXGuKmJXPMP57++ppreuz0/amposvbe4bNqUS7HSu9cWiui8a2JeJpGR zH+4dsuVxgPTe6Nsve3ja9zCz80+HckrqbPNRbi9S4mlOCPRUIu5qDgRANt4Cj+OAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170508091205eucas1p277086174c1d02695555200fab0e20211 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 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: 20170508091205eucas1p277086174c1d02695555200fab0e20211 X-RootMTR: 20170508091205eucas1p277086174c1d02695555200fab0e20211 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 ispired a bit by atomic KMS approach. Each picture processor has a number of parameters, which describe operation to be performed by respective hardware module. The list is open and can be extended in the future. In typical case those parameters are a source fb id and rectangle (x, y, width, height) and destination fb id and rectangle as well as a rotation property. Parameters are provided by their predefined IDs. To perform an operation on image data, userspace provides a set of parameters and their values for given picture processor. 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 userspace API is extensible. Drivers can add their own, custom parameters 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 646 lines) and allows driver simplification (Exynos rotator driver smaller by over 200 lines). Open questions: - How to expose supported pixel formats/modifiers? Currently this is done by the arrays of supported fourcc codes in the drm_exynos_pp_get structure and DRM_IOCTL_EXYNOS_PP_GET ioctl. I would like to switch to a structure similar to recently discussed format/modifier blob to avoid reinventing wheel: https://www.spinics.net/lists/intel-gfx/msg127094.html - How to expose the range of the supported parameters (min/max width, rotation values)? Is it really needed? 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 v4.11 kernel. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v2: - removed usage of DRM objects and properties - replaced them with simple list of parameters with predefined IDs 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 (2): drm/exynos: Add Picture Processor framework drm/exynos: Convert Exynos Rotator driver to Picture Processor interface 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 | 4 + drivers/gpu/drm/exynos/exynos_drm_pp.c | 645 ++++++++++++++++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_pp.h | 153 +++++++ drivers/gpu/drm/exynos/exynos_drm_rotator.c | 493 +++++---------------- drivers/gpu/drm/exynos/exynos_drm_rotator.h | 19 - include/uapi/drm/exynos_drm.h | 76 ++++ 9 files changed, 1006 insertions(+), 397 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