Re: [PATCH] drm/amd/display: Remove unnecessary NULL check in dcn20_set_input_transfer_func
On 2024-04-23 09:59, Srinivasan Shanmugam wrote:
> This commit removes an unnecessary NULL check in the
> `dcn20_set_input_transfer_func` function in the `dcn20_hwseq.c` file.
> The variable `tf` is assigned the address of
> `plane_state->in_transfer_func` unconditionally, so it can never be
> `NULL`. Therefore, the check `if (tf == NULL)` is unnecessary and has
> been removed.
>
> The plane_state->in_transfer_func itself cannot be NULL because it's a
> structure, not a pointer. When we do tf =
> _state->in_transfer_func;, we're getting the address of that
> structure, which will always be valid as long as plane_state itself is
> not NULL.
>
> we've already checked if plane_state is NULL with the line if (dpp_base
> == NULL || plane_state == NULL) return false;. So, if the code execution
> gets to the point where tf = _state->in_transfer_func; is called,
> plane_state is guaranteed to be not NULL, and therefore tf will also not
> be NULL.
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c
> 1094 bool dcn20_set_input_transfer_func(struct dc *dc,
> 1095 struct pipe_ctx *pipe_ctx,
> 1096 const struct dc_plane_state
> *plane_state)
> 1097 {
> 1098 struct dce_hwseq *hws = dc->hwseq;
> 1099 struct dpp *dpp_base = pipe_ctx->plane_res.dpp;
> 1100 const struct dc_transfer_func *tf = NULL;
> ^ This assignment is
> not necessary now.
>
> 1101 bool result = true;
> 1102 bool use_degamma_ram = false;
> 1103
> 1104 if (dpp_base == NULL || plane_state == NULL)
> 1105 return false;
> 1106
> 1107 hws->funcs.set_shaper_3dlut(pipe_ctx, plane_state);
> 1108 hws->funcs.set_blend_lut(pipe_ctx, plane_state);
> 1109
> 1110 tf = _state->in_transfer_func;
> ^
> Before there was an if statement but now tf is assigned unconditionally
>
>
> --> 1112 if (tf == NULL) {
> ^
> so these conditions are impossible.
>
> 1113 dpp_base->funcs->dpp_set_degamma(dpp_base,
> 1114 IPP_DEGAMMA_MODE_BYPASS);
> 1115 return true;
> 1116 }
> 1117
> 1118 if (tf->type == TF_TYPE_HWPWL || tf->type ==
> TF_TYPE_DISTRIBUTED_POINTS)
> 1119 use_degamma_ram = true;
> 1120
> 1121 if (use_degamma_ram == true) {
> 1122 if (tf->type == TF_TYPE_HWPWL)
> 1123
> dpp_base->funcs->dpp_program_degamma_pwl(dpp_base,
>
> Fixes the below Smatch static checker warning:
> drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1112
> dcn20_set_input_transfer_func() warn: address of
> 'plane_state->in_transfer_func' is non-NULL
>
> Fixes: 285a7054bf81 ("drm/amd/display: Remove plane and stream pointers from
> dc scratch")
> Cc: Wenjing Liu
> Cc: Tom Chung
> Cc: Alvin Lee
> Cc: Rodrigo Siqueira
> Cc: Roman Li
> Cc: Qingqing Zhuo
> Cc: Aurabindo Pillai
> Cc: Harry Wentland
> Suggested-by: Dan Carpenter
> Signed-off-by: Srinivasan Shanmugam
Previously plane_state->in_transfer_func was a pointer but that was
changed recently. Looks like this place was missed.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
> b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
> index b60ba2a110f7..58fbdd535068 100644
> --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c
> @@ -1109,12 +1109,6 @@ bool dcn20_set_input_transfer_func(struct dc *dc,
>
> tf = _state->in_transfer_func;
>
> - if (tf == NULL) {
> - dpp_base->funcs->dpp_set_degamma(dpp_base,
> - IPP_DEGAMMA_MODE_BYPASS);
> - return true;
> - }
> -
> if (tf->type == TF_TYPE_HWPWL || tf->type == TF_TYPE_DISTRIBUTED_POINTS)
> use_degamma_ram = true;
>
Re: [PATCH] Revert "drm/amd/display: Add fallback configuration when set DRR"
On 2024-04-22 09:51, Rodrigo Siqueira wrote:
> This reverts commit 5ea4581611d14a6a0e8df40965802ec7bee9c671.
>
> This change must be reverted since it caused soft hangs when changing
> the refresh rate to 122 & 144Hz when using a 7000 series GPU.
>
> Reported-by: Mark Broadworth
> Cc: Daniel Wheeler
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c| 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
> b/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
> index c4f0e1951427..52eab8fccb7f 100644
> --- a/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
> +++ b/drivers/gpu/drm/amd/display/dc/optc/dcn32/dcn32_optc.c
> @@ -293,16 +293,9 @@ static void optc32_set_drr(
> }
>
> optc->funcs->set_vtotal_min_max(optc,
> params->vertical_total_min - 1, params->vertical_total_max - 1);
> - optc32_setup_manual_trigger(optc);
> - } else {
> - REG_UPDATE_4(OTG_V_TOTAL_CONTROL,
> - OTG_SET_V_TOTAL_MIN_MASK, 0,
> - OTG_V_TOTAL_MIN_SEL, 0,
> - OTG_V_TOTAL_MAX_SEL, 0,
> - OTG_FORCE_LOCK_ON_EVENT, 0);
> -
> - optc->funcs->set_vtotal_min_max(optc, 0, 0);
> }
> +
> + optc32_setup_manual_trigger(optc);
> }
>
> static struct timing_generator_funcs dcn32_tg_funcs = {
Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
On 2024-03-07 01:29, Wayne Lin wrote:
> [Why]
> Commit:
> - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> allocation/removement")
> accidently overwrite the commit
> - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in
> drm_dp_add_payload_part2")
> which cause regression.
>
> [How]
> Recover the original NULL fix and remove the unnecessary input parameter
> 'state' for
> drm_dp_add_payload_part2().
>
> Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload
> allocation/removement")
> Reported-by: Leon Weiß
> Link:
> https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.ca...@ruhr-uni-bochum.de/
> Cc: ly...@redhat.com
> Cc: imre.d...@intel.com
> Cc: sta...@vger.kernel.org
> Cc: regressi...@lists.linux.dev
> Signed-off-by: Wayne Lin
I haven't been deep in MST code in a while but this all looks
pretty straightforward and good.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 1 -
> 5 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index c27063305a13..2c36f3d00ca2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -363,7 +363,7 @@ void dm_helpers_dp_mst_send_payload_allocation(
> mst_state = to_drm_dp_mst_topology_state(mst_mgr->base.state);
> new_payload = drm_atomic_get_mst_payload_state(mst_state,
> aconnector->mst_output_port);
>
> - ret = drm_dp_add_payload_part2(mst_mgr, mst_state->base.state,
> new_payload);
> + ret = drm_dp_add_payload_part2(mst_mgr, new_payload);
>
> if (ret) {
> amdgpu_dm_set_mst_status(>mst_status,
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 03d528209426..95fd18f24e94 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3421,7 +3421,6 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
> /**
> * drm_dp_add_payload_part2() - Execute payload update part 2
> * @mgr: Manager to use.
> - * @state: The global atomic state
> * @payload: The payload to update
> *
> * If @payload was successfully assigned a starting time slot by
> drm_dp_add_payload_part1(), this
> @@ -3430,14 +3429,13 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part2);
> * Returns: 0 on success, negative error code on failure.
> */
> int drm_dp_add_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
> - struct drm_atomic_state *state,
>struct drm_dp_mst_atomic_payload *payload)
> {
> int ret = 0;
>
> /* Skip failed payloads */
> if (payload->payload_allocation_status !=
> DRM_DP_MST_PAYLOAD_ALLOCATION_DFP) {
> - drm_dbg_kms(state->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> + drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s
> failed, skipping part 2\n",
> payload->port->connector->name);
> return -EIO;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 53aec023ce92..2fba66aec038 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1160,7 +1160,7 @@ static void intel_mst_enable_dp(struct
> intel_atomic_state *state,
> if (first_mst_stream)
> intel_ddi_wait_for_fec_status(encoder, pipe_config, true);
>
> - drm_dp_add_payload_part2(_dp->mst_mgr, >base,
> + drm_dp_add_payload_part2(_dp->mst_mgr,
>drm_atomic_get_mst_payload_state(mst_state,
> connector->port));
>
> if (DISPLAY_VER(dev_priv) >= 12)
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 0c3d88ad0b0e..88728a0b2c25 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -915,7 +915,7 @@ nv50_msto_cleanup(struct drm_atomic_state *state,
> msto->disabled = fals
Re: [PATCH v2 1/4] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
On 2024-01-15 11:05, Andri Yngvason wrote: > From: Werner Sembach > > Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the > drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && > force_yuv420_output case. > > Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, > there is no reason to use RGB when the display > reports drm_mode_is_420_only() even on a non HDMI connection. > > This patch also moves both checks in the same if-case. This eliminates an > extra else-if-case. > > Signed-off-by: Werner Sembach > Signed-off-by: Andri Yngvason > Tested-by: Andri Yngvason > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index f6575d7dee971..cc4d1f7f97b98 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -5575,11 +5575,7 @@ static void > fill_stream_properties_from_drm_display_mode( > timing_out->v_border_bottom = 0; > /* TODO: un-hardcode */ > if (drm_mode_is_420_only(info, mode_in) > - && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) > - timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; > - else if (drm_mode_is_420_also(info, mode_in) > - && aconnector > - && aconnector->force_yuv420_output) > + || (drm_mode_is_420_also(info, mode_in) && > aconnector->force_yuv420_output)) We need to keep the && aconnector NULL check here, otherwise writeback connectors will blow up. Harry > timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; > else if ((connector->display_info.color_formats & > DRM_COLOR_FORMAT_YCBCR444) > && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace
I'm a bit late to the game but I don't think this is merged
yet.
On 2024-01-15 11:05, Andri Yngvason wrote:
> From: Werner Sembach
>
> Add a new general drm property "force color format" which can be used
> by userspace to tell the graphics driver which color format to use.
>
> Possible options are:
> - auto (default/current behaviour)
> - rgb
> - ycbcr444
> - ycbcr422 (supported by neither amdgpu or i915)
If no driver uses this should we expose this now? I would
prefer to leave ycbcr422 out of this until we have a driver
that actually uses it.
I've seen too many properties with ever possible value defined
but they're not used by any (open) userspace and then become
the object of intense discussion on how they should work. I
doubt that this would happen here, but I still feel a slight
aversion to defining things that no open userspace can use at
this point.
I agree with all of Sebastian and Pekka's comments elsewhere in
this thread, in particular with Sebastian's comments to not
advertise color formats that a driver can't support. See this
patch for how I implemented something similar for Colorspace
c265f340eaa8 ("drm/connector: Allow drivers to pass list of supported
colorspaces")
Harry
> - ycbcr420
>
> In theory the auto option should choose the best available option for the
> current setup, but because of bad internal conversion some monitors look
> better with rgb and some with ycbcr444.
>
> Also, because of bad shielded connectors and/or cables, it might be
> preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
> for a signal that is less susceptible to interference.
>
> In the future, automatic color calibration for screens might also depend on
> this option being available.
>
> Signed-off-by: Werner Sembach
> Signed-off-by: Andri Yngvason
> Tested-by: Andri Yngvason
> ---
>
> Changes in v2:
> - Renamed to "force color format" from "preferred color format"
> - Removed Reported-by pointing to invalid email address
>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 48 +
> include/drm/drm_connector.h | 16 ++
> 4 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39ef0a6addeba..1dabd164c4f09 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -707,6 +707,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->max_requested_bpc !=
> new_connector_state->max_requested_bpc)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->force_color_format !=
> + new_connector_state->force_color_format)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d49..e45949bf4615f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -776,6 +776,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->max_requested_bpc = val;
> } else if (property == connector->privacy_screen_sw_state_property) {
> state->privacy_screen_sw_state = val;
> + } else if (property == connector->force_color_format_property) {
> + state->force_color_format = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -859,6 +861,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->max_requested_bpc;
> } else if (property == connector->privacy_screen_sw_state_property) {
> *val = state->privacy_screen_sw_state;
> + } else if (property == connector->force_color_format_property) {
> + *val = state->force_color_format;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b0516505f7ae9..e0535e58b4535 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> };
>
> +static const struct drm_prop_enum_list drm_force_color_format_enum_list[] = {
> + { 0, "auto" },
> + {
Re: [PATCH] drm/amd/display: Set color_mgmt_changed to true on unsuspend
On 2023-11-02 00:21, Joshua Ashton wrote:
> Otherwise we can end up with a frame on unsuspend where color management
> is not applied when userspace has not committed themselves.
>
> Fixes re-applying color management on Steam Deck/Gamescope on S3 resume.
>
> Signed-off-by: Joshua Ashton
Going through old emails and found this.
Reviewed-by: Harry Wentland
Pulling it into amd-staging-drm-next.
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index adbeb2c897b5..ae650707f234 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2967,6 +2967,7 @@ static int dm_resume(void *handle)
> dc_stream_release(dm_new_crtc_state->stream);
> dm_new_crtc_state->stream = NULL;
> }
> + dm_new_crtc_state->base.color_mgmt_changed = true;
> }
>
> for_each_new_plane_in_state(dm->cached_state, plane, new_plane_state,
> i) {
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-16 04:01, Pekka Paalanen wrote: > On Mon, 15 Apr 2024 18:33:39 -0400 > Leo Li wrote: > >> On 2024-04-15 04:19, Pekka Paalanen wrote: >>> On Fri, 12 Apr 2024 16:14:28 -0400 >>> Leo Li wrote: >>> On 2024-04-12 11:31, Alex Deucher wrote: > On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen > wrote: >> >> On Fri, 12 Apr 2024 10:28:52 -0400 >> Leo Li wrote: >> >>> On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: >> >> ... >> > That begs the question of what can be nailed down and what can left to > independent implementation. I guess things like which plane should be > enabled > first (PRIMARY), and how zpos should be interpreted (overlay, > underlay, mixed) > can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. >>> >>> The zpos value of the PRIMARY plane relative to OVERLAYS, for example, >>> as a way >>> for vendors to communicate overlay, underlay, or mixed-arrangement >>> support. I >>> don't think allowing OVERLAYs to be placed under the PRIMARY is >>> currently >>> documented as a way to support underlay. >> >> I always thought it's obvious that the zpos numbers dictate the plane >> order without any other rules. After all, we have the universal planes >> concept, where the plane type is only informational to aid heuristics >> rather than defining anything. >> >> Only if the zpos property does not exist, the plane types would come >> into play. >> >> Of course, if there actually exists userspace that fails if zpos allows >> an overlay type plane to be placed below primary, or fails if primary >> zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. >> >>> libliftoff for example, assumes that the PRIMARY has the lowest zpos. So >>> underlay arrangements will use an OVERLAY for the scanout plane, and >>> the PRIMARY >>> for the underlay view. >> >> That's totally ok. It works, right? Plane type does not matter if the >> KMS driver accepts the configuration. >> >> What is a "scanout plane"? Aren't all KMS planes by definition scanout >> planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. >>> >>> The assignment restriction is just technical design debt. It is >>> limiting. There is no other good reason for it, than when lighting >>> up a CRTC for the first time, Weston should do it with the renderer FB >>> only, on the plane that is most likely to succeed i.e. PRIMARY. After >>> the CRTC is lit, there should be no built-in limitations in what can go >>> where. >>> >>> The reason for this is that if a CRTC can be activated, it must always >>> be able to show the renderer FB without incurring a modeset. This is >>> important for ensuring that the fallback compositing (renderer) is >>> always possible. So we start with that configuration, and everything >>> else is optional bonus. >> >> Genuinely curious - What exactly is limiting with keeping the renderer FB on >> PRIMARY? IOW, what is the additional benefit of placing the renderer FB on >> something other than PRIMARY? > > The limitations come from a combination of hardware limitations. > Perhaps zpos is not mutable, or maybe other planes cannot arbitrarily > move between above and below the primary. This reduces the number of > possible configurations, which might cause off-loading to fail. > > I think older hardware has more of these arbitrary restrictions. > For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. >>> >>> If zpos exists, I don't think such limitation is a good idea. It will >>> just limit the possible configurations for no reason. >>> >>> With zpos, the KMS plane type should be irrelevant for their >>> z-ordering. Underlay vs. overlay completely loses its meaning at the >>> KMS level. >> >> Right, the plane types loose their meanings. But at least with the way >>
Re: [PATCH] drm/amd/display: Enable ogam_ram for dcn32+dcn35+dcn351
On 2024-04-15 11:27, Melissa Wen wrote: > On 04/12, Harry Wentland wrote: >> >> >> On 2024-04-12 16:22, Harry Wentland wrote: >>> >>> >>> On 2024-04-12 12:26, Melissa Wen wrote: >>>> On 04/12, Joshua Ashton wrote: >>>>> >>>>> >>>>> On 4/11/24 3:26 PM, Melissa Wen wrote: >>>>>> On 04/10, Joshua Ashton wrote: >>>>>>> The comment here states "no OGAM in DPP since DCN1", yet that is not >>>>>>> true. >>>>>>> >>>>>>> Testing on an RX 7900XTX (dcn32), it actually does exist in hardware and >>>>>>> works fine. >>>>>>> My best guess is the comment is confused with OGAM ROM for DPP, rather >>>>>>> than OGAM RAM. >>>>>>> >>>>>>> I did not test dcn35/351 as I do not have that hardware, but I assume >>>>>>> the same follows there given the seemingly erroneous comment. >>>>>>> Someone at AMD should check that before merging this commit. >>>>>> >>>>>> hmm... I don't have any of these hw versions, but AFAIU if there is >>>>>> ogam/blend lut block in dcn32, the helper implementation for programming >>>>>> it properly (i.e. dpp_program_blnd_lut) is also missing here: >>>>>> - >>>>>> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dpp/dcn32/dcn32_dpp.c#L125 >>>>>> right? So, it's good if AMD people can check it too. >>>>>> >>>>>> Melissa >>>>> >>>>> Hmm, yes. But, see dcn32_set_mcm_luts, that seems to handle per-plane >>>>> blend >>>>> + shaper + 3D LUT state which is equivalent to what existed before? >>>> >>>> oh, cool! nice finding. blnd_lut is set on plane state, but programmed >>>> on MPC now. >>>> >>>> But I see the color pipeline changed in many stages from this version: >>>> - shaper + 3dlut before **or** after blending, but not before **and** >>>> after? >>>> - where post-blending gamut_remap_matrix is located now in this >>>> pipeline with mpcc postblend_1dlut and shaper+3dlut with mutable >>>> position? >>>> I guess something like: >>>> - [shaper -> 3dlut -> blnd_lut] -> ctm -> regamma ?? >>> >>> [1dlut -> 3dlut -> 1dlut] is now a movable block, called Movable CM >>> (color management), or MCM for short. It can occur before blending or >>> after. Because of that it moved to MPC (multi-plane combiner). >>> >>> If it's positioned for pre-blending it looks like this: >>> >>> DPP -> MCM -> BLND -> Blending -> Gamut Remap -> Out Gam -> OPP -> ... >>> >>> If it's positioned for post-blending it looks like this: >>> >>> DPP -> BLND -> Blending -> MCM -> Gamut Remap -> Out Gam -> OPP >>> >>> This is the case since DCN 3.2. >>> >>> Because of that you don't have an ogam_ram in dpp anymore for DCN 3.2 >>> and newer. >>> >>>>> >>>>> Therefore, I think I am actually wrong with enabling the ogam_ram in DPP >>>>> cap >>>>> here, and the right solution is to change the check for exposing the >>>>> property to account for these LUTs being available per-plane with mcm. >>>>> >>>>> (what is mcm btw...? lots of acronyms and stuff moving around in hw hehe) >>>> >>>> yes, shaper, 3dlut, blend_lut don't seem DPP caps anymore. MCM looks >>>> like a component of MPC, so I think we need new mpc.color caps to >>>> describe them properly (?) >>>> >>>> I also didn't find in the Linux/AMD glossary or code comment that >>>> describe what MCM is... >>>> >>>>> >>>>> What's a good way for us to check for that? Seems like the caps don't help >>>>> much there. We could check for the literal function ptr I guess...? >>>>> >>>>> What are your thoughts, Harry and Melissa? >>>> >>> >>> I wonder if it makes sense to add an mcm cap to mpc_color_caps. Will need to >>> chat with some people about that. >>> >> >> I dug through the code a bit and talked with our resident expert. It looks >> like all the programming for
Re: [PATCH] drm/amd/display: Enable ogam_ram for dcn32+dcn35+dcn351
On 2024-04-12 16:22, Harry Wentland wrote: > > > On 2024-04-12 12:26, Melissa Wen wrote: >> On 04/12, Joshua Ashton wrote: >>> >>> >>> On 4/11/24 3:26 PM, Melissa Wen wrote: >>>> On 04/10, Joshua Ashton wrote: >>>>> The comment here states "no OGAM in DPP since DCN1", yet that is not >>>>> true. >>>>> >>>>> Testing on an RX 7900XTX (dcn32), it actually does exist in hardware and >>>>> works fine. >>>>> My best guess is the comment is confused with OGAM ROM for DPP, rather >>>>> than OGAM RAM. >>>>> >>>>> I did not test dcn35/351 as I do not have that hardware, but I assume >>>>> the same follows there given the seemingly erroneous comment. >>>>> Someone at AMD should check that before merging this commit. >>>> >>>> hmm... I don't have any of these hw versions, but AFAIU if there is >>>> ogam/blend lut block in dcn32, the helper implementation for programming >>>> it properly (i.e. dpp_program_blnd_lut) is also missing here: >>>> - >>>> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dpp/dcn32/dcn32_dpp.c#L125 >>>> right? So, it's good if AMD people can check it too. >>>> >>>> Melissa >>> >>> Hmm, yes. But, see dcn32_set_mcm_luts, that seems to handle per-plane blend >>> + shaper + 3D LUT state which is equivalent to what existed before? >> >> oh, cool! nice finding. blnd_lut is set on plane state, but programmed >> on MPC now. >> >> But I see the color pipeline changed in many stages from this version: >> - shaper + 3dlut before **or** after blending, but not before **and** after? >> - where post-blending gamut_remap_matrix is located now in this >> pipeline with mpcc postblend_1dlut and shaper+3dlut with mutable >> position? >> I guess something like: >> - [shaper -> 3dlut -> blnd_lut] -> ctm -> regamma ?? > > [1dlut -> 3dlut -> 1dlut] is now a movable block, called Movable CM > (color management), or MCM for short. It can occur before blending or > after. Because of that it moved to MPC (multi-plane combiner). > > If it's positioned for pre-blending it looks like this: > > DPP -> MCM -> BLND -> Blending -> Gamut Remap -> Out Gam -> OPP -> ... > > If it's positioned for post-blending it looks like this: > > DPP -> BLND -> Blending -> MCM -> Gamut Remap -> Out Gam -> OPP > > This is the case since DCN 3.2. > > Because of that you don't have an ogam_ram in dpp anymore for DCN 3.2 > and newer. > >>> >>> Therefore, I think I am actually wrong with enabling the ogam_ram in DPP cap >>> here, and the right solution is to change the check for exposing the >>> property to account for these LUTs being available per-plane with mcm. >>> >>> (what is mcm btw...? lots of acronyms and stuff moving around in hw hehe) >> >> yes, shaper, 3dlut, blend_lut don't seem DPP caps anymore. MCM looks >> like a component of MPC, so I think we need new mpc.color caps to >> describe them properly (?) >> >> I also didn't find in the Linux/AMD glossary or code comment that >> describe what MCM is... >> >>> >>> What's a good way for us to check for that? Seems like the caps don't help >>> much there. We could check for the literal function ptr I guess...? >>> >>> What are your thoughts, Harry and Melissa? >> > > I wonder if it makes sense to add an mcm cap to mpc_color_caps. Will need to > chat with some people about that. > I dug through the code a bit and talked with our resident expert. It looks like all the programming for in_shaper_func, lut_3d_func, and blend_tf should still work and assume a fixed pre-blending mcm, which is what we want. Caps don't really reflect MCM very well yet. We could either add an mcm flag to mpc_color_caps or simply check that DCN is 3.2 or newer: amdgpu_ip_version(adev, DCE_HWIP, 0) >= IP_VERSION(3, 2, 0) Harry > Harry > >> yeah, AFAIK color caps values are manually set and may contain >> misleading information. I'm unsure that using function ptr would solve >> the issue of having undocumented caps introduced to the color pipeline, >> such as MCM, but your suggestion seems more reliable. >> >> Anyway, the timing where the color pipeline was merged didn't help, but >> if new caps and functions are not documented and the DM handles are not >> updated according
Re: [PATCH] drm/amd/display: Enable ogam_ram for dcn32+dcn35+dcn351
On 2024-04-12 12:26, Melissa Wen wrote: > On 04/12, Joshua Ashton wrote: >> >> >> On 4/11/24 3:26 PM, Melissa Wen wrote: >>> On 04/10, Joshua Ashton wrote: >>>> The comment here states "no OGAM in DPP since DCN1", yet that is not >>>> true. >>>> >>>> Testing on an RX 7900XTX (dcn32), it actually does exist in hardware and >>>> works fine. >>>> My best guess is the comment is confused with OGAM ROM for DPP, rather >>>> than OGAM RAM. >>>> >>>> I did not test dcn35/351 as I do not have that hardware, but I assume >>>> the same follows there given the seemingly erroneous comment. >>>> Someone at AMD should check that before merging this commit. >>> >>> hmm... I don't have any of these hw versions, but AFAIU if there is >>> ogam/blend lut block in dcn32, the helper implementation for programming >>> it properly (i.e. dpp_program_blnd_lut) is also missing here: >>> - >>> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dpp/dcn32/dcn32_dpp.c#L125 >>> right? So, it's good if AMD people can check it too. >>> >>> Melissa >> >> Hmm, yes. But, see dcn32_set_mcm_luts, that seems to handle per-plane blend >> + shaper + 3D LUT state which is equivalent to what existed before? > > oh, cool! nice finding. blnd_lut is set on plane state, but programmed > on MPC now. > > But I see the color pipeline changed in many stages from this version: > - shaper + 3dlut before **or** after blending, but not before **and** after? > - where post-blending gamut_remap_matrix is located now in this > pipeline with mpcc postblend_1dlut and shaper+3dlut with mutable > position? > I guess something like: > - [shaper -> 3dlut -> blnd_lut] -> ctm -> regamma ?? [1dlut -> 3dlut -> 1dlut] is now a movable block, called Movable CM (color management), or MCM for short. It can occur before blending or after. Because of that it moved to MPC (multi-plane combiner). If it's positioned for pre-blending it looks like this: DPP -> MCM -> BLND -> Blending -> Gamut Remap -> Out Gam -> OPP -> ... If it's positioned for post-blending it looks like this: DPP -> BLND -> Blending -> MCM -> Gamut Remap -> Out Gam -> OPP This is the case since DCN 3.2. Because of that you don't have an ogam_ram in dpp anymore for DCN 3.2 and newer. >> >> Therefore, I think I am actually wrong with enabling the ogam_ram in DPP cap >> here, and the right solution is to change the check for exposing the >> property to account for these LUTs being available per-plane with mcm. >> >> (what is mcm btw...? lots of acronyms and stuff moving around in hw hehe) > > yes, shaper, 3dlut, blend_lut don't seem DPP caps anymore. MCM looks > like a component of MPC, so I think we need new mpc.color caps to > describe them properly (?) > > I also didn't find in the Linux/AMD glossary or code comment that > describe what MCM is... > >> >> What's a good way for us to check for that? Seems like the caps don't help >> much there. We could check for the literal function ptr I guess...? >> >> What are your thoughts, Harry and Melissa? > I wonder if it makes sense to add an mcm cap to mpc_color_caps. Will need to chat with some people about that. Harry > yeah, AFAIK color caps values are manually set and may contain > misleading information. I'm unsure that using function ptr would solve > the issue of having undocumented caps introduced to the color pipeline, > such as MCM, but your suggestion seems more reliable. > > Anyway, the timing where the color pipeline was merged didn't help, but > if new caps and functions are not documented and the DM handles are not > updated accordingly, we will have the same issue in the future. > For example, I see two new ptrs were introduced and implemented here: > - https://gitlab.freedesktop.org/agd5f/linux/-/commit/a820190204aef > - https://gitlab.freedesktop.org/agd5f/linux/-/commit/90f33674a0756 > and we would need to update the DM color mgmt anyway to check these > new/unknown functions. > > Seems okay if we check program_1dlut instead of ogam_ram caps, but what > should we do for dpp/mpc shaper+3d lut in set_mcm_luts? I mean, should > we enable plane or CRTC shaper+3dlut on DM? x_X > > Anyway, thanks for all these findings! > > I would like to hear more from AMD too. > > Melissa > >> >> - Joshie ✨ >> >>> >>>> >>>> Signed-off-by: Joshua Ashton >>>> >>>> Cc: Harry Wentland >>&g
Re: [PATCH] Revert "drm/amd/display: fix USB-C flag update after enc10 feature init"
On 2024-04-12 00:16, Alex Deucher wrote: > ping? > > On Fri, Mar 29, 2024 at 6:59 PM Alex Deucher > wrote: >> >> This reverts commit b5abd7f983e14054593dc91d6df2aa5f8cc67652. >> >> This change breaks DSC on 4k monitors at 144Hz over USB-C. >> >> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3254 >> Signed-off-by: Alex Deucher >> Cc: Muhammad Ahmed >> Cc: Tom Chung >> Cc: Charlene Liu >> Cc: Hamza Mahfooz >> Cc: Harry Wentland Reviewed-by: Harry Wentland Harry >> --- >> .../gpu/drm/amd/display/dc/dcn32/dcn32_dio_link_encoder.c | 8 +++- >> .../gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c | 4 ++-- >> 2 files changed, 5 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dio_link_encoder.c >> b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dio_link_encoder.c >> index e224a028d68ac..8a0460e863097 100644 >> --- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dio_link_encoder.c >> +++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dio_link_encoder.c >> @@ -248,14 +248,12 @@ void dcn32_link_encoder_construct( >> enc10->base.hpd_source = init_data->hpd_source; >> enc10->base.connector = init_data->connector; >> >> - enc10->base.preferred_engine = ENGINE_ID_UNKNOWN; >> - >> - enc10->base.features = *enc_features; >> if (enc10->base.connector.id == CONNECTOR_ID_USBC) >> enc10->base.features.flags.bits.DP_IS_USB_C = 1; >> >> - if (enc10->base.connector.id == CONNECTOR_ID_USBC) >> - enc10->base.features.flags.bits.DP_IS_USB_C = 1; >> + enc10->base.preferred_engine = ENGINE_ID_UNKNOWN; >> + >> + enc10->base.features = *enc_features; >> >> enc10->base.transmitter = init_data->transmitter; >> >> diff --git a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c >> b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c >> index 6e6ae3de08e4c..6864b6d174370 100644 >> --- a/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c >> +++ b/drivers/gpu/drm/amd/display/dc/dcn35/dcn35_dio_link_encoder.c >> @@ -184,6 +184,8 @@ void dcn35_link_encoder_construct( >> enc10->base.hpd_source = init_data->hpd_source; >> enc10->base.connector = init_data->connector; >> >> + if (enc10->base.connector.id == CONNECTOR_ID_USBC) >> + enc10->base.features.flags.bits.DP_IS_USB_C = 1; >> >> enc10->base.preferred_engine = ENGINE_ID_UNKNOWN; >> >> @@ -238,8 +240,6 @@ void dcn35_link_encoder_construct( >> } >> >> enc10->base.features.flags.bits.HDMI_6GB_EN = 1; >> - if (enc10->base.connector.id == CONNECTOR_ID_USBC) >> - enc10->base.features.flags.bits.DP_IS_USB_C = 1; >> >> if (bp_funcs->get_connector_speed_cap_info) >> result = >> bp_funcs->get_connector_speed_cap_info(enc10->base.ctx->dc_bios, >> -- >> 2.44.0 >>
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
on plane >> arrangement algorithm. I think libliftoff is the most obvious candidate >> here. It >> only handles overlay arrangements currently, but mixed-mode arrangements is >> something I've been trying to look at. >> >> Taking the driver's reported zpos into account could narrow down the search >> space for mixed arrangements. We could tell whether underlay, or overlay, or >> both, is supported by looking at the allowed zpos ranges. >> >> I also wonder if it'll make underlay assignments easier. libliftoff has an >> assumption that the PRIMARY plane has the lowest zpos (which now I realize, >> is >> not always true). Therefore, the underlay buffer has to be placed on the >> PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between >> planes when testing mixed-arrangements is kind of awkward, and simply setting >> the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. >> >> Currently only gamescope makes use of libliftoff, but I'm curious if patches >> hooking it up to Weston would be welcomed? If there are other ways to have a >> common arrangement algorithm, I'd be happy to hear that as well. > > A natural thing would be to document such an algorithm with the KMS > UAPI. > > I don't know libliftoff well enough to say how welcome it would be in > Weston. I have no fundamental or policy reason to keep an independent > implementation in Weston though, so it's plausible at least. > > It would need investigation, and perhaps also extending Weston test > suite a lot more towards VKMS to verify plane assignments. Currently > all plane assignment testing is manual on real hardware. > It looks like VKMS doesn't have explicit zpos yet, so someone would probably need to add that. https://drmdb.emersion.fr/properties/4008636142/zpos Harry >> Note that libliftoff's algorithm is more complex than weston, since it >> searches >> harder, and suffers from that permutational explosion. But it solves that by >> trying high benefit arrangements first (offloading surfaces that update >> frequently), and bailing out once the search reaches a hard-coded deadline. >> Since it's currently overlay-only, the goal could be to "simply" have no >> regressions. > > Ensuring no regressions would indeed need to be taken care of by > extending the VKMS-based automated testing. > > > Thanks, > pq > >>> >>>> Some links to provide context and details: >>>> * What is underlay?: >>>> https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76 >>>> * Discussion on how to implement underlay on Weston: >>>> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164 >>>> >>>> Cc: Joshua Ashton >>>> Cc: Michel Dänzer >>>> Cc: Chao Guo >>>> Cc: Xaver Hugl >>>> Cc: Vikas Korjani >>>> Cc: Robert Mader >>>> Cc: Pekka Paalanen >>>> Cc: Sean Paul >>>> Cc: Simon Ser >>>> Cc: Shashank Sharma >>>> Cc: Harry Wentland >>>> Cc: Sebastian Wick >>>> >>>> Leo Li (2): >>>>drm/amd/display: Introduce overlay cursor mode >>>>drm/amd/display: Move PRIMARY plane zpos higher >>>> >>>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 405 -- >>>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 + >>>> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 + >>>> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 28 +- >>>> 4 files changed, 391 insertions(+), 50 deletions(-) >>>> >>> >
Re: [PATCH 30/43] drm/amd/display: Enable cur_rom_en even if cursor degamma is not enabled
On 2024-04-01 09:40, Melissa Wen wrote:
>
>
> On 28/03/2024 16:50, roman...@amd.com wrote:
>> From: Rodrigo Siqueira
Where is the commit description. Why is this needed? What is this fixing?
Like Melissa said, this might cause a regression.
Harry
>>
>> Signed-off-by: Rodrigo Siqueira
>> Tested-by: Daniel Wheeler
>> ---
>> drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c
>> b/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c
>> index f8c0cee34080..ed1e2f65f5b5 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c
>> +++ b/drivers/gpu/drm/amd/display/dc/dpp/dcn30/dcn30_dpp.c
>> @@ -395,9 +395,7 @@ void dpp3_set_cursor_attributes(
>> if (color_format == CURSOR_MODE_COLOR_PRE_MULTIPLIED_ALPHA ||
>> color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA) {
>> - if (cursor_attributes->attribute_flags.bits.ENABLE_CURSOR_DEGAMMA) {
>> - cur_rom_en = 1;
>> - }
>> + cur_rom_en = 1;
> ugh. At first glance, I think it will cause a regression with legacy gamma.
>
> For references:
> - https://gitlab.freedesktop.org/drm/amd/-/issues/1513
> - https://lore.kernel.org/amd-gfx/20230731083505.1500965-1-m...@igalia.com/
> - https://lore.kernel.org/amd-gfx/20230824133810.10627-1-m...@igalia.com/
>
> BR,
>
> Melissa
>> }
>> REG_UPDATE_3(CURSOR0_CONTROL,
>
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).
Each DCN pipe has the ability to blend in a cursor early on in the
pipeline. In other words, there are no dedicated cursor planes in DCN,
which makes cursor behavior somewhat unintuitive for compositors.
For example, if the cursor is in RGB format, but the top-most DRM plane
is in YUV format, DCN will not be able to blend them. Because of this,
amdgpu_dm rejects all configurations where a cursor needs to be enabled
on top of a YUV formatted plane.
From a compositor's perspective, when computing an allocation for
hardware plane offloading, this cursor-on-yuv configuration result in an
atomic test failure. Since the failure reason is not obvious at all,
compositors will likely fall back to full rendering, which is not ideal.
Instead, amdgpu_dm can try to accommodate the cursor-on-yuv
configuration by opportunistically reserving a separate DCN pipe just
for the cursor. We can refer to this as "overlay cursor mode". It is
contrasted with "native cursor mode", where the native DCN per-pipe
cursor is used.
[How]
On each crtc, compute whether the cursor plane should be enabled in
overlay mode (which currently, is iff the immediate plane below has a
YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
iff -> if
IIRC another case where this would be needed is when the scale of the
plane below doesn't match the cursor scale. This is especially common
for videos and thus implicitly covered by the YUV check in most cases,
but should probably be made explicit. Michel Dänzer might be able to
comment here.
Another possible case that could be covered here is when some area is
not covered by any plane and just shows a black background. This happens
e.g. if a compositor puts a YUV surface on the primary plane that has a
different width/high ratio than the display. The compositor can add
black bars by just leaving the area uncovered and thus require only a
single hardware plane for video playback ("Unless explicitly specified
(..), the active area of a CRTC will be black by default."
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction). If the cursor is visible over this black bars, AMD currently refuses the commit IIUC (see also Michel Dänzers comment at https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177#note_1924544)
Thanks for mentioning both of these scenarios. I agree it would be
good if we can expand the use of the overlay cursor to these cases.
Harry
Thanks,
Robert Mader
During DC validation, attempt to enable a separate DCN pipe for the
cursor if it's in overlay mode. If that fails, or if no overlay mode is
requested, then fallback to native mode.
Signed-off-by: Leo Li
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
4 files changed, 288 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21a61454c878..09ab330aed17 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* Disable the cursor first if we're disabling all the planes.
* It'll remain on the screen after the planes are re-enabled
* if we don't.
+ *
+ * If the cursor is transitioning from native to overlay mode, the
+ * native cursor needs to be disabled first.
*/
- if (acrtc_state->active_planes == 0)
+ if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
+ struct dc_cursor_position cursor_position = {0};
+ dc_stream_set_cursor_position(acrtc_state->stream,
+ _position);
+ }
+
+ if (acrtc_state->active_planes == 0 &&
+ dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
amdgpu_dm_commit_cursors(state);
/* update planes when needed */
@@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
struct dm_plane_state *dm_new_plane_state =
to_dm_plane_state(new_plane_state);
/* Cursor plane is handled after stream updates */
- if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
if ((fb && crtc == pcrtc) ||
(old_plane_state->fb && old_plane_state->crtc ==
pcrtc))
Re: [PATCH 1/2] drm/amd/display: Introduce overlay cursor mode
On 2024-03-15 13:09, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> DCN is the display hardware for amdgpu. DRM planes are backed by DCN
> hardware pipes, which carry pixel data from one end (memory), to the
> other (output encoder).
>
> Each DCN pipe has the ability to blend in a cursor early on in the
> pipeline. In other words, there are no dedicated cursor planes in DCN,
> which makes cursor behavior somewhat unintuitive for compositors.
>
> For example, if the cursor is in RGB format, but the top-most DRM plane
> is in YUV format, DCN will not be able to blend them. Because of this,
> amdgpu_dm rejects all configurations where a cursor needs to be enabled
> on top of a YUV formatted plane.
>
> From a compositor's perspective, when computing an allocation for
> hardware plane offloading, this cursor-on-yuv configuration result in an
> atomic test failure. Since the failure reason is not obvious at all,
> compositors will likely fall back to full rendering, which is not ideal.
>
> Instead, amdgpu_dm can try to accommodate the cursor-on-yuv
> configuration by opportunistically reserving a separate DCN pipe just
> for the cursor. We can refer to this as "overlay cursor mode". It is
> contrasted with "native cursor mode", where the native DCN per-pipe
> cursor is used.
>
> [How]
>
> On each crtc, compute whether the cursor plane should be enabled in
> overlay mode (which currently, is iff the immediate plane below has a
> YUV format). If it is, mark the CRTC as requesting overlay cursor mode.
>
> During DC validation, attempt to enable a separate DCN pipe for the
> cursor if it's in overlay mode. If that fails, or if no overlay mode is
> requested, then fallback to native mode.
>
> Signed-off-by: Leo Li
We should run this through our usual testing cycle, and I need to go over
it a bit more closely than I have, but I like it, so it's
Acked-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 309 +++---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 1 +
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 13 +-
> 4 files changed, 288 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 21a61454c878..09ab330aed17 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8359,8 +8359,19 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* Disable the cursor first if we're disabling all the planes.
>* It'll remain on the screen after the planes are re-enabled
>* if we don't.
> + *
> + * If the cursor is transitioning from native to overlay mode, the
> + * native cursor needs to be disabled first.
>*/
> - if (acrtc_state->active_planes == 0)
> + if (acrtc_state->cursor_mode == DM_CURSOR_OVERLAY_MODE &&
> + dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
> + struct dc_cursor_position cursor_position = {0};
> + dc_stream_set_cursor_position(acrtc_state->stream,
> + _position);
> + }
> +
> + if (acrtc_state->active_planes == 0 &&
> + dm_old_crtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
> amdgpu_dm_commit_cursors(state);
>
> /* update planes when needed */
> @@ -8374,7 +8385,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> struct dm_plane_state *dm_new_plane_state =
> to_dm_plane_state(new_plane_state);
>
> /* Cursor plane is handled after stream updates */
> - if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> + if (plane->type == DRM_PLANE_TYPE_CURSOR &&
> + acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE) {
> if ((fb && crtc == pcrtc) ||
> (old_plane_state->fb && old_plane_state->crtc ==
> pcrtc))
> cursor_update = true;
> @@ -8727,7 +8739,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* This avoids redundant programming in the case where we're going
>* to be disabling a single plane - those pipes are being disabled.
>*/
> - if (acrtc_state->active_planes)
> + if (acrtc_state->active_planes &&
> + acrtc_state->cursor_mode == DM_CURSOR_NATIVE_MODE)
> amdgpu_dm
Re: [PATCH 2/2] drm/amd/display: Move PRIMARY plane zpos higher
On 2024-03-15 13:09, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> Compositors have different ways of assigning surfaces to DRM planes for
> render offloading. It may decide between various strategies: overlay,
> underlay, or a mix of both
>
> One way for compositors to implement the underlay strategy is to assign
> a higher zpos to the DRM_PRIMARY plane than the DRM_OVERLAY planes,
> effectively turning the DRM_OVERLAY plane into an underlay plane.
>
> Today, amdgpu attaches an immutable zpos of 0 to the DRM_PRIMARY plane.
> This however, is an arbitrary restriction. DCN pipes are general
> purpose, and can be arranged in any z-order. To support compositors
> using this allocation scheme, we can set a non-zero immutable zpos for
> the PRIMARY, allowing the placement of OVERLAYS (mutable zpos range
> 0-254) beneath the PRIMARY.
>
> [How]
>
> Assign a zpos = #no of OVERLAY planes to the PRIMARY plane. Then, clean
> up any assumptions in the driver of PRIMARY plane having the lowest
> zpos.
>
> Signed-off-by: Leo Li
With the typo mentioned below fixes this is
Reviewed-by: Harry Wentland
Before merging we should run a full promotion test (especially the IGT
tests) on it as this could break things in subtle ways.
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 96 ++-
> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 17 +++-
> 2 files changed, 104 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 09ab330aed17..01b00f587701 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -80,6 +80,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -369,6 +370,20 @@ static inline void reverse_planes_order(struct
> dc_surface_update *array_of_surfa
> swap(array_of_surface_update[i], array_of_surface_update[j]);
> }
>
> +/*
> + * DC will program planes with their z-order determined by their ordering
> + * in the dc_surface_updates array. This comparator is used to sort them
> + * by descending zpos.
> + */
> +static int dm_plane_layer_index_cmp(const void *a, const void *b)
> +{
> + const struct dc_surface_update *sa = (struct dc_surface_update *)a;
> + const struct dc_surface_update *sb = (struct dc_surface_update *)b;
> +
> + /* Sort by descending dc_plane layer_index (i.e. normalized_zpos) */
> + return sb->surface->layer_index - sa->surface->layer_index;
> +}
> +
> /**
> * update_planes_and_stream_adapter() - Send planes to be updated in DC
> *
> @@ -393,7 +408,8 @@ static inline bool
> update_planes_and_stream_adapter(struct dc *dc,
> struct dc_stream_update
> *stream_update,
> struct dc_surface_update
> *array_of_surface_update)
> {
> - reverse_planes_order(array_of_surface_update, planes_count);
> + sort(array_of_surface_update, planes_count,
> + sizeof(*array_of_surface_update), dm_plane_layer_index_cmp, NULL);
>
> /*
>* Previous frame finished and HW is ready for optimization.
> @@ -9363,6 +9379,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
> drm_atomic_state *state)
> for (j = 0; j < status->plane_count; j++)
> dummy_updates[j].surface = status->plane_states[0];
>
> + sort(dummy_updates, status->plane_count,
> + sizeof(*dummy_updates), dm_plane_layer_index_cmp, NULL);
>
> mutex_lock(>dc_lock);
> dc_update_planes_and_stream(dm->dc,
> @@ -10097,6 +10115,17 @@ static bool should_reset_plane(struct
> drm_atomic_state *state,
> if (new_crtc_state->color_mgmt_changed)
> return true;
>
> + /*
> + * On zpos change, planes need to be reordered by removing and re-adding
> + * them one by one to the dc state, in order of descending zpos.
> + *
> + * TODO: We can likely skip bandwidth validation if the only thing that
> + * changed about the plane was it'z z-ordering.
> + */
> + if (new_crtc_state->zpos_changed) {
> + return true;
> + }
> +
> if (drm_atomic_crtc_needs_modeset(new_crtc_state))
> return true;
>
> @@ -10509,6 +10538,65 @@ dm_get_plane_scale(struct drm_plane_state
> *plane_state,
> *out_plane_scale_h = plane_state->crtc_h * 1000 / plane_src_h;
> }
>
> +/*
> + * The normalized
Re: [PATCH] drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR
On 2024-01-01 13:28, Joshua Ashton wrote:
> The check for sending the vsc infopacket to the display was gated behind
> PSR (Panel Self Refresh) being enabled.
>
> The vsc infopacket also contains the colorimetry (specifically the
> container color gamut) information for the stream on modern DP.
>
> PSR is typically only supported on mobile phone eDP displays, thus this
> was not getting sent for typical desktop monitors or TV screens.
>
> This functionality is needed for proper HDR10 functionality on DP as it
> wants BT2020 RGB/YCbCr for the container color space.
>
So apparently this caused regressions on some panels. I sent a revert
and we'll need to revisit this.
https://gitlab.freedesktop.org/drm/amd/-/issues/3207
https://gitlab.freedesktop.org/drm/amd/-/issues/3151
> Signed-off-by: Joshua Ashton
>
> Cc: Harry Wentland
> Cc: Xaver Hugl
> Cc: Melissa Wen
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +---
> .../amd/display/modules/info_packet/info_packet.c | 13 -
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 2845c884398e..6dff56408bf4 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6233,8 +6233,9 @@ create_stream_for_sink(struct drm_connector *connector,
>
> if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> mod_build_hf_vsif_infopacket(stream, >vsp_infopacket);
> -
> - if (stream->link->psr_settings.psr_feature_enabled ||
> stream->link->replay_settings.replay_feature_enabled) {
> + else if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT ||
> + stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST ||
> + stream->signal == SIGNAL_TYPE_EDP) {
> //
> // should decide stream support vsc sdp colorimetry capability
> // before building vsc info packet
The use_vsc_sdp_for_colorimetry is being cut off in this patch
since it's not changed. We should add a DPCD revision check to
ensure the panel's revision is >= 1.4. This is what we do on other
OSes and this is likely why we're seeing the regressions in the
freedesktop issues.
> if
> (stream->linkstream->link->dpcd_caps.dprx_feature.bits.VSC_SDP_COLORIMETRY_SUPPORTED)
> stream->use_vsc_sdp_for_colorimetry = true;
> @@ -6250,8 +6251,9 @@ create_stream_for_sink(struct drm_connector *connector,
> if (stream->out_transfer_func->tf == TRANSFER_FUNCTION_GAMMA22)
> tf = TRANSFER_FUNC_GAMMA_22;
> mod_build_vsc_infopacket(stream, >vsc_infopacket,
> stream->output_color_space, tf);
> - aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY;
>
> + if (stream->link->psr_settings.psr_feature_enabled)
> + aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY;
> }
> finish:
> dc_sink_release(sink);
> diff --git a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> index 84f9b412a4f1..738ee763f24a 100644
> --- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> +++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> @@ -147,12 +147,15 @@ void mod_build_vsc_infopacket(const struct
> dc_stream_state *stream,
> }
>
> /* VSC packet set to 4 for PSR-SU, or 2 for PSR1 */
> - if (stream->link->psr_settings.psr_version == DC_PSR_VERSION_SU_1)
> - vsc_packet_revision = vsc_packet_rev4;
> - else if (stream->link->replay_settings.config.replay_supported)
> + if (stream->link->psr_settings.psr_feature_enabled) {
> + if (stream->link->psr_settings.psr_version ==
> DC_PSR_VERSION_SU_1)
> + vsc_packet_revision = vsc_packet_rev4;
> + else if (stream->link->psr_settings.psr_version ==
> DC_PSR_VERSION_1)
> + vsc_packet_revision = vsc_packet_rev2;
> + }
> +
> + if (stream->link->replay_settings.config.replay_supported)
> vsc_packet_revision = vsc_packet_rev4;
> - else if (stream->link->psr_settings.psr_version == DC_PSR_VERSION_1)
> - vsc_packet_revision = vsc_packet_rev2;
>
I'm curious whether this is really needed? The original code
should already do the same, even without the additional
.psr_feature_enabled check.
I'll send a patch that is intended to fix the colorimetry while
trying to avoid the regressions.
Harry
> /* Update to revision 5 for extended colorimetry support */
> if (stream->use_vsc_sdp_for_colorimetry)
Re: [PATCH] drm/amd/display: Get min/max vfreq from display_info
On 2024-03-12 10:58, Alex Deucher wrote:
> On Tue, Mar 12, 2024 at 9:57 AM Harry Wentland wrote:
>>
>> We need the min/max vfreq on the amdgpu_dm_connector in order to
>> program VRR.
>>
>> Fixes: db3e4f1cbb84 ("drm/amd/display: Use freesync when
>> `DRM_EDID_FEATURE_CONTINUOUS_FREQ` found")
>> Signed-off-by: Harry Wentland
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index b1ca0aee0b30..cffb2655177c 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -11278,12 +11278,15 @@ void amdgpu_dm_update_freesync_caps(struct
>> drm_connector *connector,
>>
>> if (is_dp_capable_without_timing_msa(adev->dm.dc,
>> amdgpu_dm_connector)) {
>> - if (edid->features &
>> DRM_EDID_FEATURE_CONTINUOUS_FREQ)
>> + if (edid->features &
>> DRM_EDID_FEATURE_CONTINUOUS_FREQ) {
>> freesync_capable = true;
>> - else
>> + amdgpu_dm_connector->min_vfreq =
>> connector->display_info.monitor_range.min_vfreq;
>> + amdgpu_dm_connector->max_vfreq =
>> connector->display_info.monitor_range.max_vfreq;
>
> Does this need special handling for DRM_EDID_RANGE_OFFSET_MIN_VFREQ
> and DRM_EDID_RANGE_OFFSET_MAX_VFREQ as well (similar to the code below
> it)?
>
get_monitor_range in drm_edid.c already handles it. I'm actually wondering
if the "else" and "edid_check_required" case is still required now, as it
essentially just duplicates the drm_edid code. But I don't want to rip it
out in the same patch and without a bit of testing.
Harry
> Alex
>
>> + } else {
>> edid_check_required = edid->version > 1 ||
>> (edid->version == 1 &&
>>edid->revision > 1);
>> + }
>> }
>>
>> if (edid_check_required) {
>> --
>> 2.44.0
>>
[PATCH] Revert "drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR"
This causes flicker on a bunch of eDP panels. The info_packet code
also caused regressions on other OSes that we haven't' seen on Linux
yet, but that is likely due to the fact that we haven't had a chance
to test those environments on Linux.
We'll need to revisit this.
This reverts commit bfd4e0b7eb4467f9db5bb37268565afec6cf513e.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3207
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3151
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +++-
.../amd/display/modules/info_packet/info_packet.c | 13 +
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cffb2655177c..6a61eb4148ad 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6302,9 +6302,8 @@ create_stream_for_sink(struct drm_connector *connector,
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
mod_build_hf_vsif_infopacket(stream, >vsp_infopacket);
- else if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT ||
-stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST ||
-stream->signal == SIGNAL_TYPE_EDP) {
+
+ if (stream->link->psr_settings.psr_feature_enabled ||
stream->link->replay_settings.replay_feature_enabled) {
//
// should decide stream support vsc sdp colorimetry capability
// before building vsc info packet
@@ -6320,9 +6319,8 @@ create_stream_for_sink(struct drm_connector *connector,
if (stream->out_transfer_func->tf == TRANSFER_FUNCTION_GAMMA22)
tf = TRANSFER_FUNC_GAMMA_22;
mod_build_vsc_infopacket(stream, >vsc_infopacket,
stream->output_color_space, tf);
+ aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY;
- if (stream->link->psr_settings.psr_feature_enabled)
- aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY;
}
finish:
dc_sink_release(sink);
diff --git a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
index 738ee763f24a..84f9b412a4f1 100644
--- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
+++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
@@ -147,15 +147,12 @@ void mod_build_vsc_infopacket(const struct
dc_stream_state *stream,
}
/* VSC packet set to 4 for PSR-SU, or 2 for PSR1 */
- if (stream->link->psr_settings.psr_feature_enabled) {
- if (stream->link->psr_settings.psr_version ==
DC_PSR_VERSION_SU_1)
- vsc_packet_revision = vsc_packet_rev4;
- else if (stream->link->psr_settings.psr_version ==
DC_PSR_VERSION_1)
- vsc_packet_revision = vsc_packet_rev2;
- }
-
- if (stream->link->replay_settings.config.replay_supported)
+ if (stream->link->psr_settings.psr_version == DC_PSR_VERSION_SU_1)
vsc_packet_revision = vsc_packet_rev4;
+ else if (stream->link->replay_settings.config.replay_supported)
+ vsc_packet_revision = vsc_packet_rev4;
+ else if (stream->link->psr_settings.psr_version == DC_PSR_VERSION_1)
+ vsc_packet_revision = vsc_packet_rev2;
/* Update to revision 5 for extended colorimetry support */
if (stream->use_vsc_sdp_for_colorimetry)
--
2.44.0
[PATCH] drm/amd/display: Get min/max vfreq from display_info
We need the min/max vfreq on the amdgpu_dm_connector in order to
program VRR.
Fixes: db3e4f1cbb84 ("drm/amd/display: Use freesync when
`DRM_EDID_FEATURE_CONTINUOUS_FREQ` found")
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b1ca0aee0b30..cffb2655177c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -11278,12 +11278,15 @@ void amdgpu_dm_update_freesync_caps(struct
drm_connector *connector,
if (is_dp_capable_without_timing_msa(adev->dm.dc,
amdgpu_dm_connector)) {
- if (edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ)
+ if (edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ) {
freesync_capable = true;
- else
+ amdgpu_dm_connector->min_vfreq =
connector->display_info.monitor_range.min_vfreq;
+ amdgpu_dm_connector->max_vfreq =
connector->display_info.monitor_range.max_vfreq;
+ } else {
edid_check_required = edid->version > 1 ||
(edid->version == 1 &&
edid->revision > 1);
+ }
}
if (edid_check_required) {
--
2.44.0
Re: [PATCH v2] drm/amd/display: Use freesync when `DRM_EDID_FEATURE_CONTINUOUS_FREQ` found
On 2024-03-08 14:40, Mario Limonciello wrote:
The monitor shipped with the Framework 16 supports VRR [1], but it's not
being advertised.
This is because the detailed timing block doesn't contain
`EDID_DETAIL_MONITOR_RANGE` which amdgpu looks for to find min and max
frequencies. This check however is superfluous for this case because
update_display_info() calls drm_get_monitor_range() to get these ranges
already.
So if the `DRM_EDID_FEATURE_CONTINUOUS_FREQ` EDID feature is found then
turn on freesync without extra checks.
Closes:
https://www.reddit.com/r/framework/comments/1b4y2i5/no_variable_refresh_rate_on_the_framework_16_on/
Closes:
https://www.reddit.com/r/framework/comments/1b6vzcy/framework_16_variable_refresh_rate/
Closes:
https://community.frame.work/t/resolved-no-vrr-freesync-with-amd-version/42338
Link: https://gist.github.com/superm1/e8fbacfa4d0f53150231d3a3e0a13faf
Signed-off-by: Mario Limonciello
Reviewed-by: Harry Wentland
Harry
---
v1->v2:
* Use is_dp_capable_without_timing_msa() as well for new case
* Move edid checks up a level
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5b7293da5453..4e1633a18f2c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -11233,18 +11233,21 @@ void amdgpu_dm_update_freesync_caps(struct
drm_connector *connector,
if (!adev->dm.freesync_module)
goto update;
- if (sink->sink_signal == SIGNAL_TYPE_DISPLAY_PORT
- || sink->sink_signal == SIGNAL_TYPE_EDP) {
+ if (edid && (sink->sink_signal == SIGNAL_TYPE_DISPLAY_PORT ||
+sink->sink_signal == SIGNAL_TYPE_EDP)) {
bool edid_check_required = false;
- if (edid) {
- edid_check_required = is_dp_capable_without_timing_msa(
- adev->dm.dc,
- amdgpu_dm_connector);
+ if (is_dp_capable_without_timing_msa(adev->dm.dc,
+amdgpu_dm_connector)) {
+ if (edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ)
+ freesync_capable = true;
+ else
+ edid_check_required = edid->version > 1 ||
+ (edid->version == 1 &&
+ edid->revision > 1);
}
- if (edid_check_required == true && (edid->version > 1 ||
- (edid->version == 1 && edid->revision > 1))) {
+ if (edid_check_required) {
for (i = 0; i < 4; i++) {
timing = >detailed_timings[i];
Re: [PATCH] drm/amd/display: Use freesync when `DRM_EDID_FEATURE_CONTINUOUS_FREQ` found
On 2024-03-05 15:57, Mario Limonciello wrote:
The monitor shipped with the Framework 16 supports VRR [1], but it's not
being advertised.
This is because the detailed timing block doesn't contain
`EDID_DETAIL_MONITOR_RANGE` which amdgpu looks for to find min and max
frequencies. This check however is superfluous for this case because
update_display_info() calls drm_get_monitor_range() to get these ranges
already.
So if the `DRM_EDID_FEATURE_CONTINUOUS_FREQ` EDID feature is found then
turn on freesync without extra checks.
Closes:
https://www.reddit.com/r/framework/comments/1b4y2i5/no_variable_refresh_rate_on_the_framework_16_on/
Closes:
https://www.reddit.com/r/framework/comments/1b6vzcy/framework_16_variable_refresh_rate/
Closes:
https://community.frame.work/t/resolved-no-vrr-freesync-with-amd-version/42338
Link: https://gist.github.com/superm1/e8fbacfa4d0f53150231d3a3e0a13faf [1]
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5b7293da5453..38186d669a85 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -11238,9 +11238,12 @@ void amdgpu_dm_update_freesync_caps(struct
drm_connector *connector,
bool edid_check_required = false;
if (edid) {
- edid_check_required = is_dp_capable_without_timing_msa(
- adev->dm.dc,
- amdgpu_dm_connector);
+ if (edid->features & DRM_EDID_FEATURE_CONTINUOUS_FREQ)
+ freesync_capable = true;
We still need to check that the DP RX is capable of being
driven without MSA, i.e., we should do
freesync_capable = is_dp_capable_without_timing_msa(...)
Harry
+ else
+ edid_check_required =
is_dp_capable_without_timing_msa(
+ adev->dm.dc,
+ amdgpu_dm_connector);
}
if (edid_check_required == true && (edid->version > 1 ||
Re: [PATCH] drm/amd: Drop abm_level property
On 2024-03-06 13:02, Mario Limonciello wrote: > On 3/6/2024 12:00, Xaver Hugl wrote: >> Am Mi., 6. März 2024 um 18:19 Uhr schrieb Mario Limonciello >> : >>> So the idea being if the compositor isn't using it we let >>> power-profiles-daemon (or any other software) take control via sysfs and >>> if the compositor does want to control it then it then it writes a DRM >>> cap and we destroy the sysfs file? >> >> Yes. That way still only one party controls it at a given time, and we >> can get both good default behavior for display servers that don't care >> (like Xorg or compositors without color management support), and >> compositors that want to put in the effort can do more specific things >> with it. > > I think that's a very good solution. > > Harry, Hamza, what do you guys think? In theory I like it. But how will this look in practice? Is PPD or compositor on the scene first? Would it be possible to yank the sysfs away from PPD? DRM client caps are set by the client when the client interacts with DRM. At driver creation there is no client. How will the driver set things up? A user might switch between DRM clients (login manager, to desktop compositor, maybe to another VT with a different compositor). I know everything but the login manager to desktop compositor hand-off is today considered exotic, but what if someone starts building a use-case for it? I've done a bunch of gamescope or IGT work in a different VT while I've had Plasma running on its default VT. If someone can sketch this out, with answers to all the questions above and any other questions you can come up (be creative), I'd be happy to review. Alternatively we can discuss this at the hackfest and maybe arrive at a solution. Harry
Re: [PATCH] drm/amd/display: handle range offsets in VRR ranges
On 2024-03-01 08:55, Alex Deucher wrote:
> Ping?
>
> On Wed, Feb 28, 2024 at 4:12 PM Alex Deucher
> wrote:
>>
>> Need to check the offset bits for values greater than 255.
>>
>> v2: also update amdgpu_dm_connector values.
>>
>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3203
>> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
>> 1 file changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 32efce81a5a74..4e4cbf2e33dd2 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -11292,14 +11292,23 @@ void amdgpu_dm_update_freesync_caps(struct
>> drm_connector *connector,
>> if (range->flags != 1)
>> continue;
>>
>> - amdgpu_dm_connector->min_vfreq =
>> range->min_vfreq;
>> - amdgpu_dm_connector->max_vfreq =
>> range->max_vfreq;
>> - amdgpu_dm_connector->pixel_clock_mhz =
>> - range->pixel_clock_mhz * 10;
>> -
>>
>> connector->display_info.monitor_range.min_vfreq = range->min_vfreq;
>>
>> connector->display_info.monitor_range.max_vfreq = range->max_vfreq;
>>
>> + if (edid->revision >= 4) {
>> + if (data->pad2 &
>> DRM_EDID_RANGE_OFFSET_MIN_VFREQ)
>> +
>> connector->display_info.monitor_range.min_vfreq += 255;
>> + if (data->pad2 &
>> DRM_EDID_RANGE_OFFSET_MAX_VFREQ)
>> +
>> connector->display_info.monitor_range.max_vfreq += 255;
>> + }
>> +
>> + amdgpu_dm_connector->min_vfreq =
>> +
>> connector->display_info.monitor_range.min_vfreq;
>> + amdgpu_dm_connector->max_vfreq =
>> +
>> connector->display_info.monitor_range.max_vfreq;
>> + amdgpu_dm_connector->pixel_clock_mhz =
>> + range->pixel_clock_mhz * 10;
>> +
>> break;
>> }
>>
>> --
>> 2.44.0
>>
Re: [PATCH] drm/amd/display: Add monitor patch for specific eDP
On 2024-02-27 13:18, Rodrigo Siqueira wrote:
> From: Ivan Lipski
>
> [WHY]
> Some eDP panels's ext caps don't write initial value cause the value of
> dpcd_addr(0x317) is random. It means that sometimes the eDP will
> clarify it is OLED, miniLED...etc cause the backlight control interface
> is incorrect.
>
> [HOW]
> Add a new panel patch to remove sink ext caps(HDR,OLED...etc)
>
> Cc: sta...@vger.kernel.org # 6.5.x
> Cc: Hamza Mahfooz
> Cc: Tsung-hua Lin
> Cc: Chris Chi
> Cc: Harry Wentland
> Tested-by: Daniel Wheeler
> Reviewed-by: Sun peng Li
> Acked-by: Rodrigo Siqueira
> Signed-off-by: Ivan Lipski
Acked-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index d9a482908380..764dc3ffd91b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -63,6 +63,12 @@ static void apply_edid_quirks(struct edid *edid, struct
> dc_edid_caps *edid_caps)
> DRM_DEBUG_DRIVER("Disabling FAMS on monitor with panel id
> %X\n", panel_id);
> edid_caps->panel_patch.disable_fams = true;
> break;
> + /* Workaround for some monitors that do not clear DPCD 0x317 if
> FreeSync is unsupported */
> + case drm_edid_encode_panel_id('A', 'U', 'O', 0xA7AB):
> + case drm_edid_encode_panel_id('A', 'U', 'O', 0xE69B):
> + DRM_DEBUG_DRIVER("Clearing DPCD 0x317 on monitor with panel id
> %X\n", panel_id);
> + edid_caps->panel_patch.remove_sink_ext_caps = true;
> + break;
> default:
> return;
> }
Re: [RFC PATCH v4 06/42] drm/vkms: Add kunit tests for VKMS LUT handling
On 2024-02-27 07:14, Arthur Grillo wrote:
>
>
> On 26/02/24 18:10, Harry Wentland wrote:
>> Debugging LUT math is much easier when we can unit test
>> it. Add kunit functionality to VKMS and add tests for
>> - get_lut_index
>> - lerp_u16
>>
>> v4:
>> - Test the critical points of the lerp function (Pekka)
>>
>> v3:
>> - Use include way of testing static functions (Arthur)
>>
>> Signed-off-by: Harry Wentland
>> Cc: Arthur Grillo
>> ---
>> drivers/gpu/drm/vkms/Kconfig | 5 +
>> drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
>> drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 163 ++
>> drivers/gpu/drm/vkms/vkms_composer.c | 8 +-
>> 4 files changed, 178 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
>> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>>
>> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
>> index b9ecdebecb0b..c1f8b343ff0e 100644
>> --- a/drivers/gpu/drm/vkms/Kconfig
>> +++ b/drivers/gpu/drm/vkms/Kconfig
>> @@ -13,3 +13,8 @@ config DRM_VKMS
>>a VKMS.
>>
>>If M is selected the module will be called vkms.
>> +
>> +config DRM_VKMS_KUNIT_TESTS
>> +tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
>> +depends on DRM_VKMS && KUNIT
>> +default KUNIT_ALL_TESTS
>> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig
>> b/drivers/gpu/drm/vkms/tests/.kunitconfig
>> new file mode 100644
>> index ..70e378228cbd
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
>> @@ -0,0 +1,4 @@
>> +CONFIG_KUNIT=y
>> +CONFIG_DRM=y
>> +CONFIG_DRM_VKMS=y
>> +CONFIG_DRM_VKMS_KUNIT_TESTS=y
>> diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> new file mode 100644
>> index ..fc73e48aa57c
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>> @@ -0,0 +1,163 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +
>> +#include
>> +
>> +#include
>> +
>> +#define TEST_LUT_SIZE 16
>> +
>> +static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
>> +{ 0x0, 0x0, 0x0, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +{ 0x, 0x, 0x, 0 },
>> +};
>> +
>> +const struct vkms_color_lut test_linear_lut = {
>> +.base = test_linear_array,
>> +.lut_length = TEST_LUT_SIZE,
>> +.channel_value2index_ratio = 0xf000fll
>> +};
>> +
>> +
>> +static void vkms_color_test_get_lut_index(struct kunit *test)
>> +{
>> +int i;
>> +
>> +KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_linear_lut,
>> test_linear_array[0].red)), 0);
>> +
>> +for (i = 0; i < TEST_LUT_SIZE; i++)
>> +KUNIT_EXPECT_EQ(test,
>> drm_fixp2int_ceil(get_lut_index(_linear_lut,
>> test_linear_array[i].red)), i);
>> +}
>> +
>> +static void vkms_color_test_lerp(struct kunit *test)
>> +{
>> +/*** half-way round down ***/
>> +s64 t = 0x8000 - 1;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
>> +
>> +/* odd a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x8);
>> +
>> +/* odd b */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
>> +
>> +/* b = a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
>> +
>> +/* b = a + 1 */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x10);
>> +
>> +
>> +/*** half-way round up ***/
>> +t = 0x8000;
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
>> +
>> +/* odd a */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x9);
>> +
>> +/* odd b */
>> +KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
>&
Re: [RFC PATCH v4 00/42] Color Pipeline API w/ VKMS
On 2024-02-27 05:26, Joshua Ashton wrote: > > > On 2/26/24 21:10, Harry Wentland wrote: >> This is an RFC set for a color pipeline API, along with a sample >> implementation in VKMS. All the key API bits are here. VKMS now >> supports two named transfer function colorops and two matrix >> colorops. We have IGT tests that check all four of these colorops >> with a pixel-by-pixel comparison that checks that these colorops >> do what we expect them to do with a +/- 1 8 bpc code point margin. >> >> The big new change with v4 is the addition of an amdgpu color >> pipeline, for all AMD GPUs with DCN 3 and newer. Amdgpu now support >> the following: >> >> 1. 1D Curve EOTF >> 2. 3x4 CTM >> 3. Multiplier >> 4. 1D Curve Inverse EOTF >> 5. 1D LUT >> 6. 1D Curve EOTF >> 7. 1D LUT >> >> The supported curves for the 1D Curve type are: >> - sRGB EOTF and its inverse >> - PQ EOTF, scaled to [0.0, 125.0] and its inverse >> - BT.2020/BT.709 OETF and its inverse >> >> Note that the 1st and 5th colorops take the EOTF or Inverse >> OETF while the 3rd colorop takes the Inverse EOTF or OETF. >> >> We are working on two more ops for amdgpu, the HDR multiplier >> and the 3DLUT, which will give us this: >> >> 1. 1D Curve EOTF >> 2. 3x4 CTM >> 3. HDR Multiplier >> 4. 1D Curve Inverse EOTF >> 5. 1D LUT >> 6. 3D LUT >> 7. 1D Curve EOTF >> 8. 1D LUT >> >> This, essentially mirrors the color pipeline used by gamescope >> and presented by Melissa Wen, with the exception of the DEGAM >> LUT, which is not currently used. See >> [1] >> https://indico.freedesktop.org/event/4/contributions/186/attachments/138/218/xdc2023-TheRainbowTreasureMap-MelissaWen.pdf >> >> After this we'd like to also add the following ops: >> - Scaler (Informational only) > > Why informational only? Having NEAREST and in general custom taps should be > possible on AMDGPU right? > > We don't have to solve this now, but I just want to make sure that we aren't > locking this to info only. > No, this isn't locking it to information only. We could allow for NEAREST or even custom taps in the future. Just don't want to open that debate now if we don't have a good reason to. Harry > Thanks > > - Joshie ✨ > >> - Color Encoding, to replace drm_plane's COLOR_ENCODING >> - Color Range, to replace drm_plane's COLOR_RANGE >> >> This patchset is grouped as follows: >> - Patches 1-3: couple general patches/fixes >> - Patches 4-7: introduce kunit to VKMS >> - Patch 7: description of motivation and details behind the >> Color Pipeline API. If you're reading nothing else >> but are interested in the topic I highly recommend >> you take a look at this. >> - Patches 7-27: DRM core and VKMS changes for color pipeline API >> - Patches 28-40: DRM core and amdgpu changes for color pipeline API >> >> VKMS patches could still be improved in a few ways, though the >> payoff might be limited and I would rather focus on other work >> at the moment. The most obvious thing to improve would be to >> eliminate the hard-coded LUTs for identity, and sRGB, and replace >> them with fixed-point math instead. >> >> There are plenty of things that I would like to see here but >> haven't had a chance to look at. These will (hopefully) be >> addressed in future iterations, either in VKMS or amdgpu: >> - Clear documentation for each drm_colorop_type >> - Add custom LUT colorops to VKMS >> - Add pre-blending 3DLUT >> - How to support HW which can't bypass entire pipeline? >> - Add ability to create colorops that don't have BYPASS >> - Can we do a LOAD / COMMIT model for LUTs (and other properties)? >> - read-only scaling colorop which defines scaling taps and position >> - read-only color format colorop to define supported color formats >> for a pipeline >> - named matrices, for things like converting YUV to RGB >> >> IGT tests can be found at >> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 >> >> IGT patches are also being sent to the igt-dev mailing list. >> >> If you prefer a gitlab MR for review you can find it at >> https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 >> >> v4: >> - Add amdgpu color pipeline (WIP) >> - Don't block setting of deprecated properties, instead pass client cap >> to atomic check so drivers can ignore these props >> - Drop IOCTL definitions (Pekka) >&
[RFC PATCH v4 38/42] drm/colorop: Add 1D Curve Custom LUT type
From: Alex Hung
We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.
This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a SIZE property which
is used by a driver to advertise the supported SIZE
of the LUT, as well as a DATA property which userspace
uses to set the LUT.
DATA and size function in the same way as current drm_crtc
GAMMA and DEGAMMA LUTs.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 5 +
drivers/gpu/drm/drm_colorop.c | 36 +--
include/drm/drm_colorop.h | 16 ++
include/uapi/drm/drm_mode.h | 1 +
5 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6e736ffa6d7c..f7d51839ca03 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -799,6 +799,10 @@ static void drm_atomic_colorop_print_state(struct
drm_printer *p,
drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
break;
+ case DRM_COLOROP_1D_LUT:
+ drm_printf(p, "\tsize=%d\n", state->size);
+ drm_printf(p, "\tdata blob id=%d\n", state->data ?
state->data->base.id : 0);
+ break;
case DRM_COLOROP_CTM_3X4:
drm_printf(p, "\tdata blob id=%d\n", state->data ?
state->data->base.id : 0);
break;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c7c1c614b0d9..6bfe857720cd 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -700,6 +700,9 @@ static int drm_atomic_color_set_data_property(struct
drm_colorop *colorop,
bool replaced = false;
switch (colorop->type) {
+ case DRM_COLOROP_1D_LUT:
+ size = state->size * sizeof(struct drm_color_lut);
+ break;
case DRM_COLOROP_CTM_3X4:
size = sizeof(struct drm_color_ctm_3x4);
break;
@@ -749,6 +752,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+ } else if (property == colorop->size_property) {
+ *val = state->size;
} else if (property == colorop->data_property) {
*val = (state->data) ? state->data->base.id : 0;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index b10cad5a7208..4452eaeeb242 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -34,6 +34,7 @@
static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
+ { DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
{ DRM_COLOROP_CTM_3X4, "3x4 Matrix"}
};
@@ -175,11 +176,41 @@ static int drm_colorop_create_data_prop(struct drm_device
*dev, struct drm_color
colorop->data_property = prop;
drm_object_attach_property(>base,
- colorop->data_property,
- 0);
+ colorop->data_property,
+ 0);
return 0;
}
+int drm_colorop_curve_1d_lut_init(struct drm_device *dev, struct drm_colorop
*colorop,
+ struct drm_plane *plane, uint32_t lut_size)
+{
+ struct drm_property *prop;
+ int ret;
+
+ ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_1D_LUT);
+ if (ret)
+ return ret;
+
+ /* initialize 1D LUT only attribute */
+ /* LUT size */
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC, "SIZE",
lut_size, lut_size);
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->size_property = prop;
+ drm_object_attach_property(>base, colorop->size_property, 0);
+
+ /* data */
+ ret = drm_colorop_create_data_prop(dev, colorop);
+ if (ret)
+ return ret;
+
+ drm_colorop_reset(colorop);
+ colorop->state->size = lut_size;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_colorop_curve_1d_lut_init);
int drm_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop
*colorop,
struct drm_plane *plane)
@@ -301,6 +332,7 @@ EXPORT_SYMBOL(drm_colorop_reset);
static const char * const colorop_type_name[]
[RFC PATCH v4 33/42] drm/amd/display: Add support for sRGB EOTF in BLND block
From: Alex Hung
Expose a 3rd 1D curve colorop, with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block
to perform the sRGB transform when the colorop is not in
bypass
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb_eotf
The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support
3. 1D curve colorop w/ sRGB EOTF support
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 77 +++
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 18 +
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.h | 1 +
3 files changed, 96 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 8788cfd26abd..3e3ae2b58b06 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1267,6 +1267,72 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state
*plane_state,
return __set_colorop_in_shaper_1d_curve(dc_plane_state, colorop_state);
}
+
+static int
+__set_colorop_1d_curve_blend_tf_lut(struct dc_plane_state *dc_plane_state,
+ struct drm_colorop_state *colorop_state)
+{
+
+ struct dc_transfer_func *tf = dc_plane_state->blend_tf;
+ struct drm_colorop *colorop = colorop_state->colorop;
+ struct drm_device *drm = colorop->dev;
+ const struct drm_color_lut *blend_lut;
+ uint32_t blend_size;
+
+ if (colorop->type != DRM_COLOROP_1D_CURVE &&
+ colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+ return -EINVAL;
+
+ if (colorop_state->bypass) {
+ tf->type = TF_TYPE_BYPASS;
+ tf->tf = TRANSFER_FUNCTION_LINEAR;
+ return 0;
+ }
+
+ drm_dbg(drm, "Blend colorop with ID: %d\n", colorop->base.id);
+
+ if (colorop->type == DRM_COLOROP_1D_CURVE) {
+ tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+ tf->tf =
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+ tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
+ return __set_input_tf(NULL, tf, blend_lut, blend_size);
+ }
+
+ return -EINVAL;
+}
+
+static int
+__set_dm_plane_colorop_blend(struct drm_plane_state *plane_state,
+struct dc_plane_state *dc_plane_state,
+struct drm_colorop *colorop)
+{
+ struct drm_colorop *old_colorop;
+ struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+ struct drm_atomic_state *state = plane_state->state;
+ int i = 0;
+
+ old_colorop = colorop;
+
+ /* 3nd op: 1d curve - blend */
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+
+ if (new_colorop_state->colorop == old_colorop) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+ }
+
+ if (!colorop_state)
+ return -EINVAL;
+
+ return __set_colorop_1d_curve_blend_tf_lut(dc_plane_state,
colorop_state);
+}
+
static int
amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state)
@@ -1345,6 +1411,17 @@ amdgpu_dm_plane_set_colorop_properties(struct
drm_plane_state *plane_state,
if (ret)
return ret;
+ /* 1D Curve - BLND TF */
+ colorop = colorop->next;
+ if (!colorop) {
+ drm_dbg(dev, "no Blend TF colorop found\n");
+ return -EINVAL;
+ }
+
+ ret = __set_dm_plane_colorop_blend(plane_state, dc_plane_state,
colorop);
+ if (ret)
+ return ret;
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 0d1626abf577..449a2ad6a184 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -37,6 +37,9 @@ const u64 amdgpu_dm_supported_degam_tfs =
const u64 amdgpu_dm_supported_shaper_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
+const u64 amdgpu_dm_supported_blnd_tfs =
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
+
int amdgpu_dm_initialize_default_pipeline(struct drm_plane *p
[RFC PATCH v4 08/42] drm/doc/rfc: Describe why prescriptive color pipeline is needed
v4: - Drop IOCTL docs since we dropped the IOCTLs (Pekka) - Clarify reading and setting of COLOR_PIPELINE prop (Pekka) - Add blurb about not requiring to reject a pipeline due to incompatible ops, as long as op can be bypassed (Pekka) - Dropped informational strings (such as input CSC) as they're not actually intended to be advertised (Pekka) v3: - Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian) - Ask for clear documentation of colorop behavior (Sebastian) v2: - Update colorop visualizations to match reality (Sebastian, Alex Hung) - Updated wording (Pekka) - Change BYPASS wording to make it non-mandatory (Sebastian) - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property section (Pekka) - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa) - Add "Driver Implementer's Guide" section (Pekka) - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) Signed-off-by: Harry Wentland --- Documentation/gpu/rfc/color_pipeline.rst | 360 +++ 1 file changed, 360 insertions(+) create mode 100644 Documentation/gpu/rfc/color_pipeline.rst diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst new file mode 100644 index ..6c653e17054a --- /dev/null +++ b/Documentation/gpu/rfc/color_pipeline.rst @@ -0,0 +1,360 @@ + +Linux Color Pipeline API + + +What problem are we solving? + + +We would like to support pre-, and post-blending complex color +transformations in display controller hardware in order to allow for +HW-supported HDR use-cases, as well as to provide support to +color-managed applications, such as video or image editors. + +It is possible to support an HDR output on HW supporting the Colorspace +and HDR Metadata drm_connector properties, but that requires the +compositor or application to render and compose the content into one +final buffer intended for display. Doing so is costly. + +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other +operations to support color transformations. These operations are often +implemented in fixed-function HW and therefore much more power efficient than +performing similar operations via shaders or CPU. + +We would like to make use of this HW functionality to support complex color +transformations with no, or minimal CPU or shader load. + + +How are other OSes solving this problem? + + +The most widely supported use-cases regard HDR content, whether video or +gaming. + +Most OSes will specify the source content format (color gamut, encoding transfer +function, and other metadata, such as max and average light levels) to a driver. +Drivers will then program their fixed-function HW accordingly to map from a +source content buffer's space to a display's space. + +When fixed-function HW is not available the compositor will assemble a shader to +ask the GPU to perform the transformation from the source content format to the +display's format. + +A compositor's mapping function and a driver's mapping function are usually +entirely separate concepts. On OSes where a HW vendor has no insight into +closed-source compositor code such a vendor will tune their color management +code to visually match the compositor's. On other OSes, where both mapping +functions are open to an implementer they will ensure both mappings match. + +This results in mapping algorithm lock-in, meaning that no-one alone can +experiment with or introduce new mapping algorithms and achieve +consistent results regardless of which implementation path is taken. + +Why is Linux different? +=== + +Unlike other OSes, where there is one compositor for one or more drivers, on +Linux we have a many-to-many relationship. Many compositors; many drivers. +In addition each compositor vendor or community has their own view of how +color management should be done. This is what makes Linux so beautiful. + +This means that a HW vendor can now no longer tune their driver to one +compositor, as tuning it to one could make it look fairly different from +another compositor's color mapping. + +We need a better solution. + + +Descriptive API +=== + +An API that describes the source and destination colorspaces is a descriptive +API. It describes the input and output color spaces but does not describe +how precisely they should be mapped. Such a mapping includes many minute +design decision that can greatly affect the look of the final result. + +It is not feasible to describe such mapping with enough detail to ensure the +same result from each implementation. In fact, these mappings are a very active +research area. + + +Prescriptive API + + +A prescriptive API describes not the source and destination colorspaces. It +instead prescribes a recipe for how to manipulate pi
[RFC PATCH v4 02/42] drm: Add helper for conversion from signed-magnitude
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Signed-off-by: Harry Wentland
---
include/drm/drm_fixed.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 0c9f917a4d4b..cb842ba80ddd 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -78,6 +78,24 @@ static inline u32 dfixed_div(fixed20_12 A, fixed20_12 B)
#define DRM_FIXED_EPSILON 1LL
#define DRM_FIXED_ALMOST_ONE (DRM_FIXED_ONE - DRM_FIXED_EPSILON)
+/**
+ * @drm_sm2fixp
+ *
+ * Convert a 1.31.32 signed-magnitude fixed point to 32.32
+ * 2s-complement fixed point
+ *
+ * @return s64 2s-complement fixed point
+ */
+static inline s64 drm_sm2fixp(__u64 a)
+{
+ if ((a & (1LL << 63))) {
+ return -(a & 0x7fffll);
+ } else {
+ return a;
+ }
+
+}
+
static inline s64 drm_int2fixp(int a)
{
return ((s64)a) << DRM_FIXED_POINT;
--
2.44.0
[RFC PATCH v4 29/42] drm/amd/display: Add bypass COLOR PIPELINE
Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 8a4c40b4c27e..c5c07b4cd6c9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1651,6 +1651,20 @@ dm_atomic_plane_get_property(struct drm_plane *plane,
}
#endif
+#define MAX_COLOR_PIPELINES 5
+
+static int
+dm_plane_init_colorops(struct drm_plane *plane)
+{
+ struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
+ int len = 0;
+
+ /* Create COLOR_PIPELINE property and attach */
+ drm_plane_create_color_pipeline_property(plane, pipelines, len);
+
+ return 0;
+}
+
static const struct drm_plane_funcs dm_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -1744,7 +1758,12 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager
*dm,
#ifdef AMD_PRIVATE_COLOR
dm_atomic_plane_attach_color_mgmt_properties(dm, plane);
+#else
+ res = dm_plane_init_colorops(plane);
+ if (res)
+ return res;
#endif
+
/* Create (reset) the plane state */
if (plane->funcs->reset)
plane->funcs->reset(plane);
--
2.44.0
[RFC PATCH v4 27/42] drm/colorop: define a new macro for_each_new_colorop_in_state
From: Alex Hung Create a new macro for_each_new_colorop_in_state to access new drm_colorop_state updated from uapi. Signed-off-by: Alex Hung --- include/drm/drm_atomic.h | 20 1 file changed, 20 insertions(+) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 61e6b5553eec..a4c5ff99a515 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -979,6 +979,26 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (new_colorop_state) = (__state)->colorops[__i].new_state, 1)) +/** + * for_each_new_colorop_in_state - iterate over all colorops in an atomic update + * @__state: drm_atomic_state pointer + * @colorop: drm_colorop iteration cursor + * @new_colorop_state: drm_colorop_state iteration cursor for the new state + * @__i: int iteration cursor, for macro-internal use + * + * This iterates over all colorops in an atomic update, tracking new state. This is + * useful is useful in places where the state delta needs to be considered, for + * example in atomic check functions. + */ +#define for_each_new_colorop_in_state(__state, colorop, new_colorop_state, __i) \ + for ((__i) = 0; \ +(__i) < (__state)->dev->mode_config.num_colorop; \ +(__i)++) \ + for_each_if ((__state)->colorops[__i].ptr &&\ +((colorop) = (__state)->colorops[__i].ptr, \ + (void)(colorop) /* Only to avoid unused-but-set-variable warning */, \ + (new_colorop_state) = (__state)->colorops[__i].new_state, 1)) + /** * for_each_oldnew_plane_in_state - iterate over all planes in an atomic update * @__state: drm_atomic_state pointer -- 2.44.0
[RFC PATCH v4 30/42] drm/amd/display: Skip color pipeline initialization for cursor plane
From: Alex Hung Signed-off-by: Alex Hung --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c index c5c07b4cd6c9..d3f64f586243 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c @@ -1659,6 +1659,9 @@ dm_plane_init_colorops(struct drm_plane *plane) struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES]; int len = 0; + if (plane->type == DRM_PLANE_TYPE_CURSOR) + return 0; + /* Create COLOR_PIPELINE property and attach */ drm_plane_create_color_pipeline_property(plane, pipelines, len); -- 2.44.0
[RFC PATCH v4 32/42] drm/amd/display: Add support for sRGB Inverse EOTF in SHAPER block
From: Alex Hung
Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.
With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf
The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 76 +++
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 20 -
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.h | 1 +
3 files changed, 96 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 3ec759934669..8788cfd26abd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1203,6 +1203,70 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
}
+static int
+__set_colorop_in_shaper_1d_curve(struct dc_plane_state *dc_plane_state,
+ struct drm_colorop_state *colorop_state)
+{
+ struct dc_transfer_func *tf = dc_plane_state->in_shaper_func;
+ struct drm_colorop *colorop = colorop_state->colorop;
+ struct drm_device *drm = colorop->dev;
+ const struct drm_color_lut *shaper_lut;
+ uint32_t shaper_size;
+
+ if (colorop->type != DRM_COLOROP_1D_CURVE &&
+ colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF)
+ return -EINVAL;
+
+ if (colorop_state->bypass) {
+ tf->type = TF_TYPE_BYPASS;
+ tf->tf = TRANSFER_FUNCTION_LINEAR;
+ return 0;
+ }
+
+ drm_dbg(drm, "Shaper colorop with ID: %d\n", colorop->base.id);
+
+ if (colorop->type == DRM_COLOROP_1D_CURVE) {
+ tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+ tf->tf =
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+ tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
+ return __set_output_tf(tf, shaper_lut, shaper_size, false);
+ }
+
+ return -EINVAL;
+}
+
+static int
+__set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+ struct drm_colorop *old_colorop;
+ struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+ struct drm_atomic_state *state = plane_state->state;
+ int i = 0;
+
+ old_colorop = colorop;
+
+ /* 2nd op: 1d curve - shaper */
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+
+ if (new_colorop_state->colorop == old_colorop) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+ }
+
+ if (!colorop_state)
+ return -EINVAL;
+
+ return __set_colorop_in_shaper_1d_curve(dc_plane_state, colorop_state);
+}
+
static int
amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state)
@@ -1258,6 +1322,7 @@ amdgpu_dm_plane_set_colorop_properties(struct
drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state)
{
struct drm_colorop *colorop = plane_state->color_pipeline;
+ struct drm_device *dev = plane_state->plane->dev;
int ret;
/* 1D Curve - DEGAM TF */
@@ -1269,6 +1334,17 @@ amdgpu_dm_plane_set_colorop_properties(struct
drm_plane_state *plane_state,
if (ret)
return ret;
+ /* 1D Curve - SHAPER TF */
+ colorop = colorop->next;
+ if (!colorop) {
+ drm_dbg(dev, "no Shaper TF colorop found\n");
+ return -EINVAL;
+ }
+
+ ret = __set_dm_plane_colorop_shaper(plane_state, dc_plane_state,
colorop);
+ if (ret)
+ return ret;
+
return 0;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index e8b7fc8bb0f1..0d1626abf577 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_c
[RFC PATCH v4 40/42] drm/amd/display: add 3x4 matrix colorop
From: Alex Hung
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_enc
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. 1D curve colorop
4. 1D LUT
5. 1D curve colorop
6. 1D LUT
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 50 +++
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 15 ++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index e7b51b29cc04..ef50640b362b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1212,6 +1212,45 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
}
+static int
+__set_dm_plane_colorop_3x4_matrix(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+ struct drm_colorop *old_colorop;
+ struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+ struct drm_atomic_state *state = plane_state->state;
+ const struct drm_device *dev = colorop->dev;
+ const struct drm_property_blob *blob;
+ struct drm_color_ctm_3x4 *ctm = NULL;
+ int i = 0;
+
+ /* 3x4 matrix */
+ old_colorop = colorop;
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->colorop->type == DRM_COLOROP_CTM_3X4) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+ }
+
+ if (colorop_state && !colorop_state->bypass && colorop->type ==
DRM_COLOROP_CTM_3X4) {
+ drm_dbg(dev, "3x4 matrix colorop with ID: %d\n",
colorop->base.id);
+ blob = colorop_state->data;
+ if (blob->length == sizeof(struct drm_color_ctm_3x4)) {
+ ctm = blob ? (struct drm_color_ctm_3x4 *) blob->data :
NULL;
+ __drm_ctm_3x4_to_dc_matrix(ctm,
dc_plane_state->gamut_remap_matrix.matrix);
+ dc_plane_state->gamut_remap_matrix.enable_remap = true;
+
dc_plane_state->input_csc_color_matrix.enable_adjustment = false;
+ } else
+ drm_warn(dev, "blob->length (%ld) isn't equal to
drm_color_ctm_3x4 (%ld)\n",
+blob->length, sizeof(struct
drm_color_ctm_3x4));
+ }
+
+ return 0;
+}
+
static int
__set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state,
@@ -1411,6 +1450,17 @@ amdgpu_dm_plane_set_colorop_properties(struct
drm_plane_state *plane_state,
if (ret)
return ret;
+ /* 3x4 matrix */
+ colorop = colorop->next;
+ if (!colorop) {
+ drm_dbg(dev, "no 3x4 matrix colorop found\n");
+ return -EINVAL;
+ }
+
+ ret = __set_dm_plane_colorop_3x4_matrix(plane_state, dc_plane_state,
colorop);
+ if (ret)
+ return ret;
+
/* 1D Curve & LUT - SHAPER TF & LUT */
colorop = colorop->next;
if (!colorop) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 08480bf61dc5..ba42f1f6b620 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -69,6 +69,21 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane
*plane, struct drm_pr
prev_op = op;
+ /* 3x4 matrix */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_ctm_3x4_init(dev, op, plane);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ prev_op = op;
+
/* 1D curve - SHAPER TF */
op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!op) {
--
2.44.0
[RFC PATCH v4 26/42] drm/colorop: pass plane_color_pipeline client cap to atomic check
Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.
Pass the plane_color_pipeline bit to drm_atomic_state.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 1 +
include/drm/drm_atomic.h | 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 23b248987a7c..c7c1c614b0d9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1571,6 +1571,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
state->acquire_ctx =
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
+ state->plane_color_pipeline = file_priv->plane_color_pipeline;
retry:
copied_objs = 0;
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 2346f19eda9f..61e6b5553eec 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -404,6 +404,23 @@ struct drm_atomic_state {
* states.
*/
bool duplicated : 1;
+
+ /**
+* @plane_color_pipeline : 1
+*
+* Indicates whether this atomic state originated with a client that
+* set the DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE.
+*
+* Drivers and helper functions should use this to ignore legacy
+* properties that are incompatible with the drm_plane COLOR_PIPELINE
+* behavior, such as
+* - COLOR_RANGE
+* - COLOR_ENCODING
+* or any other driver-specific properties that might affect pixel
+* values.
+*/
+ bool plane_color_pipeline : 1;
+
struct __drm_colorops_state *colorops;
struct __drm_planes_state *planes;
struct __drm_crtcs_state *crtcs;
--
2.44.0
[RFC PATCH v4 13/42] drm/colorop: Add NEXT property
We'll construct color pipelines out of drm_colorop by
chaining them via the NEXT pointer. NEXT will point to
the next drm_colorop in the pipeline, or by 0 if we're
at the end of the pipeline.
v4:
- Allow setting of NEXT property to NULL (Chaitanya Kumar Borah)
v3:
- Add next pointer to colorop to be used by drivers
and in DRM core
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_colorop.c | 29 +
include/drm/drm_colorop.h | 20
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 29979816a2d1..71c2286333a1 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -59,6 +59,7 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->dev = dev;
colorop->type = type;
colorop->plane = plane;
+ colorop->next = NULL;
list_add_tail(>head, >colorop_list);
colorop->index = config->num_colorop++;
@@ -92,6 +93,15 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->bypass_property,
1);
+ prop = drm_property_create_object(dev, DRM_MODE_PROP_IMMUTABLE |
DRM_MODE_PROP_ATOMIC,
+ "NEXT", DRM_MODE_OBJECT_COLOROP);
+ if (!prop)
+ return -ENOMEM;
+ colorop->next_property = prop;
+ drm_object_attach_property(>base,
+ colorop->next_property,
+ 0);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -279,3 +289,22 @@ const char *drm_get_colorop_curve_1d_type_name(enum
drm_colorop_curve_1d_type ty
return colorop_curve_1d_type_names[type];
}
+
+/**
+ * drm_colorop_set_next_property - sets the next pointer
+ * @colorop: drm colorop
+ * @next: next colorop
+ *
+ * Should be used when constructing the color pipeline
+ */
+void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next)
+{
+ if (!colorop->next_property)
+ return;
+
+ drm_object_property_set_value(>base,
+ colorop->next_property,
+ next ? next->base.id : 0);
+ colorop->next = next;
+}
+EXPORT_SYMBOL(drm_colorop_set_next_property);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 28aa5c1c309e..8060988b5892 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -132,6 +132,14 @@ struct drm_colorop {
*/
enum drm_colorop_type type;
+ /**
+* @next:
+*
+* Read-only
+* Pointer to next drm_colorop in pipeline
+*/
+ struct drm_colorop *next;
+
/**
* @type_property:
*
@@ -159,10 +167,20 @@ struct drm_colorop {
*/
struct drm_property *curve_1d_type_property;
+ /**
+* @next_property
+*
+* Read-only property to next colorop in the pipeline
+*/
+ struct drm_property *next_property;
+
};
#define obj_to_colorop(x) container_of(x, struct drm_colorop, base)
+
+
+
/**
* drm_crtc_find - look up a Colorop object from its ID
* @dev: DRM device
@@ -213,5 +231,7 @@ static inline unsigned int drm_colorop_index(const struct
drm_colorop *colorop)
#define drm_for_each_colorop(colorop, dev) \
list_for_each_entry(colorop, &(dev)->mode_config.colorop_list, head)
+void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
+
#endif /* __DRM_COLOROP_H__ */
--
2.44.0
[RFC PATCH v4 42/42] drm/amd/display: add multiplier colorop
From: Alex Hung
This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. Multiplier
4. 1D curve colorop
5. 1D LUT
6. 1D curve colorop
7. 1D LUT
Signed-off-by: Alex Hung
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 40 +++
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 15 +++
2 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index ef50640b362b..b05e4fea8a08 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1251,6 +1251,35 @@ __set_dm_plane_colorop_3x4_matrix(struct drm_plane_state
*plane_state,
return 0;
}
+static int
+__set_dm_plane_colorop_multiplier(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+ struct drm_colorop *old_colorop;
+ struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+ struct drm_atomic_state *state = plane_state->state;
+ const struct drm_device *dev = colorop->dev;
+ int i = 0;
+
+ /* Multiplier */
+ old_colorop = colorop;
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->colorop->type == DRM_COLOROP_MULTIPLIER)
{
+ colorop_state = new_colorop_state;
+ break;
+ }
+ }
+
+ if (colorop_state && !colorop_state->bypass && colorop->type ==
DRM_COLOROP_MULTIPLIER) {
+ drm_dbg(dev, "Multiplier colorop with ID: %d\n",
colorop->base.id);
+ dc_plane_state->hdr_mult =
amdgpu_dm_fixpt_from_s3132(colorop_state->multiplier);
+ }
+
+ return 0;
+}
+
static int
__set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state,
@@ -1461,6 +1490,17 @@ amdgpu_dm_plane_set_colorop_properties(struct
drm_plane_state *plane_state,
if (ret)
return ret;
+ /* Multiplier */
+ colorop = colorop->next;
+ if (!colorop) {
+ drm_dbg(dev, "no multiplier colorop found\n");
+ return -EINVAL;
+ }
+
+ ret = __set_dm_plane_colorop_multiplier(plane_state, dc_plane_state,
colorop);
+ if (ret)
+ return ret;
+
/* 1D Curve & LUT - SHAPER TF & LUT */
colorop = colorop->next;
if (!colorop) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index ba42f1f6b620..b739d6cb3e6b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -84,6 +84,21 @@ int amdgpu_dm_initialize_default_pipeline(struct drm_plane
*plane, struct drm_pr
prev_op = op;
+ /* Multiplier */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_mult_init(dev, op, plane);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ prev_op = op;
+
/* 1D curve - SHAPER TF */
op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!op) {
--
2.44.0
[RFC PATCH v4 31/42] drm/amd/display: Add support for sRGB EOTF in DEGAM block
From: Alex Hung
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The color pipeline now consists of a single colorop:
1. 1D curve colorop w/ sRGB EOTF
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 3 +-
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 88 +++
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 58
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.h | 34 +++
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 10 +++
5 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
index ab2a97e354da..46158d67ab12 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/Makefile
@@ -38,7 +38,8 @@ AMDGPUDM = \
amdgpu_dm_pp_smu.o \
amdgpu_dm_psr.o \
amdgpu_dm_replay.o \
- amdgpu_dm_wb.o
+ amdgpu_dm_wb.o \
+ amdgpu_dm_colorop.o
ifdef CONFIG_DRM_AMD_DC_FP
AMDGPUDM += dc_fpu.o
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 9b527bffe11a..3ec759934669 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -668,6 +668,19 @@ amdgpu_tf_to_dc_tf(enum amdgpu_transfer_function tf)
}
}
+static enum dc_transfer_func_predefined
+amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type tf)
+{
+ switch (tf)
+ {
+ case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
+ case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
+ return TRANSFER_FUNCTION_SRGB;
+ default:
+ return TRANSFER_FUNCTION_LINEAR;;
+ }
+}
+
static void __to_dc_lut3d_color(struct dc_rgb *rgb,
const struct drm_color_lut lut,
int bit_precision)
@@ -1137,6 +1150,59 @@ __set_dm_plane_degamma(struct drm_plane_state
*plane_state,
return 0;
}
+static int
+__set_colorop_in_tf_1d_curve(struct dc_plane_state *dc_plane_state,
+ struct drm_colorop_state *colorop_state)
+{
+ struct dc_transfer_func *tf = dc_plane_state->in_transfer_func;
+ struct drm_colorop *colorop = colorop_state->colorop;
+ struct drm_device *drm = colorop->dev;
+
+ if (colorop->type != DRM_COLOROP_1D_CURVE &&
+ colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+ return -EINVAL;
+
+ if (colorop_state->bypass) {
+ tf->type = TF_TYPE_BYPASS;
+ tf->tf = TRANSFER_FUNCTION_LINEAR;
+ return 0;
+ }
+
+ drm_dbg(drm, "Degamma colorop with ID: %d\n", colorop->base.id);
+
+ tf->type = TF_TYPE_PREDEFINED;
+ tf->tf = amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+
+ return 0;
+}
+
+static int
+__set_dm_plane_colorop_degamma(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state,
+ struct drm_colorop *colorop)
+{
+ struct drm_colorop *old_colorop;
+ struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
+ struct drm_atomic_state *state = plane_state->state;
+ int i = 0;
+
+ old_colorop = colorop;
+
+ /* 1st op: 1d curve - degamma */
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+ colorop_state = new_colorop_state;
+ break;
+ }
+ }
+
+ if (!colorop_state)
+ return -EINVAL;
+
+ return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
+}
+
static int
amdgpu_dm_plane_set_color_properties(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state)
@@ -1187,6 +1253,25 @@ amdgpu_dm_plane_set_color_properties(struct
drm_plane_state *plane_state,
return 0;
}
+static int
+amdgpu_dm_plane_set_colorop_properties(struct drm_plane_state *plane_state,
+ struct dc_plane_state *dc_plane_state)
+{
+ struct drm_colorop *colorop = plane_state->color_pipeline;
+ int ret;
+
+ /* 1D Curve - DEGAM TF */
+
[RFC PATCH v4 37/42] drm/amd/display: Add support for BT.709 and BT.2020 TFs
This adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 11 ---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 10 +++---
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 20b7eb47388c..d5d356cf9fc6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -677,6 +677,9 @@ amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type
tf)
case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
return TRANSFER_FUNCTION_SRGB;
+ case DRM_COLOROP_1D_CURVE_BT2020_INV_OETF:
+ case DRM_COLOROP_1D_CURVE_BT2020_OETF:
+ return TRANSFER_FUNCTION_BT709;
case DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
case DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
return TRANSFER_FUNCTION_PQ;
@@ -1287,8 +1290,10 @@ __set_colorop_1d_curve_blend_tf_lut(struct
dc_plane_state *dc_plane_state,
const struct drm_color_lut *blend_lut;
uint32_t blend_size;
- if (colorop->type != DRM_COLOROP_1D_CURVE &&
- colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+ if (colorop->type != DRM_COLOROP_1D_CURVE)
+ return -EINVAL;
+
+ if (!(BIT(colorop_state->curve_1d_type) & amdgpu_dm_supported_blnd_tfs))
return -EINVAL;
if (colorop_state->bypass) {
@@ -1324,7 +1329,7 @@ __set_dm_plane_colorop_blend(struct drm_plane_state
*plane_state,
/* 3nd op: 1d curve - blend */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
- new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+ (BIT(new_colorop_state->curve_1d_type) &
amdgpu_dm_supported_blnd_tfs)) {
colorop_state = new_colorop_state;
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index f99d8e09d89b..bc66bd4f9fdd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -33,14 +33,18 @@
const u64 amdgpu_dm_supported_degam_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
- BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
const u64 amdgpu_dm_supported_shaper_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
- BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_OETF);
const u64 amdgpu_dm_supported_blnd_tfs =
- BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_BT2020_INV_OETF);
int amdgpu_dm_initialize_default_pipeline(struct drm_plane *plane, struct
drm_prop_enum_list *list)
{
--
2.44.0
[RFC PATCH v4 20/42] drm/colorop: Add 3x4 CTM type
This type is used to support a 3x4 matrix in colorops. A 3x4
matrix uses the last column as a "bias" column. Some HW exposes
support for 3x4. The calculation looks like:
out matrixin
|R| |0 1 2 3 | | R |
|G| = |4 5 6 7 | x | G |
|B| |8 9 10 11| | B |
|1.0|
This is also the first colorop where we need a blob property to
program the property. For that we'll introduce a new DATA
property that can be used by all colorop TYPEs requiring a
blob. The way a DATA blob is read depends on the TYPE of
the colorop.
We only create the DATA property for property types that
need it.
v4:
- Create helper function for creating 3x4 CTM colorop
- Fix CTM indexes in comment (Pekka)
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 14 ++-
drivers/gpu/drm/drm_atomic_uapi.c | 29 ++
drivers/gpu/drm/drm_colorop.c | 40 +++
include/drm/drm_colorop.h | 19 +++
include/uapi/drm/drm_mode.h | 9 ++-
5 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d82858dabf06..6e736ffa6d7c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -793,7 +793,19 @@ static void drm_atomic_colorop_print_state(struct
drm_printer *p,
drm_printf(p, "colorop[%u]:\n", colorop->base.id);
drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
drm_printf(p, "\tbypass=%u\n", state->bypass);
- drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+
+ switch (colorop->type) {
+ case DRM_COLOROP_1D_CURVE:
+ drm_printf(p, "\tcurve_1d_type=%s\n",
+
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+ break;
+ case DRM_COLOROP_CTM_3X4:
+ drm_printf(p, "\tdata blob id=%d\n", state->data ?
state->data->base.id : 0);
+ break;
+ default:
+ break;
+ }
+
drm_printf(p, "\tnext=%d\n", colorop->next ? colorop->next->base.id :
0);
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index ff258b34544e..23b248987a7c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -691,6 +691,30 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
}
+static int drm_atomic_color_set_data_property(struct drm_colorop *colorop,
+ struct drm_colorop_state *state,
+ struct drm_property *property, uint64_t val)
+{
+ ssize_t elem_size = -1;
+ ssize_t size = -1;
+ bool replaced = false;
+
+ switch (colorop->type) {
+ case DRM_COLOROP_CTM_3X4:
+ size = sizeof(struct drm_color_ctm_3x4);
+ break;
+ default:
+ /* should never get here */
+ return -EINVAL;
+ }
+
+ return drm_property_replace_blob_from_id(colorop->dev,
+ >data,
+ val,
+ size,
+ elem_size,
+ );
+}
static int drm_atomic_colorop_set_property(struct drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
@@ -700,6 +724,9 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
state->bypass = val;
} else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
+ } else if (property == colorop->data_property) {
+ return drm_atomic_color_set_data_property(colorop,
+ state, property, val);
} else {
drm_dbg_atomic(colorop->dev,
"[COLOROP:%d:%d] unknown property
[PROP:%d:%s]]\n",
@@ -722,6 +749,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+ } else if (property == colorop->data_property) {
+ *val = (state->data) ? state->data->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 71c2286333a1..7baa1eba 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -34,6 +34,7 @@
static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
+ { DRM
[RFC PATCH v4 39/42] drm/amd/display: add shaper and blend colorops for 1D Curve Custom LUT
From: Alex Hung
This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 1D curve colorop
3. 1D LUT
4. 1D curve colorop
5. 1D LUT
The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 170 +-
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 30
2 files changed, 119 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index d5d356cf9fc6..e7b51b29cc04 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1212,40 +1212,6 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state
*plane_state,
return __set_colorop_in_tf_1d_curve(dc_plane_state, colorop_state);
}
-static int
-__set_colorop_in_shaper_1d_curve(struct dc_plane_state *dc_plane_state,
- struct drm_colorop_state *colorop_state)
-{
- struct dc_transfer_func *tf = dc_plane_state->in_shaper_func;
- struct drm_colorop *colorop = colorop_state->colorop;
- struct drm_device *drm = colorop->dev;
- const struct drm_color_lut *shaper_lut;
- uint32_t shaper_size;
-
- if (colorop->type != DRM_COLOROP_1D_CURVE)
- return -EINVAL;
-
- if (!(BIT(colorop_state->curve_1d_type) &
amdgpu_dm_supported_shaper_tfs))
- return -EINVAL;
-
- if (colorop_state->bypass) {
- tf->type = TF_TYPE_BYPASS;
- tf->tf = TRANSFER_FUNCTION_LINEAR;
- return 0;
- }
-
- drm_dbg(drm, "Shaper colorop with ID: %d\n", colorop->base.id);
-
- if (colorop->type == DRM_COLOROP_1D_CURVE) {
- tf->type = TF_TYPE_DISTRIBUTED_POINTS;
- tf->tf =
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
- tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
- return __set_output_tf(tf, shaper_lut, shaper_size, false);
- }
-
- return -EINVAL;
-}
-
static int
__set_dm_plane_colorop_shaper(struct drm_plane_state *plane_state,
struct dc_plane_state *dc_plane_state,
@@ -1254,64 +1220,61 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state
*plane_state,
struct drm_colorop *old_colorop;
struct drm_colorop_state *colorop_state = NULL, *new_colorop_state;
struct drm_atomic_state *state = plane_state->state;
+ enum dc_transfer_func_predefined default_tf = TRANSFER_FUNCTION_LINEAR;
+ struct dc_transfer_func *tf = dc_plane_state->in_shaper_func;
+ const struct drm_color_lut *shaper_lut;
+ struct drm_device *dev = colorop->dev;
+ uint32_t shaper_size;
int i = 0;
+ /* 1D Curve - SHAPER TF */
old_colorop = colorop;
-
- /* 2nd op: 1d curve - shaper */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
(BIT(new_colorop_state->curve_1d_type) &
amdgpu_dm_supported_shaper_tfs)) {
colorop_state = new_colorop_state;
break;
}
+ }
- if (new_colorop_state->colorop == old_colorop) {
+ if (colorop_state && !colorop_state->bypass && colorop->type ==
DRM_COLOROP_1D_CURVE) {
+ drm_dbg(dev, "Shaper TF colorop with ID: %d\n",
colorop->base.id);
+ tf->type = TF_TYPE_DISTRIBUTED_POINTS;
+ tf->tf = default_tf =
amdgpu_colorop_tf_to_dc_tf(colorop_state->curve_1d_type);
+ tf->sdr_ref_white_level = SDR_WHITE_LEVEL_INIT_VALUE;
+ __set_output_tf(tf, shaper_lut, shaper_size, false);
+ }
+
+ /* 1D LUT - SHAPER LUT */
+ colorop = old_colorop->next;
+ if (!colorop) {
+ drm_dbg(dev, "no Shaper LUT colorop found\n");
+ return -EINVAL;
+ }
+
+ old_colorop = colorop;
+ for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
+ if (new_colorop_state->colorop == old_colorop &&
+ new_colorop_state->colorop->type == DRM_COLOROP_1D_LUT) {
colorop_state = new_colorop_state;
break;
}
}
- if (!colorop_state)
- return -EINVAL;
-
- re
[RFC PATCH v4 41/42] drm/colorop: Add mutliplier type
From: Alex Hung
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Signed-off-by: Alex Hung
---
drivers/gpu/drm/drm_atomic.c | 3 +++
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_colorop.c | 29 +++--
include/drm/drm_colorop.h | 16
include/uapi/drm/drm_mode.h | 1 +
5 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f7d51839ca03..af0b6338a55c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -806,6 +806,9 @@ static void drm_atomic_colorop_print_state(struct
drm_printer *p,
case DRM_COLOROP_CTM_3X4:
drm_printf(p, "\tdata blob id=%d\n", state->data ?
state->data->base.id : 0);
break;
+ case DRM_COLOROP_MULTIPLIER:
+ drm_printf(p, "\tmultiplier=%u\n", state->multiplier);
+ break;
default:
break;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 6bfe857720cd..b4ecda563728 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -727,6 +727,8 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
state->bypass = val;
} else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
+ } else if (property == colorop->multiplier_property) {
+ state->multiplier = val;
} else if (property == colorop->data_property) {
return drm_atomic_color_set_data_property(colorop,
state, property, val);
@@ -752,6 +754,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
*val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
+ } else if (property == colorop->multiplier_property) {
+ *val = state->multiplier;
} else if (property == colorop->size_property) {
*val = state->size;
} else if (property == colorop->data_property) {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 4452eaeeb242..c6cdd743de51 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -35,7 +35,8 @@
static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
{ DRM_COLOROP_1D_LUT, "1D Curve Custom LUT" },
- { DRM_COLOROP_CTM_3X4, "3x4 Matrix"}
+ { DRM_COLOROP_CTM_3X4, "3x4 Matrix"},
+ { DRM_COLOROP_MULTIPLIER, "Multiplier"},
};
static const char * const colorop_curve_1d_type_names[] = {
@@ -231,6 +232,29 @@ int drm_colorop_ctm_3x4_init(struct drm_device *dev,
struct drm_colorop *colorop
}
EXPORT_SYMBOL(drm_colorop_ctm_3x4_init);
+int drm_colorop_mult_init(struct drm_device *dev, struct drm_colorop *colorop,
+ struct drm_plane *plane)
+{
+ struct drm_property *prop;
+ int ret;
+
+ ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_MULTIPLIER);
+ if (ret)
+ return ret;
+
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
"MULTIPLIER", 0, U64_MAX);
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->multiplier_property = prop;
+ drm_object_attach_property(>base,
colorop->multiplier_property, 0);
+
+ drm_colorop_reset(colorop);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_colorop_mult_init);
+
static void __drm_atomic_helper_colorop_duplicate_state(struct drm_colorop
*colorop,
struct
drm_colorop_state *state)
{
@@ -333,7 +357,8 @@ EXPORT_SYMBOL(drm_colorop_reset);
static const char * const colorop_type_name[] = {
[DRM_COLOROP_1D_CURVE] = "1D Curve",
[DRM_COLOROP_1D_LUT] = "1D Curve Custom LUT",
- [DRM_COLOROP_CTM_3X4] = "3x4 Matrix"
+ [DRM_COLOROP_CTM_3X4] = "3x4 Matrix",
+ [DRM_COLOROP_MULTIPLIER] = "Multiplier",
};
/**
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 8adc7ece3bd1..f9f83644cc9f 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -64,6 +64,13 @@ struct drm_colorop_state {
*/
enum drm_colorop_curve_1d_type curve_1d_type;
+ /**
+* @multiplier:
+*
+* Multiplier to 'gain' the plane. Format is S31.32 sign-magnitude.
+*/
+ uint64_t multiplier;
+
/**
* @size:
*
@@ -186,6 +193,13 @@ struct drm_colorop {
*/
struct drm_property *curve_1d_type_property;
+ /**
+* @multiplier_property:
+*
[RFC PATCH v4 36/42] drm/colorop: add BT2020/BT709 OETF and Inverse OETF
The BT.709 and BT.2020 OETFs are the same, the only difference
being that the BT.2020 variant is defined with more precision
for 10 and 12-bit per color encodings.
Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic transfer function)
instead of as EOTF (electro-optical transfer function).
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_colorop.c | 2 ++
include/drm/drm_colorop.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 781947e42b02..b10cad5a7208 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -40,6 +40,8 @@ static const struct drm_prop_enum_list
drm_colorop_type_enum_list[] = {
static const char * const colorop_curve_1d_type_names[] = {
[DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
[DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+ [DRM_COLOROP_1D_CURVE_BT2020_INV_OETF] = "BT.2020 Inverse OETF",
+ [DRM_COLOROP_1D_CURVE_BT2020_OETF] = "BT.2020 OETF",
[DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF",
[DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF",
};
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index e06d9ea28efd..28b3136dabad 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -33,6 +33,8 @@
enum drm_colorop_curve_1d_type {
DRM_COLOROP_1D_CURVE_SRGB_EOTF,
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF,
+ DRM_COLOROP_1D_CURVE_BT2020_INV_OETF,
+ DRM_COLOROP_1D_CURVE_BT2020_OETF,
DRM_COLOROP_1D_CURVE_PQ_125_EOTF,
DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF,
DRM_COLOROP_1D_CURVE_COUNT
--
2.44.0
[RFC PATCH v4 19/42] drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
- COLOR_ENCODING
- COLOR_RANGE
Drivers are expected to ignore these properties when
programming the HW.
Setting of the COLOR_PIPELINE plane property or drm_colorop
properties is only allowed for userspace that sets this
client cap.
v4:
- Don't block setting of COLOR_RANGE and COLOR_ENCODING
when client cap is set
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 13 -
drivers/gpu/drm/drm_ioctl.c | 7 +++
include/drm/drm_file.h| 7 +++
include/uapi/drm/drm.h| 16
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86f77a9aa3a8..ff258b34544e 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -570,6 +570,12 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == plane->color_range_property) {
state->color_range = val;
} else if (property == plane->color_pipeline_property) {
+ if (!file_priv->plane_color_pipeline) {
+ drm_dbg_atomic(dev,
+ "Setting COLOR_PIPELINE plane property
not permitted unless DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set\n");
+ return -EINVAL;
+ }
+
/* find DRM colorop object */
struct drm_colorop *colorop = NULL;
colorop = drm_colorop_find(dev, file_priv, val);
@@ -1179,6 +1185,12 @@ int drm_atomic_set_property(struct drm_atomic_state
*state,
break;
}
case DRM_MODE_OBJECT_COLOROP: {
+ if (!file_priv->plane_color_pipeline) {
+ drm_dbg_atomic(prop->dev,
+ "[OBJECT:%d] is a colorop but
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE not set\n",
+ obj->id);
+ ret = -EINVAL;
+ }
struct drm_colorop *colorop = obj_to_colorop(obj);
struct drm_colorop_state *colorop_state;
@@ -1191,7 +1203,6 @@ int drm_atomic_set_property(struct drm_atomic_state
*state,
ret = drm_atomic_colorop_set_property(colorop,
colorop_state, file_priv,
prop, prop_value);
-
break;
}
default:
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index e368fc084c77..da59e37ae228 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -373,6 +373,13 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
return -EINVAL;
file_priv->supports_virtualized_cursor_plane = req->value;
break;
+ case DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE:
+ if (!file_priv->atomic)
+ return -EINVAL;
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->plane_color_pipeline = req->value;
+ break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index ab230d3af138..63c1d29b8520 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -204,6 +204,13 @@ struct drm_file {
*/
bool writeback_connectors;
+ /**
+* @plane_color_pipeline:
+*
+* True if client understands plane color pipelines
+*/
+ bool plane_color_pipeline;
+
/**
* @was_master:
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 16122819edfe..2d74c49274ee 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -875,6 +875,22 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT6
+/**
+ * DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
+ *
+ * If set to 1
+ * - the DRM core will allow setting of plane the COLOR_PIPELINE
+ * property, as well as drm_colorop properties.
+ * - Drivers will ignore these properties
+ * - COLOR_ENCODING
+ * - COLOR_RANGE
+ *
+ * The client must enable _CLIENT_CAP_ATOMIC first.
+ *
+ * This capability is currently in development.
+ */
+#define DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE7
+
/* DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
2.44.0
[RFC PATCH v4 34/42] drm/colorop: Add PQ 125 EOTF and its inverse
The PQ function defines a mapping of code values to nits (cd/m^2).
The max code value maps to 10,000 nits.
Windows DWM's canonical composition color space (CCCS) defaults
to composing SDR contents to 80 nits and uses a float value of
1.0 to represent this. For this reason AMD HW hard-codes a PQ
function that is scaled by 125, yielding 80 nit PQ values for
1.0 and 10,000 nits at 125.0.
This patch introduces this scaled PQ EOTF and its inverse as
1D curve types.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_colorop.c | 2 ++
include/drm/drm_colorop.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 7baa1eba..781947e42b02 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -40,6 +40,8 @@ static const struct drm_prop_enum_list
drm_colorop_type_enum_list[] = {
static const char * const colorop_curve_1d_type_names[] = {
[DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
[DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+ [DRM_COLOROP_1D_CURVE_PQ_125_EOTF] = "PQ 125 EOTF",
+ [DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF] = "PQ 125 Inverse EOTF",
};
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 8710e550790c..e06d9ea28efd 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -33,6 +33,8 @@
enum drm_colorop_curve_1d_type {
DRM_COLOROP_1D_CURVE_SRGB_EOTF,
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF,
+ DRM_COLOROP_1D_CURVE_PQ_125_EOTF,
+ DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF,
DRM_COLOROP_1D_CURVE_COUNT
};
--
2.44.0
[RFC PATCH v4 21/42] drm/vkms: Pull apply_colorop out of pre_blend_color_transform
The if/switch statement is bound to grow with more types and
subtypes. Pull this out into its own funcion to make things more
manageable and readable.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_composer.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 9493bdb1ba3f..25b786b49db0 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -164,6 +164,31 @@ static void apply_lut(const struct vkms_crtc_state
*crtc_state, struct line_buff
}
}
+static void apply_colorop(struct pixel_argb_u16 *pixel, struct drm_colorop
*colorop)
+{
+ /* TODO is this right? */
+ struct drm_colorop_state *colorop_state = colorop->state;
+
+ if (colorop->type == DRM_COLOROP_1D_CURVE) {
+ switch (colorop_state->curve_1d_type) {
+ case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
+ pixel->r =
apply_lut_to_channel_value(_inv_eotf, pixel->r, LUT_RED);
+ pixel->g =
apply_lut_to_channel_value(_inv_eotf, pixel->g, LUT_GREEN);
+ pixel->b =
apply_lut_to_channel_value(_inv_eotf, pixel->b, LUT_BLUE);
+ break;
+ case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
+ pixel->r =
apply_lut_to_channel_value(_eotf, pixel->r, LUT_RED);
+ pixel->g =
apply_lut_to_channel_value(_eotf, pixel->g, LUT_GREEN);
+ pixel->b =
apply_lut_to_channel_value(_eotf, pixel->b, LUT_BLUE);
+ break;
+ default:
+ DRM_DEBUG_DRIVER("unkown colorop 1D curve type
%d\n", colorop_state->curve_1d_type);
+ break;
+ }
+ }
+
+}
+
static void pre_blend_color_transform(const struct vkms_plane_state
*plane_state, struct line_buffer *output_buffer)
{
struct drm_colorop *colorop = plane_state->base.base.color_pipeline;
@@ -180,26 +205,9 @@ static void pre_blend_color_transform(const struct
vkms_plane_state *plane_state
if (!colorop_state)
return;
- for (size_t x = 0; x < output_buffer->n_pixels; x++) {
- struct pixel_argb_u16 *pixel =
_buffer->pixels[x];
-
- if (colorop->type == DRM_COLOROP_1D_CURVE &&
- colorop_state->bypass == false) {
- switch (colorop_state->curve_1d_type) {
- case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
- pixel->r =
apply_lut_to_channel_value(_inv_eotf, pixel->r, LUT_RED);
- pixel->g =
apply_lut_to_channel_value(_inv_eotf, pixel->g, LUT_GREEN);
- pixel->b =
apply_lut_to_channel_value(_inv_eotf, pixel->b, LUT_BLUE);
- break;
- case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
- default:
- pixel->r =
apply_lut_to_channel_value(_eotf, pixel->r, LUT_RED);
- pixel->g =
apply_lut_to_channel_value(_eotf, pixel->g, LUT_GREEN);
- pixel->b =
apply_lut_to_channel_value(_eotf, pixel->b, LUT_BLUE);
- break;
- }
- }
- }
+ for (size_t x = 0; x < output_buffer->n_pixels; x++)
+ if (!colorop_state->bypass)
+ apply_colorop(_buffer->pixels[x],
colorop);
colorop = colorop->next;
}
--
2.44.0
[RFC PATCH v4 35/42] drm/amd/display: Enable support for PQ 125 EOTF and Inverse
This patchset enables support for the PQ_125 EOTF and its inverse
on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this patchset the following IGT subtests are passing:
kms_colorop --run plane-XR30-XR30-pq_125_eotf
kms_colorop --run plane-XR30-XR30-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf-pq_125_eotf
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 20 +--
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 8 +---
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 3e3ae2b58b06..20b7eb47388c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -25,6 +25,7 @@
#include "amdgpu.h"
#include "amdgpu_mode.h"
#include "amdgpu_dm.h"
+#include "amdgpu_dm_colorop.h"
#include "dc.h"
#include "modules/color/color_gamma.h"
#include "basics/conversion.h"
@@ -676,6 +677,9 @@ amdgpu_colorop_tf_to_dc_tf(enum drm_colorop_curve_1d_type
tf)
case DRM_COLOROP_1D_CURVE_SRGB_EOTF:
case DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF:
return TRANSFER_FUNCTION_SRGB;
+ case DRM_COLOROP_1D_CURVE_PQ_125_EOTF:
+ case DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF:
+ return TRANSFER_FUNCTION_PQ;
default:
return TRANSFER_FUNCTION_LINEAR;;
}
@@ -1158,8 +1162,10 @@ __set_colorop_in_tf_1d_curve(struct dc_plane_state
*dc_plane_state,
struct drm_colorop *colorop = colorop_state->colorop;
struct drm_device *drm = colorop->dev;
- if (colorop->type != DRM_COLOROP_1D_CURVE &&
- colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_EOTF)
+ if (colorop->type != DRM_COLOROP_1D_CURVE)
+ return -EINVAL;
+
+ if (!(BIT(colorop_state->curve_1d_type) &
amdgpu_dm_supported_degam_tfs))
return -EINVAL;
if (colorop_state->bypass) {
@@ -1191,7 +1197,7 @@ __set_dm_plane_colorop_degamma(struct drm_plane_state
*plane_state,
/* 1st op: 1d curve - degamma */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
- new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_EOTF) {
+ (BIT(new_colorop_state->curve_1d_type) &
amdgpu_dm_supported_degam_tfs)) {
colorop_state = new_colorop_state;
break;
}
@@ -1213,8 +1219,10 @@ __set_colorop_in_shaper_1d_curve(struct dc_plane_state
*dc_plane_state,
const struct drm_color_lut *shaper_lut;
uint32_t shaper_size;
- if (colorop->type != DRM_COLOROP_1D_CURVE &&
- colorop_state->curve_1d_type != DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF)
+ if (colorop->type != DRM_COLOROP_1D_CURVE)
+ return -EINVAL;
+
+ if (!(BIT(colorop_state->curve_1d_type) &
amdgpu_dm_supported_shaper_tfs))
return -EINVAL;
if (colorop_state->bypass) {
@@ -1250,7 +1258,7 @@ __set_dm_plane_colorop_shaper(struct drm_plane_state
*plane_state,
/* 2nd op: 1d curve - shaper */
for_each_new_colorop_in_state(state, colorop, new_colorop_state, i) {
if (new_colorop_state->colorop == old_colorop &&
- new_colorop_state->curve_1d_type ==
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) {
+ (BIT(new_colorop_state->curve_1d_type) &
amdgpu_dm_supported_shaper_tfs)) {
colorop_state = new_colorop_state;
break;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
index 449a2ad6a184..f99d8e09d89b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
@@ -32,10 +32,12 @@
#include "amdgpu_dm_colorop.h"
const u64 amdgpu_dm_supported_degam_tfs =
- BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_EOTF);
- const u64 amdgpu_dm_supported_shaper_tfs =
- BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
+const u64 amdgpu_dm_supported_shaper_tfs =
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_PQ_125_INV_EOTF);
const u64 amdgpu_dm_supported_blnd_tfs =
BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF);
--
2.44.0
[RFC PATCH v4 15/42] drm/plane: Add COLOR PIPELINE property
We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.
Userspace can use this to discover the available color
pipelines, as well as set the desired one. The color
pipelines are programmed via properties on the actual
drm_colorop objects.
v4:
- Add pipeline property creation helper (Pekka)
- Fix function comment for
drm_atomic_set_colorop_for_plane (Pekka)
- Always create Bypass pipeline (Pekka)
- Add missing function declaration (Chaitanya Kumar Borah)
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 46
drivers/gpu/drm/drm_atomic_state_helper.c | 5 +++
drivers/gpu/drm/drm_atomic_uapi.c | 42 ++
drivers/gpu/drm/drm_plane.c | 52 +++
include/drm/drm_atomic.h | 3 ++
include/drm/drm_atomic_uapi.h | 2 +
include/drm/drm_plane.h | 11 +
7 files changed, 161 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3645c36d63b3..27a8805c5fa1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1458,6 +1458,52 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
}
EXPORT_SYMBOL(drm_atomic_add_affected_planes);
+/**
+ * drm_atomic_add_affected_colorops - add colorops for plane
+ * @state: atomic state
+ * @plane: DRM plane
+ *
+ * This function walks the current configuration and adds all colorops
+ * currently used by @plane to the atomic configuration @state. This is useful
+ * when an atomic commit also needs to check all currently enabled colorop on
+ * @plane, e.g. when changing the mode. It's also useful when re-enabling a
plane
+ * to avoid special code to force-enable all colorops.
+ *
+ * Since acquiring a colorop state will always also acquire the w/w mutex of
the
+ * current plane for that colorop (if there is any) adding all the colorop
states for
+ * a plane will not reduce parallelism of atomic updates.
+ *
+ * Returns:
+ * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
+ * then the w/w mutex code has detected a deadlock and the entire atomic
+ * sequence must be restarted. All other errors are fatal.
+ */
+int
+drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
+struct drm_plane *plane)
+{
+ struct drm_colorop *colorop;
+ struct drm_colorop_state *colorop_state;
+
+ WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
+
+ drm_dbg_atomic(plane->dev,
+ "Adding all current colorops for [plane:%d:%s] to %p\n",
+ plane->base.id, plane->name, state);
+
+ drm_for_each_colorop(colorop, plane->dev) {
+ if (colorop->plane != plane)
+ continue;
+
+ colorop_state = drm_atomic_get_colorop_state(state, colorop);
+ if (IS_ERR(colorop_state))
+ return PTR_ERR(colorop_state);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_add_affected_colorops);
+
/**
* drm_atomic_check_only - check whether a given config would work
* @state: atomic configuration to check
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb1095..d1dd082b1286 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -267,6 +267,11 @@ void __drm_atomic_helper_plane_state_reset(struct
drm_plane_state *plane_state,
plane_state->color_range = val;
}
+ if (plane->color_pipeline_property) {
+ /* default is always NULL, i.e., bypass */
+ plane_state->color_pipeline = NULL;
+ }
+
if (plane->zpos_property) {
if (!drm_object_property_get_default_value(>base,
plane->zpos_property,
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 87f00131be11..86f77a9aa3a8 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -256,6 +256,36 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
*plane_state,
}
EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
+
+/**
+ * drm_atomic_set_colorop_for_plane - set colorop for plane
+ * @plane_state: atomic state object for the plane
+ * @colorop: colorop to use for the plane
+ *
+ * Helper function to select the color pipeline on a plane by setting
+ * it to the first drm_colorop element of the pipeline.
+ */
+void
+drm_atomic_set_colorop_for_plane(struct drm_plane_state *plane_state,
+struct drm_colorop *colorop)
+{
+ struct drm_plane *plane
[RFC PATCH v4 25/42] drm/vkms: Add tests for CTM handling
A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.
v4:
- Comment on origin of bt709_enc matrix (Pekka)
- Use full opaque alpha (Pekka)
- Add additional check for Y < 0x (Pekka)
- Remove unused code (Pekka)
- Rename red, green, blue to Y, U, V where applicable
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 251 ++
drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
2 files changed, 252 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
index e6ac01dee830..83d07f7bae37 100644
--- a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
@@ -3,6 +3,7 @@
#include
#include
+#include
#define TEST_LUT_SIZE 16
@@ -181,11 +182,261 @@ static void vkms_color_srgb_inv_srgb(struct kunit *test)
}
}
+#define FIXPT_HALF(DRM_FIXED_ONE >> 1)
+#define FIXPT_QUARTER (DRM_FIXED_ONE >> 2)
+
+const struct drm_color_ctm_3x4 test_matrix_3x4_50_desat = { {
+ FIXPT_HALF, FIXPT_QUARTER, FIXPT_QUARTER, 0,
+ FIXPT_QUARTER, FIXPT_HALF, FIXPT_QUARTER, 0,
+ FIXPT_QUARTER, FIXPT_QUARTER, FIXPT_HALF, 0
+} };
+
+static void vkms_color_ctm_3x4_50_desat(struct kunit *test)
+{
+ struct pixel_argb_s32 ref, out;
+
+ /* full white */
+ ref.a = 0x;
+ ref.r = 0x;
+ ref.g = 0x;
+ ref.b = 0x;
+
+ memcpy(, , sizeof(out));
+ apply_3x4_matrix(, _matrix_3x4_50_desat);
+
+ KUNIT_EXPECT_MEMEQ(test, , , sizeof(out));
+
+ /* full black */
+ ref.a = 0x;
+ ref.r = 0x0;
+ ref.g = 0x0;
+ ref.b = 0x0;
+
+ memcpy(, , sizeof(out));
+ apply_3x4_matrix(, _matrix_3x4_50_desat);
+
+ KUNIT_EXPECT_MEMEQ(test, , , sizeof(out));
+
+ /* 50% grey */
+ ref.a = 0x;
+ ref.r = 0x8000;
+ ref.g = 0x8000;
+ ref.b = 0x8000;
+
+ memcpy(, , sizeof(out));
+ apply_3x4_matrix(, _matrix_3x4_50_desat);
+
+ KUNIT_EXPECT_MEMEQ(test, , , sizeof(out));
+
+ /* full red to 50% desat */
+ ref.a = 0x;
+ ref.r = 0x7fff;
+ ref.g = 0x3fff;
+ ref.b = 0x3fff;
+
+ out.a = 0x;
+ out.r = 0x;
+ out.g = 0x0;
+ out.b = 0x0;
+
+ apply_3x4_matrix(, _matrix_3x4_50_desat);
+
+ KUNIT_EXPECT_MEMEQ(test, , , sizeof(out));
+}
+
+/*
+ * BT.709 encoding matrix
+ *
+ * Values printed from within IGT when converting
+ * igt_matrix_3x4_bt709_enc to the fixed-point format expected
+ * by DRM/KMS.
+ */
+const struct drm_color_ctm_3x4 test_matrix_3x4_bt709_enc = { {
+ 0x366cf400ull, 0xb7175900ull, 0x000127bb300ull, 0,
+ 0x80001993b3a0ull, 0x80005609fe80ull, 0x6f9db200ull, 0,
+ 0x9d70a400ull, 0x80008f011100ull, 0x8e6f9330ull, 0
+} };
+
+static void vkms_color_ctm_3x4_bt709(struct kunit *test)
+{
+ struct pixel_argb_s32 out;
+
+ /* full white to bt709 */
+ out.a = 0x;
+ out.r = 0x;
+ out.g = 0x;
+ out.b = 0x;
+
+ apply_3x4_matrix(, _matrix_3x4_bt709_enc);
+
+ /* Y 255 */
+ KUNIT_EXPECT_GT(test, out.r, 0xfe00);
+ KUNIT_EXPECT_LT(test, out.r, 0x1);
+
+ /* U 0 */
+ KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+ /* V 0 */
+ KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+ /* full black to bt709 */
+ out.a = 0x;
+ out.r = 0x0;
+ out.g = 0x0;
+ out.b = 0x0;
+
+ apply_3x4_matrix(, _matrix_3x4_bt709_enc);
+
+ /* Y 0 */
+ KUNIT_EXPECT_LT(test, out.r, 0x100);
+
+ /* U 0 */
+ KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+ /* V 0 */
+ KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+ /* gray to bt709 */
+ out.a = 0x;
+ out.r = 0x7fff;
+ out.g = 0x7fff;
+ out.b = 0x7fff;
+
+ apply_3x4_matrix(, _matrix_3x4_bt709_enc);
+
+ /* Y 127 */
+ KUNIT_EXPECT_GT(test, out.r, 0x7e00);
+ KUNIT_EXPECT_LT(test, out.r, 0x8000);
+
+ /* U 0 */
+ KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+ /* V 0 */
+ KUNIT_EXPECT_LT(test, out.b, 0x0100);
+
+ /* == red 255 - bt709 enc == */
+ out.a = 0x;
+ out.r = 0x;
+ out.g = 0x0;
+ out.b = 0x0;
+
+ apply_3x4_matrix(, _matrix_3x4_bt709_enc);
+
+ /* Y 54 */
+ KUNIT_EXPECT_GT(test, out.r, 0x3500);
+ KUNIT_EXPECT_LT(test, out.r, 0x3700);
+
+ /* U 0 */
+ KUNIT_EXPECT_LT(test, out.g, 0x0100);
+
+ /* V 157 */
+ KUNIT_EXPECT_GT(test, out.b, 0x9C00);
+ KUNIT_EXPECT_LT(test, out.b, 0x9E00);
+
+
+ /* == green 255 - bt709 enc == */
+ out.a = 0x;
+
[RFC PATCH v4 24/42] drm/tests: Add a few tests around drm_fixed.h
While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.
In order to make someone else's day easier I am adding the
drm_test_int2fixp test that validates the above assumption.
I am also adding a test for the new sm2fixp function that converts
from a signed-magnitude fixed point to the twos-complement fixed
point.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_fixp_test.c | 69 +++
2 files changed, 71 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index d6183b3d7688..98468f7908dd 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_fixp_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_fixp_test.c
b/drivers/gpu/drm/tests/drm_fixp_test.c
new file mode 100644
index ..f420f173ff66
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_fixp_test.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright 2022 Advanced Micro Devices, Inc.
+ */
+
+#include
+#include
+
+static void drm_test_sm2fixp(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, 0x7fffll, ((1LL << 63) - 1));
+
+ /* 1 */
+ KUNIT_EXPECT_EQ(test, drm_int2fixp(1), drm_sm2fixp(1ull <<
DRM_FIXED_POINT));
+
+ /* -1 */
+ KUNIT_EXPECT_EQ(test, drm_int2fixp(-1), drm_sm2fixp((1ull << 63) |
(1ull << DRM_FIXED_POINT)));
+
+ /* 0.5 */
+ KUNIT_EXPECT_EQ(test, drm_fixp_from_fraction(1, 2), drm_sm2fixp(1ull <<
(DRM_FIXED_POINT - 1)));
+
+ /* -0.5 */
+ KUNIT_EXPECT_EQ(test, drm_fixp_from_fraction(-1, 2), drm_sm2fixp((1ull
<< 63) | (1ull << (DRM_FIXED_POINT - 1;
+
+}
+
+static void drm_test_int2fixp(struct kunit *test)
+{
+ /* 1 */
+ KUNIT_EXPECT_EQ(test, 1ll << 32, drm_int2fixp(1));
+
+ /* -1 */
+ KUNIT_EXPECT_EQ(test, -(1ll << 32), drm_int2fixp(-1));
+
+ /* 1 + (-1) = 0 */
+ KUNIT_EXPECT_EQ(test, 0, drm_int2fixp(1) + drm_int2fixp(-1));
+
+ /* 1 / 2 */
+ KUNIT_EXPECT_EQ(test, 1ll << 31, drm_fixp_from_fraction(1, 2));
+
+ /* -0.5 */
+ KUNIT_EXPECT_EQ(test, -(1ll << 31), drm_fixp_from_fraction(-1, 2));
+
+ /* (1 / 2) + (-1) = 0.5 */
+ KUNIT_EXPECT_EQ(test, 1ll << 31, drm_fixp_from_fraction(-1, 2) +
drm_int2fixp(1));
+
+ /* (1 / 2) - 1) = 0.5 */
+ KUNIT_EXPECT_EQ(test, -(1ll << 31), drm_fixp_from_fraction(1, 2) +
drm_int2fixp(-1));
+
+ /* (1 / 2) - 1) = 0.5 */
+ KUNIT_EXPECT_EQ(test, -(1ll << 31), drm_fixp_from_fraction(1, 2) -
drm_int2fixp(1));
+
+}
+
+static struct kunit_case drm_fixp_tests[] = {
+ KUNIT_CASE(drm_test_int2fixp),
+ KUNIT_CASE(drm_test_sm2fixp),
+ { }
+};
+
+static struct kunit_suite drm_rect_test_suite = {
+ .name = "drm_fixp",
+ .test_cases = drm_fixp_tests,
+};
+
+kunit_test_suite(drm_rect_test_suite);
+
+MODULE_AUTHOR("AMD");
+MODULE_LICENSE("GPL and additional rights");
\ No newline at end of file
--
2.44.0
[RFC PATCH v4 10/42] drm/colorop: Add TYPE property
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
v4:
- Use enum property for TYPE (Pekka)
v3:
- Make TYPE a range property
- Move enum drm_colorop_type to uapi header
- Fix drm_get_colorop_type_name description
For now we're only introducing an enumerated 1D LUT type to
illustrate the concept.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 4 +--
drivers/gpu/drm/drm_atomic_uapi.c | 8 +-
drivers/gpu/drm/drm_colorop.c | 44 ++-
include/drm/drm_colorop.h | 17 +++-
include/uapi/drm/drm_mode.h | 4 +++
5 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 62e87e6a9653..b400e32c9d39 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -634,8 +634,8 @@ drm_atomic_get_colorop_state(struct drm_atomic_state *state,
state->colorops[index].new_state = colorop_state;
colorop_state->state = state;
- drm_dbg_atomic(colorop->dev, "Added [COLOROP:%d] %p state to %p\n",
- colorop->base.id, colorop_state, state);
+ drm_dbg_atomic(colorop->dev, "Added [COLOROP:%d:%d] %p state to %p\n",
+ colorop->base.id, colorop->type, colorop_state, state);
return colorop_state;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 1f9b6dfa8ca7..e3067c095c72 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -660,7 +660,13 @@ drm_atomic_colorop_get_property(struct drm_colorop
*colorop,
const struct drm_colorop_state *state,
struct drm_property *property, uint64_t *val)
{
- return -EINVAL;
+ if (property == colorop->type_property) {
+ *val = colorop->type;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
}
static int drm_atomic_set_writeback_fb_for_connector(
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index a295ab96aee1..3a07a8fe2842 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -32,12 +32,17 @@
/* TODO big colorop doc, including properties, etc. */
+static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
+ { DRM_COLOROP_1D_CURVE, "1D Curve" },
+};
+
/* Init Helpers */
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
-struct drm_plane *plane)
+struct drm_plane *plane, enum drm_colorop_type type)
{
struct drm_mode_config *config = >mode_config;
+ struct drm_property *prop;
int ret = 0;
ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_COLOROP);
@@ -46,12 +51,29 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->base.properties = >properties;
colorop->dev = dev;
+ colorop->type = type;
colorop->plane = plane;
list_add_tail(>head, >colorop_list);
colorop->index = config->num_colorop++;
/* add properties */
+
+ /* type */
+ prop = drm_property_create_enum(dev,
+ DRM_MODE_PROP_IMMUTABLE,
+ "TYPE", drm_colorop_type_enum_list,
+ ARRAY_SIZE(drm_colorop_type_enum_list));
+
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->type_property = prop;
+
+ drm_object_attach_property(>base,
+ colorop->type_property,
+ colorop->type);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -150,3 +172,23 @@ void drm_colorop_reset(struct drm_colorop *colorop)
__drm_colorop_reset(colorop, colorop->state);
}
EXPORT_SYMBOL(drm_colorop_reset);
+
+
+static const char * const colorop_type_name[] = {
+ [DRM_COLOROP_1D_CURVE] = "1D Curve",
+};
+
+/**
+ * drm_get_colorop_type_name - return a string for colorop type
+ * @type: colorop type to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorop_type_name(enum drm_colorop_type type)
+{
+ if (WARN_ON(type >= ARRAY_SIZE(colorop_type_name)))
+ return "unknown";
+
+ return colorop_type_name[type];
+}
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index e611f830f986..cb98c55f8387 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -103,6 +103,21 @@ struct drm_colorop {
/** @properties: property tracking for this plane */
s
[RFC PATCH v4 14/42] drm/colorop: Add atomic state print for drm_colorop
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 25 -
include/drm/drm_colorop.h| 5 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b400e32c9d39..3645c36d63b3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -783,6 +783,19 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
return 0;
}
+
+
+static void drm_atomic_colorop_print_state(struct drm_printer *p,
+ const struct drm_colorop_state *state)
+{
+ struct drm_colorop *colorop = state->colorop;
+
+ drm_printf(p, "colorop[%u]:\n", colorop->base.id);
+ drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
+ drm_printf(p, "\tbypass=%u\n", state->bypass);
+ drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+}
+
static void drm_atomic_plane_print_state(struct drm_printer *p,
const struct drm_plane_state *state)
{
@@ -804,7 +817,8 @@ static void drm_atomic_plane_print_state(struct drm_printer
*p,
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
-
+ drm_printf(p, "\tcolor-pipeline=%d\n",
+ state->color_pipeline ? state->color_pipeline->base.id : 0);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
}
@@ -1840,6 +1854,7 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
bool take_locks)
{
struct drm_mode_config *config = >mode_config;
+ struct drm_colorop *colorop;
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -1849,6 +1864,14 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
if (!drm_drv_uses_atomic_modeset(dev))
return;
+ list_for_each_entry(colorop, >colorop_list, head) {
+ if (take_locks)
+ drm_modeset_lock(>plane->mutex, NULL);
+ drm_atomic_colorop_print_state(p, colorop->state);
+ if (take_locks)
+ drm_modeset_unlock(>plane->mutex);
+ }
+
list_for_each_entry(plane, >plane_list, head) {
if (take_locks)
drm_modeset_lock(>mutex, NULL);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 8060988b5892..fc9a28d138b8 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -231,6 +231,11 @@ static inline unsigned int drm_colorop_index(const struct
drm_colorop *colorop)
#define drm_for_each_colorop(colorop, dev) \
list_for_each_entry(colorop, &(dev)->mode_config.colorop_list, head)
+const char *drm_get_color_pipeline_name(struct drm_colorop *colorop);
+
+const char *drm_get_colorop_type_name(enum drm_colorop_type type);
+const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type
type);
+
void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
--
2.44.0
[RFC PATCH v4 28/42] drm/amd/display: Ignore deprecated props when plane_color_pipeline set
When the plane_color_pipeline bit is set we should ignore deprecated properties, such as COLOR_RANGE and COLOR_ENCODING. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index f6575d7dee97..47c6fd33fd60 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4948,6 +4948,10 @@ fill_plane_color_attributes(const struct drm_plane_state *plane_state, *color_space = COLOR_SPACE_SRGB; + /* Ignore properties when DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set */ + if (plane_state->state && plane_state->state->plane_color_pipeline) + return 0; + /* DRM color properties only affect non-RGB formats. */ if (format < SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) return 0; -- 2.44.0
[RFC PATCH v4 09/42] drm/colorop: Introduce new drm_colorop mode object
This patches introduces a new drm_colorop mode object. This
object represents color transformations and can be used to
define color pipelines.
We also introduce the drm_colorop_state here, as well as
various helpers and state tracking bits.
v4:
- Drop IOCTL definitions (Pekka)
- add missing declaration (Chaitanya Kumar Borah)
v3:
- Drop TODO for lock (it's handled in drm_modeset_drop_locks)
(Melissa)
- Don't get plane state when getting colorop state
- Make some functions static (kernel test robot)
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_atomic.c| 70
drivers/gpu/drm/drm_atomic_helper.c | 12 +++
drivers/gpu/drm/drm_atomic_uapi.c | 48 +
drivers/gpu/drm/drm_colorop.c | 152 ++
drivers/gpu/drm/drm_mode_config.c | 7 ++
include/drm/drm_atomic.h| 82 +++
include/drm/drm_atomic_uapi.h | 1 +
include/drm/drm_colorop.h | 158
include/drm/drm_mode_config.h | 18
include/drm/drm_plane.h | 2 +
include/uapi/drm/drm_mode.h | 1 +
12 files changed, 552 insertions(+)
create mode 100644 drivers/gpu/drm/drm_colorop.c
create mode 100644 include/drm/drm_colorop.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 104b42df2e95..4b14dcbb6117 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,6 +16,7 @@ drm-y := \
drm_client.o \
drm_client_modeset.o \
drm_color_mgmt.o \
+ drm_colorop.o \
drm_connector.o \
drm_crtc.o \
drm_displayid.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a91737adf8e7..62e87e6a9653 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -108,6 +109,7 @@ void drm_atomic_state_default_release(struct
drm_atomic_state *state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+ kfree(state->colorops);
kfree(state->private_objs);
}
EXPORT_SYMBOL(drm_atomic_state_default_release);
@@ -139,6 +141,10 @@ drm_atomic_state_init(struct drm_device *dev, struct
drm_atomic_state *state)
sizeof(*state->planes), GFP_KERNEL);
if (!state->planes)
goto fail;
+ state->colorops = kcalloc(dev->mode_config.num_colorop,
+ sizeof(*state->colorops), GFP_KERNEL);
+ if (!state->colorops)
+ goto fail;
/*
* Because drm_atomic_state can be committed asynchronously we need our
@@ -250,6 +256,20 @@ void drm_atomic_state_default_clear(struct
drm_atomic_state *state)
state->planes[i].new_state = NULL;
}
+ for (i = 0; i < config->num_colorop; i++) {
+ struct drm_colorop *colorop = state->colorops[i].ptr;
+
+ if (!colorop)
+ continue;
+
+ drm_colorop_atomic_destroy_state(colorop,
+state->colorops[i].state);
+ state->colorops[i].ptr = NULL;
+ state->colorops[i].state = NULL;
+ state->colorops[i].old_state = NULL;
+ state->colorops[i].new_state = NULL;
+ }
+
for (i = 0; i < state->num_private_objs; i++) {
struct drm_private_obj *obj = state->private_objs[i].ptr;
@@ -571,6 +591,56 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_plane_state);
+
+/**
+ * drm_atomic_get_colorop_state - get colorop state
+ * @state: global atomic state object
+ * @colorop: colorop to get state object for
+ *
+ * This function returns the colorop state for the given colorop, allocating it
+ * if needed. It will also grab the relevant plane lock to make sure that the
+ * state is consistent.
+ *
+ * Returns:
+ *
+ * Either the allocated state or the error code encoded into the pointer. When
+ * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
+ * entire atomic sequence must be restarted. All other errors are fatal.
+ */
+struct drm_colorop_state *
+drm_atomic_get_colorop_state(struct drm_atomic_state *state,
+struct drm_colorop *colorop)
+{
+ int ret, index = drm_colorop_index(colorop);
+ struct drm_colorop_state *colorop_state;
+
+ WARN_ON(!state->acquire_ctx);
+
+ colorop_state = drm_atomic_get_existing_colorop_state(state, colorop);
+ if (colorop_state)
+ return colorop_state;
+
+ ret = drm_modeset_lock(>plane->mutex, state->acquire_ctx);
+ if (ret)
+
[RFC PATCH v4 11/42] drm/colorop: Add 1D Curve subtype
v4:
- Use drm_colorop_curve_1d_type_enum_list to get name (Pekka)
- Create separate init function for 1D curve
- Pass supported TFs into 1D curve init function
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Co-developed-by: Alex Hung
---
drivers/gpu/drm/drm_atomic_uapi.c | 18 +---
drivers/gpu/drm/drm_colorop.c | 71 +++
include/drm/drm_colorop.h | 24 +++
3 files changed, 108 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index e3067c095c72..fdd540cfe24f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -648,11 +648,17 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
struct drm_property *property, uint64_t val)
{
- drm_dbg_atomic(colorop->dev,
- "[COLOROP:%d] unknown property [PROP:%d:%s]]\n",
- colorop->base.id,
- property->base.id, property->name);
- return -EINVAL;
+ if (property == colorop->curve_1d_type_property) {
+ state->curve_1d_type = val;
+ } else {
+ drm_dbg_atomic(colorop->dev,
+ "[COLOROP:%d:%d] unknown property
[PROP:%d:%s]]\n",
+ colorop->base.id, colorop->type,
+ property->base.id, property->name);
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -662,6 +668,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
{
if (property == colorop->type_property) {
*val = colorop->type;
+ } else if (property == colorop->curve_1d_type_property) {
+ *val = state->curve_1d_type;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 3a07a8fe2842..f4740b6115d1 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -36,6 +36,12 @@ static const struct drm_prop_enum_list
drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
};
+static const char * const colorop_curve_1d_type_names[] = {
+ [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
+ [DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+};
+
+
/* Init Helpers */
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
@@ -78,6 +84,56 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
}
EXPORT_SYMBOL(drm_colorop_init);
+int drm_colorop_curve_1d_init(struct drm_device *dev, struct drm_colorop
*colorop,
+ struct drm_plane *plane, u64 supported_tfs)
+{
+ struct drm_prop_enum_list enum_list[DRM_COLOROP_1D_CURVE_COUNT];
+ int i, len;
+
+ struct drm_property *prop;
+ int ret;
+
+ if (!supported_tfs) {
+ drm_err(dev,
+ "No supported TFs for new 1D curve colorop on
[PLANE:%d:%s]\n",
+ plane->base.id, plane->name);
+ return -EINVAL;
+ }
+
+ if ((supported_tfs & -BIT(DRM_COLOROP_1D_CURVE_COUNT)) != 0) {
+ drm_err(dev, "Unknown TF provided on [PLANE:%d:%s]\n",
+ plane->base.id, plane->name);
+ return -EINVAL;
+ }
+
+ ret = drm_colorop_init(dev, colorop, plane, DRM_COLOROP_1D_CURVE);
+ if (ret)
+ return ret;
+
+ len = 0;
+ for (i = 0; i < DRM_COLOROP_1D_CURVE_COUNT; i++) {
+ if ((supported_tfs & BIT(i)) == 0)
+ continue;
+
+ enum_list[len].type = i;
+ enum_list[len].name = colorop_curve_1d_type_names[i];
+ len++;
+ }
+
+ /* initialize 1D curve only attribute */
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
"CURVE_1D_TYPE",
+ enum_list, len);
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->curve_1d_type_property = prop;
+ drm_object_attach_property(>base,
colorop->curve_1d_type_property, 0);
+ drm_colorop_reset(colorop);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_colorop_curve_1d_init);
+
static void __drm_atomic_helper_colorop_duplicate_state(struct drm_colorop
*colorop,
struct
drm_colorop_state *state)
{
@@ -192,3 +248,18 @@ const char *drm_get_colorop_type_name(enum
drm_colorop_type type)
return colorop_type_name[type];
}
+
+/**
+ * drm_get_colorop_curve_1d_type_name - return a string for 1D curve type
+ * @range: 1d curve type to
[RFC PATCH v4 23/42] drm/vkms: add 3x4 matrix in color pipeline
We add two 3x4 matrices into the VKMS color pipeline. The reason
we're adding matrices is so that we can test that application
of a matrix and its inverse yields an output equal to the input
image.
One complication with the matrix implementation has to do with
the fact that the matrix entries are in signed-magnitude fixed
point, whereas the drm_fixed.h implementation uses 2s-complement.
The latter one is the one that we want for easy addition and
subtraction, so we convert all entries to 2s-complement.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_colorop.c | 32 +++-
drivers/gpu/drm/vkms/vkms_composer.c | 27 +++
include/drm/drm_colorop.h| 2 ++
3 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c
b/drivers/gpu/drm/vkms/vkms_colorop.c
index d2db366da6d3..a0e54b2c1f7a 100644
--- a/drivers/gpu/drm/vkms/vkms_colorop.c
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -35,7 +35,37 @@ const int vkms_initialize_color_pipeline(struct drm_plane
*plane, struct drm_pro
prev_op = op;
- /* 2nd op: 1d curve */
+ /* 2nd op: 3x4 matrix */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_ctm_3x4_init(dev, op, plane);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ prev_op = op;
+
+ /* 3rd op: 3x4 matrix */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_ctm_3x4_init(dev, op, plane);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ prev_op = op;
+
+ /* 4th op: 1d curve */
op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
if (!op) {
DRM_ERROR("KMS: Failed to allocate colorop\n");
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index d2101fa55aa3..8bbfce651526 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -164,6 +164,30 @@ static void apply_lut(const struct vkms_crtc_state
*crtc_state, struct line_buff
}
}
+static void apply_3x4_matrix(struct pixel_argb_s32 *pixel, const struct
drm_color_ctm_3x4 *matrix)
+{
+ s64 rf, gf, bf;
+
+ rf = drm_fixp_mul(drm_sm2fixp(matrix->matrix[0]),
drm_int2fixp(pixel->r)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[1]),
drm_int2fixp(pixel->g)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[2]),
drm_int2fixp(pixel->b)) +
+drm_sm2fixp(matrix->matrix[3]);
+
+ gf = drm_fixp_mul(drm_sm2fixp(matrix->matrix[4]),
drm_int2fixp(pixel->r)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[5]),
drm_int2fixp(pixel->g)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[6]),
drm_int2fixp(pixel->b)) +
+drm_sm2fixp(matrix->matrix[7]);
+
+ bf = drm_fixp_mul(drm_sm2fixp(matrix->matrix[8]),
drm_int2fixp(pixel->r)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[9]),
drm_int2fixp(pixel->g)) +
+drm_fixp_mul(drm_sm2fixp(matrix->matrix[10]),
drm_int2fixp(pixel->b)) +
+drm_sm2fixp(matrix->matrix[11]);
+
+ pixel->r = drm_fixp2int(rf);
+ pixel->g = drm_fixp2int(gf);
+ pixel->b = drm_fixp2int(bf);
+}
+
static void apply_colorop(struct pixel_argb_s32 *pixel, struct drm_colorop
*colorop)
{
/* TODO is this right? */
@@ -185,6 +209,9 @@ static void apply_colorop(struct pixel_argb_s32 *pixel,
struct drm_colorop *colo
DRM_DEBUG_DRIVER("unkown colorop 1D curve type
%d\n", colorop_state->curve_1d_type);
break;
}
+ } else if (colorop->type == DRM_COLOROP_CTM_3X4) {
+ if (colorop_state->data)
+ apply_3x4_matrix(pixel, (struct drm_color_ctm_3x4 *)
colorop_state->data->data);
}
}
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 4aee29e161d6..8710e550790c 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -224,6 +224,8 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
int drm_colorop_curve_1d_init(struct drm_device *dev, struct drm_colorop
*colorop,
struct drm_plane *plane, u64 supported_tfs);
+int drm_colorop_ctm_3x4_init(struct drm_device *dev, struct drm_colorop
*colorop,
+struct drm_plane *plane);
struct drm_colorop_state *
drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
--
2.44.0
[RFC PATCH v4 17/42] drm/vkms: Add enumerated 1D curve colorop
This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanying IGT tests.
We introduce a new vkms_luts.c file that hard-codes sRGB EOTF,
sRGB Inverse EOTF, and a linear EOTF LUT. These have been
generated with 256 entries each as IGT is currently testing
only 8 bpc surfaces. We will likely need higher precision
but I'm reluctant to make that change without clear indication
that we need it. We'll revisit and, if necessary, regenerate
the LUTs when we have IGT tests for higher precision buffers.
v4:
- Drop _tf_ from color_pipeline init function
- Pass supported TFs into colorop init
- Create bypass pipeline in DRM helper (Pekka)
v2:
- Add commit description
- Fix sRGB EOTF LUT definition
- Add linear and sRGB inverse EOTF LUTs
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
---
drivers/gpu/drm/vkms/Makefile| 4 +-
drivers/gpu/drm/vkms/vkms_colorop.c | 70 +++
drivers/gpu/drm/vkms/vkms_composer.c | 45 ++
drivers/gpu/drm/vkms/vkms_drv.h | 4 +
drivers/gpu/drm/vkms/vkms_luts.c | 802 +++
drivers/gpu/drm/vkms/vkms_luts.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c| 2 +
7 files changed, 938 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 1b28a6a32948..c38455c46be4 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -6,6 +6,8 @@ vkms-y := \
vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
- vkms_writeback.o
+ vkms_writeback.o \
+ vkms_colorop.o \
+ vkms_luts.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c
b/drivers/gpu/drm/vkms/vkms_colorop.c
new file mode 100644
index ..d2db366da6d3
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_COLOR_PIPELINES 5
+
+static const u64 supported_tfs =
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_EOTF) |
+ BIT(DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF);
+
+const int vkms_initialize_color_pipeline(struct drm_plane *plane, struct
drm_prop_enum_list *list)
+{
+
+ struct drm_colorop *op, *prev_op;
+ struct drm_device *dev = plane->dev;
+ int ret;
+
+ /* 1st op: 1d curve */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_curve_1d_init(dev, op, plane, supported_tfs);
+ if (ret)
+ return ret;
+
+ list->type = op->base.id;
+ list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", op->base.id);
+
+ prev_op = op;
+
+ /* 2nd op: 1d curve */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_curve_1d_init(dev, op, plane, supported_tfs);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ return 0;
+}
+
+int vkms_initialize_colorops(struct drm_plane *plane)
+{
+ struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
+ int len = 0;
+ int ret;
+
+ /* Add color pipeline */
+ ret = vkms_initialize_color_pipeline(plane, &(pipelines[len]));
+ if (ret)
+ return ret;
+ len++;
+
+ /* Create COLOR_PIPELINE property and attach */
+ drm_plane_create_color_pipeline_property(plane, pipelines, len);
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index b90e446d5954..9493bdb1ba3f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -12,6 +12,7 @@
#include
#include "vkms_drv.h"
+#include "vkms_luts.h"
static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
@@ -163,6 +164,47 @@ static void apply_lut(const struct vkms_crtc_state
*crtc_state, struct line_buff
}
}
+static void pre_blend_color_transform(const struct vkms_plane_state
*plane_state, struct line_buffer *output_buffer)
+{
+ struct drm_colorop *colorop = plane_state->base.base.color_pipeline;
+
+ while (colorop) {
+ struct drm_colorop_state *colorop_state;
+
+ if (!colorop)
+ return;
+
+ /* TODO
[RFC PATCH v4 22/42] drm/vkms: Use s32 for internal color pipeline precision
Certain operations require us to preserve values below 0.0 and
above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
such operation is a BT709 encoding operation followed by its
decoding operation, or the reverse.
We'll use s32 values as intermediate in and outputs of our
color operations, for the operations where it matters.
For now this won't apply to LUT operations. We might want to
update those to work on s32 as well, but it's unclear how
that should work for unorm LUT definitions. We'll revisit
that once we add LUT + CTM tests.
In order to allow for this we'll also invert the nesting of our
colorop processing loops. We now use the pixel iteration loop
on the outside and the colorop iteration on the inside.
v4:
- Clarify that we're packing 16-bit UNORM into s32, not
converting values to a different representation (Pekka)
v3:
- Use new colorop->next pointer
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_composer.c | 57 +---
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 25b786b49db0..d2101fa55aa3 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -164,7 +164,7 @@ static void apply_lut(const struct vkms_crtc_state
*crtc_state, struct line_buff
}
}
-static void apply_colorop(struct pixel_argb_u16 *pixel, struct drm_colorop
*colorop)
+static void apply_colorop(struct pixel_argb_s32 *pixel, struct drm_colorop
*colorop)
{
/* TODO is this right? */
struct drm_colorop_state *colorop_state = colorop->state;
@@ -191,25 +191,56 @@ static void apply_colorop(struct pixel_argb_u16 *pixel,
struct drm_colorop *colo
static void pre_blend_color_transform(const struct vkms_plane_state
*plane_state, struct line_buffer *output_buffer)
{
- struct drm_colorop *colorop = plane_state->base.base.color_pipeline;
+ struct drm_colorop *colorop;
+ struct pixel_argb_s32 pixel;
- while (colorop) {
- struct drm_colorop_state *colorop_state;
+ for (size_t x = 0; x < output_buffer->n_pixels; x++) {
- if (!colorop)
- return;
+ /*
+* Some operations, such as applying a BT709 encoding matrix,
+* followed by a decoding matrix, require that we preserve
+* values above 1.0 and below 0.0 until the end of the pipeline.
+*
+* Pack the 16-bit UNORM values into s32 to give us head-room to
+* avoid clipping until we're at the end of the pipeline. Clip
+* intentionally at the end of the pipeline before packing
+* UNORM values back into u16.
+*/
+ pixel.a = output_buffer->pixels[x].a;
+ pixel.r = output_buffer->pixels[x].r;
+ pixel.g = output_buffer->pixels[x].g;
+ pixel.b = output_buffer->pixels[x].b;
- /* TODO this is probably wrong */
- colorop_state = colorop->state;
+ colorop = plane_state->base.base.color_pipeline;
+ while (colorop) {
+ struct drm_colorop_state *colorop_state;
- if (!colorop_state)
- return;
+ if (!colorop)
+ return;
+
+ /* TODO this is probably wrong */
+ colorop_state = colorop->state;
+
+ if (!colorop_state)
+ return;
- for (size_t x = 0; x < output_buffer->n_pixels; x++)
if (!colorop_state->bypass)
- apply_colorop(_buffer->pixels[x],
colorop);
+ apply_colorop(, colorop);
- colorop = colorop->next;
+ colorop = colorop->next;
+ }
+
+ /* clamp pixel */
+ pixel.a = max(min(pixel.a, 0x), 0x0);
+ pixel.r = max(min(pixel.r, 0x), 0x0);
+ pixel.g = max(min(pixel.g, 0x), 0x0);
+ pixel.b = max(min(pixel.b, 0x), 0x0);
+
+ /* put back to output_buffer */
+ output_buffer->pixels[x].a = pixel.a;
+ output_buffer->pixels[x].r = pixel.r;
+ output_buffer->pixels[x].g = pixel.g;
+ output_buffer->pixels[x].b = pixel.b;
}
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 2bcc24c196a2..fadb7685a360 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -36,6 +36,10 @@ struct vkms_frame_info {
unsigned int cpp;
};
+struct pixel_argb_s32 {
+ s32
[RFC PATCH v4 16/42] drm/colorop: Add NEXT to colorop state print
v3: - Read NEXT ID from drm_colorop's next pointer Signed-off-by: Harry Wentland --- drivers/gpu/drm/drm_atomic.c | 1 + include/drm/drm_colorop.h| 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 27a8805c5fa1..d82858dabf06 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -794,6 +794,7 @@ static void drm_atomic_colorop_print_state(struct drm_printer *p, drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type)); drm_printf(p, "\tbypass=%u\n", state->bypass); drm_printf(p, "\tcurve_1d_type=%s\n", drm_get_colorop_curve_1d_type_name(state->curve_1d_type)); + drm_printf(p, "\tnext=%d\n", colorop->next ? colorop->next->base.id : 0); } static void drm_atomic_plane_print_state(struct drm_printer *p, diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h index fc9a28d138b8..e85ed5aa68d0 100644 --- a/include/drm/drm_colorop.h +++ b/include/drm/drm_colorop.h @@ -237,6 +237,8 @@ const char *drm_get_colorop_type_name(enum drm_colorop_type type); const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type type); void drm_colorop_set_next_property(struct drm_colorop *colorop, struct drm_colorop *next); +uint32_t drm_colorop_get_next_property(struct drm_colorop *colorop); +struct drm_colorop *drm_colorop_get_next(struct drm_colorop *colorop); #endif /* __DRM_COLOROP_H__ */ -- 2.44.0
[RFC PATCH v4 04/42] drm/vkms: Round fixp2int conversion in lerp_u16
fixp2int always rounds down, fixp2int_ceil rounds up. We need the new fixp2int_round. Signed-off-by: Harry Wentland --- drivers/gpu/drm/vkms/vkms_composer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 3c99fb8b54e2..e70cd473e3be 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -98,7 +98,7 @@ static u16 lerp_u16(u16 a, u16 b, s64 t) s64 delta = drm_fixp_mul(b_fp - a_fp, t); - return drm_fixp2int(a_fp + delta); + return drm_fixp2int_round(a_fp + delta); } static s64 get_lut_index(const struct vkms_color_lut *lut, u16 channel_value) -- 2.44.0
[RFC PATCH v4 18/42] drm/vkms: Add kunit tests for linear and sRGB LUTs
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
index fc73e48aa57c..e6ac01dee830 100644
--- a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
@@ -31,7 +31,6 @@ const struct vkms_color_lut test_linear_lut = {
.channel_value2index_ratio = 0xf000fll
};
-
static void vkms_color_test_get_lut_index(struct kunit *test)
{
int i;
@@ -40,6 +39,19 @@ static void vkms_color_test_get_lut_index(struct kunit *test)
for (i = 0; i < TEST_LUT_SIZE; i++)
KUNIT_EXPECT_EQ(test,
drm_fixp2int_ceil(get_lut_index(_linear_lut, test_linear_array[i].red)),
i);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_eotf, 0x0)),
0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x0)), 0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x101)), 0x1);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x202)), 0x2);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_inv_eotf, 0x0)),
0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x0)), 0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x101)), 0x1);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x202)), 0x2);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0xfefe)), 0xfe);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x)), 0xff);
}
static void vkms_color_test_lerp(struct kunit *test)
@@ -148,9 +160,32 @@ static void vkms_color_test_lerp(struct kunit *test)
KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x1, 0x8000), 0x1);
}
+static void vkms_color_test_linear(struct kunit *test)
+{
+ for (int i = 0; i < LUT_SIZE; i++) {
+ int linear = apply_lut_to_channel_value(_eotf, i *
0x101, LUT_RED);
+ KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(linear, 0x101), i);
+ }
+}
+
+static void vkms_color_srgb_inv_srgb(struct kunit *test)
+{
+ u16 srgb, final;
+
+ for (int i = 0; i < LUT_SIZE; i++) {
+ srgb = apply_lut_to_channel_value(_eotf, i * 0x101,
LUT_RED);
+ final = apply_lut_to_channel_value(_inv_eotf, srgb,
LUT_RED);
+
+ KUNIT_EXPECT_GE(test, final / 0x101, i-1);
+ KUNIT_EXPECT_LE(test, final / 0x101, i+1);
+ }
+}
+
static struct kunit_case vkms_color_test_cases[] = {
KUNIT_CASE(vkms_color_test_get_lut_index),
KUNIT_CASE(vkms_color_test_lerp),
+ KUNIT_CASE(vkms_color_test_linear),
+ KUNIT_CASE(vkms_color_srgb_inv_srgb),
{}
};
--
2.44.0
[RFC PATCH v4 12/42] drm/colorop: Add BYPASS property
We want to be able to bypass each colorop at all times.
Introduce a new BYPASS boolean property for this.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm/drm_colorop.c | 16
include/drm/drm_colorop.h | 20
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index fdd540cfe24f..87f00131be11 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -648,7 +648,9 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
struct drm_property *property, uint64_t val)
{
- if (property == colorop->curve_1d_type_property) {
+ if (property == colorop->bypass_property) {
+ state->bypass = val;
+ } else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
} else {
drm_dbg_atomic(colorop->dev,
@@ -668,6 +670,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
{
if (property == colorop->type_property) {
*val = colorop->type;
+ } else if (property == colorop->bypass_property) {
+ *val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index f4740b6115d1..29979816a2d1 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -80,6 +80,18 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->type_property,
colorop->type);
+ /* bypass */
+ /* TODO can we reuse the mode_config->active_prop? */
+ prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
+ "BYPASS");
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->bypass_property = prop;
+ drm_object_attach_property(>base,
+ colorop->bypass_property,
+ 1);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -123,6 +135,7 @@ int drm_colorop_curve_1d_init(struct drm_device *dev,
struct drm_colorop *coloro
/* initialize 1D curve only attribute */
prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
"CURVE_1D_TYPE",
enum_list, len);
+
if (!prop)
return -ENOMEM;
@@ -138,6 +151,8 @@ static void
__drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colo
struct
drm_colorop_state *state)
{
memcpy(state, colorop->state, sizeof(*state));
+
+ state->bypass = true;
}
struct drm_colorop_state *
@@ -189,6 +204,7 @@ static void __drm_colorop_state_reset(struct
drm_colorop_state *colorop_state,
struct drm_colorop *colorop)
{
colorop_state->colorop = colorop;
+ colorop_state->bypass = true;
}
/**
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 539db900f16f..28aa5c1c309e 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -45,6 +45,14 @@ struct drm_colorop_state {
/* colorop properties */
+ /**
+* @bypass:
+*
+* True if colorop shall be bypassed. False if colorop is
+* enabled.
+*/
+ bool bypass;
+
/**
* @curve_1d_type:
*
@@ -132,6 +140,18 @@ struct drm_colorop {
*/
struct drm_property *type_property;
+ /**
+* @bypass_property:
+*
+* Boolean property to control enablement of the color
+* operation. Setting bypass to "true" shall always be supported
+* in order to allow compositors to quickly fall back to
+* alternate methods of color processing. This is important
+* since setting color operations can fail due to unique
+* HW constraints.
+*/
+ struct drm_property *bypass_property;
+
/**
* @curve_1d_type:
*
--
2.44.0
[RFC PATCH v4 05/42] drm/vkms: Create separate Kconfig file for VKMS
This aligns with most other DRM drivers and will allow us to add new VKMS config options without polluting the DRM Kconfig. v3: - Change SPDX to GPL-2.0-only to match DRM KConfig SPDX (Simon) Signed-off-by: Harry Wentland Reviewed-by: Simon Ser --- drivers/gpu/drm/Kconfig | 14 +- drivers/gpu/drm/vkms/Kconfig | 15 +++ 2 files changed, 16 insertions(+), 13 deletions(-) create mode 100644 drivers/gpu/drm/vkms/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 2520db0b776e..e3ea8793cb8a 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -289,19 +289,7 @@ config DRM_VGEM as used by Mesa's software renderer for enhanced performance. If M is selected the module will be called vgem. -config DRM_VKMS - tristate "Virtual KMS (EXPERIMENTAL)" - depends on DRM && MMU - select DRM_KMS_HELPER - select DRM_GEM_SHMEM_HELPER - select CRC32 - default n - help - Virtual Kernel Mode-Setting (VKMS) is used for testing or for - running GPU in a headless machines. Choose this option to get - a VKMS. - - If M is selected the module will be called vkms. +source "drivers/gpu/drm/vkms/Kconfig" source "drivers/gpu/drm/exynos/Kconfig" diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig new file mode 100644 index ..b9ecdebecb0b --- /dev/null +++ b/drivers/gpu/drm/vkms/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0-only + +config DRM_VKMS + tristate "Virtual KMS (EXPERIMENTAL)" + depends on DRM && MMU + select DRM_KMS_HELPER + select DRM_GEM_SHMEM_HELPER + select CRC32 + default n + help + Virtual Kernel Mode-Setting (VKMS) is used for testing or for + running GPU in a headless machines. Choose this option to get + a VKMS. + + If M is selected the module will be called vkms. -- 2.44.0
[RFC PATCH v4 07/42] drm/vkms: Avoid reading beyond LUT array
When the floor LUT index (drm_fixp2int(lut_index) is the last
index of the array the ceil LUT index will point to an entry
beyond the array. Make sure we guard against it and use the
value of the floor LUT index.
v3:
- Drop bits from commit description that didn't contribute
anything of value
Fixes: db1f254f2cfaf ("drm/vkms: Add support to 1D gamma LUT")
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_composer.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index d178f2a400f6..b90e446d5954 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -123,6 +123,8 @@ static u16 apply_lut_to_channel_value(const struct
vkms_color_lut *lut, u16 chan
enum lut_channel channel)
{
s64 lut_index = get_lut_index(lut, channel_value);
+ u16 *floor_lut_value, *ceil_lut_value;
+ u16 floor_channel_value, ceil_channel_value;
/*
* This checks if `struct drm_color_lut` has any gap added by the
compiler
@@ -130,11 +132,15 @@ static u16 apply_lut_to_channel_value(const struct
vkms_color_lut *lut, u16 chan
*/
static_assert(sizeof(struct drm_color_lut) == sizeof(__u16) * 4);
- u16 *floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
- u16 *ceil_lut_value = (__u16 *)>base[drm_fixp2int_ceil(lut_index)];
+ floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
+ if (drm_fixp2int(lut_index) == (lut->lut_length - 1))
+ /* We're at the end of the LUT array, use same value for ceil
and floor */
+ ceil_lut_value = floor_lut_value;
+ else
+ ceil_lut_value = (__u16
*)>base[drm_fixp2int_ceil(lut_index)];
- u16 floor_channel_value = floor_lut_value[channel];
- u16 ceil_channel_value = ceil_lut_value[channel];
+ floor_channel_value = floor_lut_value[channel];
+ ceil_channel_value = ceil_lut_value[channel];
return lerp_u16(floor_channel_value, ceil_channel_value,
lut_index & DRM_FIXED_DECIMAL_MASK);
--
2.44.0
[RFC PATCH v4 06/42] drm/vkms: Add kunit tests for VKMS LUT handling
Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
- get_lut_index
- lerp_u16
v4:
- Test the critical points of the lerp function (Pekka)
v3:
- Use include way of testing static functions (Arthur)
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
---
drivers/gpu/drm/vkms/Kconfig | 5 +
drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 163 ++
drivers/gpu/drm/vkms/vkms_composer.c | 8 +-
4 files changed, 178 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
index b9ecdebecb0b..c1f8b343ff0e 100644
--- a/drivers/gpu/drm/vkms/Kconfig
+++ b/drivers/gpu/drm/vkms/Kconfig
@@ -13,3 +13,8 @@ config DRM_VKMS
a VKMS.
If M is selected the module will be called vkms.
+
+config DRM_VKMS_KUNIT_TESTS
+ tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
+ depends on DRM_VKMS && KUNIT
+ default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig
b/drivers/gpu/drm/vkms/tests/.kunitconfig
new file mode 100644
index ..70e378228cbd
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_VKMS=y
+CONFIG_DRM_VKMS_KUNIT_TESTS=y
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
new file mode 100644
index ..fc73e48aa57c
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+
+#include
+
+#define TEST_LUT_SIZE 16
+
+static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
+ { 0x0, 0x0, 0x0, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+};
+
+const struct vkms_color_lut test_linear_lut = {
+ .base = test_linear_array,
+ .lut_length = TEST_LUT_SIZE,
+ .channel_value2index_ratio = 0xf000fll
+};
+
+
+static void vkms_color_test_get_lut_index(struct kunit *test)
+{
+ int i;
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_linear_lut,
test_linear_array[0].red)), 0);
+
+ for (i = 0; i < TEST_LUT_SIZE; i++)
+ KUNIT_EXPECT_EQ(test,
drm_fixp2int_ceil(get_lut_index(_linear_lut, test_linear_array[i].red)),
i);
+}
+
+static void vkms_color_test_lerp(struct kunit *test)
+{
+ /*** half-way round down ***/
+ s64 t = 0x8000 - 1;
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
+
+ /* odd a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x8);
+
+ /* odd b */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
+
+ /* b = a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
+
+ /* b = a + 1 */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x10);
+
+
+ /*** half-way round up ***/
+ t = 0x8000;
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x8);
+
+ /* odd a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x9);
+
+ /* odd b */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x8);
+
+ /* b = a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
+
+ /* b = a + 1 */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x11);
+
+ /*** t = 0.0 ***/
+ t = 0x0;
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x0);
+
+ /* odd a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x1);
+
+ /* odd b */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0x1);
+
+ /* b = a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
+
+ /* b = a + 1 */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x10);
+
+ /*** t = 1.0 ***/
+ t = 0x1;
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, t), 0x10);
+
+ /* odd a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0x10, t), 0x10);
+
+ /* odd b */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x1, 0xf, t), 0xf);
+
+ /* b = a */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x10, t), 0x10);
+
+ /* b = a + 1 */
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x10, 0x11, t), 0x11);
+
+
+ /*** t = 0.0 + 1 ***
[RFC PATCH v4 01/42] drm: Don't treat 0 as -1 in drm_fixp2int_ceil
Unit testing this in VKMS shows that passing 0 into
this function returns -1, which is highly counter-
intuitive. Fix it by checking whether the input is
>= 0 instead of > 0.
Fixes: 64566b5e767f9 ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil")
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Reviewed-by: Melissa Wen
---
include/drm/drm_fixed.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 6ea339d5de08..0c9f917a4d4b 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -95,7 +95,7 @@ static inline int drm_fixp2int_round(s64 a)
static inline int drm_fixp2int_ceil(s64 a)
{
- if (a > 0)
+ if (a >= 0)
return drm_fixp2int(a + DRM_FIXED_ALMOST_ONE);
else
return drm_fixp2int(a - DRM_FIXED_ALMOST_ONE);
--
2.44.0
[RFC PATCH v4 00/42] Color Pipeline API w/ VKMS
This is an RFC set for a color pipeline API, along with a sample implementation in VKMS. All the key API bits are here. VKMS now supports two named transfer function colorops and two matrix colorops. We have IGT tests that check all four of these colorops with a pixel-by-pixel comparison that checks that these colorops do what we expect them to do with a +/- 1 8 bpc code point margin. The big new change with v4 is the addition of an amdgpu color pipeline, for all AMD GPUs with DCN 3 and newer. Amdgpu now support the following: 1. 1D Curve EOTF 2. 3x4 CTM 3. Multiplier 4. 1D Curve Inverse EOTF 5. 1D LUT 6. 1D Curve EOTF 7. 1D LUT The supported curves for the 1D Curve type are: - sRGB EOTF and its inverse - PQ EOTF, scaled to [0.0, 125.0] and its inverse - BT.2020/BT.709 OETF and its inverse Note that the 1st and 5th colorops take the EOTF or Inverse OETF while the 3rd colorop takes the Inverse EOTF or OETF. We are working on two more ops for amdgpu, the HDR multiplier and the 3DLUT, which will give us this: 1. 1D Curve EOTF 2. 3x4 CTM 3. HDR Multiplier 4. 1D Curve Inverse EOTF 5. 1D LUT 6. 3D LUT 7. 1D Curve EOTF 8. 1D LUT This, essentially mirrors the color pipeline used by gamescope and presented by Melissa Wen, with the exception of the DEGAM LUT, which is not currently used. See [1] https://indico.freedesktop.org/event/4/contributions/186/attachments/138/218/xdc2023-TheRainbowTreasureMap-MelissaWen.pdf After this we'd like to also add the following ops: - Scaler (Informational only) - Color Encoding, to replace drm_plane's COLOR_ENCODING - Color Range, to replace drm_plane's COLOR_RANGE This patchset is grouped as follows: - Patches 1-3: couple general patches/fixes - Patches 4-7: introduce kunit to VKMS - Patch 7: description of motivation and details behind the Color Pipeline API. If you're reading nothing else but are interested in the topic I highly recommend you take a look at this. - Patches 7-27: DRM core and VKMS changes for color pipeline API - Patches 28-40: DRM core and amdgpu changes for color pipeline API VKMS patches could still be improved in a few ways, though the payoff might be limited and I would rather focus on other work at the moment. The most obvious thing to improve would be to eliminate the hard-coded LUTs for identity, and sRGB, and replace them with fixed-point math instead. There are plenty of things that I would like to see here but haven't had a chance to look at. These will (hopefully) be addressed in future iterations, either in VKMS or amdgpu: - Clear documentation for each drm_colorop_type - Add custom LUT colorops to VKMS - Add pre-blending 3DLUT - How to support HW which can't bypass entire pipeline? - Add ability to create colorops that don't have BYPASS - Can we do a LOAD / COMMIT model for LUTs (and other properties)? - read-only scaling colorop which defines scaling taps and position - read-only color format colorop to define supported color formats for a pipeline - named matrices, for things like converting YUV to RGB IGT tests can be found at https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 IGT patches are also being sent to the igt-dev mailing list. If you prefer a gitlab MR for review you can find it at https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 v4: - Add amdgpu color pipeline (WIP) - Don't block setting of deprecated properties, instead pass client cap to atomic check so drivers can ignore these props - Drop IOCTL definitions (Pekka) - Use enum property for colorop TYPE (Pekka) - A few cleanups to the docs (Pekka) - Rework the TYPE enum to name relation to avoid code duplication (Pekka) - Add missing function declarations (Chaitanya Kumar Borah) - Allow setting of NEXT property to NULL in _set_ function (Chaitanya Kumar Borah) - Add helper for creation of pipeline drm_plane property (Pekka) - Always create Bypass pipeline (Pekka) - A bunch of changes to VKMS kunit tests (Pekka) - Fix index in CTM doc (Pekka) v3: - Abandon IOCTLs and discover colorops as clients iterate the pipeline - Remove need for libdrm - Add color_pipeline client cap and make mutually exclusive with COLOR_RANGE and COLOR_ENCODING properties - add CTM colorop to VKMS - Use include way for kunit testing static functions (Arthur) - Make TYPE a range property - Move enum drm_colorop_type to uapi header - and a bunch of smaller bits that are highlighted in the relevant commit description v2: - Rebased on drm-misc-next - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer - Incorporate feedback in color_pipeline.rst doc - Add support for sRGB inverse EOTF - Add 2nd enumerated TF colorop to VKMS - Fix LUTs and some issues with applying LUTs in VKMS Cc: Ville Syrjala Cc: Pekka Paalanen Cc: Simon Ser Cc: Harry Wentland Cc: Melissa Wen Cc: Jonas Ådahl Cc: Sebastian Wick Cc: Shashank Sharma Cc: Alexander Goins Cc
[RFC PATCH v4 03/42] drm: Correctly round for fixp2int_round
A value of 0x8000 and higher should round up, and
below should round down. VKMS Kunit tests for lerp_u16
showed that this is not the case. Fix it.
1 << (DRM_FIXED_POINT_HALF - 1) =
1 << 15 = 0x8000
This is not 0.5, but 0.0762939453125.
Instead of some smart math use a simple if/else to
round up or down. This helps people like me to understand
what the function does.
Signed-off-by: Harry Wentland
---
include/drm/drm_fixed.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index cb842ba80ddd..8ee549f68537 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -77,6 +77,8 @@ static inline u32 dfixed_div(fixed20_12 A, fixed20_12 B)
#define DRM_FIXED_DIGITS_MASK (~DRM_FIXED_DECIMAL_MASK)
#define DRM_FIXED_EPSILON 1LL
#define DRM_FIXED_ALMOST_ONE (DRM_FIXED_ONE - DRM_FIXED_EPSILON)
+#define DRM_FIXED_FRACTIONAL 0xll
+#define DRM_FIXED_HALF 0x8000ll
/**
* @drm_sm2fixp
@@ -106,11 +108,6 @@ static inline int drm_fixp2int(s64 a)
return ((s64)a) >> DRM_FIXED_POINT;
}
-static inline int drm_fixp2int_round(s64 a)
-{
- return drm_fixp2int(a + (1 << (DRM_FIXED_POINT_HALF - 1)));
-}
-
static inline int drm_fixp2int_ceil(s64 a)
{
if (a >= 0)
@@ -119,6 +116,14 @@ static inline int drm_fixp2int_ceil(s64 a)
return drm_fixp2int(a - DRM_FIXED_ALMOST_ONE);
}
+static inline int drm_fixp2int_round(s64 a)
+{
+ if ((a & DRM_FIXED_FRACTIONAL) < DRM_FIXED_HALF)
+ return drm_fixp2int(a);
+ else
+ return drm_fixp2int_ceil(a);
+}
+
static inline unsigned drm_fixp_msbset(s64 a)
{
unsigned shift, sign = (a >> 63) & 1;
--
2.44.0
Re: [PATCH] drm/amd: Drop abm_level property
On 2024-02-16 10:33, Mario Limonciello wrote:
> This vendor specific property has never been used by userspace
> software and conflicts with the panel_power_savings sysfs file.
> That is a compositor and user could fight over the same data.
>
> Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to
> eDP connectors")
> Suggested-by: Harry Wentland
> Signed-off-by: Mario Limonciello
> --
> Cc: Hamza Mahfooz
> Cc: Sun peng (Leo) Li
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 --
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 --
> 3 files changed, 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index b8fbe97efe1d..3ecc7ef95172 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1350,14 +1350,6 @@ int amdgpu_display_modeset_create_props(struct
> amdgpu_device *adev)
>"dither",
>amdgpu_dither_enum_list, sz);
>
> - if (adev->dc_enabled) {
> - adev->mode_info.abm_level_property =
> - drm_property_create_range(adev_to_drm(adev), 0,
> - "abm level", 0, 4);
> - if (!adev->mode_info.abm_level_property)
> - return -ENOMEM;
> - }
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 2e4911050cc5..1fe21a70ddd0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -324,8 +324,6 @@ struct amdgpu_mode_info {
> struct drm_property *audio_property;
> /* FMT dithering */
> struct drm_property *dither_property;
> - /* Adaptive Backlight Modulation (power feature) */
> - struct drm_property *abm_level_property;
> /* hardcoded DFP edid from BIOS */
> struct edid *bios_hardcoded_edid;
> int bios_hardcoded_edid_size;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index b9ac3d2f8029..e3b32ffba85a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6388,9 +6388,6 @@ int amdgpu_dm_connector_atomic_set_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> dm_new_state->underscan_enable = val;
> ret = 0;
> - } else if (property == adev->mode_info.abm_level_property) {
> - dm_new_state->abm_level = val ?: ABM_LEVEL_IMMEDIATE_DISABLE;
> - ret = 0;
> }
>
> return ret;
> @@ -6433,10 +6430,6 @@ int amdgpu_dm_connector_atomic_get_property(struct
> drm_connector *connector,
> } else if (property == adev->mode_info.underscan_property) {
> *val = dm_state->underscan_enable;
> ret = 0;
> - } else if (property == adev->mode_info.abm_level_property) {
> - *val = (dm_state->abm_level != ABM_LEVEL_IMMEDIATE_DISABLE) ?
> - dm_state->abm_level : 0;
> - ret = 0;
> }
>
> return ret;
> @@ -7652,13 +7645,6 @@ void amdgpu_dm_connector_init_helper(struct
> amdgpu_display_manager *dm,
> aconnector->base.state->max_bpc = 16;
> aconnector->base.state->max_requested_bpc =
> aconnector->base.state->max_bpc;
>
> - if (connector_type == DRM_MODE_CONNECTOR_eDP &&
> - (dc_is_dmcu_initialized(adev->dm.dc) ||
> - adev->dm.dc->ctx->dmub_srv) && amdgpu_dm_abm_level < 0) {
> - drm_object_attach_property(>base.base,
> - adev->mode_info.abm_level_property, 0);
> - }
> -
> if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
> /* Content Type is currently only implemented for HDMI. */
> drm_connector_attach_content_type_property(>base);
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2024-02-16 11:11, Harry Wentland wrote: > > > On 2024-02-16 10:42, Pekka Paalanen wrote: >> On Fri, 16 Feb 2024 09:33:47 -0500 >> Harry Wentland wrote: >> >>> On 2024-02-16 03:19, Pekka Paalanen wrote: >>>> On Fri, 2 Feb 2024 10:28:35 -0500 >>>> Hamza Mahfooz wrote: >>>> >>>>> We want programs besides the compositor to be able to enable or disable >>>>> panel power saving features. >>>> >>>> Could you also explain why, in the commit message, please? >>>> >>>> It is unexpected for arbitrary programs to be able to override the KMS >>>> client, and certainly new ways to do so should not be added without an >>>> excellent justification. >>>> >>>> Maybe debugfs would be more appropriate if the purpose is only testing >>>> rather than production environments? >>>> >>>>> However, since they are currently only >>>>> configurable through DRM properties, that isn't possible. So, to remedy >>>>> that issue introduce a new "panel_power_savings" sysfs attribute. >>>> >>>> When the DRM property was added, what was used as the userspace to >>>> prove its workings? >>>> >>> >>> I don't think there ever was a userspace implementation and doubt any >>> exists today. Part of that is on me. In hindsight, the KMS prop should >>> have never gone upstream. >>> >>> I suggest we drop the KMS prop entirely. >> >> Sounds good. What about the sysfs thing? Should it be a debugfs thing >> instead, assuming the below question will be resolved? >> > > > It's intended to be used by the power profiles daemon (PPD). I don't think > debugfs is the right choice. See > https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc > >>> As for the color accuracy topic, I think it is important that compositors >>> can have full control over that if needed, while it's also important >>> for HW vendors to optimize for power when absolute color accuracy is not >>> needed. An average end-user writing code or working on their slides >>> would rather have a longer battery life than a perfectly color-accurate >>> display. We should probably think of a solution that can support both >>> use-cases. >> >> I agree. Maybe this pondering should start from "how would it work from >> end user perspective"? >> >> "Automatically" is probably be most desirable answer. Some kind of > > I agree > >> desktop settings with options like "save power at the expense of image >> quality": >> - always >> - not if watching movies/gaming >> - on battery >> - on battery, unless I'm watching movies/gaming >> - never >> > > It's interesting that you split out movies/gaming, specifically. AMD's > ABM algorithm seems to have considered movies in particular when > evaluating the power/fidelity trade-off. > > I wouldn't think consumer media is very particular about a specific > color fidelity (despite what HDR specs try to make you believe). Where > color fidelity would matter to me is when I'd want to edit pictures or > video. > > The "abm_level" property that we expose is really just that, a setting > for the strength of the power-savings effect, with 0 being off and 4 being > maximum strength and power saving, at the expense of fidelity. > > Mario's work is to let the PPD control it and set the ABM levels based on > the selected power profile: > 0 - Performance > 1 - Balance > 3 - Power > > And I believe we've looked at disabling ABM (setting it to 0) automatically > if we know we're on AC power. > >> Or maybe there already is something like that, and it only needs to be >> plumbed through? >> >> Which would point towards KMS clients needing to control it, which >> means a generic KMS prop rather than vendor specific? >> >> Or should the desktop compositor be talking to some daemon instead of >> KMS for this? Maybe they already are? >> > > I think the intention is for the PPD to be that daemon. Mario can elaborate. > Some more details and screenshots on how the PPD is expected to work and look: https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux Harry > Harry > >> >> Thanks, >> pq >
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2024-02-16 10:42, Pekka Paalanen wrote: > On Fri, 16 Feb 2024 09:33:47 -0500 > Harry Wentland wrote: > >> On 2024-02-16 03:19, Pekka Paalanen wrote: >>> On Fri, 2 Feb 2024 10:28:35 -0500 >>> Hamza Mahfooz wrote: >>> >>>> We want programs besides the compositor to be able to enable or disable >>>> panel power saving features. >>> >>> Could you also explain why, in the commit message, please? >>> >>> It is unexpected for arbitrary programs to be able to override the KMS >>> client, and certainly new ways to do so should not be added without an >>> excellent justification. >>> >>> Maybe debugfs would be more appropriate if the purpose is only testing >>> rather than production environments? >>> >>>> However, since they are currently only >>>> configurable through DRM properties, that isn't possible. So, to remedy >>>> that issue introduce a new "panel_power_savings" sysfs attribute. >>> >>> When the DRM property was added, what was used as the userspace to >>> prove its workings? >>> >> >> I don't think there ever was a userspace implementation and doubt any >> exists today. Part of that is on me. In hindsight, the KMS prop should >> have never gone upstream. >> >> I suggest we drop the KMS prop entirely. > > Sounds good. What about the sysfs thing? Should it be a debugfs thing > instead, assuming the below question will be resolved? > It's intended to be used by the power profiles daemon (PPD). I don't think debugfs is the right choice. See https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc >> As for the color accuracy topic, I think it is important that compositors >> can have full control over that if needed, while it's also important >> for HW vendors to optimize for power when absolute color accuracy is not >> needed. An average end-user writing code or working on their slides >> would rather have a longer battery life than a perfectly color-accurate >> display. We should probably think of a solution that can support both >> use-cases. > > I agree. Maybe this pondering should start from "how would it work from > end user perspective"? > > "Automatically" is probably be most desirable answer. Some kind of I agree > desktop settings with options like "save power at the expense of image > quality": > - always > - not if watching movies/gaming > - on battery > - on battery, unless I'm watching movies/gaming > - never > It's interesting that you split out movies/gaming, specifically. AMD's ABM algorithm seems to have considered movies in particular when evaluating the power/fidelity trade-off. I wouldn't think consumer media is very particular about a specific color fidelity (despite what HDR specs try to make you believe). Where color fidelity would matter to me is when I'd want to edit pictures or video. The "abm_level" property that we expose is really just that, a setting for the strength of the power-savings effect, with 0 being off and 4 being maximum strength and power saving, at the expense of fidelity. Mario's work is to let the PPD control it and set the ABM levels based on the selected power profile: 0 - Performance 1 - Balance 3 - Power And I believe we've looked at disabling ABM (setting it to 0) automatically if we know we're on AC power. > Or maybe there already is something like that, and it only needs to be > plumbed through? > > Which would point towards KMS clients needing to control it, which > means a generic KMS prop rather than vendor specific? > > Or should the desktop compositor be talking to some daemon instead of > KMS for this? Maybe they already are? > I think the intention is for the PPD to be that daemon. Mario can elaborate. Harry > > Thanks, > pq
Re: [PATCH] drm/amd: Only allow one entity to control ABM
On 2024-02-16 09:47, Christian König wrote:
> Am 16.02.24 um 15:42 schrieb Mario Limonciello:
>> On 2/16/2024 08:38, Christian König wrote:
>>> Am 16.02.24 um 15:07 schrieb Mario Limonciello:
>>>> By exporting ABM to sysfs it's possible that DRM master and software
>>>> controlling the sysfs file fight over the value programmed for ABM.
>>>>
>>>> Adjust the module parameter behavior to control who control ABM:
>>>> -2: DRM
>>>> -1: sysfs (IE via software like power-profiles-daemon)
>>>
>>> Well that sounds extremely awkward. Why should a power-profiles-deamon has
>>> control over the panel power saving features?
>>>
>>> I mean we are talking about things like reducing backlight level when the
>>> is inactivity, don't we?
>>
>> We're talking about activating the ABM algorithm when the system is in power
>> saving mode; not from inactivity. This allows the user to squeeze out some
>> extra power "just" in that situation.
>>
>> But given the comments on the other patch, I tend to agree with Harry's
>> proposal instead that we just drop the DRM property entirely as there are no
>> consumers of it.
>
> Yeah, but even then the design to let this be controlled by an userspace
> deamon is questionable. Stuff like that is handled inside the kernel and not
> exposed to userspace usually.
>
I think we'll need a bit in our kernel docs describing ABM. Assumptions around
what it is and does seem to lead to confusion.
The thing is that ABM has a visual impact that not all users like. It would
make sense for users to be able to change the ABM level as desired, and/or
configure their power profiles to select a certain ABM level.
ABM will reduce the backlight and compensate by adjusting brightness and
contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means off. 4 means
maximum backlight reduction. IMO, 1 and 2 look okay. 3 and 4 can be quite
impactful, both to power and visual fidelity.
Harry
> Regards,
> Christian.
>
>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>> 0-4: User via command line
>>>>
>>>> Also introduce a Kconfig option that allows distributions to choose
>>>> the default policy that is appropriate for them.
>>>>
>>>> Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry
>>>> to eDP connectors")
>>>> Signed-off-by: Mario Limonciello
>>>> ---
>>>> Cc: Hamza Mahfooz
>>>> Cc: Harry Wentland
>>>> Cc: Sun peng (Leo) Li
>>>> drivers/gpu/drm/amd/amdgpu/Kconfig | 72 +++
>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 23 +++---
>>>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +-
>>>> 3 files changed, 90 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>> b/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>> index 22d88f8ef527..2ab57ccf6f21 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
>>>> @@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
>>>> Add -Werror to the build flags for amdgpu.ko.
>>>> Only enable this if you are warning code for amdgpu.ko.
>>>> +choice
>>>> + prompt "Amdgpu panel power Savings"
>>>> + default AMDGPU_SYSFS_ABM
>>>> + help
>>>> + Control the default behavior for adaptive panel power savings.
>>>> +
>>>> + Panel power savings features will sacrifice color accuracy
>>>> + in exchange for power savings.
>>>> +
>>>> + This can be configured for:
>>>> + - dynamic control by the DRM master
>>>> + - dynamic control by sysfs nodes
>>>> + - statically by the user at kernel compile time
>>>> +
>>>> + This value can also be overridden by the amdgpu.abmlevel
>>>> + module parameter.
>>>> +
>>>> +config AMDGPU_DRM_ABM
>>>> + bool "DRM Master control"
>>>> + help
>>>> + Export a property called 'abm_level' that can be
>>>> + manipulated by the DRM master for supported hardware.
>>>> +
>>>> +config AMDGPU_SYSFS_ABM
>>>> + bool "sysfs control"
>>>> + help
>>>> + Export a sysfs file 'panel_power_savin
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2024-02-16 03:19, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 10:28:35 -0500
> Hamza Mahfooz wrote:
>
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features.
>
> Could you also explain why, in the commit message, please?
>
> It is unexpected for arbitrary programs to be able to override the KMS
> client, and certainly new ways to do so should not be added without an
> excellent justification.
>
> Maybe debugfs would be more appropriate if the purpose is only testing
> rather than production environments?
>
>> However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
>
> When the DRM property was added, what was used as the userspace to
> prove its workings?
>
I don't think there ever was a userspace implementation and doubt any
exists today. Part of that is on me. In hindsight, the KMS prop should
have never gone upstream.
I suggest we drop the KMS prop entirely.
As for the color accuracy topic, I think it is important that compositors
can have full control over that if needed, while it's also important
for HW vendors to optimize for power when absolute color accuracy is not
needed. An average end-user writing code or working on their slides
would rather have a longer battery life than a perfectly color-accurate
display. We should probably think of a solution that can support both
use-cases.
Harry
>
> Thanks,
> pq
>
>>
>> Cc: Mario Limonciello
>> Signed-off-by: Hamza Mahfooz
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>> commit when setting the value, call sysfs_remove_group() in
>> amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
>> 1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
>> drm_connector *connector,
>> return ret;
>> }
>>
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power
>> savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +struct device_attribute *attr,
>> +char *buf)
>> +{
>> +struct drm_connector *connector = dev_get_drvdata(device);
>> +struct drm_device *dev = connector->dev;
>> +u8 val;
>> +
>> +drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> +val = to_dm_connector_state(connector->state)->abm_level ==
>> +ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +to_dm_connector_state(connector->state)->abm_level;
>> +drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> +return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> +struct drm_connector *connector = dev_get_drvdata(device);
>> +struct drm_device *dev = connector->dev;
>> +long val;
>> +int ret;
>> +
>> +ret = kstrtol(buf, 0, );
>> +
>> +if (ret)
>> +return ret;
>> +
>> +if (val < 0 || val > 4)
>> +return -EINVAL;
>> +
>> +drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> +to_dm_connector_state(connector->state)->abm_level = val ?:
>> +ABM_LEVEL_IMMEDIATE_DISABLE;
>> +drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> +drm_kms_helper_hotplug_event(dev);
>> +
>> +return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +_attr_panel_power_savings.attr,
>> +NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +.name = "amdgpu",
>> +.attrs = amdgpu_attrs
>> +};
>> +
>> static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>> {
>> struct amdgpu_dm_connector *amdgpu_dm_connector =
>> to_amdgpu_dm_connector(connector);
>>
>> +sysfs_remove_group(>kdev->kobj, _group);
>> drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
>> }
>>
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct
>>
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2024-02-02 11:20, Mario Limonciello wrote:
> On 2/2/2024 09:28, Hamza Mahfooz wrote:
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features. However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
>>
I've been trying to avoid looking at this too closely, partly because
I want ABM enablement by default, with control for users. But the
more I think about this the more uncomfortable I get. The key for my
discomfort is that we're going around the back of DRM master to set
a DRM property. This is apt to create lots of weird behaviors,
especially if compositors also decide to implement support for the
abm_level property and then potentially fight PPD, or other users
of this sysfs.
I'm also not sure a new sysfs is a good candidate for drm-fixes.
Harry
>> Cc: Mario Limonciello
>> Signed-off-by: Hamza Mahfooz
>
> Reviewed-by: Mario Limonciello
> Tested-by: Mario Limonciello
>
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>> commit when setting the value, call sysfs_remove_group() in
>> amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
>> 1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
>> drm_connector *connector,
>> return ret;
>> }
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power
>> savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct drm_connector *connector = dev_get_drvdata(device);
>> + struct drm_device *dev = connector->dev;
>> + u8 val;
>> +
>> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> + val = to_dm_connector_state(connector->state)->abm_level ==
>> + ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> + to_dm_connector_state(connector->state)->abm_level;
>> + drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> + return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct drm_connector *connector = dev_get_drvdata(device);
>> + struct drm_device *dev = connector->dev;
>> + long val;
>> + int ret;
>> +
>> + ret = kstrtol(buf, 0, );
>> +
>> + if (ret)
>> + return ret;
>> +
>> + if (val < 0 || val > 4)
>> + return -EINVAL;
>> +
>> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> + to_dm_connector_state(connector->state)->abm_level = val ?:
>> + ABM_LEVEL_IMMEDIATE_DISABLE;
>> + drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> + drm_kms_helper_hotplug_event(dev);
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> + _attr_panel_power_savings.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> + .name = "amdgpu",
>> + .attrs = amdgpu_attrs
>> +};
>> +
>> static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>> {
>> struct amdgpu_dm_connector *amdgpu_dm_connector =
>> to_amdgpu_dm_connector(connector);
>> + sysfs_remove_group(>kdev->kobj, _group);
>> drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
>> }
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct
>> drm_connector *connector)
>> to_amdgpu_dm_connector(connector);
>> int r;
>> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> + r = sysfs_create_group(>kdev->kobj,
>> + _group);
>> + if (r)
>> + return r;
>> + }
>> +
>> amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>> if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
Re: [PATCH] drm/amd/display: Clear phantom stream count and plane count
On 2024-02-05 08:54, Deucher, Alexander wrote:
> [Public]
>
>
> [Public]
>
>
> Acked-by: Alex Deucher
>
Reviewed-by: Harry Wentland
Harry
--
> *From:* amd-gfx on behalf of Mario
> Limonciello
> *Sent:* Friday, February 2, 2024 7:30 PM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* Limonciello, Mario
> *Subject:* [PATCH] drm/amd/display: Clear phantom stream count and plane count
>
> When dc_state_destruct() was refactored the new phantom_stream_count
> and phantom_plane_count members weren't cleared.
>
> Fixes: 012a04b1d6af ("drm/amd/display: Refactor phantom resource allocation")
> Signed-off-by: Mario Limonciello
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_state.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> index 88c6436b28b6..180ac47868c2 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> @@ -291,11 +291,14 @@ void dc_state_destruct(struct dc_state *state)
> dc_stream_release(state->phantom_streams[i]);
> state->phantom_streams[i] = NULL;
> }
> + state->phantom_stream_count = 0;
>
> for (i = 0; i < state->phantom_plane_count; i++) {
> dc_plane_state_release(state->phantom_planes[i]);
> state->phantom_planes[i] = NULL;
> }
> + state->phantom_plane_count = 0;
> +
> state->stream_mask = 0;
> memset(>res_ctx, 0, sizeof(state->res_ctx));
> memset(>pp_display_cfg, 0, sizeof(state->pp_display_cfg));
> --
> 2.34.1
>
Re: [PATCH] drm/amd/display: only call sysfs_remove_group() for eDP connectors
On 2024-02-05 10:18, Hamza Mahfooz wrote:
> Since we only register the amdgpu sysfs group for eDP connectors, we
> should only remove it from them. Otherwise, we run into a harmless
> WARN() on device detach for all of the device's non-eDP connectors.
>
> Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to
> eDP connectors")
> Signed-off-by: Hamza Mahfooz
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index adda423615a1..b3a5e730be24 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6508,7 +6508,9 @@ static void amdgpu_dm_connector_unregister(struct
> drm_connector *connector)
> {
> struct amdgpu_dm_connector *amdgpu_dm_connector =
> to_amdgpu_dm_connector(connector);
>
> - sysfs_remove_group(>kdev->kobj, _group);
> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + sysfs_remove_group(>kdev->kobj, _group);
> +
> drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
> }
>
Re: [PATCH v2 2/2] drm/amdgpu: Implement check_async_props for planes
On 2024-01-23 13:02, Xaver Hugl wrote:
> Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
> :
>>
>>
>>
>> On 2024-01-19 13:25, Ville Syrjälä wrote:
>>> On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
>>>> AMD GPUs can do async flips with changes on more properties than just
>>>> the FB ID, so implement a custom check_async_props for AMD planes.
>>>>
>>>> Allow amdgpu to do async flips with IN_FENCE_ID and FB_DAMAGE_CLIPS
>>>> properties. For userspace to check if a driver support this two
>>>> properties, the strategy for now is to use TEST_ONLY commits.
>>>>
>>>> Signed-off-by: André Almeida
>>>> ---
>>>> v2: Drop overlay plane option for now
>>>>
>>>> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 29 +++
>>>> 1 file changed, 29 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
>>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
>>>> index 116121e647ca..7afe8c1b62d4 100644
>>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
>>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
>>>> @@ -25,6 +25,7 @@
>>>>*/
>>>>
>>>> #include
>>>> +#include
>>>> #include
>>>> #include
>>>> #include
>>>> @@ -1430,6 +1431,33 @@ static void
>>>> amdgpu_dm_plane_drm_plane_destroy_state(struct drm_plane *plane,
>>>> drm_atomic_helper_plane_destroy_state(plane, state);
>>>> }
>>>>
>>>> +static int amdgpu_dm_plane_check_async_props(struct drm_property *prop,
>>>> + struct drm_plane *plane,
>>>> + struct drm_plane_state *plane_state,
>>>> + struct drm_mode_object *obj,
>>>> + u64 prop_value, u64 old_val)
>>>> +{
>>>> +struct drm_mode_config *config = >dev->mode_config;
>>>> +int ret;
>>>> +
>>>> +if (prop != config->prop_fb_id &&
>>>> +prop != config->prop_in_fence_fd &&
>>>
>>> IN_FENCE should just be allowed always.
>>>
>>>> +prop != config->prop_fb_damage_clips) {
>>>
>>> This seems a bit dubious to me. How is amdgpu using the damage
>>> information during async flips?
>>
>> Yeah, I'm also not sure this is right. Has anyone tested this
>> with a PSR SU panel?
>>
>> Harry
>
> I attempted to, but according to
> /sys/kernel/debug/dri/1/eDP-1/psr_state, PSR never kicks in on my
> laptop at all. The only reason I wanted this property though is to
> reduce the number of special cases for async pageflips compositors
> have to implement; as it's not necessary for any functionality I think
> it's also fine to leave it out.
>
Yeah, PSR panels aren't super common. PSR SU (Selective Update) panels
even less so.
I'd prefer to keep the damage clips out of async for now unless we
can actually test it with a PSR SU panel.
Harry
>>>> +ret = drm_atomic_plane_get_property(plane, plane_state,
>>>> +prop, _val);
>>>> +return drm_atomic_check_prop_changes(ret, old_val,
>>>> prop_value, prop);
>>>> +}
>>>> +
>>>> +if (plane_state->plane->type != DRM_PLANE_TYPE_PRIMARY) {
>>>> +drm_dbg_atomic(prop->dev,
>>>> + "[OBJECT:%d] Only primary planes can be
>>>> changed during async flip\n",
>>>> + obj->id);
>>>> +return -EINVAL;
>>>> +}
>>>> +
>>>> +return 0;
>>>> +}
>>>> +
>>>> static const struct drm_plane_funcs dm_plane_funcs = {
>>>> .update_plane = drm_atomic_helper_update_plane,
>>>> .disable_plane = drm_atomic_helper_disable_plane,
>>>> @@ -1438,6 +1466,7 @@ static const struct drm_plane_funcs dm_plane_funcs =
>>>> {
>>>> .atomic_duplicate_state = amdgpu_dm_plane_drm_plane_duplicate_state,
>>>> .atomic_destroy_state = amdgpu_dm_plane_drm_plane_destroy_state,
>>>> .format_mod_supported = amdgpu_dm_plane_format_mod_supported,
>>>> +.check_async_props = amdgpu_dm_plane_check_async_props,
>>>> };
>>>>
>>>> int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
>>>> --
>>>> 2.43.0
>>>
Re: [PATCH] drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
On 2024-01-23 10:01, Srinivasan Shanmugam wrote:
> Tell snprintf() to store at most 10 bytes in the output buffer
> instead of 30.
>
> Fixes the below:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508
> dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10
>
> Fixes: c06e09b76639 ("drm/amd/display: Add DSC parameters logging to debugfs")
> Cc: Alex Hung
> Cc: Qingqing Zhuo
> Cc: Rodrigo Siqueira
> Cc: Aurabindo Pillai
> Cc: Alex Deucher
> Signed-off-by: Srinivasan Shanmugam
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 68a846323912..85fc6181303b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -1483,7 +1483,7 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
> const uint32_t rd_buf_size = 10;
> struct pipe_ctx *pipe_ctx;
> ssize_t result = 0;
> - int i, r, str_len = 30;
> + int i, r, str_len = 10;
>
> rd_buf = kcalloc(rd_buf_size, sizeof(char), GFP_KERNEL);
>
Re: [PATCH v2 2/2] drm/amdgpu: Implement check_async_props for planes
On 2024-01-19 13:25, Ville Syrjälä wrote:
On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
AMD GPUs can do async flips with changes on more properties than just
the FB ID, so implement a custom check_async_props for AMD planes.
Allow amdgpu to do async flips with IN_FENCE_ID and FB_DAMAGE_CLIPS
properties. For userspace to check if a driver support this two
properties, the strategy for now is to use TEST_ONLY commits.
Signed-off-by: André Almeida
---
v2: Drop overlay plane option for now
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 116121e647ca..7afe8c1b62d4 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -25,6 +25,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1430,6 +1431,33 @@ static void
amdgpu_dm_plane_drm_plane_destroy_state(struct drm_plane *plane,
drm_atomic_helper_plane_destroy_state(plane, state);
}
+static int amdgpu_dm_plane_check_async_props(struct drm_property *prop,
+ struct drm_plane *plane,
+ struct drm_plane_state *plane_state,
+ struct drm_mode_object *obj,
+ u64 prop_value, u64 old_val)
+{
+ struct drm_mode_config *config = >dev->mode_config;
+ int ret;
+
+ if (prop != config->prop_fb_id &&
+ prop != config->prop_in_fence_fd &&
IN_FENCE should just be allowed always.
+ prop != config->prop_fb_damage_clips) {
This seems a bit dubious to me. How is amdgpu using the damage
information during async flips?
Yeah, I'm also not sure this is right. Has anyone tested this
with a PSR SU panel?
Harry
+ ret = drm_atomic_plane_get_property(plane, plane_state,
+ prop, _val);
+ return drm_atomic_check_prop_changes(ret, old_val, prop_value,
prop);
+ }
+
+ if (plane_state->plane->type != DRM_PLANE_TYPE_PRIMARY) {
+ drm_dbg_atomic(prop->dev,
+ "[OBJECT:%d] Only primary planes can be changed
during async flip\n",
+ obj->id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct drm_plane_funcs dm_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -1438,6 +1466,7 @@ static const struct drm_plane_funcs dm_plane_funcs = {
.atomic_duplicate_state = amdgpu_dm_plane_drm_plane_duplicate_state,
.atomic_destroy_state = amdgpu_dm_plane_drm_plane_destroy_state,
.format_mod_supported = amdgpu_dm_plane_format_mod_supported,
+ .check_async_props = amdgpu_dm_plane_check_async_props,
};
int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
--
2.43.0
Re: [PATCH v3 0/9] drm/amd/display: improve DTN color state log
000 4294967296 00 > [ 3]:Bypass Bypass Bypass 12-bit 9x9x9 > BypassSW 4294967296 00 00 00 00 > 4294967296 00 00 00 00 4294967296 00 > > DPP Color Caps: input_lut_shared:0 icsc:1 dgam_ram:1 dgam_rom: > srgb:1,bt2020:1,gamma2_2:0,pq:0,hlg:0 post_csc:0 gamcor:0 > dgam_rom_for_yuv:1 3d_lut:1 blnd_lut:1 oscs:0 > > MPCC: OPP DPP MPCCBOT MODE ALPHA_MODE PREMULT OVERLAP_ONLY IDLE OGAM > mode > [ 0]: 0h 0h 3h 3 20 0 0 > RAM A > [ 3]: 0h 3h fh 2 20 0 0 > Bypass > > MPC Color Caps: gamut_remap:0, 3dlut:0, ogam_ram:1, ocsc:1 > > === > > Let me know your thoughts. > Thanks for improving this. The series is Reviewed-by: Harry Wentland I'll merge it over the next day or two (depending on how well our CI cooperates). Harry > Melissa > > [1] https://lore.kernel.org/amd-gfx/20230913164329.123687-1-m...@igalia.com/ > [2] https://lore.kernel.org/amd-gfx/20231116195812.906115-1-m...@igalia.com/ > [3] > https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png > > > Harry Wentland (1): > drm/amd/display: Add dpp_get_gamut_remap functions > > Melissa Wen (8): > drm/amd/display: decouple color state from hw state log > drm/amd/display: read gamut remap matrix in fixed-point 31.32 format > drm/amd/display: fill up DCN3 DPP color state > drm/amd/display: add get_gamut_remap helper for MPC3 > drm/amd/display: create DCN3-specific log for MPC state > drm/amd/display: hook up DCN30 color blocks data to DTN log > drm/amd/display: add DPP and MPC color caps to DTN log > drm/amd/display: hook up DCN20 color blocks data to DTN log > > .../drm/amd/display/dc/basics/conversion.c| 34 > .../drm/amd/display/dc/basics/conversion.h| 4 + > .../amd/display/dc/dcn10/dcn10_cm_common.c| 20 +++ > .../amd/display/dc/dcn10/dcn10_cm_common.h| 4 +- > .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 3 +- > .../gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 3 + > .../drm/amd/display/dc/dcn10/dcn10_dpp_cm.c | 70 +++- > .../gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c | 31 ++-- > .../gpu/drm/amd/display/dc/dcn20/dcn20_dpp.h | 3 + > .../drm/amd/display/dc/dcn20/dcn20_dpp_cm.c | 55 +++ > .../gpu/drm/amd/display/dc/dcn20/dcn20_init.c | 1 + > .../gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 24 ++- > .../drm/amd/display/dc/dcn201/dcn201_dpp.c| 1 + > .../gpu/drm/amd/display/dc/dcn21/dcn21_init.c | 1 + > .../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 38 - > .../gpu/drm/amd/display/dc/dcn30/dcn30_dpp.h | 2 + > .../drm/amd/display/dc/dcn30/dcn30_dpp_cm.c | 54 +++ > .../gpu/drm/amd/display/dc/dcn30/dcn30_init.c | 1 + > .../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.c | 106 - > .../gpu/drm/amd/display/dc/dcn30/dcn30_mpc.h | 4 + > .../drm/amd/display/dc/dcn301/dcn301_init.c | 1 + > .../gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 1 + > .../drm/amd/display/dc/dcn314/dcn314_init.c | 1 + > .../gpu/drm/amd/display/dc/dcn32/dcn32_dpp.c | 1 + > .../amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 90 --- > .../amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 106 + > .../amd/display/dc/hwss/dcn20/dcn20_hwseq.h | 2 + > .../amd/display/dc/hwss/dcn30/dcn30_hwseq.c | 149 ++ > .../amd/display/dc/hwss/dcn30/dcn30_hwseq.h | 3 + > .../drm/amd/display/dc/hwss/hw_sequencer.h| 2 + > drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 14 ++ > drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h | 7 + > 32 files changed, 795 insertions(+), 41 deletions(-) >
Re: Documentation for RGB strip on RX 7900 XTX (Reference)
On 2024-01-09 03:31, Christian König wrote: > Am 09.01.24 um 09:23 schrieb Alexander Koskovich: >> Thanks for the info, will take a look. >> >> Also just to clarify, this is the first party AMD 7900 XTX, not a third >> party AIB (e.g. Sapphire, ASRock, etc). > > Yeah, but that doesn't matter. > > For the reference designs AMD basically just says how it should look like and > then somebody else stitches it together. The handling of for example how > connectors are detected is still the same. > > AMD should somewhere have detailed documentation what's on that reference > board, but to be honest I have absolutely no idea who to ask for that. It's > simpler to just look into the tables used by all vendors. > > Regards, > Christian. > >> >> >> On Tuesday, January 9th, 2024 at 3:02 AM, Christian König >> wrote: >> >> >>> >>> Am 08.01.24 um 23:32 schrieb Deucher, Alexander: >>> [Public] > -Original Message- > From: amd-gfx amd-gfx-boun...@lists.freedesktop.org On Behalf Of > Alexander Koskovich > Sent: Sunday, January 7, 2024 11:19 PM > To: amd-gfx@lists.freedesktop.org > Subject: Documentation for RGB strip on RX 7900 XTX (Reference) > > Hello, > > I was wondering if AMD would be able provide any documentation for the > RGB strip on the reference cooler > (https://www.amd.com/en/products/graphics/amd-radeon-rx-7900xtx)? It > looks to be handled via I2C commands to the SMU, but having proper > documentation would be extremely helpful. > It depends on the AIB/OEM and how they designed the specific board. The > RGB controller will either be attached to the DDCVGA i2c bus on the > display hardware or the second SMU i2c bus. The former will require > changes to the amdgpu display code to register display i2c buses that are > not used by the display connectors on the board so they can be used by > 3rd party applications. Currently we only register i2c buses used for > display connectors. The latter buses are already registered with the i2c > subsystem since they are used for other things like EEPROMs on server and > workstation cards and should be available via standard Linux i2c APIs. > I'm not sure what i2c LED controllers each AIB vendor uses off hand. > https://openrgb.org/index.html would probably be a good resource for that > information. >>> >>> >>> It might also be a good idea to look some of the ATOMBIOS tables found >>> on your device. >>> >>> Those tables are filled in by the AIB/OEM with the information which >>> connectors (HDMI, DVI, DP etc...) are on the board and I bet that the >>> information which RGB controller is used and where to find it is >>> somewhere in there as well. >>> >>> Adding Harry from our display team, might be that he has some more hints >>> as well. >>> I don't know how the RGB strips are connected and controlled. Harry >>> Christian. >>> Alex >
[PATCH 1/2] drm/amd/display: Fix recent checkpatch errors in amdgpu_dm
- Use tabs, not spaces.
- Brace and parentheses placement
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 ++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 5 ++---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 2d5af83d40b5..9c1871b866cc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -747,7 +747,7 @@ enum amdgpu_transfer_function {
AMDGPU_TRANSFER_FUNCTION_GAMMA22_INV_EOTF,
AMDGPU_TRANSFER_FUNCTION_GAMMA24_INV_EOTF,
AMDGPU_TRANSFER_FUNCTION_GAMMA26_INV_EOTF,
-AMDGPU_TRANSFER_FUNCTION_COUNT
+ AMDGPU_TRANSFER_FUNCTION_COUNT
};
struct dm_plane_state {
@@ -844,7 +844,7 @@ struct dm_crtc_state {
int abm_level;
-/**
+ /**
* @regamma_tf:
*
* Pre-defined transfer function for converting internal FB -> wire
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index c6ed0d854b01..36bf65a8cd6e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -630,8 +630,7 @@ static int __set_input_tf(struct dc_color_caps *caps,
struct dc_transfer_func *f
static enum dc_transfer_func_predefined
amdgpu_tf_to_dc_tf(enum amdgpu_transfer_function tf)
{
- switch (tf)
- {
+ switch (tf) {
default:
case AMDGPU_TRANSFER_FUNCTION_DEFAULT:
case AMDGPU_TRANSFER_FUNCTION_IDENTITY:
@@ -1225,7 +1224,7 @@ int amdgpu_dm_update_plane_color_mgmt(struct
dm_crtc_state *crtc,
* plane and CRTC degamma at the same time. Explicitly reject atomic
* updates when userspace sets both plane and CRTC degamma properties.
*/
- if (has_crtc_cm_degamma && ret != -EINVAL){
+ if (has_crtc_cm_degamma && ret != -EINVAL) {
drm_dbg_kms(crtc->base.crtc->dev,
"doesn't support plane and CRTC degamma at the same
time\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 4439e5a27362..6e715ef3a556 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -305,7 +305,7 @@ dm_crtc_additional_color_mgmt(struct drm_crtc *crtc)
{
struct amdgpu_device *adev = drm_to_adev(crtc->dev);
- if(adev->dm.dc->caps.color.mpc.ogam_ram)
+ if (adev->dm.dc->caps.color.mpc.ogam_ram)
drm_object_attach_property(>base,
adev->mode_info.regamma_tf_property,
AMDGPU_TRANSFER_FUNCTION_DEFAULT);
--
2.43.0
[PATCH 2/2] drm/amd/display: Move fixpt_from_s3132 to amdgpu_dm
Other environments don't like the unary minus operator on
an unsigned value.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c| 18 +++---
.../gpu/drm/amd/display/include/fixed31_32.h | 12
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 36bf65a8cd6e..9b527bffe11a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -85,6 +85,18 @@ void amdgpu_dm_init_color_mod(void)
setup_x_points_distribution();
}
+static inline struct fixed31_32 amdgpu_dm_fixpt_from_s3132(__u64 x)
+{
+ struct fixed31_32 val;
+
+ /* If negative, convert to 2's complement. */
+ if (x & (1ULL << 63))
+ x = -(x & ~(1ULL << 63));
+
+ val.value = x;
+ return val;
+}
+
#ifdef AMD_PRIVATE_COLOR
/* Pre-defined Transfer Functions (TF)
*
@@ -430,7 +442,7 @@ static void __drm_ctm_to_dc_matrix(const struct
drm_color_ctm *ctm,
}
/* gamut_remap_matrix[i] = ctm[i - floor(i/4)] */
- matrix[i] = dc_fixpt_from_s3132(ctm->matrix[i - (i / 4)]);
+ matrix[i] = amdgpu_dm_fixpt_from_s3132(ctm->matrix[i - (i /
4)]);
}
}
@@ -452,7 +464,7 @@ static void __drm_ctm_3x4_to_dc_matrix(const struct
drm_color_ctm_3x4 *ctm,
*/
for (i = 0; i < 12; i++) {
/* gamut_remap_matrix[i] = ctm[i - floor(i/4)] */
- matrix[i] = dc_fixpt_from_s3132(ctm->matrix[i]);
+ matrix[i] = amdgpu_dm_fixpt_from_s3132(ctm->matrix[i]);
}
}
@@ -1136,7 +1148,7 @@ amdgpu_dm_plane_set_color_properties(struct
drm_plane_state *plane_state,
uint32_t shaper_size, lut3d_size, blend_size;
int ret;
- dc_plane_state->hdr_mult =
dc_fixpt_from_s3132(dm_plane_state->hdr_mult);
+ dc_plane_state->hdr_mult =
amdgpu_dm_fixpt_from_s3132(dm_plane_state->hdr_mult);
shaper_lut = __extract_blob_lut(dm_plane_state->shaper_lut,
_size);
shaper_size = shaper_lut != NULL ? shaper_size : 0;
diff --git a/drivers/gpu/drm/amd/display/include/fixed31_32.h
b/drivers/gpu/drm/amd/display/include/fixed31_32.h
index 84da1dd34efd..d4cf7ead1d87 100644
--- a/drivers/gpu/drm/amd/display/include/fixed31_32.h
+++ b/drivers/gpu/drm/amd/display/include/fixed31_32.h
@@ -69,18 +69,6 @@ static const struct fixed31_32 dc_fixpt_epsilon = { 1LL };
static const struct fixed31_32 dc_fixpt_half = { 0x8000LL };
static const struct fixed31_32 dc_fixpt_one = { 0x1LL };
-static inline struct fixed31_32 dc_fixpt_from_s3132(__u64 x)
-{
- struct fixed31_32 val;
-
- /* If negative, convert to 2's complement. */
- if (x & (1ULL << 63))
- x = -(x & ~(1ULL << 63));
-
- val.value = x;
- return val;
-}
-
/*
* @brief
* Initialization routines
--
2.43.0
Re: [PATCH] drm/amd/display: disable FPO and SubVP for older DMUB versions on DCN32x
On 2023-12-15 11:01, Hamza Mahfooz wrote:
> There have recently been changes that break backwards compatibility,
Please start an internal thread with the DMUB guys about this. We
shouldn't really break backwards compatibility with FW. Include Alex D.
and myself, please.
> that were introduced into DMUB firmware (for DCN32x) concerning FPO and
> SubVP. So, since those are just power optimization features, we can just
> disable them unless the user is using a new enough version of DMUB
> firmware.
>
I don't really like disabling this and don't fully understand whether
this won't break something else. But we also shouldn't crash, so this
change is
Reviewed-by: Harry Wentland
Harry
> Cc: sta...@vger.kernel.org
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2870
> Fixes: ed6e2782e974 ("drm/amd/display: For cursor P-State allow for SubVP")
> Reported-by: Mikhail Gavrilov
> Closes:
> https://lore.kernel.org/r/cabxgcsnrb0qbf2pkljmdhvokxygd6-e+8p-4qo6fowa6zp2...@mail.gmail.com/
> Signed-off-by: Hamza Mahfooz
> ---
> drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
> b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
> index 5c323718ec90..0f0972ad441a 100644
> --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c
> @@ -960,6 +960,12 @@ void dcn32_init_hw(struct dc *dc)
> dc->caps.dmub_caps.subvp_psr =
> dc->ctx->dmub_srv->dmub->feature_caps.subvp_psr_support;
> dc->caps.dmub_caps.gecc_enable =
> dc->ctx->dmub_srv->dmub->feature_caps.gecc_enable;
> dc->caps.dmub_caps.mclk_sw =
> dc->ctx->dmub_srv->dmub->feature_caps.fw_assisted_mclk_switch;
> +
> + if (dc->ctx->dmub_srv->dmub->fw_version <
> + DMUB_FW_VERSION(7, 0, 35)) {
> + dc->debug.force_disable_subvp = true;
> + dc->debug.disable_fpo_optimizations = true;
> + }
> }
> }
>
Re: [PATCH] drm/amd/display: Add a new DC debug mask for PSR-SU
On 2023-12-14 16:12, Mario Limonciello wrote:
> Some issues have been raised that appear to be tied to PSR-SU.
> To allow users to confirm they're tied to PSR-SU without turning off
> PSR entirely introduce a new debug mask:
>
> amdgpu.dcdebugmask=0x200
>
> Signed-off-by: Mario Limonciello
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 +++
> drivers/gpu/drm/amd/include/amd_shared.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> index 08ce3bb8f640..1f08c6564c3b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> @@ -51,6 +51,9 @@ static bool link_supports_psrsu(struct dc_link *link)
> !link->dpcd_caps.psr_info.psr2_su_y_granularity_cap)
> return false;
>
> + if (amdgpu_dc_debug_mask & DC_DISABLE_PSR_SU)
> + return false;
> +
> return dc_dmub_check_min_version(dc->ctx->dmub_srv->dmub);
> }
>
> diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
> b/drivers/gpu/drm/amd/include/amd_shared.h
> index ade68972ec28..5cad456f2e10 100644
> --- a/drivers/gpu/drm/amd/include/amd_shared.h
> +++ b/drivers/gpu/drm/amd/include/amd_shared.h
> @@ -256,6 +256,7 @@ enum DC_DEBUG_MASK {
> DC_DISABLE_MPO = 0x40,
> DC_ENABLE_DPIA_TRACE = 0x80,
> DC_ENABLE_DML2 = 0x100,
> + DC_DISABLE_PSR_SU = 0x200,
> };
>
> enum amd_dpm_forced_level;
Re: [PATCH] drm/amd/display: Disable PSR-SU on Parade 0803 TCON again
On 2023-12-09 15:08, Mario Limonciello wrote:
> When screen brightness is rapidly changed and PSR-SU is enabled the
> display hangs on panels with this TCON even on the latest DCN 3.1.4
> microcode (0x8002a81 at this time).
>
> This was disabled previously as commit 072030b17830 ("drm/amd: Disable
> PSR-SU on Parade 0803 TCON") but reverted as commit 1e66a17ce546 ("Revert
> "drm/amd: Disable PSR-SU on Parade 0803 TCON"") in favor of testing for
> a new enough microcode (commit cd2e31a9ab93 ("drm/amd/display: Set minimum
> requirement for using PSR-SU on Phoenix")).
>
> As hangs are still happening specifically with this TCON, disable PSR-SU
> again for it until it can be root caused.
>
> Cc: sta...@vger.kernel.org
> Cc: aaron...@canonical.com
> Cc: bi...@gnome.org
> Cc: Marc Rossi
> Cc: Hamza Mahfooz
> Signed-off-by: Mario Limonciello
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> index a522a7c02911..1675314a3ff2 100644
> --- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> +++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c
> @@ -839,6 +839,8 @@ bool is_psr_su_specific_panel(struct dc_link *link)
> ((dpcd_caps->sink_dev_id_str[1] == 0x08 &&
> dpcd_caps->sink_dev_id_str[0] == 0x08) ||
> (dpcd_caps->sink_dev_id_str[1] == 0x08 &&
> dpcd_caps->sink_dev_id_str[0] == 0x07)))
> isPSRSUSupported = false;
> + else if (dpcd_caps->sink_dev_id_str[1] == 0x08 &&
> dpcd_caps->sink_dev_id_str[0] == 0x03)
> + isPSRSUSupported = false;
> else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1)
> isPSRSUSupported = true;
> }
Re: [PATCH] drm/amd/display: fix cursor-plane-only atomic commits not triggering pageflips
On 2023-12-07 14:30, Xaver Hugl wrote:
Sorry, it looks like I sent this too soon. I tested the patch on a
second PC and it doesn't fix the issue there.
Ah, too bad. Won't merge it then.
Harry
Am Do., 7. Dez. 2023 um 19:25 Uhr schrieb Xaver Hugl :
With VRR, every atomic commit affecting a given display must trigger
a new scanout cycle, so that userspace is able to control the refresh
rate of the display. Before this commit, this was not the case for
atomic commits that only contain cursor plane properties.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034
Cc: sta...@vger.kernel.org
Signed-off-by: Xaver Hugl
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b452796fc6d3..b379c859fbef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8149,9 +8149,15 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
/* Cursor plane is handled after stream updates */
if (plane->type == DRM_PLANE_TYPE_CURSOR) {
if ((fb && crtc == pcrtc) ||
- (old_plane_state->fb && old_plane_state->crtc ==
pcrtc))
+ (old_plane_state->fb && old_plane_state->crtc ==
pcrtc)) {
cursor_update = true;
-
+ /*
+* With atomic modesetting, cursor changes must
+* also trigger a new refresh period with vrr
+*/
+ if (!state->legacy_cursor_update)
+ pflip_present = true;
+ }
continue;
}
--
2.43.0
Re: [PATCH] drm/amd/display: fix cursor-plane-only atomic commits not triggering pageflips
On 2023-12-07 13:25, Xaver Hugl wrote:
With VRR, every atomic commit affecting a given display must trigger
a new scanout cycle, so that userspace is able to control the refresh
rate of the display. Before this commit, this was not the case for
atomic commits that only contain cursor plane properties.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034
Cc: sta...@vger.kernel.org
Signed-off-by: Xaver Hugl
Reviewed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b452796fc6d3..b379c859fbef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8149,9 +8149,15 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
/* Cursor plane is handled after stream updates */
if (plane->type == DRM_PLANE_TYPE_CURSOR) {
if ((fb && crtc == pcrtc) ||
- (old_plane_state->fb && old_plane_state->crtc ==
pcrtc))
+ (old_plane_state->fb && old_plane_state->crtc ==
pcrtc)) {
cursor_update = true;
-
+ /*
+* With atomic modesetting, cursor changes must
+* also trigger a new refresh period with vrr
+*/
+ if (!state->legacy_cursor_update)
+ pflip_present = true;
+ }
continue;
}
Re: [PATCH] drm/amd/display: Restore guard against default backlight value < 1 nit
On 2023-12-07 10:03, Alex Deucher wrote:
> On Thu, Dec 7, 2023 at 9:47 AM Mario Limonciello
> wrote:
>>
>> Mark reports that brightness is not restored after Xorg dpms screen blank.
>>
>> This behavior was introduced by commit d9e865826c20 ("drm/amd/display:
>> Simplify brightness initialization") which dropped the cached backlight
>> value in display code, but also removed code for when the default value
>> read back was less than 1 nit.
>>
>> Restore this code so that the backlight brightness is restored to the
>> correct default value in this circumstance.
>>
>> Reported-by: Mark Herbert
>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3031
>> Cc: sta...@vger.kernel.org
>> Cc: Camille Cho
>> Cc: Krunoslav Kovac
>> Cc: Hamza Mahfooz
>> Fixes: d9e865826c20 ("drm/amd/display: Simplify brightness initialization")
>> Signed-off-by: Mario Limonciello
>
> Acked-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
>
>> ---
>> .../amd/display/dc/link/protocols/link_edp_panel_control.c| 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
>> b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
>> index ac0fa88b52a0..bf53a86ea817 100644
>> --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
>> +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
>> @@ -287,8 +287,8 @@ bool set_default_brightness_aux(struct dc_link *link)
>> if (link && link->dpcd_sink_ext_caps.bits.oled == 1) {
>> if (!read_default_bl_aux(link, _backlight))
>> default_backlight = 15;
>> - // if > 5000, it might be wrong readback
>> - if (default_backlight > 500)
>> + // if < 1 nits or > 5000, it might be wrong readback
>> + if (default_backlight < 1000 || default_backlight > 500)
>> default_backlight = 15;
>>
>> return edp_set_backlight_level_nits(link, true,
>> --
>> 2.34.1
>>
Re: [PATCH v2 2/8] drm/amdgpu: Do not include
On 2023-12-04 04:07, Thomas Zimmermann wrote: > Remove unnecessary include statements for . > The file contains helpers for non-atomic code and should not be > required by most drivers. No functional changes. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index aa43f1761acd3..b8c3a9b104a41 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -92,7 +92,6 @@ > #include > #include > #include > -#include > > #include >
Re: [PATCH v5 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt
On 2023-11-30 06:34, Daniel Vetter wrote: > On Tue, 28 Nov 2023 at 23:11, Harry Wentland wrote: >> >> On 2023-11-16 14:57, Melissa Wen wrote: >>> Hello, >>> >>> This series extends the current KMS color management API with AMD >>> driver-specific properties to enhance the color management support on >>> AMD Steam Deck. The key additions to the color pipeline include: >>> >> >> snip >> >>> Melissa Wen (18): >>> drm/drm_mode_object: increase max objects to accommodate new color >>> props >>> drm/drm_property: make replace_property_blob_from_id a DRM helper >>> drm/drm_plane: track color mgmt changes per plane >> >> If all patches are merged through amd-staging-drm-next I worry that >> conflicts creep in if any code around replace_property_blob_from_id >> changes in DRM. >> >> My plan is to merge DRM patches through drm-misc-next, as well >> as include them in the amd-staging-drm-next merge. They should then >> fall out at the next amd-staging-drm-next pull and (hopefully) >> ensure that there is no conflict. >> >> If no objections I'll go ahead with that later this week. > > Double-merging tends to be the worst because git doesn't realize the > commits match, which actually makes the conflicts worse when they > happen (because the 3-way merge diff gets absolute confused by all the > changed context and misplaces everything to the max). So please don't, > _only_ every cherry-pick when a patch in -next is also needed in > -fixes, and we didn't put it into the right tree. But even that is a > bit tricky and should only be done by maintainers (using dim > cherry-pick if it's drm-misc) because the conflicts tend to be bad and > need to be sorted out with backmerges sooner than later. > > For this case merge everything through one tree with the right acks, > pull to drm-next asap and then backmerge into the other tree. Here > probably amdgpu-next with drm-misc maintainer acks for the 3 core > patches. Or if amdgpu-next pull won't come for a while, put them into > drm-misc-next and just wait a week until it's in drm-next, then > forward amdgpu-next. > Maxime, Maarten, Thomas, could I get an ACK from you for the three DRM core patches and an ACK for pulling them through the AMD tree? Thanks, Harry > Cheers, Sima > >> Harry >> >>> drm/amd/display: add driver-specific property for plane degamma LUT >>> drm/amd/display: explicitly define EOTF and inverse EOTF >>> drm/amd/display: document AMDGPU pre-defined transfer functions >>> drm/amd/display: add plane 3D LUT driver-specific properties >>> drm/amd/display: add plane shaper LUT and TF driver-specific >>> properties >>> drm/amd/display: add CRTC gamma TF driver-specific property >>> drm/amd/display: add comments to describe DM crtc color mgmt behavior >>> drm/amd/display: encapsulate atomic regamma operation >>> drm/amd/display: decouple steps for mapping CRTC degamma to DC plane >>> drm/amd/display: reject atomic commit if setting both plane and CRTC >>> degamma >>> drm/amd/display: add plane shaper LUT support >>> drm/amd/display: add plane shaper TF support >>> drm/amd/display: add plane 3D LUT support >>> drm/amd/display: add plane CTM driver-specific property >>> drm/amd/display: add plane CTM support >>> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 91 ++ >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +- >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++ >>> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 818 -- >>> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++ >>> .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 232 - >>> .../gpu/drm/amd/display/include/fixed31_32.h | 12 + >>> drivers/gpu/drm/arm/malidp_crtc.c | 2 +- >>> drivers/gpu/drm/drm_atomic.c | 1 + >>> drivers/gpu/drm/drm_atomic_state_helper.c | 1 + >>> drivers/gpu/drm/drm_atomic_uapi.c | 43 +- >>> drivers/gpu/drm/drm_property.c| 49 ++ >>> include/drm/drm_mode_object.h | 2 +- >>> include/drm/drm_plane.h | 7 + >>> include/drm/drm_property.h| 6 + >>> include/uapi/drm/drm_mode.h | 8 + >>> 16 files changed, 1377 insertions(+), 109 deletions(-) >>> >> > >
Re: [PATCH] drm/amd: Add a DC debug mask for DML2
On 2023-11-30 16:56, Aurabindo Pillai wrote:
> [Why]
> To enable testing/development of DML2, expose a new debug mask for future use.
>
> Signed-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/include/amd_shared.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
> b/drivers/gpu/drm/amd/include/amd_shared.h
> index 579977f6ad52..ade68972ec28 100644
> --- a/drivers/gpu/drm/amd/include/amd_shared.h
> +++ b/drivers/gpu/drm/amd/include/amd_shared.h
> @@ -255,6 +255,7 @@ enum DC_DEBUG_MASK {
> DC_FORCE_SUBVP_MCLK_SWITCH = 0x20,
> DC_DISABLE_MPO = 0x40,
> DC_ENABLE_DPIA_TRACE = 0x80,
> + DC_ENABLE_DML2 = 0x100,
> };
>
> enum amd_dpm_forced_level;
Re: [PATCH] drm/amd/display: Increase frame warning limit with KASAN or KCSAN in dml
On 2023-11-30 17:43, Alex Deucher wrote:
> Does the same thing as:
> commit 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with
> KASAN or KCSAN in dml2")
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202311302107.hudxvywt-...@intel.com/
> Fixes: 67e38874b85b ("drm/amd/display: Increase num voltage states to 40")
> Signed-off-by: Alex Deucher
> Cc: Alvin Lee
> Cc: Hamza Mahfooz
> Cc: Samson Tam
> Cc: Harry Wentland
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dml/Makefile | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index ea7d60f9a9b4..6042a5a6a44f 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -61,8 +61,12 @@ endif
> endif
>
> ifneq ($(CONFIG_FRAME_WARN),0)
> +ifeq ($(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),y)
> +frame_warn_flag := -Wframe-larger-than=3072
> +else
> frame_warn_flag := -Wframe-larger-than=2048
> endif
> +endif
>
> CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
> CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
Re: [PATCH] drm/amd/display: Fix NULL pointer dereference at hibernate
On 2023-11-28 19:35, Mario Limonciello wrote:
During hibernate sequence the source context might not have a clk_mgr.
So don't use it to look for DML2 support.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2980
Fixes: a2815ada8616 ("drm/amd/display: Introduce DML2")
Signed-off-by: Mario Limonciello
Reviewed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index f3a9fdd2340d..e1c02527d04a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -4554,7 +4554,7 @@ void dc_resource_state_copy_construct(
struct dml2_context *dml2 = NULL;
// Need to preserve allocated dml2 context
- if (src_ctx->clk_mgr->ctx->dc->debug.using_dml2)
+ if (src_ctx->clk_mgr && src_ctx->clk_mgr->ctx->dc->debug.using_dml2)
dml2 = dst_ctx->bw_ctx.dml2;
#endif
@@ -4562,7 +4562,7 @@ void dc_resource_state_copy_construct(
#ifdef CONFIG_DRM_AMD_DC_FP
// Preserve allocated dml2 context
- if (src_ctx->clk_mgr->ctx->dc->debug.using_dml2)
+ if (src_ctx->clk_mgr && src_ctx->clk_mgr->ctx->dc->debug.using_dml2)
dst_ctx->bw_ctx.dml2 = dml2;
#endif
Re: [PATCH v5 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt
On 2023-11-16 14:57, Melissa Wen wrote: > Hello, > > This series extends the current KMS color management API with AMD > driver-specific properties to enhance the color management support on > AMD Steam Deck. The key additions to the color pipeline include: > snip > Melissa Wen (18): > drm/drm_mode_object: increase max objects to accommodate new color > props > drm/drm_property: make replace_property_blob_from_id a DRM helper > drm/drm_plane: track color mgmt changes per plane If all patches are merged through amd-staging-drm-next I worry that conflicts creep in if any code around replace_property_blob_from_id changes in DRM. My plan is to merge DRM patches through drm-misc-next, as well as include them in the amd-staging-drm-next merge. They should then fall out at the next amd-staging-drm-next pull and (hopefully) ensure that there is no conflict. If no objections I'll go ahead with that later this week. Harry > drm/amd/display: add driver-specific property for plane degamma LUT > drm/amd/display: explicitly define EOTF and inverse EOTF > drm/amd/display: document AMDGPU pre-defined transfer functions > drm/amd/display: add plane 3D LUT driver-specific properties > drm/amd/display: add plane shaper LUT and TF driver-specific > properties > drm/amd/display: add CRTC gamma TF driver-specific property > drm/amd/display: add comments to describe DM crtc color mgmt behavior > drm/amd/display: encapsulate atomic regamma operation > drm/amd/display: decouple steps for mapping CRTC degamma to DC plane > drm/amd/display: reject atomic commit if setting both plane and CRTC > degamma > drm/amd/display: add plane shaper LUT support > drm/amd/display: add plane shaper TF support > drm/amd/display: add plane 3D LUT support > drm/amd/display: add plane CTM driver-specific property > drm/amd/display: add plane CTM support > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 91 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 34 +- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 108 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 818 -- > .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 ++ > .../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 232 - > .../gpu/drm/amd/display/include/fixed31_32.h | 12 + > drivers/gpu/drm/arm/malidp_crtc.c | 2 +- > drivers/gpu/drm/drm_atomic.c | 1 + > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > drivers/gpu/drm/drm_atomic_uapi.c | 43 +- > drivers/gpu/drm/drm_property.c| 49 ++ > include/drm/drm_mode_object.h | 2 +- > include/drm/drm_plane.h | 7 + > include/drm/drm_property.h| 6 + > include/uapi/drm/drm_mode.h | 8 + > 16 files changed, 1377 insertions(+), 109 deletions(-) >
Re: [PATCH] drm/amd/display: fix ABM disablement
On 2023-11-22 17:24, Hamza Mahfooz wrote:
> On recent versions of DMUB firmware, if we want to completely disable
> ABM we have to pass ABM_LEVEL_IMMEDIATE_DISABLE as the requested ABM
> level to DMUB. Otherwise, LCD eDP displays are unable to reach their
> maximum brightness levels. So, to fix this whenever the user requests an
> ABM level of 0 pass ABM_LEVEL_IMMEDIATE_DISABLE to DMUB instead. Also,
> to keep the user's experience consistent map ABM_LEVEL_IMMEDIATE_DISABLE
> to 0 when a user tries to read the requested ABM level.
>
> Signed-off-by: Hamza Mahfooz
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5d9496db0ecb..8cb92d941cd9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6230,7 +6230,7 @@ int amdgpu_dm_connector_atomic_set_property(struct
> drm_connector *connector,
> dm_new_state->underscan_enable = val;
> ret = 0;
> } else if (property == adev->mode_info.abm_level_property) {
> - dm_new_state->abm_level = val;
> + dm_new_state->abm_level = val ?: ABM_LEVEL_IMMEDIATE_DISABLE;
> ret = 0;
> }
>
> @@ -6275,7 +6275,8 @@ int amdgpu_dm_connector_atomic_get_property(struct
> drm_connector *connector,
> *val = dm_state->underscan_enable;
> ret = 0;
> } else if (property == adev->mode_info.abm_level_property) {
> - *val = dm_state->abm_level;
> + *val = (dm_state->abm_level != ABM_LEVEL_IMMEDIATE_DISABLE) ?
> + dm_state->abm_level : 0;
> ret = 0;
> }
>
> @@ -6348,7 +6349,8 @@ void amdgpu_dm_connector_funcs_reset(struct
> drm_connector *connector)
> state->pbn = 0;
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> - state->abm_level = amdgpu_dm_abm_level;
> + state->abm_level = amdgpu_dm_abm_level ?:
> + ABM_LEVEL_IMMEDIATE_DISABLE;
>
> __drm_atomic_helper_connector_reset(connector, >base);
> }
Re: [PATCH v5 09/32] drm/amd/display: add plane 3D LUT driver-specific properties
On 2023-11-16 14:57, Melissa Wen wrote:
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources.
Since a 3D LUT has a limited number of entries in each dimension we want
to use them in an optimal fashion. This means using the 3D LUT in a
colorspace that is optimized for human vision, such as sRGB, PQ, or
another non-linear space. Therefore, userpace may need one 1D LUT
(shaper) before it to delinearize content and another 1D LUT after 3D
LUT (blend) to linearize content again for blending. The next patches
add these 1D LUTs to the plane color mgmt pipeline.
v3:
- improve commit message about 3D LUT
- describe the 3D LUT entries and size (Harry)
v4:
- advertise 3D LUT max size as the size of a single-dimension
v5:
- get lut3d blob correctly (Joshua)
- fix doc about 3d-lut dimension size (Sebastian)
Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
We'll run this series through our testing. If that doesn't show
problems and if I don't see any new comments on the series I'm
planning to merge it through amd-staging-drm-next.
Harry
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 18 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 +++
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 24 +++
4 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index ee67c5adf0f1..57822477408f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -364,6 +364,24 @@ struct amdgpu_mode_info {
* @plane_hdr_mult_property:
*/
struct drm_property *plane_hdr_mult_property;
+ /**
+* @plane_lut3d_property: Plane property for color transformation using
+* a 3D LUT (pre-blending), a three-dimensional array where each
+* element is an RGB triplet. Each dimension has the size of
+* lut3d_size. The array contains samples from the approximated
+* function. On AMD, values between samples are estimated by
+* tetrahedral interpolation. The array is accessed with three indices,
+* one for each input dimension (color channel), blue being the
+* outermost dimension, red the innermost.
+*/
+ struct drm_property *plane_lut3d_property;
+ /**
+* @plane_degamma_lut_size_property: Plane property to define the max
+* size of 3D LUT as supported by the driver (read-only). The max size
+* is the max size of one dimension and, therefore, the max number of
+* entries for 3D LUT array is the 3D LUT size cubed;
+*/
+ struct drm_property *plane_lut3d_size_property;
};
#define AMDGPU_MAX_BL_LEVEL 0xFF
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 38163b7084fa..03b48b331b7c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -776,6 +776,11 @@ struct dm_plane_state {
* TF is needed for any subsequent linear-to-non-linear transforms.
*/
__u64 hdr_mult;
+ /**
+* @lut3d: 3D lookup table blob. The blob (if not NULL) is an array of
+* drm_color_lut.
+*/
+ struct drm_property_blob *lut3d;
};
struct dm_crtc_state {
@@ -861,6 +866,10 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector
*connector,
void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
+/* 3D LUT max size is 17x17x17 (4913 entries) */
+#define MAX_COLOR_3DLUT_SIZE 17
+#define MAX_COLOR_3DLUT_BITDEPTH 12
+/* 1D LUT size */
#define MAX_COLOR_LUT_ENTRIES 4096
/* Legacy gamm LUT users such as X doesn't like large LUT sizes */
#define MAX_COLOR_LEGACY_LUT_ENTRIES 256
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index b5b34a9209e4..a3b4f6a4c4a8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -231,6 +231,20 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
*adev)
return -ENOMEM;
adev->mode_info.plane_hdr_mult_property = prop;
+ prop = drm_property_create(adev_to_drm(adev),
+ DRM_MODE_PROP_BLOB,
+ "AMD_PLANE_LUT3D", 0);
+ if (!prop)
+ return -ENOMEM;
+ adev->mode_info.plane_lut3d_property = prop;
+
+ prop = drm_property_create_range(adev_to_drm(adev),
+DRM_MOD
Re: [PATCH v4 12/32] drm/amd/display: add CRTC gamma TF driver-specific property
On 2023-10-05 13:15, Melissa Wen wrote:
> Add AMD pre-defined transfer function property to default DRM CRTC gamma
> to convert to wire encoding with or without a user gamma LUT. There is
> no post-blending regamma ROM for pre-defined TF. When setting Gamma TF
> (!= Identity) and LUT at the same time, the color module will combine
> the pre-defined TF and the custom LUT values into the LUT that's
> actually programmed.
>
> v2:
> - enable CRTC prop in the end of driver-specific prop sequence
> - define inverse EOTFs as supported regamma TFs
> - reword driver-specific function doc to remove shaper/3D LUT
>
> v3:
> - spell out TF+LUT behavior in the commit and comments (Harry)
>
> Co-developed-by: Joshua Ashton
> Signed-off-by: Joshua Ashton
> Signed-off-by: Melissa Wen
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 7 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 8 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 7 ++
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 72 +++
> 4 files changed, 94 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index dee35d208493..071cc10bfd90 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -424,6 +424,13 @@ struct amdgpu_mode_info {
>* from a combination of pre-defined TF and the custom 1D LUT).
>*/
> struct drm_property *plane_blend_tf_property;
> + /* @regamma_tf_property: Transfer function for CRTC regamma
> + * (post-blending). Possible values are defined by `enum
> + * amdgpu_transfer_function`. There is no regamma ROM, but we can use
> + * AMD color modules to program LUT parameters from predefined TF (or
> + * from a combination of pre-defined TF and the custom 1D LUT).
> + */
> + struct drm_property *regamma_tf_property;
> };
>
> #define AMDGPU_MAX_BL_LEVEL 0xFF
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 1b96c742d747..c138457ff12e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -836,6 +836,14 @@ struct dm_crtc_state {
> struct dc_info_packet vrr_infopacket;
>
> int abm_level;
> +
> +/**
> + * @regamma_tf:
> + *
> + * Pre-defined transfer function for converting internal FB -> wire
> + * encoding.
> + */
> + enum amdgpu_transfer_function regamma_tf;
> };
>
> #define to_dm_crtc_state(x) container_of(x, struct dm_crtc_state, base)
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 82c554662faa..2ecfa0e886e8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -294,6 +294,13 @@ amdgpu_dm_create_color_properties(struct amdgpu_device
> *adev)
> return -ENOMEM;
> adev->mode_info.plane_blend_tf_property = prop;
>
> + prop = amdgpu_create_tf_property(adev_to_drm(adev),
> + "AMD_CRTC_REGAMMA_TF",
> + amdgpu_inv_eotf);
> + if (!prop)
> + return -ENOMEM;
> + adev->mode_info.regamma_tf_property = prop;
> +
> return 0;
> }
> #endif
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> index 440fc0869a34..d746f0aa0f11 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> @@ -253,6 +253,7 @@ static struct drm_crtc_state
> *dm_crtc_duplicate_state(struct drm_crtc *crtc)
> state->freesync_config = cur->freesync_config;
> state->cm_has_degamma = cur->cm_has_degamma;
> state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb;
> + state->regamma_tf = cur->regamma_tf;
> state->crc_skip_count = cur->crc_skip_count;
> state->mpo_requested = cur->mpo_requested;
> /* TODO Duplicate dc_stream after objects are stream object is
> flattened */
> @@ -289,6 +290,70 @@ static int amdgpu_dm_crtc_late_register(struct drm_crtc
> *crtc)
> }
> #endif
>
> +#ifdef AMD_PRIVATE_COLOR
> +/**
> + * drm_crtc_additional_color_mgmt - enable additional color properties
> + * @crtc: DRM CRTC
> + *
> + * This function lets the driver enable
