This version is just a rebase of v5 onto the latest drm-tip, which was posted here: https://lists.freedesktop.org/archives/intel-gfx/2019-January/188352.html
There were some minor conflicts with Ville's csc/gamma disable series, so the background color write has now moved to the new color_commit function, but that's about the only notable rebase change.
Reviewed userspace (chromeos) is here: https://chromium-review.googlesource.com/c/chromium/src/+/1278858 https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1...
I've made some minor changes to the i-g-t test, so I'll resend those again shortly.
All the kernel patches are reviewed now, so I think this series is ready to merge. Since the i915 patches rely on other stuff that's landed pretty recently in dinq, it's probably easiest to merge this via the i915 tree; just need an Ack from Dave/Daniel.
Matt Roper (3): drm: Add CRTC background color property (v5) drm/i915/gen9+: Add support for pipe background color (v6) drm/i915: Add background color hardware readout and state check
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++ drivers/gpu/drm/drm_blend.c | 41 +++++++++++++++++++++++++++++++--- drivers/gpu/drm/drm_mode_config.c | 6 +++++ drivers/gpu/drm/i915/i915_debugfs.c | 9 ++++++++ drivers/gpu/drm/i915/intel_color.c | 11 ++++++--- drivers/gpu/drm/i915/intel_display.c | 43 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 ++++++++++ include/drm/drm_mode_config.h | 5 +++++ include/uapi/drm/drm_mode.h | 28 +++++++++++++++++++++++ 10 files changed, 154 insertions(+), 6 deletions(-)
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2: - Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville) - Document bgcolor property in drm_blend.c. (Sean Paul) - s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul) - Add a convenience function to attach property to a given crtc.
v3: - Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul) - s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4: - Drop the bgcolor_changed flag. (Ville, Brian Starkey) - Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey) - Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5: - Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville) - Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com --- drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++ drivers/gpu/drm/drm_blend.c | 41 ++++++++++++++++++++++++++++++++++++--- drivers/gpu/drm/drm_mode_config.c | 6 ++++++ include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 ++++++++++++ include/drm/drm_mode_config.h | 5 +++++ include/uapi/drm/drm_mode.h | 28 ++++++++++++++++++++++++++ 7 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index 0aabd401d3ca..5436201a6a0d 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -469,6 +469,8 @@ 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 == config->bgcolor_property) { + state->bgcolor = val; } else if (crtc->funcs->atomic_set_property) { return crtc->funcs->atomic_set_property(crtc, state, property, val); } else { @@ -503,6 +505,8 @@ 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 == config->bgcolor_property) + *val = state->bgcolor; else if (crtc->funcs->atomic_get_property) return crtc->funcs->atomic_get_property(crtc, state, property, val); else diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 0c78ca386cbe..2ff69fae385c 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -175,9 +175,22 @@ * plane does not expose the "alpha" property, then this is * assumed to be 1.0 * - * Note that all the property extensions described here apply either to the - * plane or the CRTC (e.g. for the background color, which currently is not - * exposed and assumed to be black). + * The property extensions described above all apply to the plane. Drivers + * may also expose the following crtc property extension: + * + * BACKGROUND_COLOR: + * Background color is setup with drm_crtc_add_bgcolor_property(). It + * controls the ARGB color of a full-screen layer that exists below all + * planes. This color will be used for pixels not covered by any plane + * and may also be blended with plane contents as allowed by a plane's + * alpha values. The background color defaults to black, and is assumed + * to be black for drivers that do not expose this property. Although + * background color isn't a plane, it is assumed that the color provided + * here undergoes the same pipe-level degamma/CSC/gamma transformations + * that planes undergo. Note that the color value provided here includes + * an alpha channel...non-opaque background color values are allowed, + * but are generally only honored in special cases (e.g., when a memory + * writeback connector is in use). */
/** @@ -593,3 +606,25 @@ int drm_plane_create_blend_mode_property(struct drm_plane *plane, return 0; } EXPORT_SYMBOL(drm_plane_create_blend_mode_property); + +/** + * drm_crtc_add_bgcolor_property - add background color property + * @crtc: drm crtc + * + * Adds the background color property to @crtc. The property defaults to + * solid black and will accept 64-bit ARGB values in the format generated by + * drm_argb(). @crtc's state will also be updated to hold a solid black + * background color when this function is called. + */ +void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc) +{ + u64 initval = drm_argb(16, 0xffff, 0, 0, 0); + + drm_object_attach_property(&crtc->base, + crtc->dev->mode_config.bgcolor_property, + initval); + + if (crtc->state) + crtc->state->bgcolor = initval; +} +EXPORT_SYMBOL(drm_crtc_add_bgcolor_property); diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 4a1c2023ccf0..8a7c346b3191 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -364,6 +364,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.modifiers_property = prop;
+ prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR", + 0, GENMASK_ULL(63, 0)); + if (!prop) + return -ENOMEM; + dev->mode_config.bgcolor_property = prop; + return 0; }
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h index 88bdfec3bd88..9e2538dd7b9a 100644 --- a/include/drm/drm_blend.h +++ b/include/drm/drm_blend.h @@ -58,4 +58,5 @@ int drm_atomic_normalize_zpos(struct drm_device *dev, struct drm_atomic_state *state); int drm_plane_create_blend_mode_property(struct drm_plane *plane, unsigned int supported_modes); +void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc); #endif diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 85abd3fe9e83..dbe0b45d5da6 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -274,6 +274,18 @@ struct drm_crtc_state { */ struct drm_property_blob *gamma_lut;
+ /** + * @bgcolor: + * + * RGB value representing the pipe's background color. The background + * color (aka "canvas color") of a pipe is the color that will be used + * for pixels not covered by a plane, or covered by transparent pixels + * of a plane. The value here should be built via drm_argb(); + * individual color components can be extracted with desired precision + * via the DRM_ARGB_*() macros. + */ + u64 bgcolor; + /** * @target_vblank: * diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h index 7f60e8eb269a..9a13d8ad92cc 100644 --- a/include/drm/drm_mode_config.h +++ b/include/drm/drm_mode_config.h @@ -836,6 +836,11 @@ struct drm_mode_config { */ struct drm_property *writeback_out_fence_ptr_property;
+ /** + * @bgcolor_property: RGB background color for CRTC. + */ + struct drm_property *bgcolor_property; + /* dumb ioctl parameters */ uint32_t preferred_depth, prefer_shadow;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index a439c2e67896..5f31e6a05bd9 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -907,6 +907,34 @@ struct drm_mode_rect { __s32 y2; };
+/* + * Put ARGB values into a standard 64-bit representation that can be used + * for ioctl parameters, inter-driver commmunication, etc. If the component + * values being provided contain less than 16 bits of precision, they'll + * be shifted into the most significant bits. + */ +static inline __u64 +drm_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue) +{ + int msb_shift = 16 - bpc; + + return (__u64)alpha << msb_shift << 48 | + (__u64)red << msb_shift << 32 | + (__u64)green << msb_shift << 16 | + (__u64)blue << msb_shift; +} + +/* + * Extract the specified number of bits of a specific color component from a + * standard 64-bit ARGB value. + */ +#define DRM_ARGB_COMP(c, shift, numbits) \ + (__u16)(((c) & 0xFFFFull << (shift)) >> ((shift) + 16 - (numbits))) +#define DRM_ARGB_BLUE(c, numbits) DRM_ARGB_COMP(c, 0, numbits) +#define DRM_ARGB_GREEN(c, numbits) DRM_ARGB_COMP(c, 16, numbits) +#define DRM_ARGB_RED(c, numbits) DRM_ARGB_COMP(c, 32, numbits) +#define DRM_ARGB_ALPHA(c, numbits) DRM_ARGB_COMP(c, 48, numbits) + #if defined(__cplusplus) } #endif
Hey,
Op 21-02-2019 om 01:28 schreef Matt Roper:
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com
I like how bgcolor is a u64 now, but there is an issue with setting crtc->state->bgcolor in attaching the property.
We should do it in atomic core init instead, like we already do for connector/plane properties..
See for example https://patchwork.freedesktop.org/series/52363/
This was specificallly for the background color proposal, but we probalby have to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
Hey,
Op 21-02-2019 om 01:28 schreef Matt Roper:
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com
I like how bgcolor is a u64 now, but there is an issue with setting crtc->state->bgcolor in attaching the property.
We should do it in atomic core init instead, like we already do for connector/plane properties..
See for example https://patchwork.freedesktop.org/series/52363/
This was specificallly for the background color proposal, but we probalby have to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.
Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it.
Matt
Op 26-02-2019 om 17:17 schreef Matt Roper:
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
Hey,
Op 21-02-2019 om 01:28 schreef Matt Roper:
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com
I like how bgcolor is a u64 now, but there is an issue with setting crtc->state->bgcolor in attaching the property.
We should do it in atomic core init instead, like we already do for connector/plane properties..
See for example https://patchwork.freedesktop.org/series/52363/
This was specificallly for the background color proposal, but we probalby have to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.
Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it.
There was a discussion about it. I will resubmit it and split it up for the non-trivial cases, so those can be reverted if needed.
Will send a new version in a bit.
Op 26-02-2019 om 17:17 schreef Matt Roper:
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
Hey,
Op 21-02-2019 om 01:28 schreef Matt Roper:
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com
I like how bgcolor is a u64 now, but there is an issue with setting crtc->state->bgcolor in attaching the property.
We should do it in atomic core init instead, like we already do for connector/plane properties..
See for example https://patchwork.freedesktop.org/series/52363/
This was specificallly for the background color proposal, but we probalby have to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.
Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it.
Matt
I've split out the patch and landed some of the preparation patches, it should be good enough to unblock this patch series at least now. :)
On Thu, Apr 25, 2019 at 12:45:33PM +0200, Maarten Lankhorst wrote:
Op 26-02-2019 om 17:17 schreef Matt Roper:
On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
Hey,
Op 21-02-2019 om 01:28 schreef Matt Roper:
Some display controllers can be programmed to present non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). Compositors that want a UI with a solid color background can potentially save memory bandwidth by setting the CRTC background property and using smaller planes to display the rest of the content.
To avoid confusion between different ways of encoding RGB data, we define a standard 64-bit format that should be used for this property's value. Helper functions and macros are provided to generate and dissect values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to understand and enclose the parameters in () to avoid calculations if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is to not worry about the internal representation of the u64, it can still be confusing to look at code that uses 'rgba' terminology, but stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the same pipe-level degamma/csc/gamma transformations that planes do. (Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are generally only useful in special cases such as when writeback connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside drm_crtc_add_bgcolor_property() in case drivers don't do this themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Sean Paul sean@poorly.run Cc: Brian Starkey Brian.Starkey@arm.com Cc: Eric Anholt eric@anholt.net Cc: Stéphane Marchesin marcheu@chromium.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by(v2): Sean Paul sean@poorly.run Reviewed-by: Brian Starkey brian.starkey@arm.com
I like how bgcolor is a u64 now, but there is an issue with setting crtc->state->bgcolor in attaching the property.
We should do it in atomic core init instead, like we already do for connector/plane properties..
See for example https://patchwork.freedesktop.org/series/52363/
This was specificallly for the background color proposal, but we probalby have to split out the non-trivial conversions of __drm_atomic_helper_crtc_reset.
Makes sense. What's the status of that patch? It looks like it has a lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking it? If you're still driving it forward, I can wait for that to land and then build on top of it.
Matt
I've split out the patch and landed some of the preparation patches, it should be good enough to unblock this patch series at least now. :)
Great, thanks! I've been traveling a bunch the last month and haven't had time to revisit this yet, but I'll come back and rebase / repost the series in the next week or so once I'm caught up again.
Matt
Gen9+ platforms allow CRTC's to be programmed with a background/canvas color below the programmable planes. Let's expose this for use by compositors.
v2: - Split out bgcolor sanitization and programming of csc/gamma bits to a separate patch that we can land before the ABI changes are ready to go in. (Ville) - Change a temporary variable name to be more consistent with other similar functions. (Ville) - Change register name to SKL_CANVAS for consistency with the CHV_CANVAS register.
v3: - Switch register name back to SKL_BOTTOM_COLOR. (Ville) - Use non-_FW register write. (Ville) - Minor parameter rename for consistency. (Ville)
v4: - Removed use of bgcolor_changed flag.
v5: - s/uint64_t/u64/
v6: - Rebase onto latest drm-tip (bgcolor writing now moves to the new color_commit function added by Ville's series)
Cc: dri-devel@lists.freedesktop.org Cc: wei.c.li@intel.com Cc: harish.krupo.kps@intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä ville.syrjala@linux.intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 9 +++++++++ drivers/gpu/drm/i915/intel_color.c | 11 ++++++++--- drivers/gpu/drm/i915/intel_display.c | 11 +++++++++++ 3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 2aeea977283f..0d9d951512af 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3060,6 +3060,15 @@ static int i915_display_info(struct seq_file *m, void *unused) intel_plane_info(m, crtc); }
+ if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) { + u64 background = pipe_config->base.bgcolor; + + seq_printf(m, "\tbackground color (10bpc): r=%x g=%x b=%x\n", + DRM_ARGB_RED(background, 10), + DRM_ARGB_GREEN(background, 10), + DRM_ARGB_BLUE(background, 10)); + } + seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n", yesno(!crtc->cpu_fifo_underrun_disabled), yesno(!crtc->pch_fifo_underrun_disabled)); diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index da7a07d5ccea..1e329a3ee6bd 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -424,12 +424,17 @@ static void skl_color_commit(const struct intel_crtc_state *crtc_state) struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum pipe pipe = crtc->pipe; + u64 propval = crtc_state->base.bgcolor; u32 val = 0;
+ /* Hardware is programmed with 10 bits of precision */ + val = DRM_ARGB_RED(propval, 10) << 20 + | DRM_ARGB_GREEN(propval, 10) << 10 + | DRM_ARGB_BLUE(propval, 10); + /* - * We don't (yet) allow userspace to control the pipe background color, - * so force it to black, but apply pipe gamma and CSC appropriately - * so that its handling will match how we program our planes. + * Apply pipe gamma and CSC appropriately so that its handling will + * match how we program our planes. */ if (crtc_state->gamma_enable) val |= SKL_BOTTOM_COLOR_GAMMA_ENABLE; diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index afa21daaae51..49e99d73ef89 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11220,6 +11220,8 @@ static int intel_crtc_atomic_check(struct drm_crtc *crtc, struct intel_crtc *intel_crtc = to_intel_crtc(crtc); struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc_state); + struct drm_crtc_state *old_crtc_state = + drm_atomic_get_old_crtc_state(crtc_state->state, crtc); int ret; bool mode_changed = needs_modeset(crtc_state);
@@ -11242,6 +11244,9 @@ static int intel_crtc_atomic_check(struct drm_crtc *crtc, return ret; }
+ if (crtc_state->bgcolor != old_crtc_state->bgcolor) + pipe_config->update_pipe = true; + ret = 0; if (dev_priv->display.compute_pipe_wm) { ret = dev_priv->display.compute_pipe_wm(pipe_config); @@ -14423,6 +14428,9 @@ static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
+ if (INTEL_GEN(dev_priv) >= 9) + drm_crtc_add_bgcolor_property(&intel_crtc->base); + return 0;
fail: @@ -15665,6 +15673,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state = to_intel_crtc_state(crtc->base.state); enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ /* Always force bgcolor to solid black */ + crtc_state->base.bgcolor = drm_argb(16, 0xFFFF, 0, 0, 0); + /* Clear any frame start delays used for debugging left by the BIOS */ if (crtc->active && !transcoder_is_dsi(cpu_transcoder)) { i915_reg_t reg = PIPECONF(cpu_transcoder);
We should support readout and verification of crtc background color as we do with other pipe state. Note that our hardware holds less bits of precision than the CRTC state allows, so we need to take care to only verify the most significant bits of the color after performing readout.
At boot time the pipe color is already sanitized to full black as required by ABI, so the new readout here won't break that requirement.
Suggested-by: Ville Syrjälä ville.syrjala@linux.intel.com Cc: Ville Syrjälä ville.syrjala@linux.intel.com Signed-off-by: Matt Roper matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä ville.syrjala@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 49e99d73ef89..2eba05e2fda6 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9869,6 +9869,7 @@ static bool haswell_get_pipe_config(struct intel_crtc *crtc, struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum intel_display_power_domain power_domain; u64 power_domain_mask; + u32 bgcolor; bool active;
intel_crtc_init_scalers(crtc, pipe_config); @@ -9947,6 +9948,15 @@ static bool haswell_get_pipe_config(struct intel_crtc *crtc, pipe_config->pixel_multiplier = 1; }
+ if (INTEL_GEN(dev_priv) >= 9) { + bgcolor = I915_READ(SKL_BOTTOM_COLOR(crtc->pipe)); + pipe_config->base.bgcolor = + drm_argb(10, 0xFFFF, + bgcolor >> 20 & 0x3FF, + bgcolor >> 10 & 0x3FF, + bgcolor & 0x3FF); + } + out: for_each_power_domain(power_domain, power_domain_mask) intel_display_power_put_unchecked(dev_priv, power_domain); @@ -11580,6 +11590,10 @@ static void intel_dump_pipe_config(struct intel_crtc *crtc, drm_rect_width(&state->base.dst), drm_rect_height(&state->base.dst)); } + + if (INTEL_GEN(dev_priv) >= 9) + DRM_DEBUG_KMS("background color: %llx\n", + pipe_config->base.bgcolor); }
static bool check_digital_port_conflicts(struct drm_atomic_state *state) @@ -11946,6 +11960,16 @@ intel_pipe_config_compare(struct drm_i915_private *dev_priv, } \ } while (0)
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \ + if ((current_config->name & mask) != (pipe_config->name & mask)) { \ + pipe_config_err(adjust, __stringify(name), \ + "(expected 0x%016llx, found 0x%016llx)\n", \ + current_config->name & mask, \ + pipe_config->name & mask); \ + ret = false; \ + } \ +} while (0) + #define PIPE_CONF_CHECK_I(name) do { \ if (current_config->name != pipe_config->name) { \ pipe_config_err(adjust, __stringify(name), \ @@ -12201,6 +12225,14 @@ intel_pipe_config_compare(struct drm_i915_private *dev_priv,
PIPE_CONF_CHECK_I(min_voltage_level);
+ /* + * Hardware only holds top 10 bits of each color component; ignore + * bottom six bits (and all of alpha) when comparing against readout. + */ + if (INTEL_GEN(dev_priv) >= 9) + PIPE_CONF_CHECK_LLX_MASKED(base.bgcolor, 0x0000FFC0FFC0FFC0); + +#undef PIPE_CONF_CHECK_LLX_MASKED #undef PIPE_CONF_CHECK_X #undef PIPE_CONF_CHECK_I #undef PIPE_CONF_CHECK_BOOL
dri-devel@lists.freedesktop.org