linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
@ 2019-09-09 13:42 Ayan Halder
  2019-09-17 12:53 ` Daniel Vetter
  0 siblings, 1 reply; 16+ messages in thread
From: Ayan Halder @ 2019-09-09 13:42 UTC (permalink / raw)
  To: Ayan Halder, Liviu Dudau, Brian Starkey, maarten.lankhorst,
	maxime.ripard, sean, airlied, daniel, dri-devel, linux-kernel
  Cc: nd

Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the framebuffer
is allocated in a protected system memory.
Essentially, we want to support EGL_EXT_protected_content in our komeda driver.

Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>

/-- Note to reviewer
Komeda driver is capable of rendering DRM (Digital Rights Management) protected
content. The DRM content is stored in a framebuffer allocated in system memory
(which needs some special hardware signals for access).

Let us ignore how the protected system memory is allocated and for the scope of
this discussion, we want to figure out the best way possible for the userspace
to communicate to the drm driver to turn the protected mode on (for accessing 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 driver
as it is going to access one of the protected framebuffers. The only problem 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 drm
framebuffer flags are generic to the drm subsystem and ideally we should not
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 property
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)
 
+/*
+ * 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_content.
+ */
+#define DRM_FORMAT_MOD_ARM_PROTECTED	fourcc_mod_code(ARM, (1ULL << 55))
+
 /*
  * Allwinner tiled modifier
  *
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2019-10-01 15:30 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-09 13:42 [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer Ayan Halder
2019-09-17 12:53 ` Daniel Vetter
2019-09-17 16:07   ` Liviu Dudau
2019-09-17 16:15     ` Neil Armstrong
2019-09-17 17:36       ` Daniel Vetter
2019-09-30  9:51         ` Brian Starkey
2019-09-30 12:57           ` Ayan Halder
2019-10-01 15:30             ` Alex Deucher
2019-09-18  8:49   ` Daniel Stone
2019-09-18 12:04     ` Liviu Dudau
2019-09-18 21:30       ` Daniel Stone
2019-09-19 14:03         ` Ayan Halder
2019-09-19 14:10           ` Daniel Vetter
2019-09-19 15:13             ` Ayan Halder
2019-09-20 14:05               ` Daniel Vetter
2019-09-19 15:52       ` Alex Deucher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).