From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ayan Halder Subject: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer Date: Mon, 9 Sep 2019 13:42:53 +0000 Message-ID: <20190909134241.23297-1-ayan.halder@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Ayan Halder , Liviu Dudau , Brian Starkey , "maarten.lankhorst@linux.intel.com" , "maxime.ripard@bootlin.com" , "sean@poorly.run" , "airlied@linux.ie" , "daniel@ffwll.ch" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" Cc: nd List-Id: dri-devel@lists.freedesktop.org Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the frameb= uffer is allocated in a protected system memory. Essentially, we want to support EGL_EXT_protected_content in our komeda dri= ver. Signed-off-by: Ayan Kumar Halder /-- Note to reviewer Komeda driver is capable of rendering DRM (Digital Rights Management) prote= cted content. The DRM content is stored in a framebuffer allocated in system mem= ory (which needs some special hardware signals for access). Let us ignore how the protected system memory is allocated and for the scop= e of this discussion, we want to figure out the best way possible for the usersp= ace to communicate to the drm driver to turn the protected mode on (for accessi= ng the framebuffer with the DRM content) or off. The possible ways by which the userspace could achieve this is via:- 1. Modifiers :- This looks to me the best way by which the userspace can communicate to the kernel to turn the protected mode on for the komeda driv= er as it is going to access one of the protected framebuffers. The only proble= m is that the current modifiers describe the tiling/compression format. However,= it does not hurt to extend the meaning of modifiers to denote other attributes= of the framebuffer as well. The other reason is that on Android, we get an info from Gralloc (GRALLOC_USAGE_PROTECTED) which tells us that the buffer is protected. This= can be used to set up the modifier/s (AddFB2) during framebuffer creation. 2. Framebuffer flags :- As of today, this can be one of the two values ie (DRM_MODE_FB_INTERLACED/DRM_MODE_FB_MODIFIERS). Unlike modifiers, the dr= m framebuffer flags are generic to the drm subsystem and ideally we should no= t introduce any driver specific constraint/feature. 3. Connector property:- I could see the following properties used for DRM protected content:- DRM_MODE_CONTENT_PROTECTION_DESIRED / ENABLED :- "This property is used by userspace to request the kernel protect future content communicated over the link". Clearly, we are not concerned with the protection attributes of = the transmitter. So, we cannot use this property for our case. 4. DRM plane property:- Again, we want to communicate that the framebuffer(= which can be attached to any plane) is protected. So introducing a new plane prop= erty does not help. 5. DRM crtc property:- For the same reason as above, introducing a new crtc property does not help. --/ --- include/uapi/drm/drm_fourcc.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 3feeaa3f987a..38e5e81d11fe 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -742,6 +742,15 @@ extern "C" { */ #define AFBC_FORMAT_MOD_BCH (1ULL << 11) =20 +/* + * Protected framebuffer + * + * The framebuffer is allocated in a protected system memory which can be = accessed + * via some special hardware signals from the dpu. This is used to support + * 'GRALLOC_USAGE_PROTECTED' in our framebuffer for EGL_EXT_protected_cont= ent. + */ +#define DRM_FORMAT_MOD_ARM_PROTECTED fourcc_mod_code(ARM, (1ULL << 55)) + /* * Allwinner tiled modifier * --=20 2.23.0