* [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 6:38 ` Kandpal, Suraj
2025-02-17 10:08 ` Pekka Paalanen
2025-01-28 15:51 ` [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT " Arun R Murthy
` (15 subsequent siblings)
16 siblings, 2 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Display Histogram is an array of bins and can be generated in many ways
referred to as modes.
Ex: HSV max(RGB), Wighted RGB etc.
Understanding the histogram data format(Ex: HSV max(RGB))
Histogram is just the pixel count.
For a maximum resolution of 10k (10240 x 4320 = 44236800)
25 bits should be sufficient to represent this along with a buffer of 7
bits(future use) u32 is being considered.
max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
bits, hence 32 bins.
Below mentioned algorithm illustrates the histogram generation in
hardware.
hist[32] = {0};
for (i = 0; i < resolution; i++) {
bin = max(RGB[i]);
bin = bin >> 3; /* consider the most significant bits */
hist[bin]++;
}
If the entire image is Red color then max(255,0,0) is 255 so the pixel
count of each pixels will be placed in the last bin. Hence except
hist[31] all other bins will have a value zero.
Generated histogram in this case would be hist[32] = {0,0,....44236800}
Description of the structures, properties defined are documented in the
header file include/uapi/drm/drm_mode.h
v8: Added doc for HDR planes, removed reserved variables (Dmitry)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
__u32 pad;
};
+/**
+ * enum drm_mode_histogram
+ *
+ * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
+ * Maximum resolution at present 10k, 10240x4320 = 44236800
+ * can be denoted in 25bits. With an additional 7 bits in buffer each bin
+ * can be a u32 value.
+ * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
+ * If the most significant 5 bits are considered, then bins = 2^5
+ * will be 32 bins.
+ * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
+ * For illustration consider a full RED image of 10k resolution considering all
+ * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
+ * plane similarly with HDR the same would look like hist[65535] =
+ * {0,0,0,....44236800}
+ */
+enum drm_mode_histogram {
+ DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
+};
+
+/**
+ * struct drm_histogram_caps
+ *
+ * @histogram_mode: histogram generation modes, defined in the
+ * enum drm_mode_histogram
+ * @bins_count: number of bins for a chosen histogram mode. For illustration
+ * refer the above defined histogram mode.
+ */
+struct drm_histogram_caps {
+ __u32 histogram_mode;
+ __u32 bins_count;
+};
+
+/**
+ * struct drm_histogram_config
+ *
+ * @hist_mode_data: address to the histogram mode specific data if any
+ * @nr_hist_mode_data: number of elements pointed by the address in
+ * hist_mode_data
+ * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
+ * @enable: flag to enable/disable histogram
+ */
+struct drm_histogram_config {
+ __u64 hist_mode_data;
+ __u32 nr_hist_mode_data;
+ enum drm_mode_histogram hist_mode;
+ bool enable;
+};
+
+/**
+ * struct drm_histogram
+ *
+ * @config: histogram configuration data pointed by struct drm_histogram_config
+ * @data_ptr: pointer to the array of histogram.
+ * Histogram is an array of bins. Data format for each bin depends
+ * on the histogram mode. Refer to the above histogram modes for
+ * more information.
+ * @nr_elements: number of bins in the histogram.
+ */
+struct drm_histogram {
+ struct drm_histogram_config config;
+ __u64 data_ptr;
+ __u32 nr_elements;
+};
+
#if defined(__cplusplus)
}
#endif
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-01-28 15:51 ` [PATCH v8 01/14] drm: Define histogram structures exposed to user Arun R Murthy
@ 2025-02-14 6:38 ` Kandpal, Suraj
2025-02-14 8:38 ` Kandpal, Suraj
2025-03-13 6:10 ` Murthy, Arun R
2025-02-17 10:08 ` Pekka Paalanen
1 sibling, 2 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 6:38 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 01/14] drm: Define histogram structures exposed to user
>
> Display Histogram is an array of bins and can be generated in many ways
> referred to as modes.
> Ex: HSV max(RGB), Wighted RGB etc.
>
> Understanding the histogram data format(Ex: HSV max(RGB)) Histogram is just
> the pixel count.
> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> 25 bits should be sufficient to represent this along with a buffer of 7 bits(future
> use) u32 is being considered.
> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5 bits,
> hence 32 bins.
> Below mentioned algorithm illustrates the histogram generation in hardware.
>
> hist[32] = {0};
> for (i = 0; i < resolution; i++) {
> bin = max(RGB[i]);
> bin = bin >> 3; /* consider the most significant bits */
> hist[bin]++;
> }
> If the entire image is Red color then max(255,0,0) is 255 so the pixel count of
> each pixels will be placed in the last bin. Hence except hist[31] all other bins
> will have a value zero.
> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>
> Description of the structures, properties defined are documented in the header
> file include/uapi/drm/drm_mode.h
>
> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> include/uapi/drm/drm_mode.h | 65
> +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index
> c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b
> 20ac6cbf5df69e9 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> __u32 pad;
> };
>
> +/**
> + * enum drm_mode_histogram
> + *
> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> + * Maximum resolution at present 10k, 10240x4320 = 44236800
> + * can be denoted in 25bits. With an additional 7 bits in buffer each
> +bin
> + * can be a u32 value.
> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
Type: SDR
> + * If the most significant 5 bits are considered, then bins = 2^5
> + * will be 32 bins.
> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> + * For illustration consider a full RED image of 10k resolution
> +considering all
> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with
> +SDR
> + * plane similarly with HDR the same would look like hist[65535] =
> + * {0,0,0,....44236800}
> + */
> +enum drm_mode_histogram {
> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01, };
> +
> +/**
> + * struct drm_histogram_caps
> + *
> + * @histogram_mode: histogram generation modes, defined in the
> + * enum drm_mode_histogram
> + * @bins_count: number of bins for a chosen histogram mode. For illustration
> + * refer the above defined histogram mode.
> + */
> +struct drm_histogram_caps {
> + __u32 histogram_mode;
Do we really need __u32 for histogram mode don't you think a __u16 should suffice?
> + __u32 bins_count;
Nit: bin_count sounds better.
> +};
> +
> +/**
> + * struct drm_histogram_config
> + *
> + * @hist_mode_data: address to the histogram mode specific data if any
> + * @nr_hist_mode_data: number of elements pointed by the address in
> + * hist_mode_data
> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> + * @enable: flag to enable/disable histogram */ struct
> +drm_histogram_config {
> + __u64 hist_mode_data;
> + __u32 nr_hist_mode_data;
> + enum drm_mode_histogram hist_mode;
> + bool enable;
> +};
> +
> +/**
> + * struct drm_histogram
> + *
> + * @config: histogram configuration data pointed by struct
> +drm_histogram_config
> + * @data_ptr: pointer to the array of histogram.
> + * Histogram is an array of bins. Data format for each bin depends
> + * on the histogram mode. Refer to the above histogram modes for
I think you can write the drm_histogram_mode_caps instead of writing histogram mode
So people can directly jump to it
Regards,
Suraj Kandpal
> + * more information.
> + * @nr_elements: number of bins in the histogram.
> + */
> +struct drm_histogram {
> + struct drm_histogram_config config;
> + __u64 data_ptr;
> + __u32 nr_elements;
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-14 6:38 ` Kandpal, Suraj
@ 2025-02-14 8:38 ` Kandpal, Suraj
2025-03-13 6:10 ` Murthy, Arun R
1 sibling, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 8:38 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Kandpal, Suraj
> Sent: Friday, February 14, 2025 12:09 PM
> To: Murthy, Arun R <arun.r.murthy@intel.com>; intel-xe@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: dmitry.baryshkov@linaro.org
> Subject: RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
>
>
>
> > -----Original Message-----
> > From: Murthy, Arun R <arun.r.murthy@intel.com>
> > Sent: Tuesday, January 28, 2025 9:21 PM
> > To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> > dri- devel@lists.freedesktop.org
> > Cc: Kandpal, Suraj <suraj.kandpal@intel.com>;
> > dmitry.baryshkov@linaro.org; Murthy, Arun R <arun.r.murthy@intel.com>
> > Subject: [PATCH v8 01/14] drm: Define histogram structures exposed to
> > user
> >
> > Display Histogram is an array of bins and can be generated in many
> > ways referred to as modes.
> > Ex: HSV max(RGB), Wighted RGB etc.
One more Typo I forgot to point out *Weighted
Regards,
Suraj Kandpal
> >
> > Understanding the histogram data format(Ex: HSV max(RGB)) Histogram is
> > just the pixel count.
> > For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > 25 bits should be sufficient to represent this along with a buffer of
> > 7 bits(future
> > use) u32 is being considered.
> > max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> > bits, hence 32 bins.
> > Below mentioned algorithm illustrates the histogram generation in hardware.
> >
> > hist[32] = {0};
> > for (i = 0; i < resolution; i++) {
> > bin = max(RGB[i]);
> > bin = bin >> 3; /* consider the most significant bits */
> > hist[bin]++;
> > }
> > If the entire image is Red color then max(255,0,0) is 255 so the pixel
> > count of each pixels will be placed in the last bin. Hence except
> > hist[31] all other bins will have a value zero.
> > Generated histogram in this case would be hist[32] =
> > {0,0,....44236800}
> >
> > Description of the structures, properties defined are documented in
> > the header file include/uapi/drm/drm_mode.h
> >
> > v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >
> > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> > ---
> > include/uapi/drm/drm_mode.h | 65
> > +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 65 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index
> >
> c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b
> > 20ac6cbf5df69e9 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> > __u32 pad;
> > };
> >
> > +/**
> > + * enum drm_mode_histogram
> > + *
> > + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> > + * Maximum resolution at present 10k, 10240x4320 = 44236800
> > + * can be denoted in 25bits. With an additional 7 bits in buffer each
> > +bin
> > + * can be a u32 value.
> > + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>
> Type: SDR
>
> > + * If the most significant 5 bits are considered, then bins = 2^5
> > + * will be 32 bins.
> > + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> > + * For illustration consider a full RED image of 10k resolution
> > +considering all
> > + * 8 bits histogram would look like hist[255] = {0,0,....44236800}
> > +with SDR
> > + * plane similarly with HDR the same would look like hist[65535] =
> > + * {0,0,0,....44236800}
> > + */
> > +enum drm_mode_histogram {
> > + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01, };
> > +
> > +/**
> > + * struct drm_histogram_caps
> > + *
> > + * @histogram_mode: histogram generation modes, defined in the
> > + * enum drm_mode_histogram
> > + * @bins_count: number of bins for a chosen histogram mode. For
> illustration
> > + * refer the above defined histogram mode.
> > + */
> > +struct drm_histogram_caps {
> > + __u32 histogram_mode;
>
> Do we really need __u32 for histogram mode don't you think a __u16 should
> suffice?
>
>
> > + __u32 bins_count;
>
> Nit: bin_count sounds better.
>
> > +};
> > +
> > +/**
> > + * struct drm_histogram_config
> > + *
> > + * @hist_mode_data: address to the histogram mode specific data if
> > +any
> > + * @nr_hist_mode_data: number of elements pointed by the address in
> > + * hist_mode_data
> > + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> > + * @enable: flag to enable/disable histogram */ struct
> > +drm_histogram_config {
> > + __u64 hist_mode_data;
> > + __u32 nr_hist_mode_data;
> > + enum drm_mode_histogram hist_mode;
> > + bool enable;
> > +};
> > +
> > +/**
> > + * struct drm_histogram
> > + *
> > + * @config: histogram configuration data pointed by struct
> > +drm_histogram_config
> > + * @data_ptr: pointer to the array of histogram.
> > + * Histogram is an array of bins. Data format for each bin depends
> > + * on the histogram mode. Refer to the above histogram modes for
>
> I think you can write the drm_histogram_mode_caps instead of writing
> histogram mode So people can directly jump to it
>
> Regards,
> Suraj Kandpal
>
> > + * more information.
> > + * @nr_elements: number of bins in the histogram.
> > + */
> > +struct drm_histogram {
> > + struct drm_histogram_config config;
> > + __u64 data_ptr;
> > + __u32 nr_elements;
> > +};
> > +
> > #if defined(__cplusplus)
> > }
> > #endif
> >
> > --
> > 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-14 6:38 ` Kandpal, Suraj
2025-02-14 8:38 ` Kandpal, Suraj
@ 2025-03-13 6:10 ` Murthy, Arun R
1 sibling, 0 replies; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-13 6:10 UTC (permalink / raw)
To: Kandpal, Suraj, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> > Display Histogram is an array of bins and can be generated in many
> > ways referred to as modes.
> > Ex: HSV max(RGB), Wighted RGB etc.
> >
> > Understanding the histogram data format(Ex: HSV max(RGB)) Histogram is
> > just the pixel count.
> > For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > 25 bits should be sufficient to represent this along with a buffer of
> > 7 bits(future
> > use) u32 is being considered.
> > max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> > bits, hence 32 bins.
> > Below mentioned algorithm illustrates the histogram generation in hardware.
> >
> > hist[32] = {0};
> > for (i = 0; i < resolution; i++) {
> > bin = max(RGB[i]);
> > bin = bin >> 3; /* consider the most significant bits */
> > hist[bin]++;
> > }
> > If the entire image is Red color then max(255,0,0) is 255 so the pixel
> > count of each pixels will be placed in the last bin. Hence except
> > hist[31] all other bins will have a value zero.
> > Generated histogram in this case would be hist[32] =
> > {0,0,....44236800}
> >
> > Description of the structures, properties defined are documented in
> > the header file include/uapi/drm/drm_mode.h
> >
> > v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >
> > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> > ---
> > include/uapi/drm/drm_mode.h | 65
> > +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 65 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index
> >
> c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61
> b
> > 20ac6cbf5df69e9 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> > __u32 pad;
> > };
> >
> > +/**
> > + * enum drm_mode_histogram
> > + *
> > + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> > + * Maximum resolution at present 10k, 10240x4320 = 44236800
> > + * can be denoted in 25bits. With an additional 7 bits in buffer each
> > +bin
> > + * can be a u32 value.
> > + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>
> Type: SDR
>
> > + * If the most significant 5 bits are considered, then bins = 2^5
> > + * will be 32 bins.
> > + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> > + * For illustration consider a full RED image of 10k resolution
> > +considering all
> > + * 8 bits histogram would look like hist[255] = {0,0,....44236800}
> > +with SDR
> > + * plane similarly with HDR the same would look like hist[65535] =
> > + * {0,0,0,....44236800}
> > + */
> > +enum drm_mode_histogram {
> > + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01, };
> > +
> > +/**
> > + * struct drm_histogram_caps
> > + *
> > + * @histogram_mode: histogram generation modes, defined in the
> > + * enum drm_mode_histogram
> > + * @bins_count: number of bins for a chosen histogram mode. For
> illustration
> > + * refer the above defined histogram mode.
> > + */
> > +struct drm_histogram_caps {
> > + __u32 histogram_mode;
>
> Do we really need __u32 for histogram mode don't you think a __u16 should
> suffice?
>
For future compatibility we have it as __u32 but yes __u16 should be fine.
I am fine changing to __u16 if no other comments on this.
>
> > + __u32 bins_count;
>
> Nit: bin_count sounds better.
>
> > +};
> > +
> > +/**
> > + * struct drm_histogram_config
> > + *
> > + * @hist_mode_data: address to the histogram mode specific data if
> > +any
> > + * @nr_hist_mode_data: number of elements pointed by the address in
> > + * hist_mode_data
> > + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> > + * @enable: flag to enable/disable histogram */ struct
> > +drm_histogram_config {
> > + __u64 hist_mode_data;
> > + __u32 nr_hist_mode_data;
> > + enum drm_mode_histogram hist_mode;
> > + bool enable;
> > +};
> > +
> > +/**
> > + * struct drm_histogram
> > + *
> > + * @config: histogram configuration data pointed by struct
> > +drm_histogram_config
> > + * @data_ptr: pointer to the array of histogram.
> > + * Histogram is an array of bins. Data format for each bin depends
> > + * on the histogram mode. Refer to the above histogram modes for
>
> I think you can write the drm_histogram_mode_caps instead of writing
> histogram mode So people can directly jump to it
>
Mode_caps will give all the modes supported by the hardware and this mode_config will choose one among the supported modes hence the name.
Thanks and Regards,
Arun R Murthy
--------------------
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-01-28 15:51 ` [PATCH v8 01/14] drm: Define histogram structures exposed to user Arun R Murthy
2025-02-14 6:38 ` Kandpal, Suraj
@ 2025-02-17 10:08 ` Pekka Paalanen
2025-02-17 12:27 ` Pekka Paalanen
` (2 more replies)
1 sibling, 3 replies; 58+ messages in thread
From: Pekka Paalanen @ 2025-02-17 10:08 UTC (permalink / raw)
To: Arun R Murthy
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 6875 bytes --]
Hi Arun,
this whole series seems to be missing all the UAPI docs for the DRM
ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
replacement for them, I would assume both are a requirement.
Without the ReST docs it is really difficult to see how this new UAPI
should be used.
On Tue, 28 Jan 2025 21:21:07 +0530
Arun R Murthy <arun.r.murthy@intel.com> wrote:
> Display Histogram is an array of bins and can be generated in many ways
> referred to as modes.
> Ex: HSV max(RGB), Wighted RGB etc.
>
> Understanding the histogram data format(Ex: HSV max(RGB))
> Histogram is just the pixel count.
> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> 25 bits should be sufficient to represent this along with a buffer of 7
> bits(future use) u32 is being considered.
> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> bits, hence 32 bins.
> Below mentioned algorithm illustrates the histogram generation in
> hardware.
>
> hist[32] = {0};
> for (i = 0; i < resolution; i++) {
> bin = max(RGB[i]);
> bin = bin >> 3; /* consider the most significant bits */
> hist[bin]++;
> }
> If the entire image is Red color then max(255,0,0) is 255 so the pixel
> count of each pixels will be placed in the last bin. Hence except
> hist[31] all other bins will have a value zero.
> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>
> Description of the structures, properties defined are documented in the
> header file include/uapi/drm/drm_mode.h
>
> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> __u32 pad;
> };
>
> +/**
> + * enum drm_mode_histogram
> + *
> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> + * Maximum resolution at present 10k, 10240x4320 = 44236800
> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
> + * can be a u32 value.
> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
I assume s/SDL/SDR/.
This assumption seems false. SDR can be also 10-bit and probably even
more.
> + * If the most significant 5 bits are considered, then bins = 2^5
> + * will be 32 bins.
> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
Does this mean that the histogram is computed on the pixel values
emitted to the cable? What if the cable format is YUV?
> + * For illustration consider a full RED image of 10k resolution considering all
> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
> + * plane similarly with HDR the same would look like hist[65535] =
> + * {0,0,0,....44236800}
This SDR vs. HDR is a false dichotomy. I presume the meaningful
difference is bits-per-channel, not the dynamic range.
It would be good to have the pseudocode snippet here instead of the
commit message. The commit message should not contain any UAPI notes
that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
message is probably not very useful, as the more interesting questions
are why this exists and what it can be used for.
> + */
> +enum drm_mode_histogram {
> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
What does the HSV stand for?
When talking about pixel values, my first impression is
hue-saturation-value. But there are no hue-saturation-value
computations at all?
> +};
> +
> +/**
> + * struct drm_histogram_caps
> + *
> + * @histogram_mode: histogram generation modes, defined in the
> + * enum drm_mode_histogram
> + * @bins_count: number of bins for a chosen histogram mode. For illustration
> + * refer the above defined histogram mode.
> + */
> +struct drm_histogram_caps {
> + __u32 histogram_mode;
> + __u32 bins_count;
> +};
Patch 3 says:
+ * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
+ * Description of the structure is in include/uapi/drm/drm_mode.h
This is a read-only property, right?
The blob contains one struct drm_histogram_caps. What if more than one
mode is supported?
If the bin count depends on the bits-per-channel of something which
depends on set video mode or other things, how does updating work?
What if userspace uses a stale count? How does userspace ensure it uses
the current count?
> +
> +/**
> + * struct drm_histogram_config
> + *
> + * @hist_mode_data: address to the histogram mode specific data if any
Do I understand correctly that the KMS blob will contain a userspace
virtual memory address (a user pointer)? How does that work? What are
the lifetime requirements for that memory?
I do not remember any precedent of this, and I suspect it's not a good
design. I believe all the data should be contained in the blobs, e.g.
how IN_FORMATS does it. I'm not sure what would be the best UAPI here
for returning histogram data to userspace, but at least all the data
sent to the kernel should be contained in the blob itself since it
seems to be quite small. Variable length is ok for blobs.
> + * @nr_hist_mode_data: number of elements pointed by the address in
> + * hist_mode_data
> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> + * @enable: flag to enable/disable histogram
> + */
> +struct drm_histogram_config {
> + __u64 hist_mode_data;
> + __u32 nr_hist_mode_data;
> + enum drm_mode_histogram hist_mode;
> + bool enable;
Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
if architecture, build options, or the contents of the enum change the
ABI.
> +};
> +
> +/**
> + * struct drm_histogram
> + *
> + * @config: histogram configuration data pointed by struct drm_histogram_config
s/pointed by/defined by/ I presume? That much is obvious from the field
type. What does it mean? Why is struct drm_histogram_config a separate
struct?
> + * @data_ptr: pointer to the array of histogram.
> + * Histogram is an array of bins. Data format for each bin depends
> + * on the histogram mode. Refer to the above histogram modes for
> + * more information.
Another userspace virtual address stored in a KMS blob?
> + * @nr_elements: number of bins in the histogram.
> + */
> +struct drm_histogram {
> + struct drm_histogram_config config;
> + __u64 data_ptr;
> + __u32 nr_elements;
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
>
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 10:08 ` Pekka Paalanen
@ 2025-02-17 12:27 ` Pekka Paalanen
2025-03-03 7:52 ` Murthy, Arun R
2025-02-17 17:26 ` Simona Vetter
2025-02-18 5:43 ` Murthy, Arun R
2 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-02-17 12:27 UTC (permalink / raw)
To: Arun R Murthy
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 7735 bytes --]
On Mon, 17 Feb 2025 12:08:08 +0200
Pekka Paalanen <pekka.paalanen@haloniitty.fi> wrote:
> Hi Arun,
>
> this whole series seems to be missing all the UAPI docs for the DRM
> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> replacement for them, I would assume both are a requirement.
>
> Without the ReST docs it is really difficult to see how this new UAPI
> should be used.
>
>
> On Tue, 28 Jan 2025 21:21:07 +0530
> Arun R Murthy <arun.r.murthy@intel.com> wrote:
>
> > Display Histogram is an array of bins and can be generated in many ways
> > referred to as modes.
> > Ex: HSV max(RGB), Wighted RGB etc.
> >
> > Understanding the histogram data format(Ex: HSV max(RGB))
> > Histogram is just the pixel count.
> > For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > 25 bits should be sufficient to represent this along with a buffer of 7
> > bits(future use) u32 is being considered.
> > max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> > bits, hence 32 bins.
> > Below mentioned algorithm illustrates the histogram generation in
> > hardware.
> >
> > hist[32] = {0};
> > for (i = 0; i < resolution; i++) {
> > bin = max(RGB[i]);
> > bin = bin >> 3; /* consider the most significant bits */
> > hist[bin]++;
> > }
> > If the entire image is Red color then max(255,0,0) is 255 so the pixel
> > count of each pixels will be placed in the last bin. Hence except
> > hist[31] all other bins will have a value zero.
> > Generated histogram in this case would be hist[32] = {0,0,....44236800}
> >
> > Description of the structures, properties defined are documented in the
> > header file include/uapi/drm/drm_mode.h
> >
> > v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >
> > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> > ---
> > include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 65 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> > __u32 pad;
> > };
> >
> > +/**
> > + * enum drm_mode_histogram
> > + *
> > + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> > + * Maximum resolution at present 10k, 10240x4320 = 44236800
> > + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
> > + * can be a u32 value.
> > + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>
> I assume s/SDL/SDR/.
>
> This assumption seems false. SDR can be also 10-bit and probably even
> more.
>
> > + * If the most significant 5 bits are considered, then bins = 2^5
> > + * will be 32 bins.
> > + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
As another reviewer pointed out before, there are 256 different
possible values for an 8-bit integer, and not 255. Likewise, a 16-bit
integer can have 65536 different values, not 65535. Zero is a possible
value.
>
> Does this mean that the histogram is computed on the pixel values
> emitted to the cable? What if the cable format is YUV?
>
> > + * For illustration consider a full RED image of 10k resolution considering all
> > + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
> > + * plane similarly with HDR the same would look like hist[65535] =
> > + * {0,0,0,....44236800}
>
> This SDR vs. HDR is a false dichotomy. I presume the meaningful
> difference is bits-per-channel, not the dynamic range.
>
> It would be good to have the pseudocode snippet here instead of the
> commit message. The commit message should not contain any UAPI notes
> that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
> message is probably not very useful, as the more interesting questions
> are why this exists and what it can be used for.
>
> > + */
> > +enum drm_mode_histogram {
> > + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
>
> What does the HSV stand for?
>
> When talking about pixel values, my first impression is
> hue-saturation-value. But there are no hue-saturation-value
> computations at all?
>
> > +};
> > +
> > +/**
> > + * struct drm_histogram_caps
> > + *
> > + * @histogram_mode: histogram generation modes, defined in the
> > + * enum drm_mode_histogram
> > + * @bins_count: number of bins for a chosen histogram mode. For illustration
> > + * refer the above defined histogram mode.
> > + */
> > +struct drm_histogram_caps {
> > + __u32 histogram_mode;
> > + __u32 bins_count;
> > +};
>
> Patch 3 says:
>
> + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
> + * Description of the structure is in include/uapi/drm/drm_mode.h
>
> This is a read-only property, right?
>
> The blob contains one struct drm_histogram_caps. What if more than one
> mode is supported?
>
> If the bin count depends on the bits-per-channel of something which
> depends on set video mode or other things, how does updating work?
> What if userspace uses a stale count? How does userspace ensure it uses
> the current count?
>
> > +
> > +/**
> > + * struct drm_histogram_config
> > + *
> > + * @hist_mode_data: address to the histogram mode specific data if any
>
> Do I understand correctly that the KMS blob will contain a userspace
> virtual memory address (a user pointer)? How does that work? What are
> the lifetime requirements for that memory?
>
> I do not remember any precedent of this, and I suspect it's not a good
> design. I believe all the data should be contained in the blobs, e.g.
> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> for returning histogram data to userspace, but at least all the data
> sent to the kernel should be contained in the blob itself since it
> seems to be quite small. Variable length is ok for blobs.
>
> > + * @nr_hist_mode_data: number of elements pointed by the address in
> > + * hist_mode_data
> > + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> > + * @enable: flag to enable/disable histogram
> > + */
> > +struct drm_histogram_config {
> > + __u64 hist_mode_data;
> > + __u32 nr_hist_mode_data;
> > + enum drm_mode_histogram hist_mode;
> > + bool enable;
>
> Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
> if architecture, build options, or the contents of the enum change the
> ABI.
To clarify: defining named values with an enum {...} block is ok. Using
the enum type in ABI may cause problems.
Thanks,
pq
> > +};
> > +
> > +/**
> > + * struct drm_histogram
> > + *
> > + * @config: histogram configuration data pointed by struct drm_histogram_config
>
> s/pointed by/defined by/ I presume? That much is obvious from the field
> type. What does it mean? Why is struct drm_histogram_config a separate
> struct?
>
> > + * @data_ptr: pointer to the array of histogram.
> > + * Histogram is an array of bins. Data format for each bin depends
> > + * on the histogram mode. Refer to the above histogram modes for
> > + * more information.
>
> Another userspace virtual address stored in a KMS blob?
>
> > + * @nr_elements: number of bins in the histogram.
> > + */
> > +struct drm_histogram {
> > + struct drm_histogram_config config;
> > + __u64 data_ptr;
> > + __u32 nr_elements;
> > +};
> > +
> > #if defined(__cplusplus)
> > }
> > #endif
> >
>
> Thanks,
> pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 12:27 ` Pekka Paalanen
@ 2025-03-03 7:52 ` Murthy, Arun R
2025-03-03 9:33 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-03 7:52 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
On 17-02-2025 17:57, Pekka Paalanen wrote:
> On Mon, 17 Feb 2025 12:08:08 +0200
> Pekka Paalanen <pekka.paalanen@haloniitty.fi> wrote:
>
>> Hi Arun,
>>
>> this whole series seems to be missing all the UAPI docs for the DRM
>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>> replacement for them, I would assume both are a requirement.
>>
>> Without the ReST docs it is really difficult to see how this new UAPI
>> should be used.
>>
>>
>> On Tue, 28 Jan 2025 21:21:07 +0530
>> Arun R Murthy <arun.r.murthy@intel.com> wrote:
>>
>>> Display Histogram is an array of bins and can be generated in many ways
>>> referred to as modes.
>>> Ex: HSV max(RGB), Wighted RGB etc.
>>>
>>> Understanding the histogram data format(Ex: HSV max(RGB))
>>> Histogram is just the pixel count.
>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
>>> 25 bits should be sufficient to represent this along with a buffer of 7
>>> bits(future use) u32 is being considered.
>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
>>> bits, hence 32 bins.
>>> Below mentioned algorithm illustrates the histogram generation in
>>> hardware.
>>>
>>> hist[32] = {0};
>>> for (i = 0; i < resolution; i++) {
>>> bin = max(RGB[i]);
>>> bin = bin >> 3; /* consider the most significant bits */
>>> hist[bin]++;
>>> }
>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
>>> count of each pixels will be placed in the last bin. Hence except
>>> hist[31] all other bins will have a value zero.
>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>>>
>>> Description of the structures, properties defined are documented in the
>>> header file include/uapi/drm/drm_mode.h
>>>
>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>>>
>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>> ---
>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 65 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
>>> __u32 pad;
>>> };
>>>
>>> +/**
>>> + * enum drm_mode_histogram
>>> + *
>>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
>>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
>>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
>>> + * can be a u32 value.
>>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>> I assume s/SDL/SDR/.
>>
>> This assumption seems false. SDR can be also 10-bit and probably even
>> more.
>>
>>> + * If the most significant 5 bits are considered, then bins = 2^5
>>> + * will be 32 bins.
>>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> As another reviewer pointed out before, there are 256 different
> possible values for an 8-bit integer, and not 255. Likewise, a 16-bit
> integer can have 65536 different values, not 65535. Zero is a possible
> value.
>
>
>> Does this mean that the histogram is computed on the pixel values
>> emitted to the cable? What if the cable format is YUV?
>>
>>> + * For illustration consider a full RED image of 10k resolution considering all
>>> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
>>> + * plane similarly with HDR the same would look like hist[65535] =
>>> + * {0,0,0,....44236800}
>> This SDR vs. HDR is a false dichotomy. I presume the meaningful
>> difference is bits-per-channel, not the dynamic range.
>>
>> It would be good to have the pseudocode snippet here instead of the
>> commit message. The commit message should not contain any UAPI notes
>> that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
>> message is probably not very useful, as the more interesting questions
>> are why this exists and what it can be used for.
>>
>>> + */
>>> +enum drm_mode_histogram {
>>> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
>> What does the HSV stand for?
>>
>> When talking about pixel values, my first impression is
>> hue-saturation-value. But there are no hue-saturation-value
>> computations at all?
>>
>>> +};
>>> +
>>> +/**
>>> + * struct drm_histogram_caps
>>> + *
>>> + * @histogram_mode: histogram generation modes, defined in the
>>> + * enum drm_mode_histogram
>>> + * @bins_count: number of bins for a chosen histogram mode. For illustration
>>> + * refer the above defined histogram mode.
>>> + */
>>> +struct drm_histogram_caps {
>>> + __u32 histogram_mode;
>>> + __u32 bins_count;
>>> +};
>> Patch 3 says:
>>
>> + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
>> + * Description of the structure is in include/uapi/drm/drm_mode.h
>>
>> This is a read-only property, right?
>>
>> The blob contains one struct drm_histogram_caps. What if more than one
>> mode is supported?
>>
>> If the bin count depends on the bits-per-channel of something which
>> depends on set video mode or other things, how does updating work?
>> What if userspace uses a stale count? How does userspace ensure it uses
>> the current count?
>>
>>> +
>>> +/**
>>> + * struct drm_histogram_config
>>> + *
>>> + * @hist_mode_data: address to the histogram mode specific data if any
>> Do I understand correctly that the KMS blob will contain a userspace
>> virtual memory address (a user pointer)? How does that work? What are
>> the lifetime requirements for that memory?
>>
>> I do not remember any precedent of this, and I suspect it's not a good
>> design. I believe all the data should be contained in the blobs, e.g.
>> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
>> for returning histogram data to userspace, but at least all the data
>> sent to the kernel should be contained in the blob itself since it
>> seems to be quite small. Variable length is ok for blobs.
Sorry forgot to add the reason for choosing u64 based ptr in the UAPI.
This histogram is related(something to do) to the color. drm_color is
also exposing the rgb values as __u64 pointer in the struct
drm_mode_crtc_lut
But using __u32 offset as suggested is a very good approach as in
IN_FORMATS.
Thanks and Regards,
Arun R Murthy
--------------------
>>> + * @nr_hist_mode_data: number of elements pointed by the address in
>>> + * hist_mode_data
>>> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
>>> + * @enable: flag to enable/disable histogram
>>> + */
>>> +struct drm_histogram_config {
>>> + __u64 hist_mode_data;
>>> + __u32 nr_hist_mode_data;
>>> + enum drm_mode_histogram hist_mode;
>>> + bool enable;
>> Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
>> if architecture, build options, or the contents of the enum change the
>> ABI.
> To clarify: defining named values with an enum {...} block is ok. Using
> the enum type in ABI may cause problems.
>
>
> Thanks,
> pq
>
>>> +};
>>> +
>>> +/**
>>> + * struct drm_histogram
>>> + *
>>> + * @config: histogram configuration data pointed by struct drm_histogram_config
>> s/pointed by/defined by/ I presume? That much is obvious from the field
>> type. What does it mean? Why is struct drm_histogram_config a separate
>> struct?
>>
>>> + * @data_ptr: pointer to the array of histogram.
>>> + * Histogram is an array of bins. Data format for each bin depends
>>> + * on the histogram mode. Refer to the above histogram modes for
>>> + * more information.
>> Another userspace virtual address stored in a KMS blob?
>>
>>> + * @nr_elements: number of bins in the histogram.
>>> + */
>>> +struct drm_histogram {
>>> + struct drm_histogram_config config;
>>> + __u64 data_ptr;
>>> + __u32 nr_elements;
>>> +};
>>> +
>>> #if defined(__cplusplus)
>>> }
>>> #endif
>>>
>> Thanks,
>> pq
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-03 7:52 ` Murthy, Arun R
@ 2025-03-03 9:33 ` Pekka Paalanen
0 siblings, 0 replies; 58+ messages in thread
From: Pekka Paalanen @ 2025-03-03 9:33 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]
On Mon, 3 Mar 2025 13:22:29 +0530
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 17-02-2025 17:57, Pekka Paalanen wrote:
> > On Mon, 17 Feb 2025 12:08:08 +0200
> > Pekka Paalanen <pekka.paalanen@haloniitty.fi> wrote:
> >
> >> Hi Arun,
> >>
> >> this whole series seems to be missing all the UAPI docs for the DRM
> >> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> >> replacement for them, I would assume both are a requirement.
> >>
> >> Without the ReST docs it is really difficult to see how this new UAPI
> >> should be used.
> >>
> >>
> >> On Tue, 28 Jan 2025 21:21:07 +0530
> >> Arun R Murthy <arun.r.murthy@intel.com> wrote:
> >>
> >>> Display Histogram is an array of bins and can be generated in many ways
> >>> referred to as modes.
> >>> Ex: HSV max(RGB), Wighted RGB etc.
> >>>
> >>> Understanding the histogram data format(Ex: HSV max(RGB))
> >>> Histogram is just the pixel count.
> >>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> >>> 25 bits should be sufficient to represent this along with a buffer of 7
> >>> bits(future use) u32 is being considered.
> >>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> >>> bits, hence 32 bins.
> >>> Below mentioned algorithm illustrates the histogram generation in
> >>> hardware.
> >>>
> >>> hist[32] = {0};
> >>> for (i = 0; i < resolution; i++) {
> >>> bin = max(RGB[i]);
> >>> bin = bin >> 3; /* consider the most significant bits */
> >>> hist[bin]++;
> >>> }
> >>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
> >>> count of each pixels will be placed in the last bin. Hence except
> >>> hist[31] all other bins will have a value zero.
> >>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
> >>>
> >>> Description of the structures, properties defined are documented in the
> >>> header file include/uapi/drm/drm_mode.h
> >>>
> >>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >>>
> >>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >>> ---
> >>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> >>> 1 file changed, 65 insertions(+)
> >>>
> >>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
...
> >>> +/**
> >>> + * struct drm_histogram_config
> >>> + *
> >>> + * @hist_mode_data: address to the histogram mode specific data if any
> >> Do I understand correctly that the KMS blob will contain a userspace
> >> virtual memory address (a user pointer)? How does that work? What are
> >> the lifetime requirements for that memory?
> >>
> >> I do not remember any precedent of this, and I suspect it's not a good
> >> design. I believe all the data should be contained in the blobs, e.g.
> >> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> >> for returning histogram data to userspace, but at least all the data
> >> sent to the kernel should be contained in the blob itself since it
> >> seems to be quite small. Variable length is ok for blobs.
> Sorry forgot to add the reason for choosing u64 based ptr in the UAPI.
> This histogram is related(something to do) to the color. drm_color is
> also exposing the rgb values as __u64 pointer in the struct
> drm_mode_crtc_lut
struct drm_mode_crtc_lut is used in the ioctls DRM_IOCTL_MODE_GETGAMMA
and DRM_IOCTL_MODE_SETGAMMA. The pointers are used only inside the
ioctl call for copying the data to/from user, and they are never saved
for later use in the kernel. That's the fundamental difference. KMS
blob objects OTOH are by definition saved in the kernel for re-use.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 10:08 ` Pekka Paalanen
2025-02-17 12:27 ` Pekka Paalanen
@ 2025-02-17 17:26 ` Simona Vetter
2025-02-17 22:23 ` Simona Vetter
` (2 more replies)
2025-02-18 5:43 ` Murthy, Arun R
2 siblings, 3 replies; 58+ messages in thread
From: Simona Vetter @ 2025-02-17 17:26 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Arun R Murthy, intel-xe, intel-gfx, dri-devel, suraj.kandpal,
dmitry.baryshkov
On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
> Hi Arun,
>
> this whole series seems to be missing all the UAPI docs for the DRM
> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> replacement for them, I would assume both are a requirement.
>
> Without the ReST docs it is really difficult to see how this new UAPI
> should be used.
Seconded. But really only wanted to comment on the userspace address in
drm blobs.
> > +/**
> > + * struct drm_histogram_config
> > + *
> > + * @hist_mode_data: address to the histogram mode specific data if any
>
> Do I understand correctly that the KMS blob will contain a userspace
> virtual memory address (a user pointer)? How does that work? What are
> the lifetime requirements for that memory?
>
> I do not remember any precedent of this, and I suspect it's not a good
> design. I believe all the data should be contained in the blobs, e.g.
> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> for returning histogram data to userspace, but at least all the data
> sent to the kernel should be contained in the blob itself since it
> seems to be quite small. Variable length is ok for blobs.
So yeah this doesn't work for a few reasons:
- It's very restrictive what you're allowed to do during an atomic kms
commit, and a userspace page fault due to copy_from/to_user is
definitely not ok. Which means you need to unconditionally copy before
the atomic commit in the synchronous prep phase for the user->kernel
direction, and somewhere after the entire thing has finished for the
other direction. So this is worse than just more blobs, because with
drm blobs you can at least avoid copying if nothing has changed.
- Due to the above you also cannot synchronize with userspace for the
kernel->userspace copy. And you can't fix that with a sync_file out
fence, because the underlying dma_fence rules are what prevents you from
doing userspace page faults in atomic commit, and the same rules apply
for any other sync_file fence too.
- More fundamentally, both drm blobs and userspace virtual address spaces
(as represented by struct mm_struct) are refconted objects, with
entirely decoupled lifetimes. You'll have UAF issues here, and if you
fix them by grabbing references you'll break the world.
tldr; this does not work
Alternative A: drm blob
-----------------------
This would work for the userspace->kernel direction, but there's some
downsides:
- You still copy, although less often than with a userspace pointer.
- The kernel->userspace direction doesn't work, because blob objects are
immutable. We have mutable blob properties, but mutability is achieved
by exchanging the entire blob object. There's two options to address
that:
a) Fundamentally immutable objects is really nice api designs, so I
prefer to not change that. But in theory making blob objects mutable
would work, and probably break the world.
b) A more benign trick would be to split the blob object id allocation
from creating the object itself. We could then allocate and return
the blob ID of the new histogram to userspace synchronously from the
atomic ioctl, while creating the object for real only in the atomic
commit.
As long as we preallocate any memory this doesn't break and dma_fence
signalling rules. Which also means we could use the existing atomic
out-fence (or a new one for histograms) to signal to userspace when
the data is ready, so this is at least somewhat useful for
compositors without fundamental issues.
You still suffer from additional copies here.
Alternative B: gem_bo
---------------------
One alternative which naturally has mutable data would be gem_bo, maybe
wrapped in a drm_fb. The issue with that is that for small histograms you
really want cpu access both in userspace and the kernel, while most
display hardware wants uncached. And all the display-only kms drivers we
have do not have a concept of cached gem_bo, unlike many of the drm
drivers with render/accel support. Which means we're adding gem_bo which
cannot be used for display, on display-only drivers, and I'd expect this
will result in compositors blowing up in funny ways to no end.
So not a good idea either, at least not if your histograms are small and
the display hw doesn't dma them in/out already anyway.
This also means that we'll probably need 2 interfaces here, one supporting
gem_bo for big histograms and hw that can dma in/out of them, and a 2nd
one optimized for the cpu access case.
Alternative C: memfd
--------------------
I think a new drm property type that accepts memfd would fit the bill
quit well:
- memfd can be mmap(), so you avoid copies.
- their distinct from gem_bo, so no chaos in apis everywhere with imposter
gem_bo that cannot ever be used for display.
- memfd can be sealed, so we can validate that they have the right size
- thanks to umdabuf there's already core mm code to properly pin them, so
painful to implement this all.
For a driver interface I think the memfd should be pinned as long as it's
in a drm_crtc/plane/whatever_state structure, with a kernel vmap void *
pointer already set up. That way drivers can't get this wrong.
The uapi has a few options:
- Allow memfd to back drm_framebuffer. This won't result in api chaos
since the compositor creates these, and these memfd should never show up
in any property that would have a real fb backed by gem_bo. This still
feels horrible to me personally, but it would allow to support
histograms that need gem_bo in the same api. Personally I think we
should just do two flavors, they're too distinct.
- A new memfd kms object like blob objects, which you can create and
destroy and which are refcounted. Creation would also pin the memfd and
check it has a sealed size (and whatever else we want sealed). This
avoids pin/unpin every time you change the memfd property, but no idea
whether that's a real use-case.
- memfd properties just get the file descriptor (like in/out fences do)
and the drm atomic ioctl layer transparently pins/unpins as needed.
Personally I think option C is neat, A doable, B really only for hw that
can dma in/out of histograms and where it's big enough that doing so is a
functional requirement.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 17:26 ` Simona Vetter
@ 2025-02-17 22:23 ` Simona Vetter
2025-02-18 6:01 ` Murthy, Arun R
2025-02-19 13:31 ` Simona Vetter
2 siblings, 0 replies; 58+ messages in thread
From: Simona Vetter @ 2025-02-17 22:23 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Arun R Murthy, intel-xe, intel-gfx, dri-devel, suraj.kandpal,
dmitry.baryshkov
On Mon, Feb 17, 2025 at 06:26:17PM +0100, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> > replacement for them, I would assume both are a requirement.
> >
> > Without the ReST docs it is really difficult to see how this new UAPI
> > should be used.
>
> Seconded. But really only wanted to comment on the userspace address in
> drm blobs.
>
> > > +/**
> > > + * struct drm_histogram_config
> > > + *
> > > + * @hist_mode_data: address to the histogram mode specific data if any
> >
> > Do I understand correctly that the KMS blob will contain a userspace
> > virtual memory address (a user pointer)? How does that work? What are
> > the lifetime requirements for that memory?
> >
> > I do not remember any precedent of this, and I suspect it's not a good
> > design. I believe all the data should be contained in the blobs, e.g.
> > how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> > for returning histogram data to userspace, but at least all the data
> > sent to the kernel should be contained in the blob itself since it
> > seems to be quite small. Variable length is ok for blobs.
>
> So yeah this doesn't work for a few reasons:
>
> - It's very restrictive what you're allowed to do during an atomic kms
> commit, and a userspace page fault due to copy_from/to_user is
> definitely not ok. Which means you need to unconditionally copy before
> the atomic commit in the synchronous prep phase for the user->kernel
> direction, and somewhere after the entire thing has finished for the
> other direction. So this is worse than just more blobs, because with
> drm blobs you can at least avoid copying if nothing has changed.
>
> - Due to the above you also cannot synchronize with userspace for the
> kernel->userspace copy. And you can't fix that with a sync_file out
> fence, because the underlying dma_fence rules are what prevents you from
> doing userspace page faults in atomic commit, and the same rules apply
> for any other sync_file fence too.
>
> - More fundamentally, both drm blobs and userspace virtual address spaces
> (as represented by struct mm_struct) are refconted objects, with
> entirely decoupled lifetimes. You'll have UAF issues here, and if you
> fix them by grabbing references you'll break the world.
>
> tldr; this does not work
>
> Alternative A: drm blob
> -----------------------
>
> This would work for the userspace->kernel direction, but there's some
> downsides:
>
> - You still copy, although less often than with a userspace pointer.
>
> - The kernel->userspace direction doesn't work, because blob objects are
> immutable. We have mutable blob properties, but mutability is achieved
> by exchanging the entire blob object. There's two options to address
> that:
>
> a) Fundamentally immutable objects is really nice api designs, so I
> prefer to not change that. But in theory making blob objects mutable
> would work, and probably break the world.
>
> b) A more benign trick would be to split the blob object id allocation
> from creating the object itself. We could then allocate and return
> the blob ID of the new histogram to userspace synchronously from the
> atomic ioctl, while creating the object for real only in the atomic
> commit.
>
> As long as we preallocate any memory this doesn't break and dma_fence
> signalling rules. Which also means we could use the existing atomic
> out-fence (or a new one for histograms) to signal to userspace when
> the data is ready, so this is at least somewhat useful for
> compositors without fundamental issues.
>
> You still suffer from additional copies here.
>
> Alternative B: gem_bo
> ---------------------
>
> One alternative which naturally has mutable data would be gem_bo, maybe
> wrapped in a drm_fb. The issue with that is that for small histograms you
> really want cpu access both in userspace and the kernel, while most
> display hardware wants uncached. And all the display-only kms drivers we
> have do not have a concept of cached gem_bo, unlike many of the drm
> drivers with render/accel support. Which means we're adding gem_bo which
> cannot be used for display, on display-only drivers, and I'd expect this
> will result in compositors blowing up in funny ways to no end.
>
> So not a good idea either, at least not if your histograms are small and
> the display hw doesn't dma them in/out already anyway.
>
> This also means that we'll probably need 2 interfaces here, one supporting
> gem_bo for big histograms and hw that can dma in/out of them, and a 2nd
> one optimized for the cpu access case.
>
> Alternative C: memfd
> --------------------
>
> I think a new drm property type that accepts memfd would fit the bill
> quit well:
>
> - memfd can be mmap(), so you avoid copies.
>
> - their distinct from gem_bo, so no chaos in apis everywhere with imposter
> gem_bo that cannot ever be used for display.
>
> - memfd can be sealed, so we can validate that they have the right size
>
> - thanks to umdabuf there's already core mm code to properly pin them, so
> painful to implement this all.
>
> For a driver interface I think the memfd should be pinned as long as it's
> in a drm_crtc/plane/whatever_state structure, with a kernel vmap void *
> pointer already set up. That way drivers can't get this wrong.
>
> The uapi has a few options:
>
> - Allow memfd to back drm_framebuffer. This won't result in api chaos
> since the compositor creates these, and these memfd should never show up
> in any property that would have a real fb backed by gem_bo. This still
> feels horrible to me personally, but it would allow to support
> histograms that need gem_bo in the same api. Personally I think we
> should just do two flavors, they're too distinct.
>
> - A new memfd kms object like blob objects, which you can create and
> destroy and which are refcounted. Creation would also pin the memfd and
> check it has a sealed size (and whatever else we want sealed). This
> avoids pin/unpin every time you change the memfd property, but no idea
> whether that's a real use-case.
>
> - memfd properties just get the file descriptor (like in/out fences do)
> and the drm atomic ioctl layer transparently pins/unpins as needed.
One thing I forgot: We'd need to think through if other compositors can
get back to the memfd from the property. Or if it's better to just
disallow that because it'd open up a very funny new ipc mechanism.
-Sima
> Personally I think option C is neat, A doable, B really only for hw that
> can dma in/out of histograms and where it's big enough that doing so is a
> functional requirement.
>
> Cheers, Sima
> --
> Simona Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 17:26 ` Simona Vetter
2025-02-17 22:23 ` Simona Vetter
@ 2025-02-18 6:01 ` Murthy, Arun R
2025-02-19 13:31 ` Simona Vetter
2 siblings, 0 replies; 58+ messages in thread
From: Murthy, Arun R @ 2025-02-18 6:01 UTC (permalink / raw)
To: Simona Vetter, Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
On 17-02-2025 22:56, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
>> Hi Arun,
>>
>> this whole series seems to be missing all the UAPI docs for the DRM
>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>> replacement for them, I would assume both are a requirement.
>>
>> Without the ReST docs it is really difficult to see how this new UAPI
>> should be used.
> Seconded. But really only wanted to comment on the userspace address in
> drm blobs.
>
>>> +/**
>>> + * struct drm_histogram_config
>>> + *
>>> + * @hist_mode_data: address to the histogram mode specific data if any
>> Do I understand correctly that the KMS blob will contain a userspace
>> virtual memory address (a user pointer)? How does that work? What are
>> the lifetime requirements for that memory?
>>
>> I do not remember any precedent of this, and I suspect it's not a good
>> design. I believe all the data should be contained in the blobs, e.g.
>> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
>> for returning histogram data to userspace, but at least all the data
>> sent to the kernel should be contained in the blob itself since it
>> seems to be quite small. Variable length is ok for blobs.
> So yeah this doesn't work for a few reasons:
>
> - It's very restrictive what you're allowed to do during an atomic kms
> commit, and a userspace page fault due to copy_from/to_user is
> definitely not ok. Which means you need to unconditionally copy before
> the atomic commit in the synchronous prep phase for the user->kernel
> direction, and somewhere after the entire thing has finished for the
> other direction. So this is worse than just more blobs, because with
> drm blobs you can at least avoid copying if nothing has changed.
>
> - Due to the above you also cannot synchronize with userspace for the
> kernel->userspace copy. And you can't fix that with a sync_file out
> fence, because the underlying dma_fence rules are what prevents you from
> doing userspace page faults in atomic commit, and the same rules apply
> for any other sync_file fence too.
>
> - More fundamentally, both drm blobs and userspace virtual address spaces
> (as represented by struct mm_struct) are refconted objects, with
> entirely decoupled lifetimes. You'll have UAF issues here, and if you
> fix them by grabbing references you'll break the world.
>
> tldr; this does not work
>
> Alternative A: drm blob
> -----------------------
>
> This would work for the userspace->kernel direction, but there's some
> downsides:
>
> - You still copy, although less often than with a userspace pointer.
>
> - The kernel->userspace direction doesn't work, because blob objects are
> immutable. We have mutable blob properties, but mutability is achieved
> by exchanging the entire blob object. There's two options to address
> that:
>
> a) Fundamentally immutable objects is really nice api designs, so I
> prefer to not change that. But in theory making blob objects mutable
> would work, and probably break the world.
>
> b) A more benign trick would be to split the blob object id allocation
> from creating the object itself. We could then allocate and return
> the blob ID of the new histogram to userspace synchronously from the
> atomic ioctl, while creating the object for real only in the atomic
> commit.
>
> As long as we preallocate any memory this doesn't break and dma_fence
> signalling rules. Which also means we could use the existing atomic
> out-fence (or a new one for histograms) to signal to userspace when
> the data is ready, so this is at least somewhat useful for
> compositors without fundamental issues.
>
> You still suffer from additional copies here.
>
> Alternative B: gem_bo
> ---------------------
>
> One alternative which naturally has mutable data would be gem_bo, maybe
> wrapped in a drm_fb. The issue with that is that for small histograms you
> really want cpu access both in userspace and the kernel, while most
> display hardware wants uncached. And all the display-only kms drivers we
> have do not have a concept of cached gem_bo, unlike many of the drm
> drivers with render/accel support. Which means we're adding gem_bo which
> cannot be used for display, on display-only drivers, and I'd expect this
> will result in compositors blowing up in funny ways to no end.
>
> So not a good idea either, at least not if your histograms are small and
> the display hw doesn't dma them in/out already anyway.
>
> This also means that we'll probably need 2 interfaces here, one supporting
> gem_bo for big histograms and hw that can dma in/out of them, and a 2nd
> one optimized for the cpu access case.
>
> Alternative C: memfd
> --------------------
>
> I think a new drm property type that accepts memfd would fit the bill
> quit well:
>
> - memfd can be mmap(), so you avoid copies.
>
> - their distinct from gem_bo, so no chaos in apis everywhere with imposter
> gem_bo that cannot ever be used for display.
>
> - memfd can be sealed, so we can validate that they have the right size
>
> - thanks to umdabuf there's already core mm code to properly pin them, so
> painful to implement this all.
>
> For a driver interface I think the memfd should be pinned as long as it's
> in a drm_crtc/plane/whatever_state structure, with a kernel vmap void *
> pointer already set up. That way drivers can't get this wrong.
>
> The uapi has a few options:
>
> - Allow memfd to back drm_framebuffer. This won't result in api chaos
> since the compositor creates these, and these memfd should never show up
> in any property that would have a real fb backed by gem_bo. This still
> feels horrible to me personally, but it would allow to support
> histograms that need gem_bo in the same api. Personally I think we
> should just do two flavors, they're too distinct.
>
> - A new memfd kms object like blob objects, which you can create and
> destroy and which are refcounted. Creation would also pin the memfd and
> check it has a sealed size (and whatever else we want sealed). This
> avoids pin/unpin every time you change the memfd property, but no idea
> whether that's a real use-case.
>
> - memfd properties just get the file descriptor (like in/out fences do)
> and the drm atomic ioctl layer transparently pins/unpins as needed.
>
> Personally I think option C is neat, A doable, B really only for hw that
> can dma in/out of histograms and where it's big enough that doing so is a
> functional requirement.
>
> Cheers, Sima
Thanks for the detailed exploration of the options available and the
conclusion among the available options.
Bringing memfd as a drm object opens up new opportunity for the drm
users and a very good thought. Just curious to know if will histogram be
the only user for this or does new IPC open up the thoughts for other
interfaces such as writeback etc
I also personally feel bringing this memfd to drm is a good approach,
will try to explore on the design part.
Any other comments/opinions on this from anyone?
Thanks and Regards,
Arun R Murthy
--------------------
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 17:26 ` Simona Vetter
2025-02-17 22:23 ` Simona Vetter
2025-02-18 6:01 ` Murthy, Arun R
@ 2025-02-19 13:31 ` Simona Vetter
2025-03-03 7:50 ` Murthy, Arun R
2 siblings, 1 reply; 58+ messages in thread
From: Simona Vetter @ 2025-02-19 13:31 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Arun R Murthy, intel-xe, intel-gfx, dri-devel, suraj.kandpal,
dmitry.baryshkov
On Mon, Feb 17, 2025 at 06:26:17PM +0100, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> > replacement for them, I would assume both are a requirement.
> >
> > Without the ReST docs it is really difficult to see how this new UAPI
> > should be used.
>
> Seconded. But really only wanted to comment on the userspace address in
> drm blobs.
>
> > > +/**
> > > + * struct drm_histogram_config
> > > + *
> > > + * @hist_mode_data: address to the histogram mode specific data if any
> >
> > Do I understand correctly that the KMS blob will contain a userspace
> > virtual memory address (a user pointer)? How does that work? What are
> > the lifetime requirements for that memory?
> >
> > I do not remember any precedent of this, and I suspect it's not a good
> > design. I believe all the data should be contained in the blobs, e.g.
> > how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> > for returning histogram data to userspace, but at least all the data
> > sent to the kernel should be contained in the blob itself since it
> > seems to be quite small. Variable length is ok for blobs.
>
> So yeah this doesn't work for a few reasons:
>
> - It's very restrictive what you're allowed to do during an atomic kms
> commit, and a userspace page fault due to copy_from/to_user is
> definitely not ok. Which means you need to unconditionally copy before
> the atomic commit in the synchronous prep phase for the user->kernel
> direction, and somewhere after the entire thing has finished for the
> other direction. So this is worse than just more blobs, because with
> drm blobs you can at least avoid copying if nothing has changed.
>
> - Due to the above you also cannot synchronize with userspace for the
> kernel->userspace copy. And you can't fix that with a sync_file out
> fence, because the underlying dma_fence rules are what prevents you from
> doing userspace page faults in atomic commit, and the same rules apply
> for any other sync_file fence too.
>
> - More fundamentally, both drm blobs and userspace virtual address spaces
> (as represented by struct mm_struct) are refconted objects, with
> entirely decoupled lifetimes. You'll have UAF issues here, and if you
> fix them by grabbing references you'll break the world.
>
> tldr; this does not work
>
> Alternative A: drm blob
> -----------------------
>
> This would work for the userspace->kernel direction, but there's some
> downsides:
>
> - You still copy, although less often than with a userspace pointer.
>
> - The kernel->userspace direction doesn't work, because blob objects are
> immutable. We have mutable blob properties, but mutability is achieved
> by exchanging the entire blob object. There's two options to address
> that:
>
> a) Fundamentally immutable objects is really nice api designs, so I
> prefer to not change that. But in theory making blob objects mutable
> would work, and probably break the world.
>
> b) A more benign trick would be to split the blob object id allocation
> from creating the object itself. We could then allocate and return
> the blob ID of the new histogram to userspace synchronously from the
> atomic ioctl, while creating the object for real only in the atomic
> commit.
>
> As long as we preallocate any memory this doesn't break and dma_fence
> signalling rules. Which also means we could use the existing atomic
> out-fence (or a new one for histograms) to signal to userspace when
> the data is ready, so this is at least somewhat useful for
> compositors without fundamental issues.
>
> You still suffer from additional copies here.
Another detail I've forgotten: If you queue an atomic commit and then
immmediately do a compositor swithc, then the new compositor would end up
with the very confusing situation of having a blob property pointing at a
blob which does not yet exist. And since it wont get the drm_event nor has
a dma_fence out-fence, it also cannot reliably wait.
So this would be awkward at best, and might actually be a cross-compositor
attack vector.
So yeah delayed blob object creation also don't look great, and mutable
blob objects probably break compositors even harder and we'd need to make
this all opt-in.
We need an opt-in for all of these I think, but the more I think about it
the more this alternative looks like the worst.
> Alternative B: gem_bo
> ---------------------
>
> One alternative which naturally has mutable data would be gem_bo, maybe
> wrapped in a drm_fb. The issue with that is that for small histograms you
> really want cpu access both in userspace and the kernel, while most
> display hardware wants uncached. And all the display-only kms drivers we
> have do not have a concept of cached gem_bo, unlike many of the drm
> drivers with render/accel support. Which means we're adding gem_bo which
> cannot be used for display, on display-only drivers, and I'd expect this
> will result in compositors blowing up in funny ways to no end.
>
> So not a good idea either, at least not if your histograms are small and
> the display hw doesn't dma them in/out already anyway.
>
> This also means that we'll probably need 2 interfaces here, one supporting
> gem_bo for big histograms and hw that can dma in/out of them, and a 2nd
> one optimized for the cpu access case.
>
> Alternative C: memfd
> --------------------
>
> I think a new drm property type that accepts memfd would fit the bill
> quit well:
>
> - memfd can be mmap(), so you avoid copies.
>
> - their distinct from gem_bo, so no chaos in apis everywhere with imposter
> gem_bo that cannot ever be used for display.
>
> - memfd can be sealed, so we can validate that they have the right size
>
> - thanks to umdabuf there's already core mm code to properly pin them, so
> painful to implement this all.
>
> For a driver interface I think the memfd should be pinned as long as it's
> in a drm_crtc/plane/whatever_state structure, with a kernel vmap void *
> pointer already set up. That way drivers can't get this wrong.
>
> The uapi has a few options:
>
> - Allow memfd to back drm_framebuffer. This won't result in api chaos
> since the compositor creates these, and these memfd should never show up
> in any property that would have a real fb backed by gem_bo. This still
> feels horrible to me personally, but it would allow to support
> histograms that need gem_bo in the same api. Personally I think we
> should just do two flavors, they're too distinct.
>
> - A new memfd kms object like blob objects, which you can create and
> destroy and which are refcounted. Creation would also pin the memfd and
> check it has a sealed size (and whatever else we want sealed). This
> avoids pin/unpin every time you change the memfd property, but no idea
> whether that's a real use-case.
>
> - memfd properties just get the file descriptor (like in/out fences do)
> and the drm atomic ioctl layer transparently pins/unpins as needed.
>
> Personally I think option C is neat, A doable, B really only for hw that
> can dma in/out of histograms and where it's big enough that doing so is a
> functional requirement.
Also for all these we'd need to make these new properties opt-in and hide
them from compositors who cannot cope. Just defensive programming best
practices.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-19 13:31 ` Simona Vetter
@ 2025-03-03 7:50 ` Murthy, Arun R
0 siblings, 0 replies; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-03 7:50 UTC (permalink / raw)
To: Simona Vetter, Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
On 19-02-2025 19:01, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 06:26:17PM +0100, Simona Vetter wrote:
>> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
>>> Hi Arun,
>>>
>>> this whole series seems to be missing all the UAPI docs for the DRM
>>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>>> replacement for them, I would assume both are a requirement.
>>>
>>> Without the ReST docs it is really difficult to see how this new UAPI
>>> should be used.
>> Seconded. But really only wanted to comment on the userspace address in
>> drm blobs.
>>
>>>> +/**
>>>> + * struct drm_histogram_config
>>>> + *
>>>> + * @hist_mode_data: address to the histogram mode specific data if any
>>> Do I understand correctly that the KMS blob will contain a userspace
>>> virtual memory address (a user pointer)? How does that work? What are
>>> the lifetime requirements for that memory?
>>>
>>> I do not remember any precedent of this, and I suspect it's not a good
>>> design. I believe all the data should be contained in the blobs, e.g.
>>> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
>>> for returning histogram data to userspace, but at least all the data
>>> sent to the kernel should be contained in the blob itself since it
>>> seems to be quite small. Variable length is ok for blobs.
>> So yeah this doesn't work for a few reasons:
>>
>> - It's very restrictive what you're allowed to do during an atomic kms
>> commit, and a userspace page fault due to copy_from/to_user is
>> definitely not ok. Which means you need to unconditionally copy before
>> the atomic commit in the synchronous prep phase for the user->kernel
>> direction, and somewhere after the entire thing has finished for the
>> other direction. So this is worse than just more blobs, because with
>> drm blobs you can at least avoid copying if nothing has changed.
>>
>> - Due to the above you also cannot synchronize with userspace for the
>> kernel->userspace copy. And you can't fix that with a sync_file out
>> fence, because the underlying dma_fence rules are what prevents you from
>> doing userspace page faults in atomic commit, and the same rules apply
>> for any other sync_file fence too.
>>
>> - More fundamentally, both drm blobs and userspace virtual address spaces
>> (as represented by struct mm_struct) are refconted objects, with
>> entirely decoupled lifetimes. You'll have UAF issues here, and if you
>> fix them by grabbing references you'll break the world.
>>
>> tldr; this does not work
>>
>> Alternative A: drm blob
>> -----------------------
>>
>> This would work for the userspace->kernel direction, but there's some
>> downsides:
>>
>> - You still copy, although less often than with a userspace pointer.
>>
>> - The kernel->userspace direction doesn't work, because blob objects are
>> immutable. We have mutable blob properties, but mutability is achieved
>> by exchanging the entire blob object. There's two options to address
>> that:
>>
>> a) Fundamentally immutable objects is really nice api designs, so I
>> prefer to not change that. But in theory making blob objects mutable
>> would work, and probably break the world.
>>
>> b) A more benign trick would be to split the blob object id allocation
>> from creating the object itself. We could then allocate and return
>> the blob ID of the new histogram to userspace synchronously from the
>> atomic ioctl, while creating the object for real only in the atomic
>> commit.
>>
>> As long as we preallocate any memory this doesn't break and dma_fence
>> signalling rules. Which also means we could use the existing atomic
>> out-fence (or a new one for histograms) to signal to userspace when
>> the data is ready, so this is at least somewhat useful for
>> compositors without fundamental issues.
>>
>> You still suffer from additional copies here.
> Another detail I've forgotten: If you queue an atomic commit and then
> immmediately do a compositor swithc, then the new compositor would end up
> with the very confusing situation of having a blob property pointing at a
> blob which does not yet exist. And since it wont get the drm_event nor has
> a dma_fence out-fence, it also cannot reliably wait.
>
> So this would be awkward at best, and might actually be a cross-compositor
> attack vector.
>
> So yeah delayed blob object creation also don't look great, and mutable
> blob objects probably break compositors even harder and we'd need to make
> this all opt-in.
>
> We need an opt-in for all of these I think, but the more I think about it
> the more this alternative looks like the worst.
>
>> Alternative B: gem_bo
>> ---------------------
>>
>> One alternative which naturally has mutable data would be gem_bo, maybe
>> wrapped in a drm_fb. The issue with that is that for small histograms you
>> really want cpu access both in userspace and the kernel, while most
>> display hardware wants uncached. And all the display-only kms drivers we
>> have do not have a concept of cached gem_bo, unlike many of the drm
>> drivers with render/accel support. Which means we're adding gem_bo which
>> cannot be used for display, on display-only drivers, and I'd expect this
>> will result in compositors blowing up in funny ways to no end.
>>
>> So not a good idea either, at least not if your histograms are small and
>> the display hw doesn't dma them in/out already anyway.
>>
>> This also means that we'll probably need 2 interfaces here, one supporting
>> gem_bo for big histograms and hw that can dma in/out of them, and a 2nd
>> one optimized for the cpu access case.
>>
>> Alternative C: memfd
>> --------------------
>>
>> I think a new drm property type that accepts memfd would fit the bill
>> quit well:
>>
>> - memfd can be mmap(), so you avoid copies.
>>
>> - their distinct from gem_bo, so no chaos in apis everywhere with imposter
>> gem_bo that cannot ever be used for display.
>>
>> - memfd can be sealed, so we can validate that they have the right size
>>
>> - thanks to umdabuf there's already core mm code to properly pin them, so
>> painful to implement this all.
>>
>> For a driver interface I think the memfd should be pinned as long as it's
>> in a drm_crtc/plane/whatever_state structure, with a kernel vmap void *
>> pointer already set up. That way drivers can't get this wrong.
>>
>> The uapi has a few options:
>>
>> - Allow memfd to back drm_framebuffer. This won't result in api chaos
>> since the compositor creates these, and these memfd should never show up
>> in any property that would have a real fb backed by gem_bo. This still
>> feels horrible to me personally, but it would allow to support
>> histograms that need gem_bo in the same api. Personally I think we
>> should just do two flavors, they're too distinct.
>>
>> - A new memfd kms object like blob objects, which you can create and
>> destroy and which are refcounted. Creation would also pin the memfd and
>> check it has a sealed size (and whatever else we want sealed). This
>> avoids pin/unpin every time you change the memfd property, but no idea
>> whether that's a real use-case.
>>
>> - memfd properties just get the file descriptor (like in/out fences do)
>> and the drm atomic ioctl layer transparently pins/unpins as needed.
>>
>> Personally I think option C is neat, A doable, B really only for hw that
>> can dma in/out of histograms and where it's big enough that doing so is a
>> functional requirement.
> Also for all these we'd need to make these new properties opt-in and hide
> them from compositors who cannot cope. Just defensive programming best
> practices.
Thanks for the suggestions, having a new IPC memfd in drm is a great
idea and helps not only for this but should also help others like
writeback etc. I will explore more on the memfd.
Thanks and Regards,
Arun R Murthy
--------------------
> -Sima
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-17 10:08 ` Pekka Paalanen
2025-02-17 12:27 ` Pekka Paalanen
2025-02-17 17:26 ` Simona Vetter
@ 2025-02-18 5:43 ` Murthy, Arun R
2025-02-18 16:18 ` Pekka Paalanen
2025-02-20 16:26 ` Dmitry Baryshkov
2 siblings, 2 replies; 58+ messages in thread
From: Murthy, Arun R @ 2025-02-18 5:43 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
On 17-02-2025 15:38, Pekka Paalanen wrote:
> Hi Arun,
>
> this whole series seems to be missing all the UAPI docs for the DRM
> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> replacement for them, I would assume both are a requirement.
>
> Without the ReST docs it is really difficult to see how this new UAPI
> should be used.
Hi Pekka,
I also realized later on this. Will add this in my next patchset.
>
> On Tue, 28 Jan 2025 21:21:07 +0530
> Arun R Murthy <arun.r.murthy@intel.com> wrote:
>
>> Display Histogram is an array of bins and can be generated in many ways
>> referred to as modes.
>> Ex: HSV max(RGB), Wighted RGB etc.
>>
>> Understanding the histogram data format(Ex: HSV max(RGB))
>> Histogram is just the pixel count.
>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
>> 25 bits should be sufficient to represent this along with a buffer of 7
>> bits(future use) u32 is being considered.
>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
>> bits, hence 32 bins.
>> Below mentioned algorithm illustrates the histogram generation in
>> hardware.
>>
>> hist[32] = {0};
>> for (i = 0; i < resolution; i++) {
>> bin = max(RGB[i]);
>> bin = bin >> 3; /* consider the most significant bits */
>> hist[bin]++;
>> }
>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
>> count of each pixels will be placed in the last bin. Hence except
>> hist[31] all other bins will have a value zero.
>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>>
>> Description of the structures, properties defined are documented in the
>> header file include/uapi/drm/drm_mode.h
>>
>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>>
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 65 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
>> __u32 pad;
>> };
>>
>> +/**
>> + * enum drm_mode_histogram
>> + *
>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
>> + * can be a u32 value.
>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
> I assume s/SDL/SDR/.
Yes, sorry TYPO
>
> This assumption seems false. SDR can be also 10-bit and probably even
> more.
Yes but in practice majority of them being 8-bit. So have considered
8-bit for illustration purpose only.
The design itself should accommodate 10-bit as well.
>> + * If the most significant 5 bits are considered, then bins = 2^5
>> + * will be 32 bins.
>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> Does this mean that the histogram is computed on the pixel values
> emitted to the cable? What if the cable format is YUV?
Yes, again the illustration over here is max(RGB) used for histogram
generation.
If YUV is used or weighted RGB is used for histogram generation then the
mode will have to change and accordingly the data for that mode.
>> + * For illustration consider a full RED image of 10k resolution considering all
>> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
>> + * plane similarly with HDR the same would look like hist[65535] =
>> + * {0,0,0,....44236800}
> This SDR vs. HDR is a false dichotomy. I presume the meaningful
> difference is bits-per-channel, not the dynamic range.
>
> It would be good to have the pseudocode snippet here instead of the
> commit message. The commit message should not contain any UAPI notes
> that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
> message is probably not very useful, as the more interesting questions
> are why this exists and what it can be used for.
I have the pseudocode in the cover letter of this patchset.
>> + */
>> +enum drm_mode_histogram {
>> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
> What does the HSV stand for?
>
> When talking about pixel values, my first impression is
> hue-saturation-value. But there are no hue-saturation-value
> computations at all?
The computation will have to be done by the user in the library.
>> +};
>> +
>> +/**
>> + * struct drm_histogram_caps
>> + *
>> + * @histogram_mode: histogram generation modes, defined in the
>> + * enum drm_mode_histogram
>> + * @bins_count: number of bins for a chosen histogram mode. For illustration
>> + * refer the above defined histogram mode.
>> + */
>> +struct drm_histogram_caps {
>> + __u32 histogram_mode;
>> + __u32 bins_count;
>> +};
> Patch 3 says:
>
> + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
> + * Description of the structure is in include/uapi/drm/drm_mode.h
>
> This is a read-only property, right?
>
> The blob contains one struct drm_histogram_caps. What if more than one
> mode is supported?
Multiple modes can be ORed. User will have to choose one of them
depending on the algorithm that he is developing/using.
> If the bin count depends on the bits-per-channel of something which
> depends on set video mode or other things, how does updating work?
> What if userspace uses a stale count? How does userspace ensure it uses
> the current count?
The bin count depends on the hardware design. Hence this bin count will
be share to the user via the histogram capability.
>> +
>> +/**
>> + * struct drm_histogram_config
>> + *
>> + * @hist_mode_data: address to the histogram mode specific data if any
> Do I understand correctly that the KMS blob will contain a userspace
> virtual memory address (a user pointer)? How does that work? What are
> the lifetime requirements for that memory?
>
> I do not remember any precedent of this, and I suspect it's not a good
> design. I believe all the data should be contained in the blobs, e.g.
> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> for returning histogram data to userspace, but at least all the data
> sent to the kernel should be contained in the blob itself since it
> seems to be quite small. Variable length is ok for blobs.
This point has actually opened up discussion on the design. Sima has
infact commented the same with multiple options and which among them
buits best. Lets take this discussion on that thread.
>> + * @nr_hist_mode_data: number of elements pointed by the address in
>> + * hist_mode_data
>> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
>> + * @enable: flag to enable/disable histogram
>> + */
>> +struct drm_histogram_config {
>> + __u64 hist_mode_data;
>> + __u32 nr_hist_mode_data;
>> + enum drm_mode_histogram hist_mode;
>> + bool enable;
> Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
> if architecture, build options, or the contents of the enum change the
> ABI.
>
>> +};
>> +
>> +/**
>> + * struct drm_histogram
>> + *
>> + * @config: histogram configuration data pointed by struct drm_histogram_config
> s/pointed by/defined by/ I presume? That much is obvious from the field
> type. What does it mean? Why is struct drm_histogram_config a separate
> struct?
This is totally a separate property for enabling histogram. When
enabling histogram if there are multiple modes of histogram generation
supported by the hardware which among them will be used here and the
data for that mode if required(For Ex: weights for the RGB in case of
weighted RGB) would have to be sent from user and this struct
drm_histogram_config holds those elements.
>> + * @data_ptr: pointer to the array of histogram.
>> + * Histogram is an array of bins. Data format for each bin depends
>> + * on the histogram mode. Refer to the above histogram modes for
>> + * more information.
> Another userspace virtual address stored in a KMS blob?
>
>> + * @nr_elements: number of bins in the histogram.
>> + */
>> +struct drm_histogram {
>> + struct drm_histogram_config config;
>> + __u64 data_ptr;
>> + __u32 nr_elements;
>> +};
>> +
>> #if defined(__cplusplus)
>> }
>> #endif
>>
> Thanks,
> pq
Thanks and Regards,
Arun R Murthy
-------------------
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-18 5:43 ` Murthy, Arun R
@ 2025-02-18 16:18 ` Pekka Paalanen
2025-02-19 3:58 ` Murthy, Arun R
2025-02-20 16:26 ` Dmitry Baryshkov
1 sibling, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-02-18 16:18 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 11085 bytes --]
On Tue, 18 Feb 2025 11:13:39 +0530
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 17-02-2025 15:38, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> > replacement for them, I would assume both are a requirement.
> >
> > Without the ReST docs it is really difficult to see how this new UAPI
> > should be used.
> Hi Pekka,
> I also realized later on this. Will add this in my next patchset.
> >
> > On Tue, 28 Jan 2025 21:21:07 +0530
> > Arun R Murthy <arun.r.murthy@intel.com> wrote:
> >
> >> Display Histogram is an array of bins and can be generated in many ways
> >> referred to as modes.
> >> Ex: HSV max(RGB), Wighted RGB etc.
> >>
> >> Understanding the histogram data format(Ex: HSV max(RGB))
> >> Histogram is just the pixel count.
> >> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> >> 25 bits should be sufficient to represent this along with a buffer of 7
> >> bits(future use) u32 is being considered.
> >> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> >> bits, hence 32 bins.
> >> Below mentioned algorithm illustrates the histogram generation in
> >> hardware.
> >>
> >> hist[32] = {0};
> >> for (i = 0; i < resolution; i++) {
> >> bin = max(RGB[i]);
> >> bin = bin >> 3; /* consider the most significant bits */
> >> hist[bin]++;
> >> }
> >> If the entire image is Red color then max(255,0,0) is 255 so the pixel
> >> count of each pixels will be placed in the last bin. Hence except
> >> hist[31] all other bins will have a value zero.
> >> Generated histogram in this case would be hist[32] = {0,0,....44236800}
> >>
> >> Description of the structures, properties defined are documented in the
> >> header file include/uapi/drm/drm_mode.h
> >>
> >> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >>
> >> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> >> ---
> >> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 65 insertions(+)
> >>
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> >> __u32 pad;
> >> };
> >>
> >> +/**
> >> + * enum drm_mode_histogram
> >> + *
> >> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> >> + * Maximum resolution at present 10k, 10240x4320 = 44236800
> >> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
> >> + * can be a u32 value.
> >> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
> > I assume s/SDL/SDR/.
> Yes, sorry TYPO
> >
> > This assumption seems false. SDR can be also 10-bit and probably even
> > more.
> Yes but in practice majority of them being 8-bit. So have considered
> 8-bit for illustration purpose only.
> The design itself should accommodate 10-bit as well.
Hi Arun,
if these are just examples, then there is no need to mention SDR or
HDR. You can say that if "thing" is 8-bit, then there are 256 possible
values, and we could have 256 bins or we could have just 32 bins.
But what is "thing"? Let's see below.
> >> + * If the most significant 5 bits are considered, then bins = 2^5
> >> + * will be 32 bins.
> >> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> > Does this mean that the histogram is computed on the pixel values
> > emitted to the cable? What if the cable format is YUV?
> Yes, again the illustration over here is max(RGB) used for histogram
> generation.
> If YUV is used or weighted RGB is used for histogram generation then the
> mode will have to change and accordingly the data for that mode.
Do you mean that the HDMI or DisplayPort signalling mode (YUV vs. RGB?
sub-sampling? bit-depth?) affects which histogram modes can be used?
Currently userspace cannot know or control the signalling mode. How
would userspace know which histogram modes are possible?
You should also define at which point of the pixel pipeline the
histogram is recorded. Is it before, say, CRTC DEGAMMA processing? Is
it after signal encoding to the 6/8/10/12/14/16-bit RGB or YUV format?
Before or after YUV sub-sampling? Limited or full range?
> >> + * For illustration consider a full RED image of 10k resolution considering all
> >> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
> >> + * plane similarly with HDR the same would look like hist[65535] =
> >> + * {0,0,0,....44236800}
> > This SDR vs. HDR is a false dichotomy. I presume the meaningful
> > difference is bits-per-channel, not the dynamic range.
> >
> > It would be good to have the pseudocode snippet here instead of the
> > commit message. The commit message should not contain any UAPI notes
> > that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
> > message is probably not very useful, as the more interesting questions
> > are why this exists and what it can be used for.
> I have the pseudocode in the cover letter of this patchset.
The cover letter won't end up in kernel documentation. It should be in
the documentation since it is a very explicit and good way to document
what the histogram recorder does.
> >> + */
> >> +enum drm_mode_histogram {
> >> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
> > What does the HSV stand for?
> >
> > When talking about pixel values, my first impression is
> > hue-saturation-value. But there are no hue-saturation-value
> > computations at all?
> The computation will have to be done by the user in the library.
Why does the UAPI token have "HSV" in its name?
There is nothing related to hue, saturation or value here. It's just
max(R, G, B).
> >> +};
> >> +
> >> +/**
> >> + * struct drm_histogram_caps
> >> + *
> >> + * @histogram_mode: histogram generation modes, defined in the
> >> + * enum drm_mode_histogram
> >> + * @bins_count: number of bins for a chosen histogram mode. For illustration
> >> + * refer the above defined histogram mode.
> >> + */
> >> +struct drm_histogram_caps {
> >> + __u32 histogram_mode;
> >> + __u32 bins_count;
> >> +};
> > Patch 3 says:
> >
> > + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
> > + * Description of the structure is in include/uapi/drm/drm_mode.h
> >
> > This is a read-only property, right?
> >
> > The blob contains one struct drm_histogram_caps. What if more than one
> > mode is supported?
> Multiple modes can be ORed. User will have to choose one of them
> depending on the algorithm that he is developing/using.
Oh! That did not occur to me. This needs documentation.
Do all modes use the same bin count?
> > If the bin count depends on the bits-per-channel of something which
> > depends on set video mode or other things, how does updating work?
> > What if userspace uses a stale count? How does userspace ensure it uses
> > the current count?
> The bin count depends on the hardware design. Hence this bin count will
> be share to the user via the histogram capability.
If the bin counts depend on hardware only, then the SDR/HDR examples
are misleading. They seem to imply a connection between bit depth and
bin count. Instead, you can just say that the bin count is dictated by
the hardware design.
I wonder if that is a future-proof assumption. I could easily expect
that different histogram modes would use different bin counts, or
produce multiple histograms (one per channel), or even 3D histograms.
One also wouldn't want to use more bins than the signal has possible
values.
Just pondering. It's perilous to try to make UAPI generic if there is
only one vendor or piece of hardware.
> >> +
> >> +/**
> >> + * struct drm_histogram_config
> >> + *
> >> + * @hist_mode_data: address to the histogram mode specific data if any
> > Do I understand correctly that the KMS blob will contain a userspace
> > virtual memory address (a user pointer)? How does that work? What are
> > the lifetime requirements for that memory?
> >
> > I do not remember any precedent of this, and I suspect it's not a good
> > design. I believe all the data should be contained in the blobs, e.g.
> > how IN_FORMATS does it. I'm not sure what would be the best UAPI here
> > for returning histogram data to userspace, but at least all the data
> > sent to the kernel should be contained in the blob itself since it
> > seems to be quite small. Variable length is ok for blobs.
> This point has actually opened up discussion on the design. Sima has
> infact commented the same with multiple options and which among them
> buits best. Lets take this discussion on that thread.
Indeed, I don't know much about that topic.
> >> + * @nr_hist_mode_data: number of elements pointed by the address in
> >> + * hist_mode_data
> >> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
> >> + * @enable: flag to enable/disable histogram
> >> + */
> >> +struct drm_histogram_config {
> >> + __u64 hist_mode_data;
> >> + __u32 nr_hist_mode_data;
> >> + enum drm_mode_histogram hist_mode;
> >> + bool enable;
> > Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
> > if architecture, build options, or the contents of the enum change the
> > ABI.
> >
> >> +};
> >> +
> >> +/**
> >> + * struct drm_histogram
> >> + *
> >> + * @config: histogram configuration data pointed by struct drm_histogram_config
> > s/pointed by/defined by/ I presume? That much is obvious from the field
> > type. What does it mean? Why is struct drm_histogram_config a separate
> > struct?
> This is totally a separate property for enabling histogram. When
> enabling histogram if there are multiple modes of histogram generation
> supported by the hardware which among them will be used here and the
> data for that mode if required(For Ex: weights for the RGB in case of
> weighted RGB) would have to be sent from user and this struct
> drm_histogram_config holds those elements.
Ah, I missed that there is a KMS property holding only a config.
> >> + * @data_ptr: pointer to the array of histogram.
> >> + * Histogram is an array of bins. Data format for each bin depends
> >> + * on the histogram mode. Refer to the above histogram modes for
> >> + * more information.
> > Another userspace virtual address stored in a KMS blob?
> >
> >> + * @nr_elements: number of bins in the histogram.
> >> + */
> >> +struct drm_histogram {
> >> + struct drm_histogram_config config;
> >> + __u64 data_ptr;
> >> + __u32 nr_elements;
> >> +};
> >> +
> >> #if defined(__cplusplus)
> >> }
> >> #endif
> >>
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-18 16:18 ` Pekka Paalanen
@ 2025-02-19 3:58 ` Murthy, Arun R
2025-02-20 15:50 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-02-19 3:58 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 12022 bytes --]
On 18-02-2025 21:48, Pekka Paalanen wrote:
> On Tue, 18 Feb 2025 11:13:39 +0530
> "Murthy, Arun R"<arun.r.murthy@intel.com> wrote:
>
>> On 17-02-2025 15:38, Pekka Paalanen wrote:
>>> Hi Arun,
>>>
>>> this whole series seems to be missing all the UAPI docs for the DRM
>>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>>> replacement for them, I would assume both are a requirement.
>>>
>>> Without the ReST docs it is really difficult to see how this new UAPI
>>> should be used.
>> Hi Pekka,
>> I also realized later on this. Will add this in my next patchset.
>>> On Tue, 28 Jan 2025 21:21:07 +0530
>>> Arun R Murthy<arun.r.murthy@intel.com> wrote:
>>>
>>>> Display Histogram is an array of bins and can be generated in many ways
>>>> referred to as modes.
>>>> Ex: HSV max(RGB), Wighted RGB etc.
>>>>
>>>> Understanding the histogram data format(Ex: HSV max(RGB))
>>>> Histogram is just the pixel count.
>>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
>>>> 25 bits should be sufficient to represent this along with a buffer of 7
>>>> bits(future use) u32 is being considered.
>>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
>>>> bits, hence 32 bins.
>>>> Below mentioned algorithm illustrates the histogram generation in
>>>> hardware.
>>>>
>>>> hist[32] = {0};
>>>> for (i = 0; i < resolution; i++) {
>>>> bin = max(RGB[i]);
>>>> bin = bin >> 3; /* consider the most significant bits */
>>>> hist[bin]++;
>>>> }
>>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
>>>> count of each pixels will be placed in the last bin. Hence except
>>>> hist[31] all other bins will have a value zero.
>>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>>>>
>>>> Description of the structures, properties defined are documented in the
>>>> header file include/uapi/drm/drm_mode.h
>>>>
>>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>>>>
>>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
>>>> ---
>>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 65 insertions(+)
>>>>
>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
>>>> --- a/include/uapi/drm/drm_mode.h
>>>> +++ b/include/uapi/drm/drm_mode.h
>>>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
>>>> __u32 pad;
>>>> };
>>>>
>>>> +/**
>>>> + * enum drm_mode_histogram
>>>> + *
>>>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
>>>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
>>>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
>>>> + * can be a u32 value.
>>>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>>> I assume s/SDL/SDR/.
>> Yes, sorry TYPO
>>> This assumption seems false. SDR can be also 10-bit and probably even
>>> more.
>> Yes but in practice majority of them being 8-bit. So have considered
>> 8-bit for illustration purpose only.
>> The design itself should accommodate 10-bit as well.
> Hi Arun,
>
> if these are just examples, then there is no need to mention SDR or
> HDR. You can say that if "thing" is 8-bit, then there are 256 possible
> values, and we could have 256 bins or we could have just 32 bins.
>
> But what is "thing"? Let's see below.
Sure will remove these over here and add then in the ReST document.
>>>> + * If the most significant 5 bits are considered, then bins = 2^5
>>>> + * will be 32 bins.
>>>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
>>> Does this mean that the histogram is computed on the pixel values
>>> emitted to the cable? What if the cable format is YUV?
>> Yes, again the illustration over here is max(RGB) used for histogram
>> generation.
>> If YUV is used or weighted RGB is used for histogram generation then the
>> mode will have to change and accordingly the data for that mode.
> Do you mean that the HDMI or DisplayPort signalling mode (YUV vs. RGB?
> sub-sampling? bit-depth?) affects which histogram modes can be used?
No this is actually for user as to how to interpret the histogram data
that is being sent from the KMD. UMD reads this histogram so in order to
understand the format of this data he needs to know the histogram mode.
> Currently userspace cannot know or control the signalling mode. How
> would userspace know which histogram modes are possible?
As part of drm_histogram_caps struct under HISTOGRAM_CAPS property KMD
will expose all of the supported histogram modes to the user. User will
then choose one among the supported modes by drm_histogram_config
struct(HISTOGRAM_ENABLE property)
> You should also define at which point of the pixel pipeline the
> histogram is recorded. Is it before, say, CRTC DEGAMMA processing? Is
> it after signal encoding to the 6/8/10/12/14/16-bit RGB or YUV format?
> Before or after YUV sub-sampling? Limited or full range?
This again is the hardware design. Theoretically this histogram hardware
will be at the end of the hardware pipe, i.e after hardware/software
composition is done.
>>>> + * For illustration consider a full RED image of 10k resolution considering all
>>>> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
>>>> + * plane similarly with HDR the same would look like hist[65535] =
>>>> + * {0,0,0,....44236800}
>>> This SDR vs. HDR is a false dichotomy. I presume the meaningful
>>> difference is bits-per-channel, not the dynamic range.
>>>
>>> It would be good to have the pseudocode snippet here instead of the
>>> commit message. The commit message should not contain any UAPI notes
>>> that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
>>> message is probably not very useful, as the more interesting questions
>>> are why this exists and what it can be used for.
>> I have the pseudocode in the cover letter of this patchset.
> The cover letter won't end up in kernel documentation. It should be in
> the documentation since it is a very explicit and good way to document
> what the histogram recorder does.
Sure will move to the ReST doc.
>>>> + */
>>>> +enum drm_mode_histogram {
>>>> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
>>> What does the HSV stand for?
>>>
>>> When talking about pixel values, my first impression is
>>> hue-saturation-value. But there are no hue-saturation-value
>>> computations at all?
>> The computation will have to be done by the user in the library.
> Why does the UAPI token have "HSV" in its name?
Agree, will remove that.
> There is nothing related to hue, saturation or value here. It's just
> max(R, G, B).
>
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct drm_histogram_caps
>>>> + *
>>>> + * @histogram_mode: histogram generation modes, defined in the
>>>> + * enum drm_mode_histogram
>>>> + * @bins_count: number of bins for a chosen histogram mode. For illustration
>>>> + * refer the above defined histogram mode.
>>>> + */
>>>> +struct drm_histogram_caps {
>>>> + __u32 histogram_mode;
>>>> + __u32 bins_count;
>>>> +};
>>> Patch 3 says:
>>>
>>> + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
>>> + * Description of the structure is in include/uapi/drm/drm_mode.h
>>>
>>> This is a read-only property, right?
>>>
>>> The blob contains one struct drm_histogram_caps. What if more than one
>>> mode is supported?
>> Multiple modes can be ORed. User will have to choose one of them
>> depending on the algorithm that he is developing/using.
> Oh! That did not occur to me. This needs documentation.
Sure will add this in ReST doc.
> Do all modes use the same bin count?
Again this dependents on the hardware design.
>>> If the bin count depends on the bits-per-channel of something which
>>> depends on set video mode or other things, how does updating work?
>>> What if userspace uses a stale count? How does userspace ensure it uses
>>> the current count?
>> The bin count depends on the hardware design. Hence this bin count will
>> be share to the user via the histogram capability.
> If the bin counts depend on hardware only, then the SDR/HDR examples
> are misleading. They seem to imply a connection between bit depth and
> bin count. Instead, you can just say that the bin count is dictated by
> the hardware design.
>
> I wonder if that is a future-proof assumption. I could easily expect
> that different histogram modes would use different bin counts, or
> produce multiple histograms (one per channel), or even 3D histograms.
> One also wouldn't want to use more bins than the signal has possible
> values.
Here we are not considering 3D, hence the name 1D LUT in the next patches.
> Just pondering. It's perilous to try to make UAPI generic if there is
> only one vendor or piece of hardware.
I had this series in i915 and based on the comment from the community
moved to drm with a generic UAPI. I assume histogram is supported by AMD
as well.
>>>> +
>>>> +/**
>>>> + * struct drm_histogram_config
>>>> + *
>>>> + * @hist_mode_data: address to the histogram mode specific data if any
>>> Do I understand correctly that the KMS blob will contain a userspace
>>> virtual memory address (a user pointer)? How does that work? What are
>>> the lifetime requirements for that memory?
>>>
>>> I do not remember any precedent of this, and I suspect it's not a good
>>> design. I believe all the data should be contained in the blobs, e.g.
>>> how IN_FORMATS does it. I'm not sure what would be the best UAPI here
>>> for returning histogram data to userspace, but at least all the data
>>> sent to the kernel should be contained in the blob itself since it
>>> seems to be quite small. Variable length is ok for blobs.
>> This point has actually opened up discussion on the design. Sima has
>> infact commented the same with multiple options and which among them
>> buits best. Lets take this discussion on that thread.
> Indeed, I don't know much about that topic.
>
>>>> + * @nr_hist_mode_data: number of elements pointed by the address in
>>>> + * hist_mode_data
>>>> + * @hist_mode: histogram mode(HSV max(RGB), RGB, LUMA etc)
>>>> + * @enable: flag to enable/disable histogram
>>>> + */
>>>> +struct drm_histogram_config {
>>>> + __u64 hist_mode_data;
>>>> + __u32 nr_hist_mode_data;
>>>> + enum drm_mode_histogram hist_mode;
>>>> + bool enable;
>>> Don't enum and bool have non-fixed sizes? Hence inappropriate as UABI,
>>> if architecture, build options, or the contents of the enum change the
>>> ABI.
>>>
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct drm_histogram
>>>> + *
>>>> + * @config: histogram configuration data pointed by struct drm_histogram_config
>>> s/pointed by/defined by/ I presume? That much is obvious from the field
>>> type. What does it mean? Why is struct drm_histogram_config a separate
>>> struct?
>> This is totally a separate property for enabling histogram. When
>> enabling histogram if there are multiple modes of histogram generation
>> supported by the hardware which among them will be used here and the
>> data for that mode if required(For Ex: weights for the RGB in case of
>> weighted RGB) would have to be sent from user and this struct
>> drm_histogram_config holds those elements.
> Ah, I missed that there is a KMS property holding only a config.
>
>>>> + * @data_ptr: pointer to the array of histogram.
>>>> + * Histogram is an array of bins. Data format for each bin depends
>>>> + * on the histogram mode. Refer to the above histogram modes for
>>>> + * more information.
>>> Another userspace virtual address stored in a KMS blob?
>>>
>>>> + * @nr_elements: number of bins in the histogram.
>>>> + */
>>>> +struct drm_histogram {
>>>> + struct drm_histogram_config config;
>>>> + __u64 data_ptr;
>>>> + __u32 nr_elements;
>>>> +};
>>>> +
>>>> #if defined(__cplusplus)
>>>> }
>>>> #endif
>>>>
> Thanks,
> pq
Thanks and Regards,
Arun R Murthy
--------------------
[-- Attachment #2: Type: text/html, Size: 17190 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-19 3:58 ` Murthy, Arun R
@ 2025-02-20 15:50 ` Pekka Paalanen
2025-03-03 7:53 ` Murthy, Arun R
0 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-02-20 15:50 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 6676 bytes --]
On Wed, 19 Feb 2025 09:28:51 +0530
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 18-02-2025 21:48, Pekka Paalanen wrote:
> > On Tue, 18 Feb 2025 11:13:39 +0530
> > "Murthy, Arun R"<arun.r.murthy@intel.com> wrote:
> >
> >> On 17-02-2025 15:38, Pekka Paalanen wrote:
> >>> Hi Arun,
> >>>
> >>> this whole series seems to be missing all the UAPI docs for the DRM
> >>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> >>> replacement for them, I would assume both are a requirement.
> >>>
> >>> Without the ReST docs it is really difficult to see how this new UAPI
> >>> should be used.
> >> Hi Pekka,
> >> I also realized later on this. Will add this in my next patchset.
> >>> On Tue, 28 Jan 2025 21:21:07 +0530
> >>> Arun R Murthy<arun.r.murthy@intel.com> wrote:
> >>>
> >>>> Display Histogram is an array of bins and can be generated in many ways
> >>>> referred to as modes.
> >>>> Ex: HSV max(RGB), Wighted RGB etc.
> >>>>
> >>>> Understanding the histogram data format(Ex: HSV max(RGB))
> >>>> Histogram is just the pixel count.
> >>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> >>>> 25 bits should be sufficient to represent this along with a buffer of 7
> >>>> bits(future use) u32 is being considered.
> >>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> >>>> bits, hence 32 bins.
> >>>> Below mentioned algorithm illustrates the histogram generation in
> >>>> hardware.
> >>>>
> >>>> hist[32] = {0};
> >>>> for (i = 0; i < resolution; i++) {
> >>>> bin = max(RGB[i]);
> >>>> bin = bin >> 3; /* consider the most significant bits */
> >>>> hist[bin]++;
> >>>> }
> >>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
> >>>> count of each pixels will be placed in the last bin. Hence except
> >>>> hist[31] all other bins will have a value zero.
> >>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
> >>>>
> >>>> Description of the structures, properties defined are documented in the
> >>>> header file include/uapi/drm/drm_mode.h
> >>>>
> >>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >>>>
> >>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
> >>>> ---
> >>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> >>>> 1 file changed, 65 insertions(+)
> >>>>
> >>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >>>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
> >>>> --- a/include/uapi/drm/drm_mode.h
> >>>> +++ b/include/uapi/drm/drm_mode.h
> >>>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> >>>> __u32 pad;
> >>>> };
> >>>>
> >>>> +/**
> >>>> + * enum drm_mode_histogram
> >>>> + *
> >>>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> >>>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
> >>>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
> >>>> + * can be a u32 value.
> >>>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
> >>> I assume s/SDL/SDR/.
> >> Yes, sorry TYPO
> >>> This assumption seems false. SDR can be also 10-bit and probably even
> >>> more.
> >> Yes but in practice majority of them being 8-bit. So have considered
> >> 8-bit for illustration purpose only.
> >> The design itself should accommodate 10-bit as well.
> > Hi Arun,
> >
> > if these are just examples, then there is no need to mention SDR or
> > HDR. You can say that if "thing" is 8-bit, then there are 256 possible
> > values, and we could have 256 bins or we could have just 32 bins.
> >
> > But what is "thing"? Let's see below.
> Sure will remove these over here and add then in the ReST document.
> >>>> + * If the most significant 5 bits are considered, then bins = 2^5
> >>>> + * will be 32 bins.
> >>>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> >>> Does this mean that the histogram is computed on the pixel values
> >>> emitted to the cable? What if the cable format is YUV?
> >> Yes, again the illustration over here is max(RGB) used for histogram
> >> generation.
> >> If YUV is used or weighted RGB is used for histogram generation then the
> >> mode will have to change and accordingly the data for that mode.
> > Do you mean that the HDMI or DisplayPort signalling mode (YUV vs. RGB?
> > sub-sampling? bit-depth?) affects which histogram modes can be used?
> No this is actually for user as to how to interpret the histogram data
> that is being sent from the KMD. UMD reads this histogram so in order to
> understand the format of this data he needs to know the histogram mode.
> > Currently userspace cannot know or control the signalling mode. How
> > would userspace know which histogram modes are possible?
> As part of drm_histogram_caps struct under HISTOGRAM_CAPS property KMD
> will expose all of the supported histogram modes to the user. User will
> then choose one among the supported modes by drm_histogram_config
> struct(HISTOGRAM_ENABLE property)
> > You should also define at which point of the pixel pipeline the
> > histogram is recorded. Is it before, say, CRTC DEGAMMA processing? Is
> > it after signal encoding to the 6/8/10/12/14/16-bit RGB or YUV format?
> > Before or after YUV sub-sampling? Limited or full range?
> This again is the hardware design. Theoretically this histogram hardware
> will be at the end of the hardware pipe, i.e after hardware/software
> composition is done.
Hi Arun,
sure, it may be by hardware design, but the UAPI must specify or
communicate exactly what it is. This seems to be the recurring theme in
all the remaining comments, so I trimmed them away.
A generic UAPI is mandatory, because that's KMS policy AFAIU. A generic
UAPI cannot key anything off of the hardware revision. Instead,
everything must be specified and communicated explicitly. It's good if
AMD has similar functionality, someone from their team could take a
look so you can come up with an UAPI that works for both.
Dmitry Baryshkov tried to ask for the same thing. Assuming I know
nothing about the hardware, and the only documentation I have is the
KMS UAPI documentation (userland side, not kernel internals), I should
be able to write a program from scratch that correctly records and
analyses the histogram on every piece of hardware where the kernel
driver exposes it. That means explaining exactly what the driver and the
hardware will do when I poke that UAPI.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-20 15:50 ` Pekka Paalanen
@ 2025-03-03 7:53 ` Murthy, Arun R
2025-03-03 9:20 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-03 7:53 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
On 20-02-2025 21:20, Pekka Paalanen wrote:
> On Wed, 19 Feb 2025 09:28:51 +0530
> "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
>
>> On 18-02-2025 21:48, Pekka Paalanen wrote:
>>> On Tue, 18 Feb 2025 11:13:39 +0530
>>> "Murthy, Arun R"<arun.r.murthy@intel.com> wrote:
>>>
>>>> On 17-02-2025 15:38, Pekka Paalanen wrote:
>>>>> Hi Arun,
>>>>>
>>>>> this whole series seems to be missing all the UAPI docs for the DRM
>>>>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>>>>> replacement for them, I would assume both are a requirement.
>>>>>
>>>>> Without the ReST docs it is really difficult to see how this new UAPI
>>>>> should be used.
>>>> Hi Pekka,
>>>> I also realized later on this. Will add this in my next patchset.
>>>>> On Tue, 28 Jan 2025 21:21:07 +0530
>>>>> Arun R Murthy<arun.r.murthy@intel.com> wrote:
>>>>>
>>>>>> Display Histogram is an array of bins and can be generated in many ways
>>>>>> referred to as modes.
>>>>>> Ex: HSV max(RGB), Wighted RGB etc.
>>>>>>
>>>>>> Understanding the histogram data format(Ex: HSV max(RGB))
>>>>>> Histogram is just the pixel count.
>>>>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
>>>>>> 25 bits should be sufficient to represent this along with a buffer of 7
>>>>>> bits(future use) u32 is being considered.
>>>>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
>>>>>> bits, hence 32 bins.
>>>>>> Below mentioned algorithm illustrates the histogram generation in
>>>>>> hardware.
>>>>>>
>>>>>> hist[32] = {0};
>>>>>> for (i = 0; i < resolution; i++) {
>>>>>> bin = max(RGB[i]);
>>>>>> bin = bin >> 3; /* consider the most significant bits */
>>>>>> hist[bin]++;
>>>>>> }
>>>>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
>>>>>> count of each pixels will be placed in the last bin. Hence except
>>>>>> hist[31] all other bins will have a value zero.
>>>>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>>>>>>
>>>>>> Description of the structures, properties defined are documented in the
>>>>>> header file include/uapi/drm/drm_mode.h
>>>>>>
>>>>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>>>>>>
>>>>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
>>>>>> ---
>>>>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 65 insertions(+)
>>>>>>
>>>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>>>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
>>>>>> --- a/include/uapi/drm/drm_mode.h
>>>>>> +++ b/include/uapi/drm/drm_mode.h
>>>>>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
>>>>>> __u32 pad;
>>>>>> };
>>>>>>
>>>>>> +/**
>>>>>> + * enum drm_mode_histogram
>>>>>> + *
>>>>>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
>>>>>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
>>>>>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
>>>>>> + * can be a u32 value.
>>>>>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>>>>> I assume s/SDL/SDR/.
>>>> Yes, sorry TYPO
>>>>> This assumption seems false. SDR can be also 10-bit and probably even
>>>>> more.
>>>> Yes but in practice majority of them being 8-bit. So have considered
>>>> 8-bit for illustration purpose only.
>>>> The design itself should accommodate 10-bit as well.
>>> Hi Arun,
>>>
>>> if these are just examples, then there is no need to mention SDR or
>>> HDR. You can say that if "thing" is 8-bit, then there are 256 possible
>>> values, and we could have 256 bins or we could have just 32 bins.
>>>
>>> But what is "thing"? Let's see below.
>> Sure will remove these over here and add then in the ReST document.
>>>>>> + * If the most significant 5 bits are considered, then bins = 2^5
>>>>>> + * will be 32 bins.
>>>>>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
>>>>> Does this mean that the histogram is computed on the pixel values
>>>>> emitted to the cable? What if the cable format is YUV?
>>>> Yes, again the illustration over here is max(RGB) used for histogram
>>>> generation.
>>>> If YUV is used or weighted RGB is used for histogram generation then the
>>>> mode will have to change and accordingly the data for that mode.
>>> Do you mean that the HDMI or DisplayPort signalling mode (YUV vs. RGB?
>>> sub-sampling? bit-depth?) affects which histogram modes can be used?
>> No this is actually for user as to how to interpret the histogram data
>> that is being sent from the KMD. UMD reads this histogram so in order to
>> understand the format of this data he needs to know the histogram mode.
>>> Currently userspace cannot know or control the signalling mode. How
>>> would userspace know which histogram modes are possible?
>> As part of drm_histogram_caps struct under HISTOGRAM_CAPS property KMD
>> will expose all of the supported histogram modes to the user. User will
>> then choose one among the supported modes by drm_histogram_config
>> struct(HISTOGRAM_ENABLE property)
>>> You should also define at which point of the pixel pipeline the
>>> histogram is recorded. Is it before, say, CRTC DEGAMMA processing? Is
>>> it after signal encoding to the 6/8/10/12/14/16-bit RGB or YUV format?
>>> Before or after YUV sub-sampling? Limited or full range?
>> This again is the hardware design. Theoretically this histogram hardware
>> will be at the end of the hardware pipe, i.e after hardware/software
>> composition is done.
> Hi Arun,
>
> sure, it may be by hardware design, but the UAPI must specify or
> communicate exactly what it is. This seems to be the recurring theme in
> all the remaining comments, so I trimmed them away.
>
> A generic UAPI is mandatory, because that's KMS policy AFAIU. A generic
> UAPI cannot key anything off of the hardware revision. Instead,
> everything must be specified and communicated explicitly. It's good if
> AMD has similar functionality, someone from their team could take a
> look so you can come up with an UAPI that works for both.
>
> Dmitry Baryshkov tried to ask for the same thing. Assuming I know
> nothing about the hardware, and the only documentation I have is the
> KMS UAPI documentation (userland side, not kernel internals), I should
> be able to write a program from scratch that correctly records and
> analyses the histogram on every piece of hardware where the kernel
> driver exposes it. That means explaining exactly what the driver and the
> hardware will do when I poke that UAPI.
Hi Pekka,
Sorry got getting back late on this.
I totally agree that the UAPI should not be any hardware specific and
have taken care to get rid of such if any.
Here we are just exposing the histogram data and what point is the
histogram generated is out of the scope. Generated histogram is exposed
to the user. Please let me know if anything is hardware specific, will
change it.
I feel the rst documentation as suggested is missing and is creating the
gap. Can I go ahead create the rst documentation and then repost the
series and then we can continue the review?
Thanks and Regards,
Arun R Murthy
--------------------
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-03 7:53 ` Murthy, Arun R
@ 2025-03-03 9:20 ` Pekka Paalanen
2025-03-19 12:08 ` Murthy, Arun R
0 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-03-03 9:20 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe, intel-gfx, dri-devel, suraj.kandpal, dmitry.baryshkov
[-- Attachment #1: Type: text/plain, Size: 5476 bytes --]
On Mon, 3 Mar 2025 13:23:42 +0530
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> On 20-02-2025 21:20, Pekka Paalanen wrote:
> > On Wed, 19 Feb 2025 09:28:51 +0530
> > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> >
> >> On 18-02-2025 21:48, Pekka Paalanen wrote:
> >>> On Tue, 18 Feb 2025 11:13:39 +0530
> >>> "Murthy, Arun R"<arun.r.murthy@intel.com> wrote:
> >>>
> >>>> On 17-02-2025 15:38, Pekka Paalanen wrote:
> >>>>> Hi Arun,
> >>>>>
> >>>>> this whole series seems to be missing all the UAPI docs for the DRM
> >>>>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> >>>>> replacement for them, I would assume both are a requirement.
> >>>>>
> >>>>> Without the ReST docs it is really difficult to see how this new UAPI
> >>>>> should be used.
> >>>> Hi Pekka,
> >>>> I also realized later on this. Will add this in my next patchset.
> >>>>> On Tue, 28 Jan 2025 21:21:07 +0530
> >>>>> Arun R Murthy<arun.r.murthy@intel.com> wrote:
> >>>>>
> >>>>>> Display Histogram is an array of bins and can be generated in many ways
> >>>>>> referred to as modes.
> >>>>>> Ex: HSV max(RGB), Wighted RGB etc.
> >>>>>>
> >>>>>> Understanding the histogram data format(Ex: HSV max(RGB))
> >>>>>> Histogram is just the pixel count.
> >>>>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> >>>>>> 25 bits should be sufficient to represent this along with a buffer of 7
> >>>>>> bits(future use) u32 is being considered.
> >>>>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> >>>>>> bits, hence 32 bins.
> >>>>>> Below mentioned algorithm illustrates the histogram generation in
> >>>>>> hardware.
> >>>>>>
> >>>>>> hist[32] = {0};
> >>>>>> for (i = 0; i < resolution; i++) {
> >>>>>> bin = max(RGB[i]);
> >>>>>> bin = bin >> 3; /* consider the most significant bits */
> >>>>>> hist[bin]++;
> >>>>>> }
> >>>>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
> >>>>>> count of each pixels will be placed in the last bin. Hence except
> >>>>>> hist[31] all other bins will have a value zero.
> >>>>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
> >>>>>>
> >>>>>> Description of the structures, properties defined are documented in the
> >>>>>> header file include/uapi/drm/drm_mode.h
> >>>>>>
> >>>>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> >>>>>>
> >>>>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
> >>>>>> ---
> >>>>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> >>>>>> 1 file changed, 65 insertions(+)
...
> > Hi Arun,
> >
> > sure, it may be by hardware design, but the UAPI must specify or
> > communicate exactly what it is. This seems to be the recurring theme in
> > all the remaining comments, so I trimmed them away.
> >
> > A generic UAPI is mandatory, because that's KMS policy AFAIU. A generic
> > UAPI cannot key anything off of the hardware revision. Instead,
> > everything must be specified and communicated explicitly. It's good if
> > AMD has similar functionality, someone from their team could take a
> > look so you can come up with an UAPI that works for both.
> >
> > Dmitry Baryshkov tried to ask for the same thing. Assuming I know
> > nothing about the hardware, and the only documentation I have is the
> > KMS UAPI documentation (userland side, not kernel internals), I should
> > be able to write a program from scratch that correctly records and
> > analyses the histogram on every piece of hardware where the kernel
> > driver exposes it. That means explaining exactly what the driver and the
> > hardware will do when I poke that UAPI.
>
> Hi Pekka,
> Sorry got getting back late on this.
> I totally agree that the UAPI should not be any hardware specific and
> have taken care to get rid of such if any.
> Here we are just exposing the histogram data and what point is the
> histogram generated is out of the scope.
It's not out of scope. Understanding exactly at what point the
histogram is generated in the KMS pixel pipeline is paramount to being
able to use the results correctly - how it relates to the framebuffers'
contents and KMS pixel pipeline configuration.
As a simple example, if the histogram is recorded before CRTC GAMMA
processing, then changing CRTC GAMMA will not change the histogram. Or,
if the histogram is recorded after CRTC GAMMA processing, then changing
CRTC GAMMA will change the histogram as well, assuming the content
stays the same. This makes a fundamental difference to how the
histogram results should be looked at. Userspace needs to know whether
the differences in the histogram over time are caused by changes in the
content or by changes driven by the userspace itself.
In the CRTC GAMMA example, it's not just whether changing GAMMA
directly changes the histogram. GAMMA also changes the units on the
x-axis of the histogram, are they optical or electrical for instance.
Those units are important, too, because the ideal target histogram has a
very different shape depending on the units.
> I feel the rst documentation as suggested is missing and is creating the
> gap. Can I go ahead create the rst documentation and then repost the
> series and then we can continue the review?
I'm not sure why you are asking? Of course, I guess.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-03 9:20 ` Pekka Paalanen
@ 2025-03-19 12:08 ` Murthy, Arun R
2025-03-20 9:23 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-19 12:08 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj
> On Mon, 3 Mar 2025 13:23:42 +0530
> "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
>
> > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > On Wed, 19 Feb 2025 09:28:51 +0530
> > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > >
> > >> On 18-02-2025 21:48, Pekka Paalanen wrote:
> > >>> On Tue, 18 Feb 2025 11:13:39 +0530 "Murthy, Arun
> > >>> R"<arun.r.murthy@intel.com> wrote:
> > >>>
> > >>>> On 17-02-2025 15:38, Pekka Paalanen wrote:
> > >>>>> Hi Arun,
> > >>>>>
> > >>>>> this whole series seems to be missing all the UAPI docs for the
> > >>>>> DRM ReST files, e.g. drm-kms.rst. The UAPI header doc comments
> > >>>>> are not a replacement for them, I would assume both are a
> requirement.
> > >>>>>
> > >>>>> Without the ReST docs it is really difficult to see how this new
> > >>>>> UAPI should be used.
> > >>>> Hi Pekka,
> > >>>> I also realized later on this. Will add this in my next patchset.
> > >>>>> On Tue, 28 Jan 2025 21:21:07 +0530 Arun R
> > >>>>> Murthy<arun.r.murthy@intel.com> wrote:
> > >>>>>
> > >>>>>> Display Histogram is an array of bins and can be generated in
> > >>>>>> many ways referred to as modes.
> > >>>>>> Ex: HSV max(RGB), Wighted RGB etc.
> > >>>>>>
> > >>>>>> Understanding the histogram data format(Ex: HSV max(RGB))
> > >>>>>> Histogram is just the pixel count.
> > >>>>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > >>>>>> 25 bits should be sufficient to represent this along with a
> > >>>>>> buffer of 7 bits(future use) u32 is being considered.
> > >>>>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most
> > >>>>>> significant 5 bits, hence 32 bins.
> > >>>>>> Below mentioned algorithm illustrates the histogram generation
> > >>>>>> in hardware.
> > >>>>>>
> > >>>>>> hist[32] = {0};
> > >>>>>> for (i = 0; i < resolution; i++) {
> > >>>>>> bin = max(RGB[i]);
> > >>>>>> bin = bin >> 3; /* consider the most significant bits */
> > >>>>>> hist[bin]++;
> > >>>>>> }
> > >>>>>> If the entire image is Red color then max(255,0,0) is 255 so
> > >>>>>> the pixel count of each pixels will be placed in the last bin.
> > >>>>>> Hence except hist[31] all other bins will have a value zero.
> > >>>>>> Generated histogram in this case would be hist[32] =
> > >>>>>> {0,0,....44236800}
> > >>>>>>
> > >>>>>> Description of the structures, properties defined are
> > >>>>>> documented in the header file include/uapi/drm/drm_mode.h
> > >>>>>>
> > >>>>>> v8: Added doc for HDR planes, removed reserved variables
> > >>>>>> (Dmitry)
> > >>>>>>
> > >>>>>> Signed-off-by: Arun R Murthy<arun.r.murthy@intel.com>
> > >>>>>> ---
> > >>>>>> include/uapi/drm/drm_mode.h | 65
> +++++++++++++++++++++++++++++++++++++++++++++
> > >>>>>> 1 file changed, 65 insertions(+)
>
> ...
>
> > > Hi Arun,
> > >
> > > sure, it may be by hardware design, but the UAPI must specify or
> > > communicate exactly what it is. This seems to be the recurring theme
> > > in all the remaining comments, so I trimmed them away.
> > >
> > > A generic UAPI is mandatory, because that's KMS policy AFAIU. A
> > > generic UAPI cannot key anything off of the hardware revision.
> > > Instead, everything must be specified and communicated explicitly.
> > > It's good if AMD has similar functionality, someone from their team
> > > could take a look so you can come up with an UAPI that works for both.
> > >
> > > Dmitry Baryshkov tried to ask for the same thing. Assuming I know
> > > nothing about the hardware, and the only documentation I have is the
> > > KMS UAPI documentation (userland side, not kernel internals), I
> > > should be able to write a program from scratch that correctly
> > > records and analyses the histogram on every piece of hardware where
> > > the kernel driver exposes it. That means explaining exactly what the
> > > driver and the hardware will do when I poke that UAPI.
> >
> > Hi Pekka,
> > Sorry got getting back late on this.
> > I totally agree that the UAPI should not be any hardware specific and
> > have taken care to get rid of such if any.
> > Here we are just exposing the histogram data and what point is the
> > histogram generated is out of the scope.
>
> It's not out of scope. Understanding exactly at what point the histogram is
> generated in the KMS pixel pipeline is paramount to being able to use the
> results correctly - how it relates to the framebuffers'
> contents and KMS pixel pipeline configuration.
>
While working around this comment, it looks to be quite challenging to
address this comment and agree that this will have to be addressed and is
important for the user to know at which point in the pixel pipeline configuration
the histogram is generated.
I can think of 2 options on addressing this.
1. Have this documented in the driver. Since this can vary on each vendor
hardware, can have this documented in the drivers or ReST document.
2. Maybe have a bitmapping like we have it for histogram_mode. Define
user readable macros for that.
Ex: CC1_DEGAMMA_HIST_CC2
In this case histogram is between the two color conversion hardware block
in the pixel pipeline.
This macro will have to be defined on need basis and define a u32 variable
for this bit manipulation.
Please let me know your opinion on this.
Thanks and Regards,
Arun R Murthy
--------------------
> As a simple example, if the histogram is recorded before CRTC GAMMA
> processing, then changing CRTC GAMMA will not change the histogram. Or, if
> the histogram is recorded after CRTC GAMMA processing, then changing CRTC
> GAMMA will change the histogram as well, assuming the content stays the
> same. This makes a fundamental difference to how the histogram results should
> be looked at. Userspace needs to know whether the differences in the
> histogram over time are caused by changes in the content or by changes driven
> by the userspace itself.
>
> In the CRTC GAMMA example, it's not just whether changing GAMMA directly
> changes the histogram. GAMMA also changes the units on the x-axis of the
> histogram, are they optical or electrical for instance.
> Those units are important, too, because the ideal target histogram has a very
> different shape depending on the units.
>
> > I feel the rst documentation as suggested is missing and is creating
> > the gap. Can I go ahead create the rst documentation and then repost
> > the series and then we can continue the review?
>
> I'm not sure why you are asking? Of course, I guess.
>
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-19 12:08 ` Murthy, Arun R
@ 2025-03-20 9:23 ` Pekka Paalanen
2025-03-26 6:03 ` Murthy, Arun R
0 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-03-20 9:23 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj, harry.wentland,
alex.hung
[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]
On Wed, 19 Mar 2025 12:08:15 +0000
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > On Mon, 3 Mar 2025 13:23:42 +0530
> > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> >
> > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > On Wed, 19 Feb 2025 09:28:51 +0530
> > > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
...
> > > Hi Pekka,
> > > Sorry got getting back late on this.
> > > I totally agree that the UAPI should not be any hardware specific and
> > > have taken care to get rid of such if any.
> > > Here we are just exposing the histogram data and what point is the
> > > histogram generated is out of the scope.
> >
> > It's not out of scope. Understanding exactly at what point the histogram is
> > generated in the KMS pixel pipeline is paramount to being able to use the
> > results correctly - how it relates to the framebuffers'
> > contents and KMS pixel pipeline configuration.
> >
>
> While working around this comment, it looks to be quite challenging to
> address this comment and agree that this will have to be addressed and is
> important for the user to know at which point in the pixel pipeline configuration
> the histogram is generated.
> I can think of 2 options on addressing this.
>
> 1. Have this documented in the driver. Since this can vary on each vendor
> hardware, can have this documented in the drivers or ReST document.
>
Hi Arun,
this is not acceptable in KMS, because it requires userspace to have
code that depends on the hardware revision or identity. When new
hardware appears, it will not be enough to update the drivers, one will
also need to update userspace. There currently is no userspace
"standard KMS library" to abstract all drivers further, like there is
libcamera and Mesa.
> 2. Maybe have a bitmapping like we have it for histogram_mode. Define
> user readable macros for that.
> Ex: CC1_DEGAMMA_HIST_CC2
> In this case histogram is between the two color conversion hardware block
> in the pixel pipeline.
> This macro will have to be defined on need basis and define a u32 variable
> for this bit manipulation.
This one still has problems in that some hardware may not have all the
non-HIST elements or not in the same order. It's a better abstraction
than option 1, but it's still weak.
I can see one solid solution, but it won't be usable for quite some
time I suppose:
https://lore.kernel.org/dri-devel/20241220043410.416867-5-alex.hung@amd.com/
The current work on the color pipelines UAPI is concentrated on the
per-plane operations. The idea is that once those are hashed out, the
same design is applied to CRTCs as well, deprecating all existing CRTC
color processing properties. A histogram processing element could be
exposed as a colorop object, and its position in a CRTC color pipeline
represents the point where the histogram is collected.
That would be the best possible UAPI design on current knowledge in my
opinion.
Btw. this applies also to the image enhancement processing element you
are proposing.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-20 9:23 ` Pekka Paalanen
@ 2025-03-26 6:03 ` Murthy, Arun R
2025-03-27 8:59 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-26 6:03 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj,
harry.wentland@amd.com, alex.hung@amd.com
> On Wed, 19 Mar 2025 12:08:15 +0000
> "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
>
> > > On Mon, 3 Mar 2025 13:23:42 +0530
> > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > >
> > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > <arun.r.murthy@intel.com> wrote:
>
> ...
>
> > > > Hi Pekka,
> > > > Sorry got getting back late on this.
> > > > I totally agree that the UAPI should not be any hardware specific
> > > > and have taken care to get rid of such if any.
> > > > Here we are just exposing the histogram data and what point is the
> > > > histogram generated is out of the scope.
> > >
> > > It's not out of scope. Understanding exactly at what point the
> > > histogram is generated in the KMS pixel pipeline is paramount to
> > > being able to use the results correctly - how it relates to the framebuffers'
> > > contents and KMS pixel pipeline configuration.
> > >
> >
> > While working around this comment, it looks to be quite challenging to
> > address this comment and agree that this will have to be addressed and
> > is important for the user to know at which point in the pixel pipeline
> > configuration the histogram is generated.
> > I can think of 2 options on addressing this.
> >
> > 1. Have this documented in the driver. Since this can vary on each
> > vendor hardware, can have this documented in the drivers or ReST document.
> >
>
> Hi Arun,
>
> this is not acceptable in KMS, because it requires userspace to have code that
> depends on the hardware revision or identity. When new hardware appears, it
> will not be enough to update the drivers, one will also need to update
> userspace. There currently is no userspace "standard KMS library" to abstract
> all drivers further, like there is libcamera and Mesa.
>
> > 2. Maybe have a bitmapping like we have it for histogram_mode. Define
> > user readable macros for that.
> > Ex: CC1_DEGAMMA_HIST_CC2
> > In this case histogram is between the two color conversion hardware
> > block in the pixel pipeline.
> > This macro will have to be defined on need basis and define a u32
> > variable for this bit manipulation.
>
> This one still has problems in that some hardware may not have all the non-
> HIST elements or not in the same order. It's a better abstraction than option 1,
> but it's still weak.
>
> I can see one solid solution, but it won't be usable for quite some time I
> suppose:
>
> https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> alex.hung@amd.com/
>
> The current work on the color pipelines UAPI is concentrated on the per-plane
> operations. The idea is that once those are hashed out, the same design is
> applied to CRTCs as well, deprecating all existing CRTC color processing
> properties. A histogram processing element could be exposed as a colorop
> object, and its position in a CRTC color pipeline represents the point where the
> histogram is collected.
>
> That would be the best possible UAPI design on current knowledge in my
> opinion.
>
Yes this would be the best design, but looking into the timeline for this CRTC
color pipeline can we proceed with this as in interim solution.
Once we have the CRTC color pipeline in drm, will rebase this histogram to
make use of the pipeline.
We can also take up the crtc color pipeline and will also start contributing
to get things faster but since there is not timeline defined for that activity,
would it be viable to go ahead with option2 as in interim solution?
Thanks and Regards,
Arun R Murthy
-------------------
> Btw. this applies also to the image enhancement processing element you are
> proposing.
>
>
> Thanks,
> pq
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-26 6:03 ` Murthy, Arun R
@ 2025-03-27 8:59 ` Pekka Paalanen
2025-03-28 5:06 ` Murthy, Arun R
0 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-03-27 8:59 UTC (permalink / raw)
To: Murthy, Arun R
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj,
harry.wentland@amd.com, alex.hung@amd.com
[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]
On Wed, 26 Mar 2025 06:03:27 +0000
"Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > On Wed, 19 Mar 2025 12:08:15 +0000
> > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> >
> > > > On Mon, 3 Mar 2025 13:23:42 +0530
> > > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > > >
> > > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > > <arun.r.murthy@intel.com> wrote:
> >
> > ...
> >
> > > > > Hi Pekka,
> > > > > Sorry got getting back late on this.
> > > > > I totally agree that the UAPI should not be any hardware specific
> > > > > and have taken care to get rid of such if any.
> > > > > Here we are just exposing the histogram data and what point is the
> > > > > histogram generated is out of the scope.
> > > >
> > > > It's not out of scope. Understanding exactly at what point the
> > > > histogram is generated in the KMS pixel pipeline is paramount to
> > > > being able to use the results correctly - how it relates to the framebuffers'
> > > > contents and KMS pixel pipeline configuration.
> > > >
> > >
> > > While working around this comment, it looks to be quite challenging to
> > > address this comment and agree that this will have to be addressed and
> > > is important for the user to know at which point in the pixel pipeline
> > > configuration the histogram is generated.
> > > I can think of 2 options on addressing this.
> > >
> > > 1. Have this documented in the driver. Since this can vary on each
> > > vendor hardware, can have this documented in the drivers or ReST document.
> > >
> >
> > Hi Arun,
> >
> > this is not acceptable in KMS, because it requires userspace to have code that
> > depends on the hardware revision or identity. When new hardware appears, it
> > will not be enough to update the drivers, one will also need to update
> > userspace. There currently is no userspace "standard KMS library" to abstract
> > all drivers further, like there is libcamera and Mesa.
> >
> > > 2. Maybe have a bitmapping like we have it for histogram_mode. Define
> > > user readable macros for that.
> > > Ex: CC1_DEGAMMA_HIST_CC2
> > > In this case histogram is between the two color conversion hardware
> > > block in the pixel pipeline.
> > > This macro will have to be defined on need basis and define a u32
> > > variable for this bit manipulation.
> >
> > This one still has problems in that some hardware may not have all the non-
> > HIST elements or not in the same order. It's a better abstraction than option 1,
> > but it's still weak.
> >
> > I can see one solid solution, but it won't be usable for quite some time I
> > suppose:
> >
> > https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> > alex.hung@amd.com/
> >
> > The current work on the color pipelines UAPI is concentrated on the per-plane
> > operations. The idea is that once those are hashed out, the same design is
> > applied to CRTCs as well, deprecating all existing CRTC color processing
> > properties. A histogram processing element could be exposed as a colorop
> > object, and its position in a CRTC color pipeline represents the point where the
> > histogram is collected.
> >
> > That would be the best possible UAPI design on current knowledge in my
> > opinion.
> >
> Yes this would be the best design, but looking into the timeline for this CRTC
> color pipeline can we proceed with this as in interim solution.
> Once we have the CRTC color pipeline in drm, will rebase this histogram to
> make use of the pipeline.
> We can also take up the crtc color pipeline and will also start contributing
> to get things faster but since there is not timeline defined for that activity,
> would it be viable to go ahead with option2 as in interim solution?
Hi Arun,
I think that's something the DRM maintainers should chime in on.
Thanks,
pq
> > Btw. this applies also to the image enhancement processing element you are
> > proposing.
> >
> >
> > Thanks,
> > pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-27 8:59 ` Pekka Paalanen
@ 2025-03-28 5:06 ` Murthy, Arun R
2025-04-17 6:31 ` Shankar, Uma
0 siblings, 1 reply; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-28 5:06 UTC (permalink / raw)
To: Pekka Paalanen
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj,
harry.wentland@amd.com, alex.hung@amd.com, Vetter, Simona,
airlied@gmail.com
> On Wed, 26 Mar 2025 06:03:27 +0000
> "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
>
> > > On Wed, 19 Mar 2025 12:08:15 +0000
> > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > >
> > > > > On Mon, 3 Mar 2025 13:23:42 +0530 "Murthy, Arun R"
> > > > > <arun.r.murthy@intel.com> wrote:
> > > > >
> > > > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > > > <arun.r.murthy@intel.com> wrote:
> > >
> > > ...
> > >
> > > > > > Hi Pekka,
> > > > > > Sorry got getting back late on this.
> > > > > > I totally agree that the UAPI should not be any hardware
> > > > > > specific and have taken care to get rid of such if any.
> > > > > > Here we are just exposing the histogram data and what point is
> > > > > > the histogram generated is out of the scope.
> > > > >
> > > > > It's not out of scope. Understanding exactly at what point the
> > > > > histogram is generated in the KMS pixel pipeline is paramount to
> > > > > being able to use the results correctly - how it relates to the
> framebuffers'
> > > > > contents and KMS pixel pipeline configuration.
> > > > >
> > > >
> > > > While working around this comment, it looks to be quite
> > > > challenging to address this comment and agree that this will have
> > > > to be addressed and is important for the user to know at which
> > > > point in the pixel pipeline configuration the histogram is generated.
> > > > I can think of 2 options on addressing this.
> > > >
> > > > 1. Have this documented in the driver. Since this can vary on
> > > > each vendor hardware, can have this documented in the drivers or ReST
> document.
> > > >
> > >
> > > Hi Arun,
> > >
> > > this is not acceptable in KMS, because it requires userspace to have
> > > code that depends on the hardware revision or identity. When new
> > > hardware appears, it will not be enough to update the drivers, one
> > > will also need to update userspace. There currently is no userspace
> > > "standard KMS library" to abstract all drivers further, like there is libcamera
> and Mesa.
> > >
> > > > 2. Maybe have a bitmapping like we have it for histogram_mode.
> > > > Define user readable macros for that.
> > > > Ex: CC1_DEGAMMA_HIST_CC2
> > > > In this case histogram is between the two color conversion
> > > > hardware block in the pixel pipeline.
> > > > This macro will have to be defined on need basis and define a u32
> > > > variable for this bit manipulation.
> > >
> > > This one still has problems in that some hardware may not have all
> > > the non- HIST elements or not in the same order. It's a better
> > > abstraction than option 1, but it's still weak.
> > >
> > > I can see one solid solution, but it won't be usable for quite some
> > > time I
> > > suppose:
> > >
> > > https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> > > alex.hung@amd.com/
> > >
> > > The current work on the color pipelines UAPI is concentrated on the
> > > per-plane operations. The idea is that once those are hashed out,
> > > the same design is applied to CRTCs as well, deprecating all
> > > existing CRTC color processing properties. A histogram processing
> > > element could be exposed as a colorop object, and its position in a
> > > CRTC color pipeline represents the point where the histogram is collected.
> > >
> > > That would be the best possible UAPI design on current knowledge in
> > > my opinion.
> > >
> > Yes this would be the best design, but looking into the timeline for
> > this CRTC color pipeline can we proceed with this as in interim solution.
> > Once we have the CRTC color pipeline in drm, will rebase this
> > histogram to make use of the pipeline.
> > We can also take up the crtc color pipeline and will also start
> > contributing to get things faster but since there is not timeline
> > defined for that activity, would it be viable to go ahead with option2 as in
> interim solution?
>
> Hi Arun,
>
> I think that's something the DRM maintainers should chime in on.
>
>
> Thanks,
> pq
>
drm Maintainers, any inputs on this?
Thanks and Regards,
Arun R Murthy
--------------------
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-03-28 5:06 ` Murthy, Arun R
@ 2025-04-17 6:31 ` Shankar, Uma
2025-04-17 7:18 ` Pekka Paalanen
0 siblings, 1 reply; 58+ messages in thread
From: Shankar, Uma @ 2025-04-17 6:31 UTC (permalink / raw)
To: Murthy, Arun R, Pekka Paalanen
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, Kandpal, Suraj,
harry.wentland@amd.com, alex.hung@amd.com, Vetter, Simona,
airlied@gmail.com
> -----Original Message-----
> From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Murthy,
> Arun R
> Sent: Friday, March 28, 2025 10:36 AM
> To: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
> Cc: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org; Kandpal, Suraj <suraj.kandpal@intel.com>;
> harry.wentland@amd.com; alex.hung@amd.com; Vetter, Simona
> <simona.vetter@intel.com>; airlied@gmail.com
> Subject: RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
>
> > On Wed, 26 Mar 2025 06:03:27 +0000
> > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> >
> > > > On Wed, 19 Mar 2025 12:08:15 +0000 "Murthy, Arun R"
> > > > <arun.r.murthy@intel.com> wrote:
> > > >
> > > > > > On Mon, 3 Mar 2025 13:23:42 +0530 "Murthy, Arun R"
> > > > > > <arun.r.murthy@intel.com> wrote:
> > > > > >
> > > > > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > > > > <arun.r.murthy@intel.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > Hi Pekka,
> > > > > > > Sorry got getting back late on this.
> > > > > > > I totally agree that the UAPI should not be any hardware
> > > > > > > specific and have taken care to get rid of such if any.
> > > > > > > Here we are just exposing the histogram data and what point
> > > > > > > is the histogram generated is out of the scope.
> > > > > >
> > > > > > It's not out of scope. Understanding exactly at what point the
> > > > > > histogram is generated in the KMS pixel pipeline is paramount
> > > > > > to being able to use the results correctly - how it relates to
> > > > > > the
> > framebuffers'
> > > > > > contents and KMS pixel pipeline configuration.
> > > > > >
> > > > >
> > > > > While working around this comment, it looks to be quite
> > > > > challenging to address this comment and agree that this will
> > > > > have to be addressed and is important for the user to know at
> > > > > which point in the pixel pipeline configuration the histogram is generated.
> > > > > I can think of 2 options on addressing this.
> > > > >
> > > > > 1. Have this documented in the driver. Since this can vary on
> > > > > each vendor hardware, can have this documented in the drivers or
> > > > > ReST
> > document.
> > > > >
> > > >
> > > > Hi Arun,
> > > >
> > > > this is not acceptable in KMS, because it requires userspace to
> > > > have code that depends on the hardware revision or identity. When
> > > > new hardware appears, it will not be enough to update the drivers,
> > > > one will also need to update userspace. There currently is no
> > > > userspace "standard KMS library" to abstract all drivers further,
> > > > like there is libcamera
> > and Mesa.
> > > >
> > > > > 2. Maybe have a bitmapping like we have it for histogram_mode.
> > > > > Define user readable macros for that.
> > > > > Ex: CC1_DEGAMMA_HIST_CC2
> > > > > In this case histogram is between the two color conversion
> > > > > hardware block in the pixel pipeline.
> > > > > This macro will have to be defined on need basis and define a
> > > > > u32 variable for this bit manipulation.
> > > >
> > > > This one still has problems in that some hardware may not have all
> > > > the non- HIST elements or not in the same order. It's a better
> > > > abstraction than option 1, but it's still weak.
> > > >
> > > > I can see one solid solution, but it won't be usable for quite
> > > > some time I
> > > > suppose:
> > > >
> > > > https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> > > > alex.hung@amd.com/
> > > >
> > > > The current work on the color pipelines UAPI is concentrated on
> > > > the per-plane operations. The idea is that once those are hashed
> > > > out, the same design is applied to CRTCs as well, deprecating all
> > > > existing CRTC color processing properties. A histogram processing
> > > > element could be exposed as a colorop object, and its position in
> > > > a CRTC color pipeline represents the point where the histogram is collected.
> > > >
> > > > That would be the best possible UAPI design on current knowledge
> > > > in my opinion.
> > > >
> > > Yes this would be the best design, but looking into the timeline for
> > > this CRTC color pipeline can we proceed with this as in interim solution.
> > > Once we have the CRTC color pipeline in drm, will rebase this
> > > histogram to make use of the pipeline.
> > > We can also take up the crtc color pipeline and will also start
> > > contributing to get things faster but since there is not timeline
> > > defined for that activity, would it be viable to go ahead with
> > > option2 as in
> > interim solution?
> >
> > Hi Arun,
> >
> > I think that's something the DRM maintainers should chime in on.
As a first step, I think we can expose the Histogram through the property.
We can later hook this into the crtc color pipeline once we implement it.
A userspace implementation showing end to end benefit of the feature and
usecase would be needed. Hope this is ok and no strong objection to this
approach.
Regards,
Uma Shankar
> >
> > Thanks,
> > pq
> >
> drm Maintainers, any inputs on this?
>
> Thanks and Regards,
> Arun R Murthy
> --------------------
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-04-17 6:31 ` Shankar, Uma
@ 2025-04-17 7:18 ` Pekka Paalanen
2025-04-17 10:50 ` Shankar, Uma
0 siblings, 1 reply; 58+ messages in thread
From: Pekka Paalanen @ 2025-04-17 7:18 UTC (permalink / raw)
To: Shankar, Uma
Cc: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Kandpal, Suraj, harry.wentland@amd.com, alex.hung@amd.com,
Vetter, Simona, airlied@gmail.com
[-- Attachment #1: Type: text/plain, Size: 5728 bytes --]
On Thu, 17 Apr 2025 06:31:21 +0000
"Shankar, Uma" <uma.shankar@intel.com> wrote:
> > -----Original Message-----
> > From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Murthy,
> > Arun R
> > Sent: Friday, March 28, 2025 10:36 AM
> > To: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
> > Cc: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> > devel@lists.freedesktop.org; Kandpal, Suraj <suraj.kandpal@intel.com>;
> > harry.wentland@amd.com; alex.hung@amd.com; Vetter, Simona
> > <simona.vetter@intel.com>; airlied@gmail.com
> > Subject: RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
> >
> > > On Wed, 26 Mar 2025 06:03:27 +0000
> > > "Murthy, Arun R" <arun.r.murthy@intel.com> wrote:
> > >
> > > > > On Wed, 19 Mar 2025 12:08:15 +0000 "Murthy, Arun R"
> > > > > <arun.r.murthy@intel.com> wrote:
> > > > >
> > > > > > > On Mon, 3 Mar 2025 13:23:42 +0530 "Murthy, Arun R"
> > > > > > > <arun.r.murthy@intel.com> wrote:
> > > > > > >
> > > > > > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > > > > > <arun.r.murthy@intel.com> wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > > > Hi Pekka,
> > > > > > > > Sorry got getting back late on this.
> > > > > > > > I totally agree that the UAPI should not be any hardware
> > > > > > > > specific and have taken care to get rid of such if any.
> > > > > > > > Here we are just exposing the histogram data and what point
> > > > > > > > is the histogram generated is out of the scope.
> > > > > > >
> > > > > > > It's not out of scope. Understanding exactly at what point the
> > > > > > > histogram is generated in the KMS pixel pipeline is paramount
> > > > > > > to being able to use the results correctly - how it relates to
> > > > > > > the
> > > framebuffers'
> > > > > > > contents and KMS pixel pipeline configuration.
> > > > > > >
> > > > > >
> > > > > > While working around this comment, it looks to be quite
> > > > > > challenging to address this comment and agree that this will
> > > > > > have to be addressed and is important for the user to know at
> > > > > > which point in the pixel pipeline configuration the histogram is generated.
> > > > > > I can think of 2 options on addressing this.
> > > > > >
> > > > > > 1. Have this documented in the driver. Since this can vary on
> > > > > > each vendor hardware, can have this documented in the drivers or
> > > > > > ReST
> > > document.
> > > > > >
> > > > >
> > > > > Hi Arun,
> > > > >
> > > > > this is not acceptable in KMS, because it requires userspace to
> > > > > have code that depends on the hardware revision or identity. When
> > > > > new hardware appears, it will not be enough to update the drivers,
> > > > > one will also need to update userspace. There currently is no
> > > > > userspace "standard KMS library" to abstract all drivers further,
> > > > > like there is libcamera
> > > and Mesa.
> > > > >
> > > > > > 2. Maybe have a bitmapping like we have it for histogram_mode.
> > > > > > Define user readable macros for that.
> > > > > > Ex: CC1_DEGAMMA_HIST_CC2
> > > > > > In this case histogram is between the two color conversion
> > > > > > hardware block in the pixel pipeline.
> > > > > > This macro will have to be defined on need basis and define a
> > > > > > u32 variable for this bit manipulation.
> > > > >
> > > > > This one still has problems in that some hardware may not have all
> > > > > the non- HIST elements or not in the same order. It's a better
> > > > > abstraction than option 1, but it's still weak.
> > > > >
> > > > > I can see one solid solution, but it won't be usable for quite
> > > > > some time I
> > > > > suppose:
> > > > >
> > > > > https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> > > > > alex.hung@amd.com/
> > > > >
> > > > > The current work on the color pipelines UAPI is concentrated on
> > > > > the per-plane operations. The idea is that once those are hashed
> > > > > out, the same design is applied to CRTCs as well, deprecating all
> > > > > existing CRTC color processing properties. A histogram processing
> > > > > element could be exposed as a colorop object, and its position in
> > > > > a CRTC color pipeline represents the point where the histogram is collected.
> > > > >
> > > > > That would be the best possible UAPI design on current knowledge
> > > > > in my opinion.
> > > > >
> > > > Yes this would be the best design, but looking into the timeline for
> > > > this CRTC color pipeline can we proceed with this as in interim solution.
> > > > Once we have the CRTC color pipeline in drm, will rebase this
> > > > histogram to make use of the pipeline.
> > > > We can also take up the crtc color pipeline and will also start
> > > > contributing to get things faster but since there is not timeline
> > > > defined for that activity, would it be viable to go ahead with
> > > > option2 as in
> > > interim solution?
> > >
> > > Hi Arun,
> > >
> > > I think that's something the DRM maintainers should chime in on.
>
> As a first step, I think we can expose the Histogram through the property.
> We can later hook this into the crtc color pipeline once we implement it.
Do you mean upstreamed as well?
How is that different from the original proposal here that I raised
concerns about?
Thanks,
pq
> A userspace implementation showing end to end benefit of the feature and
> usecase would be needed. Hope this is ok and no strong objection to this
> approach.
>
> Regards,
> Uma Shankar
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-04-17 7:18 ` Pekka Paalanen
@ 2025-04-17 10:50 ` Shankar, Uma
0 siblings, 0 replies; 58+ messages in thread
From: Shankar, Uma @ 2025-04-17 10:50 UTC (permalink / raw)
To: Pekka Paalanen
Cc: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Kandpal, Suraj, harry.wentland@amd.com, alex.hung@amd.com,
Vetter, Simona, airlied@gmail.com
> -----Original Message-----
> From: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
> Sent: Thursday, April 17, 2025 12:48 PM
> To: Shankar, Uma <uma.shankar@intel.com>
> Cc: Murthy, Arun R <arun.r.murthy@intel.com>; intel-xe@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Kandpal, Suraj
> <suraj.kandpal@intel.com>; harry.wentland@amd.com; alex.hung@amd.com;
> Vetter, Simona <simona.vetter@intel.com>; airlied@gmail.com
> Subject: Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
>
> On Thu, 17 Apr 2025 06:31:21 +0000
> "Shankar, Uma" <uma.shankar@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of
> > > Murthy, Arun R
> > > Sent: Friday, March 28, 2025 10:36 AM
> > > To: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
> > > Cc: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> > > dri- devel@lists.freedesktop.org; Kandpal, Suraj
> > > <suraj.kandpal@intel.com>; harry.wentland@amd.com;
> > > alex.hung@amd.com; Vetter, Simona <simona.vetter@intel.com>;
> > > airlied@gmail.com
> > > Subject: RE: [PATCH v8 01/14] drm: Define histogram structures
> > > exposed to user
> > >
> > > > On Wed, 26 Mar 2025 06:03:27 +0000 "Murthy, Arun R"
> > > > <arun.r.murthy@intel.com> wrote:
> > > >
> > > > > > On Wed, 19 Mar 2025 12:08:15 +0000 "Murthy, Arun R"
> > > > > > <arun.r.murthy@intel.com> wrote:
> > > > > >
> > > > > > > > On Mon, 3 Mar 2025 13:23:42 +0530 "Murthy, Arun R"
> > > > > > > > <arun.r.murthy@intel.com> wrote:
> > > > > > > >
> > > > > > > > > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > > > > > > > > On Wed, 19 Feb 2025 09:28:51 +0530 "Murthy, Arun R"
> > > > > > > > > > <arun.r.murthy@intel.com> wrote:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > > > Hi Pekka,
> > > > > > > > > Sorry got getting back late on this.
> > > > > > > > > I totally agree that the UAPI should not be any hardware
> > > > > > > > > specific and have taken care to get rid of such if any.
> > > > > > > > > Here we are just exposing the histogram data and what
> > > > > > > > > point is the histogram generated is out of the scope.
> > > > > > > >
> > > > > > > > It's not out of scope. Understanding exactly at what point
> > > > > > > > the histogram is generated in the KMS pixel pipeline is
> > > > > > > > paramount to being able to use the results correctly - how
> > > > > > > > it relates to the
> > > > framebuffers'
> > > > > > > > contents and KMS pixel pipeline configuration.
> > > > > > > >
> > > > > > >
> > > > > > > While working around this comment, it looks to be quite
> > > > > > > challenging to address this comment and agree that this will
> > > > > > > have to be addressed and is important for the user to know
> > > > > > > at which point in the pixel pipeline configuration the histogram is
> generated.
> > > > > > > I can think of 2 options on addressing this.
> > > > > > >
> > > > > > > 1. Have this documented in the driver. Since this can vary
> > > > > > > on each vendor hardware, can have this documented in the
> > > > > > > drivers or ReST
> > > > document.
> > > > > > >
> > > > > >
> > > > > > Hi Arun,
> > > > > >
> > > > > > this is not acceptable in KMS, because it requires userspace
> > > > > > to have code that depends on the hardware revision or
> > > > > > identity. When new hardware appears, it will not be enough to
> > > > > > update the drivers, one will also need to update userspace.
> > > > > > There currently is no userspace "standard KMS library" to
> > > > > > abstract all drivers further, like there is libcamera
> > > > and Mesa.
> > > > > >
> > > > > > > 2. Maybe have a bitmapping like we have it for histogram_mode.
> > > > > > > Define user readable macros for that.
> > > > > > > Ex: CC1_DEGAMMA_HIST_CC2
> > > > > > > In this case histogram is between the two color conversion
> > > > > > > hardware block in the pixel pipeline.
> > > > > > > This macro will have to be defined on need basis and define
> > > > > > > a
> > > > > > > u32 variable for this bit manipulation.
> > > > > >
> > > > > > This one still has problems in that some hardware may not have
> > > > > > all the non- HIST elements or not in the same order. It's a
> > > > > > better abstraction than option 1, but it's still weak.
> > > > > >
> > > > > > I can see one solid solution, but it won't be usable for quite
> > > > > > some time I
> > > > > > suppose:
> > > > > >
> > > > > > https://lore.kernel.org/dri-devel/20241220043410.416867-5-
> > > > > > alex.hung@amd.com/
> > > > > >
> > > > > > The current work on the color pipelines UAPI is concentrated
> > > > > > on the per-plane operations. The idea is that once those are
> > > > > > hashed out, the same design is applied to CRTCs as well,
> > > > > > deprecating all existing CRTC color processing properties. A
> > > > > > histogram processing element could be exposed as a colorop
> > > > > > object, and its position in a CRTC color pipeline represents the point
> where the histogram is collected.
> > > > > >
> > > > > > That would be the best possible UAPI design on current
> > > > > > knowledge in my opinion.
> > > > > >
> > > > > Yes this would be the best design, but looking into the timeline
> > > > > for this CRTC color pipeline can we proceed with this as in interim solution.
> > > > > Once we have the CRTC color pipeline in drm, will rebase this
> > > > > histogram to make use of the pipeline.
> > > > > We can also take up the crtc color pipeline and will also start
> > > > > contributing to get things faster but since there is not
> > > > > timeline defined for that activity, would it be viable to go
> > > > > ahead with
> > > > > option2 as in
> > > > interim solution?
> > > >
> > > > Hi Arun,
> > > >
> > > > I think that's something the DRM maintainers should chime in on.
> >
> > As a first step, I think we can expose the Histogram through the property.
> > We can later hook this into the crtc color pipeline once we implement it.
>
> Do you mean upstreamed as well?
>
> How is that different from the original proposal here that I raised concerns about?
Hi Pekka,
I meant the option 2 as an interim approach to get the visibility to userspace of histogram
blocks which can be extended further once we get the full crtc color pipeline in place.
Regards,
Uma Shankar
>
> Thanks,
> pq
>
> > A userspace implementation showing end to end benefit of the feature
> > and usecase would be needed. Hope this is ok and no strong objection
> > to this approach.
> >
> > Regards,
> > Uma Shankar
> >
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-18 5:43 ` Murthy, Arun R
2025-02-18 16:18 ` Pekka Paalanen
@ 2025-02-20 16:26 ` Dmitry Baryshkov
2025-03-03 7:54 ` Murthy, Arun R
1 sibling, 1 reply; 58+ messages in thread
From: Dmitry Baryshkov @ 2025-02-20 16:26 UTC (permalink / raw)
To: Murthy, Arun R
Cc: Pekka Paalanen, intel-xe, intel-gfx, dri-devel, suraj.kandpal
On Tue, Feb 18, 2025 at 11:13:39AM +0530, Murthy, Arun R wrote:
> On 17-02-2025 15:38, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> > replacement for them, I would assume both are a requirement.
> >
> > Without the ReST docs it is really difficult to see how this new UAPI
> > should be used.
> Hi Pekka,
> I also realized later on this. Will add this in my next patchset.
> >
> > On Tue, 28 Jan 2025 21:21:07 +0530
> > Arun R Murthy <arun.r.murthy@intel.com> wrote:
> >
> > > Display Histogram is an array of bins and can be generated in many ways
> > > referred to as modes.
> > > Ex: HSV max(RGB), Wighted RGB etc.
> > >
> > > Understanding the histogram data format(Ex: HSV max(RGB))
> > > Histogram is just the pixel count.
> > > For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > > 25 bits should be sufficient to represent this along with a buffer of 7
> > > bits(future use) u32 is being considered.
> > > max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
> > > bits, hence 32 bins.
> > > Below mentioned algorithm illustrates the histogram generation in
> > > hardware.
> > >
> > > hist[32] = {0};
> > > for (i = 0; i < resolution; i++) {
> > > bin = max(RGB[i]);
> > > bin = bin >> 3; /* consider the most significant bits */
> > > hist[bin]++;
> > > }
> > > If the entire image is Red color then max(255,0,0) is 255 so the pixel
> > > count of each pixels will be placed in the last bin. Hence except
> > > hist[31] all other bins will have a value zero.
> > > Generated histogram in this case would be hist[32] = {0,0,....44236800}
> > >
> > > Description of the structures, properties defined are documented in the
> > > header file include/uapi/drm/drm_mode.h
> > >
> > > v8: Added doc for HDR planes, removed reserved variables (Dmitry)
> > >
> > > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> > > ---
> > > include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 65 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
> > > __u32 pad;
> > > };
> > > +/**
> > > + * enum drm_mode_histogram
> > > + *
> > > + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
> > > + * Maximum resolution at present 10k, 10240x4320 = 44236800
> > > + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
> > > + * can be a u32 value.
> > > + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
> > I assume s/SDL/SDR/.
> Yes, sorry TYPO
> >
> > This assumption seems false. SDR can be also 10-bit and probably even
> > more.
> Yes but in practice majority of them being 8-bit. So have considered 8-bit
> for illustration purpose only.
> The design itself should accommodate 10-bit as well.
> > > + * If the most significant 5 bits are considered, then bins = 2^5
> > > + * will be 32 bins.
> > > + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
> > Does this mean that the histogram is computed on the pixel values
> > emitted to the cable? What if the cable format is YUV?
> Yes, again the illustration over here is max(RGB) used for histogram
> generation.
> If YUV is used or weighted RGB is used for histogram generation then the
> mode will have to change and accordingly the data for that mode.
> > > + * For illustration consider a full RED image of 10k resolution considering all
> > > + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
> > > + * plane similarly with HDR the same would look like hist[65535] =
> > > + * {0,0,0,....44236800}
> > This SDR vs. HDR is a false dichotomy. I presume the meaningful
> > difference is bits-per-channel, not the dynamic range.
> >
> > It would be good to have the pseudocode snippet here instead of the
> > commit message. The commit message should not contain any UAPI notes
> > that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
> > message is probably not very useful, as the more interesting questions
> > are why this exists and what it can be used for.
> I have the pseudocode in the cover letter of this patchset.
> > > + */
> > > +enum drm_mode_histogram {
> > > + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
> > What does the HSV stand for?
> >
> > When talking about pixel values, my first impression is
> > hue-saturation-value. But there are no hue-saturation-value
> > computations at all?
> The computation will have to be done by the user in the library.
> > > +};
> > > +
> > > +/**
> > > + * struct drm_histogram_caps
> > > + *
> > > + * @histogram_mode: histogram generation modes, defined in the
> > > + * enum drm_mode_histogram
> > > + * @bins_count: number of bins for a chosen histogram mode. For illustration
> > > + * refer the above defined histogram mode.
> > > + */
> > > +struct drm_histogram_caps {
> > > + __u32 histogram_mode;
> > > + __u32 bins_count;
> > > +};
> > Patch 3 says:
> >
> > + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
> > + * Description of the structure is in include/uapi/drm/drm_mode.h
> >
> > This is a read-only property, right?
> >
> > The blob contains one struct drm_histogram_caps. What if more than one
> > mode is supported?
> Multiple modes can be ORed. User will have to choose one of them depending
> on the algorithm that he is developing/using.
No. Modes can not be ORed. The structure can be applicable to a single
mode (e.g. user settings) or to a multiple modes (e.g. caps).
So when the struct describes a single mode, it should be just that
mode, enumerated linearly, starting from 0. When you have a struct
which can actually be related to several modes, it should have a value
of BIT(DRM_MODE_HISTOGRAM_foo) | BIT(DRM_MODE_HISTOGRAM_bar).
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 01/14] drm: Define histogram structures exposed to user
2025-02-20 16:26 ` Dmitry Baryshkov
@ 2025-03-03 7:54 ` Murthy, Arun R
0 siblings, 0 replies; 58+ messages in thread
From: Murthy, Arun R @ 2025-03-03 7:54 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Pekka Paalanen, intel-xe, intel-gfx, dri-devel, suraj.kandpal
On 20-02-2025 21:56, Dmitry Baryshkov wrote:
> On Tue, Feb 18, 2025 at 11:13:39AM +0530, Murthy, Arun R wrote:
>> On 17-02-2025 15:38, Pekka Paalanen wrote:
>>> Hi Arun,
>>>
>>> this whole series seems to be missing all the UAPI docs for the DRM
>>> ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
>>> replacement for them, I would assume both are a requirement.
>>>
>>> Without the ReST docs it is really difficult to see how this new UAPI
>>> should be used.
>> Hi Pekka,
>> I also realized later on this. Will add this in my next patchset.
>>> On Tue, 28 Jan 2025 21:21:07 +0530
>>> Arun R Murthy <arun.r.murthy@intel.com> wrote:
>>>
>>>> Display Histogram is an array of bins and can be generated in many ways
>>>> referred to as modes.
>>>> Ex: HSV max(RGB), Wighted RGB etc.
>>>>
>>>> Understanding the histogram data format(Ex: HSV max(RGB))
>>>> Histogram is just the pixel count.
>>>> For a maximum resolution of 10k (10240 x 4320 = 44236800)
>>>> 25 bits should be sufficient to represent this along with a buffer of 7
>>>> bits(future use) u32 is being considered.
>>>> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most significant 5
>>>> bits, hence 32 bins.
>>>> Below mentioned algorithm illustrates the histogram generation in
>>>> hardware.
>>>>
>>>> hist[32] = {0};
>>>> for (i = 0; i < resolution; i++) {
>>>> bin = max(RGB[i]);
>>>> bin = bin >> 3; /* consider the most significant bits */
>>>> hist[bin]++;
>>>> }
>>>> If the entire image is Red color then max(255,0,0) is 255 so the pixel
>>>> count of each pixels will be placed in the last bin. Hence except
>>>> hist[31] all other bins will have a value zero.
>>>> Generated histogram in this case would be hist[32] = {0,0,....44236800}
>>>>
>>>> Description of the structures, properties defined are documented in the
>>>> header file include/uapi/drm/drm_mode.h
>>>>
>>>> v8: Added doc for HDR planes, removed reserved variables (Dmitry)
>>>>
>>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>>> ---
>>>> include/uapi/drm/drm_mode.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 65 insertions(+)
>>>>
>>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>>> index c082810c08a8b234ef2672ecf54fc8c05ddc2bd3..b8b7b18843ae7224263a9c61b20ac6cbf5df69e9 100644
>>>> --- a/include/uapi/drm/drm_mode.h
>>>> +++ b/include/uapi/drm/drm_mode.h
>>>> @@ -1355,6 +1355,71 @@ struct drm_mode_closefb {
>>>> __u32 pad;
>>>> };
>>>> +/**
>>>> + * enum drm_mode_histogram
>>>> + *
>>>> + * @DRM_MODE_HISTOGRAM_HSV_MAX_RGB:
>>>> + * Maximum resolution at present 10k, 10240x4320 = 44236800
>>>> + * can be denoted in 25bits. With an additional 7 bits in buffer each bin
>>>> + * can be a u32 value.
>>>> + * For SDL, Maximum value of max(RGB) is 255, so max 255 bins.
>>> I assume s/SDL/SDR/.
>> Yes, sorry TYPO
>>> This assumption seems false. SDR can be also 10-bit and probably even
>>> more.
>> Yes but in practice majority of them being 8-bit. So have considered 8-bit
>> for illustration purpose only.
>> The design itself should accommodate 10-bit as well.
>>>> + * If the most significant 5 bits are considered, then bins = 2^5
>>>> + * will be 32 bins.
>>>> + * For HDR, maximum value of max(RGB) is 65535, so max 65535 bins.
>>> Does this mean that the histogram is computed on the pixel values
>>> emitted to the cable? What if the cable format is YUV?
>> Yes, again the illustration over here is max(RGB) used for histogram
>> generation.
>> If YUV is used or weighted RGB is used for histogram generation then the
>> mode will have to change and accordingly the data for that mode.
>>>> + * For illustration consider a full RED image of 10k resolution considering all
>>>> + * 8 bits histogram would look like hist[255] = {0,0,....44236800} with SDR
>>>> + * plane similarly with HDR the same would look like hist[65535] =
>>>> + * {0,0,0,....44236800}
>>> This SDR vs. HDR is a false dichotomy. I presume the meaningful
>>> difference is bits-per-channel, not the dynamic range.
>>>
>>> It would be good to have the pseudocode snippet here instead of the
>>> commit message. The commit message should not contain any UAPI notes
>>> that are not in the UAPI docs. OTOH, repeating UAPI docs in the commit
>>> message is probably not very useful, as the more interesting questions
>>> are why this exists and what it can be used for.
>> I have the pseudocode in the cover letter of this patchset.
>>>> + */
>>>> +enum drm_mode_histogram {
>>>> + DRM_MODE_HISTOGRAM_HSV_MAX_RGB = 0x01,
>>> What does the HSV stand for?
>>>
>>> When talking about pixel values, my first impression is
>>> hue-saturation-value. But there are no hue-saturation-value
>>> computations at all?
>> The computation will have to be done by the user in the library.
>>>> +};
>>>> +
>>>> +/**
>>>> + * struct drm_histogram_caps
>>>> + *
>>>> + * @histogram_mode: histogram generation modes, defined in the
>>>> + * enum drm_mode_histogram
>>>> + * @bins_count: number of bins for a chosen histogram mode. For illustration
>>>> + * refer the above defined histogram mode.
>>>> + */
>>>> +struct drm_histogram_caps {
>>>> + __u32 histogram_mode;
>>>> + __u32 bins_count;
>>>> +};
>>> Patch 3 says:
>>>
>>> + * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
>>> + * Description of the structure is in include/uapi/drm/drm_mode.h
>>>
>>> This is a read-only property, right?
>>>
>>> The blob contains one struct drm_histogram_caps. What if more than one
>>> mode is supported?
>> Multiple modes can be ORed. User will have to choose one of them depending
>> on the algorithm that he is developing/using.
> No. Modes can not be ORed. The structure can be applicable to a single
> mode (e.g. user settings) or to a multiple modes (e.g. caps).
I meant the same. KMD can support multiple modes and when setting the
config only one among the supported mode will have to be choosen by the
user.
Sorry if I created some confusion over here.
Thanks and Regards,
Arun R Murthy
--------------------
> So when the struct describes a single mode, it should be just that
> mode, enumerated linearly, starting from 0. When you have a struct
> which can actually be related to several modes, it should have a value
> of BIT(DRM_MODE_HISTOGRAM_foo) | BIT(DRM_MODE_HISTOGRAM_bar).
>
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT structures exposed to user
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 01/14] drm: Define histogram structures exposed to user Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 9:11 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for histogram Arun R Murthy
` (14 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
ImageEnhancemenT(IET) hardware interpolates the LUT value to generate
the enhanced output image. LUT takes an input value, outputs a new
value based on the data within the LUT. 1D LUT can remap individual
input values to new output values based on the LUT sample. LUT can be
interpolated by the hardware by multiple modes Ex: Direct Lookup LUT,
Multiplicative LUT etc
The list of supported mode by hardware along with the format(exponent
mantissa) is exposed to user by the iet_lut_caps property. Maximum
format being 8.24 i.e 8 exponent and 24 mantissa.
For illustration a hardware supporting 1.9 format denotes this as
0x10001FF. In order to know the exponent do a bitwise AND with
0xF000000. The LUT value to be provided by user would be a 10bit value
with 1 bit integer and 9 bit fractional value.
Multiple formats can be supported, hence pointer is used over here.
User can then provide the LUT with any one of the supported modes in
any of the supported formats.
The entries in the LUT can vary depending on the hardware capability
with max being 255. This will also be exposed as iet_lut_caps so user
can generate a LUT with the specified entries.
v8: define enum for iet_mode, add more doc for iet modes (Dmitry)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
include/uapi/drm/drm_mode.h | 68 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b8b7b18843ae7224263a9c61b20ac6cbf5df69e9..006be62218bf1e985c2ca6352cb04110a38d1e84 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -1420,6 +1420,74 @@ struct drm_histogram {
__u32 nr_elements;
};
+/**
+ * enum drm_iet_mode
+ * @DRM_MODE_IET_LOOKUP_LUT:
+ * LUT values are points on exponential graph with x axis and y-axis y=f(x)
+ * This f(x) can be the algorithm, defined by the user space algorithm.
+ * When this LUT table is passed to the hardware it signifies how the hardware
+ * should use this table to get the LUT values. In this mode its direct lookup
+ * table. x-axis corresponds to input pixel value and y-axis corresponds to
+ * the output pixel value.
+ *
+ * @DRM_MODE_IET_MULTIPLICATIVE:
+ * LUT values, x and y are points on negative exponential graph with
+ * x-axis and y-axis (y = y/x). The value passed by the user will be
+ * in y/x i.e OutPixel/InPixel. X co-ordinate proportional to pixel value
+ * and Y-cordinate is the multiplier factor, i.e x-axis in pixels and
+ * y-axis is OutPixel/InPixel. so upon multiplying x, y is obtained,
+ * hence multiplicative.
+ * The format of LUT can at max be 8.24(8integer 24 fractional)
+ * represented by u32. 32bit is the container and if 16.16 is chosen
+ * then it doesn't make sense to boost the pixel by 2^16. Hence set aside
+ * 8bit for integer 2^8 thereby boosting the pixel by a value 255 which
+ * itself is a huge boost factor. Remaining 24bits out of the 32bit
+ * container is fractional part. This is also optimal for implementing
+ * in the hardware.
+ * Depending on the hardware capability and exponent mantissa can be
+ * chosen within this limits.
+ */
+enum drm_iet_mode {
+ DRM_MODE_IET_LOOKUP_LUT = 0x01,
+ DRM_MODE_IET_MULTIPLICATIVE = 0x02,
+};
+
+/**
+ * struct drm_iet_caps
+ *
+ * @iet_mode: pixel factor enhancement modes defined in enum drm_iet_mode.
+ * Multiple modes can be supported by hardware, the value can be
+ * ORed.
+ * @iet_sample_format: holds the address of an array of u32 LUT sample formats
+ * depending on the hardware capability. Max being 8.24
+ * Doing a bitwise AND will get the present sample.
+ * Ex: for 1 integer 9 fraction AND with 0x10001FF
+ * @nr_iet_sample_formats: number of iet_sample_formsts supported by the
+ * hardware
+ * @nr_iet_lut_entries: number of LUT entries
+ */
+struct drm_iet_caps {
+ __u32 iet_mode;
+ __u64 iet_sample_format;
+ __u32 nr_iet_sample_formats;
+ __u32 nr_iet_lut_entries;
+};
+
+/**
+ * struct drm_iet_1dlut_sample
+ * @iet_lut: the address in the field describes the format of the data
+ * corresponding to the @iet_mode
+ * In case of direct lookup this is NULL, in case of
+ * multiplicative mode LUT exponent and mantissa format.
+ * @nr_elements: number of entries pointed by the data @iet_lut
+ * @iet_mode: image enhancement mode, this will also convey the channel.
+ */
+struct drm_iet_1dlut_sample {
+ __u64 iet_lut;
+ __u32 nr_elements;
+ enum drm_iet_mode iet_mode;
+};
+
#if defined(__cplusplus)
}
#endif
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT structures exposed to user
2025-01-28 15:51 ` [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT " Arun R Murthy
@ 2025-02-14 9:11 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 9:11 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT structures
> exposed to user
>
> ImageEnhancemenT(IET) hardware interpolates the LUT value to generate the
> enhanced output image. LUT takes an input value, outputs a new value based
> on the data within the LUT. 1D LUT can remap individual input values to new
> output values based on the LUT sample. LUT can be interpolated by the
> hardware by multiple modes Ex: Direct Lookup LUT, Multiplicative LUT etc The
> list of supported mode by hardware along with the format(exponent
> mantissa) is exposed to user by the iet_lut_caps property. Maximum format
> being 8.24 i.e 8 exponent and 24 mantissa.
> For illustration a hardware supporting 1.9 format denotes this as 0x10001FF. In
> order to know the exponent do a bitwise AND with 0xF000000. The LUT value
> to be provided by user would be a 10bit value with 1 bit integer and 9 bit
> fractional value.
>
> Multiple formats can be supported, hence pointer is used over here.
> User can then provide the LUT with any one of the supported modes in any of
> the supported formats.
> The entries in the LUT can vary depending on the hardware capability with max
> being 255. This will also be exposed as iet_lut_caps so user can generate a LUT
> with the specified entries.
>
> v8: define enum for iet_mode, add more doc for iet modes (Dmitry)
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> include/uapi/drm/drm_mode.h | 68
> +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index
> b8b7b18843ae7224263a9c61b20ac6cbf5df69e9..006be62218bf1e985c2ca6352
> cb04110a38d1e84 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -1420,6 +1420,74 @@ struct drm_histogram {
> __u32 nr_elements;
> };
>
> +/**
> + * enum drm_iet_mode
> + * @DRM_MODE_IET_LOOKUP_LUT:
> + * LUT values are points on exponential graph with x axis and y-axis
> +y=f(x)
> + * This f(x) can be the algorithm, defined by the user space algorithm.
> + * When this LUT table is passed to the hardware it signifies how the
> +hardware
> + * should use this table to get the LUT values. In this mode its direct
> +lookup
> + * table. x-axis corresponds to input pixel value and y-axis
> +corresponds to
> + * the output pixel value.
> + *
> + * @DRM_MODE_IET_MULTIPLICATIVE:
> + * LUT values, x and y are points on negative exponential graph with
> + * x-axis and y-axis (y = y/x). The value passed by the user will be
> + * in y/x i.e OutPixel/InPixel. X co-ordinate proportional to pixel
> +value
> + * and Y-cordinate is the multiplier factor, i.e x-axis in pixels and
> + * y-axis is OutPixel/InPixel. so upon multiplying x, y is obtained,
> + * hence multiplicative.
> + * The format of LUT can at max be 8.24(8integer 24 fractional)
> + * represented by u32. 32bit is the container and if 16.16 is chosen
> + * then it doesn't make sense to boost the pixel by 2^16. Hence set
> +aside
> + * 8bit for integer 2^8 thereby boosting the pixel by a value 255 which
> + * itself is a huge boost factor. Remaining 24bits out of the 32bit
> + * container is fractional part. This is also optimal for implementing
> + * in the hardware.
> + * Depending on the hardware capability and exponent mantissa can be
> + * chosen within this limits.
> + */
> +enum drm_iet_mode {
> + DRM_MODE_IET_LOOKUP_LUT = 0x01,
> + DRM_MODE_IET_MULTIPLICATIVE = 0x02,
> +};
> +
> +/**
> + * struct drm_iet_caps
> + *
Let's remove the space here
> + * @iet_mode: pixel factor enhancement modes defined in enum
> drm_iet_mode.
> + * Multiple modes can be supported by hardware, the value can be
> + * ORed.
> + * @iet_sample_format: holds the address of an array of u32 LUT sample
> formats
> + * depending on the hardware capability. Max being 8.24
> + * Doing a bitwise AND will get the present sample.
> + * Ex: for 1 integer 9 fraction AND with 0x10001FF
> + * @nr_iet_sample_formats: number of iet_sample_formsts supported by the
> + * hardware
Typo: formats
> + * @nr_iet_lut_entries: number of LUT entries */ struct drm_iet_caps {
> + __u32 iet_mode;
Again do we really need 32 bits for this 16 should suffice
Regards,
Suraj Kandpal
> + __u64 iet_sample_format;
> + __u32 nr_iet_sample_formats;
> + __u32 nr_iet_lut_entries;
> +};
> +
> +/**
> + * struct drm_iet_1dlut_sample
> + * @iet_lut: the address in the field describes the format of the data
> + * corresponding to the @iet_mode
> + * In case of direct lookup this is NULL, in case of
> + * multiplicative mode LUT exponent and mantissa format.
> + * @nr_elements: number of entries pointed by the data @iet_lut
> + * @iet_mode: image enhancement mode, this will also convey the channel.
> + */
> +struct drm_iet_1dlut_sample {
> + __u64 iet_lut;
> + __u32 nr_elements;
> + enum drm_iet_mode iet_mode;
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for histogram
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 01/14] drm: Define histogram structures exposed to user Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 02/14] drm: Define ImageEnhancemenT LUT " Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 9:36 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for IET LUT Arun R Murthy
` (13 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Add drm-crtc property for histogram and for the properties added add
the corresponding get/set_property.
v8: Rebased
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 14 ++++++
drivers/gpu/drm/drm_atomic_uapi.c | 15 +++++++
drivers/gpu/drm/drm_crtc.c | 73 +++++++++++++++++++++++++++++++
include/drm/drm_crtc.h | 44 +++++++++++++++++++
4 files changed, 146 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb109533d2596e899a57b571fa0995824f..dfe6293f7a42d034da3de593094019ca15014a02 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -143,6 +143,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
drm_property_blob_get(state->ctm);
if (state->gamma_lut)
drm_property_blob_get(state->gamma_lut);
+ if (state->histogram_caps)
+ drm_property_blob_get(state->histogram_caps);
+ if (state->histogram_enable)
+ drm_property_blob_get(state->histogram_enable);
+ if (state->histogram_data)
+ drm_property_blob_get(state->histogram_data);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -156,6 +162,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
/* Self refresh should be canceled when a new update is available */
state->active = drm_atomic_crtc_effectively_active(state);
state->self_refresh_active = false;
+
+ state->histogram_updated = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
@@ -215,6 +223,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
drm_property_blob_put(state->gamma_lut);
+ if (state->histogram_caps)
+ drm_property_blob_put(state->histogram_caps);
+ if (state->histogram_enable)
+ drm_property_blob_put(state->histogram_enable);
+ if (state->histogram_data)
+ drm_property_blob_put(state->histogram_data);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 370dc676e3aa543c9827b50df20df78f02b738c9..459d30898196c94392a7f916b1fa9ca3a334eea8 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -415,6 +415,15 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == crtc->histogram_enable_property) {
+ ret = drm_property_replace_blob_from_id(dev,
+ &state->histogram_enable,
+ val,
+ -1,
+ sizeof(struct drm_histogram_config),
+ &replaced);
+ state->histogram_updated |= replaced;
+ return ret;
} else if (property == crtc->scaling_filter_property) {
state->scaling_filter = val;
} else if (crtc->funcs->atomic_set_property) {
@@ -452,6 +461,12 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == crtc->histogram_caps_property)
+ *val = (state->histogram_caps) ? state->histogram_caps->base.id : 0;
+ else if (property == crtc->histogram_enable_property)
+ *val = (state->histogram_enable) ? state->histogram_enable->base.id : 0;
+ else if (property == crtc->histogram_data_property)
+ *val = (state->histogram_data) ? state->histogram_data->base.id : 0;
else if (property == crtc->scaling_filter_property)
*val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 46655339003db2a1b43441434839e26f61d79b4e..d10b29aff725e40bdb93e6bd0828347db40fa3e8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -959,3 +959,76 @@ bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state)
return hweight32(crtc_state->encoder_mask) > 1;
}
EXPORT_SYMBOL(drm_crtc_in_clone_mode);
+
+/**
+ * drm_crtc_create_histogram_property: create histogram properties
+ *
+ * @crtc: pointer to the struct drm_crtc.
+ * @caps: pointer to the struct drm_histogram_caps, holds the
+ * histogram hardware capabilities.
+ *
+ * The property HISTOGRAM_CAPS exposes the hardware capability for
+ * histogram which includes the histogram mode, number of bins etc
+ * The property HISTOGRAM_ENABLE allows user to enable/disable the
+ * histogram feature and also configure the hardware.
+ * Upon KMD enabling by writing to the hardware registers, histogram
+ * is generated. Histogram is composed of 'n' bins with each bin
+ * being an integer(pixel count).
+ * An event HISTOGRAM will be sent to the user. User upon receiving this
+ * event can read the hardware generated histogram using crtc property
+ * HISTOGRAM_DATA.
+ * User can use this histogram data to enhance the image or in shaders.
+ *
+ * Property HISTOGRAM_CAPS is a blob pointing to the struct drm_histogram_caps
+ * Description of the structure is in include/uapi/drm/drm_mode.h
+ * Property HISTOGRAM_ENABLE is a blob pointing to the struct
+ * drm_histogram_config
+ * Description of the structure is in include/uapi/drm/drm_mode.h
+ * Property HISTOGRAM_DATA is a blob pointing to the struct drm_histogram
+ * Description of the structure is in include/uapi/drm/drm_mode.h
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
+ struct drm_histogram_caps *caps)
+{
+ struct drm_property *prop;
+ struct drm_property_blob *blob;
+ struct drm_histogram_caps *blob_data;
+
+ blob = drm_property_create_blob(crtc->dev,
+ sizeof(struct drm_histogram_caps),
+ NULL);
+ if (IS_ERR(blob))
+ return -1;
+ blob_data = blob->data;
+ blob_data->histogram_mode = caps->histogram_mode;
+ blob_data->bins_count = caps->bins_count;
+
+ prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "HISTOGRAM_CAPS", blob->base.id);
+ if (!prop)
+ return -ENOMEM;
+ drm_object_attach_property(&crtc->base, prop, 0);
+ crtc->histogram_caps_property = prop;
+
+ prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_BLOB, "HISTOGRAM_ENABLE", 0);
+ if (!prop)
+ return -ENOMEM;
+ drm_object_attach_property(&crtc->base, prop, 0);
+ crtc->histogram_enable_property = prop;
+
+ prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "HISTOGRAM_DATA", 0);
+ if (!prop)
+ return -ENOMEM;
+ drm_object_attach_property(&crtc->base, prop, 0);
+ crtc->histogram_data_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_crtc_create_histogram_property);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index caa56e039da2a748cf40ebf45b37158acda439d9..2da803749bdf03c07268be4e075793ef4e4eb99a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -274,6 +274,32 @@ struct drm_crtc_state {
*/
struct drm_property_blob *gamma_lut;
+ /**
+ * @histogram_caps:
+ *
+ * The blob points to the structure drm_histogram_caps.
+ * For more info on the elements of the struct drm_histogram_caps
+ * see include/uapi/drm/drm_mode.h
+ */
+ struct drm_property_blob *histogram_caps;
+ /**
+ * @histogram_enable:
+ *
+ * The blob points to the structure drm_histogram_config.
+ * For more information on the elements of struct drm_histogram_config
+ * see include/uapi/drm/drm_mode.h
+ */
+ struct drm_property_blob *histogram_enable;
+ /**
+ * @histogram_data:
+ *
+ * The blob points to the structure drm_histogram.
+ * For more information on the elements of struct drm_histogram
+ * see include/uapi/drm/drm_mode.h
+ */
+ struct drm_property_blob *histogram_data;
+ bool histogram_updated;
+
/**
* @target_vblank:
*
@@ -1088,6 +1114,22 @@ struct drm_crtc {
*/
struct drm_property *scaling_filter_property;
+ /**
+ * @histogram_caps_property: Optional CRTC property for getting the
+ * histogram hardware capability.
+ */
+ struct drm_property *histogram_caps_property;
+ /**
+ * @histogram_enable_property: Optional CRTC property for enabling or
+ * disabling global histogram.
+ */
+ struct drm_property *histogram_enable_property;
+ /**
+ * @histogram_data_proeprty: Optional CRTC property for getting the
+ * histogram blob data.
+ */
+ struct drm_property *histogram_data_property;
+
/**
* @state:
*
@@ -1324,4 +1366,6 @@ static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
unsigned int supported_filters);
bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state);
+int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
+ struct drm_histogram_caps *caps);
#endif /* __DRM_CRTC_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for histogram
2025-01-28 15:51 ` [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for histogram Arun R Murthy
@ 2025-02-14 9:36 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 9:36 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for
> histogram
>
> Add drm-crtc property for histogram and for the properties added add the
> corresponding get/set_property.
>
> v8: Rebased
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 14 ++++++
> drivers/gpu/drm/drm_atomic_uapi.c | 15 +++++++
> drivers/gpu/drm/drm_crtc.c | 73
> +++++++++++++++++++++++++++++++
> include/drm/drm_crtc.h | 44 +++++++++++++++++++
> 4 files changed, 146 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index
> 519228eb109533d2596e899a57b571fa0995824f..dfe6293f7a42d034da3de5930
> 94019ca15014a02 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -143,6 +143,12 @@ void
> __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
> drm_property_blob_get(state->ctm);
> if (state->gamma_lut)
> drm_property_blob_get(state->gamma_lut);
> + if (state->histogram_caps)
> + drm_property_blob_get(state->histogram_caps);
> + if (state->histogram_enable)
> + drm_property_blob_get(state->histogram_enable);
> + if (state->histogram_data)
> + drm_property_blob_get(state->histogram_data);
> state->mode_changed = false;
> state->active_changed = false;
> state->planes_changed = false;
> @@ -156,6 +162,8 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
> /* Self refresh should be canceled when a new update is available */
> state->active = drm_atomic_crtc_effectively_active(state);
> state->self_refresh_active = false;
> +
Nit : Extra line not needed. Also move right under planes_changed.
> + state->histogram_updated = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> @@ -215,6 +223,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
> drm_crtc_state *state)
> drm_property_blob_put(state->degamma_lut);
> drm_property_blob_put(state->ctm);
> drm_property_blob_put(state->gamma_lut);
> + if (state->histogram_caps)
> + drm_property_blob_put(state->histogram_caps);
> + if (state->histogram_enable)
> + drm_property_blob_put(state->histogram_enable);
> + if (state->histogram_data)
> + drm_property_blob_put(state->histogram_data);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index
> 370dc676e3aa543c9827b50df20df78f02b738c9..459d30898196c94392a7f916b
> 1fa9ca3a334eea8 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -415,6 +415,15 @@ static int drm_atomic_crtc_set_property(struct
> drm_crtc *crtc,
> return -EFAULT;
>
> set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> + } else if (property == crtc->histogram_enable_property) {
> + ret = drm_property_replace_blob_from_id(dev,
> + &state-
> >histogram_enable,
> + val,
> + -1,
> + sizeof(struct
> drm_histogram_config),
> + &replaced);
> + state->histogram_updated |= replaced;
> + return ret;
> } else if (property == crtc->scaling_filter_property) {
> state->scaling_filter = val;
> } else if (crtc->funcs->atomic_set_property) { @@ -452,6 +461,12 @@
> drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> else if (property == config->prop_out_fence_ptr)
> *val = 0;
> + else if (property == crtc->histogram_caps_property)
> + *val = (state->histogram_caps) ? state->histogram_caps-
> >base.id : 0;
> + else if (property == crtc->histogram_enable_property)
> + *val = (state->histogram_enable) ? state->histogram_enable-
> >base.id : 0;
> + else if (property == crtc->histogram_data_property)
> + *val = (state->histogram_data) ? state->histogram_data-
> >base.id : 0;
> else if (property == crtc->scaling_filter_property)
> *val = state->scaling_filter;
> else if (crtc->funcs->atomic_get_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index
> 46655339003db2a1b43441434839e26f61d79b4e..d10b29aff725e40bdb93e6b
> d0828347db40fa3e8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -959,3 +959,76 @@ bool drm_crtc_in_clone_mode(struct drm_crtc_state
> *crtc_state)
> return hweight32(crtc_state->encoder_mask) > 1; }
> EXPORT_SYMBOL(drm_crtc_in_clone_mode);
> +
> +/**
> + * drm_crtc_create_histogram_property: create histogram properties
> + *
> + * @crtc: pointer to the struct drm_crtc.
> + * @caps: pointer to the struct drm_histogram_caps, holds the
> + * histogram hardware capabilities.
> + *
> + * The property HISTOGRAM_CAPS exposes the hardware capability for
> + * histogram which includes the histogram mode, number of bins etc
> + * The property HISTOGRAM_ENABLE allows user to enable/disable the
> + * histogram feature and also configure the hardware.
> + * Upon KMD enabling by writing to the hardware registers, histogram
> + * is generated. Histogram is composed of 'n' bins with each bin
> + * being an integer(pixel count).
> + * An event HISTOGRAM will be sent to the user. User upon receiving
> +this
> + * event can read the hardware generated histogram using crtc property
> + * HISTOGRAM_DATA.
> + * User can use this histogram data to enhance the image or in shaders.
> + *
> + * Property HISTOGRAM_CAPS is a blob pointing to the struct
> +drm_histogram_caps
> + * Description of the structure is in include/uapi/drm/drm_mode.h
I feel the line " Description of the structure is in include/uapi/drm/drm_mode.h"
isn't needed since once can use ctags to directly jump to the struct
> + * Property HISTOGRAM_ENABLE is a blob pointing to the struct
> + * drm_histogram_config
> + * Description of the structure is in include/uapi/drm/drm_mode.h
> + * Property HISTOGRAM_DATA is a blob pointing to the struct
> +drm_histogram
> + * Description of the structure is in include/uapi/drm/drm_mode.h
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
> + struct drm_histogram_caps *caps) {
> + struct drm_property *prop;
> + struct drm_property_blob *blob;
> + struct drm_histogram_caps *blob_data;
> +
> + blob = drm_property_create_blob(crtc->dev,
> + sizeof(struct drm_histogram_caps),
> + NULL);
Align with parenthesis
> + if (IS_ERR(blob))
> + return -1;
Shouldn’t be -1 maybe -EINVAL. Also new line after this if
> + blob_data = blob->data;
> + blob_data->histogram_mode = caps->histogram_mode;
> + blob_data->bins_count = caps->bins_count;
> +
> + prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
> + DRM_MODE_PROP_IMMUTABLE |
> DRM_MODE_PROP_BLOB,
> + "HISTOGRAM_CAPS", blob->base.id);
> + if (!prop)
> + return -ENOMEM;
New line here
> + drm_object_attach_property(&crtc->base, prop, 0);
> + crtc->histogram_caps_property = prop;
> +
> + prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
> + DRM_MODE_PROP_BLOB,
> "HISTOGRAM_ENABLE", 0);
> + if (!prop)
> + return -ENOMEM;
> + drm_object_attach_property(&crtc->base, prop, 0);
> + crtc->histogram_enable_property = prop;
> +
> + prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
> + DRM_MODE_PROP_IMMUTABLE |
> DRM_MODE_PROP_BLOB,
> + "HISTOGRAM_DATA", 0);
> + if (!prop)
> + return -ENOMEM;
*Ditto
Regards,
Suraj Kandpal
> + drm_object_attach_property(&crtc->base, prop, 0);
> + crtc->histogram_data_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_crtc_create_histogram_property);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> caa56e039da2a748cf40ebf45b37158acda439d9..2da803749bdf03c07268be4e0
> 75793ef4e4eb99a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -274,6 +274,32 @@ struct drm_crtc_state {
> */
> struct drm_property_blob *gamma_lut;
>
> + /**
> + * @histogram_caps:
> + *
> + * The blob points to the structure drm_histogram_caps.
> + * For more info on the elements of the struct drm_histogram_caps
> + * see include/uapi/drm/drm_mode.h
> + */
> + struct drm_property_blob *histogram_caps;
> + /**
> + * @histogram_enable:
> + *
> + * The blob points to the structure drm_histogram_config.
> + * For more information on the elements of struct
> drm_histogram_config
> + * see include/uapi/drm/drm_mode.h
> + */
> + struct drm_property_blob *histogram_enable;
> + /**
> + * @histogram_data:
> + *
> + * The blob points to the structure drm_histogram.
> + * For more information on the elements of struct drm_histogram
> + * see include/uapi/drm/drm_mode.h
> + */
> + struct drm_property_blob *histogram_data;
> + bool histogram_updated;
> +
> /**
> * @target_vblank:
> *
> @@ -1088,6 +1114,22 @@ struct drm_crtc {
> */
> struct drm_property *scaling_filter_property;
>
> + /**
> + * @histogram_caps_property: Optional CRTC property for getting the
> + * histogram hardware capability.
> + */
> + struct drm_property *histogram_caps_property;
> + /**
> + * @histogram_enable_property: Optional CRTC property for enabling
> or
> + * disabling global histogram.
> + */
> + struct drm_property *histogram_enable_property;
> + /**
> + * @histogram_data_proeprty: Optional CRTC property for getting the
> + * histogram blob data.
> + */
> + struct drm_property *histogram_data_property;
> +
> /**
> * @state:
> *
> @@ -1324,4 +1366,6 @@ static inline struct drm_crtc *drm_crtc_find(struct
> drm_device *dev, int drm_crtc_create_scaling_filter_property(struct drm_crtc
> *crtc,
> unsigned int supported_filters);
> bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state);
> +int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
> + struct drm_histogram_caps *caps);
> #endif /* __DRM_CRTC_H__ */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for IET LUT
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (2 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 03/14] drm/crtc: Expose API to create drm crtc property for histogram Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 9:47 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 05/14] drm/i915/histogram: Define registers for histogram Arun R Murthy
` (12 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Add drm-crtc property for IET 1DLUT and for the properties added add
corresponding get/set_property.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 9 ++++++
drivers/gpu/drm/drm_atomic_uapi.c | 13 ++++++++
drivers/gpu/drm/drm_crtc.c | 54 +++++++++++++++++++++++++++++++
include/drm/drm_crtc.h | 36 +++++++++++++++++++++
4 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfe6293f7a42d034da3de593094019ca15014a02..ceab90cec57cc580afcf334e275982827e9b0e0d 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -149,6 +149,10 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
drm_property_blob_get(state->histogram_enable);
if (state->histogram_data)
drm_property_blob_get(state->histogram_data);
+ if (state->iet_lut_caps)
+ drm_property_blob_get(state->iet_lut_caps);
+ if (state->iet_lut)
+ drm_property_blob_get(state->iet_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -164,6 +168,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
state->self_refresh_active = false;
state->histogram_updated = false;
+ state->iet_lut_updated = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
@@ -229,6 +234,10 @@ void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
drm_property_blob_put(state->histogram_enable);
if (state->histogram_data)
drm_property_blob_put(state->histogram_data);
+ if (state->iet_lut_caps)
+ drm_property_blob_put(state->iet_lut_caps);
+ if (state->iet_lut)
+ drm_property_blob_put(state->iet_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 459d30898196c94392a7f916b1fa9ca3a334eea8..f31d24d80cc082b38c611b12f36f281fa7404869 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -424,6 +424,15 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
&replaced);
state->histogram_updated |= replaced;
return ret;
+ } else if (property == crtc->iet_lut_property) {
+ ret = drm_property_replace_blob_from_id(dev,
+ &state->iet_lut,
+ val,
+ -1,
+ sizeof(struct drm_iet_1dlut_sample),
+ &replaced);
+ state->iet_lut_updated |= replaced;
+ return ret;
} else if (property == crtc->scaling_filter_property) {
state->scaling_filter = val;
} else if (crtc->funcs->atomic_set_property) {
@@ -467,6 +476,10 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->histogram_enable) ? state->histogram_enable->base.id : 0;
else if (property == crtc->histogram_data_property)
*val = (state->histogram_data) ? state->histogram_data->base.id : 0;
+ else if (property == crtc->iet_lut_caps_property)
+ *val = (state->iet_lut_caps) ? state->iet_lut_caps->base.id : 0;
+ else if (property == crtc->iet_lut_property)
+ *val = (state->iet_lut) ? state->iet_lut->base.id : 0;
else if (property == crtc->scaling_filter_property)
*val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d10b29aff725e40bdb93e6bd0828347db40fa3e8..850d98d7f9c8965c7a5e9ac5505e355042041449 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1032,3 +1032,57 @@ int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
return 0;
}
EXPORT_SYMBOL(drm_crtc_create_histogram_property);
+
+/**
+ * drm_crtc_create_iet_lut_property
+ *
+ * @crtc: pointer to the struct drm_crtc.
+ * @caps: pointer to the struct drm_iet_caps, holds the
+ * image enhancement LUT hardware capabilities.
+ *
+ * This 1DLUT is used by the hardware to enahance the image. Hardware
+ * interpolates this LUT value to generate the enhanced output image.
+ *
+ * The blob property IET_LUT_CAPS points to the struct drm_iet_lut_caps
+ * The blob property IET_LUT points to the struct drm_iet_1dlut_sample
+ * Description of the structure is in include/uapi/drm/drm_mode.h
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_crtc_create_iet_lut_property(struct drm_crtc *crtc,
+ struct drm_iet_caps *caps)
+{
+ struct drm_property *prop;
+ struct drm_iet_caps *blob_data;
+ struct drm_property_blob *blob;
+
+ blob = drm_property_create_blob(crtc->dev,
+ sizeof(struct drm_iet_caps),
+ NULL);
+ if (IS_ERR(blob))
+ return -1;
+ blob_data = blob->data;
+ blob_data->iet_mode = caps->iet_mode;
+ blob_data->nr_iet_sample_formats = caps->nr_iet_sample_formats;
+ blob_data->nr_iet_lut_entries = caps->nr_iet_lut_entries;
+ blob_data->iet_sample_format = caps->iet_sample_format;
+
+ prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "IET_LUT_CAPS", blob->base.id);
+ if (!prop)
+ return -ENOMEM;
+ drm_object_attach_property(&crtc->base, prop, 0);
+ crtc->iet_lut_caps_property = prop;
+
+ prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
+ DRM_MODE_PROP_BLOB, "IET_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+ drm_object_attach_property(&crtc->base, prop, 0);
+ crtc->iet_lut_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_crtc_create_iet_lut_property);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2da803749bdf03c07268be4e075793ef4e4eb99a..bc85ab16d5c817773a1d8b415eb256d08c13c709 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -300,6 +300,29 @@ struct drm_crtc_state {
struct drm_property_blob *histogram_data;
bool histogram_updated;
+ /**
+ * @iet_lut_caps:
+ *
+ * The blob points to the structure drm_iet_lut_caps.
+ * For more info on the elements of the struct drm_iet_lut_caps
+ * see include/uapi/drm/drm_mode.h
+ */
+ struct drm_property_blob *iet_lut_caps;
+ /**
+ * @iet_lut:
+ *
+ * The blob points to the struct drm_lut_sample
+ * For more information on the elements of struct drm_lut_sample
+ * see include/uapi/drm/drm_mode.h
+ */
+ struct drm_property_blob *iet_lut;
+ /**
+ * @iet_lut_updates:
+ *
+ * Convey that the image enhanced data has been updated by the user
+ */
+ bool iet_lut_updated;
+
/**
* @target_vblank:
*
@@ -1130,6 +1153,17 @@ struct drm_crtc {
*/
struct drm_property *histogram_data_property;
+ /**
+ * @iet_lut_caps_property: Optional CRTC property for getting the
+ * iet LUT hardware capability.
+ */
+ struct drm_property *iet_lut_caps_property;
+ /**
+ * @iet_lut_proeprty: Optional CRTC property for writing the
+ * image enhanced LUT
+ */
+ struct drm_property *iet_lut_property;
+
/**
* @state:
*
@@ -1368,4 +1402,6 @@ int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
bool drm_crtc_in_clone_mode(struct drm_crtc_state *crtc_state);
int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
struct drm_histogram_caps *caps);
+int drm_crtc_create_iet_lut_property(struct drm_crtc *crtc,
+ struct drm_iet_caps *caps);
#endif /* __DRM_CRTC_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for IET LUT
2025-01-28 15:51 ` [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for IET LUT Arun R Murthy
@ 2025-02-14 9:47 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 9:47 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for
> IET LUT
>
> Add drm-crtc property for IET 1DLUT and for the properties added add
Nit: Fix Grammar * added. Add
Do the same in previous patch as well
> corresponding get/set_property.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9 ++++++
> drivers/gpu/drm/drm_atomic_uapi.c | 13 ++++++++
> drivers/gpu/drm/drm_crtc.c | 54
> +++++++++++++++++++++++++++++++
> include/drm/drm_crtc.h | 36 +++++++++++++++++++++
> 4 files changed, 112 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index
> dfe6293f7a42d034da3de593094019ca15014a02..ceab90cec57cc580afcf334e27
> 5982827e9b0e0d 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -149,6 +149,10 @@ void
> __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
> drm_property_blob_get(state->histogram_enable);
> if (state->histogram_data)
> drm_property_blob_get(state->histogram_data);
> + if (state->iet_lut_caps)
> + drm_property_blob_get(state->iet_lut_caps);
> + if (state->iet_lut)
> + drm_property_blob_get(state->iet_lut);
> state->mode_changed = false;
> state->active_changed = false;
> state->planes_changed = false;
> @@ -164,6 +168,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
> state->self_refresh_active = false;
>
> state->histogram_updated = false;
> + state->iet_lut_updated = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> @@ -229,6 +234,10 @@ void __drm_atomic_helper_crtc_destroy_state(struct
> drm_crtc_state *state)
> drm_property_blob_put(state->histogram_enable);
> if (state->histogram_data)
> drm_property_blob_put(state->histogram_data);
> + if (state->iet_lut_caps)
> + drm_property_blob_put(state->iet_lut_caps);
> + if (state->iet_lut)
> + drm_property_blob_put(state->iet_lut);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index
> 459d30898196c94392a7f916b1fa9ca3a334eea8..f31d24d80cc082b38c611b12f3
> 6f281fa7404869 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -424,6 +424,15 @@ static int drm_atomic_crtc_set_property(struct
> drm_crtc *crtc,
> &replaced);
> state->histogram_updated |= replaced;
> return ret;
> + } else if (property == crtc->iet_lut_property) {
> + ret = drm_property_replace_blob_from_id(dev,
> + &state->iet_lut,
> + val,
> + -1,
> + sizeof(struct
> drm_iet_1dlut_sample),
> + &replaced);
> + state->iet_lut_updated |= replaced;
> + return ret;
> } else if (property == crtc->scaling_filter_property) {
> state->scaling_filter = val;
> } else if (crtc->funcs->atomic_set_property) { @@ -467,6 +476,10 @@
> drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->histogram_enable) ? state->histogram_enable-
> >base.id : 0;
> else if (property == crtc->histogram_data_property)
> *val = (state->histogram_data) ? state->histogram_data-
> >base.id : 0;
> + else if (property == crtc->iet_lut_caps_property)
> + *val = (state->iet_lut_caps) ? state->iet_lut_caps->base.id : 0;
> + else if (property == crtc->iet_lut_property)
> + *val = (state->iet_lut) ? state->iet_lut->base.id : 0;
> else if (property == crtc->scaling_filter_property)
> *val = state->scaling_filter;
> else if (crtc->funcs->atomic_get_property)
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index
> d10b29aff725e40bdb93e6bd0828347db40fa3e8..850d98d7f9c8965c7a5e9ac55
> 05e355042041449 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1032,3 +1032,57 @@ int drm_crtc_create_histogram_property(struct
> drm_crtc *crtc,
> return 0;
> }
> EXPORT_SYMBOL(drm_crtc_create_histogram_property);
> +
> +/**
> + * drm_crtc_create_iet_lut_property
> + *
> + * @crtc: pointer to the struct drm_crtc.
> + * @caps: pointer to the struct drm_iet_caps, holds the
> + * image enhancement LUT hardware capabilities.
> + *
> + * This 1DLUT is used by the hardware to enahance the image. Hardware
> + * interpolates this LUT value to generate the enhanced output image.
> + *
> + * The blob property IET_LUT_CAPS points to the struct drm_iet_lut_caps
> + * The blob property IET_LUT points to the struct drm_iet_1dlut_sample
> + * Description of the structure is in include/uapi/drm/drm_mode.h
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +int drm_crtc_create_iet_lut_property(struct drm_crtc *crtc,
> + struct drm_iet_caps *caps)
> +{
> + struct drm_property *prop;
> + struct drm_iet_caps *blob_data;
> + struct drm_property_blob *blob;
> +
> + blob = drm_property_create_blob(crtc->dev,
> + sizeof(struct drm_iet_caps),
> + NULL);
> + if (IS_ERR(blob))
> + return -1;
Use PTR_ERR(blob) to return error instead of directly returning -1
And add new line after the if.
> + blob_data = blob->data;
> + blob_data->iet_mode = caps->iet_mode;
Shouldn't we be Oring this
> + blob_data->nr_iet_sample_formats = caps->nr_iet_sample_formats;
> + blob_data->nr_iet_lut_entries = caps->nr_iet_lut_entries;
> + blob_data->iet_sample_format = caps->iet_sample_format;
> +
> + prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
> + DRM_MODE_PROP_IMMUTABLE |
> DRM_MODE_PROP_BLOB,
> + "IET_LUT_CAPS", blob->base.id);
> + if (!prop)
> + return -ENOMEM;
Ditto
> + drm_object_attach_property(&crtc->base, prop, 0);
> + crtc->iet_lut_caps_property = prop;
> +
> + prop = drm_property_create(crtc->dev, DRM_MODE_PROP_ATOMIC |
> + DRM_MODE_PROP_BLOB, "IET_LUT", 0);
> + if (!prop)
> + return -ENOMEM;
Here too.
> + drm_object_attach_property(&crtc->base, prop, 0);
> + crtc->iet_lut_property = prop;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_crtc_create_iet_lut_property);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> 2da803749bdf03c07268be4e075793ef4e4eb99a..bc85ab16d5c817773a1d8b415
> eb256d08c13c709 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -300,6 +300,29 @@ struct drm_crtc_state {
> struct drm_property_blob *histogram_data;
> bool histogram_updated;
>
> + /**
> + * @iet_lut_caps:
> + *
> + * The blob points to the structure drm_iet_lut_caps.
> + * For more info on the elements of the struct drm_iet_lut_caps
> + * see include/uapi/drm/drm_mode.h
Don’t see the need of this
> + */
> + struct drm_property_blob *iet_lut_caps;
> + /**
> + * @iet_lut:
> + *
> + * The blob points to the struct drm_lut_sample
> + * For more information on the elements of struct drm_lut_sample
> + * see include/uapi/drm/drm_mode.h
Same here
Regards,
Suraj Kandpal
> + */
> + struct drm_property_blob *iet_lut;
> + /**
> + * @iet_lut_updates:
> + *
> + * Convey that the image enhanced data has been updated by the user
> + */
> + bool iet_lut_updated;
> +
> /**
> * @target_vblank:
> *
> @@ -1130,6 +1153,17 @@ struct drm_crtc {
> */
> struct drm_property *histogram_data_property;
>
> + /**
> + * @iet_lut_caps_property: Optional CRTC property for getting the
> + * iet LUT hardware capability.
> + */
> + struct drm_property *iet_lut_caps_property;
> + /**
> + * @iet_lut_proeprty: Optional CRTC property for writing the
> + * image enhanced LUT
> + */
> + struct drm_property *iet_lut_property;
> +
> /**
> * @state:
> *
> @@ -1368,4 +1402,6 @@ int drm_crtc_create_scaling_filter_property(struct
> drm_crtc *crtc, bool drm_crtc_in_clone_mode(struct drm_crtc_state
> *crtc_state); int drm_crtc_create_histogram_property(struct drm_crtc *crtc,
> struct drm_histogram_caps *caps);
> +int drm_crtc_create_iet_lut_property(struct drm_crtc *crtc,
> + struct drm_iet_caps *caps);
> #endif /* __DRM_CRTC_H__ */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 05/14] drm/i915/histogram: Define registers for histogram
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (3 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 04/14] drm/crtc: Expose API to create drm crtc property for IET LUT Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 06/14] drm/i915/histogram: Add support " Arun R Murthy
` (11 subsequent siblings)
16 siblings, 0 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Add the register/bit definitions for global histogram.
v2: Intended the register contents, removed unused regs (Jani)
Bspec: 4270
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
.../gpu/drm/i915/display/intel_histogram_regs.h | 48 ++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_histogram_regs.h b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
new file mode 100644
index 0000000000000000000000000000000000000000..1252b4f339a63f70f44e249bdeae87805bee20fc
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2024 Intel Corporation
+ */
+
+#ifndef __INTEL_HISTOGRAM_REGS_H__
+#define __INTEL_HISTOGRAM_REGS_H__
+
+#include "intel_display_reg_defs.h"
+
+/* GLOBAL_HIST related registers */
+#define _DPST_CTL_A 0x490C0
+#define _DPST_CTL_B 0x491C0
+#define DPST_CTL(pipe) _MMIO_PIPE(pipe, _DPST_CTL_A, _DPST_CTL_B)
+#define DPST_CTL_IE_HIST_EN REG_BIT(31)
+#define DPST_CTL_RESTORE REG_BIT(28)
+#define DPST_CTL_IE_MODI_TABLE_EN REG_BIT(27)
+#define DPST_CTL_HIST_MODE REG_BIT(24)
+#define DPST_CTL_ENHANCEMENT_MODE_MASK REG_GENMASK(14, 13)
+#define DPST_CTL_EN_MULTIPLICATIVE REG_FIELD_PREP(DPST_CTL_ENHANCEMENT_MODE_MASK, 2)
+#define DPST_CTL_IE_TABLE_VALUE_FORMAT REG_BIT(15)
+#define DPST_CTL_BIN_REG_FUNC_SEL REG_BIT(11)
+#define DPST_CTL_BIN_REG_FUNC_TC REG_FIELD_PREP(DPST_CTL_BIN_REG_FUNC_SEL, 0)
+#define DPST_CTL_BIN_REG_FUNC_IE REG_FIELD_PREP(DPST_CTL_BIN_REG_FUNC_SEL, 1)
+#define DPST_CTL_BIN_REG_MASK REG_GENMASK(6, 0)
+#define DPST_CTL_BIN_REG_CLEAR REG_FIELD_PREP(DPST_CTL_BIN_REG_MASK, 0)
+#define DPST_CTL_IE_TABLE_VALUE_FORMAT_2INT_8FRAC REG_FIELD_PREP(DPST_CTL_IE_TABLE_VALUE_FORMAT, 1)
+#define DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC REG_FIELD_PREP(DPST_CTL_IE_TABLE_VALUE_FORMAT, 0)
+#define DPST_CTL_HIST_MODE_YUV REG_FIELD_PREP(DPST_CTL_HIST_MODE, 0)
+#define DPST_CTL_HIST_MODE_HSV REG_FIELD_PREP(DPST_CTL_HIST_MODE, 1)
+
+#define _DPST_GUARD_A 0x490C8
+#define _DPST_GUARD_B 0x491C8
+#define DPST_GUARD(pipe) _MMIO_PIPE(pipe, _DPST_GUARD_A, _DPST_GUARD_B)
+#define DPST_GUARD_HIST_INT_EN REG_BIT(31)
+#define DPST_GUARD_HIST_EVENT_STATUS REG_BIT(30)
+#define DPST_GUARD_INTERRUPT_DELAY_MASK REG_GENMASK(29, 22)
+#define DPST_GUARD_INTERRUPT_DELAY(val) REG_FIELD_PREP(DPST_GUARD_INTERRUPT_DELAY_MASK, val)
+#define DPST_GUARD_THRESHOLD_GB_MASK REG_GENMASK(21, 0)
+#define DPST_GUARD_THRESHOLD_GB(val) REG_FIELD_PREP(DPST_GUARD_THRESHOLD_GB_MASK, val)
+
+#define _DPST_BIN_A 0x490C4
+#define _DPST_BIN_B 0x491C4
+#define DPST_BIN(pipe) _MMIO_PIPE(pipe, _DPST_BIN_A, _DPST_BIN_B)
+#define DPST_BIN_DATA_MASK REG_GENMASK(23, 0)
+#define DPST_BIN_BUSY REG_BIT(31)
+
+#endif /* __INTEL_HISTOGRAM_REGS_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (4 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 05/14] drm/i915/histogram: Define registers for histogram Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 10:02 ` Kandpal, Suraj
2025-02-16 14:32 ` [v8,06/14] " Thasleem, Mohammed
2025-01-28 15:51 ` [PATCH v8 07/14] drm/xe: Add histogram support to Xe builds Arun R Murthy
` (10 subsequent siblings)
16 siblings, 2 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Statistics is generated from the image frame that is coming to display
and an event is sent to user after reading this histogram data.
v2: forward declaration in header file along with error handling (Jani)
v3: Replaced i915 with intel_display (Suraj)
v4: Removed dithering enable/disable (Vandita)
New patch for histogram register definitions (Suraj)
v5: IET LUT pgm follow the seq in spec and removed change to TC at end
(Suraj)
v8: Retained only the Histogram part and move IET LUT to a different
patch.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display_types.h | 2 +
drivers/gpu/drm/i915/display/intel_histogram.c | 157 +++++++++++++++++++++
drivers/gpu/drm/i915/display/intel_histogram.h | 48 +++++++
4 files changed, 208 insertions(+)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4caa8e30bc98387d45212fbc7cea8b38687bd0d5..f993b19174ba79c0bcc34994619937be7d2797ed 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -270,6 +270,7 @@ i915-y += \
display/intel_hdcp.o \
display/intel_hdcp_gsc.o \
display/intel_hdcp_gsc_message.o \
+ display/intel_histogram.o \
display/intel_hotplug.o \
display/intel_hotplug_irq.o \
display/intel_hti.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index cb51b7936f9338caaf14b1c6f7bbcc4327da4ef1..761fefed9376439c0ee5d346e8110a219ad0a586 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1434,6 +1434,8 @@ struct intel_crtc {
/* for loading single buffered registers during vblank */
struct pm_qos_request vblank_pm_qos;
+ struct intel_histogram *histogram;
+
#ifdef CONFIG_DEBUG_FS
struct intel_pipe_crc pipe_crc;
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
new file mode 100644
index 0000000000000000000000000000000000000000..26eae8f40d0bf642546d583546782e22d5cefa9c
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#include <drm/drm_device.h>
+#include <drm/drm_file.h>
+#include <drm/drm_vblank.h>
+
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "intel_de.h"
+#include "intel_display.h"
+#include "intel_display_types.h"
+#include "intel_histogram.h"
+#include "intel_histogram_regs.h"
+
+/* 3.0% of the pipe's current pixel count, hw does x4 */
+#define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
+/* Precision factor for threshold guardband */
+#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000
+#define HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
+
+int intel_histogram_atomic_check(struct intel_crtc *intel_crtc)
+{
+ struct intel_histogram *histogram = intel_crtc->histogram;
+
+ /* TODO: Restrictions for enabling histogram */
+ histogram->can_enable = true;
+
+ return 0;
+}
+
+static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8 mode)
+{
+ struct intel_display *display = to_intel_display(intel_crtc);
+ struct intel_histogram *histogram = intel_crtc->histogram;
+ int pipe = intel_crtc->pipe;
+ u64 res;
+ u32 gbandthreshold;
+
+ if (!histogram || !histogram->can_enable)
+ return -EINVAL;
+
+ if (histogram->enable)
+ return 0;
+
+ /* enable histogram, clear DPST_CTL bin reg func select to TC */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE | DPST_CTL_IE_TABLE_VALUE_FORMAT |
+ DPST_CTL_ENHANCEMENT_MODE_MASK | DPST_CTL_IE_MODI_TABLE_EN,
+ ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
+ DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE_HSV |
+ DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
+ DPST_CTL_EN_MULTIPLICATIVE | DPST_CTL_IE_MODI_TABLE_EN);
+
+ /* Re-Visit: check if wait for one vblank is required */
+ drm_crtc_wait_one_vblank(&intel_crtc->base);
+
+ /* TODO: Program GuardBand Threshold needs to be moved to modeset path */
+ res = (intel_crtc->config->hw.adjusted_mode.vtotal *
+ intel_crtc->config->hw.adjusted_mode.htotal);
+
+ gbandthreshold = (res * HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT) /
+ HISTOGRAM_GUARDBAND_PRECISION_FACTOR;
+
+ /* Enable histogram interrupt mode */
+ intel_de_rmw(display, DPST_GUARD(pipe),
+ DPST_GUARD_THRESHOLD_GB_MASK |
+ DPST_GUARD_INTERRUPT_DELAY_MASK | DPST_GUARD_HIST_INT_EN,
+ DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
+ DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY) |
+ DPST_GUARD_HIST_INT_EN);
+
+ /* Clear pending interrupts has to be done on separate write */
+ intel_de_rmw(display, DPST_GUARD(pipe),
+ DPST_GUARD_HIST_EVENT_STATUS, 1);
+
+ histogram->enable = true;
+
+ return 0;
+}
+
+static void intel_histogram_disable(struct intel_crtc *intel_crtc)
+{
+ struct intel_display *display = to_intel_display(intel_crtc);
+ struct intel_histogram *histogram = intel_crtc->histogram;
+ int pipe = intel_crtc->pipe;
+
+ if (!histogram)
+ return;
+
+ /* If already disabled return */
+ if (histogram->enable)
+ return;
+
+ /* Clear pending interrupts and disable interrupts */
+ intel_de_rmw(display, DPST_GUARD(pipe),
+ DPST_GUARD_HIST_INT_EN | DPST_GUARD_HIST_EVENT_STATUS, 0);
+
+ /* disable DPST_CTL Histogram mode */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_IE_HIST_EN, 0);
+
+ histogram->enable = false;
+}
+
+int intel_histogram_update(struct intel_crtc *intel_crtc,
+ struct drm_histogram_config *config)
+{
+ struct intel_display *display = to_intel_display(intel_crtc);
+
+ if (config->enable) {
+ if (config->hist_mode != DRM_MODE_HISTOGRAM_HSV_MAX_RGB) {
+ drm_err(display->drm,
+ "Only max(RGB) mode is supported for histogram\n");
+ return -EINVAL;
+ }
+ return intel_histogram_enable(intel_crtc, config->hist_mode);
+ }
+
+ intel_histogram_disable(intel_crtc);
+ return 0;
+}
+
+void intel_histogram_finish(struct intel_crtc *intel_crtc)
+{
+ struct intel_histogram *histogram = intel_crtc->histogram;
+
+ kfree(histogram);
+}
+
+int intel_histogram_init(struct intel_crtc *crtc)
+{
+ struct intel_histogram *histogram;
+ struct drm_histogram_caps *histogram_caps;
+
+ /* Allocate histogram internal struct */
+ histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
+ if (!histogram)
+ return -ENOMEM;
+ histogram_caps = kzalloc(sizeof(*histogram_caps), GFP_KERNEL);
+ if (!histogram_caps)
+ return -ENOMEM;
+
+ histogram_caps->histogram_mode = DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
+ histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
+
+ crtc->histogram = histogram;
+ histogram->crtc = crtc;
+ histogram->can_enable = false;
+ histogram->caps = histogram_caps;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h b/drivers/gpu/drm/i915/display/intel_histogram.h
new file mode 100644
index 0000000000000000000000000000000000000000..5ea19ef2d3ecadf1ac159a784f51278fdde593de
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_histogram.h
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#ifndef __INTEL_HISTOGRAM_H__
+#define __INTEL_HISTOGRAM_H__
+
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+struct delayed_work;
+struct drm_property_blob;
+struct drm_histogram_config;
+struct drm_histogram_caps;
+struct intel_crtc;
+
+#define HISTOGRAM_BIN_COUNT 32
+
+struct intel_histogram {
+ struct drm_histogram_caps *caps;
+ struct intel_crtc *crtc;
+ struct delayed_work work;
+ bool enable;
+ bool can_enable;
+ u32 bin_data[HISTOGRAM_BIN_COUNT];
+};
+
+enum intel_global_hist_status {
+ INTEL_HISTOGRAM_ENABLE,
+ INTEL_HISTOGRAM_DISABLE,
+};
+
+enum intel_global_histogram {
+ INTEL_HISTOGRAM,
+};
+
+enum intel_global_hist_lut {
+ INTEL_HISTOGRAM_PIXEL_FACTOR,
+};
+
+int intel_histogram_atomic_check(struct intel_crtc *intel_crtc);
+int intel_histogram_update(struct intel_crtc *intel_crtc,
+ struct drm_histogram_config *config);
+int intel_histogram_init(struct intel_crtc *intel_crtc);
+void intel_histogram_finish(struct intel_crtc *intel_crtc);
+
+#endif /* __INTEL_HISTOGRAM_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
2025-01-28 15:51 ` [PATCH v8 06/14] drm/i915/histogram: Add support " Arun R Murthy
@ 2025-02-14 10:02 ` Kandpal, Suraj
2025-02-14 10:24 ` Kandpal, Suraj
2025-02-16 14:32 ` [v8,06/14] " Thasleem, Mohammed
1 sibling, 1 reply; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 10:02 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
>
> Statistics is generated from the image frame that is coming to display and an
> event is sent to user after reading this histogram data.
>
> v2: forward declaration in header file along with error handling (Jani)
> v3: Replaced i915 with intel_display (Suraj)
> v4: Removed dithering enable/disable (Vandita)
> New patch for histogram register definitions (Suraj)
> v5: IET LUT pgm follow the seq in spec and removed change to TC at end
> (Suraj)
> v8: Retained only the Histogram part and move IET LUT to a different
> patch.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 +
> drivers/gpu/drm/i915/display/intel_histogram.c | 157
> +++++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_histogram.h | 48 +++++++
> 4 files changed, 208 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index
> 4caa8e30bc98387d45212fbc7cea8b38687bd0d5..f993b19174ba79c0bcc349946
> 19937be7d2797ed 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -270,6 +270,7 @@ i915-y += \
> display/intel_hdcp.o \
> display/intel_hdcp_gsc.o \
> display/intel_hdcp_gsc_message.o \
> + display/intel_histogram.o \
> display/intel_hotplug.o \
> display/intel_hotplug_irq.o \
> display/intel_hti.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index
> cb51b7936f9338caaf14b1c6f7bbcc4327da4ef1..761fefed9376439c0ee5d346e81
> 10a219ad0a586 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1434,6 +1434,8 @@ struct intel_crtc {
> /* for loading single buffered registers during vblank */
> struct pm_qos_request vblank_pm_qos;
>
> + struct intel_histogram *histogram;
> +
> #ifdef CONFIG_DEBUG_FS
> struct intel_pipe_crc pipe_crc;
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> new file mode 100644
> index
> 0000000000000000000000000000000000000000..26eae8f40d0bf642546d5835
> 46782e22d5cefa9c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#include <drm/drm_device.h>
> +#include <drm/drm_file.h>
> +#include <drm/drm_vblank.h>
> +
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "intel_de.h"
> +#include "intel_display.h"
> +#include "intel_display_types.h"
> +#include "intel_histogram.h"
> +#include "intel_histogram_regs.h"
> +
> +/* 3.0% of the pipe's current pixel count, hw does x4 */ #define
> +HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
> +/* Precision factor for threshold guardband */ #define
> +HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000 #define
> +HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> +
> +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) {
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + /* TODO: Restrictions for enabling histogram */
> + histogram->can_enable = true;
We don’t change anything in the intel_crtc structure during compute or atomic check phase
We need to consider moving this to the crtc_state.
> +
> + return 0;
> +}
> +
> +static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8
> +mode) {
> + struct intel_display *display = to_intel_display(intel_crtc);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> + u64 res;
> + u32 gbandthreshold;
> +
> + if (!histogram || !histogram->can_enable)
> + return -EINVAL;
> +
> + if (histogram->enable)
> + return 0;
> +
> + /* enable histogram, clear DPST_CTL bin reg func select to TC */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE |
> DPST_CTL_IE_TABLE_VALUE_FORMAT |
> + DPST_CTL_ENHANCEMENT_MODE_MASK |
> DPST_CTL_IE_MODI_TABLE_EN,
> + ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> + DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN
> |
> + DPST_CTL_HIST_MODE_HSV |
> + DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
> + DPST_CTL_EN_MULTIPLICATIVE |
> DPST_CTL_IE_MODI_TABLE_EN);
> +
> + /* Re-Visit: check if wait for one vblank is required */
> + drm_crtc_wait_one_vblank(&intel_crtc->base);
> +
> + /* TODO: Program GuardBand Threshold needs to be moved to
> modeset path */
> + res = (intel_crtc->config->hw.adjusted_mode.vtotal *
> + intel_crtc->config->hw.adjusted_mode.htotal);
> +
> + gbandthreshold = (res *
> HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT) /
> + HISTOGRAM_GUARDBAND_PRECISION_FACTOR;
> +
> + /* Enable histogram interrupt mode */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_THRESHOLD_GB_MASK |
> + DPST_GUARD_INTERRUPT_DELAY_MASK |
> DPST_GUARD_HIST_INT_EN,
> + DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
> +
> DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY)
> |
> + DPST_GUARD_HIST_INT_EN);
> +
> + /* Clear pending interrupts has to be done on separate write */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_HIST_EVENT_STATUS, 1);
> +
> + histogram->enable = true;
> +
> + return 0;
> +}
> +
> +static void intel_histogram_disable(struct intel_crtc *intel_crtc) {
> + struct intel_display *display = to_intel_display(intel_crtc);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> +
> + if (!histogram)
> + return;
> +
> + /* If already disabled return */
> + if (histogram->enable)
> + return;
> +
> + /* Clear pending interrupts and disable interrupts */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_HIST_INT_EN |
> DPST_GUARD_HIST_EVENT_STATUS, 0);
> +
> + /* disable DPST_CTL Histogram mode */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_IE_HIST_EN, 0);
> +
> + histogram->enable = false;
> +}
> +
> +int intel_histogram_update(struct intel_crtc *intel_crtc,
> + struct drm_histogram_config *config) {
> + struct intel_display *display = to_intel_display(intel_crtc);
> +
> + if (config->enable) {
> + if (config->hist_mode !=
> DRM_MODE_HISTOGRAM_HSV_MAX_RGB) {
> + drm_err(display->drm,
> + "Only max(RGB) mode is supported for
> histogram\n");
> + return -EINVAL;
> + }
> + return intel_histogram_enable(intel_crtc, config->hist_mode);
> + }
> +
> + intel_histogram_disable(intel_crtc);
> + return 0;
> +}
> +
> +void intel_histogram_finish(struct intel_crtc *intel_crtc) {
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + kfree(histogram);
> +}
> +
> +int intel_histogram_init(struct intel_crtc *crtc) {
> + struct intel_histogram *histogram;
> + struct drm_histogram_caps *histogram_caps;
> +
> + /* Allocate histogram internal struct */
> + histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
> + if (!histogram)
> + return -ENOMEM;
New line here
> + histogram_caps = kzalloc(sizeof(*histogram_caps), GFP_KERNEL);
> + if (!histogram_caps)
> + return -ENOMEM;
> +
> + histogram_caps->histogram_mode =
> DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
> + histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
> +
Remove extra line
Regards,
Suraj Kandpal
> + crtc->histogram = histogram;
> + histogram->crtc = crtc;
> + histogram->can_enable = false;
> + histogram->caps = histogram_caps;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h
> b/drivers/gpu/drm/i915/display/intel_histogram.h
> new file mode 100644
> index
> 0000000000000000000000000000000000000000..5ea19ef2d3ecadf1ac159a78
> 4f51278fdde593de
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#ifndef __INTEL_HISTOGRAM_H__
> +#define __INTEL_HISTOGRAM_H__
> +
> +#include <linux/types.h>
> +#include <linux/workqueue.h>
> +
> +struct delayed_work;
> +struct drm_property_blob;
> +struct drm_histogram_config;
> +struct drm_histogram_caps;
> +struct intel_crtc;
> +
> +#define HISTOGRAM_BIN_COUNT 32
> +
> +struct intel_histogram {
> + struct drm_histogram_caps *caps;
> + struct intel_crtc *crtc;
> + struct delayed_work work;
> + bool enable;
> + bool can_enable;
> + u32 bin_data[HISTOGRAM_BIN_COUNT];
> +};
> +
> +enum intel_global_hist_status {
> + INTEL_HISTOGRAM_ENABLE,
> + INTEL_HISTOGRAM_DISABLE,
> +};
> +
> +enum intel_global_histogram {
> + INTEL_HISTOGRAM,
> +};
> +
> +enum intel_global_hist_lut {
> + INTEL_HISTOGRAM_PIXEL_FACTOR,
> +};
> +
> +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc); int
> +intel_histogram_update(struct intel_crtc *intel_crtc,
> + struct drm_histogram_config *config); int
> +intel_histogram_init(struct intel_crtc *intel_crtc); void
> +intel_histogram_finish(struct intel_crtc *intel_crtc);
> +
> +#endif /* __INTEL_HISTOGRAM_H__ */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
2025-02-14 10:02 ` Kandpal, Suraj
@ 2025-02-14 10:24 ` Kandpal, Suraj
2025-02-17 6:09 ` Kandpal, Suraj
0 siblings, 1 reply; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 10:24 UTC (permalink / raw)
To: Kandpal, Suraj, Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> Kandpal, Suraj
> Sent: Friday, February 14, 2025 3:32 PM
> To: Murthy, Arun R <arun.r.murthy@intel.com>; intel-xe@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: dmitry.baryshkov@linaro.org
> Subject: RE: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
>
>
>
> > -----Original Message-----
> > From: Murthy, Arun R <arun.r.murthy@intel.com>
> > Sent: Tuesday, January 28, 2025 9:21 PM
> > To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> > dri- devel@lists.freedesktop.org
> > Cc: Kandpal, Suraj <suraj.kandpal@intel.com>;
> > dmitry.baryshkov@linaro.org; Murthy, Arun R <arun.r.murthy@intel.com>
> > Subject: [PATCH v8 06/14] drm/i915/histogram: Add support for
> > histogram
> >
> > Statistics is generated from the image frame that is coming to display
> > and an event is sent to user after reading this histogram data.
> >
> > v2: forward declaration in header file along with error handling
> > (Jani)
> > v3: Replaced i915 with intel_display (Suraj)
> > v4: Removed dithering enable/disable (Vandita)
> > New patch for histogram register definitions (Suraj)
> > v5: IET LUT pgm follow the seq in spec and removed change to TC at end
> > (Suraj)
> > v8: Retained only the Histogram part and move IET LUT to a different
> > patch.
> >
> > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
LGTM,
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
> > ---
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/display/intel_display_types.h | 2 +
> > drivers/gpu/drm/i915/display/intel_histogram.c | 157
> > +++++++++++++++++++++
> > drivers/gpu/drm/i915/display/intel_histogram.h | 48 +++++++
> > 4 files changed, 208 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile index
> >
> 4caa8e30bc98387d45212fbc7cea8b38687bd0d5..f993b19174ba79c0bcc349946
> > 19937be7d2797ed 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -270,6 +270,7 @@ i915-y += \
> > display/intel_hdcp.o \
> > display/intel_hdcp_gsc.o \
> > display/intel_hdcp_gsc_message.o \
> > + display/intel_histogram.o \
> > display/intel_hotplug.o \
> > display/intel_hotplug_irq.o \
> > display/intel_hti.o \
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index
> >
> cb51b7936f9338caaf14b1c6f7bbcc4327da4ef1..761fefed9376439c0ee5d346e81
> > 10a219ad0a586 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1434,6 +1434,8 @@ struct intel_crtc {
> > /* for loading single buffered registers during vblank */
> > struct pm_qos_request vblank_pm_qos;
> >
> > + struct intel_histogram *histogram;
> > +
> > #ifdef CONFIG_DEBUG_FS
> > struct intel_pipe_crc pipe_crc;
> > #endif
> > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> > b/drivers/gpu/drm/i915/display/intel_histogram.c
> > new file mode 100644
> > index
> >
> 0000000000000000000000000000000000000000..26eae8f40d0bf642546d5835
> > 46782e22d5cefa9c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> > @@ -0,0 +1,157 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2025 Intel Corporation */
> > +
> > +#include <drm/drm_device.h>
> > +#include <drm/drm_file.h>
> > +#include <drm/drm_vblank.h>
> > +
> > +#include "i915_reg.h"
> > +#include "i915_drv.h"
> > +#include "intel_de.h"
> > +#include "intel_display.h"
> > +#include "intel_display_types.h"
> > +#include "intel_histogram.h"
> > +#include "intel_histogram_regs.h"
> > +
> > +/* 3.0% of the pipe's current pixel count, hw does x4 */ #define
> > +HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
> > +/* Precision factor for threshold guardband */ #define
> > +HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000 #define
> > +HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> > +
> > +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) {
> > + struct intel_histogram *histogram = intel_crtc->histogram;
> > +
> > + /* TODO: Restrictions for enabling histogram */
> > + histogram->can_enable = true;
>
> We don’t change anything in the intel_crtc structure during compute or atomic
> check phase We need to consider moving this to the crtc_state.
>
> > +
> > + return 0;
> > +}
> > +
> > +static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8
> > +mode) {
> > + struct intel_display *display = to_intel_display(intel_crtc);
> > + struct intel_histogram *histogram = intel_crtc->histogram;
> > + int pipe = intel_crtc->pipe;
> > + u64 res;
> > + u32 gbandthreshold;
> > +
> > + if (!histogram || !histogram->can_enable)
> > + return -EINVAL;
> > +
> > + if (histogram->enable)
> > + return 0;
> > +
> > + /* enable histogram, clear DPST_CTL bin reg func select to TC */
> > + intel_de_rmw(display, DPST_CTL(pipe),
> > + DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> > + DPST_CTL_HIST_MODE |
> > DPST_CTL_IE_TABLE_VALUE_FORMAT |
> > + DPST_CTL_ENHANCEMENT_MODE_MASK |
> > DPST_CTL_IE_MODI_TABLE_EN,
> > + ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> > + DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN
> > |
> > + DPST_CTL_HIST_MODE_HSV |
> > + DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
> > + DPST_CTL_EN_MULTIPLICATIVE |
> > DPST_CTL_IE_MODI_TABLE_EN);
> > +
> > + /* Re-Visit: check if wait for one vblank is required */
> > + drm_crtc_wait_one_vblank(&intel_crtc->base);
> > +
> > + /* TODO: Program GuardBand Threshold needs to be moved to
> > modeset path */
> > + res = (intel_crtc->config->hw.adjusted_mode.vtotal *
> > + intel_crtc->config->hw.adjusted_mode.htotal);
> > +
> > + gbandthreshold = (res *
> > HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT) /
> > + HISTOGRAM_GUARDBAND_PRECISION_FACTOR;
> > +
> > + /* Enable histogram interrupt mode */
> > + intel_de_rmw(display, DPST_GUARD(pipe),
> > + DPST_GUARD_THRESHOLD_GB_MASK |
> > + DPST_GUARD_INTERRUPT_DELAY_MASK |
> > DPST_GUARD_HIST_INT_EN,
> > + DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
> > +
> >
> DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY)
> > |
> > + DPST_GUARD_HIST_INT_EN);
> > +
> > + /* Clear pending interrupts has to be done on separate write */
> > + intel_de_rmw(display, DPST_GUARD(pipe),
> > + DPST_GUARD_HIST_EVENT_STATUS, 1);
> > +
> > + histogram->enable = true;
> > +
> > + return 0;
> > +}
> > +
> > +static void intel_histogram_disable(struct intel_crtc *intel_crtc) {
> > + struct intel_display *display = to_intel_display(intel_crtc);
> > + struct intel_histogram *histogram = intel_crtc->histogram;
> > + int pipe = intel_crtc->pipe;
> > +
> > + if (!histogram)
> > + return;
> > +
> > + /* If already disabled return */
> > + if (histogram->enable)
> > + return;
> > +
> > + /* Clear pending interrupts and disable interrupts */
> > + intel_de_rmw(display, DPST_GUARD(pipe),
> > + DPST_GUARD_HIST_INT_EN |
> > DPST_GUARD_HIST_EVENT_STATUS, 0);
> > +
> > + /* disable DPST_CTL Histogram mode */
> > + intel_de_rmw(display, DPST_CTL(pipe),
> > + DPST_CTL_IE_HIST_EN, 0);
> > +
> > + histogram->enable = false;
> > +}
> > +
> > +int intel_histogram_update(struct intel_crtc *intel_crtc,
> > + struct drm_histogram_config *config) {
> > + struct intel_display *display = to_intel_display(intel_crtc);
> > +
> > + if (config->enable) {
> > + if (config->hist_mode !=
> > DRM_MODE_HISTOGRAM_HSV_MAX_RGB) {
> > + drm_err(display->drm,
> > + "Only max(RGB) mode is supported for
> > histogram\n");
> > + return -EINVAL;
> > + }
> > + return intel_histogram_enable(intel_crtc, config->hist_mode);
> > + }
> > +
> > + intel_histogram_disable(intel_crtc);
> > + return 0;
> > +}
> > +
> > +void intel_histogram_finish(struct intel_crtc *intel_crtc) {
> > + struct intel_histogram *histogram = intel_crtc->histogram;
> > +
> > + kfree(histogram);
> > +}
> > +
> > +int intel_histogram_init(struct intel_crtc *crtc) {
> > + struct intel_histogram *histogram;
> > + struct drm_histogram_caps *histogram_caps;
> > +
> > + /* Allocate histogram internal struct */
> > + histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
> > + if (!histogram)
> > + return -ENOMEM;
>
> New line here
>
> > + histogram_caps = kzalloc(sizeof(*histogram_caps), GFP_KERNEL);
> > + if (!histogram_caps)
> > + return -ENOMEM;
> > +
> > + histogram_caps->histogram_mode =
> > DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
> > + histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
> > +
>
> Remove extra line
>
> Regards,
> Suraj Kandpal
> > + crtc->histogram = histogram;
> > + histogram->crtc = crtc;
> > + histogram->can_enable = false;
> > + histogram->caps = histogram_caps;
> > +
> > + return 0;
> > +}
> > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h
> > b/drivers/gpu/drm/i915/display/intel_histogram.h
> > new file mode 100644
> > index
> >
> 0000000000000000000000000000000000000000..5ea19ef2d3ecadf1ac159a78
> > 4f51278fdde593de
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> > @@ -0,0 +1,48 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2025 Intel Corporation */
> > +
> > +#ifndef __INTEL_HISTOGRAM_H__
> > +#define __INTEL_HISTOGRAM_H__
> > +
> > +#include <linux/types.h>
> > +#include <linux/workqueue.h>
> > +
> > +struct delayed_work;
> > +struct drm_property_blob;
> > +struct drm_histogram_config;
> > +struct drm_histogram_caps;
> > +struct intel_crtc;
> > +
> > +#define HISTOGRAM_BIN_COUNT 32
> > +
> > +struct intel_histogram {
> > + struct drm_histogram_caps *caps;
> > + struct intel_crtc *crtc;
> > + struct delayed_work work;
> > + bool enable;
> > + bool can_enable;
> > + u32 bin_data[HISTOGRAM_BIN_COUNT];
> > +};
> > +
> > +enum intel_global_hist_status {
> > + INTEL_HISTOGRAM_ENABLE,
> > + INTEL_HISTOGRAM_DISABLE,
> > +};
> > +
> > +enum intel_global_histogram {
> > + INTEL_HISTOGRAM,
> > +};
> > +
> > +enum intel_global_hist_lut {
> > + INTEL_HISTOGRAM_PIXEL_FACTOR,
> > +};
> > +
> > +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc); int
> > +intel_histogram_update(struct intel_crtc *intel_crtc,
> > + struct drm_histogram_config *config); int
> > +intel_histogram_init(struct intel_crtc *intel_crtc); void
> > +intel_histogram_finish(struct intel_crtc *intel_crtc);
> > +
> > +#endif /* __INTEL_HISTOGRAM_H__ */
> >
> > --
> > 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
2025-02-14 10:24 ` Kandpal, Suraj
@ 2025-02-17 6:09 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-17 6:09 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Kandpal, Suraj
> Sent: Friday, February 14, 2025 3:54 PM
> To: Kandpal, Suraj <suraj.kandpal@intel.com>; Murthy, Arun R
> <arun.r.murthy@intel.com>; intel-xe@lists.freedesktop.org; intel-
> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: dmitry.baryshkov@linaro.org
> Subject: RE: [PATCH v8 06/14] drm/i915/histogram: Add support for histogram
>
>
>
> > -----Original Message-----
> > From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
> > Kandpal, Suraj
> > Sent: Friday, February 14, 2025 3:32 PM
> > To: Murthy, Arun R <arun.r.murthy@intel.com>;
> > intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> > dri-devel@lists.freedesktop.org
> > Cc: dmitry.baryshkov@linaro.org
> > Subject: RE: [PATCH v8 06/14] drm/i915/histogram: Add support for
> > histogram
> >
> >
> >
> > > -----Original Message-----
> > > From: Murthy, Arun R <arun.r.murthy@intel.com>
> > > Sent: Tuesday, January 28, 2025 9:21 PM
> > > To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> > > dri- devel@lists.freedesktop.org
> > > Cc: Kandpal, Suraj <suraj.kandpal@intel.com>;
> > > dmitry.baryshkov@linaro.org; Murthy, Arun R
> > > <arun.r.murthy@intel.com>
> > > Subject: [PATCH v8 06/14] drm/i915/histogram: Add support for
> > > histogram
> > >
> > > Statistics is generated from the image frame that is coming to
> > > display and an event is sent to user after reading this histogram data.
> > >
> > > v2: forward declaration in header file along with error handling
> > > (Jani)
> > > v3: Replaced i915 with intel_display (Suraj)
> > > v4: Removed dithering enable/disable (Vandita)
> > > New patch for histogram register definitions (Suraj)
> > > v5: IET LUT pgm follow the seq in spec and removed change to TC at end
> > > (Suraj)
> > > v8: Retained only the Histogram part and move IET LUT to a different
> > > patch.
> > >
> > > Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>
> LGTM,
> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
I meant to send this to another patch in this series but sent it here this patch already has some comments of mine that need to be addressed
Don't consider this Rb
Regards,
Suraj Kandpal
>
> > > ---
> > > drivers/gpu/drm/i915/Makefile | 1 +
> > > drivers/gpu/drm/i915/display/intel_display_types.h | 2 +
> > > drivers/gpu/drm/i915/display/intel_histogram.c | 157
> > > +++++++++++++++++++++
> > > drivers/gpu/drm/i915/display/intel_histogram.h | 48 +++++++
> > > 4 files changed, 208 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > b/drivers/gpu/drm/i915/Makefile index
> > >
> >
> 4caa8e30bc98387d45212fbc7cea8b38687bd0d5..f993b19174ba79c0bcc349946
> > > 19937be7d2797ed 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -270,6 +270,7 @@ i915-y += \
> > > display/intel_hdcp.o \
> > > display/intel_hdcp_gsc.o \
> > > display/intel_hdcp_gsc_message.o \
> > > + display/intel_histogram.o \
> > > display/intel_hotplug.o \
> > > display/intel_hotplug_irq.o \
> > > display/intel_hti.o \
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index
> > >
> >
> cb51b7936f9338caaf14b1c6f7bbcc4327da4ef1..761fefed9376439c0ee5d346e8
> 1
> > > 10a219ad0a586 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1434,6 +1434,8 @@ struct intel_crtc {
> > > /* for loading single buffered registers during vblank */
> > > struct pm_qos_request vblank_pm_qos;
> > >
> > > + struct intel_histogram *histogram;
> > > +
> > > #ifdef CONFIG_DEBUG_FS
> > > struct intel_pipe_crc pipe_crc;
> > > #endif
> > > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> > > b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > new file mode 100644
> > > index
> > >
> >
> 0000000000000000000000000000000000000000..26eae8f40d0bf642546d5835
> > > 46782e22d5cefa9c
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> > > @@ -0,0 +1,157 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2025 Intel Corporation */
> > > +
> > > +#include <drm/drm_device.h>
> > > +#include <drm/drm_file.h>
> > > +#include <drm/drm_vblank.h>
> > > +
> > > +#include "i915_reg.h"
> > > +#include "i915_drv.h"
> > > +#include "intel_de.h"
> > > +#include "intel_display.h"
> > > +#include "intel_display_types.h"
> > > +#include "intel_histogram.h"
> > > +#include "intel_histogram_regs.h"
> > > +
> > > +/* 3.0% of the pipe's current pixel count, hw does x4 */ #define
> > > +HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
> > > +/* Precision factor for threshold guardband */ #define
> > > +HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000 #define
> > > +HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> > > +
> > > +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) {
> > > + struct intel_histogram *histogram = intel_crtc->histogram;
> > > +
> > > + /* TODO: Restrictions for enabling histogram */
> > > + histogram->can_enable = true;
> >
> > We don’t change anything in the intel_crtc structure during compute or
> > atomic check phase We need to consider moving this to the crtc_state.
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8
> > > +mode) {
> > > + struct intel_display *display = to_intel_display(intel_crtc);
> > > + struct intel_histogram *histogram = intel_crtc->histogram;
> > > + int pipe = intel_crtc->pipe;
> > > + u64 res;
> > > + u32 gbandthreshold;
> > > +
> > > + if (!histogram || !histogram->can_enable)
> > > + return -EINVAL;
> > > +
> > > + if (histogram->enable)
> > > + return 0;
> > > +
> > > + /* enable histogram, clear DPST_CTL bin reg func select to TC */
> > > + intel_de_rmw(display, DPST_CTL(pipe),
> > > + DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> > > + DPST_CTL_HIST_MODE |
> > > DPST_CTL_IE_TABLE_VALUE_FORMAT |
> > > + DPST_CTL_ENHANCEMENT_MODE_MASK |
> > > DPST_CTL_IE_MODI_TABLE_EN,
> > > + ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> > > + DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN
> > > |
> > > + DPST_CTL_HIST_MODE_HSV |
> > > + DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
> > > + DPST_CTL_EN_MULTIPLICATIVE |
> > > DPST_CTL_IE_MODI_TABLE_EN);
> > > +
> > > + /* Re-Visit: check if wait for one vblank is required */
> > > + drm_crtc_wait_one_vblank(&intel_crtc->base);
> > > +
> > > + /* TODO: Program GuardBand Threshold needs to be moved to
> > > modeset path */
> > > + res = (intel_crtc->config->hw.adjusted_mode.vtotal *
> > > + intel_crtc->config->hw.adjusted_mode.htotal);
> > > +
> > > + gbandthreshold = (res *
> > > HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT) /
> > > + HISTOGRAM_GUARDBAND_PRECISION_FACTOR;
> > > +
> > > + /* Enable histogram interrupt mode */
> > > + intel_de_rmw(display, DPST_GUARD(pipe),
> > > + DPST_GUARD_THRESHOLD_GB_MASK |
> > > + DPST_GUARD_INTERRUPT_DELAY_MASK |
> > > DPST_GUARD_HIST_INT_EN,
> > > + DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
> > > +
> > >
> >
> DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY
> )
> > > |
> > > + DPST_GUARD_HIST_INT_EN);
> > > +
> > > + /* Clear pending interrupts has to be done on separate write */
> > > + intel_de_rmw(display, DPST_GUARD(pipe),
> > > + DPST_GUARD_HIST_EVENT_STATUS, 1);
> > > +
> > > + histogram->enable = true;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void intel_histogram_disable(struct intel_crtc *intel_crtc) {
> > > + struct intel_display *display = to_intel_display(intel_crtc);
> > > + struct intel_histogram *histogram = intel_crtc->histogram;
> > > + int pipe = intel_crtc->pipe;
> > > +
> > > + if (!histogram)
> > > + return;
> > > +
> > > + /* If already disabled return */
> > > + if (histogram->enable)
> > > + return;
> > > +
> > > + /* Clear pending interrupts and disable interrupts */
> > > + intel_de_rmw(display, DPST_GUARD(pipe),
> > > + DPST_GUARD_HIST_INT_EN |
> > > DPST_GUARD_HIST_EVENT_STATUS, 0);
> > > +
> > > + /* disable DPST_CTL Histogram mode */
> > > + intel_de_rmw(display, DPST_CTL(pipe),
> > > + DPST_CTL_IE_HIST_EN, 0);
> > > +
> > > + histogram->enable = false;
> > > +}
> > > +
> > > +int intel_histogram_update(struct intel_crtc *intel_crtc,
> > > + struct drm_histogram_config *config) {
> > > + struct intel_display *display = to_intel_display(intel_crtc);
> > > +
> > > + if (config->enable) {
> > > + if (config->hist_mode !=
> > > DRM_MODE_HISTOGRAM_HSV_MAX_RGB) {
> > > + drm_err(display->drm,
> > > + "Only max(RGB) mode is supported for
> > > histogram\n");
> > > + return -EINVAL;
> > > + }
> > > + return intel_histogram_enable(intel_crtc, config->hist_mode);
> > > + }
> > > +
> > > + intel_histogram_disable(intel_crtc);
> > > + return 0;
> > > +}
> > > +
> > > +void intel_histogram_finish(struct intel_crtc *intel_crtc) {
> > > + struct intel_histogram *histogram = intel_crtc->histogram;
> > > +
> > > + kfree(histogram);
> > > +}
> > > +
> > > +int intel_histogram_init(struct intel_crtc *crtc) {
> > > + struct intel_histogram *histogram;
> > > + struct drm_histogram_caps *histogram_caps;
> > > +
> > > + /* Allocate histogram internal struct */
> > > + histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
> > > + if (!histogram)
> > > + return -ENOMEM;
> >
> > New line here
> >
> > > + histogram_caps = kzalloc(sizeof(*histogram_caps), GFP_KERNEL);
> > > + if (!histogram_caps)
> > > + return -ENOMEM;
> > > +
> > > + histogram_caps->histogram_mode =
> > > DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
> > > + histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
> > > +
> >
> > Remove extra line
> >
> > Regards,
> > Suraj Kandpal
> > > + crtc->histogram = histogram;
> > > + histogram->crtc = crtc;
> > > + histogram->can_enable = false;
> > > + histogram->caps = histogram_caps;
> > > +
> > > + return 0;
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h
> > > b/drivers/gpu/drm/i915/display/intel_histogram.h
> > > new file mode 100644
> > > index
> > >
> >
> 0000000000000000000000000000000000000000..5ea19ef2d3ecadf1ac159a78
> > > 4f51278fdde593de
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> > > @@ -0,0 +1,48 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2025 Intel Corporation */
> > > +
> > > +#ifndef __INTEL_HISTOGRAM_H__
> > > +#define __INTEL_HISTOGRAM_H__
> > > +
> > > +#include <linux/types.h>
> > > +#include <linux/workqueue.h>
> > > +
> > > +struct delayed_work;
> > > +struct drm_property_blob;
> > > +struct drm_histogram_config;
> > > +struct drm_histogram_caps;
> > > +struct intel_crtc;
> > > +
> > > +#define HISTOGRAM_BIN_COUNT 32
> > > +
> > > +struct intel_histogram {
> > > + struct drm_histogram_caps *caps;
> > > + struct intel_crtc *crtc;
> > > + struct delayed_work work;
> > > + bool enable;
> > > + bool can_enable;
> > > + u32 bin_data[HISTOGRAM_BIN_COUNT]; };
> > > +
> > > +enum intel_global_hist_status {
> > > + INTEL_HISTOGRAM_ENABLE,
> > > + INTEL_HISTOGRAM_DISABLE,
> > > +};
> > > +
> > > +enum intel_global_histogram {
> > > + INTEL_HISTOGRAM,
> > > +};
> > > +
> > > +enum intel_global_hist_lut {
> > > + INTEL_HISTOGRAM_PIXEL_FACTOR,
> > > +};
> > > +
> > > +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc);
> > > +int intel_histogram_update(struct intel_crtc *intel_crtc,
> > > + struct drm_histogram_config *config); int
> > > +intel_histogram_init(struct intel_crtc *intel_crtc); void
> > > +intel_histogram_finish(struct intel_crtc *intel_crtc);
> > > +
> > > +#endif /* __INTEL_HISTOGRAM_H__ */
> > >
> > > --
> > > 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [v8,06/14] drm/i915/histogram: Add support for histogram
2025-01-28 15:51 ` [PATCH v8 06/14] drm/i915/histogram: Add support " Arun R Murthy
2025-02-14 10:02 ` Kandpal, Suraj
@ 2025-02-16 14:32 ` Thasleem, Mohammed
1 sibling, 0 replies; 58+ messages in thread
From: Thasleem, Mohammed @ 2025-02-16 14:32 UTC (permalink / raw)
To: Arun R Murthy, intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov
Hi Arun,
On 1/28/2025 9:21 PM, Arun R Murthy wrote:
> Statistics is generated from the image frame that is coming to display
> and an event is sent to user after reading this histogram data.
>
> v2: forward declaration in header file along with error handling (Jani)
> v3: Replaced i915 with intel_display (Suraj)
> v4: Removed dithering enable/disable (Vandita)
> New patch for histogram register definitions (Suraj)
> v5: IET LUT pgm follow the seq in spec and removed change to TC at end
> (Suraj)
> v8: Retained only the Histogram part and move IET LUT to a different
> patch.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 +
> drivers/gpu/drm/i915/display/intel_histogram.c | 157 +++++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_histogram.h | 48 +++++++
> 4 files changed, 208 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4caa8e30bc98387d45212fbc7cea8b38687bd0d5..f993b19174ba79c0bcc34994619937be7d2797ed 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -270,6 +270,7 @@ i915-y += \
> display/intel_hdcp.o \
> display/intel_hdcp_gsc.o \
> display/intel_hdcp_gsc_message.o \
> + display/intel_histogram.o \
> display/intel_hotplug.o \
> display/intel_hotplug_irq.o \
> display/intel_hti.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index cb51b7936f9338caaf14b1c6f7bbcc4327da4ef1..761fefed9376439c0ee5d346e8110a219ad0a586 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1434,6 +1434,8 @@ struct intel_crtc {
> /* for loading single buffered registers during vblank */
> struct pm_qos_request vblank_pm_qos;
>
> + struct intel_histogram *histogram;
> +
> #ifdef CONFIG_DEBUG_FS
> struct intel_pipe_crc pipe_crc;
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..26eae8f40d0bf642546d583546782e22d5cefa9c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -0,0 +1,157 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#include <drm/drm_device.h>
> +#include <drm/drm_file.h>
> +#include <drm/drm_vblank.h>
> +
> +#include "i915_reg.h"
> +#include "i915_drv.h"
> +#include "intel_de.h"
> +#include "intel_display.h"
> +#include "intel_display_types.h"
> +#include "intel_histogram.h"
> +#include "intel_histogram_regs.h"
> +
> +/* 3.0% of the pipe's current pixel count, hw does x4 */
> +#define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
> +/* Precision factor for threshold guardband */
> +#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000
> +#define HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> +
> +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc)
> +{
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + /* TODO: Restrictions for enabling histogram */
> + histogram->can_enable = true;
> +
> + return 0;
> +}
> +
> +static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8 mode)
> +{
> + struct intel_display *display = to_intel_display(intel_crtc);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> + u64 res;
> + u32 gbandthreshold;
> +
> + if (!histogram || !histogram->can_enable)
> + return -EINVAL;
> +
> + if (histogram->enable)
> + return 0;
> +
> + /* enable histogram, clear DPST_CTL bin reg func select to TC */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE | DPST_CTL_IE_TABLE_VALUE_FORMAT |
> + DPST_CTL_ENHANCEMENT_MODE_MASK | DPST_CTL_IE_MODI_TABLE_EN,
> + ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> + DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE_HSV |
> + DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
> + DPST_CTL_EN_MULTIPLICATIVE | DPST_CTL_IE_MODI_TABLE_EN);
> +
> + /* Re-Visit: check if wait for one vblank is required */
> + drm_crtc_wait_one_vblank(&intel_crtc->base);
> +
> + /* TODO: Program GuardBand Threshold needs to be moved to modeset path */
> + res = (intel_crtc->config->hw.adjusted_mode.vtotal *
> + intel_crtc->config->hw.adjusted_mode.htotal);
> +
> + gbandthreshold = (res * HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT) /
> + HISTOGRAM_GUARDBAND_PRECISION_FACTOR;
> +
> + /* Enable histogram interrupt mode */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_THRESHOLD_GB_MASK |
> + DPST_GUARD_INTERRUPT_DELAY_MASK | DPST_GUARD_HIST_INT_EN,
> + DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
> + DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY) |
> + DPST_GUARD_HIST_INT_EN);
> +
> + /* Clear pending interrupts has to be done on separate write */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_HIST_EVENT_STATUS, 1);
> +
> + histogram->enable = true;
> +
> + return 0;
> +}
> +
> +static void intel_histogram_disable(struct intel_crtc *intel_crtc)
> +{
> + struct intel_display *display = to_intel_display(intel_crtc);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int pipe = intel_crtc->pipe;
> +
> + if (!histogram)
> + return;
> +
> + /* If already disabled return */
> + if (histogram->enable)
It should be !histogram->enable right?
Thanks,
Thasleem
> + return;
> +
> + /* Clear pending interrupts and disable interrupts */
> + intel_de_rmw(display, DPST_GUARD(pipe),
> + DPST_GUARD_HIST_INT_EN | DPST_GUARD_HIST_EVENT_STATUS, 0);
> +
> + /* disable DPST_CTL Histogram mode */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_IE_HIST_EN, 0);
> +
> + histogram->enable = false;
> +}
> +
> +int intel_histogram_update(struct intel_crtc *intel_crtc,
> + struct drm_histogram_config *config)
> +{
> + struct intel_display *display = to_intel_display(intel_crtc);
> +
> + if (config->enable) {
> + if (config->hist_mode != DRM_MODE_HISTOGRAM_HSV_MAX_RGB) {
> + drm_err(display->drm,
> + "Only max(RGB) mode is supported for histogram\n");
> + return -EINVAL;
> + }
> + return intel_histogram_enable(intel_crtc, config->hist_mode);
> + }
> +
> + intel_histogram_disable(intel_crtc);
> + return 0;
> +}
> +
> +void intel_histogram_finish(struct intel_crtc *intel_crtc)
> +{
> + struct intel_histogram *histogram = intel_crtc->histogram;
> +
> + kfree(histogram);
> +}
> +
> +int intel_histogram_init(struct intel_crtc *crtc)
> +{
> + struct intel_histogram *histogram;
> + struct drm_histogram_caps *histogram_caps;
> +
> + /* Allocate histogram internal struct */
> + histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
> + if (!histogram)
> + return -ENOMEM;
> + histogram_caps = kzalloc(sizeof(*histogram_caps), GFP_KERNEL);
> + if (!histogram_caps)
> + return -ENOMEM;
> +
> + histogram_caps->histogram_mode = DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
> + histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
> +
> + crtc->histogram = histogram;
> + histogram->crtc = crtc;
> + histogram->can_enable = false;
> + histogram->caps = histogram_caps;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h b/drivers/gpu/drm/i915/display/intel_histogram.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..5ea19ef2d3ecadf1ac159a784f51278fdde593de
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#ifndef __INTEL_HISTOGRAM_H__
> +#define __INTEL_HISTOGRAM_H__
> +
> +#include <linux/types.h>
> +#include <linux/workqueue.h>
> +
> +struct delayed_work;
> +struct drm_property_blob;
> +struct drm_histogram_config;
> +struct drm_histogram_caps;
> +struct intel_crtc;
> +
> +#define HISTOGRAM_BIN_COUNT 32
> +
> +struct intel_histogram {
> + struct drm_histogram_caps *caps;
> + struct intel_crtc *crtc;
> + struct delayed_work work;
> + bool enable;
> + bool can_enable;
> + u32 bin_data[HISTOGRAM_BIN_COUNT];
> +};
> +
> +enum intel_global_hist_status {
> + INTEL_HISTOGRAM_ENABLE,
> + INTEL_HISTOGRAM_DISABLE,
> +};
> +
> +enum intel_global_histogram {
> + INTEL_HISTOGRAM,
> +};
> +
> +enum intel_global_hist_lut {
> + INTEL_HISTOGRAM_PIXEL_FACTOR,
> +};
> +
> +int intel_histogram_atomic_check(struct intel_crtc *intel_crtc);
> +int intel_histogram_update(struct intel_crtc *intel_crtc,
> + struct drm_histogram_config *config);
> +int intel_histogram_init(struct intel_crtc *intel_crtc);
> +void intel_histogram_finish(struct intel_crtc *intel_crtc);
> +
> +#endif /* __INTEL_HISTOGRAM_H__ */
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 07/14] drm/xe: Add histogram support to Xe builds
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (5 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 06/14] drm/i915/histogram: Add support " Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling Arun R Murthy
` (9 subsequent siblings)
16 siblings, 0 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Histogram added as part of i915/display driver. Adding the same for xe
as well.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
drivers/gpu/drm/xe/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index 80ab87cfeecbcf9f64183e938a8b15efe71459ed..7ee23d31a1a3584852708c4e17ad179a47e5b6b9 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -248,6 +248,7 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_hdcp.o \
i915-display/intel_hdcp_gsc_message.o \
i915-display/intel_hdmi.o \
+ i915-display/intel_histogram.o \
i915-display/intel_hotplug.o \
i915-display/intel_hotplug_irq.o \
i915-display/intel_hti.o \
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (6 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 07/14] drm/xe: Add histogram support to Xe builds Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 10:19 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm histogram Arun R Murthy
` (8 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Upon enabling histogram an interrupt is trigerred after the generation
of the statistics. This patch registers the histogram interrupt and
handles the interrupt.
v2: Added intel_crtc backpointer to intel_histogram struct (Jani)
Removed histogram_wq and instead use dev_priv->unodered_eq (Jani)
v3: Replaced drm_i915_private with intel_display (Suraj)
Refactored the histogram read code (Jani)
v4: Rebased after addressing comments on patch 1
v5: removed the retry logic and moved to patch7 (Jani)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/display/intel_display_irq.c | 6 +-
drivers/gpu/drm/i915/display/intel_histogram.c | 106 ++++++++++++++++++++++-
drivers/gpu/drm/i915/display/intel_histogram.h | 3 +
drivers/gpu/drm/i915/i915_reg.h | 5 +-
4 files changed, 115 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c b/drivers/gpu/drm/i915/display/intel_display_irq.c
index d9734fcd0d45b9f7c2891730e73b7e1d59c206ad..b62c3cdfd6a0607d9d2e1caa0d71edb0aa99fdbb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_irq.c
+++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
@@ -21,6 +21,7 @@
#include "intel_fdi_regs.h"
#include "intel_fifo_underrun.h"
#include "intel_gmbus.h"
+#include "intel_histogram.h"
#include "intel_hotplug_irq.h"
#include "intel_pipe_crc_regs.h"
#include "intel_pmdemand.h"
@@ -1230,6 +1231,9 @@ void gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
if (iir & GEN8_PIPE_FIFO_UNDERRUN)
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
+ if (iir & GEN9_PIPE_HISTOGRAM_EVENT)
+ intel_histogram_irq_handler(display, pipe);
+
fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
if (fault_errors)
drm_err_ratelimited(&dev_priv->drm,
@@ -1827,7 +1831,7 @@ void gen8_de_irq_postinstall(struct drm_i915_private *dev_priv)
struct intel_display *display = &dev_priv->display;
u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) |
- GEN8_PIPE_CDCLK_CRC_DONE;
+ GEN8_PIPE_CDCLK_CRC_DONE | GEN9_PIPE_HISTOGRAM_EVENT;
u32 de_pipe_enables;
u32 de_port_masked = gen8_de_port_aux_mask(dev_priv);
u32 de_port_enables;
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
index 26eae8f40d0bf642546d583546782e22d5cefa9c..4f3dcbabfe96e955a65874718272c4beb53b0827 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.c
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -19,7 +19,104 @@
#define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
/* Precision factor for threshold guardband */
#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000
-#define HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
+#define HISTOGRAM_BIN_READ_RETRY_COUNT 5
+
+static bool intel_histogram_get_data(struct intel_crtc *intel_crtc)
+{
+ struct intel_display *display = to_intel_display(intel_crtc);
+ struct intel_histogram *histogram = intel_crtc->histogram;
+ int index;
+ u32 dpstbin;
+
+ for (index = 0; index < ARRAY_SIZE(histogram->bin_data); index++) {
+ dpstbin = intel_de_read(display, DPST_BIN(intel_crtc->pipe));
+ if (!(dpstbin & DPST_BIN_BUSY)) {
+ histogram->bin_data[index] = dpstbin & DPST_BIN_DATA_MASK;
+ } else
+ return false;
+ }
+ return true;
+}
+
+static void intel_histogram_handle_int_work(struct work_struct *work)
+{
+ struct intel_histogram *histogram = container_of(work,
+ struct intel_histogram, work.work);
+ struct intel_crtc *intel_crtc = histogram->crtc;
+ struct intel_display *display = to_intel_display(intel_crtc);
+ char event[] = "HISTOGRAM=1", pipe_id[21];
+ char *histogram_event[] = { event, pipe_id, NULL };
+ int retry;
+
+ snprintf(pipe_id, sizeof(pipe_id),
+ "PIPE=%u", intel_crtc->base.base.id);
+
+ /*
+ * TODO: PSR to be exited while reading the Histogram data
+ * Set DPST_CTL Bin Reg function select to TC
+ * Set DPST_CTL Bin Register Index to 0
+ */
+ intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_BIN_REG_MASK, 0);
+ for (retry = 0; retry < HISTOGRAM_BIN_READ_RETRY_COUNT; retry++) {
+ if (intel_histogram_get_data(intel_crtc)) {
+ u32 *data;
+ struct drm_histogram *hist;
+
+ data = kzalloc(sizeof(data) * sizeof(histogram->bin_data), GFP_KERNEL);
+ if (!data)
+ return;
+ memcpy(histogram->bin_data, data, sizeof(histogram->bin_data));
+ hist = kzalloc(sizeof(struct drm_histogram), GFP_KERNEL);
+ if (!hist)
+ return;
+ hist->data_ptr = *data;
+ hist->nr_elements = sizeof(histogram->bin_data);
+
+ /* TODO: fill the drm_histogram_config data back this drm_histogram struct */
+ drm_property_replace_global_blob(display->drm,
+ &intel_crtc->base.state->histogram_data,
+ sizeof(struct drm_histogram),
+ hist, &intel_crtc->base.base,
+ intel_crtc->base.histogram_data_property);
+ /* Notify user for Histogram readiness */
+ if (kobject_uevent_env(&display->drm->primary->kdev->kobj,
+ KOBJ_CHANGE, histogram_event))
+ drm_err(display->drm,
+ "Sending HISTOGRAM event failed\n");
+ break;
+ }
+ }
+ if (retry >= HISTOGRAM_BIN_READ_RETRY_COUNT) {
+ drm_err(display->drm, "Histogram bin read failed with max retry\n");
+ return;
+ }
+
+ /* Enable histogram interrupt */
+ intel_de_rmw(display, DPST_GUARD(intel_crtc->pipe), DPST_GUARD_HIST_INT_EN,
+ DPST_GUARD_HIST_INT_EN);
+
+ /* Clear histogram interrupt by setting histogram interrupt status bit*/
+ intel_de_rmw(display, DPST_GUARD(intel_crtc->pipe),
+ DPST_GUARD_HIST_EVENT_STATUS, 1);
+}
+
+void intel_histogram_irq_handler(struct intel_display *display, enum pipe pipe)
+{
+ struct intel_crtc *intel_crtc =
+ to_intel_crtc(drm_crtc_from_index(display->drm, pipe));
+ struct intel_histogram *histogram = intel_crtc->histogram;
+ struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
+
+ if (!histogram->enable) {
+ drm_err(display->drm,
+ "Spurious interrupt, histogram not enabled\n");
+ return;
+ }
+
+ queue_delayed_work(i915->unordered_wq,
+ &histogram->work, 0);
+}
int intel_histogram_atomic_check(struct intel_crtc *intel_crtc)
{
@@ -71,7 +168,7 @@ static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8 mode)
DPST_GUARD_THRESHOLD_GB_MASK |
DPST_GUARD_INTERRUPT_DELAY_MASK | DPST_GUARD_HIST_INT_EN,
DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
- DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY) |
+ DPST_GUARD_INTERRUPT_DELAY(0x04) |
DPST_GUARD_HIST_INT_EN);
/* Clear pending interrupts has to be done on separate write */
@@ -104,6 +201,7 @@ static void intel_histogram_disable(struct intel_crtc *intel_crtc)
intel_de_rmw(display, DPST_CTL(pipe),
DPST_CTL_IE_HIST_EN, 0);
+ cancel_delayed_work(&histogram->work);
histogram->enable = false;
}
@@ -129,6 +227,7 @@ void intel_histogram_finish(struct intel_crtc *intel_crtc)
{
struct intel_histogram *histogram = intel_crtc->histogram;
+ cancel_delayed_work_sync(&histogram->work);
kfree(histogram);
}
@@ -153,5 +252,8 @@ int intel_histogram_init(struct intel_crtc *crtc)
histogram->can_enable = false;
histogram->caps = histogram_caps;
+ INIT_DEFERRABLE_WORK(&histogram->work,
+ intel_histogram_handle_int_work);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h b/drivers/gpu/drm/i915/display/intel_histogram.h
index 5ea19ef2d3ecadf1ac159a784f51278fdde593de..b44ba3afc94f79f291f4e5ebdd04dcf9434b48a4 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.h
+++ b/drivers/gpu/drm/i915/display/intel_histogram.h
@@ -14,6 +14,8 @@ struct drm_property_blob;
struct drm_histogram_config;
struct drm_histogram_caps;
struct intel_crtc;
+struct intel_display;
+enum pipe;
#define HISTOGRAM_BIN_COUNT 32
@@ -39,6 +41,7 @@ enum intel_global_hist_lut {
INTEL_HISTOGRAM_PIXEL_FACTOR,
};
+void intel_histogram_irq_handler(struct intel_display *display, enum pipe pipe);
int intel_histogram_atomic_check(struct intel_crtc *intel_crtc);
int intel_histogram_update(struct intel_crtc *intel_crtc,
struct drm_histogram_config *config);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b9e2aa1c6f8afefade761b8d291bb62efb96e53c..fc451783c9c23bfdd74a2dfc78be40c9d576fb56 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1599,7 +1599,7 @@
#define PIPE_HOTPLUG_INTERRUPT_ENABLE (1UL << 26)
#define PIPE_VSYNC_INTERRUPT_ENABLE (1UL << 25)
#define PIPE_DISPLAY_LINE_COMPARE_ENABLE (1UL << 24)
-#define PIPE_DPST_EVENT_ENABLE (1UL << 23)
+#define PIPE_HISTOGRAM_EVENT_ENABLE (1UL << 23)
#define SPRITE0_FLIP_DONE_INT_EN_VLV (1UL << 22)
#define PIPE_LEGACY_BLC_EVENT_ENABLE (1UL << 22)
#define PIPE_ODD_FIELD_INTERRUPT_ENABLE (1UL << 21)
@@ -1622,7 +1622,7 @@
#define PIPE_HOTPLUG_INTERRUPT_STATUS (1UL << 10)
#define PIPE_VSYNC_INTERRUPT_STATUS (1UL << 9)
#define PIPE_DISPLAY_LINE_COMPARE_STATUS (1UL << 8)
-#define PIPE_DPST_EVENT_STATUS (1UL << 7)
+#define PIPE_HISTOGRAM_EVENT_STATUS (1UL << 7)
#define PIPE_A_PSR_STATUS_VLV (1UL << 6)
#define PIPE_LEGACY_BLC_EVENT_STATUS (1UL << 6)
#define PIPE_ODD_FIELD_INTERRUPT_STATUS (1UL << 5)
@@ -2224,6 +2224,7 @@
#define GEN12_DSB_1_INT REG_BIT(14) /* tgl+ */
#define GEN12_DSB_0_INT REG_BIT(13) /* tgl+ */
#define GEN12_DSB_INT(dsb_id) REG_BIT(13 + (dsb_id))
+#define GEN9_PIPE_HISTOGRAM_EVENT REG_BIT(12) /* skl+ */
#define GEN9_PIPE_CURSOR_FAULT REG_BIT(11) /* skl+ */
#define GEN9_PIPE_PLANE4_FAULT REG_BIT(10) /* skl+ */
#define GEN8_PIPE_CURSOR_FAULT REG_BIT(10) /* bdw */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling
2025-01-28 15:51 ` [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling Arun R Murthy
@ 2025-02-14 10:19 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 10:19 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling
>
> Upon enabling histogram an interrupt is trigerred after the generation of the
Typo: *triggered
> statistics. This patch registers the histogram interrupt and handles the interrupt.
We don't use the word patch since it won't be a patch once merged
>
> v2: Added intel_crtc backpointer to intel_histogram struct (Jani)
> Removed histogram_wq and instead use dev_priv->unodered_eq (Jani)
> v3: Replaced drm_i915_private with intel_display (Suraj)
> Refactored the histogram read code (Jani)
> v4: Rebased after addressing comments on patch 1
> v5: removed the retry logic and moved to patch7 (Jani)
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 6 +-
> drivers/gpu/drm/i915/display/intel_histogram.c | 106
> ++++++++++++++++++++++-
> drivers/gpu/drm/i915/display/intel_histogram.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 5 +-
> 4 files changed, 115 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index
> d9734fcd0d45b9f7c2891730e73b7e1d59c206ad..b62c3cdfd6a0607d9d2e1caa0
> d71edb0aa99fdbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -21,6 +21,7 @@
> #include "intel_fdi_regs.h"
> #include "intel_fifo_underrun.h"
> #include "intel_gmbus.h"
> +#include "intel_histogram.h"
> #include "intel_hotplug_irq.h"
> #include "intel_pipe_crc_regs.h"
> #include "intel_pmdemand.h"
> @@ -1230,6 +1231,9 @@ void gen8_de_irq_handler(struct drm_i915_private
> *dev_priv, u32 master_ctl)
> if (iir & GEN8_PIPE_FIFO_UNDERRUN)
> intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_HISTOGRAM_EVENT)
> + intel_histogram_irq_handler(display, pipe);
> +
> fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv);
> if (fault_errors)
> drm_err_ratelimited(&dev_priv->drm,
> @@ -1827,7 +1831,7 @@ void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> struct intel_display *display = &dev_priv->display;
>
> u32 de_pipe_masked = gen8_de_pipe_fault_mask(dev_priv) |
> - GEN8_PIPE_CDCLK_CRC_DONE;
> + GEN8_PIPE_CDCLK_CRC_DONE |
> GEN9_PIPE_HISTOGRAM_EVENT;
> u32 de_pipe_enables;
> u32 de_port_masked = gen8_de_port_aux_mask(dev_priv);
> u32 de_port_enables;
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index
> 26eae8f40d0bf642546d583546782e22d5cefa9c..4f3dcbabfe96e955a658747182
> 72c4beb53b0827 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -19,7 +19,104 @@
> #define HISTOGRAM_GUARDBAND_THRESHOLD_DEFAULT 300
> /* Precision factor for threshold guardband */ #define
> HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000 -#define
> HISTOGRAM_DEFAULT_GUARDBAND_DELAY 0x04
> +#define HISTOGRAM_BIN_READ_RETRY_COUNT 5
> +
> +static bool intel_histogram_get_data(struct intel_crtc *intel_crtc) {
> + struct intel_display *display = to_intel_display(intel_crtc);
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + int index;
> + u32 dpstbin;
> +
> + for (index = 0; index < ARRAY_SIZE(histogram->bin_data); index++) {
> + dpstbin = intel_de_read(display, DPST_BIN(intel_crtc->pipe));
> + if (!(dpstbin & DPST_BIN_BUSY)) {
> + histogram->bin_data[index] = dpstbin &
> DPST_BIN_DATA_MASK;
> + } else
The {} here are not required
> + return false;
> + }
Newline here please
> + return true;
> +}
> +
> +static void intel_histogram_handle_int_work(struct work_struct *work) {
> + struct intel_histogram *histogram = container_of(work,
> + struct intel_histogram, work.work);
> + struct intel_crtc *intel_crtc = histogram->crtc;
> + struct intel_display *display = to_intel_display(intel_crtc);
> + char event[] = "HISTOGRAM=1", pipe_id[21];
> + char *histogram_event[] = { event, pipe_id, NULL };
> + int retry;
> +
> + snprintf(pipe_id, sizeof(pipe_id),
> + "PIPE=%u", intel_crtc->base.base.id);
> +
> + /*
> + * TODO: PSR to be exited while reading the Histogram data
> + * Set DPST_CTL Bin Reg function select to TC
> + * Set DPST_CTL Bin Register Index to 0
> + */
> + intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
> + for (retry = 0; retry < HISTOGRAM_BIN_READ_RETRY_COUNT; retry++) {
> + if (intel_histogram_get_data(intel_crtc)) {
> + u32 *data;
> + struct drm_histogram *hist;
> +
> + data = kzalloc(sizeof(data) * sizeof(histogram-
> >bin_data), GFP_KERNEL);
> + if (!data)
> + return;
New line here
> + memcpy(histogram->bin_data, data, sizeof(histogram-
> >bin_data));
> + hist = kzalloc(sizeof(struct drm_histogram),
> GFP_KERNEL);
> + if (!hist)
> + return;
Same here
> + hist->data_ptr = *data;
> + hist->nr_elements = sizeof(histogram->bin_data);
> +
> + /* TODO: fill the drm_histogram_config data back this
> drm_histogram struct */
*to this drm_histogram struc
> + drm_property_replace_global_blob(display->drm,
> + &intel_crtc->base.state->histogram_data,
> + sizeof(struct drm_histogram),
> + hist, &intel_crtc->base.base,
> + intel_crtc->base.histogram_data_property);
Align this with parenthesis and add a new line here.
> + /* Notify user for Histogram readiness */
> + if (kobject_uevent_env(&display->drm->primary-
> >kdev->kobj,
> + KOBJ_CHANGE, histogram_event))
> + drm_err(display->drm,
> + "Sending HISTOGRAM event failed\n");
> + break;
> + }
> + }
New line here
> + if (retry >= HISTOGRAM_BIN_READ_RETRY_COUNT) {
> + drm_err(display->drm, "Histogram bin read failed with max
> retry\n");
> + return;
> + }
> +
> + /* Enable histogram interrupt */
> + intel_de_rmw(display, DPST_GUARD(intel_crtc->pipe),
> DPST_GUARD_HIST_INT_EN,
> + DPST_GUARD_HIST_INT_EN);
> +
> + /* Clear histogram interrupt by setting histogram interrupt status bit*/
> + intel_de_rmw(display, DPST_GUARD(intel_crtc->pipe),
> + DPST_GUARD_HIST_EVENT_STATUS, 1); }
> +
> +void intel_histogram_irq_handler(struct intel_display *display, enum
> +pipe pipe) {
> + struct intel_crtc *intel_crtc =
> + to_intel_crtc(drm_crtc_from_index(display->drm, pipe));
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> +
> + if (!histogram->enable) {
> + drm_err(display->drm,
> + "Spurious interrupt, histogram not enabled\n");
> + return;
> + }
> +
> + queue_delayed_work(i915->unordered_wq,
> + &histogram->work, 0);
> +}
>
> int intel_histogram_atomic_check(struct intel_crtc *intel_crtc) { @@ -71,7
> +168,7 @@ static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8
> mode)
> DPST_GUARD_THRESHOLD_GB_MASK |
> DPST_GUARD_INTERRUPT_DELAY_MASK |
> DPST_GUARD_HIST_INT_EN,
> DPST_GUARD_THRESHOLD_GB(gbandthreshold) |
> -
> DPST_GUARD_INTERRUPT_DELAY(HISTOGRAM_DEFAULT_GUARDBAND_DELAY)
> |
> + DPST_GUARD_INTERRUPT_DELAY(0x04) |
Why no need.
Regards,
Suraj Kandpal
> DPST_GUARD_HIST_INT_EN);
>
> /* Clear pending interrupts has to be done on separate write */ @@ -
> 104,6 +201,7 @@ static void intel_histogram_disable(struct intel_crtc
> *intel_crtc)
> intel_de_rmw(display, DPST_CTL(pipe),
> DPST_CTL_IE_HIST_EN, 0);
>
> + cancel_delayed_work(&histogram->work);
> histogram->enable = false;
> }
>
> @@ -129,6 +227,7 @@ void intel_histogram_finish(struct intel_crtc *intel_crtc)
> {
> struct intel_histogram *histogram = intel_crtc->histogram;
>
> + cancel_delayed_work_sync(&histogram->work);
> kfree(histogram);
> }
>
> @@ -153,5 +252,8 @@ int intel_histogram_init(struct intel_crtc *crtc)
> histogram->can_enable = false;
> histogram->caps = histogram_caps;
>
> + INIT_DEFERRABLE_WORK(&histogram->work,
> + intel_histogram_handle_int_work);
> +
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h
> b/drivers/gpu/drm/i915/display/intel_histogram.h
> index
> 5ea19ef2d3ecadf1ac159a784f51278fdde593de..b44ba3afc94f79f291f4e5ebdd0
> 4dcf9434b48a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.h
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> @@ -14,6 +14,8 @@ struct drm_property_blob; struct drm_histogram_config;
> struct drm_histogram_caps; struct intel_crtc;
> +struct intel_display;
> +enum pipe;
>
> #define HISTOGRAM_BIN_COUNT 32
>
> @@ -39,6 +41,7 @@ enum intel_global_hist_lut {
> INTEL_HISTOGRAM_PIXEL_FACTOR,
> };
>
> +void intel_histogram_irq_handler(struct intel_display *display, enum
> +pipe pipe);
> int intel_histogram_atomic_check(struct intel_crtc *intel_crtc); int
> intel_histogram_update(struct intel_crtc *intel_crtc,
> struct drm_histogram_config *config); diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> b9e2aa1c6f8afefade761b8d291bb62efb96e53c..fc451783c9c23bfdd74a2dfc78b
> e40c9d576fb56 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1599,7 +1599,7 @@
> #define PIPE_HOTPLUG_INTERRUPT_ENABLE (1UL << 26)
> #define PIPE_VSYNC_INTERRUPT_ENABLE (1UL << 25)
> #define PIPE_DISPLAY_LINE_COMPARE_ENABLE (1UL << 24)
> -#define PIPE_DPST_EVENT_ENABLE (1UL << 23)
> +#define PIPE_HISTOGRAM_EVENT_ENABLE (1UL << 23)
> #define SPRITE0_FLIP_DONE_INT_EN_VLV (1UL << 22)
> #define PIPE_LEGACY_BLC_EVENT_ENABLE (1UL << 22)
> #define PIPE_ODD_FIELD_INTERRUPT_ENABLE (1UL << 21)
> @@ -1622,7 +1622,7 @@
> #define PIPE_HOTPLUG_INTERRUPT_STATUS (1UL << 10)
> #define PIPE_VSYNC_INTERRUPT_STATUS (1UL << 9)
> #define PIPE_DISPLAY_LINE_COMPARE_STATUS (1UL << 8)
> -#define PIPE_DPST_EVENT_STATUS (1UL << 7)
> +#define PIPE_HISTOGRAM_EVENT_STATUS (1UL << 7)
> #define PIPE_A_PSR_STATUS_VLV (1UL << 6)
> #define PIPE_LEGACY_BLC_EVENT_STATUS (1UL << 6)
> #define PIPE_ODD_FIELD_INTERRUPT_STATUS (1UL << 5)
> @@ -2224,6 +2224,7 @@
> #define GEN12_DSB_1_INT REG_BIT(14) /* tgl+ */
> #define GEN12_DSB_0_INT REG_BIT(13) /* tgl+ */
> #define GEN12_DSB_INT(dsb_id) REG_BIT(13 + (dsb_id))
> +#define GEN9_PIPE_HISTOGRAM_EVENT REG_BIT(12) /* skl+ */
> #define GEN9_PIPE_CURSOR_FAULT REG_BIT(11) /* skl+ */
> #define GEN9_PIPE_PLANE4_FAULT REG_BIT(10) /* skl+ */
> #define GEN8_PIPE_CURSOR_FAULT REG_BIT(10) /* bdw */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm histogram
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (7 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 08/14] drm/i915/histogram: histogram interrupt handling Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-14 10:22 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data Arun R Murthy
` (7 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Handle histogram caps and histogram config property in i915 driver. Fill
the histogram hardware capability and act upon the histogram config
property to enable/disable histogram in i915.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/display/intel_crtc.c | 7 +++++++
drivers/gpu/drm/i915/display/intel_display.c | 12 ++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index e69b28779ac551bde56c9c3d394e784275a9b69e..b90017409a23de2a214ca43d32ba537998ea0f78 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -28,6 +28,7 @@
#include "intel_drrs.h"
#include "intel_dsi.h"
#include "intel_fifo_underrun.h"
+#include "intel_histogram.h"
#include "intel_pipe_crc.h"
#include "intel_psr.h"
#include "intel_sprite.h"
@@ -211,6 +212,7 @@ static struct intel_crtc *intel_crtc_alloc(void)
static void intel_crtc_free(struct intel_crtc *crtc)
{
intel_crtc_destroy_state(&crtc->base, crtc->base.state);
+ intel_histogram_finish(crtc);
kfree(crtc);
}
@@ -381,6 +383,11 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
BIT(DRM_SCALING_FILTER_DEFAULT) |
BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
+ intel_histogram_init(crtc);
+ if (drm_crtc_create_histogram_property(&crtc->base,
+ crtc->histogram->caps))
+ drm_err(&dev_priv->drm, "Failed to initialize histogram properties\n");
+
intel_color_crtc_init(crtc);
intel_drrs_crtc_init(crtc);
intel_crtc_crc_init(crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 7d68d652c1bc91acc68281c4761f688f3779bd79..c38a33ee90aef144931215254f178ba955f998b0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -93,6 +93,7 @@
#include "intel_fifo_underrun.h"
#include "intel_frontbuffer.h"
#include "intel_hdmi.h"
+#include "intel_histogram.h"
#include "intel_hotplug.h"
#include "intel_link_bw.h"
#include "intel_lvds.h"
@@ -4675,6 +4676,12 @@ static int intel_crtc_atomic_check(struct intel_atomic_state *state,
if (ret)
return ret;
+ if (crtc_state->uapi.histogram_updated) {
+ ret = intel_histogram_atomic_check(crtc);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -7933,6 +7940,11 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
*/
old_crtc_state->dsb_color_vblank = fetch_and_zero(&new_crtc_state->dsb_color_vblank);
old_crtc_state->dsb_commit = fetch_and_zero(&new_crtc_state->dsb_commit);
+
+ if (new_crtc_state->uapi.histogram_updated)
+ intel_histogram_update(crtc,
+ (struct drm_histogram_config *)
+ new_crtc_state->uapi.histogram_enable->data);
}
/* Underruns don't always raise interrupts, so check manually */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm histogram
2025-01-28 15:51 ` [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm histogram Arun R Murthy
@ 2025-02-14 10:22 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-14 10:22 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm
> histogram
>
> Handle histogram caps and histogram config property in i915 driver. Fill the
> histogram hardware capability and act upon the histogram config property to
> enable/disable histogram in i915.
Need to fix comment its not just for i915 but xe as well.
Otherwise LGTM,
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 7 +++++++
> drivers/gpu/drm/i915/display/intel_display.c | 12 ++++++++++++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index
> e69b28779ac551bde56c9c3d394e784275a9b69e..b90017409a23de2a214ca43d
> 32ba537998ea0f78 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -28,6 +28,7 @@
> #include "intel_drrs.h"
> #include "intel_dsi.h"
> #include "intel_fifo_underrun.h"
> +#include "intel_histogram.h"
> #include "intel_pipe_crc.h"
> #include "intel_psr.h"
> #include "intel_sprite.h"
> @@ -211,6 +212,7 @@ static struct intel_crtc *intel_crtc_alloc(void) static
> void intel_crtc_free(struct intel_crtc *crtc) {
> intel_crtc_destroy_state(&crtc->base, crtc->base.state);
> + intel_histogram_finish(crtc);
> kfree(crtc);
> }
>
> @@ -381,6 +383,11 @@ int intel_crtc_init(struct drm_i915_private *dev_priv,
> enum pipe pipe)
>
> BIT(DRM_SCALING_FILTER_DEFAULT) |
>
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
>
> + intel_histogram_init(crtc);
> + if (drm_crtc_create_histogram_property(&crtc->base,
> + crtc->histogram->caps))
> + drm_err(&dev_priv->drm, "Failed to initialize histogram
> +properties\n");
> +
> intel_color_crtc_init(crtc);
> intel_drrs_crtc_init(crtc);
> intel_crtc_crc_init(crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index
> 7d68d652c1bc91acc68281c4761f688f3779bd79..c38a33ee90aef144931215254f
> 178ba955f998b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -93,6 +93,7 @@
> #include "intel_fifo_underrun.h"
> #include "intel_frontbuffer.h"
> #include "intel_hdmi.h"
> +#include "intel_histogram.h"
> #include "intel_hotplug.h"
> #include "intel_link_bw.h"
> #include "intel_lvds.h"
> @@ -4675,6 +4676,12 @@ static int intel_crtc_atomic_check(struct
> intel_atomic_state *state,
> if (ret)
> return ret;
>
> + if (crtc_state->uapi.histogram_updated) {
> + ret = intel_histogram_atomic_check(crtc);
> + if (ret)
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -7933,6 +7940,11 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> */
> old_crtc_state->dsb_color_vblank =
> fetch_and_zero(&new_crtc_state->dsb_color_vblank);
> old_crtc_state->dsb_commit =
> fetch_and_zero(&new_crtc_state->dsb_commit);
> +
> + if (new_crtc_state->uapi.histogram_updated)
> + intel_histogram_update(crtc,
> + (struct drm_histogram_config *)
> + new_crtc_state-
> >uapi.histogram_enable->data);
> }
>
> /* Underruns don't always raise interrupts, so check manually */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (8 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 09/14] drm/i915/histogram: Hook i915 histogram with drm histogram Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-17 4:23 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 11/14] drm/i915/crtc: Hook i915 IET LUT with the drm IET properties Arun R Murthy
` (6 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
User created LUT can be fed back to the hardware so that the hardware
can apply this LUT data to see the enhancement in the image.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/display/intel_histogram.c | 70 ++++++++++++++++++++++++++
drivers/gpu/drm/i915/display/intel_histogram.h | 4 ++
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
index 4f3dcbabfe96e955a65874718272c4beb53b0827..aa02e7ce42b930a858de4ad7e0d39d93fa7d4298 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.c
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -20,6 +20,7 @@
/* Precision factor for threshold guardband */
#define HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000
#define HISTOGRAM_BIN_READ_RETRY_COUNT 5
+#define IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
static bool intel_histogram_get_data(struct intel_crtc *intel_crtc)
{
@@ -223,6 +224,60 @@ int intel_histogram_update(struct intel_crtc *intel_crtc,
return 0;
}
+int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
+ struct drm_property_blob *blob)
+{
+ struct intel_histogram *histogram = intel_crtc->histogram;
+ struct intel_display *display = to_intel_display(intel_crtc);
+ int pipe = intel_crtc->pipe;
+ int i = 0;
+ struct drm_iet_1dlut_sample *iet;
+ u32 *data;
+ int ret;
+
+ if (!histogram)
+ return -EINVAL;
+
+ if (!histogram->enable) {
+ drm_err(display->drm, "histogram not enabled");
+ return -EINVAL;
+ }
+
+ if (!data) {
+ drm_err(display->drm, "enhancement LUT data is NULL");
+ return -EINVAL;
+ }
+
+ /* Set DPST_CTL Bin Reg function select to IE & wait for a vblabk */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL, DPST_CTL_BIN_REG_FUNC_IE);
+
+ drm_crtc_wait_one_vblank(&intel_crtc->base);
+
+ /* Set DPST_CTL Bin Register Index to 0 */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_MASK, DPST_CTL_BIN_REG_CLEAR);
+
+ iet = (struct drm_iet_1dlut_sample *)blob->data;
+ data = kzalloc(sizeof(data) * iet->nr_elements, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+ ret = copy_from_user(data, (uint32_t __user *)(unsigned long)iet->iet_lut,
+ sizeof(uint32_t) * iet->nr_elements);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
+ intel_de_rmw(display, DPST_BIN(pipe),
+ DPST_BIN_DATA_MASK, data[i]);
+ drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n", i, data[i]);
+ }
+ kfree(data);
+ drm_property_blob_put(intel_crtc->base.state->iet_lut);
+
+ return 0;
+}
+
void intel_histogram_finish(struct intel_crtc *intel_crtc)
{
struct intel_histogram *histogram = intel_crtc->histogram;
@@ -235,6 +290,8 @@ int intel_histogram_init(struct intel_crtc *crtc)
{
struct intel_histogram *histogram;
struct drm_histogram_caps *histogram_caps;
+ struct drm_iet_caps *iet_caps;
+ u32 *iet_format;
/* Allocate histogram internal struct */
histogram = kzalloc(sizeof(*histogram), GFP_KERNEL);
@@ -247,10 +304,23 @@ int intel_histogram_init(struct intel_crtc *crtc)
histogram_caps->histogram_mode = DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
+ iet_caps = kzalloc(sizeof(*iet_caps), GFP_KERNEL);
+ if (!iet_caps)
+ return -ENOMEM;
+
+ iet_caps->iet_mode = DRM_MODE_IET_MULTIPLICATIVE;
+ iet_caps->nr_iet_sample_formats = 1;
+ iet_caps->nr_iet_lut_entries = HISTOGRAM_IET_LENGTH;
+ iet_format = kzalloc(sizeof(u32)*iet_caps->nr_iet_sample_formats,
+ GFP_KERNEL);
+ *iet_format = IET_SAMPLE_FORMAT_1_INT_9_FRACT;
+ iet_caps->iet_sample_format = *iet_format;
+
crtc->histogram = histogram;
histogram->crtc = crtc;
histogram->can_enable = false;
histogram->caps = histogram_caps;
+ histogram->iet_caps = iet_caps;
INIT_DEFERRABLE_WORK(&histogram->work,
intel_histogram_handle_int_work);
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.h b/drivers/gpu/drm/i915/display/intel_histogram.h
index b44ba3afc94f79f291f4e5ebdd04dcf9434b48a4..0999d1720c7abee8907c77896e4b1e6ff756160f 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.h
+++ b/drivers/gpu/drm/i915/display/intel_histogram.h
@@ -18,9 +18,11 @@ struct intel_display;
enum pipe;
#define HISTOGRAM_BIN_COUNT 32
+#define HISTOGRAM_IET_LENGTH 33
struct intel_histogram {
struct drm_histogram_caps *caps;
+ struct drm_iet_caps *iet_caps;
struct intel_crtc *crtc;
struct delayed_work work;
bool enable;
@@ -45,6 +47,8 @@ void intel_histogram_irq_handler(struct intel_display *display, enum pipe pipe);
int intel_histogram_atomic_check(struct intel_crtc *intel_crtc);
int intel_histogram_update(struct intel_crtc *intel_crtc,
struct drm_histogram_config *config);
+int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
+ struct drm_property_blob *blob);
int intel_histogram_init(struct intel_crtc *intel_crtc);
void intel_histogram_finish(struct intel_crtc *intel_crtc);
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data
2025-01-28 15:51 ` [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data Arun R Murthy
@ 2025-02-17 4:23 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-17 4:23 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data
>
> User created LUT can be fed back to the hardware so that the hardware can
> apply this LUT data to see the enhancement in the image.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_histogram.c | 70
> ++++++++++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_histogram.h | 4 ++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index
> 4f3dcbabfe96e955a65874718272c4beb53b0827..aa02e7ce42b930a858de4ad7e
> 0d39d93fa7d4298 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -20,6 +20,7 @@
> /* Precision factor for threshold guardband */ #define
> HISTOGRAM_GUARDBAND_PRECISION_FACTOR 10000 #define
> HISTOGRAM_BIN_READ_RETRY_COUNT 5
> +#define IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
>
> static bool intel_histogram_get_data(struct intel_crtc *intel_crtc) { @@ -223,6
> +224,60 @@ int intel_histogram_update(struct intel_crtc *intel_crtc,
> return 0;
> }
>
> +int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
> + struct drm_property_blob *blob)
> +{
> + struct intel_histogram *histogram = intel_crtc->histogram;
> + struct intel_display *display = to_intel_display(intel_crtc);
> + int pipe = intel_crtc->pipe;
> + int i = 0;
> + struct drm_iet_1dlut_sample *iet;
> + u32 *data;
> + int ret;
> +
> + if (!histogram)
> + return -EINVAL;
> +
> + if (!histogram->enable) {
> + drm_err(display->drm, "histogram not enabled");
Please add /n at the end of sentence.
Nit: start the log statement with a capital letter
> + return -EINVAL;
> + }
> +
> + if (!data) {
> + drm_err(display->drm, "enhancement LUT data is NULL");
> + return -EINVAL;
> + }
> +
> + /* Set DPST_CTL Bin Reg function select to IE & wait for a vblabk */
Typo you mean vblank
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL,
> DPST_CTL_BIN_REG_FUNC_IE);
> +
> + drm_crtc_wait_one_vblank(&intel_crtc->base);
> +
> + /* Set DPST_CTL Bin Register Index to 0 */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_MASK, DPST_CTL_BIN_REG_CLEAR);
> +
> + iet = (struct drm_iet_1dlut_sample *)blob->data;
> + data = kzalloc(sizeof(data) * iet->nr_elements, GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
New line here
> + ret = copy_from_user(data, (uint32_t __user *)(unsigned long)iet-
> >iet_lut,
> + sizeof(uint32_t) * iet->nr_elements);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
> + intel_de_rmw(display, DPST_BIN(pipe),
> + DPST_BIN_DATA_MASK, data[i]);
DATA_BIN_MASK is 0:23 for TC mode and only 0:9 for IE I think you should create a new
IE DATA_BIN_MASK and then write the data.
> + drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n", i, data[i]);
Drm_dbg_kms
Regards,
Suraj Kandpal
> + }
> + kfree(data);
> + drm_property_blob_put(intel_crtc->base.state->iet_lut);
> +
> + return 0;
> +}
> +
> void intel_histogram_finish(struct intel_crtc *intel_crtc) {
> struct intel_histogram *histogram = intel_crtc->histogram; @@ -235,6
> +290,8 @@ int intel_histogram_init(struct intel_crtc *crtc) {
> struct intel_histogram *histogram;
> struct drm_histogram_caps *histogram_caps;
> + struct drm_iet_caps *iet_caps;
> + u32 *iet_format;
>
> /* Allocate histogram internal struct */
> histogram = kzalloc(sizeof(*histogram), GFP_KERNEL); @@ -247,10
> +304,23 @@ int intel_histogram_init(struct intel_crtc *crtc)
> histogram_caps->histogram_mode =
> DRM_MODE_HISTOGRAM_HSV_MAX_RGB;
> histogram_caps->bins_count = HISTOGRAM_BIN_COUNT;
>
> + iet_caps = kzalloc(sizeof(*iet_caps), GFP_KERNEL);
> + if (!iet_caps)
> + return -ENOMEM;
> +
> + iet_caps->iet_mode = DRM_MODE_IET_MULTIPLICATIVE;
> + iet_caps->nr_iet_sample_formats = 1;
> + iet_caps->nr_iet_lut_entries = HISTOGRAM_IET_LENGTH;
> + iet_format = kzalloc(sizeof(u32)*iet_caps->nr_iet_sample_formats,
> + GFP_KERNEL);
> + *iet_format = IET_SAMPLE_FORMAT_1_INT_9_FRACT;
> + iet_caps->iet_sample_format = *iet_format;
> +
> crtc->histogram = histogram;
> histogram->crtc = crtc;
> histogram->can_enable = false;
> histogram->caps = histogram_caps;
> + histogram->iet_caps = iet_caps;
>
> INIT_DEFERRABLE_WORK(&histogram->work,
> intel_histogram_handle_int_work); diff --git
> a/drivers/gpu/drm/i915/display/intel_histogram.h
> b/drivers/gpu/drm/i915/display/intel_histogram.h
> index
> b44ba3afc94f79f291f4e5ebdd04dcf9434b48a4..0999d1720c7abee8907c77896e
> 4b1e6ff756160f 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.h
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.h
> @@ -18,9 +18,11 @@ struct intel_display; enum pipe;
>
> #define HISTOGRAM_BIN_COUNT 32
> +#define HISTOGRAM_IET_LENGTH 33
>
> struct intel_histogram {
> struct drm_histogram_caps *caps;
> + struct drm_iet_caps *iet_caps;
> struct intel_crtc *crtc;
> struct delayed_work work;
> bool enable;
> @@ -45,6 +47,8 @@ void intel_histogram_irq_handler(struct intel_display
> *display, enum pipe pipe); int intel_histogram_atomic_check(struct intel_crtc
> *intel_crtc); int intel_histogram_update(struct intel_crtc *intel_crtc,
> struct drm_histogram_config *config);
> +int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
> + struct drm_property_blob *blob);
> int intel_histogram_init(struct intel_crtc *intel_crtc); void
> intel_histogram_finish(struct intel_crtc *intel_crtc);
>
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 11/14] drm/i915/crtc: Hook i915 IET LUT with the drm IET properties
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (9 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 10/14] drm/i915/iet: Add support to writing the IET LUT data Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 12/14] drm/i915/histogram: histogram delay counter doesnt reset Arun R Murthy
` (5 subsequent siblings)
16 siblings, 0 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Upon drm getting the IET LUT value from the user through the IET_LUT
property, i915 driver will write the LUT table to the hardware
registers.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/display/intel_crtc.c | 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index b90017409a23de2a214ca43d32ba537998ea0f78..4e6c790f53ffe375e1b496fe48e9dc10e05bf11b 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -387,6 +387,9 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
if (drm_crtc_create_histogram_property(&crtc->base,
crtc->histogram->caps))
drm_err(&dev_priv->drm, "Failed to initialize histogram properties\n");
+ if (drm_crtc_create_iet_lut_property(&crtc->base,
+ crtc->histogram->iet_caps))
+ drm_err(&dev_priv->drm, "Failed to initialize histogram properties\n");
intel_color_crtc_init(crtc);
intel_drrs_crtc_init(crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index c38a33ee90aef144931215254f178ba955f998b0..673012e716e448b4aef0db530f5eeb44edc14265 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7945,6 +7945,8 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
intel_histogram_update(crtc,
(struct drm_histogram_config *)
new_crtc_state->uapi.histogram_enable->data);
+ if (new_crtc_state->uapi.iet_lut_updated)
+ intel_histogram_set_iet_lut(crtc, new_crtc_state->uapi.iet_lut);
}
/* Underruns don't always raise interrupts, so check manually */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 12/14] drm/i915/histogram: histogram delay counter doesnt reset
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (10 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 11/14] drm/i915/crtc: Hook i915 IET LUT with the drm IET properties Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-01-28 15:51 ` [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display 20+ Arun R Murthy
` (4 subsequent siblings)
16 siblings, 0 replies; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
The delay counter for histogram does not reset and as a result the
histogram bin never gets updated. Workaround would be to use save and
restore histogram register.
v2: Follow the seq in interrupt handler
Restore DPST bit 0
read/write dpst ctl rg
Restore DPST bit 1 and Guardband Delay Interrupt counter = 0
(Suraj)
v3: updated wa version for display 13 and 14
Wa: 14014889975
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
drivers/gpu/drm/i915/display/intel_histogram.c | 14 ++++++++++++++
drivers/gpu/drm/i915/display/intel_histogram_regs.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
index aa02e7ce42b930a858de4ad7e0d39d93fa7d4298..dd4ab30795df48011013c019d7525e046cdd5404 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.c
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -52,6 +52,11 @@ static void intel_histogram_handle_int_work(struct work_struct *work)
snprintf(pipe_id, sizeof(pipe_id),
"PIPE=%u", intel_crtc->base.base.id);
+ /* Wa: 14014889975 */
+ if (IS_DISPLAY_VER(display, 13, 14))
+ intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
+ DPST_CTL_RESTORE, 0);
+
/*
* TODO: PSR to be exited while reading the Histogram data
* Set DPST_CTL Bin Reg function select to TC
@@ -93,6 +98,15 @@ static void intel_histogram_handle_int_work(struct work_struct *work)
return;
}
+ /* Wa: 14014889975 */
+ if (IS_DISPLAY_VER(display, 13, 14))
+ /* Write the value read from DPST_CTL to DPST_CTL.Interrupt Delay Counter(bit 23:16) */
+ intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
+ DPST_CTL_GUARDBAND_INTERRUPT_DELAY_CNT |
+ DPST_CTL_RESTORE,
+ DPST_CTL_GUARDBAND_INTERRUPT_DELAY(0x0) |
+ DPST_CTL_RESTORE);
+
/* Enable histogram interrupt */
intel_de_rmw(display, DPST_GUARD(intel_crtc->pipe), DPST_GUARD_HIST_INT_EN,
DPST_GUARD_HIST_INT_EN);
diff --git a/drivers/gpu/drm/i915/display/intel_histogram_regs.h b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
index 1252b4f339a63f70f44e249bdeae87805bee20fc..213c9f483567cb19a47b44953749f6baf0afe9e7 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
@@ -16,6 +16,8 @@
#define DPST_CTL_RESTORE REG_BIT(28)
#define DPST_CTL_IE_MODI_TABLE_EN REG_BIT(27)
#define DPST_CTL_HIST_MODE REG_BIT(24)
+#define DPST_CTL_GUARDBAND_INTERRUPT_DELAY_CNT REG_GENMASK(23, 16)
+#define DPST_CTL_GUARDBAND_INTERRUPT_DELAY(val) REG_FIELD_PREP(DPST_CTL_GUARDBAND_INTERRUPT_DELAY_CNT, val)
#define DPST_CTL_ENHANCEMENT_MODE_MASK REG_GENMASK(14, 13)
#define DPST_CTL_EN_MULTIPLICATIVE REG_FIELD_PREP(DPST_CTL_ENHANCEMENT_MODE_MASK, 2)
#define DPST_CTL_IE_TABLE_VALUE_FORMAT REG_BIT(15)
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display 20+
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (11 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 12/14] drm/i915/histogram: histogram delay counter doesnt reset Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-17 6:25 ` Kandpal, Suraj
2025-01-28 15:51 ` [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering Arun R Murthy
` (3 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
In Display 20+, new registers are added for setting index, reading
histogram and writing the IET.
v2: Removed duplicate code (Jani)
v3: Moved histogram core changes to earlier patches (Jani/Suraj)
v4: Rebased after addressing comments on patch 1
v5: Added the retry logic from patch3 and rebased the patch series
v6: optimize wite_iet() (Suraj)
Bspec: 68895
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
---
drivers/gpu/drm/i915/display/intel_histogram.c | 108 +++++++++++++++------
.../gpu/drm/i915/display/intel_histogram_regs.h | 25 +++++
2 files changed, 104 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
index dd4ab30795df48011013c019d7525e046cdd5404..f6844449e4bb6167116d223af316e5f3a5e8707c 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.c
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -22,6 +22,37 @@
#define HISTOGRAM_BIN_READ_RETRY_COUNT 5
#define IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
+static void set_bin_index_0(struct intel_display *display, enum pipe pipe)
+{
+ if (DISPLAY_VER(display) >= 20)
+ intel_de_rmw(display, DPST_IE_INDEX(pipe),
+ DPST_IE_BIN_INDEX_MASK, DPST_IE_BIN_INDEX(0));
+ else
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_MASK,
+ DPST_CTL_BIN_REG_CLEAR);
+}
+
+static void write_iet(struct intel_display *display, enum pipe pipe,
+ u32 *data)
+{
+ int i;
+
+ for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
+ if (DISPLAY_VER(display) >= 20)
+ intel_de_rmw(display, DPST_IE_BIN(pipe),
+ DPST_IE_BIN_DATA_MASK,
+ DPST_IE_BIN_DATA(data[i]));
+ else
+ intel_de_rmw(display, DPST_BIN(pipe),
+ DPST_BIN_DATA_MASK,
+ DPST_BIN_DATA(data[i]));
+
+ drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n",
+ i, data[i]);
+ }
+}
+
static bool intel_histogram_get_data(struct intel_crtc *intel_crtc)
{
struct intel_display *display = to_intel_display(intel_crtc);
@@ -29,12 +60,27 @@ static bool intel_histogram_get_data(struct intel_crtc *intel_crtc)
int index;
u32 dpstbin;
+ if (DISPLAY_VER(display) >= 20)
+ intel_de_rmw(display, DPST_HIST_INDEX(intel_crtc->pipe),
+ DPST_HIST_BIN_INDEX_MASK,
+ DPST_HIST_BIN_INDEX(0));
+ else
+ intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_BIN_REG_MASK, 0);
+
for (index = 0; index < ARRAY_SIZE(histogram->bin_data); index++) {
- dpstbin = intel_de_read(display, DPST_BIN(intel_crtc->pipe));
+ dpstbin = intel_de_read(display, (DISPLAY_VER(display) >= 20 ?
+ DPST_HIST_BIN(intel_crtc->pipe) :
+ DPST_BIN(intel_crtc->pipe)));
if (!(dpstbin & DPST_BIN_BUSY)) {
- histogram->bin_data[index] = dpstbin & DPST_BIN_DATA_MASK;
- } else
+ histogram->bin_data[index] = dpstbin & (DISPLAY_VER(display) >= 20 ?
+ DPST_HIST_BIN_DATA_MASK :
+ DPST_BIN_DATA_MASK);
+ } else {
+ drm_err(display->drm, "Histogram bin busy, retyring\n");
+ fsleep(2);
return false;
+ }
}
return true;
}
@@ -62,8 +108,6 @@ static void intel_histogram_handle_int_work(struct work_struct *work)
* Set DPST_CTL Bin Reg function select to TC
* Set DPST_CTL Bin Register Index to 0
*/
- intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
- DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_BIN_REG_MASK, 0);
for (retry = 0; retry < HISTOGRAM_BIN_READ_RETRY_COUNT; retry++) {
if (intel_histogram_get_data(intel_crtc)) {
u32 *data;
@@ -156,17 +200,27 @@ static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8 mode)
if (histogram->enable)
return 0;
-
- /* enable histogram, clear DPST_CTL bin reg func select to TC */
- intel_de_rmw(display, DPST_CTL(pipe),
- DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
- DPST_CTL_HIST_MODE | DPST_CTL_IE_TABLE_VALUE_FORMAT |
- DPST_CTL_ENHANCEMENT_MODE_MASK | DPST_CTL_IE_MODI_TABLE_EN,
- ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
- DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN |
- DPST_CTL_HIST_MODE_HSV |
- DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
- DPST_CTL_EN_MULTIPLICATIVE | DPST_CTL_IE_MODI_TABLE_EN);
+ /* enable histogram, clear DPST_BIN reg and select TC function */
+ if (DISPLAY_VER(display) >= 20)
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE,
+ DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE_HSV);
+ else
+ /* enable histogram, clear DPST_CTL bin reg func select to TC */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE |
+ DPST_CTL_IE_TABLE_VALUE_FORMAT |
+ DPST_CTL_ENHANCEMENT_MODE_MASK |
+ DPST_CTL_IE_MODI_TABLE_EN,
+ ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
+ DPST_CTL_BIN_REG_FUNC_TC : 0) |
+ DPST_CTL_IE_HIST_EN |
+ DPST_CTL_HIST_MODE_HSV |
+ DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
+ DPST_CTL_EN_MULTIPLICATIVE | DPST_CTL_IE_MODI_TABLE_EN);
/* Re-Visit: check if wait for one vblank is required */
drm_crtc_wait_one_vblank(&intel_crtc->base);
@@ -244,7 +298,6 @@ int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
struct intel_histogram *histogram = intel_crtc->histogram;
struct intel_display *display = to_intel_display(intel_crtc);
int pipe = intel_crtc->pipe;
- int i = 0;
struct drm_iet_1dlut_sample *iet;
u32 *data;
int ret;
@@ -262,15 +315,15 @@ int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
return -EINVAL;
}
- /* Set DPST_CTL Bin Reg function select to IE & wait for a vblabk */
- intel_de_rmw(display, DPST_CTL(pipe),
- DPST_CTL_BIN_REG_FUNC_SEL, DPST_CTL_BIN_REG_FUNC_IE);
- drm_crtc_wait_one_vblank(&intel_crtc->base);
+ if (DISPLAY_VER(display) < 20) {
+ /* Set DPST_CTL Bin Reg function select to IE & wait for a vblabk */
+ intel_de_rmw(display, DPST_CTL(pipe),
+ DPST_CTL_BIN_REG_FUNC_SEL,
+ DPST_CTL_BIN_REG_FUNC_IE);
+ }
- /* Set DPST_CTL Bin Register Index to 0 */
- intel_de_rmw(display, DPST_CTL(pipe),
- DPST_CTL_BIN_REG_MASK, DPST_CTL_BIN_REG_CLEAR);
+ set_bin_index_0(display, pipe);
iet = (struct drm_iet_1dlut_sample *)blob->data;
data = kzalloc(sizeof(data) * iet->nr_elements, GFP_KERNEL);
@@ -281,11 +334,8 @@ int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
if (ret)
return ret;
- for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
- intel_de_rmw(display, DPST_BIN(pipe),
- DPST_BIN_DATA_MASK, data[i]);
- drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n", i, data[i]);
- }
+ write_iet(display, pipe, data);
+
kfree(data);
drm_property_blob_put(intel_crtc->base.state->iet_lut);
diff --git a/drivers/gpu/drm/i915/display/intel_histogram_regs.h b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
index 213c9f483567cb19a47b44953749f6baf0afe9e7..3fbb9c2deaae6278d5a832dfb61ef860de0c6f21 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
@@ -45,6 +45,31 @@
#define _DPST_BIN_B 0x491C4
#define DPST_BIN(pipe) _MMIO_PIPE(pipe, _DPST_BIN_A, _DPST_BIN_B)
#define DPST_BIN_DATA_MASK REG_GENMASK(23, 0)
+#define DPST_BIN_DATA(val) REG_FIELD_PREP(DPST_BIN_DATA_MASK, val)
#define DPST_BIN_BUSY REG_BIT(31)
+#define _DPST_HIST_INDEX_A 0x490D8
+#define _DPST_HIST_INDEX_B 0x491D8
+#define DPST_HIST_INDEX(pipe) _MMIO_PIPE(pipe, _DPST_HIST_INDEX_A, _DPST_HIST_INDEX_B)
+#define DPST_HIST_BIN_INDEX_MASK REG_GENMASK(4, 0)
+#define DPST_HIST_BIN_INDEX(val) REG_FIELD_PREP(DPST_HIST_BIN_INDEX_MASK, val)
+
+#define _DPST_HIST_BIN_A 0x490C4
+#define _DPST_HIST_BIN_B 0x491C4
+#define DPST_HIST_BIN(pipe) _MMIO_PIPE(pipe, _DPST_HIST_BIN_A, _DPST_HIST_BIN_B)
+#define DPST_HIST_BIN_BUSY REG_BIT(31)
+#define DPST_HIST_BIN_DATA_MASK REG_GENMASK(30, 0)
+
+#define _DPST_IE_BIN_A 0x490CC
+#define _DPST_IE_BIN_B 0x491CC
+#define DPST_IE_BIN(pipe) _MMIO_PIPE(pipe, _DPST_IE_BIN_A, _DPST_IE_BIN_B)
+#define DPST_IE_BIN_DATA_MASK REG_GENMASK(9, 0)
+#define DPST_IE_BIN_DATA(val) REG_FIELD_PREP(DPST_IE_BIN_DATA_MASK, val)
+
+#define _DPST_IE_INDEX_A 0x490DC
+#define _DPST_IE_INDEX_B 0x491DC
+#define DPST_IE_INDEX(pipe) _MMIO_PIPE(pipe, _DPST_IE_INDEX_A, _DPST_IE_INDEX_B)
+#define DPST_IE_BIN_INDEX_MASK REG_GENMASK(6, 0)
+#define DPST_IE_BIN_INDEX(val) REG_FIELD_PREP(DPST_IE_BIN_INDEX_MASK, val)
+
#endif /* __INTEL_HISTOGRAM_REGS_H__ */
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display 20+
2025-01-28 15:51 ` [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display 20+ Arun R Murthy
@ 2025-02-17 6:25 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-17 6:25 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display
> 20+
>
> In Display 20+, new registers are added for setting index, reading histogram and
> writing the IET.
>
> v2: Removed duplicate code (Jani)
> v3: Moved histogram core changes to earlier patches (Jani/Suraj)
> v4: Rebased after addressing comments on patch 1
> v5: Added the retry logic from patch3 and rebased the patch series
> v6: optimize wite_iet() (Suraj)
>
> Bspec: 68895
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
We need to remove the Rb from this patch because some changes will come to this patch
Because of the comments left on some of the previous patches.
> ---
> drivers/gpu/drm/i915/display/intel_histogram.c | 108 +++++++++++++++-----
> -
> .../gpu/drm/i915/display/intel_histogram_regs.h | 25 +++++
> 2 files changed, 104 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index
> dd4ab30795df48011013c019d7525e046cdd5404..f6844449e4bb6167116d223a
> f316e5f3a5e8707c 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -22,6 +22,37 @@
> #define HISTOGRAM_BIN_READ_RETRY_COUNT 5 #define
> IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
>
> +static void set_bin_index_0(struct intel_display *display, enum pipe
> +pipe) {
> + if (DISPLAY_VER(display) >= 20)
> + intel_de_rmw(display, DPST_IE_INDEX(pipe),
> + DPST_IE_BIN_INDEX_MASK,
> DPST_IE_BIN_INDEX(0));
> + else
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_MASK,
> + DPST_CTL_BIN_REG_CLEAR);
> +}
> +
> +static void write_iet(struct intel_display *display, enum pipe pipe,
> + u32 *data)
> +{
> + int i;
> +
> + for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
> + if (DISPLAY_VER(display) >= 20)
> + intel_de_rmw(display, DPST_IE_BIN(pipe),
> + DPST_IE_BIN_DATA_MASK,
> + DPST_IE_BIN_DATA(data[i]));
> + else
> + intel_de_rmw(display, DPST_BIN(pipe),
> + DPST_BIN_DATA_MASK,
> + DPST_BIN_DATA(data[i]));
Change needs to comes in which we write to dpst_bin_data on 0:23 or 0:9 depending on if we are writing histogram data or iet data
> +
> + drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n",
> + i, data[i]);
Drm_dbg_kms
> + }
> +}
> +
> static bool intel_histogram_get_data(struct intel_crtc *intel_crtc) {
> struct intel_display *display = to_intel_display(intel_crtc); @@ -29,12
> +60,27 @@ static bool intel_histogram_get_data(struct intel_crtc *intel_crtc)
> int index;
> u32 dpstbin;
>
> + if (DISPLAY_VER(display) >= 20)
> + intel_de_rmw(display, DPST_HIST_INDEX(intel_crtc->pipe),
> + DPST_HIST_BIN_INDEX_MASK,
> + DPST_HIST_BIN_INDEX(0));
> + else
> + intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
> +
> for (index = 0; index < ARRAY_SIZE(histogram->bin_data); index++) {
> - dpstbin = intel_de_read(display, DPST_BIN(intel_crtc->pipe));
> + dpstbin = intel_de_read(display, (DISPLAY_VER(display) >= 20 ?
> + DPST_HIST_BIN(intel_crtc->pipe) :
> + DPST_BIN(intel_crtc->pipe)));
> if (!(dpstbin & DPST_BIN_BUSY)) {
> - histogram->bin_data[index] = dpstbin &
> DPST_BIN_DATA_MASK;
> - } else
> + histogram->bin_data[index] = dpstbin &
> (DISPLAY_VER(display) >= 20 ?
> +
> DPST_HIST_BIN_DATA_MASK :
> +
> DPST_BIN_DATA_MASK);
> + } else {
> + drm_err(display->drm, "Histogram bin busy,
> retyring\n");
Typo: * retrying
Regards,
Suraj Kandpal
> + fsleep(2);
> return false;
> + }
> }
> return true;
> }
> @@ -62,8 +108,6 @@ static void intel_histogram_handle_int_work(struct
> work_struct *work)
> * Set DPST_CTL Bin Reg function select to TC
> * Set DPST_CTL Bin Register Index to 0
> */
> - intel_de_rmw(display, DPST_CTL(intel_crtc->pipe),
> - DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_BIN_REG_MASK, 0);
> for (retry = 0; retry < HISTOGRAM_BIN_READ_RETRY_COUNT; retry++) {
> if (intel_histogram_get_data(intel_crtc)) {
> u32 *data;
> @@ -156,17 +200,27 @@ static int intel_histogram_enable(struct intel_crtc
> *intel_crtc, u8 mode)
>
> if (histogram->enable)
> return 0;
> -
> - /* enable histogram, clear DPST_CTL bin reg func select to TC */
> - intel_de_rmw(display, DPST_CTL(pipe),
> - DPST_CTL_BIN_REG_FUNC_SEL | DPST_CTL_IE_HIST_EN |
> - DPST_CTL_HIST_MODE |
> DPST_CTL_IE_TABLE_VALUE_FORMAT |
> - DPST_CTL_ENHANCEMENT_MODE_MASK |
> DPST_CTL_IE_MODI_TABLE_EN,
> - ((mode == DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> - DPST_CTL_BIN_REG_FUNC_TC : 0) | DPST_CTL_IE_HIST_EN
> |
> - DPST_CTL_HIST_MODE_HSV |
> - DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC |
> - DPST_CTL_EN_MULTIPLICATIVE |
> DPST_CTL_IE_MODI_TABLE_EN);
> + /* enable histogram, clear DPST_BIN reg and select TC function */
> + if (DISPLAY_VER(display) >= 20)
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE,
> + DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE_HSV);
> + else
> + /* enable histogram, clear DPST_CTL bin reg func select to TC
> */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL |
> DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE |
> + DPST_CTL_IE_TABLE_VALUE_FORMAT |
> + DPST_CTL_ENHANCEMENT_MODE_MASK |
> + DPST_CTL_IE_MODI_TABLE_EN,
> + ((mode ==
> DRM_MODE_HISTOGRAM_HSV_MAX_RGB) ?
> + DPST_CTL_BIN_REG_FUNC_TC : 0) |
> + DPST_CTL_IE_HIST_EN |
> + DPST_CTL_HIST_MODE_HSV |
> + DPST_CTL_IE_TABLE_VALUE_FORMAT_1INT_9FRAC
> |
> + DPST_CTL_EN_MULTIPLICATIVE |
> DPST_CTL_IE_MODI_TABLE_EN);
>
> /* Re-Visit: check if wait for one vblank is required */
> drm_crtc_wait_one_vblank(&intel_crtc->base);
> @@ -244,7 +298,6 @@ int intel_histogram_set_iet_lut(struct intel_crtc
> *intel_crtc,
> struct intel_histogram *histogram = intel_crtc->histogram;
> struct intel_display *display = to_intel_display(intel_crtc);
> int pipe = intel_crtc->pipe;
> - int i = 0;
> struct drm_iet_1dlut_sample *iet;
> u32 *data;
> int ret;
> @@ -262,15 +315,15 @@ int intel_histogram_set_iet_lut(struct intel_crtc
> *intel_crtc,
> return -EINVAL;
> }
>
> - /* Set DPST_CTL Bin Reg function select to IE & wait for a vblabk */
> - intel_de_rmw(display, DPST_CTL(pipe),
> - DPST_CTL_BIN_REG_FUNC_SEL,
> DPST_CTL_BIN_REG_FUNC_IE);
>
> - drm_crtc_wait_one_vblank(&intel_crtc->base);
> + if (DISPLAY_VER(display) < 20) {
> + /* Set DPST_CTL Bin Reg function select to IE & wait for a
> vblabk */
> + intel_de_rmw(display, DPST_CTL(pipe),
> + DPST_CTL_BIN_REG_FUNC_SEL,
> + DPST_CTL_BIN_REG_FUNC_IE);
> + }
>
> - /* Set DPST_CTL Bin Register Index to 0 */
> - intel_de_rmw(display, DPST_CTL(pipe),
> - DPST_CTL_BIN_REG_MASK, DPST_CTL_BIN_REG_CLEAR);
> + set_bin_index_0(display, pipe);
>
> iet = (struct drm_iet_1dlut_sample *)blob->data;
> data = kzalloc(sizeof(data) * iet->nr_elements, GFP_KERNEL); @@ -
> 281,11 +334,8 @@ int intel_histogram_set_iet_lut(struct intel_crtc *intel_crtc,
> if (ret)
> return ret;
>
> - for (i = 0; i < HISTOGRAM_IET_LENGTH; i++) {
> - intel_de_rmw(display, DPST_BIN(pipe),
> - DPST_BIN_DATA_MASK, data[i]);
> - drm_dbg_atomic(display->drm, "iet_lut[%d]=%x\n", i, data[i]);
> - }
> + write_iet(display, pipe, data);
> +
> kfree(data);
> drm_property_blob_put(intel_crtc->base.state->iet_lut);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram_regs.h
> b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
> index
> 213c9f483567cb19a47b44953749f6baf0afe9e7..3fbb9c2deaae6278d5a832dfb6
> 1ef860de0c6f21 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_histogram_regs.h
> @@ -45,6 +45,31 @@
> #define _DPST_BIN_B 0x491C4
> #define DPST_BIN(pipe)
> _MMIO_PIPE(pipe, _DPST_BIN_A, _DPST_BIN_B)
> #define DPST_BIN_DATA_MASK
> REG_GENMASK(23, 0)
> +#define DPST_BIN_DATA(val)
> REG_FIELD_PREP(DPST_BIN_DATA_MASK, val)
> #define DPST_BIN_BUSY REG_BIT(31)
>
> +#define _DPST_HIST_INDEX_A 0x490D8
> +#define _DPST_HIST_INDEX_B 0x491D8
> +#define DPST_HIST_INDEX(pipe)
> _MMIO_PIPE(pipe, _DPST_HIST_INDEX_A, _DPST_HIST_INDEX_B)
> +#define DPST_HIST_BIN_INDEX_MASK REG_GENMASK(4, 0)
> +#define DPST_HIST_BIN_INDEX(val)
> REG_FIELD_PREP(DPST_HIST_BIN_INDEX_MASK, val)
> +
> +#define _DPST_HIST_BIN_A 0x490C4
> +#define _DPST_HIST_BIN_B 0x491C4
> +#define DPST_HIST_BIN(pipe) _MMIO_PIPE(pipe,
> _DPST_HIST_BIN_A, _DPST_HIST_BIN_B)
> +#define DPST_HIST_BIN_BUSY REG_BIT(31)
> +#define DPST_HIST_BIN_DATA_MASK
> REG_GENMASK(30, 0)
> +
> +#define _DPST_IE_BIN_A 0x490CC
> +#define _DPST_IE_BIN_B 0x491CC
> +#define DPST_IE_BIN(pipe) _MMIO_PIPE(pipe,
> _DPST_IE_BIN_A, _DPST_IE_BIN_B)
> +#define DPST_IE_BIN_DATA_MASK
> REG_GENMASK(9, 0)
> +#define DPST_IE_BIN_DATA(val)
> REG_FIELD_PREP(DPST_IE_BIN_DATA_MASK, val)
> +
> +#define _DPST_IE_INDEX_A 0x490DC
> +#define _DPST_IE_INDEX_B 0x491DC
> +#define DPST_IE_INDEX(pipe) _MMIO_PIPE(pipe,
> _DPST_IE_INDEX_A, _DPST_IE_INDEX_B)
> +#define DPST_IE_BIN_INDEX_MASK
> REG_GENMASK(6, 0)
> +#define DPST_IE_BIN_INDEX(val)
> REG_FIELD_PREP(DPST_IE_BIN_INDEX_MASK, val)
> +
> #endif /* __INTEL_HISTOGRAM_REGS_H__ */
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (12 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 13/14] drm/i915/histogram: Histogram changes for Display 20+ Arun R Murthy
@ 2025-01-28 15:51 ` Arun R Murthy
2025-02-17 6:20 ` Kandpal, Suraj
2025-01-28 19:26 ` ✗ Fi.CI.BUILD: warning for Display Global Histogram (rev13) Patchwork
` (2 subsequent siblings)
16 siblings, 1 reply; 58+ messages in thread
From: Arun R Murthy @ 2025-01-28 15:51 UTC (permalink / raw)
To: intel-xe, intel-gfx, dri-devel
Cc: suraj.kandpal, dmitry.baryshkov, Arun R Murthy
Enable pipe dithering while enabling histogram to overcome some
atrifacts seen on the screen.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
---
drivers/gpu/drm/i915/display/intel_histogram.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c b/drivers/gpu/drm/i915/display/intel_histogram.c
index f6844449e4bb6167116d223af316e5f3a5e8707c..ead9c2391d460f459dfca8e99ea423a34418e67d 100644
--- a/drivers/gpu/drm/i915/display/intel_histogram.c
+++ b/drivers/gpu/drm/i915/display/intel_histogram.c
@@ -22,6 +22,13 @@
#define HISTOGRAM_BIN_READ_RETRY_COUNT 5
#define IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
+static void intel_histogram_enable_dithering(struct intel_display *display,
+ enum pipe pipe)
+{
+ intel_de_rmw(display, PIPE_MISC(pipe), PIPE_MISC_DITHER_ENABLE,
+ PIPE_MISC_DITHER_ENABLE);
+}
+
static void set_bin_index_0(struct intel_display *display, enum pipe pipe)
{
if (DISPLAY_VER(display) >= 20)
@@ -200,6 +207,10 @@ static int intel_histogram_enable(struct intel_crtc *intel_crtc, u8 mode)
if (histogram->enable)
return 0;
+
+ /* Pipe Dithering should be enabled with histogram */
+ intel_histogram_enable_dithering(display, pipe);
+
/* enable histogram, clear DPST_BIN reg and select TC function */
if (DISPLAY_VER(display) >= 20)
intel_de_rmw(display, DPST_CTL(pipe),
--
2.25.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* RE: [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering
2025-01-28 15:51 ` [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering Arun R Murthy
@ 2025-02-17 6:20 ` Kandpal, Suraj
0 siblings, 0 replies; 58+ messages in thread
From: Kandpal, Suraj @ 2025-02-17 6:20 UTC (permalink / raw)
To: Murthy, Arun R, intel-xe@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: dmitry.baryshkov@linaro.org
> -----Original Message-----
> From: Murthy, Arun R <arun.r.murthy@intel.com>
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> devel@lists.freedesktop.org
> Cc: Kandpal, Suraj <suraj.kandpal@intel.com>; dmitry.baryshkov@linaro.org;
> Murthy, Arun R <arun.r.murthy@intel.com>
> Subject: [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering
>
> Enable pipe dithering while enabling histogram to overcome some atrifacts
Typo: *artifacts
> seen on the screen.
>
> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_histogram.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_histogram.c
> b/drivers/gpu/drm/i915/display/intel_histogram.c
> index
> f6844449e4bb6167116d223af316e5f3a5e8707c..ead9c2391d460f459dfca8e99
> ea423a34418e67d 100644
> --- a/drivers/gpu/drm/i915/display/intel_histogram.c
> +++ b/drivers/gpu/drm/i915/display/intel_histogram.c
> @@ -22,6 +22,13 @@
> #define HISTOGRAM_BIN_READ_RETRY_COUNT 5 #define
> IET_SAMPLE_FORMAT_1_INT_9_FRACT 0x1000009
>
> +static void intel_histogram_enable_dithering(struct intel_display *display,
> + enum pipe pipe)
Align with parenthesis
With the above fixed.
LGTM,
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
> +{
> + intel_de_rmw(display, PIPE_MISC(pipe), PIPE_MISC_DITHER_ENABLE,
> + PIPE_MISC_DITHER_ENABLE);
> +}
> +
> static void set_bin_index_0(struct intel_display *display, enum pipe pipe) {
> if (DISPLAY_VER(display) >= 20)
> @@ -200,6 +207,10 @@ static int intel_histogram_enable(struct intel_crtc
> *intel_crtc, u8 mode)
>
> if (histogram->enable)
> return 0;
> +
> + /* Pipe Dithering should be enabled with histogram */
> + intel_histogram_enable_dithering(display, pipe);
> +
> /* enable histogram, clear DPST_BIN reg and select TC function */
> if (DISPLAY_VER(display) >= 20)
> intel_de_rmw(display, DPST_CTL(pipe),
>
> --
> 2.25.1
^ permalink raw reply [flat|nested] 58+ messages in thread
* ✗ Fi.CI.BUILD: warning for Display Global Histogram (rev13)
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (13 preceding siblings ...)
2025-01-28 15:51 ` [PATCH v8 14/14] drm/i915/histogram: Enable pipe dithering Arun R Murthy
@ 2025-01-28 19:26 ` Patchwork
2025-01-28 19:43 ` ✓ i915.CI.BAT: success " Patchwork
2025-01-29 10:34 ` ✗ i915.CI.Full: failure " Patchwork
16 siblings, 0 replies; 58+ messages in thread
From: Patchwork @ 2025-01-28 19:26 UTC (permalink / raw)
To: Arun R Murthy; +Cc: intel-gfx
== Series Details ==
Series: Display Global Histogram (rev13)
URL : https://patchwork.freedesktop.org/series/135793/
State : warning
== Summary ==
Error: patch https://patchwork.freedesktop.org/api/1.0/series/135793/revisions/13/mbox/ not found
^ permalink raw reply [flat|nested] 58+ messages in thread* ✓ i915.CI.BAT: success for Display Global Histogram (rev13)
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (14 preceding siblings ...)
2025-01-28 19:26 ` ✗ Fi.CI.BUILD: warning for Display Global Histogram (rev13) Patchwork
@ 2025-01-28 19:43 ` Patchwork
2025-01-29 10:34 ` ✗ i915.CI.Full: failure " Patchwork
16 siblings, 0 replies; 58+ messages in thread
From: Patchwork @ 2025-01-28 19:43 UTC (permalink / raw)
To: Arun R Murthy; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5865 bytes --]
== Series Details ==
Series: Display Global Histogram (rev13)
URL : https://patchwork.freedesktop.org/series/135793/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16035 -> Patchwork_135793v13
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/index.html
Participating hosts (43 -> 42)
------------------------------
Missing (1): fi-snb-2520m
Known issues
------------
Here are the changes found in Patchwork_135793v13 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_pm_rpm@module-reload:
- bat-dg2-11: [PASS][1] -> [FAIL][2] ([i915#13401])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-dg2-11/igt@i915_pm_rpm@module-reload.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-dg2-11/igt@i915_pm_rpm@module-reload.html
- bat-dg1-7: [PASS][3] -> [FAIL][4] ([i915#13401])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-dg1-7/igt@i915_pm_rpm@module-reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-dg1-7/igt@i915_pm_rpm@module-reload.html
- bat-rpls-4: [PASS][5] -> [FAIL][6] ([i915#13401])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-rpls-4/igt@i915_pm_rpm@module-reload.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-rpls-4/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live:
- bat-mtlp-8: [PASS][7] -> [DMESG-FAIL][8] ([i915#12061]) +1 other test dmesg-fail
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-mtlp-8/igt@i915_selftest@live.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-mtlp-8/igt@i915_selftest@live.html
- bat-arlh-3: [PASS][9] -> [DMESG-FAIL][10] ([i915#12061] / [i915#12435])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-arlh-3/igt@i915_selftest@live.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-arlh-3/igt@i915_selftest@live.html
* igt@i915_selftest@live@workarounds:
- bat-arlh-3: [PASS][11] -> [DMESG-FAIL][12] ([i915#12061])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-arlh-3/igt@i915_selftest@live@workarounds.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-arlh-3/igt@i915_selftest@live@workarounds.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: [PASS][13] -> [SKIP][14] ([i915#9197]) +3 other tests skip
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence.html
#### Possible fixes ####
* igt@i915_selftest@live:
- bat-twl-2: [ABORT][15] ([i915#12919]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-twl-2/igt@i915_selftest@live.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-twl-2/igt@i915_selftest@live.html
* igt@i915_selftest@live@gt_contexts:
- bat-twl-2: [ABORT][17] -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/bat-twl-2/igt@i915_selftest@live@gt_contexts.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/bat-twl-2/igt@i915_selftest@live@gt_contexts.html
#### Warnings ####
* igt@i915_module_load@reload:
- fi-kbl-7567u: [DMESG-WARN][19] ([i915#11621] / [i915#180] / [i915#1982]) -> [DMESG-WARN][20] ([i915#11621] / [i915#180])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/fi-kbl-7567u/igt@i915_module_load@reload.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/fi-kbl-7567u/igt@i915_module_load@reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- fi-kbl-7567u: [DMESG-WARN][21] ([i915#11621] / [i915#180]) -> [DMESG-WARN][22] ([i915#11621] / [i915#180] / [i915#1982]) +1 other test dmesg-warn
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/fi-kbl-7567u/igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/fi-kbl-7567u/igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#11621]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11621
[i915#12061]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
[i915#12435]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12435
[i915#12919]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12919
[i915#13401]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13401
[i915#13577]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13577
[i915#180]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/180
[i915#1982]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/1982
[i915#9197]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/9197
Build changes
-------------
* Linux: CI_DRM_16035 -> Patchwork_135793v13
CI-20190529: 20190529
CI_DRM_16035: 20759526c04a7f776f477bee66300dae33b51872 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_8212: 76102a17560c6e6fc6528db29286b0266ccc48ef @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_135793v13: 20759526c04a7f776f477bee66300dae33b51872 @ git://anongit.freedesktop.org/gfx-ci/linux
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/index.html
[-- Attachment #2: Type: text/html, Size: 7409 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread* ✗ i915.CI.Full: failure for Display Global Histogram (rev13)
2025-01-28 15:51 [PATCH v8 00/14] Display Global Histogram Arun R Murthy
` (15 preceding siblings ...)
2025-01-28 19:43 ` ✓ i915.CI.BAT: success " Patchwork
@ 2025-01-29 10:34 ` Patchwork
16 siblings, 0 replies; 58+ messages in thread
From: Patchwork @ 2025-01-29 10:34 UTC (permalink / raw)
To: Arun R Murthy; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 100260 bytes --]
== Series Details ==
Series: Display Global Histogram (rev13)
URL : https://patchwork.freedesktop.org/series/135793/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16035_full -> Patchwork_135793v13_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_135793v13_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_135793v13_full, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/index.html
Participating hosts (11 -> 11)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_135793v13_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-mtlp: [PASS][1] -> [DMESG-WARN][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-2/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-7/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-mtlp: [PASS][3] -> [ABORT][4] +3 other tests abort
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-1/igt@gem_eio@in-flight-contexts-immediate.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-7/igt@gem_eio@in-flight-contexts-immediate.html
* igt@kms_pm_dc@dc5-psr:
- shard-mtlp: [PASS][5] -> [FAIL][6] +1 other test fail
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-6/igt@kms_pm_dc@dc5-psr.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-1/igt@kms_pm_dc@dc5-psr.html
* igt@kms_properties@get_properties-sanity-atomic:
- shard-dg2: [PASS][7] -> [FAIL][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-5/igt@kms_properties@get_properties-sanity-atomic.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-3/igt@kms_properties@get_properties-sanity-atomic.html
- shard-rkl: [PASS][9] -> [FAIL][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-1/igt@kms_properties@get_properties-sanity-atomic.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-6/igt@kms_properties@get_properties-sanity-atomic.html
- shard-dg1: NOTRUN -> [FAIL][11]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_properties@get_properties-sanity-atomic.html
- shard-snb: [PASS][12] -> [FAIL][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-snb2/igt@kms_properties@get_properties-sanity-atomic.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb1/igt@kms_properties@get_properties-sanity-atomic.html
- shard-tglu: [PASS][14] -> [FAIL][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-4/igt@kms_properties@get_properties-sanity-atomic.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-2/igt@kms_properties@get_properties-sanity-atomic.html
* igt@perf_pmu@module-unload:
- shard-rkl: [PASS][16] -> [INCOMPLETE][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-2/igt@perf_pmu@module-unload.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@perf_pmu@module-unload.html
Known issues
------------
Here are the changes found in Patchwork_135793v13_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@device_reset@cold-reset-bound:
- shard-rkl: NOTRUN -> [SKIP][18] ([i915#11078])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@device_reset@cold-reset-bound.html
* igt@device_reset@unbind-reset-rebind:
- shard-dg1: NOTRUN -> [ABORT][19] ([i915#11814] / [i915#11815] / [i915#9413])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@device_reset@unbind-reset-rebind.html
- shard-tglu: [PASS][20] -> [ABORT][21] ([i915#12817] / [i915#5507])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-4/igt@device_reset@unbind-reset-rebind.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-2/igt@device_reset@unbind-reset-rebind.html
* igt@drm_fdinfo@busy-hang@rcs0:
- shard-mtlp: NOTRUN -> [SKIP][22] ([i915#8414]) +8 other tests skip
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@drm_fdinfo@busy-hang@rcs0.html
* igt@drm_fdinfo@busy@rcs0:
- shard-dg2: NOTRUN -> [SKIP][23] ([i915#8414]) +8 other tests skip
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@drm_fdinfo@busy@rcs0.html
* igt@drm_fdinfo@most-busy-idle-check-all@bcs0:
- shard-dg1: NOTRUN -> [SKIP][24] ([i915#8414]) +6 other tests skip
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@drm_fdinfo@most-busy-idle-check-all@bcs0.html
* igt@gem_busy@semaphore:
- shard-dg2: NOTRUN -> [SKIP][25] ([i915#3936])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_busy@semaphore.html
* igt@gem_ccs@block-copy-compressed:
- shard-rkl: NOTRUN -> [SKIP][26] ([i915#3555] / [i915#9323])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@gem_ccs@block-copy-compressed.html
* igt@gem_ccs@block-multicopy-inplace:
- shard-dg1: NOTRUN -> [SKIP][27] ([i915#3555] / [i915#9323])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_ccs@block-multicopy-inplace.html
- shard-tglu: NOTRUN -> [SKIP][28] ([i915#3555] / [i915#9323])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@gem_ccs@block-multicopy-inplace.html
* igt@gem_ccs@ctrl-surf-copy:
- shard-mtlp: NOTRUN -> [SKIP][29] ([i915#3555] / [i915#9323]) +1 other test skip
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_ccs@ctrl-surf-copy.html
* igt@gem_ccs@ctrl-surf-copy-new-ctx:
- shard-dg1: NOTRUN -> [SKIP][30] ([i915#9323])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_ccs@ctrl-surf-copy-new-ctx.html
* igt@gem_ccs@suspend-resume:
- shard-tglu: NOTRUN -> [SKIP][31] ([i915#9323])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@gem_ccs@suspend-resume.html
* igt@gem_ccs@suspend-resume@tile4-compressed-compfmt0-smem-lmem0:
- shard-dg2: NOTRUN -> [INCOMPLETE][32] ([i915#12392] / [i915#7297])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-7/igt@gem_ccs@suspend-resume@tile4-compressed-compfmt0-smem-lmem0.html
* igt@gem_close_race@multigpu-basic-threads:
- shard-tglu: NOTRUN -> [SKIP][33] ([i915#7697])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@gem_close_race@multigpu-basic-threads.html
* igt@gem_create@create-ext-cpu-access-big:
- shard-rkl: NOTRUN -> [SKIP][34] ([i915#6335])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@gem_create@create-ext-cpu-access-big.html
* igt@gem_create@create-ext-cpu-access-sanity-check:
- shard-tglu-1: NOTRUN -> [SKIP][35] ([i915#6335])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_create@create-ext-cpu-access-sanity-check.html
* igt@gem_create@create-ext-set-pat:
- shard-tglu-1: NOTRUN -> [SKIP][36] ([i915#8562])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_create@create-ext-set-pat.html
- shard-dg1: NOTRUN -> [SKIP][37] ([i915#8562])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@gem_create@create-ext-set-pat.html
* igt@gem_ctx_persistence@heartbeat-stop:
- shard-mtlp: NOTRUN -> [SKIP][38] ([i915#8555]) +1 other test skip
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_ctx_persistence@heartbeat-stop.html
* igt@gem_ctx_persistence@legacy-engines-hostile-preempt:
- shard-snb: NOTRUN -> [SKIP][39] ([i915#1099]) +1 other test skip
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb7/igt@gem_ctx_persistence@legacy-engines-hostile-preempt.html
* igt@gem_ctx_persistence@saturated-hostile-nopreempt@vcs0:
- shard-mtlp: NOTRUN -> [SKIP][40] ([i915#5882]) +6 other tests skip
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_ctx_persistence@saturated-hostile-nopreempt@vcs0.html
* igt@gem_ctx_sseu@invalid-sseu:
- shard-dg2: NOTRUN -> [SKIP][41] ([i915#280])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_ctx_sseu@invalid-sseu.html
- shard-rkl: NOTRUN -> [SKIP][42] ([i915#280]) +1 other test skip
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@gem_ctx_sseu@invalid-sseu.html
* igt@gem_eio@hibernate:
- shard-dg1: [PASS][43] -> [ABORT][44] ([i915#7975] / [i915#8213])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-13/igt@gem_eio@hibernate.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@gem_eio@hibernate.html
- shard-rkl: NOTRUN -> [ABORT][45] ([i915#7975] / [i915#8213])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@gem_eio@hibernate.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-tglu: NOTRUN -> [SKIP][46] ([i915#4525]) +1 other test skip
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@gem_exec_balancer@parallel-balancer.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-rkl: NOTRUN -> [SKIP][47] ([i915#4525]) +1 other test skip
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_exec_balancer@parallel-bb-first.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-tglu-1: NOTRUN -> [SKIP][48] ([i915#4525])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_exec_balancer@parallel-contexts.html
* igt@gem_exec_capture@capture-invisible:
- shard-tglu-1: NOTRUN -> [SKIP][49] ([i915#6334]) +1 other test skip
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_exec_capture@capture-invisible.html
- shard-dg1: NOTRUN -> [SKIP][50] ([i915#6334]) +2 other tests skip
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@gem_exec_capture@capture-invisible.html
* igt@gem_exec_capture@capture-recoverable:
- shard-tglu-1: NOTRUN -> [SKIP][51] ([i915#6344])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_exec_capture@capture-recoverable.html
* igt@gem_exec_capture@capture@vecs0-lmem0:
- shard-dg1: NOTRUN -> [FAIL][52] ([i915#11965]) +2 other tests fail
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@gem_exec_capture@capture@vecs0-lmem0.html
* igt@gem_exec_fence@submit:
- shard-dg1: NOTRUN -> [SKIP][53] ([i915#4812]) +4 other tests skip
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_exec_fence@submit.html
- shard-mtlp: NOTRUN -> [SKIP][54] ([i915#4812])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_exec_fence@submit.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-mtlp: NOTRUN -> [SKIP][55] ([i915#3711])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_exec_flush@basic-batch-kernel-default-cmd.html
* igt@gem_exec_flush@basic-uc-prw-default:
- shard-rkl: NOTRUN -> [DMESG-WARN][56] ([i915#12964]) +44 other tests dmesg-warn
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@gem_exec_flush@basic-uc-prw-default.html
* igt@gem_exec_flush@basic-uc-rw-default:
- shard-dg1: NOTRUN -> [SKIP][57] ([i915#3539] / [i915#4852]) +3 other tests skip
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@gem_exec_flush@basic-uc-rw-default.html
* igt@gem_exec_flush@basic-uc-set-default:
- shard-dg2: NOTRUN -> [SKIP][58] ([i915#3539])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_exec_flush@basic-uc-set-default.html
* igt@gem_exec_reloc@basic-cpu-noreloc:
- shard-dg2: NOTRUN -> [SKIP][59] ([i915#3281]) +1 other test skip
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_exec_reloc@basic-cpu-noreloc.html
* igt@gem_exec_reloc@basic-gtt-noreloc:
- shard-mtlp: NOTRUN -> [SKIP][60] ([i915#3281]) +6 other tests skip
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_exec_reloc@basic-gtt-noreloc.html
* igt@gem_exec_reloc@basic-wc-read:
- shard-dg1: NOTRUN -> [SKIP][61] ([i915#3281]) +13 other tests skip
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@gem_exec_reloc@basic-wc-read.html
* igt@gem_exec_reloc@basic-write-gtt:
- shard-rkl: NOTRUN -> [SKIP][62] ([i915#3281]) +8 other tests skip
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_exec_reloc@basic-write-gtt.html
* igt@gem_exec_schedule@preempt-queue-contexts:
- shard-dg2: NOTRUN -> [SKIP][63] ([i915#4537] / [i915#4812])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_exec_schedule@preempt-queue-contexts.html
* igt@gem_exec_schedule@reorder-wide:
- shard-mtlp: NOTRUN -> [SKIP][64] ([i915#4537] / [i915#4812])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_exec_schedule@reorder-wide.html
* igt@gem_exec_schedule@smoketest@vcs0:
- shard-rkl: [PASS][65] -> [DMESG-WARN][66] ([i915#12964]) +14 other tests dmesg-warn
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-1/igt@gem_exec_schedule@smoketest@vcs0.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@gem_exec_schedule@smoketest@vcs0.html
* igt@gem_exec_schedule@thriceslice:
- shard-snb: NOTRUN -> [SKIP][67] +367 other tests skip
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb7/igt@gem_exec_schedule@thriceslice.html
* igt@gem_exec_suspend@basic-s0:
- shard-dg2: [PASS][68] -> [INCOMPLETE][69] ([i915#11441] / [i915#13304])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-4/igt@gem_exec_suspend@basic-s0.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-7/igt@gem_exec_suspend@basic-s0.html
* igt@gem_exec_suspend@basic-s0@lmem0:
- shard-dg2: [PASS][70] -> [INCOMPLETE][71] ([i915#11441])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-4/igt@gem_exec_suspend@basic-s0@lmem0.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-7/igt@gem_exec_suspend@basic-s0@lmem0.html
* igt@gem_fence_thrash@bo-write-verify-none:
- shard-dg2: NOTRUN -> [SKIP][72] ([i915#4860])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_fence_thrash@bo-write-verify-none.html
* igt@gem_fenced_exec_thrash@no-spare-fences:
- shard-dg1: NOTRUN -> [SKIP][73] ([i915#4860]) +2 other tests skip
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_fenced_exec_thrash@no-spare-fences.html
* igt@gem_fenced_exec_thrash@no-spare-fences-busy:
- shard-mtlp: NOTRUN -> [SKIP][74] ([i915#4860])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_fenced_exec_thrash@no-spare-fences-busy.html
* igt@gem_lmem_swapping@heavy-random:
- shard-tglu: NOTRUN -> [SKIP][75] ([i915#4613]) +2 other tests skip
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@gem_lmem_swapping@heavy-random.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-mtlp: NOTRUN -> [SKIP][76] ([i915#4613]) +1 other test skip
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_lmem_swapping@heavy-verify-multi-ccs.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][77] ([i915#4613])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk9/igt@gem_lmem_swapping@heavy-verify-random-ccs.html
* igt@gem_lmem_swapping@massive:
- shard-rkl: NOTRUN -> [SKIP][78] ([i915#4613]) +4 other tests skip
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@gem_lmem_swapping@massive.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-tglu-1: NOTRUN -> [SKIP][79] ([i915#4613])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_lmem_swapping@parallel-random-verify.html
* igt@gem_madvise@dontneed-before-exec:
- shard-mtlp: NOTRUN -> [SKIP][80] ([i915#3282])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_madvise@dontneed-before-exec.html
* igt@gem_media_vme:
- shard-rkl: NOTRUN -> [SKIP][81] ([i915#284])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_media_vme.html
* igt@gem_mmap_gtt@basic:
- shard-mtlp: NOTRUN -> [SKIP][82] ([i915#4077]) +4 other tests skip
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_mmap_gtt@basic.html
* igt@gem_mmap_gtt@big-copy-odd:
- shard-dg2: NOTRUN -> [SKIP][83] ([i915#4077]) +3 other tests skip
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_mmap_gtt@big-copy-odd.html
* igt@gem_mmap_gtt@cpuset-basic-small-copy:
- shard-dg1: NOTRUN -> [SKIP][84] ([i915#4077]) +11 other tests skip
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@gem_mmap_gtt@cpuset-basic-small-copy.html
* igt@gem_mmap_wc@read:
- shard-dg1: NOTRUN -> [SKIP][85] ([i915#4083]) +6 other tests skip
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_mmap_wc@read.html
* igt@gem_mmap_wc@write-wc-read-gtt:
- shard-mtlp: NOTRUN -> [SKIP][86] ([i915#4083])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_mmap_wc@write-wc-read-gtt.html
* igt@gem_partial_pwrite_pread@write:
- shard-dg1: NOTRUN -> [SKIP][87] ([i915#3282]) +7 other tests skip
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_partial_pwrite_pread@write.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- shard-rkl: NOTRUN -> [SKIP][88] ([i915#3282]) +5 other tests skip
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@gem_partial_pwrite_pread@writes-after-reads-uncached.html
* igt@gem_pread@exhaustion:
- shard-tglu-1: NOTRUN -> [WARN][89] ([i915#2658])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_pread@exhaustion.html
- shard-snb: NOTRUN -> [WARN][90] ([i915#2658])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb7/igt@gem_pread@exhaustion.html
* igt@gem_pxp@create-valid-protected-context:
- shard-dg2: NOTRUN -> [SKIP][91] ([i915#4270]) +2 other tests skip
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@gem_pxp@create-valid-protected-context.html
* igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted:
- shard-rkl: NOTRUN -> [TIMEOUT][92] ([i915#12964]) +1 other test timeout
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_pxp@dmabuf-shared-protected-dst-is-context-refcounted.html
* igt@gem_pxp@hw-rejects-pxp-buffer:
- shard-rkl: NOTRUN -> [TIMEOUT][93] ([i915#12917] / [i915#12964]) +4 other tests timeout
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@gem_pxp@hw-rejects-pxp-buffer.html
* igt@gem_pxp@hw-rejects-pxp-context:
- shard-tglu: NOTRUN -> [SKIP][94] ([i915#13398])
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@gem_pxp@hw-rejects-pxp-context.html
- shard-mtlp: NOTRUN -> [SKIP][95] ([i915#13398])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_pxp@hw-rejects-pxp-context.html
* igt@gem_pxp@verify-pxp-key-change-after-suspend-resume:
- shard-dg1: NOTRUN -> [SKIP][96] ([i915#4270]) +4 other tests skip
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_pxp@verify-pxp-key-change-after-suspend-resume.html
* igt@gem_readwrite@read-bad-handle:
- shard-dg2: NOTRUN -> [SKIP][97] ([i915#3282]) +3 other tests skip
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@gem_readwrite@read-bad-handle.html
* igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs:
- shard-mtlp: NOTRUN -> [SKIP][98] ([i915#8428]) +4 other tests skip
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs.html
* igt@gem_render_copy@y-tiled-to-vebox-linear:
- shard-dg2: NOTRUN -> [SKIP][99] ([i915#5190] / [i915#8428]) +1 other test skip
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@gem_render_copy@y-tiled-to-vebox-linear.html
* igt@gem_set_tiling_vs_blt@tiled-to-tiled:
- shard-rkl: NOTRUN -> [SKIP][100] ([i915#8411])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_set_tiling_vs_blt@tiled-to-tiled.html
* igt@gem_set_tiling_vs_pwrite:
- shard-dg1: NOTRUN -> [SKIP][101] ([i915#4079]) +1 other test skip
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_set_tiling_vs_pwrite.html
- shard-mtlp: NOTRUN -> [SKIP][102] ([i915#4079]) +1 other test skip
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gem_set_tiling_vs_pwrite.html
* igt@gem_softpin@evict-snoop:
- shard-mtlp: NOTRUN -> [SKIP][103] ([i915#4885])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_softpin@evict-snoop.html
* igt@gem_tiled_pread_basic:
- shard-dg2: NOTRUN -> [SKIP][104] ([i915#4079])
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@gem_tiled_pread_basic.html
* igt@gem_tiled_swapping@non-threaded:
- shard-tglu: [PASS][105] -> [FAIL][106] ([i915#12941])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-7/igt@gem_tiled_swapping@non-threaded.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-2/igt@gem_tiled_swapping@non-threaded.html
* igt@gem_userptr_blits@access-control:
- shard-tglu-1: NOTRUN -> [SKIP][107] ([i915#3297]) +1 other test skip
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gem_userptr_blits@access-control.html
* igt@gem_userptr_blits@create-destroy-unsync:
- shard-mtlp: NOTRUN -> [SKIP][108] ([i915#3297])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@gem_userptr_blits@create-destroy-unsync.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-rkl: NOTRUN -> [SKIP][109] ([i915#3297] / [i915#3323])
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_userptr_blits@forbidden-operations:
- shard-rkl: NOTRUN -> [SKIP][110] ([i915#3282] / [i915#3297])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@gem_userptr_blits@forbidden-operations.html
* igt@gem_userptr_blits@invalid-mmap-offset-unsync:
- shard-tglu: NOTRUN -> [SKIP][111] ([i915#3297])
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@gem_userptr_blits@invalid-mmap-offset-unsync.html
* igt@gem_userptr_blits@relocations:
- shard-dg1: NOTRUN -> [SKIP][112] ([i915#3281] / [i915#3297])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_userptr_blits@relocations.html
* igt@gem_userptr_blits@unsync-unmap:
- shard-dg1: NOTRUN -> [SKIP][113] ([i915#3297]) +1 other test skip
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gem_userptr_blits@unsync-unmap.html
* igt@gen9_exec_parse@allowed-single:
- shard-dg2: NOTRUN -> [SKIP][114] ([i915#2856]) +1 other test skip
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@gen9_exec_parse@allowed-single.html
* igt@gen9_exec_parse@bb-oversize:
- shard-dg1: NOTRUN -> [SKIP][115] ([i915#2527]) +2 other tests skip
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@gen9_exec_parse@bb-oversize.html
- shard-mtlp: NOTRUN -> [SKIP][116] ([i915#2856]) +2 other tests skip
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@gen9_exec_parse@bb-oversize.html
* igt@gen9_exec_parse@bb-secure:
- shard-tglu-1: NOTRUN -> [SKIP][117] ([i915#2527] / [i915#2856])
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@gen9_exec_parse@bb-secure.html
* igt@gen9_exec_parse@bb-start-out:
- shard-rkl: NOTRUN -> [SKIP][118] ([i915#2527]) +4 other tests skip
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@gen9_exec_parse@bb-start-out.html
* igt@gen9_exec_parse@unaligned-jump:
- shard-tglu: NOTRUN -> [SKIP][119] ([i915#2527] / [i915#2856]) +1 other test skip
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@gen9_exec_parse@unaligned-jump.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-rkl: NOTRUN -> [ABORT][120] ([i915#9820])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@i915_module_load@reload-with-fault-injection.html
- shard-snb: [PASS][121] -> [ABORT][122] ([i915#9820])
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-snb1/igt@i915_module_load@reload-with-fault-injection.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb2/igt@i915_module_load@reload-with-fault-injection.html
- shard-glk: [PASS][123] -> [ABORT][124] ([i915#9820])
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-glk8/igt@i915_module_load@reload-with-fault-injection.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk1/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_freq_api@freq-basic-api:
- shard-rkl: NOTRUN -> [SKIP][125] ([i915#8399])
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@i915_pm_freq_api@freq-basic-api.html
* igt@i915_pm_freq_api@freq-reset:
- shard-tglu: NOTRUN -> [SKIP][126] ([i915#8399])
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@i915_pm_freq_api@freq-reset.html
* igt@i915_pm_freq_api@freq-suspend:
- shard-tglu-1: NOTRUN -> [SKIP][127] ([i915#8399])
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@i915_pm_freq_api@freq-suspend.html
* igt@i915_pm_freq_mult@media-freq@gt0:
- shard-tglu: NOTRUN -> [SKIP][128] ([i915#6590]) +1 other test skip
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@i915_pm_freq_mult@media-freq@gt0.html
* igt@i915_pm_rps@min-max-config-idle:
- shard-dg1: NOTRUN -> [SKIP][129] ([i915#11681] / [i915#6621])
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@i915_pm_rps@min-max-config-idle.html
* igt@i915_pm_rps@thresholds:
- shard-dg1: NOTRUN -> [SKIP][130] ([i915#11681])
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@i915_pm_rps@thresholds.html
* igt@i915_pm_rps@thresholds-idle:
- shard-dg2: NOTRUN -> [SKIP][131] ([i915#11681])
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@i915_pm_rps@thresholds-idle.html
* igt@i915_pm_sseu@full-enable:
- shard-rkl: NOTRUN -> [SKIP][132] ([i915#4387])
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@i915_pm_sseu@full-enable.html
* igt@i915_power@sanity:
- shard-rkl: NOTRUN -> [SKIP][133] ([i915#7984])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@i915_power@sanity.html
* igt@i915_query@hwconfig_table:
- shard-dg1: NOTRUN -> [SKIP][134] ([i915#6245])
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@i915_query@hwconfig_table.html
* igt@i915_query@query-topology-coherent-slice-mask:
- shard-mtlp: NOTRUN -> [SKIP][135] ([i915#6188])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@i915_query@query-topology-coherent-slice-mask.html
* igt@i915_query@test-query-geometry-subslices:
- shard-dg1: NOTRUN -> [SKIP][136] ([i915#5723])
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@i915_query@test-query-geometry-subslices.html
* igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling:
- shard-mtlp: NOTRUN -> [SKIP][137] ([i915#4212]) +1 other test skip
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling.html
* igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- shard-dg1: NOTRUN -> [SKIP][138] ([i915#4212]) +2 other tests skip
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_addfb_basic@framebuffer-vs-set-tiling.html
* igt@kms_async_flips@async-flip-with-page-flip-events-atomic@pipe-b-hdmi-a-3-4-rc-ccs-cc:
- shard-dg2: NOTRUN -> [SKIP][139] ([i915#8709]) +7 other tests skip
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_async_flips@async-flip-with-page-flip-events-atomic@pipe-b-hdmi-a-3-4-rc-ccs-cc.html
* igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-2-y-rc-ccs-cc:
- shard-rkl: NOTRUN -> [SKIP][140] ([i915#8709]) +3 other tests skip
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-3/igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-hdmi-a-2-y-rc-ccs-cc.html
* igt@kms_atomic_transition@plane-all-modeset-transition-fencing-internal-panels:
- shard-rkl: NOTRUN -> [SKIP][141] ([i915#1769] / [i915#3555])
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@kms_atomic_transition@plane-all-modeset-transition-fencing-internal-panels.html
* igt@kms_big_fb@4-tiled-addfb:
- shard-tglu-1: NOTRUN -> [SKIP][142] ([i915#5286]) +2 other tests skip
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_big_fb@4-tiled-addfb.html
- shard-dg1: NOTRUN -> [SKIP][143] ([i915#5286])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_big_fb@4-tiled-addfb.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-rkl: NOTRUN -> [SKIP][144] ([i915#5286]) +7 other tests skip
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180:
- shard-tglu: NOTRUN -> [SKIP][145] ([i915#5286]) +3 other tests skip
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-dg1: NOTRUN -> [SKIP][146] ([i915#4538] / [i915#5286]) +4 other tests skip
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][147] +63 other tests skip
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk9/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-270:
- shard-dg2: NOTRUN -> [SKIP][148] +6 other tests skip
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_big_fb@x-tiled-32bpp-rotate-270.html
- shard-rkl: NOTRUN -> [SKIP][149] ([i915#3638]) +2 other tests skip
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_big_fb@x-tiled-32bpp-rotate-270.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-dg1: NOTRUN -> [SKIP][150] ([i915#3638])
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html
* igt@kms_big_fb@y-tiled-addfb:
- shard-dg2: NOTRUN -> [SKIP][151] ([i915#5190])
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_big_fb@y-tiled-addfb.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip:
- shard-mtlp: NOTRUN -> [SKIP][152] +7 other tests skip
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
- shard-dg1: NOTRUN -> [DMESG-WARN][153] ([i915#4423]) +2 other tests dmesg-warn
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-dg2: NOTRUN -> [SKIP][154] ([i915#4538] / [i915#5190]) +4 other tests skip
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-dg1: NOTRUN -> [SKIP][155] ([i915#4538]) +4 other tests skip
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_ccs@bad-rotation-90-4-tiled-dg2-rc-ccs-cc@pipe-b-hdmi-a-1:
- shard-tglu-1: NOTRUN -> [SKIP][156] ([i915#6095]) +29 other tests skip
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_ccs@bad-rotation-90-4-tiled-dg2-rc-ccs-cc@pipe-b-hdmi-a-1.html
* igt@kms_ccs@crc-primary-basic-4-tiled-dg2-rc-ccs@pipe-b-hdmi-a-1:
- shard-tglu: NOTRUN -> [SKIP][157] ([i915#6095]) +49 other tests skip
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_ccs@crc-primary-basic-4-tiled-dg2-rc-ccs@pipe-b-hdmi-a-1.html
* igt@kms_ccs@crc-primary-basic-4-tiled-mtl-rc-ccs:
- shard-dg2: NOTRUN -> [SKIP][158] ([i915#10307] / [i915#6095]) +126 other tests skip
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_ccs@crc-primary-basic-4-tiled-mtl-rc-ccs.html
* igt@kms_ccs@crc-primary-basic-y-tiled-ccs@pipe-d-edp-1:
- shard-mtlp: NOTRUN -> [SKIP][159] ([i915#6095]) +34 other tests skip
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_ccs@crc-primary-basic-y-tiled-ccs@pipe-d-edp-1.html
* igt@kms_ccs@crc-primary-rotation-180-4-tiled-bmg-ccs:
- shard-tglu-1: NOTRUN -> [SKIP][160] ([i915#12313])
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_ccs@crc-primary-rotation-180-4-tiled-bmg-ccs.html
* igt@kms_ccs@crc-primary-rotation-180-4-tiled-mtl-mc-ccs@pipe-d-hdmi-a-1:
- shard-dg2: NOTRUN -> [SKIP][161] ([i915#10307] / [i915#10434] / [i915#6095]) +2 other tests skip
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-8/igt@kms_ccs@crc-primary-rotation-180-4-tiled-mtl-mc-ccs@pipe-d-hdmi-a-1.html
* igt@kms_ccs@crc-primary-suspend-4-tiled-bmg-ccs:
- shard-mtlp: NOTRUN -> [SKIP][162] ([i915#12805])
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_ccs@crc-primary-suspend-4-tiled-bmg-ccs.html
* igt@kms_ccs@crc-primary-suspend-4-tiled-lnl-ccs:
- shard-dg2: NOTRUN -> [SKIP][163] ([i915#12805])
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_ccs@crc-primary-suspend-4-tiled-lnl-ccs.html
- shard-rkl: NOTRUN -> [SKIP][164] ([i915#12805])
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@kms_ccs@crc-primary-suspend-4-tiled-lnl-ccs.html
* igt@kms_ccs@crc-primary-suspend-4-tiled-mtl-rc-ccs-cc@pipe-d-hdmi-a-1:
- shard-dg2: NOTRUN -> [SKIP][165] ([i915#6095]) +15 other tests skip
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-4/igt@kms_ccs@crc-primary-suspend-4-tiled-mtl-rc-ccs-cc@pipe-d-hdmi-a-1.html
* igt@kms_ccs@crc-primary-suspend-4-tiled-mtl-rc-ccs@pipe-b-hdmi-a-2:
- shard-rkl: NOTRUN -> [SKIP][166] ([i915#6095]) +63 other tests skip
[166]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-3/igt@kms_ccs@crc-primary-suspend-4-tiled-mtl-rc-ccs@pipe-b-hdmi-a-2.html
* igt@kms_ccs@crc-sprite-planes-basic-4-tiled-lnl-ccs:
- shard-dg1: NOTRUN -> [SKIP][167] ([i915#12313]) +3 other tests skip
[167]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-lnl-ccs.html
- shard-tglu: NOTRUN -> [SKIP][168] ([i915#12313]) +1 other test skip
[168]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-lnl-ccs.html
- shard-mtlp: NOTRUN -> [SKIP][169] ([i915#12313])
[169]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-lnl-ccs.html
* igt@kms_ccs@random-ccs-data-4-tiled-bmg-ccs:
- shard-rkl: NOTRUN -> [SKIP][170] ([i915#12313])
[170]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_ccs@random-ccs-data-4-tiled-bmg-ccs.html
* igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs@pipe-a-hdmi-a-3:
- shard-dg1: NOTRUN -> [SKIP][171] ([i915#6095]) +130 other tests skip
[171]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs@pipe-a-hdmi-a-3.html
* igt@kms_cdclk@mode-transition:
- shard-dg2: NOTRUN -> [SKIP][172] ([i915#11616] / [i915#7213])
[172]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_cdclk@mode-transition.html
- shard-rkl: NOTRUN -> [SKIP][173] ([i915#3742])
[173]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@kms_cdclk@mode-transition.html
* igt@kms_cdclk@mode-transition-all-outputs:
- shard-tglu-1: NOTRUN -> [SKIP][174] ([i915#3742])
[174]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_cdclk@mode-transition-all-outputs.html
* igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3:
- shard-dg2: NOTRUN -> [SKIP][175] ([i915#7213]) +3 other tests skip
[175]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3.html
* igt@kms_cdclk@plane-scaling@pipe-d-hdmi-a-1:
- shard-dg2: NOTRUN -> [SKIP][176] ([i915#4087]) +3 other tests skip
[176]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-4/igt@kms_cdclk@plane-scaling@pipe-d-hdmi-a-1.html
* igt@kms_chamelium_edid@dp-edid-change-during-suspend:
- shard-tglu: NOTRUN -> [SKIP][177] ([i915#11151] / [i915#7828]) +5 other tests skip
[177]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_chamelium_edid@dp-edid-change-during-suspend.html
* igt@kms_chamelium_frames@hdmi-cmp-planar-formats:
- shard-dg2: NOTRUN -> [SKIP][178] ([i915#11151] / [i915#7828]) +3 other tests skip
[178]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_chamelium_frames@hdmi-cmp-planar-formats.html
* igt@kms_chamelium_frames@hdmi-crc-single:
- shard-rkl: NOTRUN -> [SKIP][179] ([i915#11151] / [i915#7828]) +9 other tests skip
[179]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_chamelium_frames@hdmi-crc-single.html
* igt@kms_chamelium_hpd@dp-hpd-for-each-pipe:
- shard-mtlp: NOTRUN -> [SKIP][180] ([i915#11151] / [i915#7828]) +2 other tests skip
[180]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_chamelium_hpd@dp-hpd-for-each-pipe.html
* igt@kms_chamelium_hpd@hdmi-hpd-storm-disable:
- shard-tglu-1: NOTRUN -> [SKIP][181] ([i915#11151] / [i915#7828]) +3 other tests skip
[181]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_chamelium_hpd@hdmi-hpd-storm-disable.html
- shard-dg1: NOTRUN -> [SKIP][182] ([i915#11151] / [i915#7828]) +9 other tests skip
[182]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_chamelium_hpd@hdmi-hpd-storm-disable.html
* igt@kms_color@deep-color:
- shard-tglu: NOTRUN -> [SKIP][183] ([i915#3555] / [i915#9979])
[183]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_color@deep-color.html
* igt@kms_content_protection@atomic-dpms@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [TIMEOUT][184] ([i915#7173])
[184]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_content_protection@atomic-dpms@pipe-a-dp-4.html
* igt@kms_content_protection@dp-mst-lic-type-1:
- shard-dg1: NOTRUN -> [SKIP][185] ([i915#3299])
[185]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_content_protection@dp-mst-lic-type-1.html
* igt@kms_content_protection@lic-type-0:
- shard-rkl: NOTRUN -> [SKIP][186] ([i915#9424])
[186]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_content_protection@lic-type-0.html
* igt@kms_content_protection@mei-interface:
- shard-tglu: NOTRUN -> [SKIP][187] ([i915#6944] / [i915#9424])
[187]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_content_protection@mei-interface.html
* igt@kms_content_protection@srm:
- shard-tglu: NOTRUN -> [SKIP][188] ([i915#6944] / [i915#7116] / [i915#7118])
[188]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_content_protection@srm.html
* igt@kms_content_protection@uevent:
- shard-tglu-1: NOTRUN -> [SKIP][189] ([i915#6944] / [i915#7116] / [i915#7118] / [i915#9424])
[189]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_content_protection@uevent.html
* igt@kms_cursor_crc@cursor-onscreen-32x32:
- shard-dg1: NOTRUN -> [SKIP][190] ([i915#3555]) +10 other tests skip
[190]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_cursor_crc@cursor-onscreen-32x32.html
* igt@kms_cursor_crc@cursor-onscreen-max-size:
- shard-mtlp: NOTRUN -> [SKIP][191] ([i915#3555] / [i915#8814])
[191]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_cursor_crc@cursor-onscreen-max-size.html
* igt@kms_cursor_crc@cursor-rapid-movement-32x10:
- shard-rkl: NOTRUN -> [SKIP][192] ([i915#3555]) +5 other tests skip
[192]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_cursor_crc@cursor-rapid-movement-32x10.html
* igt@kms_cursor_crc@cursor-rapid-movement-512x170:
- shard-dg1: NOTRUN -> [SKIP][193] ([i915#13049])
[193]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_cursor_crc@cursor-rapid-movement-512x170.html
* igt@kms_cursor_crc@cursor-rapid-movement-512x512:
- shard-tglu: NOTRUN -> [SKIP][194] ([i915#13049]) +1 other test skip
[194]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_cursor_crc@cursor-rapid-movement-512x512.html
* igt@kms_cursor_crc@cursor-rapid-movement-max-size:
- shard-tglu-1: NOTRUN -> [SKIP][195] ([i915#3555]) +4 other tests skip
[195]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_cursor_crc@cursor-rapid-movement-max-size.html
* igt@kms_cursor_crc@cursor-sliding-512x170:
- shard-rkl: NOTRUN -> [SKIP][196] ([i915#13049])
[196]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_cursor_crc@cursor-sliding-512x170.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-varying-size:
- shard-dg1: NOTRUN -> [SKIP][197] ([i915#4103] / [i915#4213]) +2 other tests skip
[197]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-varying-size.html
* igt@kms_cursor_legacy@cursora-vs-flipb-atomic:
- shard-mtlp: NOTRUN -> [SKIP][198] ([i915#9809]) +2 other tests skip
[198]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_cursor_legacy@cursora-vs-flipb-atomic.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-atomic:
- shard-dg2: NOTRUN -> [SKIP][199] ([i915#13046] / [i915#5354]) +1 other test skip
[199]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_cursor_legacy@cursorb-vs-flipa-atomic.html
* igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions:
- shard-tglu: NOTRUN -> [SKIP][200] ([i915#4103])
[200]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions.html
- shard-mtlp: NOTRUN -> [SKIP][201] ([i915#4213]) +1 other test skip
[201]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions.html
* igt@kms_dirtyfb@drrs-dirtyfb-ioctl:
- shard-rkl: NOTRUN -> [SKIP][202] ([i915#9723])
[202]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_dirtyfb@drrs-dirtyfb-ioctl.html
* igt@kms_dp_linktrain_fallback@dp-fallback:
- shard-dg1: NOTRUN -> [SKIP][203] ([i915#12402])
[203]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_dp_linktrain_fallback@dp-fallback.html
* igt@kms_dsc@dsc-fractional-bpp:
- shard-tglu: NOTRUN -> [SKIP][204] ([i915#3840])
[204]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_dsc@dsc-fractional-bpp.html
* igt@kms_dsc@dsc-fractional-bpp-with-bpc:
- shard-rkl: NOTRUN -> [SKIP][205] ([i915#3840])
[205]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_dsc@dsc-fractional-bpp-with-bpc.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-mtlp: NOTRUN -> [SKIP][206] ([i915#3555] / [i915#3840])
[206]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_dsc@dsc-with-bpc-formats.html
- shard-dg1: NOTRUN -> [SKIP][207] ([i915#3555] / [i915#3840])
[207]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_dsc@dsc-with-bpc-formats.html
- shard-tglu: NOTRUN -> [SKIP][208] ([i915#3555] / [i915#3840])
[208]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_dsc@dsc-with-bpc-formats.html
* igt@kms_dsc@dsc-with-output-formats-with-bpc:
- shard-dg1: NOTRUN -> [SKIP][209] ([i915#3840] / [i915#9053])
[209]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_dsc@dsc-with-output-formats-with-bpc.html
* igt@kms_fbcon_fbt@psr:
- shard-dg2: NOTRUN -> [SKIP][210] ([i915#3469])
[210]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_fbcon_fbt@psr.html
- shard-rkl: NOTRUN -> [SKIP][211] ([i915#3955])
[211]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_fbcon_fbt@psr.html
* igt@kms_feature_discovery@dp-mst:
- shard-tglu-1: NOTRUN -> [SKIP][212] ([i915#9337])
[212]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_feature_discovery@dp-mst.html
- shard-dg1: NOTRUN -> [SKIP][213] ([i915#9337])
[213]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_feature_discovery@dp-mst.html
* igt@kms_feature_discovery@psr1:
- shard-tglu-1: NOTRUN -> [SKIP][214] ([i915#658])
[214]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_feature_discovery@psr1.html
* igt@kms_feature_discovery@psr2:
- shard-dg1: NOTRUN -> [SKIP][215] ([i915#658])
[215]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_feature_discovery@psr2.html
* igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible:
- shard-rkl: NOTRUN -> [SKIP][216] ([i915#9934]) +11 other tests skip
[216]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset-interruptible.html
* igt@kms_flip@2x-flip-vs-fences:
- shard-dg1: NOTRUN -> [SKIP][217] ([i915#8381]) +1 other test skip
[217]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_flip@2x-flip-vs-fences.html
* igt@kms_flip@2x-flip-vs-panning-interruptible:
- shard-dg2: NOTRUN -> [SKIP][218] ([i915#9934]) +1 other test skip
[218]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_flip@2x-flip-vs-panning-interruptible.html
* igt@kms_flip@2x-plain-flip:
- shard-tglu-1: NOTRUN -> [SKIP][219] ([i915#3637]) +2 other tests skip
[219]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_flip@2x-plain-flip.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
- shard-dg1: NOTRUN -> [SKIP][220] ([i915#9934]) +5 other tests skip
[220]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible.html
- shard-tglu: NOTRUN -> [SKIP][221] ([i915#3637]) +2 other tests skip
[221]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible.html
- shard-mtlp: NOTRUN -> [SKIP][222] ([i915#3637]) +1 other test skip
[222]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible.html
* igt@kms_flip@blocking-wf_vblank@a-hdmi-a2:
- shard-rkl: NOTRUN -> [FAIL][223] ([i915#11989]) +1 other test fail
[223]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_flip@blocking-wf_vblank@a-hdmi-a2.html
* igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscaling@pipe-a-valid-mode:
- shard-rkl: NOTRUN -> [SKIP][224] ([i915#2672]) +2 other tests skip
[224]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-upscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-upscaling@pipe-a-valid-mode:
- shard-dg1: NOTRUN -> [SKIP][225] ([i915#2587] / [i915#2672]) +6 other tests skip
[225]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-upscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling:
- shard-mtlp: NOTRUN -> [SKIP][226] ([i915#2672] / [i915#3555] / [i915#8813]) +1 other test skip
[226]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-default-mode:
- shard-mtlp: NOTRUN -> [SKIP][227] ([i915#2672] / [i915#8813]) +1 other test skip
[227]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-64bpp-yftile-downscaling@pipe-a-default-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-downscaling:
- shard-tglu: NOTRUN -> [SKIP][228] ([i915#2672] / [i915#3555]) +2 other tests skip
[228]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-downscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscaling:
- shard-rkl: NOTRUN -> [SKIP][229] ([i915#2672] / [i915#3555]) +2 other tests skip
[229]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-4/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-16bpp-4tile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling:
- shard-mtlp: NOTRUN -> [SKIP][230] ([i915#3555] / [i915#8813])
[230]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling@pipe-a-default-mode:
- shard-mtlp: NOTRUN -> [SKIP][231] ([i915#8810])
[231]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling@pipe-a-default-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling@pipe-a-valid-mode:
- shard-tglu: NOTRUN -> [SKIP][232] ([i915#2587] / [i915#2672]) +2 other tests skip
[232]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_flip_scaled_crc@flip-64bpp-4tile-to-32bpp-4tile-downscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling:
- shard-tglu-1: NOTRUN -> [SKIP][233] ([i915#2672] / [i915#3555]) +1 other test skip
[233]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling.html
- shard-dg1: NOTRUN -> [SKIP][234] ([i915#2672] / [i915#3555]) +6 other tests skip
[234]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode:
- shard-tglu-1: NOTRUN -> [SKIP][235] ([i915#2587] / [i915#2672]) +1 other test skip
[235]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling:
- shard-dg2: NOTRUN -> [SKIP][236] ([i915#2672] / [i915#3555] / [i915#5190]) +2 other tests skip
[236]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling@pipe-a-valid-mode:
- shard-dg2: NOTRUN -> [SKIP][237] ([i915#2672]) +2 other tests skip
[237]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytile-upscaling@pipe-a-valid-mode.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render:
- shard-dg2: [PASS][238] -> [FAIL][239] ([i915#6880]) +2 other tests fail
[238]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html
[239]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-render:
- shard-dg1: NOTRUN -> [SKIP][240] +42 other tests skip
[240]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-dg1: NOTRUN -> [SKIP][241] ([i915#8708]) +19 other tests skip
[241]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move:
- shard-dg2: NOTRUN -> [SKIP][242] ([i915#5354]) +9 other tests skip
[242]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move.html
* igt@kms_frontbuffer_tracking@fbc-tiling-4:
- shard-rkl: NOTRUN -> [SKIP][243] ([i915#5439])
[243]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-tiling-4.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
- shard-dg1: NOTRUN -> [SKIP][244] ([i915#3458] / [i915#4423])
[244]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-indfb-fliptrack-mmap-gtt:
- shard-rkl: NOTRUN -> [SKIP][245] +22 other tests skip
[245]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_frontbuffer_tracking@fbcpsr-2p-indfb-fliptrack-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-mmap-wc:
- shard-dg2: NOTRUN -> [SKIP][246] ([i915#8708]) +12 other tests skip
[246]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-cpu:
- shard-mtlp: NOTRUN -> [SKIP][247] ([i915#1825]) +10 other tests skip
[247]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-render:
- shard-tglu: NOTRUN -> [SKIP][248] +59 other tests skip
[248]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-blt:
- shard-rkl: NOTRUN -> [SKIP][249] ([i915#1825]) +37 other tests skip
[249]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-tiling-4:
- shard-dg1: NOTRUN -> [SKIP][250] ([i915#5439])
[250]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_frontbuffer_tracking@fbcpsr-tiling-4.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-tglu-1: NOTRUN -> [SKIP][251] +41 other tests skip
[251]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-render:
- shard-dg1: NOTRUN -> [SKIP][252] ([i915#3458]) +22 other tests skip
[252]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-msflip-blt:
- shard-rkl: NOTRUN -> [SKIP][253] ([i915#3023]) +25 other tests skip
[253]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-msflip-blt.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-dg2: NOTRUN -> [SKIP][254] ([i915#3458]) +8 other tests skip
[254]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-mtlp: NOTRUN -> [SKIP][255] ([i915#8708]) +2 other tests skip
[255]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_hdr@bpc-switch:
- shard-dg1: NOTRUN -> [SKIP][256] ([i915#3555] / [i915#8228]) +1 other test skip
[256]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_hdr@bpc-switch.html
- shard-tglu: NOTRUN -> [SKIP][257] ([i915#3555] / [i915#8228])
[257]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_hdr@bpc-switch.html
* igt@kms_hdr@brightness-with-hdr:
- shard-rkl: NOTRUN -> [SKIP][258] ([i915#12713])
[258]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_hdr@brightness-with-hdr.html
* igt@kms_hdr@static-swap:
- shard-mtlp: NOTRUN -> [SKIP][259] ([i915#3555] / [i915#8228])
[259]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_hdr@static-swap.html
- shard-dg2: [PASS][260] -> [SKIP][261] ([i915#3555] / [i915#8228]) +1 other test skip
[260]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-10/igt@kms_hdr@static-swap.html
[261]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-6/igt@kms_hdr@static-swap.html
* igt@kms_hdr@static-toggle:
- shard-tglu-1: NOTRUN -> [SKIP][262] ([i915#3555] / [i915#8228])
[262]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_hdr@static-toggle.html
* igt@kms_hdr@static-toggle-dpms:
- shard-rkl: NOTRUN -> [SKIP][263] ([i915#3555] / [i915#8228])
[263]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_hdr@static-toggle-dpms.html
* igt@kms_invalid_mode@clock-too-high:
- shard-mtlp: NOTRUN -> [SKIP][264] ([i915#3555] / [i915#6403] / [i915#8826])
[264]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_invalid_mode@clock-too-high.html
* igt@kms_invalid_mode@clock-too-high@pipe-a-edp-1:
- shard-mtlp: NOTRUN -> [SKIP][265] ([i915#9457]) +3 other tests skip
[265]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_invalid_mode@clock-too-high@pipe-a-edp-1.html
* igt@kms_joiner@basic-big-joiner:
- shard-tglu-1: NOTRUN -> [SKIP][266] ([i915#10656])
[266]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_joiner@basic-big-joiner.html
* igt@kms_joiner@basic-force-big-joiner:
- shard-rkl: NOTRUN -> [SKIP][267] ([i915#12388])
[267]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_joiner@basic-force-big-joiner.html
* igt@kms_joiner@basic-force-ultra-joiner:
- shard-dg1: NOTRUN -> [SKIP][268] ([i915#12394] / [i915#13522])
[268]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_joiner@basic-force-ultra-joiner.html
* igt@kms_joiner@invalid-modeset-big-joiner:
- shard-dg1: NOTRUN -> [SKIP][269] ([i915#10656])
[269]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_joiner@invalid-modeset-big-joiner.html
* igt@kms_joiner@invalid-modeset-force-ultra-joiner:
- shard-tglu: NOTRUN -> [SKIP][270] ([i915#12394] / [i915#13522])
[270]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_joiner@invalid-modeset-force-ultra-joiner.html
* igt@kms_joiner@invalid-modeset-ultra-joiner:
- shard-tglu: NOTRUN -> [SKIP][271] ([i915#12339])
[271]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_joiner@invalid-modeset-ultra-joiner.html
* igt@kms_multipipe_modeset@basic-max-pipe-crc-check:
- shard-rkl: NOTRUN -> [SKIP][272] ([i915#4816])
[272]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html
* igt@kms_panel_fitting@atomic-fastset:
- shard-dg2: NOTRUN -> [SKIP][273] ([i915#6301])
[273]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_panel_fitting@atomic-fastset.html
- shard-rkl: NOTRUN -> [SKIP][274] ([i915#6301])
[274]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_panel_fitting@atomic-fastset.html
* igt@kms_panel_fitting@legacy:
- shard-dg1: NOTRUN -> [SKIP][275] ([i915#6301])
[275]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_panel_fitting@legacy.html
* igt@kms_plane_lowres@tiling-4:
- shard-tglu: NOTRUN -> [SKIP][276] ([i915#3555]) +5 other tests skip
[276]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_plane_lowres@tiling-4.html
- shard-mtlp: NOTRUN -> [SKIP][277] ([i915#10226] / [i915#11614] / [i915#3555] / [i915#8821])
[277]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_plane_lowres@tiling-4.html
* igt@kms_plane_lowres@tiling-4@pipe-b-edp-1:
- shard-mtlp: NOTRUN -> [SKIP][278] ([i915#11614] / [i915#3582]) +3 other tests skip
[278]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_plane_lowres@tiling-4@pipe-b-edp-1.html
* igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers@pipe-a:
- shard-rkl: NOTRUN -> [SKIP][279] ([i915#12247]) +11 other tests skip
[279]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-modifiers@pipe-a.html
* igt@kms_plane_scaling@plane-downscale-factor-0-25-with-rotation@pipe-a:
- shard-mtlp: NOTRUN -> [SKIP][280] ([i915#12247]) +12 other tests skip
[280]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-rotation@pipe-a.html
* igt@kms_plane_scaling@plane-downscale-factor-0-25-with-rotation@pipe-c:
- shard-tglu: NOTRUN -> [SKIP][281] ([i915#12247]) +9 other tests skip
[281]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_plane_scaling@plane-downscale-factor-0-25-with-rotation@pipe-c.html
* igt@kms_plane_scaling@plane-upscale-20x20-with-rotation@pipe-a:
- shard-dg1: NOTRUN -> [SKIP][282] ([i915#12247]) +19 other tests skip
[282]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_plane_scaling@plane-upscale-20x20-with-rotation@pipe-a.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25:
- shard-rkl: NOTRUN -> [SKIP][283] ([i915#12247] / [i915#6953]) +1 other test skip
[283]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_plane_scaling@planes-downscale-factor-0-25.html
* igt@kms_plane_scaling@planes-downscale-factor-0-75:
- shard-mtlp: NOTRUN -> [SKIP][284] ([i915#12247] / [i915#3555] / [i915#6953])
[284]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_plane_scaling@planes-downscale-factor-0-75.html
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5:
- shard-mtlp: NOTRUN -> [SKIP][285] ([i915#6953])
[285]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-5.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25:
- shard-rkl: NOTRUN -> [SKIP][286] ([i915#12247] / [i915#3555])
[286]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25:
- shard-dg2: NOTRUN -> [SKIP][287] ([i915#12247] / [i915#6953] / [i915#9423])
[287]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-d:
- shard-dg2: NOTRUN -> [SKIP][288] ([i915#12247]) +3 other tests skip
[288]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-d.html
* igt@kms_pm_backlight@bad-brightness:
- shard-rkl: NOTRUN -> [SKIP][289] ([i915#5354]) +1 other test skip
[289]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_pm_backlight@bad-brightness.html
* igt@kms_pm_backlight@basic-brightness:
- shard-dg1: NOTRUN -> [SKIP][290] ([i915#5354])
[290]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_pm_backlight@basic-brightness.html
- shard-tglu: NOTRUN -> [SKIP][291] ([i915#9812])
[291]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_pm_backlight@basic-brightness.html
* igt@kms_pm_backlight@brightness-with-dpms:
- shard-dg1: NOTRUN -> [SKIP][292] ([i915#12343])
[292]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_pm_backlight@brightness-with-dpms.html
* igt@kms_pm_dc@dc5-psr:
- shard-dg1: NOTRUN -> [SKIP][293] ([i915#9685])
[293]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_pm_dc@dc5-psr.html
* igt@kms_pm_dc@dc5-retention-flops:
- shard-tglu-1: NOTRUN -> [SKIP][294] ([i915#3828])
[294]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_pm_dc@dc5-retention-flops.html
* igt@kms_pm_dc@dc6-dpms:
- shard-rkl: NOTRUN -> [SKIP][295] ([i915#3361])
[295]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_pm_dc@dc6-dpms.html
- shard-tglu: [PASS][296] -> [FAIL][297] ([i915#9295])
[296]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-10/igt@kms_pm_dc@dc6-dpms.html
[297]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-7/igt@kms_pm_dc@dc6-dpms.html
* igt@kms_pm_dc@dc6-psr:
- shard-rkl: NOTRUN -> [SKIP][298] ([i915#9685])
[298]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_pm_dc@dc6-psr.html
* igt@kms_pm_dc@dc9-dpms:
- shard-tglu: NOTRUN -> [SKIP][299] ([i915#4281])
[299]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_pm_dc@dc9-dpms.html
* igt@kms_pm_lpsp@screens-disabled:
- shard-dg1: NOTRUN -> [SKIP][300] ([i915#8430])
[300]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_pm_lpsp@screens-disabled.html
* igt@kms_pm_rpm@dpms-lpsp:
- shard-dg1: NOTRUN -> [SKIP][301] ([i915#9519]) +1 other test skip
[301]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_pm_rpm@dpms-lpsp.html
* igt@kms_pm_rpm@dpms-mode-unset-lpsp:
- shard-rkl: NOTRUN -> [SKIP][302] ([i915#9519])
[302]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_pm_rpm@dpms-mode-unset-lpsp.html
* igt@kms_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-dg2: NOTRUN -> [SKIP][303] ([i915#9519])
[303]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_pm_rpm@modeset-lpsp-stress-no-wait.html
* igt@kms_pm_rpm@modeset-non-lpsp:
- shard-mtlp: NOTRUN -> [SKIP][304] ([i915#9519]) +1 other test skip
[304]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-6/igt@kms_pm_rpm@modeset-non-lpsp.html
* igt@kms_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-tglu: NOTRUN -> [SKIP][305] ([i915#9519])
[305]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_pm_rpm@modeset-non-lpsp-stress-no-wait.html
* igt@kms_pm_rpm@system-suspend-modeset:
- shard-dg1: NOTRUN -> [ABORT][306] ([i915#10553])
[306]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@kms_pm_rpm@system-suspend-modeset.html
* igt@kms_prime@basic-crc-hybrid:
- shard-tglu: NOTRUN -> [SKIP][307] ([i915#6524])
[307]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_prime@basic-crc-hybrid.html
* igt@kms_prime@d3hot:
- shard-rkl: NOTRUN -> [SKIP][308] ([i915#6524])
[308]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-2/igt@kms_prime@d3hot.html
* igt@kms_psr2_sf@fbc-psr2-cursor-plane-update-sf:
- shard-dg2: NOTRUN -> [SKIP][309] ([i915#11520]) +4 other tests skip
[309]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_psr2_sf@fbc-psr2-cursor-plane-update-sf.html
* igt@kms_psr2_sf@fbc-psr2-overlay-plane-move-continuous-exceed-fully-sf:
- shard-glk: NOTRUN -> [SKIP][310] ([i915#11520])
[310]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk9/igt@kms_psr2_sf@fbc-psr2-overlay-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@fbc-psr2-plane-move-sf-dmg-area:
- shard-tglu-1: NOTRUN -> [SKIP][311] ([i915#11520]) +3 other tests skip
[311]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_psr2_sf@fbc-psr2-plane-move-sf-dmg-area.html
* igt@kms_psr2_sf@pr-overlay-plane-move-continuous-exceed-fully-sf:
- shard-tglu: NOTRUN -> [SKIP][312] ([i915#11520]) +5 other tests skip
[312]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@kms_psr2_sf@pr-overlay-plane-move-continuous-exceed-fully-sf.html
- shard-mtlp: NOTRUN -> [SKIP][313] ([i915#12316]) +1 other test skip
[313]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_psr2_sf@pr-overlay-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@pr-overlay-plane-update-sf-dmg-area:
- shard-rkl: NOTRUN -> [SKIP][314] ([i915#11520]) +11 other tests skip
[314]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_psr2_sf@pr-overlay-plane-update-sf-dmg-area.html
- shard-snb: NOTRUN -> [SKIP][315] ([i915#11520]) +8 other tests skip
[315]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-snb7/igt@kms_psr2_sf@pr-overlay-plane-update-sf-dmg-area.html
* igt@kms_psr2_sf@psr2-primary-plane-update-sf-dmg-area-big-fb:
- shard-dg1: NOTRUN -> [SKIP][316] ([i915#11520]) +11 other tests skip
[316]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_psr2_sf@psr2-primary-plane-update-sf-dmg-area-big-fb.html
* igt@kms_psr2_su@page_flip-nv12:
- shard-dg1: NOTRUN -> [SKIP][317] ([i915#9683])
[317]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_psr2_su@page_flip-nv12.html
* igt@kms_psr@fbc-psr-cursor-plane-move:
- shard-dg2: NOTRUN -> [SKIP][318] ([i915#1072] / [i915#9732]) +9 other tests skip
[318]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_psr@fbc-psr-cursor-plane-move.html
* igt@kms_psr@fbc-psr-dpms:
- shard-mtlp: NOTRUN -> [SKIP][319] ([i915#9688]) +9 other tests skip
[319]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_psr@fbc-psr-dpms.html
* igt@kms_psr@fbc-psr-sprite-plane-move:
- shard-tglu: NOTRUN -> [SKIP][320] ([i915#9732]) +16 other tests skip
[320]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_psr@fbc-psr-sprite-plane-move.html
* igt@kms_psr@pr-sprite-mmap-gtt:
- shard-rkl: NOTRUN -> [SKIP][321] ([i915#1072] / [i915#9732]) +21 other tests skip
[321]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_psr@pr-sprite-mmap-gtt.html
* igt@kms_psr@psr-sprite-mmap-cpu:
- shard-dg1: NOTRUN -> [SKIP][322] ([i915#1072] / [i915#9732]) +27 other tests skip
[322]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_psr@psr-sprite-mmap-cpu.html
* igt@kms_psr@psr2-primary-mmap-gtt:
- shard-tglu-1: NOTRUN -> [SKIP][323] ([i915#9732]) +10 other tests skip
[323]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_psr@psr2-primary-mmap-gtt.html
* igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270:
- shard-dg1: NOTRUN -> [SKIP][324] ([i915#5289]) +2 other tests skip
[324]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270.html
* igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90:
- shard-rkl: NOTRUN -> [SKIP][325] ([i915#5289])
[325]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90.html
* igt@kms_selftest@drm_framebuffer:
- shard-rkl: NOTRUN -> [ABORT][326] ([i915#13179]) +1 other test abort
[326]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-3/igt@kms_selftest@drm_framebuffer.html
- shard-tglu-1: NOTRUN -> [ABORT][327] ([i915#13179]) +1 other test abort
[327]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_selftest@drm_framebuffer.html
* igt@kms_setmode@basic@pipe-b-edp-1:
- shard-mtlp: NOTRUN -> [FAIL][328] ([i915#5465]) +2 other tests fail
[328]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_setmode@basic@pipe-b-edp-1.html
* igt@kms_sysfs_edid_timing:
- shard-dg2: [PASS][329] -> [FAIL][330] ([IGT#160])
[329]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-10/igt@kms_sysfs_edid_timing.html
[330]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-6/igt@kms_sysfs_edid_timing.html
- shard-dg1: NOTRUN -> [FAIL][331] ([IGT#160] / [i915#6493])
[331]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_sysfs_edid_timing.html
* igt@kms_tiled_display@basic-test-pattern:
- shard-rkl: NOTRUN -> [SKIP][332] ([i915#8623])
[332]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_tiled_display@basic-test-pattern.html
* igt@kms_tiled_display@basic-test-pattern-with-chamelium:
- shard-tglu: NOTRUN -> [SKIP][333] ([i915#8623])
[333]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html
* igt@kms_vblank@ts-continuation-dpms-suspend@pipe-a-hdmi-a-2:
- shard-glk: NOTRUN -> [INCOMPLETE][334] ([i915#12276]) +1 other test incomplete
[334]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk9/igt@kms_vblank@ts-continuation-dpms-suspend@pipe-a-hdmi-a-2.html
* igt@kms_vrr@flip-basic:
- shard-mtlp: NOTRUN -> [SKIP][335] ([i915#3555] / [i915#8808])
[335]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_vrr@flip-basic.html
* igt@kms_vrr@flip-basic-fastset:
- shard-tglu: NOTRUN -> [SKIP][336] ([i915#9906])
[336]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-9/igt@kms_vrr@flip-basic-fastset.html
* igt@kms_vrr@flip-suspend:
- shard-dg2: NOTRUN -> [SKIP][337] ([i915#3555]) +2 other tests skip
[337]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@kms_vrr@flip-suspend.html
* igt@kms_vrr@lobf:
- shard-tglu-1: NOTRUN -> [SKIP][338] ([i915#11920])
[338]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-1/igt@kms_vrr@lobf.html
* igt@kms_vrr@negative-basic:
- shard-dg2: [PASS][339] -> [SKIP][340] ([i915#3555] / [i915#9906])
[339]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-10/igt@kms_vrr@negative-basic.html
[340]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-8/igt@kms_vrr@negative-basic.html
- shard-rkl: NOTRUN -> [SKIP][341] ([i915#3555] / [i915#9906])
[341]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@kms_vrr@negative-basic.html
* igt@kms_vrr@seamless-rr-switch-drrs:
- shard-rkl: NOTRUN -> [SKIP][342] ([i915#9906])
[342]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-5/igt@kms_vrr@seamless-rr-switch-drrs.html
- shard-dg2: NOTRUN -> [SKIP][343] ([i915#9906])
[343]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_vrr@seamless-rr-switch-drrs.html
* igt@kms_writeback@writeback-check-output:
- shard-mtlp: NOTRUN -> [SKIP][344] ([i915#2437])
[344]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_writeback@writeback-check-output.html
* igt@kms_writeback@writeback-fb-id-xrgb2101010:
- shard-dg1: NOTRUN -> [SKIP][345] ([i915#2437] / [i915#9412])
[345]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_writeback@writeback-fb-id-xrgb2101010.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-rkl: NOTRUN -> [SKIP][346] ([i915#2437] / [i915#9412])
[346]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@kms_writeback@writeback-pixel-formats.html
* igt@prime_vgem@basic-fence-flip:
- shard-dg2: NOTRUN -> [SKIP][347] ([i915#3708])
[347]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-5/igt@prime_vgem@basic-fence-flip.html
* igt@prime_vgem@coherency-gtt:
- shard-dg1: NOTRUN -> [SKIP][348] ([i915#3708] / [i915#4077]) +1 other test skip
[348]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@prime_vgem@coherency-gtt.html
* igt@prime_vgem@fence-read-hang:
- shard-dg1: NOTRUN -> [SKIP][349] ([i915#3708])
[349]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@prime_vgem@fence-read-hang.html
* igt@sriov_basic@bind-unbind-vf:
- shard-rkl: NOTRUN -> [SKIP][350] ([i915#9917]) +2 other tests skip
[350]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-1/igt@sriov_basic@bind-unbind-vf.html
* igt@sriov_basic@enable-vfs-autoprobe-on:
- shard-dg1: NOTRUN -> [SKIP][351] ([i915#9917])
[351]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@sriov_basic@enable-vfs-autoprobe-on.html
* igt@sriov_basic@enable-vfs-autoprobe-on@numvfs-1:
- shard-tglu: NOTRUN -> [FAIL][352] ([i915#12910]) +9 other tests fail
[352]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-5/igt@sriov_basic@enable-vfs-autoprobe-on@numvfs-1.html
* igt@sriov_basic@enable-vfs-autoprobe-on@numvfs-2:
- shard-mtlp: NOTRUN -> [FAIL][353] ([i915#12910]) +9 other tests fail
[353]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@sriov_basic@enable-vfs-autoprobe-on@numvfs-2.html
* igt@sriov_basic@enable-vfs-bind-unbind-each:
- shard-dg2: NOTRUN -> [SKIP][354] ([i915#9917])
[354]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@sriov_basic@enable-vfs-bind-unbind-each.html
#### Possible fixes ####
* igt@api_intel_allocator@alloc-simple:
- shard-rkl: [DMESG-WARN][355] ([i915#12964]) -> [PASS][356] +4 other tests pass
[355]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-4/igt@api_intel_allocator@alloc-simple.html
[356]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-7/igt@api_intel_allocator@alloc-simple.html
* igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0:
- shard-dg2: [INCOMPLETE][357] ([i915#12392] / [i915#7297]) -> [PASS][358]
[357]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-4/igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0.html
[358]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-7/igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0.html
* igt@gem_eio@reset-stress:
- shard-dg1: [FAIL][359] ([i915#12543] / [i915#5784]) -> [PASS][360]
[359]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-14/igt@gem_eio@reset-stress.html
[360]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-17/igt@gem_eio@reset-stress.html
* igt@gem_workarounds@suspend-resume-context:
- shard-dg1: [ABORT][361] -> [PASS][362]
[361]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-17/igt@gem_workarounds@suspend-resume-context.html
[362]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@gem_workarounds@suspend-resume-context.html
* igt@i915_hangman@gt-error-state-capture@vecs0:
- shard-mtlp: [DMESG-WARN][363] -> [PASS][364]
[363]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-7/igt@i915_hangman@gt-error-state-capture@vecs0.html
[364]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@i915_hangman@gt-error-state-capture@vecs0.html
* igt@i915_power@sanity:
- shard-mtlp: [SKIP][365] ([i915#7984]) -> [PASS][366]
[365]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-1/igt@i915_power@sanity.html
[366]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@i915_power@sanity.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-dg1: [FAIL][367] ([i915#12518] / [i915#12766]) -> [PASS][368]
[367]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-12/igt@kms_async_flips@alternate-sync-async-flip.html
[368]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3:
- shard-dg1: [FAIL][369] ([i915#12518]) -> [PASS][370]
[369]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-12/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3.html
[370]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-12/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-3.html
* igt@kms_cursor_crc@cursor-onscreen-128x42:
- shard-rkl: [FAIL][371] ([i915#13566]) -> [PASS][372] +3 other tests pass
[371]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-7/igt@kms_cursor_crc@cursor-onscreen-128x42.html
[372]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-3/igt@kms_cursor_crc@cursor-onscreen-128x42.html
* igt@kms_cursor_crc@cursor-onscreen-128x42@pipe-a-hdmi-a-1:
- shard-tglu: [FAIL][373] ([i915#13566]) -> [PASS][374] +1 other test pass
[373]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-10/igt@kms_cursor_crc@cursor-onscreen-128x42@pipe-a-hdmi-a-1.html
[374]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-7/igt@kms_cursor_crc@cursor-onscreen-128x42@pipe-a-hdmi-a-1.html
* igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions:
- shard-glk: [FAIL][375] ([i915#2346]) -> [PASS][376]
[375]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-glk8/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
[376]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-glk1/igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc:
- shard-dg2: [SKIP][377] ([i915#3555]) -> [PASS][378]
[377]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-3/igt@kms_dither@fb-8bpc-vs-panel-6bpc.html
[378]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_dither@fb-8bpc-vs-panel-6bpc.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite:
- shard-dg2: [FAIL][379] ([i915#6880]) -> [PASS][380]
[379]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-10/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite.html
[380]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite.html
* igt@kms_pipe_crc_basic@hang-read-crc@pipe-a-edp-1:
- shard-mtlp: [ABORT][381] -> [PASS][382] +4 other tests pass
[381]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-7/igt@kms_pipe_crc_basic@hang-read-crc@pipe-a-edp-1.html
[382]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-5/igt@kms_pipe_crc_basic@hang-read-crc@pipe-a-edp-1.html
* igt@kms_pm_rpm@dpms-lpsp:
- shard-dg2: [SKIP][383] ([i915#9519]) -> [PASS][384] +1 other test pass
[383]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-1/igt@kms_pm_rpm@dpms-lpsp.html
[384]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-8/igt@kms_pm_rpm@dpms-lpsp.html
* igt@kms_pm_rpm@modeset-non-lpsp:
- shard-rkl: [SKIP][385] ([i915#9519]) -> [PASS][386] +1 other test pass
[385]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-rkl-7/igt@kms_pm_rpm@modeset-non-lpsp.html
[386]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-rkl-3/igt@kms_pm_rpm@modeset-non-lpsp.html
* igt@perf_pmu@busy-double-start@vecs1:
- shard-dg2: [FAIL][387] ([i915#4349]) -> [PASS][388] +4 other tests pass
[387]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-10/igt@perf_pmu@busy-double-start@vecs1.html
[388]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-6/igt@perf_pmu@busy-double-start@vecs1.html
* igt@syncobj_wait@invalid-reset-illegal-handle:
- shard-dg1: [DMESG-WARN][389] ([i915#4423]) -> [PASS][390]
[389]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-18/igt@syncobj_wait@invalid-reset-illegal-handle.html
[390]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@syncobj_wait@invalid-reset-illegal-handle.html
#### Warnings ####
* igt@i915_module_load@reload-with-fault-injection:
- shard-mtlp: [DMESG-WARN][391] ([i915#10887] / [i915#13475]) -> [DMESG-WARN][392] ([i915#13475])
[391]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-6/igt@i915_module_load@reload-with-fault-injection.html
[392]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-3/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_suspend@basic-s3-without-i915:
- shard-tglu: [INCOMPLETE][393] ([i915#4817] / [i915#7443]) -> [INCOMPLETE][394] ([i915#7443])
[393]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-tglu-8/igt@i915_suspend@basic-s3-without-i915.html
[394]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-tglu-10/igt@i915_suspend@basic-s3-without-i915.html
* igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- shard-dg1: [SKIP][395] ([i915#4212] / [i915#4423]) -> [SKIP][396] ([i915#4212])
[395]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-18/igt@kms_addfb_basic@addfb25-x-tiled-legacy.html
[396]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-14/igt@kms_addfb_basic@addfb25-x-tiled-legacy.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180:
- shard-mtlp: [FAIL][397] ([i915#5138]) -> [DMESG-FAIL][398] ([i915#11627] / [i915#13314])
[397]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-mtlp-4/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180.html
[398]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-mtlp-1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180.html
* igt@kms_content_protection@atomic-dpms:
- shard-dg2: [SKIP][399] ([i915#7118] / [i915#9424]) -> [TIMEOUT][400] ([i915#7173])
[399]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-3/igt@kms_content_protection@atomic-dpms.html
[400]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-10/igt@kms_content_protection@atomic-dpms.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu:
- shard-dg2: [SKIP][401] ([i915#3458]) -> [SKIP][402] ([i915#10433] / [i915#3458]) +2 other tests skip
[401]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-6/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu.html
[402]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-4/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@fbcpsr-tiling-4:
- shard-dg2: [SKIP][403] ([i915#10433] / [i915#3458]) -> [SKIP][404] ([i915#3458])
[403]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg2-4/igt@kms_frontbuffer_tracking@fbcpsr-tiling-4.html
[404]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg2-7/igt@kms_frontbuffer_tracking@fbcpsr-tiling-4.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move:
- shard-dg1: [SKIP][405] ([i915#3458]) -> [SKIP][406] ([i915#3458] / [i915#4423])
[405]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_16035/shard-dg1-13/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move.html
[406]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/shard-dg1-13/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#160]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/160
[i915#10226]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10226
[i915#10307]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10307
[i915#10433]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10433
[i915#10434]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10434
[i915#10553]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10553
[i915#10656]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10656
[i915#1072]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/1072
[i915#10887]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887
[i915#1099]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/1099
[i915#11078]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11078
[i915#11151]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11151
[i915#11441]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11441
[i915#11520]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11520
[i915#11527]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11527
[i915#11614]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11614
[i915#11616]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11616
[i915#11627]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11627
[i915#11681]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11681
[i915#11814]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11814
[i915#11815]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11815
[i915#11920]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11920
[i915#11965]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11965
[i915#11989]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11989
[i915#12247]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12247
[i915#12276]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12276
[i915#12313]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12313
[i915#12316]: https://gitlab.freedesktop.org/drm
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_135793v13/index.html
[-- Attachment #2: Type: text/html, Size: 111779 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread