All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hsia-Jun Li <randy.li@synaptics.com>
To: dri-devel@lists.freedesktop.org
Cc: ayaka@soulik.info, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
	daniel@ffwll.ch, linux-kernel@vger.kernel.org,
	tfiga@chromium.org, nicolas@ndufresne.ca,
	"Hsia-Jun(Randy) Li" <randy.li@synaptics.com>
Subject: [PATCH] RFC: drm: Create a alloc helper flags blob
Date: Wed, 22 Mar 2023 18:52:26 +0800	[thread overview]
Message-ID: <20230322105226.122467-1-randy.li@synaptics.com> (raw)

From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>

In Android, we could also call gralloc to allocate a
graphics buffer for the decoder, display or encoder.
In the GNU Linux, we don't have such framework, the only
thing we could have is the GBM.
Unfortunately, some platforms don't have a GPU may not
ship the gbm library or the GBM is a part of proprietary
GPU driver. They may not know the allocation requirement
for the other display device.

So it would be better to offer an generic interfaces
for the application allocating the buffer from the 3rd place,
likes DMA-heap or DRM dumb.

The storage of this blob would is different to the modifier
blob, userspace would likes the format key and modifiers
data relation. It would be better to let application seek
the allocation flags they want.

Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
---
 include/uapi/drm/drm_mode.h | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..ee5b4d5aee0a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -218,6 +218,11 @@ extern "C" {
 #define DRM_MODE_CONTENT_PROTECTION_DESIRED     1
 #define DRM_MODE_CONTENT_PROTECTION_ENABLED     2
 
+/* DRM buffer allocation flags */
+#define DRM_BUF_ALLOC_FLAG_DUMB_IMPORT		(1UL << 63)
+#define DRM_BUF_ALLOC_FLAG_SEPARATE_PLANE	(1UL << 62)
+/* bits 0~31 were reserved for DMA-heap heap_flags */
+
 /**
  * struct drm_mode_modeinfo - Display mode information.
  * @clock: pixel clock in kHz
@@ -1168,6 +1173,37 @@ struct drm_format_modifier {
 	__u64 modifier;
 };
 
+struct drm_buf_alloc_flags_blob {
+#define FORMAT_BLOB_CURRENT 1
+	/* Version of this blob format */
+	__u32 version;
+
+	/* Flags */
+	__u32 flags;
+
+	/* Number of fourcc formats supported */
+	__u32 count_formats;
+
+	/* Where in this blob the formats exist (in bytes) */
+	__u32 formats_offset;
+
+	/* Number of drm_buf_alloc_flags */
+	__u32 count_alloc_flags;
+
+	/* Where in this blob the modifiers exist (in bytes) */
+	__u32 alloc_flags_offset;
+
+	/* __u32 formats[] */
+	/* struct drm_buf_alloc_flags alloc_flags[] */
+};
+
+struct drm_buf_alloc_flags {
+	__u32 format;
+	__u32 pad;
+	__u64 modifier_mask;
+	__u64 flags;
+};
+
 /**
  * struct drm_mode_create_blob - Create New blob property
  *
-- 
2.17.1


WARNING: multiple messages have this Message-ID (diff)
From: Hsia-Jun Li <randy.li@synaptics.com>
To: dri-devel@lists.freedesktop.org
Cc: tzimmermann@suse.de, ayaka@soulik.info,
	linux-kernel@vger.kernel.org, tfiga@chromium.org,
	"Hsia-Jun\(Randy\) Li" <randy.li@synaptics.com>,
	nicolas@ndufresne.ca
Subject: [PATCH] RFC: drm: Create a alloc helper flags blob
Date: Wed, 22 Mar 2023 18:52:26 +0800	[thread overview]
Message-ID: <20230322105226.122467-1-randy.li@synaptics.com> (raw)

From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>

In Android, we could also call gralloc to allocate a
graphics buffer for the decoder, display or encoder.
In the GNU Linux, we don't have such framework, the only
thing we could have is the GBM.
Unfortunately, some platforms don't have a GPU may not
ship the gbm library or the GBM is a part of proprietary
GPU driver. They may not know the allocation requirement
for the other display device.

So it would be better to offer an generic interfaces
for the application allocating the buffer from the 3rd place,
likes DMA-heap or DRM dumb.

The storage of this blob would is different to the modifier
blob, userspace would likes the format key and modifiers
data relation. It would be better to let application seek
the allocation flags they want.

Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
---
 include/uapi/drm/drm_mode.h | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..ee5b4d5aee0a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -218,6 +218,11 @@ extern "C" {
 #define DRM_MODE_CONTENT_PROTECTION_DESIRED     1
 #define DRM_MODE_CONTENT_PROTECTION_ENABLED     2
 
+/* DRM buffer allocation flags */
+#define DRM_BUF_ALLOC_FLAG_DUMB_IMPORT		(1UL << 63)
+#define DRM_BUF_ALLOC_FLAG_SEPARATE_PLANE	(1UL << 62)
+/* bits 0~31 were reserved for DMA-heap heap_flags */
+
 /**
  * struct drm_mode_modeinfo - Display mode information.
  * @clock: pixel clock in kHz
@@ -1168,6 +1173,37 @@ struct drm_format_modifier {
 	__u64 modifier;
 };
 
+struct drm_buf_alloc_flags_blob {
+#define FORMAT_BLOB_CURRENT 1
+	/* Version of this blob format */
+	__u32 version;
+
+	/* Flags */
+	__u32 flags;
+
+	/* Number of fourcc formats supported */
+	__u32 count_formats;
+
+	/* Where in this blob the formats exist (in bytes) */
+	__u32 formats_offset;
+
+	/* Number of drm_buf_alloc_flags */
+	__u32 count_alloc_flags;
+
+	/* Where in this blob the modifiers exist (in bytes) */
+	__u32 alloc_flags_offset;
+
+	/* __u32 formats[] */
+	/* struct drm_buf_alloc_flags alloc_flags[] */
+};
+
+struct drm_buf_alloc_flags {
+	__u32 format;
+	__u32 pad;
+	__u64 modifier_mask;
+	__u64 flags;
+};
+
 /**
  * struct drm_mode_create_blob - Create New blob property
  *
-- 
2.17.1


             reply	other threads:[~2023-03-22 10:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 10:52 Hsia-Jun Li [this message]
2023-03-22 10:52 ` [PATCH] RFC: drm: Create a alloc helper flags blob Hsia-Jun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230322105226.122467-1-randy.li@synaptics.com \
    --to=randy.li@synaptics.com \
    --cc=airlied@gmail.com \
    --cc=ayaka@soulik.info \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=tfiga@chromium.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.