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
next 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: linkBe 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.