> -----Original Message----- > From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > Sent: Wednesday, July 31, 2024 2:51 PM > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx> > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane capability and > interoperability > > On Wed, 31 Jul 2024 at 11:48, Murthy, Arun R <arun.r.murthy@xxxxxxxxx> > wrote: > > > > > -----Original Message----- > > > From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > > Sent: Wednesday, July 31, 2024 2:04 PM > > > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx> > > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane capability > > > and interoperability > > > > > > On Tue, 30 Jul 2024 at 07:07, Murthy, Arun R > > > <arun.r.murthy@xxxxxxxxx> > > > wrote: > > > > > > > > > -----Original Message----- > > > > > From: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > > > > Sent: Tuesday, July 30, 2024 4:21 AM > > > > > To: Murthy, Arun R <arun.r.murthy@xxxxxxxxx> > > > > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; > > > > > intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > > > Subject: Re: [PATCH] RFC: drm/drm_plane: Expose the plane > > > > > capability and interoperability > > > > > > Please fix your email client. > > > > > Sorry for that. Sure will fix it. > > > > > > > > > > > > On Mon, Jul 29, 2024 at 04:59:14AM GMT, Murthy, Arun R wrote: > > > > > > Gentle Reminder! > > > > > > Any comments? > > > > > > > > > > First of all, the format is underdocumented. Second, there is a > > > > > usual requirement for new uAPI: please provide a pointer to IGT > > > > > patch and to the userspace utilising the property. > > > > There are some discussions on using this in UMD. > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29618#no > > > > te_2 > > > > 487123 > > > > > > It should be a MR rather than "some discussion". And IGT patchset too, > please. > > There is no IGT patch yet. > > > > > > Regarding the patch itself. It is completely underdocumented. There > > > is no way for me to understand which of these caps should e.g. be > > > set for the drm/msm planes. > > > > I have explained it in the patch header. There are certain plane restrictions. > > For example, certain pixel formats are not supported in async flip. If this is > known to the compositor ahead, then compositor sending a flip with this > unsupported formats leads to a flip failure. In order to overcome this if the KMD > sends the list of supported pixel formats, compositor can verify for the same > and then send the flip request. > > This can be achieved in two options. The options are listed below in the patch > header and expected some review comments or suggestion as to which option > to use! > > It is impossible to understand what your options / capabilities _actually_ mean. > I browsed through the patch and I still don't understand how to select which > options apply to DRM_FORMAT_MOD_QCOM_* > Sorry for that let me put it more simple words. Agenda: KMD should share the plane restrictions i.e capability in terms of what is supported and what is not to the UMD. We can see two options of achieving this Option 1: drm_mode_getplane() -> This function exposes the plane metadata such as formats. But these are generic formats supported by the plane. There can be few restrictions like some formats not supported by async flip, certain formats not supported in 270/90 deg rotation and so on. These are the hardware limitations and in order to expose these, this function can be reused. A new pointer is added to the existing drm_mode_get_plane struct to share this. --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -312,6 +312,20 @@ struct drm_mode_set_plane { __u32 src_w; }; +#define DRM_FORMAT_PLANE_CAP_LINEAR_TILE BIT(0) +#define DRM_FORMAT_PLANE_CAP_X_TILE BIT(1) +#define DRM_FORMAT_PLANE_CAP_Y_TILE BIT(2) +#define DRM_FORMAT_PLANE_CAP_Yf_TILE BIT(3) +#define DRM_FORMAT_PLANE_CAP_ASYNC_FLIP BIT(4) +#define DRM_FORMAT_PLANE_CAP_FBC BIT(5) +#define DRM_FORMAT_PLANE_CAP_RC BIT(6) + +struct drm_format_blob { + __u64 modifier; + __u32 plane_caps; + +}; + /** * struct drm_mode_get_plane - Get plane metadata. * @@ -355,6 +369,12 @@ struct drm_mode_get_plane { * supported by the plane. These formats do not require modifiers. */ __u64 format_type_ptr; + /** + * @ format_blob_ptr: Pointer to the array of struct drm_format_blob. + * Specify the plane capabilites/restrictions w.r.t tiling/sync-async + * flips etc + */ + __u64 format_blob_ptr; }; Option 2: Exposing this restriction/capabilities as a plane property. The struct drm_format_blob defined in Option 1 will be used over here as well. --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -631,6 +631,9 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->hotspot_x; } else if (property == plane->hotspot_y_property) { *val = state->hotspot_y; + } else if (property == config->prop_plane_caps) { + *val = (state->plane_caps) ? + state->plane_caps->base.id : 0; } else { drm_dbg_atomic(dev, "[PLANE:%d:%s] unknown property [PROP:%d:%s]\n", diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index dd718c62ac31..dfe931677d0a 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -260,6 +260,14 @@ struct drm_plane_state { * flow. */ bool color_mgmt_changed : 1; + + /** + * @plane_caps: + * + * Blob representing plane capcabilites and interoperability. + * This element is a pointer to the array of struct drm_format_blob. + */ + struct drm_property_blob *plane_caps; }; Thanks and Regards, Arun R Murthy --------------------
