Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Harry Wentland]

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

[Harry Wentland]

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

[Harry Wentland]

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 00/28] Plane Color Pipeline support for Intel platforms

[Harry Wentland]

On 2024-02-13 01:48, Uma Shankar wrote:
> This series intends to add support for Plane Color Management for
> Intel platforms. This is based on the design which has been agreed
> upon by the community. Series implementing the design for generic
> DRM core has been sent out by Harry Wentland and is under review
> below:
> https://patchwork.freedesktop.org/series/123446/
> 
> The base work of above series is squashed under 1 patch and support
> for Intel platform is added on top of it.
> Any reviews on the original core design is expected to be done in 
> Harry's series to avoid any forking of the discussion.
> 
> We have added some changes/fixes to the Harry's core DRM changes,
> being put up as separate patches on top of squashed patch. These are
> expected to get included in the main series from Harry once agreed upon.
> 
> Changes added on core design:
> 1. Below patches implement some fixes on original series
> drm: Add missing function declarations
> drm: handle NULL next colorop in drm_colorop_set_next_property
> drm: Fix error logging in set Color Pipeline
> 
> 2. Implemented a HW capability property to expose segmented luts.
> drm: Add Color lut range attributes
> drm: Add Color ops capability property
> drm: Define helper to create color ops capability property
> drm: Define helper for adding capability property for 1D LUT
> 
> This helps in generically defining the hardware lut capabilities,
> lut distribution, precision, segmented or PWL LUTS.
> 
> 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT:
> drm: Add Enhanced LUT precision structure
> drm: Add support for 3x3 CTM
> drm: Add 1D LUT color op
> 
> On top of this base work for DRM core plane color pipeline design,
> implementation is done for Intel hardware platforms. Below patches
> include the same:
> 
> drm/i915: Add identifiers for intel color blocks
> drm/i915: Add intel_color_op
> drm/i915/color: Add helper to allocate intel colorop
> drm/i915/color: Add helper to create intel colorop
> drm/i915/color: Create a transfer function color pipeline
> drm/i915/color: Add and attach COLORPIPELINE plane property
> drm/i915/color: Add framework to set colorop
> drm/i915/color: Add callbacks to set plane CTM
> drm/i915/color: Add framework to program PRE/POST CSC LUT
> FIXME: force disable legacy plane color properties for TGL and beyond
> drm/i915/color: Enable Plane Color Pipelines
> drm/i915: Define segmented Lut and add capabilities to colorop
> drm/i915/color: Add plane CTM callback for TGL and beyond
> drm/i915: Add register definitions for Plane Degamma
> drm/i915: Add register definitions for Plane Post CSC
> drm/i915/color: Program Pre-CSC registers
> drm/i915/xelpd: Program Plane Post CSC Registers
> 
> Bhanu from Intel will be sending out the igt changes to help test the
> color pipeline implementation based on the current igt changes sent out
> by Harry.
> https://patchwork.freedesktop.org/series/123448/
> 
> Planned Next Steps:
> 1. Work with Harry and community and get DRM core changes for color
> pipeline merged.

We'll need a userspace to implement support before merging, but we're
working to enabling all color properties gamescope currently uses for
the SteamDeck color management to the Color Pipeline API, which should
help us get there. It's still a journey but I think the path is clear.

I'll send a new version of my patch series next week, including some AMD
implementation (not the entire AMD pipeline yet).

We're also adding a 1D_LUT type that's much simpler, basically a copy
of what the drm_crtc currently uses. One option is to keep both types,
another is to see if AMD's LUT can be expressed using the caps that you
define. I think it should be possible to express it as a single segment.

There might be another few changes in the core that might help you. Like
seeing the value of the client cap in the driver.

It's really good to see your work. With that we'll have three driver
implementations: VKMS, Intel, AMD,, which shows broad usability of this
approach.

Harry

> 2. Implement pipe color management (post blending) based on the current
> color pipeline design.
> 3. Work with compositor maintainers to get color processing implemented
> using display hardware, thereby avoid any GL or GPU shaders.
> 
> Thanks to all the community maintainers and contributors who have helped
> to get this support in upstream Linux. Looking forward to collaborate,
> work together and get this merged.
> 
> 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: Joshua Ashton 
> Cc: Michel Dänzer 
> Cc: Aleix Pol 
> Cc: Xaver Hugl

Re: [RFC 0/5] Introduce drm sharpening property

[Harry Wentland]

Adding a couple of compositor devs as they might be interested in this.

On 2024-02-14 06:24, Nemesa Garg wrote:
>   Many a times images are blurred or upscaled content is also not as
> crisp as original rendered image. Traditional sharpening techniques often
> apply a uniform level of enhancement across entire image, which sometimes
> result in over-sharpening of some areas and potential loss of natural 
> details. 
> 
> Intel has come up with Display Engine based adaptive sharpening filter 
> with minimal power and performance impact. From LNL onwards, the Display
> hardware can use one of the pipe scaler for adaptive sharpness filter.
> This can be used for both gaming and non-gaming use cases like photos,
> image viewing. It works on a region of pixels depending on the tap size.
> 
> This RFC is an attempt to introduce an adaptive sharpness solution which
> helps in improving the image quality. For this new CRTC property is added.

I don't think CRTC is the right place for this. Scaling tends to be more
of a plane thing. Planes can be scaled independently, or is that not the
case for Intel? Or does Intel HW do this sharpening operation independent
of any scaling, on the entire output?

> The user can set this property with desired sharpness strength value with
> 0-255. A value of 1 representing minimum sharpening strength and 255
> representing maximum sharpness strength. A strength value of 0 means no
> sharpening or sharpening feature disabled.
> It works on a region of pixels depending on the tap size. The coefficients
> are used to generate an alpha value which is used to blend the sharpened
> image to original image.
>  
> Userspace implementation for sharpening feature and IGT implementation
> is in progress.

It would be very helpful to have an idea how this looks in userspace, and
which compositors will implement this.

Harry

> 
> Nemesa Garg (5):
>   drm: Introduce sharpeness mode property
>   drm/i915/display/: Compute the scaler filter coefficients
>   drm/i915/dispaly/: Enable the second scaler
>   drm/i915/display/: Add registers and compute the strength
>   drm/i915/display: Load the lut values and enable sharpness
> 
>  drivers/gpu/drm/drm_atomic_uapi.c |   4 +
>  drivers/gpu/drm/drm_crtc.c|  17 ++
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_crtc.c |   3 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  20 +-
>  .../drm/i915/display/intel_display_types.h|  11 +
>  .../drm/i915/display/intel_modeset_verify.c   |   1 +
>  .../drm/i915/display/intel_sharpen_filter.c   | 214 ++
>  .../drm/i915/display/intel_sharpen_filter.h   |  31 +++
>  drivers/gpu/drm/i915/display/skl_scaler.c |  86 ++-
>  drivers/gpu/drm/i915/display/skl_scaler.h |   1 +
>  drivers/gpu/drm/i915/i915_reg.h   |  19 ++
>  drivers/gpu/drm/xe/Makefile   |   1 +
>  include/drm/drm_crtc.h|  17 ++
>  14 files changed, 416 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.h
> 

Re: [Intel-gfx] [PATCH v4 02/30] drm/dp_mst: Fix fractional DSC bpp handling

[Harry Wentland]

On 2023-10-30 11:58, Imre Deak wrote:
> From: Ville Syrjälä 
> 
> The current code does '(bpp << 4) / 16' in the MST PBN
> calculation, but that is just the same as 'bpp' so the
> DSC codepath achieves absolutely nothing. Fix it up so that
> the fractional part of the bpp value is actually used instead
> of truncated away. 64*1006 has enough zero lsbs that we can
> just shift that down in the dividend and thus still manage
> to stick to a 32bit divisor.
> 
> And while touching this, let's just make the whole thing more
> straightforward by making the passed in bpp value .4 binary
> fixed point always, instead of having to pass in different
> things based on whether DSC is enabled or not.
> 
> v2:
> - Fix DSC kunit test cases.
> 
> Cc: Manasi Navare 
> Cc: Lyude Paul 
> Cc: Harry Wentland 
> Cc: David Francis 
> Cc: Mikita Lipski 
> Cc: Alex Deucher 
> Fixes: dc48529fb14e ("drm/dp_mst: Add PBN calculation for DSC modes")
> Reviewed-by: Lyude Paul  (v1)
> Signed-off-by: Ville Syrjälä 
> [Imre: Fix kunit test cases]
> Signed-off-by: Imre Deak 

Acked-by: Harry Wentland 

Harry

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 20 +--
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  5 ++---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  3 +--
>  .../gpu/drm/tests/drm_dp_mst_helper_test.c|  6 +++---
>  include/drm/display/drm_dp_mst_helper.h   |  2 +-
>  7 files changed, 14 insertions(+), 26 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 9a712791f309f..ada3773869ff0 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6918,7 +6918,7 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
>   max_bpc);
>   bpp = convert_dc_color_depth_into_bpc(color_depth) * 3;
>   clock = adjusted_mode->clock;
> - dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
> false);
> + dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp 
> << 4);
>   }
>  
>   dm_new_connector_state->vcpi_slots =
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index d3b13d362edac..9a58e1a4c5f49 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -1642,7 +1642,7 @@ enum dc_status dm_dp_mst_is_port_support_mode(
>   } else {
>   /* check if mode could be supported within full_pbn */
>   bpp = 
> convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
> - pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10, 
> bpp, false);
> + pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10, 
> bpp << 4);
>  
>   if (pbn > aconnector->mst_output_port->full_pbn)
>   return DC_FAIL_BANDWIDTH_VALIDATE;
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 0e0d0e76de065..772b00ebd57bd 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4718,13 +4718,12 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
>  
>  /**
>   * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
> - * @clock: dot clock for the mode
> - * @bpp: bpp for the mode.
> - * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
> + * @clock: dot clock
> + * @bpp: bpp as .4 binary fixed point
>   *
>   * This uses the formula in the spec to calculate the PBN value for a mode.
>   */
> -int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
> +int drm_dp_calc_pbn_mode(int clock, int bpp)
>  {
>   /*
>* margin 5300ppm + 300ppm ~ 0.6% as per spec, factor is 1.006
> @@ -4735,18 +4734,9 @@ int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
>* peak_kbps *= (1006/1000)
>* peak_kbps *= (64/54)
>* peak_kbps *= 8convert to bytes
> -  *
> -  * If the bpp is in units of 1/16, further divide by 16. Put this
> -  * factor in the numerator rather than the denominator to avoid
> -  * integer overflow
>*/
> -
> - if (dsc)
> - return DI

Re: [Intel-gfx] [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline

[Harry Wentland]

On 2023-08-29 12:03, Uma Shankar wrote:

Add the documentation for the new proposed Plane Color Pipeline.

Co-developed-by: Chaitanya Kumar Borah 
Signed-off-by: Chaitanya Kumar Borah 
Signed-off-by: Uma Shankar 
---
  .../gpu/rfc/plane_color_pipeline.rst  | 394 ++
  1 file changed, 394 insertions(+)
  create mode 100644 Documentation/gpu/rfc/plane_color_pipeline.rst

diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst 
b/Documentation/gpu/rfc/plane_color_pipeline.rst
new file mode 100644
index ..60ce515b6ea7
--- /dev/null
+++ b/Documentation/gpu/rfc/plane_color_pipeline.rst
@@ -0,0 +1,394 @@
+===
+ Plane Color Pipeline: A UAPI proposal
+===
+
+To build the proposal on, lets take the premise of a color pipeline as shown
+below.
+
+ +---+
+ |RAM|
+ |  +--++-++-+   |
+ |  | FB 1 ||  FB 2   || FB N|   |
+ |  +--++-++-+   |
+ +---+
+   |  Plane Color Hardware Block |
+ ++
+ | +---v-+   +---v---+   +---v--+ |
+ | | Plane A |   | Plane B   |   | Plane N  | |
+ | | Pre-CSC |   | Pre-CSC   |   | Pre-CSC  | |
+ | +---+-+   +---+---+   +---+--+ |
+ | | |   ||
+ | +---v-+   +---v---+   +---v--+ |
+ | |Plane A  |   | Plane B   |   | Plane N  | |
+ | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
+ | +---+-+   ++--+   ++-+ |
+ | |  |   |   |
+ | +---v-+   +v--+   +v-+ |
+ | | Plane A |   | Plane B   |   | Plane N  | |
+ | |Post-CSC |   | Post-CSC  |   | Post-CSC | |
+ | +---+-+   ++--+   ++-+ |
+ | |  |   |   |
+ ++
++--v--v---v---|
+||   ||
+||   Pipe Blender||
++++
+|||
+|+---v--+ |
+||  Pipe Pre-CSC| |
+||  | |
+|+---+--+ |
+||Pipe Color  |
+|+---v--+ Hardware|
+||  Pipe CSC/CTM| |
+||  | |
+|+---+--+ |
+|||
+|+---v--+ |
+||  Pipe Post-CSC   | |
+||  | |
+|+---+--+ |
+|||
++-+
+ |
+ v
+Pipe Output
+
+Each plane consists of the following color blocks
+ * Pre-CSC : This block can used to linearize the input frame buffer data.
+ The linear data then can be further acted on by the following
+ color hardware blocks in the display hardware pipeline
+
+ * CSC/CTM: Used to program color transformation matrix, this block is used
+to perform color space conversions like BT2020 to BT709 or BT601
+etc. This block acts on the linearized data coming from the
+Pre-CSC HW block.
+
+ * Post-CSC: This HW block can be used to non-linearize frame buffer data to
+ match the sink. Another use case of it could be to perform Tone
+ mapping for HDR use-cases.
+
+Data from multiple planes will then be fed to pipe/crtc where it will get 
blended.
+There is a similar set of HW blocks available at pipe/crtc level which acts on
+this blended data.
+
+Below is a sample usecase fo video playback with sub-titles and playback
+controls
+
+┌┐┌─┐ ┌─┐┌─┐
+│FB1 ││PRE-CSC  │ │ CTM Matrix  ││ POST-CSC│
+│├───►│Linearize├►│ BT709 to├───►│ SDR to HDR  │
+│BT709 SDR   ││ │ │ BT2020  ││ Tone Mapping├─┐
+└┘└─┘ └─┘└─┘ │
+(subtitles)  │
+ │
+┌┐┌─┐ ┌─┐┌─┐ │
+│FB2 ││PRE-CSC  │ │ CTM Matrix  ││ POST-CSC│ │
+│├───►│Linearize├►│ BT601 to├───►│ SDR to HDR  ├───┐ │
+│BT601 SDR   ││ │ │ BT2020  ││ Tone Mapping│   │ │

Re: [Intel-gfx] [RFC 00/33] Add Support for Plane Color Pipeline

[Harry Wentland]

 is then packaged within a blob for the user space to
retrieve it.



Would it be better to expose the drm_color_ops directly, instead of 
packing a array of drm_color_ops into a blob and then giving that to 
userspace.



To advertise the available color pipelines, an immutable ENUM property
"GET_COLOR_PIPELINE" is introduced. This enum property has blob id's as values.
With each blob id representing a distinct color pipeline based on underlying HW
capabilities and their respective combinations.

Once the user space decides on a color pipeline, it can set the pipeline and
the corresponding data for the hardware blocks within the pipeline with
the BLOB property "SET_COLOR_PIPELINE".



When I discussed this at the hackfest with Simon he proposed a new DRM 
object, (I've called it a drm_colorop) to represent a color operation. 
Each drm_colorop has a "NEXT" pointer to another drm_colorop, or NULL if 
its the last in the pipeline. You can then have a mutable enum property 
on the plane to discover and select a color pipeline.


This seems a bit more transparent than a blob. You can see my changes 
(unfortunately very WIP, don't look too closely at individual patches) at

https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5/diffs

libdrm changes:
https://gitlab.freedesktop.org/hwentland/drm/-/merge_requests/1/diffs

IGT changes:
https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1/diffs

I'll take time to review your whole series and will see whether we can 
somehow keep the best parts of each.


Curious to hear other opinions on the blob vs new DRM object question as 
well.



Refer to Documentation/gpu/rfc/plane_color_pipeline.rst added in the patch

IGT and test details


A set of IGT tests is written to demonstrate the usage of the proposed UAPIs
along with some sanity validation.

Details of the IGT test can be found here:
https://patchwork.freedesktop.org/series/123018/

Opens
=

a. To come up with a list of common HW blocks which can be defined generically 
by the DRM
core in agreement with all the stakeholders
b. To enhance/finalize the data structure to define segmented LUTs generically.



It would be good to add some basic support in VKMS. My work has been 
based on VKMS. Once we kinda settle on an approach I'll look at exposing 
the AMD private properties from Melissa through the API.




Out of Scope


a. The coefficients for CTM and LUT value calculations are out of scope of the 
proposal.
b. The onus of programming the HW blocks and their values is on user-space. 
Driver will
just provide the interface for the same.
c. In order to compute LUT values and coefficients, a helper library can be 
created in
user-space. However, it is out of scope for the current proposal.

Acknowledgements and credits


There are multiple contributors who have helped us to reach to this proposal. 
Special mention
to Ville Syrjala, Pekka 
Paalanen,
Simon Ser, Harry Wentland,
Melissa Wen, Jonas, Sebastian 
Wick,
Bhanu and Shashank.

Also, thanks to Carlos  and the Redhat team for organizing 
the HDR hackfest.


UAPI dependency and Usermode development


The current KMS implementation requires a user space consumer for it to be 
accepted upstream.
Work is ongoing in weston and mutter community to get color management and HDR 
support implemented
in the respective stacks.



If we can get AMD properties encoded using a Color Pipeline API we can 
probably use gamescope as the userspace vehicle.


I'm reviewing this in sequence, so there's a chance I'm missing context. 
Please bear with me if some of my comments are answered later in the series.


Again, thanks for sending this.

Harry


=

We have tried to take care of all the scenarios and use-cases which possibly 
could exists in the
current proposal. Thanks to everyone who has contributed in all color 
management discussions so
far. Let's work together to improve the current proposal and get this thing 
implemented in
upstream linux. All the feedback and suggestions to enhance the design are 
welcome.

Regards,
Uma Shankar
Chaitanya Kumar Borah

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 

Chaitanya Kumar Borah (14):
   drm: Add color operation structure
   drm: Add plane get color pipeline property
   drm: Add helper to add color pipeline
   drm: Manage color blob states
   drm: Replace individual color blobs
   drm: Reset pipeline when user sends NULL blob
   drm: Reset plane color state on pipeline switch request
   drm/i915/color: Add HDR plane LUT range data to color pipeline
   drm/i915/color: Add SDR plane LUT range data to color pipeline
   drm/i915/color: Add color pipelines to plane
   drm

Re: [Intel-gfx] [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property

[Harry Wentland]

On 2/14/23 05:28, Ville Syrjälä wrote:

On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote:

On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote:

On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote:

On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote:

From: Ville Syrjälä 

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.

Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
stragey is desirable.

Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.

A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.

Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.

v2: Try to add some docs

Cc: Simon Ser 
Cc: Jonas Ådahl 
Cc: Daniel Stone 
Cc: Pekka Paalanen 
Acked-by: Harry Wentland 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_mode_config.c |  7 +
  drivers/gpu/drm/drm_plane.c   | 48 +++
  include/drm/drm_mode_config.h |  5 
  include/drm/drm_plane.h   |  4 +++
  include/uapi/drm/drm_mode.h   | 11 +++
  5 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 87eb591fe9b5..21860f94a18c 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
  
+	prop = drm_property_create(dev,

+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "SIZE_HINTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.size_hints_property = prop;
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c

index 24e7998d1731..ae51b1f83755 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -140,6 +140,21 @@
   * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
   * various bugs in this area with inconsistencies between the capability
   * flag and per-plane properties.
+ *
+ * SIZE_HINTS:
+ * Blob property which contains the set of recommended plane size
+ * which can used for simple "cursor like" use cases (eg. no scaling).
+ * Using these hints frees userspace from extensive probing of
+ * supported plane sizes through atomic/setcursor ioctls.
+ *
+ * For optimal usage userspace should pick the smallest size
+ * that satisfies its own requirements.
+ *
+ * The blob contains an array of struct drm_plane_size_hint.
+ *
+ * Drivers should only attach this property to planes that
+ * support a very limited set of sizes (eg. cursor planes
+ * on typical hardware).


This is a bit awkward since problematic drivers would only expose
this property if they are new enough.

A way to avoid this is for all new drivers expose this property, but
special case the size 0x0 as "everything below the max limit goes". Then
userspace can do (ignoring the missing cap fallback).


I don't think there are any drivers that need that.
So I'm thinking we can just ignore that for now.


None the less, userspace not seeing SIZE_HINTS will be required to
indefinitely use the existing "old" behavior using the size cap as the
buffer size with a fallback, and drivers without any size limitations
that, i.e. details that are hard to express with a set of accepted
sizes, will still use the inoptimal buffer sizes.

If I read [1] correctly, AMD has no particular size limitations other
than a size limit, but without a SIZE_HINTS, userspace still needs to
use the maximum size.


Simon pointed out they have pretty much the same exact limits as i915.
Ie. only a few power of two sizes, and stride must match width.



That's an artificial limitation in the driver. The HW has no such
limitation and it would be nice to drop that from our driver as
well.

Harry



[1] https://gitlab.freedesktop.org/drm/in

Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

[Harry Wentland]

On 2/7/23 23:09, Ville Syrjala wrote:

From: Ville Syrjälä 

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.

Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
stragey is desirable.

Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.

A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.

Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.

Cc: Simon Ser 
Cc: Jonas Ådahl 
Cc: Daniel Stone 
Cc: Pekka Paalanen 
Signed-off-by: Ville Syrjälä 


This would be great to have. amdgpu could take advantage of it as
well. I didn't have a thorough look at the details of this
implementation but like what it does, so this is
Acked-by: Harry Wentland 

Harry


---
  drivers/gpu/drm/drm_mode_config.c |  7 +++
  drivers/gpu/drm/drm_plane.c   | 33 +++
  include/drm/drm_mode_config.h |  5 +
  include/drm/drm_plane.h   |  4 
  include/uapi/drm/drm_mode.h   |  5 +
  5 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 87eb591fe9b5..21860f94a18c 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
  
+	prop = drm_property_create(dev,

+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "SIZE_HINTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.size_hints_property = prop;
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c

index 24e7998d1731..d0a277f4be1f 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1582,3 +1582,36 @@ int drm_plane_create_scaling_filter_property(struct 
drm_plane *plane,
return 0;
  }
  EXPORT_SYMBOL(drm_plane_create_scaling_filter_property);
+
+/**
+ * drm_plane_add_size_hint_property - create a size hint property
+ *
+ * @plane: drm plane
+ * @hints: size hints
+ * @num_hints: number of size hints
+ *
+ * Create a size hints property for the plane.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_plane_add_size_hints_property(struct drm_plane *plane,
+ const struct drm_plane_size_hint *hints,
+ int num_hints)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_property_blob *blob;
+
+   blob = drm_property_create_blob(dev,
+   array_size(sizeof(hints[0]), num_hints),
+   hints);
+   if (IS_ERR(blob))
+   return PTR_ERR(blob);
+
+   drm_object_attach_property(>base, config->size_hints_property,
+  blob->base.id);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_add_size_hints_property);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5b053001d22..ed9f6938dca1 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -949,6 +949,11 @@ struct drm_mode_config {
 */
struct drm_property *modifiers_property;
  
+	/**

+* @size_hints_property: Plane SIZE_HINTS property.
+*/
+   struct drm_property *size_hints_property;
+
/* cursor size */
uint32_t cursor_width, cursor_height;
  
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h

index 51291983ea44..1997d7d64b69 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -32,6 +32,7 @@
  #include 
  
  struct drm_crtc;

+struct drm_plane_size_hint;
  struct drm_printer;
  struct drm_modeset_acquire_ctx;
  
@@ -945,5 +946,8 @@ drm_plane_get_damage_clips(const struct drm_plane_state *state);
  
  int drm_plane_create_scalin

Re: [Intel-gfx] [PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register

[Harry Wentland]

On 1/19/23 06:47, Arun R Murthy wrote:
> DP2.0 E11 defines a new register to facilitate SDP error detection by a
> 128B/132B capable DPRX device.
> 
> v2: Update the macro name to reflect the DP spec(Harry)
> 
> Signed-off-by: Arun R Murthy 

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/display/drm_dp.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 632376c291db..358db4a9f167 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -692,6 +692,9 @@
>  # define DP_FEC_LANE_2_SELECT(2 << 4)
>  # define DP_FEC_LANE_3_SELECT(3 << 4)
>  
> +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121   /* DP 2.0 E11 */
> +#define DP_SDP_CRC16_128B132B_EN BIT(0)
> +
>  #define DP_AUX_FRAME_SYNC_VALUE  0x15c   /* eDP 1.4 */
>  # define DP_AUX_FRAME_SYNC_VALID (1 << 0)
>  

Re: [Intel-gfx] [PATCH 1/2] drm: Add SDP Error Detection Configuration Register

[Harry Wentland]

On 1/12/23 23:36, Arun R Murthy wrote:
> DP2.0 E11 defines a new register to facilitate SDP error detection by a
> 128B/132B capable DPRX device.
> 
> Signed-off-by: Arun R Murthy 
> ---
>  include/drm/display/drm_dp.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 9bc22a02874d..8bf6f0a60c38 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -691,6 +691,9 @@
>  # define DP_FEC_LANE_2_SELECT(2 << 4)
>  # define DP_FEC_LANE_3_SELECT(3 << 4)
>  
> +#define DP_SDP_ERROR_DETECTION   0x121   /* DP 2.0 E11 */

If we're sticking with copying the exact naming from the DP spec
this might be more correctly be named DP_SDP_ERROR_DETECTION_CONFIGURATION

Harry

> +#define DP_SDP_CRC16_128B132B_EN BIT(0)
> +
>  #define DP_AUX_FRAME_SYNC_VALUE  0x15c   /* eDP 1.4 */
>  # define DP_AUX_FRAME_SYNC_VALID (1 << 0)
>  

Re: [Intel-gfx] [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Harry Wentland]

On 1/13/23 05:25, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>>
>> Cc: intel-gfx, drm maintainers
>>
>> Please have the courtesy of Cc'ing us for changes impacting us, and
>> maybe try to involve us earlier instead of surprising us like
>> this. Looks like this has been debugged for at least three months, and
>> the huge revert at this point is going to set us back with what's been
>> developed on top of it for i915 DP MST and DSC.
> 
> tbf I assumed this wont land when I've seen it fly by. It feels a bit much
> like living under a rock for half a year and then creating a mess for
> everyone else who's been building on top of this is not great.
> 
> Like yes it's a regression, but apparently not a blantantly obvious one,
> and I think if we just ram this in there's considerable community goodwill
> down the drain. Someone needs to get that goodwill up the drain again.
> 
>> It's a regression, I get that, but this is also going to be really nasty
>> to deal with. It's a 2500-line commit, plus the dependencies, which I
>> don't think are accounted for here. (What's the baseline for the revert
>> anyway?) I don't expect all the dependent commits to be easy to revert
>> or backport to v6.1 or v6.2.
>>
>> *sad trombone*
> 
> Yeah that's the other thing. 2500 patch revert is not cc stable material.
> So this isn't even really helping users all that much.
> 
> Unless it also comes with full amounts of backports of the reverts on all
> affected drivers for all curent stable trees, fully validated.
> 
> This is bad. I do think we need to have some understanding first of what
> "fix this in amdgpu" would look like as plan B. Because plan A does not
> look like a happy one at all.

Agree with your sentiments and apologies for not making this visible to
you sooner. This has been on the corner of my radar but I should've given
it a higher priority and more visibility sooner.

Has anyone looked at the dependencies? I assume there are a number of
dependent commits that would be hard/impossible to untangle but haven't had
a chance to look for those myself. Could you highlight a couple?

Harry

> -Daniel
> 
>> BR,
>> Jani.
>>
>>
>> On Thu, 12 Jan 2023, Wayne Lin  wrote:
>>> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>>>
>>> [Why]
>>> Changes cause regression on amdgpu mst.
>>> E.g.
>>> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove 
>>> payload
>>> one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
>>> maintained payload table. But previous change tries to go through all the
>>> payloads in mst_state and update amdpug hw maintained table in once 
>>> everytime
>>> driver only tries to add/remove a specific payload stream only. The newly
>>> design idea conflicts with the implementation in amdgpu nowadays.
>>>
>>> [How]
>>> Revert this patch first. After addressing all regression problems caused by
>>> this previous patch, will add it back and adjust it.
>>>
>>> Signed-off-by: Wayne Lin 
>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
>>> Cc: sta...@vger.kernel.org # 6.1
>>> Cc: Lyude Paul 
>>> Cc: Harry Wentland 
>>> Cc: Mario Limonciello 
>>> Cc: Ville Syrjälä 
>>> Cc: Ben Skeggs 
>>> Cc: Stanislav Lisovskiy 
>>> Cc: Fangzhi Zuo 
>>> ---
>>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
>>>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
>>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
>>>  .../amd/display/include/link_service_types.h  |   3 -
>>>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
>>>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
>>>  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
>>>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
>>>  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
>>>  9 files changed, 878 insertions(+), 530 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 77277d90b6e2..674f5dc1102b 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
>>> drm_encoder *encoder,
>>> const struct drm_display_mode *adjusted_m

Re: [Intel-gfx] [RFC 0/2] drm/connector: connector iterator with filtering

[Harry Wentland]

On 10/5/22 06:51, Jani Nikula wrote:
> Currently i915 assumes all drm_connectors it encounters are embedded in
> intel_connectors that i915 allocated. The drm_writeback_connector forces
> a design where this is not the case; we can't provide our own connector,
> and writeback embeds the drm_connector it initializes itself.
> 
> To use drm writeback, none of the i915 connector iteration could assume
> the drm connector is embedded in intel_connector. Checking this is
> tedious, and would require an intermediate step with
> drm_connector. Here's an idea I came up with; filtering at the drm
> connector iterator level with a caller supplied function. Not too much
> code, and could be used for other things as well.
> 

We've been trying to hook up drm_writeback_connector in amdgpu and
this would be really helpful. I've had to do liberal sprinkling
of "!= DRM_MODE_CONNECTOR_WRITEBACK" all over the place.

> Mind you, we'd still much rather modify drm writeback to allow passing
> the connector i915 allocated, instead of the current midlayer design
> that forces drivers to a certain model. Working around this is a bunch
> of error prone and tedious code that we really could do without.
> 

I think this would be even better but also be much more work and impact
every driver that implements writeback. FWIW, there was no way for me
to add writeback connector handling without KASAN. Interpreting the
connector wrong in one place leads to memory corruption and
undefined behavior and is almost impossible to spot without KASAN.

This series is
Acked-by: Harry Wentland 

Harry

> 
> BR,
> Jani.
> 
> 
> Cc: Arun R Murthy 
> Cc: Dave Airlie 
> Cc: Laurent Pinchart 
> Cc: Suraj Kandpal 
> Cc: Ville Syrjälä 
> 
> Jani Nikula (2):
>   drm/connector: add connector list iteration with filtering
>   drm/i915: iterate intel_connectors only
> 
>  drivers/gpu/drm/drm_connector.c   | 57 +++
>  drivers/gpu/drm/i915/display/intel_display.c  |  3 +-
>  .../drm/i915/display/intel_display_types.h|  7 +++
>  drivers/gpu/drm/i915/display/intel_dp.c   |  6 +-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  3 +-
>  drivers/gpu/drm/i915/display/intel_hotplug.c  | 12 ++--
>  .../drm/i915/display/intel_modeset_setup.c|  6 +-
>  drivers/gpu/drm/i915/display/intel_opregion.c |  9 ++-
>  include/drm/drm_connector.h   |  9 +++
>  10 files changed, 89 insertions(+), 26 deletions(-)
> 

Re: [Intel-gfx] [PATCH 03/15] drm/amd/display: stop using connector->override_edid

[Harry Wentland]

On 2022-10-11 09:49, Jani Nikula wrote:
> The connector->override_edid flag is strictly for EDID override debugfs
> management, and drivers have no business using it.
> 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Xinhui Pan 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> I really have no idea what the functional impact here is. I can only
> guess that the intention is to abuse ->override_edid to block EDID
> property updates. In any case, this use needs to go.
> 
> It also seems really curious we get here via connector .get_modes hook!
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ---
>  1 file changed, 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 4c73727e0b7d..d96877196a7f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6109,7 +6109,6 @@ static void create_eml_sink(struct amdgpu_dm_connector 
> *aconnector)
>   aconnector->base.name);
>  
>   aconnector->base.force = DRM_FORCE_OFF;
> - aconnector->base.override_edid = false;

I'm not even sure the DRM_FORCE_OFF business is right.

Either way, I don't think amdgpu should be messing with
override_edid, so this is
Reviewed-by: Harry Wentland 

Harry

>   return;
>   }
>  
> @@ -6144,8 +6143,6 @@ static void handle_edid_mgmt(struct amdgpu_dm_connector 
> *aconnector)
>   link->verified_link_cap.link_rate = LINK_RATE_HIGH2;
>   }
>  
> -
> - aconnector->base.override_edid = true;
>   create_eml_sink(aconnector);
>  }
>  

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

[Harry Wentland]

On 2022-05-02 10:29, Harry Wentland wrote:
> 
> 
> On 2022-05-02 10:27, Modem, Bhanuprakash wrote:
>> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote:
>>>
>>>
>>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
>>>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
>>>>>
>>>>>
>>>>>> -Original Message-
>>>>>> From: Intel-gfx  On Behalf Of
>>>>>> Bhanuprakash Modem
>>>>>> Sent: Monday, April 11, 2022 3:21 PM
>>>>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>>>>>> amd-
>>>>>> g...@lists.freedesktop.org; jani.nik...@linux.intel.com;
>>>>>> ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2
>>>>>> 
>>>>>> Cc: Rodrigo Siqueira 
>>>>>> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector
>>>>>> debugfs to
>>>>>> drm
>>>>>>
>>>>>> As drm_connector already have the display_info, instead of creating
>>>>>> "output_bpc" debugfs in vendor specific driver, move the logic to the
>>>>>> drm
>>>>>> layer.
>>>>>>
>>>>>> This patch will also move "Current" bpc to the crtc debugfs from
>>>>>> connector
>>>>>> debugfs, since we are getting this info from crtc_state.
>>>>>>
>>>>>> Cc: Harry Wentland 
>>>>>> Cc: Rodrigo Siqueira 
>>>>>> Signed-off-by: Bhanuprakash Modem 
>>>>>> Reported-by: kernel test robot 
>>>>>> ---
>>>>> Reviewed-by: Arun R Murthy 
>>>>
>>>> Thanks Arun,
>>>>
>>>> @Harry/@Rodrigo, If this change sounds good to you, can you please help
>>>> to push it?
>>>>
>>>
>>> This changes the output_bpc debugfs behavior on amdgpu and breaks
>>> the amd_max_bpc IGT test. I don't think we should merge this as-is.
>>
>> Yeah, I have floated the IGT changes to support this series:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F102387%2Fdata=05%7C01%7Charry.wentland%40amd.com%7C8cb627c63b194b3b82f808da2c4839b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637870985961376064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kn26Et7wc9IUkYhSG3R%2FXVKIJoqyKlQ1%2FNcduVh9Fuo%3Dreserved=0
>>
>>
>> With this IGT change, we can merge this series as-is. I would like to
>> request you to review IGT patches too.
>>
>>>
>>> This patch also seems dependent on patch 1 of the series. Shouldn't
>>> they be merged together (please don't merge them as-is, though)?
>>
>> Yes, as other patches in this series are already reviewed, I think we
>> need to plan to merge all patches in this series together (If above IGT
>> & this patch looks good to you).
>>
> 
> Thanks for the context again and apologies I haven't had the time to
> have a closer look so far. I'll go over these and the IGT patches today
> and get back to you.
> 

Both the kernel and IGT series look good to me.

I recommend you merge the entire kernel set as one into drm-next. We
can pull it into amd-staging-drm-next so as not to break our CI once
the IGT patches land.

Harry

> Harry
> 
>> - Bhanu
>>
>>>
>>> Harry
>>>
>>>> - Bhanu
>>>>
>>>>>
>>>>> Thanks and Regards,
>>>>> Arun R Murthy
>>>>> 
>>>>
>>

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

[Harry Wentland]

On 2022-05-02 10:27, Modem, Bhanuprakash wrote:
> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote:
>>
>>
>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
>>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Intel-gfx  On Behalf Of
>>>>> Bhanuprakash Modem
>>>>> Sent: Monday, April 11, 2022 3:21 PM
>>>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>>>>> amd-
>>>>> g...@lists.freedesktop.org; jani.nik...@linux.intel.com;
>>>>> ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2
>>>>> 
>>>>> Cc: Rodrigo Siqueira 
>>>>> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector
>>>>> debugfs to
>>>>> drm
>>>>>
>>>>> As drm_connector already have the display_info, instead of creating
>>>>> "output_bpc" debugfs in vendor specific driver, move the logic to the
>>>>> drm
>>>>> layer.
>>>>>
>>>>> This patch will also move "Current" bpc to the crtc debugfs from
>>>>> connector
>>>>> debugfs, since we are getting this info from crtc_state.
>>>>>
>>>>> Cc: Harry Wentland 
>>>>> Cc: Rodrigo Siqueira 
>>>>> Signed-off-by: Bhanuprakash Modem 
>>>>> Reported-by: kernel test robot 
>>>>> ---
>>>> Reviewed-by: Arun R Murthy 
>>>
>>> Thanks Arun,
>>>
>>> @Harry/@Rodrigo, If this change sounds good to you, can you please help
>>> to push it?
>>>
>>
>> This changes the output_bpc debugfs behavior on amdgpu and breaks
>> the amd_max_bpc IGT test. I don't think we should merge this as-is.
> 
> Yeah, I have floated the IGT changes to support this series:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F102387%2Fdata=05%7C01%7Charry.wentland%40amd.com%7C61d4e4a755a5449ec58308da2c47dd89%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637870984414230229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kge5PgzzX81hsFLBKyPfyv7vQpb1Gse72FWuiGtyoAQ%3Dreserved=0
> 
> 
> With this IGT change, we can merge this series as-is. I would like to
> request you to review IGT patches too.
> 
>>
>> This patch also seems dependent on patch 1 of the series. Shouldn't
>> they be merged together (please don't merge them as-is, though)?
> 
> Yes, as other patches in this series are already reviewed, I think we
> need to plan to merge all patches in this series together (If above IGT
> & this patch looks good to you).
> 

Thanks for the context again and apologies I haven't had the time to
have a closer look so far. I'll go over these and the IGT patches today
and get back to you.

Harry

> - Bhanu
> 
>>
>> Harry
>>
>>> - Bhanu
>>>
>>>>
>>>> Thanks and Regards,
>>>> Arun R Murthy
>>>> 
>>>
> 

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

[Harry Wentland]

On 2022-05-02 09:28, Modem, Bhanuprakash wrote:
> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote:
>>
>>
>>> -Original Message-
>>> From: Intel-gfx  On Behalf Of
>>> Bhanuprakash Modem
>>> Sent: Monday, April 11, 2022 3:21 PM
>>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>>> amd-
>>> g...@lists.freedesktop.org; jani.nik...@linux.intel.com;
>>> ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2
>>> 
>>> Cc: Rodrigo Siqueira 
>>> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to
>>> drm
>>>
>>> As drm_connector already have the display_info, instead of creating
>>> "output_bpc" debugfs in vendor specific driver, move the logic to the
>>> drm
>>> layer.
>>>
>>> This patch will also move "Current" bpc to the crtc debugfs from
>>> connector
>>> debugfs, since we are getting this info from crtc_state.
>>>
>>> Cc: Harry Wentland 
>>> Cc: Rodrigo Siqueira 
>>> Signed-off-by: Bhanuprakash Modem 
>>> Reported-by: kernel test robot 
>>> ---
>> Reviewed-by: Arun R Murthy 
> 
> Thanks Arun,
> 
> @Harry/@Rodrigo, If this change sounds good to you, can you please help
> to push it?
> 

This changes the output_bpc debugfs behavior on amdgpu and breaks
the amd_max_bpc IGT test. I don't think we should merge this as-is.

This patch also seems dependent on patch 1 of the series. Shouldn't
they be merged together (please don't merge them as-is, though)?

Harry

> - Bhanu
> 
>>
>> Thanks and Regards,
>> Arun R Murthy
>> 
> 

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

[Harry Wentland]

On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede  
> wrote:
> 
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede 
>>>  wrote:
>>>
 What I'm reading in the above is that it is being considered to allow
 changing the panel-orientation value after the connector has been made
 available to userspace; and let userspace know about this through a uevent.

 I believe that this is a bad idea, it is important to keep in mind here
 what userspace (e.g. plymouth) uses this prorty for. This property is
 used to rotate the image being rendered / shown on the framebuffer to
 adjust for the panel orientation.

 So now lets assume we apply the correct upside-down orientation later
 on a device with an upside-down mounted LCD panel. Then on boot the
 following could happen:

 1. amdgpu exports a connector for the LCD panel to userspace without
 setting panel-orient=upside-down
 2. plymouth sees this and renders its splash normally, but since the
 panel is upside-down it will now actually show upside-down
>>>
>>> At this point amdgpu hasn't probed the connector yet. So the connector
>>> will be marked as disconnected, and plymouth shouldn't render anything.
>>
>> If before the initial probe of the connector there is a /dev/dri/card0
>> which plymouth can access, then plymouth may at this point decide
>> to disable any seemingly unused crtcs, which will make the screen go black...
>>
>> I'm not sure if plymouth will actually do this, but AFAICT this would
>> not be invalid behavior for a userspace kms consumer to do and I
>> believe it is likely that mutter will disable unused crtcs.
>>
>> IMHO it is just a bad idea to register /dev/dri/card0 with userspace
>> before the initial connector probe is done. Nothing good can come
>> of that.
>>
>> If all the exposed connectors initially are going to show up as
>> disconnected anyways what is the value in registering /dev/dri/card0
>> with userspace early ?
> 
> OK. I'm still unsure how I feel about this, but I think I agree with
> you. That said, the amdgpu architecture is quite involved with multiple
> abstraction levels, so I don't think I'm equipped to write a patch to
> fix this...
> 

amdgpu_dm's connector registration already triggers a detection. See the
calls to dc_link_detect and amdgpu_dm_update_connector_after_detect in
amdgpu_dm_initialize_drm_device.

dc_link_detect is supposed to read the edid via
dm_helpers_read_local_edid and amdgpu_dm_update_connector_after_detect
will update the EDID on the connector via a
drm_connector_update_edid_property call.

This all happens at driver load.

I don't know why you're seeing the embedded connector as disconnected
unless the DP-MIPI bridge for some reason doesn't indicate that the panel
is connected at driver load.

Harry

> cc Daniel Vetter: can you confirm probing all connectors is a good thing
> to do on driver module load?
> 
 I guess the initial modeline is inherited from the video-bios, but
 what about the physical size? Note that you cannot just change the
 physical size later either, that gets used to determine the hidpi
 scaling factor in the bootsplash, and changing that after the initial
 bootsplash dislay will also look ugly

 b) Why you need the edid for the panel-orientation property at all,
 typically the edid prom is part of the panel and the panel does not
 know that it is mounted e.g. upside down at all, that is a property
 of the system as a whole not of the panel as a standalone unit so
 in my experience getting panel-orient info is something which comes
 from the firmware /video-bios not from edid ?
>>>
>>> This is an internal DRM thing. The orientation quirks logic uses the
>>> mode size advertised by the EDID.
>>
>> The DMI based quirking does, yes. But e.g. the quirk code directly
>> reading this from the Intel VBT does not rely on the mode.
>>
>> But if you are planning on using a DMI based quirk for the steamdeck
>> then yes that needs the mode.
>>
>> Thee mode check is there for 2 reasons:
>>
>> 1. To avoid also applying the quirk to external displays, but
>> I think that that is also solved in most drivers by only checking for
>> a quirk at all on the eDP connector
>>
>> 2. Some laptop models ship with different panels in different badges
>> some of these are portrait (so need a panel-orient) setting and others
>> are landscape.
> 
> That makes sense. So yeah the EDID mode based matching logic needs to
> stay to accomodate for these cases.
> 
>>> I agree that at least in the Steam
>>> Deck case it may not make a lot of sense to use any info from the
>>> EDID, but that's needed for the current status quo.
>>
>> We could extend the DMI quirk mechanism to allow quirks which don't
>> do the mode check, for use on devices where we can guarantee neither
>> 1 nor 2 happens, then amdgpu could call the 

Re: [Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

[Harry Wentland]

On 2021-10-29 09:43, Sean Paul wrote:
> On Thu, Oct 28, 2021 at 11:03:54PM -0400, Mark Yacoub wrote:
>> On Thu, Oct 28, 2021 at 8:42 PM Sean Paul  wrote:
>>>
>>> On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote:
 From: Mark Yacoub 

 [Why]
 This function and enum do not do generic checking on the luts but they
 test color channels in the LUTs.
>>>
>>> I'm not sure there's anything inherently specific to channels, it seems like
>>> one could add a new test to reflect a HW limitation and it would fit pretty 
>>> well
>>> in the lut check function. I wonder if it would be better to expose the 
>>> types of
>>> tests required by the crtc such that the atomic_check could also do the 
>>> test?
>>>
>> So the tests of the color are pretty unique to intel devices, no other
>> device is using it so I didn't think it adds a lot of benefit adding
>> it to the lut check. However, it's still in DRM because technically it
>> can be supported by any driver. But once it is, the driver will have
>> to expose the tests it wants so we can check it in atomic_check. but
>> given that no one does expose any test but intel, i just left it only
>> used by them.
>>
> 
> Yeah, understood. Regardless of that, the spirit of the function is not 
> specific
> to the color channels in the LUT, so renaming as channels_check is probably 
> not
> the correct fix. I'd probably lean towards stuffing this in i915 as a
> driver-specific check instead of renaming it.
> 

The checks could be generally useful for other drivers. I assume a lot
of HW wants the LUT to be non-decreasing and there might be other HW
out there that implements LUTs with a single channel that applies to
all colors. Since this is only used by i915 at the moment I don't have
a strong opinion about keeping it in DRM core or stuffing it into i915.

I agree with Sean that this function isn't specifically about color
channels. The function seems to be designed as a generic check for LUTs,
which is why the "tests" flag is passed in. DRM_COLOR_LUT_EQUAL_CHANNELS
is checking the channels but DRM_COLOR_LUT_NON_DECREASING doesn't
particularly have anything to do with the channels.

Harry

> Sean
> 
>>> Sean
>>>
 Keeping the name explicit as more generic LUT checks will follow.

 Tested on Eldrid ChromeOS (TGL).

 Signed-off-by: Mark Yacoub 
 ---
  drivers/gpu/drm/drm_color_mgmt.c   | 12 ++--
  drivers/gpu/drm/i915/display/intel_color.c | 10 +-
  include/drm/drm_color_mgmt.h   |  7 ---
  3 files changed, 15 insertions(+), 14 deletions(-)

 diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
 b/drivers/gpu/drm/drm_color_mgmt.c
 index bb14f488c8f6c..6f4e04746d90f 100644
 --- a/drivers/gpu/drm/drm_color_mgmt.c
 +++ b/drivers/gpu/drm/drm_color_mgmt.c
 @@ -585,17 +585,17 @@ int drm_plane_create_color_properties(struct 
 drm_plane *plane,
  EXPORT_SYMBOL(drm_plane_create_color_properties);

  /**
 - * drm_color_lut_check - check validity of lookup table
 + * drm_color_lut_channels_check - check validity of the channels in the 
 lookup table
   * @lut: property blob containing LUT to check
   * @tests: bitmask of tests to run
   *
 - * Helper to check whether a userspace-provided lookup table is valid and
 - * satisfies hardware requirements.  Drivers pass a bitmask indicating 
 which of
 - * the tests in _color_lut_tests should be performed.
 + * Helper to check whether each color channel of userspace-provided 
 lookup table is valid and
 + * satisfies hardware requirements. Drivers pass a bitmask indicating 
 which of in
 + * _color_lut_channels_tests should be performed.
   *
   * Returns 0 on success, -EINVAL on failure.
   */
 -int drm_color_lut_check(const struct drm_property_blob *lut, u32 tests)
 +int drm_color_lut_channels_check(const struct drm_property_blob *lut, u32 
 tests)
  {
   const struct drm_color_lut *entry;
   int i;
 @@ -625,4 +625,4 @@ int drm_color_lut_check(const struct drm_property_blob 
 *lut, u32 tests)

   return 0;
  }
 -EXPORT_SYMBOL(drm_color_lut_check);
 +EXPORT_SYMBOL(drm_color_lut_channels_check);
 diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
 b/drivers/gpu/drm/i915/display/intel_color.c
 index dab892d2251ba..4bb1bc76c4de9 100644
 --- a/drivers/gpu/drm/i915/display/intel_color.c
 +++ b/drivers/gpu/drm/i915/display/intel_color.c
 @@ -1285,7 +1285,7 @@ static int check_luts(const struct intel_crtc_state 
 *crtc_state)
   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
   const struct drm_property_blob *degamma_lut = 
 crtc_state->hw.degamma_lut;
   int gamma_length, degamma_length;
 - u32 gamma_tests, degamma_tests;
 + u32 gamma_channels_tests, degamma_channels_tests;

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

On 2021-10-27 04:00, Pekka Paalanen wrote:
> On Tue, 26 Oct 2021 11:36:33 -0400
> Harry Wentland  wrote:
> 
>> On 2021-10-14 15:44, Shankar, Uma wrote:
>>>
> 

...

>> FWIW, AMD HW (depending on generation) can do these operations
>> (in this order):
>>
>> 1) 1D LUT (fixed or PWL programmable)
>> 2) simple multiplier (for scaling SDR content to HDR output)
>> 3) CTM matrix
>> 4) 1D LUT (shaper LUT to non-linearize for more effective 3D LUT transform)
>> 5) 3D LUT
>> 6) 1D LUT (for non-linear blending, or to linearize after 3D LUT)
>> 7) blending
>> 8) CTM matrix
>> 9) 1D LUT (shaper LUT like above)
>> 10) 3D LUT
>> 11) 1D LUT (generally for EOTF^-1 for display EOTF)
>>
>> Not all blocks are available on all (current and future) HW.
>>
>> I sketched a few diagrams that show how these might be used by
>> a compositor if we exposed all of these blocks and should
>> really try to add some of them to the color-and-hdr docs
>> repo.
> 
> Yes, please.
> 
> That pipeline looks pretty comprehensive.
> 
> Btw. how about YUV<->RGB conversion? Where would that matrix go? It
> needs to operate on non-linear values, while a color space conversion
> matrix needs to operate on linear color values.
> 

That is communicated via drm_framebuffer.format, and drm_plane's
color_range and color_encoding. I expect it to happen before
everything else, i.e. at step 0. It seems like any color management
implementation I've seen is always operating in RGB.

Harry

>>>>>>> +   * This can be used to perform a color space conversion like
>>>>>>> +   * BT2020 to BT709 or BT601 etc.
>>>>>>> +   * This block is generally kept after the degamma unit so that  
>>>>>>
>>>>>> Not "generally". If blocks can change places, then it becomes 
>>>>>> intractable for generic userspace to program.  
>>>>>
>>>>> Sure, will drop this wording here. But one open will still remain 
>>>>> for userspace, as to how it gets the pipeline dynamically for a 
>>>>> respective hardware.
>>>>> Currently we have assumed that this would be the logical fixed order 
>>>>> of hardware units.  
>>>>
>>>> If we cannot model the abstract KMS pipeline as a fixed order of units 
>>>> (where each unit may exist or not), we need to take a few steps back 
>>>> here and look at what do we actually want to expose. That is a much 
>>>> bigger design problem which we are currently not even considering.  
>>>
>>> I think most of the hardware vendor platforms have this pipeline, so we can 
>>> implement the properties which include all the possible hardware blocks. If 
>>> certain units don't exist, the respective properties should not be exposed 
>>> which will make things easier for userspace.  
>>
>> I think the color pipeline should be modeled in a way that makes
>> sense from a color science standpoint and in a way that makes sense
>> for compositor implementations. Fortunately HW design generally
>> aligns with these intentions but we should be careful to not
>> let HW design dictate KMS interfaces.
> 
> I'm so happy to hear that!
> 
> 
> Thanks,
> pq
> 

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

On 2021-10-12 16:58, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Tuesday, October 12, 2021 4:01 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; 
>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>> shashank.sha...@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue,  7 Sep 2021 03:08:43 +0530
>> Uma Shankar  wrote:
>>

snip

>>> +
>>> +
>>> +This patch series adds properties for plane color features. It adds 
>>> +properties for degamma used to linearize data and CSC used for 
>>> +gamut conversion. It also includes Gamma support used to again 
>>> +non-linearize data as per panel supported color space. These can be 
>>> +utilize by user space to convert planes from one format to another, 
>>> +one color space to another etc.
>>
>> FWIW, this is exactly the structure I have assumed in the Weston CM work.
> 
> This is great to hear that we are aligned wrt how the pipeline should work.
> 
> Thanks Pekka for taking time out and providing the feedback.
> 
> @harry.wentl...@amd.com We can work together and build our design to 
> accommodate
> both Intel and AMD's hardware needs. This will also make things generic 
> enough for any
> other hardware vendor as well.
> 

Definitely. I think we're on the right path. Personally I would like to
arrive at a solid KMS definition for this by the time Weston guys
get to the HDR enablement with SW composition so we can start looking
at KMS offloading for HDR planes as next step.

Harry

> Thanks & Regards,
> Uma Shankar
> 
>>> +
>>> +Userspace can take smart blending decisions and utilize these 
>>> +hardware supported plane color features to get accurate color 
>>> +profile. The same can help in consistent color quality from source 
>>> +to panel taking advantage of advanced color features in hardware.
>>> +
>>> +These patches add the property interfaces and enable helper functions.
>>> +This series adds Intel's XE_LPD hw specific plane gamma feature. We 
>>> +can build up and add other platform/hardware specific 
>>> +implementation on top of this series.
>>> +
>>> +Credits: Special mention and credits to Ville Syrjala for coming up 
>>> +with a design for this feature and inputs. This series is based on 
>>> +his original design and idea.
>>
>>
>> Thanks,
>> pq

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

On 2021-10-14 15:44, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Wednesday, October 13, 2021 2:01 PM
>> To: Shankar, Uma 
>> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- 
>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>> shashank.sha...@amd.com
>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>
>> On Tue, 12 Oct 2021 20:58:27 +
>> "Shankar, Uma"  wrote:
>>
 -Original Message-
 From: Pekka Paalanen 
 Sent: Tuesday, October 12, 2021 4:01 PM
 To: Shankar, Uma 
 Cc: intel-gfx@lists.freedesktop.org; 
 dri-de...@lists.freedesktop.org; harry.wentl...@amd.com; 
 ville.syrj...@linux.intel.com; brian.star...@arm.com; 
 sebast...@sebastianwick.net; shashank.sha...@amd.com
 Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware 
 Pipeline

 On Tue,  7 Sep 2021 03:08:43 +0530 Uma Shankar 
  wrote:

> This is a RFC proposal for plane color hardware blocks.
> It exposes the property interface to userspace and calls out the 
> details or interfaces created and the intended purpose.
>
> Credits: Ville Syrjälä 
> Signed-off-by: Uma Shankar 
> ---
>  Documentation/gpu/rfc/drm_color_pipeline.rst | 167
> +++
>  1 file changed, 167 insertions(+)  create mode 100644 
> Documentation/gpu/rfc/drm_color_pipeline.rst
>
> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
> b/Documentation/gpu/rfc/drm_color_pipeline.rst
> new file mode 100644
> index ..0d1ca858783b
> --- /dev/null
> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
> @@ -0,0 +1,167 @@
> +==
> +Display Color Pipeline: Proposed DRM Properties
>>
>> ...
>>
> +Proposal is to have below properties for a plane:
> +
> +* Plane Degamma or Pre-Curve:
> + * This will be used to linearize the input framebuffer data.
> + * It will apply the reverse of the color transfer function.
> + * It can be a degamma curve or OETF for HDR.

 As you want to produce light-linear values, you use EOTF or inverse OETF.

 The term OETF has a built-in assumption that that happens in a camera:
 it takes in light and produces and electrical signal. Lately I 
 have personally started talking about non-linear encoding of color 
 values, since EOTF is often associated with displays if nothing 
 else is said (taking
>> in an electrical signal and producing light).

 So this would be decoding the color values into light-linear color 
 values. That is what an EOTF does, yes, but I feel there is a 
 nuanced difference. A piece of equipment implements an EOTF by 
 turning an electrical signal into light, hence EOTF often refers 
 to specific equipment. You could talk about content EOTF to denote 
 content value encoding, as opposed to output or display EOTF, but 
 that might be confusing if you look at e.g. the diagrams in
 BT.2100: is it the EOTF
>> or is it the inverse OETF? Is the (inverse?) OOTF included?

 So I try to side-step those questions by talking about encoding.
>>>
>>> The idea here is that frame buffer presented to display plane engine 
>>> will be non-
>> linear.
>>> So output of a media decode should result in content with EOTF applied.
>>
>> Hi,
>>
>> sure, but the question is: which EOTF. There can be many different 
>> things called "EOTF" in a single pipeline, and then it's up to the 
>> document writer to make the difference between them. Comparing two 
>> documents with different conventions causes a lot of confusion in my 
>> personal experience, so it is good to define the concepts more carefully.
> 
> Hi Pekka,
> I think you have given some nice inputs to really deep dive and document here.
> Will update this with the right expectations wrt what transfer functions to 
> be used at various stages in the operation pipeline.
> 
>>> So output of a media decode should result in content with EOTF applied.
>>
>> I suspect you have it backwards. Media decode produces electrical
>> (non-linear) pixel color values. If EOTF was applied, they would be 
>> linear instead (and require more memory to achieve the same visual 
>> precision).
>>
>> If you want to put it this way, you could say "with inverse EOTF 
>> applied", but that might be slightly confusing because it is already 
>> baked in to the video, it's not something a media decoder has to 
>> specifically apply, I think. However, the (inverse) EOTF in this case is the 
>> content EOTF, not the display EOTF.
>>
>> If content and display EOTF differ, then one must apply first content 
>> EOTF and then inverse display EOTF to get values that are correctly 
>> encoded for the display. (This is necessary but not sufficient in
>> 

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

[Harry Wentland]

Thanks, Uma, for the updated patches. I'm finally finding
time to go through them.

On 2021-10-15 03:42, Pekka Paalanen wrote:
> On Thu, 14 Oct 2021 19:44:25 +
> "Shankar, Uma"  wrote:
> 
>>> -Original Message-
>>> From: Pekka Paalanen 
>>> Sent: Wednesday, October 13, 2021 2:01 PM
>>> To: Shankar, Uma 
>>> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- 
>>> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
>>> brian.star...@arm.com; sebast...@sebastianwick.net; 
>>> shashank.sha...@amd.com
>>> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline
>>>
>>> On Tue, 12 Oct 2021 20:58:27 +
>>> "Shankar, Uma"  wrote:
>>>   
> -Original Message-
> From: Pekka Paalanen 
> Sent: Tuesday, October 12, 2021 4:01 PM
> To: Shankar, Uma 
> Cc: intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; harry.wentl...@amd.com; 
> ville.syrj...@linux.intel.com; brian.star...@arm.com; 
> sebast...@sebastianwick.net; shashank.sha...@amd.com
> Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware 
> Pipeline
>
> On Tue,  7 Sep 2021 03:08:43 +0530 Uma Shankar 
>  wrote:
>  
>> This is a RFC proposal for plane color hardware blocks.
>> It exposes the property interface to userspace and calls out the 
>> details or interfaces created and the intended purpose.
>>
>> Credits: Ville Syrjälä 
>> Signed-off-by: Uma Shankar 
>> ---
>>  Documentation/gpu/rfc/drm_color_pipeline.rst | 167
>> +++
>>  1 file changed, 167 insertions(+)  create mode 100644 
>> Documentation/gpu/rfc/drm_color_pipeline.rst
>>
>> diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst
>> b/Documentation/gpu/rfc/drm_color_pipeline.rst
>> new file mode 100644
>> index ..0d1ca858783b
>> --- /dev/null
>> +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst
>> @@ -0,0 +1,167 @@
>> +==
>> +Display Color Pipeline: Proposed DRM Properties  
> 
> ...
> 
>>> cf. BT.2100 Annex 1, "The relationship between the OETF, the EOTF and 
>>> the OOTF", although I find those diagrams somewhat confusing still. It 
>>> does not seem to clearly account for transmission non-linear encoding being 
>>> different from the display EOTF.
>>>
>>> Different documents use OOTF to refer to different things. Then there 
>>> is also the fundamental difference between PQ and HLG systems, where 
>>> OOTF is by definition in different places of the 
>>> camera-transmission-display pipeline.  
>>
>> Agree this is a bit confusing, I admit I was much more confused than what 
>> you were for sure.
>> Will do some research to get my understanding in place. Thanks for all the 
>> inputs.
> 
> I'm sure I was at least equally confused or even more at the start. I
> have just had a year of casual reading, discussions, and a W3C workshop
> attendance to improve my understanding. :-)
> 
> Now I know enough to be dangerous.
> 
> ...
> 
>> +
>> +UAPI Name: PLANE_DEGAMMA_MODE
>> +Description: Enum property with values as blob_id's which 
>> +advertizes
>> the  
>
> Is enum with blob id values even a thing?  

 Yeah we could have. This is a dynamic enum created with blobs. Each 
 entry contains the data structure to extract the full color 
 capabilities of the hardware. It’s a very interesting play with 
 blobs (@ville.syrj...@linux.intel.com brainchild)  
>>>
>>> Yes, I think I can imagine how that works. The blobs are created 
>>> immutable, unable to change once the plane has been advertised to 
>>> userspace, because their IDs are used as enum values. But that is ok, 
>>> because the blob describes capabilities that cannot change during the 
>>> device's lifetime... or can they? What if you would want to extend the 
>>> blob format, do you need a KMS client cap to change the format which 
>>> would be impossible because you can't change an enum definition after it 
>>> has been installed so you cannot swap the blob to a new one?
>>>
>>> This also relies on enums being identified by their string names, 
>>> because the numerical value is not a constant but a blob ID and gets 
>>> determined when the immutable blob is created.
>>>
>>> Did I understand correctly?  
>>
>> Yes that’s right. We are not expecting these structures to change as
>> they represent the platforms capabilities.
> 
> Until there comes a new platform whose capabilities you cannot quite
> describe with the existing structure. What's the plan to deal with that?
> A new enum value, like LUT2 instead of LUT? I suppose that works.
> 

See my comment on the coverletter. It would be great if we could come
up with a PWL definition that's generic enough to work on all HW
that uses PWL and not require compositors to learn a new LUT2
type in the future.

>>
>>> As a userspace developer, I can totally work 

Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features

[Harry Wentland]

On 2021-10-12 17:01, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Tuesday, October 12, 2021 5:25 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com;
>> sebast...@sebastianwick.net; shashank.sha...@amd.com
>> Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
>>
>> On Tue,  7 Sep 2021 03:08:42 +0530
>> Uma Shankar  wrote:
>>
>>> This is how a typical display color hardware pipeline looks like:
>>>  +---+
>>>  |RAM|
>>>  |  +--++-++-+   |
>>>  |  | FB 1 ||  FB 2   || FB N|   |
>>>  |  +--++-++-+   |
>>>  +---+
>>>|  Plane Color Hardware Block |
>>> ++
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | DeGamma |   | Degamma   |   | Degamma  | |
>>>  | +---+-+   +---+---+   +---+--+ |
>>>  | | |   ||
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | |Plane A  |   | Plane B   |   | Plane N  | |
>>>  | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  | +---v-+   +v--+   +v-+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | Gamma   |   | Gamma |   | Gamma| |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  ++
>>> +--v--v---v---|
>>> ||   ||
>>> ||   Pipe Blender||
>>> +++
>>> |||
>>> |+---v--+ |
>>> ||  Pipe DeGamma| |
>>> ||  | |
>>> |+---+--+ |
>>> ||Pipe Color  |
>>> |+---v--+ Hardware|
>>> ||  Pipe CSC/CTM| |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> |+---v--+ |
>>> ||  Pipe Gamma  | |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> +-+
>>>  |
>>>  v
>>>Pipe Output
>>>
>>> This patch series adds properties for plane color features. It adds
>>> properties for degamma used to linearize data and CSC used for gamut
>>> conversion. It also includes Gamma support used to again non-linearize
>>> data as per panel supported color space. These can be utilize by user
>>> space to convert planes from one format to another, one color space to
>>> another etc.
>>>
>>> Userspace can take smart blending decisions and utilize these hardware
>>> supported plane color features to get accurate color profile. The same
>>> can help in consistent color quality from source to panel taking
>>> advantage of advanced color features in hardware.
>>>
>>> These patches add the property interfaces and enable helper functions.
>>> This series adds Intel's XE_LPD hw specific plane gamma feature. We
>>> can build up and add other platform/hardware specific implementation
>>> on top of this series.
>>>
>>> Credits: Special mention and credits to Ville Syrjala for coming up
>>> with a design for this feature and inputs. This series is based on his
>>> original design and idea.
>>>
>>> Note: Userspace support for this new UAPI will be done on Chrome in
>>> alignment with weston and general opensource community.
>>> Discussion

Re: [Intel-gfx] [PATCH 02/15] drm/amdgpu: use drm_* functions instead of duplicated code in amdgpu driver

[Harry Wentland]

On 2021-10-15 07:37, Claudio Suarez wrote:
> a) Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. The amdgpu driver still calls
> drm_detect_hdmi_monitor() to retrieve the same information, which
> is less efficient. Change to drm_display_info.is_hdmi
> 
> This is a TODO task in Documentation/gpu/todo.rst
> 
> b) drm_display_info is updated by drm_get_edid() or
> drm_connector_update_edid_property(). In the amdgpu driver it is almost
> always updated when the edid is read in amdgpu_connector_get_edid(),
> but not always.  Change amdgpu_connector_get_edid() and
> amdgpu_connector_free_edid() to keep drm_display_info updated. This allows a)
> to work properly.
> 
> c) Use drm_edid_get_monitor_name() instead of duplicating the code that
> parses the EDID in dm_helpers_parse_edid_caps()
> 
> Also, remove the unused "struct dc_context *ctx" parameter in
> dm_helpers_parse_edid_caps()
> 

Thanks for this work.

The fact that you listed three separate changes in this commit
is a clear indication that this patch should be three separate
patches instead. Separating the functional bits from the straight
refactor will help with bisection if this leads to a regression.

All changes look reasonable to me, though. With this patch split
into three patches in the sequence (b), (c), then (a) this is
Reviewed-by: Harry Wentland 

Harry

> Signed-off-by: Claudio Suarez 
> ---
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +++
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.h|  2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c  |  4 +-
>  .../gpu/drm/amd/amdgpu/atombios_encoders.c|  6 +--
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 39 ++-
>  drivers/gpu/drm/amd/display/dc/core/dc.c  |  2 +-
>  drivers/gpu/drm/amd/display/dc/dm_helpers.h   |  2 +-
>  9 files changed, 39 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index b9c11c2b2885..7b41a1120b70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -25,6 +25,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -108,7 +109,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
> *connector)
>   case DRM_MODE_CONNECTOR_DVII:
>   case DRM_MODE_CONNECTOR_HDMIB:
>   if (amdgpu_connector->use_digital) {
> - if 
> (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
>   if (connector->display_info.bpc)
>   bpc = connector->display_info.bpc;
>   }
> @@ -116,7 +117,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
> *connector)
>   break;
>   case DRM_MODE_CONNECTOR_DVID:
>   case DRM_MODE_CONNECTOR_HDMIA:
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
>   if (connector->display_info.bpc)
>   bpc = connector->display_info.bpc;
>   }
> @@ -125,7 +126,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
> *connector)
>   dig_connector = amdgpu_connector->con_priv;
>   if ((dig_connector->dp_sink_type == 
> CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
>   (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP) ||
> - drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + (amdgpu_connector_is_hdmi_monitor(connector))) {
>   if (connector->display_info.bpc)
>   bpc = connector->display_info.bpc;
>   }
> @@ -149,7 +150,7 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
> *connector)
>   break;
>   }
>  
> - if (drm_detect_hdmi_monitor(amdgpu_connector_edid(connector))) {
> + if (amdgpu_connector_is_hdmi_monitor(connector)) {
>   /*
>* Pre DCE-8 hw can't handle > 12 bpc, and more than 12 bpc 
> doesn't make
>* much sense without support for > 12 bpc framebuffers. RGB 
> 4:4:4 at
> @@ -315,8 +316,10 @@ static void amdgpu_connector_get_edid(struct 
> drm_connector *connector)
>   if (!amdgpu

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

[Harry Wentland]

On 2021-10-08 04:36, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> Is it my checkout only or this causes a lot of build warnings for everyone?
> 
> ./include/drm/drm_dp_helper.h:1120: warning: 
> "DP_TEST_264BIT_CUSTOM_PATTERN_7_0" redefined
>  1120 | #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0x2230
>   |
> In file included from 
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:35,
>  from 
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
>  from 
> ./drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu.h:66,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:40:
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:871: note: this is 
> the location of the previous definition
> 
> Etc..
> 

Fixed by https://patchwork.freedesktop.org/patch/456190/?series=95166=2 but 
looks like it's not in drm-misc-next.

Siqueira, do you have bandwidth to pull that patch into drm-misc-next?

Harry

> Regards,
> 
> Tvrtko
> 
> 
> On 30/09/2021 22:21, Rodrigo Siqueira wrote:
>> Applied to drm-misc-next.
>>
>> Thanks
>>
>> On 09/28, Harry Wentland wrote:
>>> On 2021-09-27 15:23, Fangzhi Zuo wrote:
>>>> Include FEC, DSC, Link Training related headers.
>>>>
>>>> Change since v2
>>>> - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
>>>>
>>>> Signed-off-by: Fangzhi Zuo 
>>>
>>> Reviewed-by: Harry Wentland 
>>>
>>> Harry
>>>
>>>> ---
>>>> This patch is based on top of the other DP2.0 work in
>>>> "drm/dp: add LTTPR DP 2.0 DPCD addresses"
>>>> ---
>>>>   include/drm/drm_dp_helper.h | 20 
>>>>   1 file changed, 20 insertions(+)
>>>>
>>>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>>>> index 1d5b3dbb6e56..a1df35aa6e68 100644
>>>> --- a/include/drm/drm_dp_helper.h
>>>> +++ b/include/drm/drm_dp_helper.h
>>>> @@ -453,6 +453,7 @@ struct drm_panel;
>>>>   # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>>>>   # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP    (1 << 2)
>>>>   # define DP_FEC_BIT_ERROR_COUNT_CAP    (1 << 3)
>>>> +#define DP_FEC_CAPABILITY_1    0x091   /* 2.0 */
>>>>     /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
>>>>   #define DP_PCON_DSC_ENCODER_CAP_SIZE    0xC    /* 0x9E - 0x92 */
>>>> @@ -537,6 +538,9 @@ struct drm_panel;
>>>>   #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
>>>>   #define DP_DSC_BRANCH_MAX_LINE_WIDTH    0x0a2
>>>>   +/* DFP Capability Extension */
>>>> +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT    0x0a3    /* 2.0 */
>>>> +
>>>>   /* Link Configuration */
>>>>   #define    DP_LINK_BW_SET    0x100
>>>>   # define DP_LINK_RATE_TABLE    0x00    /* eDP 1.4 */
>>>> @@ -688,6 +692,7 @@ struct drm_panel;
>>>>     #define DP_DSC_ENABLE   0x160   /* DP 1.4 */
>>>>   # define DP_DECOMPRESSION_EN    (1 << 0)
>>>> +#define DP_DSC_CONFIGURATION    0x161    /* DP 2.0 */
>>>>     #define DP_PSR_EN_CFG    0x170   /* XXX 1.2? */
>>>>   # define DP_PSR_ENABLE    BIT(0)
>>>> @@ -743,6 +748,7 @@ struct drm_panel;
>>>>   # define DP_RECEIVE_PORT_0_STATUS    (1 << 0)
>>>>   # define DP_RECEIVE_PORT_1_STATUS    (1 << 1)
>>>>   # define DP_STREAM_REGENERATION_STATUS  (1 << 2) /* 2.0 */
>>>> +# define DP_INTRA_HOP_AUX_REPLY_INDICATION    (1 << 3) /* 2.0 */
>>>>     #define DP_ADJUST_REQUEST_LANE0_1    0x206
>>>>   #define DP_ADJUST_REQUEST_LANE2_3    0x207
>>>> @@ -865,6 +871,8 @@ struct drm_panel;
>>>>   # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
>>>>   # define DP_PHY_TEST_PATTERN_CP2520 0x5
>>>>   +#define DP_PHY_SQUARE_PATTERN    0x249
>>>> +
>>>>   #define DP_TEST_HBR2_SCRAMBLER_RESET    0x24A
>>>>   #define DP_TEST_80BIT_CUSTOM_PATTERN_7_0    0x250
>>>>   #define    DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
>>>> @@ -1109,6 +1117,18 @@ struct drm_panel;
>>>>   #define DP_128B132B_TRAINING_AUX_RD_INTERVAL   0x2216 /* 2.0 */
>>>>   # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f
>>>>   +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0    0x2230
>>>> +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256    0x2250
>>>> +
>>>> +/* DSC Extended Capability Branch Total DSC Resources */
>>>> +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT    0x2260    /* 2.0 */
>>>> +# define DP_DSC_DECODER_COUNT_MASK    (0b111 << 5)
>>>> +# define DP_DSC_DECODER_COUNT_SHIFT    5
>>>> +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0    0x2270    /* 2.0 */
>>>> +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK    (1 << 0)
>>>> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK    (0b111 << 1)
>>>> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT    1
>>>> +
>>>>   /* Protocol Converter Extension */
>>>>   /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
>>>>   #define DP_CEC_TUNNELING_CAPABILITY    0x3000
>>>>
>>>
>>

Re: [Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

[Harry Wentland]

On 2021-09-28 23:58, Navare, Manasi D wrote:
> [AMD Official Use Only]
> 
> We have merged such DRM definition dependencies previously through a topic 
> branch in order to avoid redefining inside the driver.
> But yes guarding this with ifdef is good.
> 
> Reviewed-by: Manasi Navare 
> 

Ah, I merged it already. But thanks for your review.

I agree these are better defined in drm headers, with a preparatory
patch if needed by the driver. We're working on cleaning it up and
dropping the driver defines.

Harry

> Manasi
> 
> -Original Message-
> From: Zuo, Jerry 
> Sent: Tuesday, September 28, 2021 11:11 PM
> To: Wentland, Harry ; Deucher, Alexander 
> ; amd-...@lists.freedesktop.org
> Cc: Nikula, Jani ; Li, Sun peng (Leo) 
> ; nat...@kernel.org; intel-gfx@lists.freedesktop.org; 
> dri-de...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Navare, 
> Manasi D ; Koenig, Christian 
> ; Pan, Xinhui ; 
> s...@canb.auug.org.au; linux-n...@vger.kernel.org; airl...@gmail.com; 
> daniel.vet...@ffwll.ch; Wentland, Harry 
> Subject: RE: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not 
> already defined
> 
> [AMD Official Use Only]
> 
>> -Original Message-
>> From: Harry Wentland 
>> Sent: September 28, 2021 1:08 PM
>> To: Deucher, Alexander ; amd-
>> g...@lists.freedesktop.org; Zuo, Jerry 
>> Cc: jani.nik...@intel.com; Li, Sun peng (Leo) ;
>> nat...@kernel.org; intel-gfx@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
>> manasi.d.nav...@intel.com; Koenig, Christian
>> ; Pan, Xinhui ;
>> s...@canb.auug.org.au; linux- n...@vger.kernel.org; airl...@gmail.com;
>> daniel.vet...@ffwll.ch; Wentland, Harry 
>> Subject: [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not
>> already defined
>>
>> [Why]
>> For some reason we're defining DP 2.0 definitions inside our driver.
>> Now that patches to introduce relevant definitions are slated to be
>> merged into drm- next this is causing conflicts.
>>
>> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
>> In file included
>> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
>> ./include/drm/drm_dp_helper.h:1322:9: error:
>> 'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined [-
>> Werror,-Wmacro-redefined]
>> ^
>> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note:
>> previous definition is here
>> ^
>> 1 error generated.
>>
>> v2: Add one missing endif
>>
>> [How]
>> Guard all display driver defines with #ifndef for now. Once we pull in
>> the new definitions into amd-staging-drm-next we will follow up and
>> drop definitions from our driver and provide follow-up header updates
>> for any addition DP
>> 2.0 definitions required by our driver.
>>
>> Signed-off-by: Harry Wentland 
> 
> Reviewed-by: Fangzhi Zuo 
> 
>> ---
>>  drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54
>> ++--
>>  1 file changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> index a5e798b5da79..9de86ff5ef1b 100644
>> --- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> +++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
>> @@ -860,28 +860,72 @@ struct psr_caps {  };
>>
>>  #if defined(CONFIG_DRM_AMD_DC_DCN)
>> +#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
>>  #define DP_MAIN_LINK_CHANNEL_CODING_CAP  0x006
>> +#endif
>> +#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
>>  #define DP_SINK_VIDEO_FALLBACK_FORMATS   0x020
>> +#endif
>> +#ifndef DP_FEC_CAPABILITY_1
>>  #define DP_FEC_CAPABILITY_1  0x091
>> +#endif
>> +#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
>>  #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0A3
>> +#endif
>> +#ifndef DP_DSC_CONFIGURATION
>>  #define DP_DSC_CONFIGURATION 0x161
>> +#endif
>> +#ifndef DP_PHY_SQUARE_PATTERN
>>  #define DP_PHY_SQUARE_PATTERN0x249
>> +#endif
>> +#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
>>  #define DP_128b_132b_SUPPORTED_LINK_RATES0x2215
>> +#endif
>> +#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>>  #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL
>>   0x2216
>> +#endif
>> +#ifndef DP_TEST_264BI

[Intel-gfx] [PATCH v3] drm/amd/display: Only define DP 2.0 symbols if not already defined

[Harry Wentland]

[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined 
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous 
definition is here
^
1 error generated.

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

We also ensure drm_dp_helper.h is included before dc_dp_types.h.

v3: Ensure drm_dp_helper.h is included before dc_dp_types.h

v2: Add one missing endif

Signed-off-by: Harry Wentland 
Reviewed-by: Fangzhi Zuo 
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
 drivers/gpu/drm/amd/display/dc/os_types.h|  1 +
 2 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
 };
 
 #if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
 #define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
 #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
 #define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
 #define DP_DSC_CONFIGURATION   0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
 #define DP_PHY_SQUARE_PATTERN  0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
 #define DP_128b_132b_SUPPORTED_LINK_RATES  0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL  0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
 #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
 #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
 #define DP_DSC_SUPPORT_AND_DECODER_COUNT   0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
 #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK  (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK  (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK  (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
 #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER   0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
 #define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
 #define DP_INTRA_HOP_AUX_REPLY_INDICATION  (1 << 3)
+#endif
 /* TODO - Use DRM header to replace above once available */
 
 union dp_main_line_channel_coding_cap {
diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h 
b/drivers/gpu/drm/amd/display/dc/os_types.h
index f50cae252de4..34efb708ea12 100644
--- a/drivers/gpu/drm/amd/display/dc/os_types.h
+++ b/drivers/gpu/drm/amd/display/dc/os_types.h
@@ -35,6 +35,7 @@
 #include 
 
 #include 
+#include 
 
 #include "cgs_common.h"
 
-- 
2.33.0

[Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

[Harry Wentland]

[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined 
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous 
definition is here
^
1 error generated.

v2: Add one missing endif

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++--
 1 file changed, 49 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..9de86ff5ef1b 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,72 @@ struct psr_caps {
 };
 
 #if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
 #define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
 #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
 #define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
 #define DP_DSC_CONFIGURATION   0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
 #define DP_PHY_SQUARE_PATTERN  0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
 #define DP_128b_132b_SUPPORTED_LINK_RATES  0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL  0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
 #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
 #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
 #define DP_DSC_SUPPORT_AND_DECODER_COUNT   0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
 #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK  (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK  (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK  (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
 #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER   0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
 #define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
 #define DP_INTRA_HOP_AUX_REPLY_INDICATION  (1 << 3)
+#endif
 /* TODO - Use DRM header to replace above once available */
 
 union dp_main_line_channel_coding_cap {
-- 
2.33.0

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

[Harry Wentland]

On 2021-09-27 15:23, Fangzhi Zuo wrote:
> Include FEC, DSC, Link Training related headers.
> 
> Change since v2
> - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
> 
> Signed-off-by: Fangzhi Zuo 

Reviewed-by: Harry Wentland 

Harry

> ---
> This patch is based on top of the other DP2.0 work in
> "drm/dp: add LTTPR DP 2.0 DPCD addresses"
> ---
>  include/drm/drm_dp_helper.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 1d5b3dbb6e56..a1df35aa6e68 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -453,6 +453,7 @@ struct drm_panel;
>  # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>  # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
>  # define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +#define DP_FEC_CAPABILITY_1  0x091   /* 2.0 */
>  
>  /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
>  #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC  /* 0x9E - 0x92 */
> @@ -537,6 +538,9 @@ struct drm_panel;
>  #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
>  #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2
>  
> +/* DFP Capability Extension */
> +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0a3   /* 2.0 */
> +
>  /* Link Configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -688,6 +692,7 @@ struct drm_panel;
>  
>  #define DP_DSC_ENABLE   0x160   /* DP 1.4 */
>  # define DP_DECOMPRESSION_EN(1 << 0)
> +#define DP_DSC_CONFIGURATION 0x161   /* DP 2.0 */
>  
>  #define DP_PSR_EN_CFG0x170   /* XXX 1.2? */
>  # define DP_PSR_ENABLE   BIT(0)
> @@ -743,6 +748,7 @@ struct drm_panel;
>  # define DP_RECEIVE_PORT_0_STATUS(1 << 0)
>  # define DP_RECEIVE_PORT_1_STATUS(1 << 1)
>  # define DP_STREAM_REGENERATION_STATUS  (1 << 2) /* 2.0 */
> +# define DP_INTRA_HOP_AUX_REPLY_INDICATION   (1 << 3) /* 2.0 */
>  
>  #define DP_ADJUST_REQUEST_LANE0_10x206
>  #define DP_ADJUST_REQUEST_LANE2_30x207
> @@ -865,6 +871,8 @@ struct drm_panel;
>  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
>  # define DP_PHY_TEST_PATTERN_CP2520 0x5
>  
> +#define DP_PHY_SQUARE_PATTERN0x249
> +
>  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
> @@ -1109,6 +1117,18 @@ struct drm_panel;
>  #define DP_128B132B_TRAINING_AUX_RD_INTERVAL   0x2216 /* 2.0 */
>  # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f
>  
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_00x2230
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_2560x2250
> +
> +/* DSC Extended Capability Branch Total DSC Resources */
> +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260  /* 2.0 */
> +# define DP_DSC_DECODER_COUNT_MASK   (0b111 << 5)
> +# define DP_DSC_DECODER_COUNT_SHIFT  5
> +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270  /* 2.0 */
> +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 << 0)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK   (0b111 << 1)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT  1
> +
>  /* Protocol Converter Extension */
>  /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
>  #define DP_CEC_TUNNELING_CAPABILITY0x3000
> 

Re: [Intel-gfx] [PATCH] drm/dp: Add Additional DP2 Headers

[Harry Wentland]

On 2021-09-27 10:38, Fangzhi Zuo wrote:
> Include FEC, DSC, Link Training related headers.
> 
> Signed-off-by: Fangzhi Zuo 

Please send this to dri-devel and amd-gfx as well.

> ---

The section after the '---' is not part of the commit
description. Please mention here that this patch is based
on top of the other DP2.0 header patches from Intel and
leave a link here, for context.

>  include/drm/drm_dp_helper.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 1d5b3dbb6e56..bfd8e3e0171d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -453,6 +453,7 @@ struct drm_panel;
>  # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP  (1 << 1)
>  # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
>  # define DP_FEC_BIT_ERROR_COUNT_CAP  (1 << 3)
> +#define DP_FEC_CAPABILITY_1  0x091   /* 2.0 */
>  
>  /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
>  #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC  /* 0x9E - 0x92 */
> @@ -537,6 +538,9 @@ struct drm_panel;
>  #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1  0x0a1
>  #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2
>  
> +/* DFP Capability Extension */
> +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT  0x0a3   /* 2.0 */
> +
>  /* Link Configuration */
>  #define  DP_LINK_BW_SET  0x100
>  # define DP_LINK_RATE_TABLE  0x00/* eDP 1.4 */
> @@ -688,6 +692,7 @@ struct drm_panel;
>  
>  #define DP_DSC_ENABLE   0x160   /* DP 1.4 */
>  # define DP_DECOMPRESSION_EN(1 << 0)
> +#define DP_DSC_CONFIGURATION 0x161   /* DP 2.0 */
>  
>  #define DP_PSR_EN_CFG0x170   /* XXX 1.2? */
>  # define DP_PSR_ENABLE   BIT(0)
> @@ -743,6 +748,7 @@ struct drm_panel;
>  # define DP_RECEIVE_PORT_0_STATUS(1 << 0)
>  # define DP_RECEIVE_PORT_1_STATUS(1 << 1)
>  # define DP_STREAM_REGENERATION_STATUS  (1 << 2) /* 2.0 */
> +# define DP_INTRA_HOP_AUX_REPLY_INDICATION   (1 << 3) /* 2.0 */

Are you sure this is DP 2.0? The DP2.0 spec has 'RESERVED'
bits after the STREAM_REGENERATION_STATUS.

>  
>  #define DP_ADJUST_REQUEST_LANE0_10x206
>  #define DP_ADJUST_REQUEST_LANE2_30x207
> @@ -865,6 +871,8 @@ struct drm_panel;
>  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
>  # define DP_PHY_TEST_PATTERN_CP2520 0x5
>  
> +#define DP_PHY_SQUARE_PATTERN0x249
> +
>  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
> @@ -1109,6 +1117,18 @@ struct drm_panel;
>  #define DP_128B132B_TRAINING_AUX_RD_INTERVAL   0x2216 /* 2.0 */
>  # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f
>  
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_00x2230
> +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_2560x2250
> +
> +/* DSC Extended Capability Branch Total DSC Resources */
> +#define DP_DSC_SUPPORT_AND_DECODER_COUNT 0x2260  /* 2.0 
> */

To align with the spec and make it easier to search this should be:
DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT

> +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270  /* 2.0 */
> +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK   (1 << 0)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK   (0b111 << 1)
> +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT  1
> +# define DP_DSC_DECODER_COUNT_MASK   (0b111 << 5)
> +# define DP_DSC_DECODER_COUNT_SHIFT  5
> +

The spec seems to call these "DSC Decoder 1 Aggregation Support" and also
has a definition for "DSC Decoder 1 Maximum Slice Count"

Harry

>  /* Protocol Converter Extension */
>  /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */
>  #define DP_CEC_TUNNELING_CAPABILITY0x3000
> 

[Intel-gfx] [PATCH] drm/amd/display: Only define DP 2.0 symbols if not already defined

[Harry Wentland]

[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.

In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:70:
In file included from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_mode.h:36:
./include/drm/drm_dp_helper.h:1322:9: error: 
'DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER' macro redefined 
[-Werror,-Wmacro-redefined]
^
./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:881:9: note: previous 
definition is here
^
1 error generated.

[How]
Guard all display driver defines with #ifndef for now. Once we pull
in the new definitions into amd-staging-drm-next we will follow
up and drop definitions from our driver and provide follow-up
header updates for any addition DP 2.0 definitions required
by our driver.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 53 ++--
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
index a5e798b5da79..74b8de616dcd 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_dp_types.h
@@ -860,28 +860,71 @@ struct psr_caps {
 };
 
 #if defined(CONFIG_DRM_AMD_DC_DCN)
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_CAP
 #define DP_MAIN_LINK_CHANNEL_CODING_CAP0x006
+#endif
+#ifndef DP_SINK_VIDEO_FALLBACK_FORMATS
 #define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020
+#endif
+#ifndef DP_FEC_CAPABILITY_1
 #define DP_FEC_CAPABILITY_10x091
+#endif
+#ifndef DP_DFP_CAPABILITY_EXTENSION_SUPPORT
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0A3
+#endif
+#ifndef DP_DSC_CONFIGURATION
 #define DP_DSC_CONFIGURATION   0x161
+#endif
+#ifndef DP_PHY_SQUARE_PATTERN
 #define DP_PHY_SQUARE_PATTERN  0x249
+#endif
+#ifndef DP_128b_132b_SUPPORTED_LINK_RATES
 #define DP_128b_132b_SUPPORTED_LINK_RATES  0x2215
+#endif
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL  0x2216
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_7_0
 #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0  0X2230
+#endif
+#ifndef DP_TEST_264BIT_CUSTOM_PATTERN_263_256
 #define DP_TEST_264BIT_CUSTOM_PATTERN_263_256  0X2250
+#endif
+#ifndef DP_DSC_SUPPORT_AND_DECODER_COUNT
 #define DP_DSC_SUPPORT_AND_DECODER_COUNT   0x2260
+#endif
+#ifndef DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0
 #define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0   0x2270
-# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1)
-# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1
-# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5)
-# define DP_DSC_DECODER_COUNT_SHIFT5
+#endif
+#ifndef DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK
+#define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK  (1 << 0)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK  (0b111 << 1)
+#endif
+#ifndef DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT
+#define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1
+#endif
+#ifndef DP_DSC_DECODER_COUNT_MASK
+#define DP_DSC_DECODER_COUNT_MASK  (0b111 << 5)
+#endif
+#ifndef DP_DSC_DECODER_COUNT_SHIFT
+#define DP_DSC_DECODER_COUNT_SHIFT 5
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_SET
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
+#endif
+#ifndef DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER
 #define DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER   0xF0006
+#endif
+#ifndef DP_PHY_REPEATER_128b_132b_RATES
 #define DP_PHY_REPEATER_128b_132b_RATES0xF0007
+#ifndef DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1
 #define DP_128b_132b_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xF0022
+#endif
+#ifndef DP_INTRA_HOP_AUX_REPLY_INDICATION
 #define DP_INTRA_HOP_AUX_REPLY_INDICATION  (1 << 3)
+#endif
 /* TODO - Use DRM header to replace above once available */
 
 union dp_main_line_channel_coding_cap {
-- 
2.33.0

Re: [Intel-gfx] [PATCH 00/14] drm/hdcp: Pull HDCP auth/exchange/check into

[Harry Wentland]

On 2021-09-13 3:26 p.m., Sean Paul wrote:
> On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher  wrote:
>>
>> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul  wrote:
>>>
>>> From: Sean Paul 
>>>
>>> Hello,
>>> This patchset pulls the HDCP protocol auth/exchange/check logic out from
>>> i915 into a HDCP helper library which drivers can use to implement the
>>> proper protocol and UAPI interactions for achieving HDCP.
>>>
>>> Originally this was all stuffed into i915 since it was the only driver
>>> supporting HDCP. Over the last while I've been working on HDCP support
>>> in the msm driver and have identified the parts which can/should be
>>> shared between drivers and the parts which are hw-specific.
>>>
>>> We can generalize all of the sink interactions in the helper as well as
>>> state handling and link checks. This tends to be the trickiest part of
>>> adding HDCP support, since the property state and locking is a bit of a
>>> nightmare. The driver need only implement the more mechanical display
>>> controller register accesses.
>>>
>>> The first third of the pachset is establishing the helpers, the next
>>> third is converting the i915 driver to use the helpers, and the last
>>> third is the msm driver implementation.
>>>
>>> I've left out HDCP 2.x support, since we still only have i915 as the
>>> reference implementation and I'm not super comfortable speculating on
>>> which parts are platform independent.
>>
>> FWIW, amdgpu has support for both HDCP 1.x and 2.x
>>
> 
> Thanks Alex, I knew this and neglected to mention it, apologies for
> the omission.
> 
> IIRC amdgpu is much less hands-on than i915/msm, with PSP doing most
> of the heavy lifting. There's probably some value in using the helpers
> since it'll handle the state transitions in a consistent manner, do
> you think this is something you can use?
> 

We might be able to use drm_hdcp_atomic_check but the HDCP protocol
stuff is sitting in our hdcp module and shared with other OSes so
sharing it would be difficult.

Harry

> Sean
> 
> 
>> Alex
>>
>>>
>>> Please take a look,
>>>
>>> Sean
>>>
>>> Sean Paul (14):
>>>   drm/hdcp: Add drm_hdcp_atomic_check()
>>>   drm/hdcp: Avoid changing crtc state in hdcp atomic check
>>>   drm/hdcp: Update property value on content type and user changes
>>>   drm/hdcp: Expand HDCP helper library for enable/disable/check
>>>   drm/i915/hdcp: Consolidate HDCP setup/state cache
>>>   drm/i915/hdcp: Retain hdcp_capable return codes
>>>   drm/i915/hdcp: Use HDCP helpers for i915
>>>   drm/msm/dpu_kms: Re-order dpu includes
>>>   drm/msm/dpu: Remove useless checks in dpu_encoder
>>>   drm/msm/dpu: Remove encoder->enable() hack
>>>   drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules
>>>   dt-bindings: msm/dp: Add bindings for HDCP registers
>>>   drm/msm: Add hdcp register ranges to sc7180 device tree
>>>   drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
>>>
>>>  .../bindings/display/msm/dp-controller.yaml   |   11 +-
>>>  drivers/gpu/drm/drm_hdcp.c| 1198 -
>>>  drivers/gpu/drm/i915/display/intel_atomic.c   |7 +-
>>>  drivers/gpu/drm/i915/display/intel_ddi.c  |   29 +-
>>>  .../drm/i915/display/intel_display_debugfs.c  |   11 +-
>>>  .../drm/i915/display/intel_display_types.h|   58 +-
>>>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  |  341 ++---
>>>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |   17 +-
>>>  drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++---
>>>  drivers/gpu/drm/i915/display/intel_hdcp.h |   35 +-
>>>  drivers/gpu/drm/i915/display/intel_hdmi.c |  256 ++--
>>>  drivers/gpu/drm/msm/Makefile  |1 +
>>>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   17 +-
>>>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   30 +-
>>>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |2 -
>>>  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 -
>>>  drivers/gpu/drm/msm/dp/dp_debug.c |   49 +-
>>>  drivers/gpu/drm/msm/dp/dp_debug.h |6 +-
>>>  drivers/gpu/drm/msm/dp/dp_display.c   |   47 +-
>>>  drivers/gpu/drm/msm/dp/dp_display.h   |5 +
>>>  drivers/gpu/drm/msm/dp/dp_drm.c   |   68 +-
>>>  drivers/gpu/drm/msm/dp/dp_drm.h   |5 +
>>>  drivers/gpu/drm/msm/dp/dp_hdcp.c  |  433 ++
>>>  drivers/gpu/drm/msm/dp/dp_hdcp.h  |   27 +
>>>  drivers/gpu/drm/msm/dp/dp_parser.c|   30 +-
>>>  drivers/gpu/drm/msm/dp/dp_parser.h|4 +
>>>  drivers/gpu/drm/msm/dp/dp_reg.h   |   44 +-
>>>  drivers/gpu/drm/msm/msm_atomic.c  |   15 +
>>>  include/drm/drm_hdcp.h|  194 +++
>>>  29 files changed, 2570 insertions(+), 1385 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c
>>>  create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h
>>>
>>> --
>>> Sean Paul, Software Engineer, Google / Chromium OS
>>>

Re: [Intel-gfx] [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

[Harry Wentland]

On 2021-06-01 6:52 a.m., Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 52 ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index dab892d2251b..c735d06a6b54 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2093,6 +2093,58 @@ static void icl_read_luts(struct intel_crtc_state 
> *crtc_state)
>   }
>  }
>  
> + /* FIXME input bpc? */
> +__maybe_unused
> +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> + /* segment 1 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |

Why are these using DRM_MODE_LUT_GAMMA and not DRM_MODE_LUT_DEGAMMA when
the lut_type for this LUT is LUT_TYPE_DEGAMMA?


> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> +   DRM_MODE_LUT_INTERPOLATE |
> +   DRM_MODE_LUT_NON_DECREASING),
> + .count = 128,
> + .input_bpc = 24, .output_bpc = 16,

Why do we need more than 16 bpc for LUT? FP16 is enough to represent HDR in 
linear space. Wouldn't 16 bpc be enough?


> + .start = 0, .end = (1 << 24) - 1,
> + .min = 0, .max = (1 << 24) - 1,
> + },
> + /* segment 2 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> +   DRM_MODE_LUT_INTERPOLATE |
> +   DRM_MODE_LUT_REUSE_LAST |
> +   DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = (1 << 24) - 1, .end = 1 << 24,
> + .min = 0, .max = (1 << 27) - 1,

How can max be 1 << 27 if input_bpc is 24?

Harry

> + },
> + /* Segment 3 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> +   DRM_MODE_LUT_INTERPOLATE |
> +   DRM_MODE_LUT_REUSE_LAST |
> +   DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 1 << 24, .end = 3 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> + /* Segment 4 */
> + {
> + .flags = (DRM_MODE_LUT_GAMMA |
> +   DRM_MODE_LUT_REFLECT_NEGATIVE |
> +   DRM_MODE_LUT_INTERPOLATE |
> +   DRM_MODE_LUT_REUSE_LAST |
> +   DRM_MODE_LUT_NON_DECREASING),
> + .count = 1,
> + .input_bpc = 24, .output_bpc = 16,
> + .start = 3 << 24, .end = 7 << 24,
> + .min = 0, .max = (1 << 27) - 1,
> + },
> +};
> +
>  void intel_color_init(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/9] Enhance pipe color support for multi segmented luts

[Harry Wentland]

On 2021-06-07 2:01 p.m., Shankar, Uma wrote:
> 
> 
>> -Original Message-----
>> From: Harry Wentland 
>> Sent: Saturday, June 5, 2021 12:21 AM
>> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; 
>> dri-
>> de...@lists.freedesktop.org
>> Cc: Modem, Bhanuprakash ; Cyr, Aric
>> 
>> Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
>>
>> On 2021-06-01 6:41 a.m., Uma Shankar wrote:
>>> Modern hardwares have multi segmented lut approach to prioritize the
>>> darker regions of the spectrum. This series introduces a new UAPI to
>>> define the lut ranges supported by the respective hardware.
>>>
>>> This also enables Pipe Color Management Support for Intel's XE_LPD hw.
>>> Enable Support for Pipe Degamma with the increased lut samples
>>> supported by hardware. This also adds support for newly introduced
>>> Logarithmic Gamma for XE_LPD. Also added the gamma readout support.
>>>
>>> The Logarithmic gamma implementation on XE_LPD is non linear and adds
>>> 25 segments with non linear lut samples in each segment. The
>>> expectation is userspace will create the luts as per this distribution
>>> and pass the final samples to driver to be programmed in hardware.
>>>
>>
>> Is this design targetting Intel XE_LPD HW in particular or is it intended to 
>> be generic?
>>
>> If this is intended to be generic I think it would benefit from a lot more
>> documentation. At this point it's difficult for me to see how to adapt this 
>> to AMD
>> HW. It would take me a while to be comfortable to make a call on whether we 
>> can
>> use it or not. And what about other vendors?
> 
> This is expected to be generic for all vendors.  XE_LPD is just a reference 
> implementation.
> It's basically an extension of what we have for crtc color but designing the 
> UAPI to have it
> more scalable for future hardware. The legacy hardware implementation which 
> we have in
> crtc properties can easily fit in this new UAPI and this can help represent 
> hardware better
> with more precision and scalability. Credits to Ville as to this is his idea 
> of how we can represent
> hardware generically and advertise to userspace.
> 
> Sure, I will add more documentation to make this clearer. 
> 
>> I think we need to be cautious in directly exposing HW functionality through 
>> UAPI.
>> The CM parts of AMD HW seem to be changing in some way each generation and it
>> looks like the same is true for Intel. The trouble we have with adapting the 
>> old
>> gamma/degamma properties to modern HW is some indication to me that this
>> approach is somewhat problematic.
>>
> 
> The advantage of having flexibility in userspace is that we give access of 
> hardware to
> userspace.It can then control things based on various usecases and not 
> limited by just
> a subset of operations what we define (in the lack of such an implementation).
> 
>> It would be useful to understand and document the specific use-cases we want 
>> to
>> provide to userspace implementers with this functionality. Do we want to 
>> support
>> modern transfer functions such as PQ or HLG? If so, it might be beneficial 
>> to have an
>> API to explicitly specify that, and then use LUT tables in drivers that are 
>> optimized for
>> the implementing HW. Or is the use case tone mapping? If so, would a 
>> parametric
>> definition of tone mapping be easier to manage?
>>
> 
> Yes right, ideally this is what intend to achieve here. We cant have fixed 
> tables for operations
> like Tone mapping as it will depend on mastering luminance values which can 
> vary along with
> other attributes of metadata. Eventually this operation would be done by the 
> gamma block
> (non linear luts), the values for which would be calculated and send by 
> userspace. Thus making
> all this very generic. Also we can't do any color math in driver as it has 
> lot of floating operations.
> 
> So here the trade-off is between having a UAPI where userspace controls hw, 
> computes and sends
> values vs having just a fixed function operations with hard coded lut tables 
> in driver.
> 
> Maybe we can have both the options in order to give flexibility to hardware 
> vendors. We can
> document the usage of the UAPI we create which can help things co-exist. 
> Userspace can query
> the supported properties and implement based on the properties exposed by the 
> respective
> vendor driver implementation. 
> 
> My personal preference would be to go with generic option (expose hardw

Re: [Intel-gfx] [PATCH 0/9] Enhance pipe color support for multi segmented luts

[Harry Wentland]

On 2021-06-01 6:41 a.m., Uma Shankar wrote:
> Modern hardwares have multi segmented lut approach to prioritize
> the darker regions of the spectrum. This series introduces a new
> UAPI to define the lut ranges supported by the respective hardware.
> 
> This also enables Pipe Color Management Support for Intel's XE_LPD hw.
> Enable Support for Pipe Degamma with the increased lut samples
> supported by hardware. This also adds support for newly introduced
> Logarithmic Gamma for XE_LPD. Also added the gamma readout support.
> 
> The Logarithmic gamma implementation on XE_LPD is non linear and adds 25
> segments with non linear lut samples in each segment. The expectation
> is userspace will create the luts as per this distribution and pass
> the final samples to driver to be programmed in hardware.
> 

Is this design targetting Intel XE_LPD HW in particular or is it intended
to be generic?

If this is intended to be generic I think it would benefit from a lot more
documentation. At this point it's difficult for me to see how to adapt this
to AMD HW. It would take me a while to be comfortable to make a call on whether
we can use it or not. And what about other vendors?

I think we need to be cautious in directly exposing HW functionality through
UAPI. The CM parts of AMD HW seem to be changing in some way each generation
and it looks like the same is true for Intel. The trouble we have with adapting
the old gamma/degamma properties to modern HW is some indication to me that
this approach is somewhat problematic.

It would be useful to understand and document the specific use-cases we want to
provide to userspace implementers with this functionality. Do we want to support
modern transfer functions such as PQ or HLG? If so, it might be beneficial to
have an API to explicitly specify that, and then use LUT tables in drivers that
are optimized for the implementing HW. Or is the use case tone mapping? If so,
would a parametric definition of tone mapping be easier to manage?

> +-+--+
> | x   |  2 pow x segment|No of Entries
> | |  0  | 1  |
> | 0   |  1  | 1  |
> | 1   |  2  | 2  |
> | 2   |  4  | 2  |
> | 3   |  8  | 2  |
> | 4   |  16 | 2  |
> | 5   |  32 | 4  |
> | 6   |  64 | 4  |
> | 7   |  128| 4  |
> | 8   |  256| 8  |
> | 9   |  512| 8  |
> | 10  |  1024   | 8  |
> | 11  |  2048   | 16 |
> | 12  |  4096   | 16 |
> | 13  |  8192   | 16 |
> | 14  |  16384  | 32 |
> | 15  |  32768  | 32 |
> | 16  |  65536  | 64 |
> | 17  |  131072 | 64 |
> | 18  |  262144 | 64 |
> | 19  |  524288 | 32 |
> | 20  |  1048576| 32 |
> | 21  |  2097152| 32 |
> | 22  |  4194304| 32 |
> | 23  |  8388608| 32 |
> | 24  |  16777216   | 1  |
> | | Total Entries   | 511|
>  -+-++
> 
> Credits: Special mention and credits to Ville Syrjala for coming up
> with a design for this feature and inputs. This series is based on
> his original design.
> 
> Note: Userspace support for this new UAPI will be done on Chrome and
> plan is to get this supported on mutter as well. We will notify the
> list once we have that ready for review.
> 

Is this an RFC? If so it would be good to mark it as such.

Harry

> Uma Shankar (9):
>   drm: Add gamma mode property
>   drm/i915/xelpd: Define color lut range structure
>   drm/i915/xelpd: Add support for Logarithmic gamma mode
>   drm/i915/xelpd: Attach gamma mode property
>   drm: Add Client Cap for advance gamma mode
>   drm/i915/xelpd: logarithmic gamma enabled only with advance gamma mode
>   drm/i915/xelpd: Enable Pipe Degamma
>   drm/i915/xelpd: Add Pipe Color Lut caps to platform config
>   drm/i915/xelpd: Enable XE_LPD Gamma Lut readout
> 
>  drivers/gpu/drm/drm_atomic_uapi.c  |   8 +
>  drivers/gpu/drm/drm_color_mgmt.c   |  75 
>  drivers/gpu/drm/drm_ioctl.c|   5 +
>  drivers/gpu/drm/i915/display/intel_color.c | 454 -
>  drivers/gpu/drm/i915/i915_pci.c|   3 +-
>  drivers/gpu/drm/i915/i915_reg.h|   7 +
>  include/drm/drm_atomic.h   |   1 +
>  include/drm/drm_color_mgmt.h   |   8 +
>  include/drm/drm_crtc.h |  25 ++
>  include/drm/drm_file.h |   8 +
>  include/uapi/drm/drm.h |   8 +
>  include/uapi/drm/drm_mode.h|  43 ++
>  12 files changed, 630 insertions(+), 15 deletions(-)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 02/21] drm: Add Plane Degamma Mode property

[Harry Wentland]

On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
> 
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Getting
> the blob id in userspace, user can get the mode supported and
> also the range of gamma mode supported with number of lut
> coefficients. It can then set one of the modes using this
> enum property.
> 
> Lut values will be sent through separate GAMMA_LUT blob property.
> 
> Signed-off-by: Uma Shankar 
> ---
>  Documentation/gpu/drm-kms.rst | 90 ++
>  drivers/gpu/drm/drm_atomic.c  |  1 +
>  drivers/gpu/drm/drm_atomic_state_helper.c |  2 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  4 +
>  drivers/gpu/drm/drm_color_mgmt.c  | 93 ++-
>  include/drm/drm_mode_object.h |  2 +-
>  include/drm/drm_plane.h   | 23 ++
>  7 files changed, 212 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..752be545e7d7 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -514,9 +514,99 @@ Damage Tracking Properties
>  Color Management Properties
>  ---
>  
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> +   :alt: Display Color Pipeline
> +   :caption: Display Color Pipeline Overview
> +
> +   digraph "KMS" {
> +  node [shape=box]
> +
> +  subgraph cluster_static {
> +  style=dashed
> +  label="Display Color Hardware Blocks"
> +
> +  node [bgcolor=grey style=filled]
> +  "Plane Degamma A" -> "Plane CSC/CTM A"
> +  "Plane CSC/CTM A" -> "Plane Gamma A"
> +  "Pipe Blender" [color=lightblue,style=filled, width=5.25, 
> height=0.75];
> +  "Plane Gamma A" -> "Pipe Blender"
> +   "Pipe Blender" -> "Pipe DeGamma"
> +  "Pipe DeGamma" -> "Pipe CSC/CTM"
> +  "Pipe CSC/CTM" -> "Pipe Gamma"
> +  "Pipe Gamma" -> "Pipe Output"
> +  }
> +

It might be worthwhile to also highlight the YCbCr coefficient matrix in the 
pipeline,
between the FB and Plane degamma, i.e.
  YCbCr coefficients > plane degamma > csc > ...

One problem with this view is that not all HW will support all (or any) of these
CM blocks on all planes. For example, on AMD HW cursors are very different from
other planes and don't really have full CM support.

> +  subgraph cluster_static {
> +  style=dashed
> +
> +  node [shape=box]
> +  "Plane Degamma B" -> "Plane CSC/CTM B"
> +  "Plane CSC/CTM B" -> "Plane Gamma B"
> +  "Plane Gamma B" -> "Pipe Blender"
> +  }
> +
> +  subgraph cluster_static {
> +  style=dashed
> +
> +  node [shape=box]
> +  "Plane Degamma C" -> "Plane CSC/CTM C"
> +  "Plane CSC/CTM C" -> "Plane Gamma C"
> +  "Plane Gamma C" -> "Pipe Blender"
> +  }
> +
> +  subgraph cluster_fb {
> +  style=dashed
> +  label="RAM"
> +
> +  node [shape=box width=1.7 height=0.2]
> +
> +  "FB 1" -> "Plane Degamma A"
> +  "FB 2" -> "Plane Degamma B"
> +  "FB 3" -> "Plane Degamma C"
> +  }
> +   }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +

This would mean you're blending in gamma space which is likely not what
most compositors expect. There are numerous articles that describe why
blending in gamma space is problematic, such as [1]

[1] https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html

To blend in linear space this should be configured to do

  Plane Degamma > Plane CTM > CRTC Gamma

I think it would also be good if we moved away from calling this gamma. It's
really only gamma for legacy SDR scenarios. For HDR cases I would never expect
these to use gamma and even though the sRGB transfer function is based on gamma
functions it's complicated [2].

[2] https://en.wikipedia.org/wiki/SRGB

A better way to describe these would be as "transfer function" and "inverse
transfer function." The space at various stages could then be described as 
linear
or non-linear, specifically PQ, HLG, sRGB, BT709, or using another transfer
function.

Harry

> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware 

Re: [Intel-gfx] [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes

[Harry Wentland]

On 2021-06-02 4:26 p.m., Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Wednesday, June 2, 2021 3:04 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
>> Bhanuprakash 
>> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
>> attributes
>>
>> On Tue,  1 Jun 2021 16:21:58 +0530
>> Uma Shankar  wrote:
>>
>>> Existing LUT precision structure is having only 16 bit precision. This
>>> is not enough for upcoming enhanced hardwares and advance usecases
>>> like HDR processing. Hence added a new structure with 32 bit precision
>>> values.
>>>
>>> This also defines a new structure to define color lut ranges, along
>>> with related macro definitions and enums. This will help describe
>>> multi segmented lut ranges in the hardware.
>>>
>>> Signed-off-by: Uma Shankar 
>>> ---
>>>  include/uapi/drm/drm_mode.h | 58
>>> +
>>>  1 file changed, 58 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 9b6722d45f36..d0ce48d2e732 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -819,6 +819,64 @@ struct hdr_output_metadata {
>>> };
>>>  };
>>>
>>> +/*
>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
>> the LUT
>>> + * can be used for either purpose, but not simultaneously. To expose
>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>> + * must declare distinct DRM_MODE_LUT_GAMMA and
>> DRM_MODE_LUT_DEGAMMA
>>> + * ranges.
>>> + */
>>> +/* LUT is for gamma (after CTM) */
>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>> +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
>>> +BIT(1)
>>> +/* linearly interpolate between the points */ #define
>>> +DRM_MODE_LUT_INTERPOLATE BIT(2)
>>> +/*
>>> + * the last value of the previous range is the
>>> + * first value of the current range.
>>> + */
>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>> +/* the curve must be non-decreasing */ #define
>>> +DRM_MODE_LUT_NON_DECREASING BIT(4)
>>> +/* the curve is reflected across origin for negative inputs */
>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>> +/* the same curve (red) is used for blue and green channels as well
>>> +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>> +
>>> +struct drm_color_lut_range {
>>> +   /* DRM_MODE_LUT_* */
>>> +   __u32 flags;
>>> +   /* number of points on the curve */
>>> +   __u16 count;
>>> +   /* input/output bits per component */
>>> +   __u8 input_bpc, output_bpc;
>>> +   /* input start/end values */
>>> +   __s32 start, end;
>>> +   /* output min/max values */
>>> +   __s32 min, max;
>>> +};
>>> +
>>> +enum lut_type {
>>
>> Unprefixed type name in UAPI headers is probably not a good idea.
> 
> Ok, will rename these.
> 
>>> +   LUT_TYPE_DEGAMMA = 0,
>>> +   LUT_TYPE_GAMMA = 1,
>>> +};
>>
>> All the above stuff seems to be the same in your other patch series'
>> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series replacing 
>> the
>> series "[PATCH 0/9] Enhance pipe color support for multi segmented luts" or 
>> what
>> does this mean?
> 
> The concept and idea is similar and the range definition is also common. But 
> this series
> focuses on plane color management while the other one is for pipe/crtc color 
> features.
> Hence separated and floated them as unique series for review.
> 

Might be better in this case to combine both patchsets. It wasn't entirely 
clear to
me whether I could base one patchset on top of the other (doesn't look like it) 
and
what base to apply them on. I had success applying the plane stuff on drm-next 
and
the crtc stuff on drm-intel.

Harry

> Regards,
> Uma Shankar
>>
>> Thanks,
>> pq
>>
>>> +
>>> +/*
>>> + * Creating 64 bit palette entries for better data
>>> + * precision. This will be required for HDR and
>>> + * similar color processing usecases.
>>> + */
>>> +struct drm_color_lut_ext {
>>> +   /*
>>> +* Data is U32.32 fixed point format.
>>> +*/
>>> +   __u64 red;
>>> +   __u64 green;
>>> +   __u64 blue;
>>> +   __u64 reserved;
>>> +};
>>> +
>>>  #define DRM_MODE_PAGE_FLIP_EVENT 0x01  #define
>>> DRM_MODE_PAGE_FLIP_ASYNC 0x02  #define
>>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features

[Harry Wentland]

On 2021-06-02 4:22 p.m., Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Pekka Paalanen 
>> Sent: Wednesday, June 2, 2021 2:59 PM
>> To: Shankar, Uma 
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
>> Bhanuprakash ; Harry Wentland
>> 
>> Subject: Re: [PATCH 00/21] Add Support for Plane Color Lut and CSC features
>>
>> On Tue,  1 Jun 2021 16:21:57 +0530
>> Uma Shankar  wrote:
>>
>>> This is how a typical display color hardware pipeline looks like:
>>>  +---+
>>>  |RAM|
>>>  |  +--++-++-+   |
>>>  |  | FB 1 ||  FB 2   || FB N|   |
>>>  |  +--++-++-+   |
>>>  +---+
>>>|  Plane Color Hardware Block |
>>> ++
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | DeGamma |   | Degamma   |   | Degamma  | |
>>>  | +---+-+   +---+---+   +---+--+ |
>>>  | | |   ||
>>>  | +---v-+   +---v---+   +---v--+ |
>>>  | |Plane A  |   | Plane B   |   | Plane N  | |
>>>  | |CSC/CTM  |   | CSC/CTM   |   | CSC/CTM  | |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  | +---v-+   +v--+   +v-+ |
>>>  | | Plane A |   | Plane B   |   | Plane N  | |
>>>  | | Gamma   |   | Gamma |   | Gamma| |
>>>  | +---+-+   ++--+   ++-+ |
>>>  | |  |   |   |
>>>  ++
>>> +--v--v---v---|
>>> ||   ||
>>> ||   Pipe Blender||
>>> +++
>>> |||
>>> |+---v--+ |
>>> ||  Pipe DeGamma| |
>>> ||  | |
>>> |+---+--+ |
>>> ||Pipe Color  |
>>> |+---v--+ Hardware|
>>> ||  Pipe CSC/CTM| |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> |+---v--+ |
>>> ||  Pipe Gamma  | |
>>> ||  | |
>>> |+---+--+ |
>>> |||
>>> +-+
>>>  |
>>>  v
>>>Pipe Output
>>
>> Hi,
>>
>> this is an excellent picture. I have long been wanting schematics like that 
>> in the DRM
>> UAPI documentation. Another note on that:
>> https://lists.freedesktop.org/archives/dri-devel/2021-May/307310.html>>>
>> But the schematic for DRM UAPI documentation needs to be written in terms of 
>> the
>> abstract KMS pipeline with property names spelled out, like in what Ville 
>> sketched in
>> that email.
> 
> Sure Pekka, I can add that.
> 
>>> This patch series adds properties for plane color features. It adds
>>> properties for degamma used to linearize data and CSC used for gamut
>>> conversion. It also includes Gamma support used to again non-linearize
>>> data as per panel supported color space. These can be utilize by user
>>> space to convert planes from one format to another, one color space to
>>> another etc.
>>
>> This is very much welcome!
>>
>> There is also the thread:
>> https://lists.freedesktop.org/archives/dri-devel/2021-May/306726.html>>>
>> Everything mentioned will interact with each other by changing what the 
>> abstract
>> KMS pixel pipeline does. I think you and Harry should probably look at each 
>> others'
>> suggestions and see how to fit them all into a single abstract KMS pipeline.
>>
>> People are adding new pieces into KMS left and right, and I fear we lose 
>> sig

Re: [Intel-gfx] [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

[Harry Wentland]

On 2021-03-19 8:49 a.m., Maxime Ripard wrote:

All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.

All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.

Signed-off-by: Maxime Ripard 


Patches 1 & 2 are
Reviewed-by: Harry Wentland 

Harry


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +--
  drivers/gpu/drm/drm_connector.c   | 28 +++
  drivers/gpu/drm/i915/display/intel_atomic.c   | 13 +
  include/drm/drm_connector.h   |  2 ++
  5 files changed, 33 insertions(+), 48 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 06908a3cee0f..4eb5201e566a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5924,25 +5924,6 @@ static int fill_hdr_info_packet(const struct 
drm_connector_state *state,
return 0;
  }
  
-static bool

-is_hdr_metadata_different(const struct drm_connector_state *old_state,
- const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (old_blob != new_blob) {
-   if (old_blob && new_blob &&
-   old_blob->length == new_blob->length)
-   return memcmp(old_blob->data, new_blob->data,
- old_blob->length);
-
-   return true;
-   }
-
-   return false;
-}
-
  static int
  amdgpu_dm_connector_atomic_check(struct drm_connector *conn,
 struct drm_atomic_state *state)
@@ -5960,7 +5941,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
if (!crtc)
return 0;
  
-	if (is_hdr_metadata_different(old_con_state, new_con_state)) {

+   if (!drm_connector_atomic_hdr_metadata_equal(old_con_state, 
new_con_state)) {
struct dc_info_packet hdr_infopacket;
  
  		ret = fill_hdr_info_packet(new_con_state, _infopacket);

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f24bbb840dbf..f871e33c2fc9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2395,21 +2395,6 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return ret;
  }
  
-static bool hdr_metadata_equal(const struct drm_connector_state *old_state,

-  const struct drm_connector_state *new_state)
-{
-   struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
-   struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
-
-   if (!old_blob || !new_blob)
-   return old_blob == new_blob;
-
-   if (old_blob->length != new_blob->length)
-   return false;
-
-   return !memcmp(old_blob->data, new_blob->data, old_blob->length);
-}
-
  static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
  struct drm_atomic_state *state)
  {
@@ -2423,7 +2408,7 @@ static int dw_hdmi_connector_atomic_check(struct 
drm_connector *connector,
if (!crtc)
return 0;
  
-	if (!hdr_metadata_equal(old_state, new_state)) {

+   if (!drm_connector_atomic_hdr_metadata_equal(old_state, new_state)) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e25248e23e18..d781a3a1e9bf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2170,6 +2170,34 @@ int 
drm_connector_attach_hdr_output_metadata_property(struct drm_connector *conn
  }
  EXPORT_SYMBOL(drm_connector_attach_hdr_output_metadata_property);
  
+/**

+ * drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
+ * @old_state: old connector state to compare
+ * @new_state: new connector state to compare
+ *
+ * This is used by HDR-enabled drivers to test whether the HDR metadata
+ * have changed between two different connector state (and thus probably
+ * requires a full blown mode change).
+ *
+ * Returns:
+ * True if the metadata are equal, False otherwise
+ */
+bool drm_connector_atomic_hdr_metadata_equal(struct drm_connector_state 
*old_state,
+struct drm_connector_state 
*new_state)
+{
+   struc

Re: [Intel-gfx] 2021 X.Org Foundation Election Candidates

[Harry Wentland]

Correction, we have 7 candidates for 4 positions.

I seem to have overlooked Walter Harms's nomination email. My sincerest 
apologies. His personal affiliation, statement of contribution, and 
personal statement are below.


The full slate of candidates can be found at 
https://wiki.freedesktop.org/xorg/BoardOfDirectors/Elections/2021/



## Walter Harms
__Current Affiliation:__ Scientist @ Bundesamt für Strahlenschutz

__Statement of Contribution:__

I am involved into the open source since studying physics several
years ago. I am also certified trainer for programmers.
I contributed in the last years to projects like linux kernel,
man pages, etc. Since a few years i have commit rights for X11 and
did some work on libX11 and libXt.

__Personal Statement:__

Since i started to become a trainer i have a predilection for documentation.
Xorg has a lot good documentation but today is it less. NTL what is
important is the application. I would like to see more training
material and more X11 applications especially for remote access.
But i was never involved in the xorg organisation. So i see myself more
as an apprentice. We will see if i can help.


Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

On 2021-03-15 2:47 p.m., Harry Wentland wrote:

To all X.Org Foundation Members:

The election for the X.Org Foundation Board of Directors will begin on 
22 March 2021. We have 6 candidates who are running for 4 seats. They 
are (in alphabetical order):


     Samuel Iglesias Gonsálvez
     Manasi Navare
     Lyude Paul
     Rodrigo Siqueira
     Lucas Stach
     Daniel Vetter

Attached below are the Personal Statements each candidate submitted for 
your consideration along with their Statements of Contribution that they 
submitted with the membership application. Please review each of the 
candidates' statements to help you decide whom to vote for during the 
upcoming election.


If you have questions of the candidates, you should feel free to ask 
them here on the mailing list.


The election committee will provide detailed instructions on how the 
voting system will work when the voting period begins.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Deadline of X.Org membership application or renewal: Thu 18th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

** Nominees **

## Samuel Iglesias Gonsálvez

__Current Affiliation:__ Igalia

__Personal Statement:__

I have been contributing to Mesa and piglit for 7 years improving
open-source drivers for both OpenGL and Vulkan.

During my time on the board, I have become the XDC organization
coordinator and the XDC CFP committee chair, due to my experience
organizing the XDC 2018 in A Coruña, Spain.

Thanks to these experiences, I have been deeply involved in the XDC
organization process, where I have helped make a great and welcoming
conference every year.

If I am elected, I plan to continue leading both the XDC organization
process and the XDC CFP committee.


## Manasi Navare

__Current Affiliation:__ Intel

__Statement of contribution:__

I am a lead contributor to Intel’s Open source graphics kernel driver 
i915 as well as to the Linux Kernel DRM subsystem. One of my most widely 
used contributions is the Display Port Compliance code in i915, DRM as 
well as in Xserver and IGT to make the entire graphics stack Display 
Port compliant and reward the end users with black screen free displays. 
  I have also enabled features like Display stream compression across 
DRM and i915 as per VESA’s DSC specification for Display Port. Most 
recently I have been working with both the DRM and i915 community as 
well as the AMD developers to implement and enable adaptive sync feature 
for variable refresh rate on display drivers for enhanced gaming 
experience. I also have commit rights to several upstream projects like 
drm-intel, drm-misc and Intel GPU Tools.


I have served on X.org board of directors for last 2 years organizing 
XDC conferences, being on Code of Conduct committee for X.org and 
Freedesktop and taking over the treasurer responsibility since September 
2020.


__Personal Statement:__

I have been a Linux Open Source contributor for last 7 years since I 
joined Intel's Open source technology center. My major contributions are 
in enabling display interfaces and develop display features in upcoming 
display specifications in i915 and Linux DRM subsystem. I have presented 
several talks at Linux Graphics conferences like Embedded Linux 
Conference, XDC and FOSDEM on several graphics display features like 
Display Port compliance and Display Stream Compression, Tiled display 
support, Adaptive 

[Intel-gfx] 2021 X.Org Foundation Election Candidates

[Harry Wentland]

To all X.Org Foundation Members:

The election for the X.Org Foundation Board of Directors will begin on 
22 March 2021. We have 6 candidates who are running for 4 seats. They 
are (in alphabetical order):


Samuel Iglesias Gonsálvez
Manasi Navare
Lyude Paul
Rodrigo Siqueira
Lucas Stach
Daniel Vetter

Attached below are the Personal Statements each candidate submitted for 
your consideration along with their Statements of Contribution that they 
submitted with the membership application. Please review each of the 
candidates' statements to help you decide whom to vote for during the 
upcoming election.


If you have questions of the candidates, you should feel free to ask 
them here on the mailing list.


The election committee will provide detailed instructions on how the 
voting system will work when the voting period begins.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Deadline of X.Org membership application or renewal: Thu 18th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

** Nominees **

## Samuel Iglesias Gonsálvez

__Current Affiliation:__ Igalia

__Personal Statement:__

I have been contributing to Mesa and piglit for 7 years improving
open-source drivers for both OpenGL and Vulkan.

During my time on the board, I have become the XDC organization
coordinator and the XDC CFP committee chair, due to my experience
organizing the XDC 2018 in A Coruña, Spain.

Thanks to these experiences, I have been deeply involved in the XDC
organization process, where I have helped make a great and welcoming
conference every year.

If I am elected, I plan to continue leading both the XDC organization
process and the XDC CFP committee.


## Manasi Navare

__Current Affiliation:__ Intel

__Statement of contribution:__

I am a lead contributor to Intel’s Open source graphics kernel driver 
i915 as well as to the Linux Kernel DRM subsystem. One of my most widely 
used contributions is the Display Port Compliance code in i915, DRM as 
well as in Xserver and IGT to make the entire graphics stack Display 
Port compliant and reward the end users with black screen free displays. 
 I have also enabled features like Display stream compression across 
DRM and i915 as per VESA’s DSC specification for Display Port. Most 
recently I have been working with both the DRM and i915 community as 
well as the AMD developers to implement and enable adaptive sync feature 
for variable refresh rate on display drivers for enhanced gaming 
experience. I also have commit rights to several upstream projects like 
drm-intel, drm-misc and Intel GPU Tools.


I have served on X.org board of directors for last 2 years organizing 
XDC conferences, being on Code of Conduct committee for X.org and 
Freedesktop and taking over the treasurer responsibility since September 
2020.


__Personal Statement:__

I have been a Linux Open Source contributor for last 7 years since I 
joined Intel's Open source technology center. My major contributions are 
in enabling display interfaces and develop display features in upcoming 
display specifications in i915 and Linux DRM subsystem. I have presented 
several talks at Linux Graphics conferences like Embedded Linux 
Conference, XDC and FOSDEM on several graphics display features like 
Display Port compliance and Display Stream Compression, Tiled display 
support, Adaptive Sync or Variable Refresh rate kernel support for 
gaming and I have been already actively involved in IRC discussions with 
DRM and i915 maintainers to constantly provide any solution on display 
port questions and work on improving the kernel documentation and code 
quality.


I have served on the X.org board of directors since 2019 helping in XDC 
2019 and XDC 2020 organization and for ensuring the Code of Conduct on 
the X.org community and during XDC events. I have previously mentored 
for the KMS project in Outreachy 2018 winter program as well as 
administered the Google summer of code 2019 program and will continue to 
do so whenever I get an opportunity. I joined the Code of Conduct 
Freedesktop committee as well to ensure it is followed on all the 
Freedesktop projects and open source channels. I have recently stepped 
up to take over the treasurer responsibility as part of the X.org board 
and working with all our sponsors to get the invoicing for the X.org 
events.


If I get elected I would like to continue being a treasurer managing the 
XDC sponsorship and invoicing responsibilities as well as continue 
serving on the Code of conduct committee for X.org and Freedesktop. In 
addition to this I would like to help out on XDC event website 
organiza

[Intel-gfx] 2021 X.Org Foundation Membership renewal period extended to Mar 18

[Harry Wentland]

Due to some hickups with some of the early election emails and the large 
spike in membership registrations the elections committee decided to 
extend the membership deadline by one week to Mar 18, 2021.


If you have not renewed your membership please do so by Thursday, Mar 18 
at https://members.x.org.


The nominated candidates will be announced on Sunday, allowing for a 
week of Candidate QA before the start of election on Mon Mar 22.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Deadline of X.Org membership application or renewal: Thu 18th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

 * Eric Anholt
 * Mark Filion
 * Keith Packard
 * Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11

[Harry Wentland]

The nomination period for the 2021 X.Org Foundation Board of Directors 
Election closed yesterday and the election is rapidly approaching. We 
currently only see membership renewals for 59 people.


If you have not renewed your membership please do so by Thursday, Mar 11 
at https://members.x.org.


The nominated candidates will be announced a week from yesterday.

There were some hickups with our earlier emails and we realize some of 
you may have not received them. To ensure you receive this email we're 
BCCing any member that has been registered as a member in the last 2 years.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

 * Eric Anholt
 * Mark Filion
 * Keith Packard
 * Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 2021 X.Org Board of Directions Nomination period ends next Sunday

[Harry Wentland]

Unfortunately my previous email seems to not have been received by many 
people. I will send this email separately to each mailing list to 
hopefully get better coverage.


The nomination period is currently ongoing. So far we have received 3 
nominations and will need at least 4 to fill the vacant spots on the 
board. We hope you will consider putting your nomination forward.


To nominate yourself or someone else please send the nomination, along 
with a personal statement to elections at x dot org.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Cheers,
Harry Wentland,
on behalf of the X.Org elections committee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 2021 X.Org Board of Directors Elections Nomination period is NOW

[Harry Wentland]

We are seeking nominations for candidates for election to the X.Org 
Foundation Board of Directors. All X.Org Foundation members are eligible 
for election to the board.


Nominations for the 2021 election are now open and will remain open 
until Sunday, the 7th of March.


The Board consists of directors elected from the membership. Each year, 
an election is held to bring the total number of directors to eight. The 
four members receiving the highest vote totals will serve as directors 
for two year terms.


The directors who received two year terms starting in 2020 were Eric 
Anholt, Mark Filion, Keith Packard, and Harry Wentland. They will 
continue to serve until their term ends in 2022. Current directors whose 
term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, 
Lyude Paul, and Daniel Vetter.


A director is expected to participate in the fortnightly IRC meeting to 
discuss current business and to attend the annual meeting of the X.Org 
Foundation, which will be held at a location determined in advance by 
the Board of Directors.


A member may nominate themselves or any other member they feel is 
qualified. Nominations should be sent to the Election Committee at 
elections at x.org.


Nominees shall be required to be current members of the X.Org 
Foundation, and submit a personal statement of up to 200 words that will 
be provided to prospective voters. The collected statements, along with 
the statement of contribution to the X.Org Foundation in the member's 
account page on http://members.x.org, will be made available to all 
voters to help them make their voting decisions.


Nominations must be received before the end of day on Sunday, the 7th of 
March.


Membership applications or renewals and completed personal statements 
must be received no later than the end of day on Thursday, the 11tth of 
March.


The slate of candidates will be published on Monday, the 15th of March 
and candidate Q will begin then.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Cheers,
Harry Wentland,
on behalf of the X.Org elections committee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 2021 X.Org Foundation Membership renewal and election schedule

[Harry Wentland]

The 2021 X.Org Foundation elections are rapidly approaching. In 
preparation of the elections we would like to remind you that members 
will need to renew their membership each year in order to vote. Please 
take the time to renew your membership by logging into 
https://members.x.org and clicking on the "Apply" button to apply for 
the 2021-2022 membership.


We would also like to encourage you to start considering yourself or 
someone else for nomination to the board. We will send another email to 
start the official nomination period when it opens.


** Election Schedule **

Nomination period Start: Mon 22nd February
Nomination period End: Sun 7th March
Deadline of X.Org membership application or renewal: Thu 11th March
Publication of Candidates & start of Candidate QA: Mon 15th March
Election Planned Start: Mon 22nd March anywhere on earth
Election Planned End: Sun 4th April anywhere on earth

** Election Committee **

* Eric Anholt
* Mark Filion
* Keith Packard
* Harry Wentland

Thanks,
Harry Wentland,
on behalf of the X.Org elections committee

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/amdgpu: Use __drm_atomic_helper_crtc_reset

[Harry Wentland]

On 2020-06-12 12:00 p.m., Daniel Vetter wrote:
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Alex Deucher 
> Cc: Nicholas Kazlauskas 
> Cc: Harry Wentland 
> Cc: Rodrigo Siqueira 
> Cc: Bhawanpreet Lakha 
> Cc: Roman Li 
> Cc: Mikita Lipski 
> Cc: Stylon Wang 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
>  1 file changed, 1 insertion(+), 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 68a73065b516..36d605a6eb16 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4594,9 +4594,7 @@ static void dm_crtc_reset_state(struct drm_crtc *crtc)
>   if (WARN_ON(!state))
>   return;
>  
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> -
> + __drm_atomic_helper_crtc_reset(crtc, >base);
>  }
>  
>  static struct drm_crtc_state *
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm: Create a drm_connector_helper_funcs hook for Adaptive Sync support

[Harry Wentland]

On 2020-03-18 2:35 a.m., Manasi Navare wrote:
> This patch adds a hook in drm_connector_helper_funcs to get the
> support of the driver for adaptive sync functionality.
> 
> This can be called in the connector probe helper function after
> the connector detect() and get_modes() hooks to also
> query the adaptive sync support of the driver.
> 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Nicholas Kazlauskas 
> Signed-off-by: Manasi Navare 

Patches 1 and 2 are
Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_probe_helper.c   |  4 
>  include/drm/drm_modeset_helper_vtables.h | 16 
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 576b4b7dcd89..4403817bfb02 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -482,6 +482,10 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>  
>   count = (*connector_funcs->get_modes)(connector);
>  
> + /* Get the Adaptive Sync Support if helper exists */
> + if (*connector_funcs->get_adaptive_sync_support)
> + (**connector_funcs->get_adaptive_sync_support)(connector);
> +
>   /*
>* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
>* override/firmware EDID.
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 7c20b1c8b6a7..0b203fdd25df 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1079,6 +1079,22 @@ struct drm_connector_helper_funcs {
>struct drm_writeback_job *job);
>   void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
> struct drm_writeback_job *job);
> +
> + /**
> +  * @get_adaptive_sync_support:
> +  *
> +  * This hook is used by the probe helper to get the driver's support
> +  * for adaptive sync or variable refresh rate.
> +  * This is called from drm_helper_probe_single_connector_modes()
> +  * This is called after the @get_modes hook so that the connector modes
> +  * are already obtained and EDID is parsed to obtain the monitor
> +  * range descriptor information.
> +  *
> +  * This hook is optional and defined only for the drivers and on
> +  * connectors that advertise adaptive sync support.
> +  *
> +  */
> + void (*get_adaptive_sync_support)(struct drm_connector *connector);
>  };
>  
>  /**
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V6] drm: Add support for DP 1.4 Compliance edid corruption test

[Harry Wentland]

On 2020-02-05 10:22 a.m., Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC calculates routine adds the last CRC byte,
> and check if non-zero.
> 
> This behavior is not accurate; actually, we need to return
> the actual CRC value when corruption is detected.
> This commit changes this issue by returning the calculated CRC,
> and initiate the required sequence.
> 
> Change since v6
> - Add return check
> 
> Change since v5
> - Obtain real CRC value before dumping bad edid
> 
> Change since v4
> - Fix for CI.CHECKPATCH
> 
> Change since v3
> - Fix a minor typo.
> 
> Change since v2
> - Rewrite checksum computation routine to avoid duplicated code.
> - Rename to avoid confusion.
> 
> Change since v1
> - Have separate routine for returning real CRC.
> 
> Signed-off-by: Jerry (Fangzhi) Zuo 

Please make sure to add the Reviewed-bys you've received on previous
versions. I've already reviewed v5 and an earlier one. Please add my
Reviewed-by.

Harry

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 51 +
>  drivers/gpu/drm/drm_edid.c  | 23 ---
>  include/drm/drm_connector.h |  6 
>  include/drm/drm_dp_helper.h |  3 ++
>  4 files changed, 79 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f629fc5494a4..1efd609df402 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -351,6 +351,57 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> + * drm_dp_send_real_edid_checksum() - send back real edid checksum value
> + * @aux: DisplayPort AUX channel
> + * @real_edid_checksum: real edid checksum for the last block
> + *
> + * Returns:
> + * True on success
> + */
> +bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
> + u8 real_edid_checksum)
> +{
> + u8 link_edid_read = 0, auto_test_req = 0, test_resp = 0;
> +
> + if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 
> 1) < 1) {
> + DRM_ERROR("DPCD failed read at register 0x%x\n", 
> DP_DEVICE_SERVICE_IRQ_VECTOR);
> + return false;
> + }
> + auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> + if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1) < 1) {
> + DRM_ERROR("DPCD failed read at register 0x%x\n", 
> DP_TEST_REQUEST);
> + return false;
> + }
> + link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> + if (!auto_test_req || !link_edid_read) {
> + DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
> + return false;
> + }
> +
> + if (drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, 
> _test_req, 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_DEVICE_SERVICE_IRQ_VECTOR);
> + return false;
> + }
> +
> + /* send back checksum for the last edid extension block data */
> + if (drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 
> 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_TEST_EDID_CHECKSUM);
> + return false;
> + }
> +
> + test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> + if (drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_TEST_RESPONSE);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> +
>  /**
>   * drm_dp_downstream_max_clock() - extract branch device max
>   * pixel rate for legacy VGA
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..f064e75fb4c5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1590,11 +1590,22 @@ static int validate_displayid(u8 *displayid, int 
> length, int idx);
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
>   int i;
> - u8 csum = 0;
> - for (i = 0; i < EDID_LENGTH; i++)
> + u8 csum = 0, crc = 0;
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
>   csum += raw_edid[i];
>  
> - return csum;
> + crc = 0x100 - csum;
> +
> + return crc;
> +}
> +
> +static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 
> real_checksum)
> +{
> + if (raw_edid[EDID_LENGTH - 1] != real_checksum)
> + return true;
> + else
> + return false;
>  }
>  
>  static bool drm_edid_is_zero(const u8 *in_edid, int length)
> @@ -1652,7 +1663,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>   }
>  
>   csum = drm_edid_block_checksum(raw_edid);
> - if (csum) {
> + if (drm_edid_block_checksum_diff(raw_edid, csum)) {

Re: [Intel-gfx] [PATCH V5] drm: Add support for DP 1.4 Compliance edid corruption test

[Harry Wentland]

On 2020-01-31 3:24 p.m., Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC calculates routine adds the last CRC byte,
> and check if non-zero.
> 
> This behavior is not accurate; actually, we need to return
> the actual CRC value when corruption is detected.
> This commit changes this issue by returning the calculated CRC,
> and initiate the required sequence.
> 
> Change since v5
> - Obtain real CRC value before dumping bad edid
> 
> Change since v4
> - Fix for CI.CHECKPATCH
> 
> Change since v3
> - Fix a minor typo.
> 
> Change since v2
> - Rewrite checksum computation routine to avoid duplicated code.
> - Rename to avoid confusion.
> 
> Change since v1
> - Have separate routine for returning real CRC.
> 
> Signed-off-by: Jerry (Fangzhi) Zuo 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 35 +
>  drivers/gpu/drm/drm_edid.c  | 23 ++
>  include/drm/drm_connector.h |  6 ++
>  include/drm/drm_dp_helper.h |  3 +++
>  4 files changed, 63 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f629fc5494a4..18b285fa1a42 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -351,6 +351,41 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> + * drm_dp_send_real_edid_checksum() - send back real edid checksum value
> + * @aux: DisplayPort AUX channel
> + * @real_edid_checksum: real edid checksum for the last block
> + *
> + * Returns true on success
> + */
> +bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
> +u8 real_edid_checksum)
> +{
> + u8 link_edid_read = 0, auto_test_req = 0, test_resp = 0;
> +
> + drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 1);
> + auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> + drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1);
> + link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> + if (!auto_test_req || !link_edid_read) {
> + DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
> + return false;
> + }
> +
> + drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 1);
> +
> + /* send back checksum for the last edid extension block data */
> + drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 1);
> +
> + test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> + drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1);
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> +
>  /**
>   * drm_dp_downstream_max_clock() - extract branch device max
>   * pixel rate for legacy VGA
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..f064e75fb4c5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1590,11 +1590,22 @@ static int validate_displayid(u8 *displayid, int 
> length, int idx);
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
>   int i;
> - u8 csum = 0;
> - for (i = 0; i < EDID_LENGTH; i++)
> + u8 csum = 0, crc = 0;
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
>   csum += raw_edid[i];
>  
> - return csum;
> + crc = 0x100 - csum;
> +
> + return crc;
> +}
> +
> +static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 
> real_checksum)
> +{
> + if (raw_edid[EDID_LENGTH - 1] != real_checksum)
> + return true;
> + else
> + return false;
>  }
>  
>  static bool drm_edid_is_zero(const u8 *in_edid, int length)
> @@ -1652,7 +1663,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>   }
>  
>   csum = drm_edid_block_checksum(raw_edid);
> - if (csum) {
> + if (drm_edid_block_checksum_diff(raw_edid, csum)) {
>   if (edid_corrupt)
>   *edid_corrupt = true;
>  
> @@ -1793,6 +1804,10 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  u8 *edid, int num_blocks)
>  {
>   int i;
> + u8 num_of_ext = edid[0x7e];
> +
> + /* Calculate real checksum for the last edid extension block data */
> + connector->real_edid_checksum = drm_edid_block_checksum(edid + 
> num_of_

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

[Harry Wentland]

On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher  > wrote:
>
> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> mailto:mario.kleiner...@gmail.com>>
> wrote:
> >
> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> mailto:alexdeuc...@gmail.com>> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >>  > wrote:
> >> >
> As Harry mentioned in the other thread, won't this only work if the
> display was brought up by the vbios?  In the suspend/resume case,
> won't we just fall back to 2.7Gbps?
>
> Alex
>
>
> Adding Harry to cc...
>
> The code is only executed for eDP. On the Intel side, it seems that
> intel_edp_init_dpcd() gets only called during driver load /
> modesetting init, so not on resume.
>
> On the AMD DC side, dc_link_detect_helper() has this early no-op
> return at the beginning:
>
> if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
>   link->connector_signal == SIGNAL_TYPE_EDP) &&
>   link->local_sink)
>   return true;
>
> So i guess if link->local_sink doesn't get NULL'ed during a
> suspend/resume cycle, then we never reach the setup code that would
> overwrite with non vbios settings?
>
> Sounds reasonable to me, given that eDP panels are usually fixed
> internal panels, nothing that gets hot(un-)plugged?
>
> I can't test, because suspend/resume with the Polaris gpu on the MBP
> 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> Looks like powering down the gpu works, but powering up doesn't. And
> also modesetting at vgaswitcheroo switch time is no-go, because the
> DDC/AUX lines apparently can't be switched on that Apple gmux, and
> handover of that data seems to be not implemented in current
> vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> Prime setup is quite a pita...
>

I haven't followed the entire discussion on the i915 thread but for the
amdgpu dc patch I would prefer a DPCD quirk to override the reported
link settings with the correct link rate.

Harry

> -mario
>
>

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/9] drm/dp: get/set phy compliance pattern

[Harry Wentland]

On 2019-12-30 11:05 a.m., Manna, Animesh wrote:
> On 24-12-2019 01:23, Harry Wentland wrote:
>>
>> On 2019-12-23 12:03 p.m., Animesh Manna wrote:
>>> During phy compliance auto test mode source need to read
>>> requested test pattern from sink through DPCD. After processing
>>> the request source need to set the pattern. So set/get method
>>> added in drm layer as it is DP protocol.
>>>
>>> v2: As per review feedback from Manasi on RFC version,
>>> - added dp revision as function argument in set_phy_pattern api.
>>> - used int for link_rate and u8 for lane_count to align with
>>> existing code.
>>>
>>> Signed-off-by: Animesh Manna 
>>> ---
>>>   drivers/gpu/drm/drm_dp_helper.c | 93
>>> +
>>>   include/drm/drm_dp_helper.h | 31 +++
>>>   2 files changed, 124 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 2c7870aef469..91c80973aa83 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1371,3 +1371,96 @@ int
>>> drm_dp_dsc_sink_supported_input_bpcs(const u8
>>> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
>>>   return num_bpc;
>>>   }
>>>   EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
>>> +
>>> +/**
>>> + * drm_dp_get_phy_test_pattern() - get the requested pattern from
>>> the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
>>> +    struct drm_dp_phy_test_params *data)
>>> +{
>>> +    int err;
>>> +    u8 rate, lanes;
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
>>> +    if (err < 0)
>>> +    return err;
>>> +    data->link_rate = drm_dp_bw_code_to_link_rate(rate);
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
>>> +    if (err < 0)
>>> +    return err;
>>> +    data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
>>> +
>>> +    if (lanes & DP_ENHANCED_FRAME_CAP)
>>> +    data->enahanced_frame_cap = true;
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN,
>>> >phy_pattern);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    switch (data->phy_pattern) {
>>> +    case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
>>> +    err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
>>> +   >custom80, 10);
>> Using sizeof(data->custom80) might be safer.
>>
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    break;
>>> +    case DP_PHY_TEST_PATTERN_CP2520:
>>> +    err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
>>> +   >hbr2_reset, 2);
>> Same here, using sizeof(data->hbr2_reset).
>>
>>> +    if (err < 0)
>>> +    return err;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
>>> +
>>> +/**
>>> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
>>> +    struct drm_dp_phy_test_params *data, u8 dp_rev)
>>> +{
>>> +    int err, i;
>>> +    u8 link_config[2];
>>> +    u8 test_pattern;
>>> +
>>> +    link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
>>> +    link_config[1] = data->num_lanes;
>>> +    if (data->enahanced_frame_cap)
>>> +    link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>>> +    err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    test_pattern = data->phy_pattern;
>>> +    if (dp_rev < 0x12) {
>>> +    test_pattern = (test_pattern << 2) &
>>> + 

Re: [Intel-gfx] [PATCH v3 2/9] drm/dp: get/set phy compliance pattern

[Harry Wentland]

On 2019-12-23 12:03 p.m., Animesh Manna wrote:
> During phy compliance auto test mode source need to read
> requested test pattern from sink through DPCD. After processing
> the request source need to set the pattern. So set/get method
> added in drm layer as it is DP protocol.
> 
> v2: As per review feedback from Manasi on RFC version,
> - added dp revision as function argument in set_phy_pattern api.
> - used int for link_rate and u8 for lane_count to align with existing code.
> 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 93 +
>  include/drm/drm_dp_helper.h | 31 +++
>  2 files changed, 124 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2c7870aef469..91c80973aa83 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1371,3 +1371,96 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8 
> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
>   return num_bpc;
>  }
>  EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
> +
> +/**
> + * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data)
> +{
> + int err;
> + u8 rate, lanes;
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
> + if (err < 0)
> + return err;
> + data->link_rate = drm_dp_bw_code_to_link_rate(rate);
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
> + if (err < 0)
> + return err;
> + data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
> +
> + if (lanes & DP_ENHANCED_FRAME_CAP)
> + data->enahanced_frame_cap = true;
> +
> + err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
> + if (err < 0)
> + return err;
> +
> + switch (data->phy_pattern) {
> + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
> + err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
> +>custom80, 10);

Using sizeof(data->custom80) might be safer.

> + if (err < 0)
> + return err;
> +
> + break;
> + case DP_PHY_TEST_PATTERN_CP2520:
> + err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
> +>hbr2_reset, 2);

Same here, using sizeof(data->hbr2_reset).

> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
> +
> +/**
> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data, u8 dp_rev)
> +{
> + int err, i;
> + u8 link_config[2];
> + u8 test_pattern;
> +
> + link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
> + link_config[1] = data->num_lanes;
> + if (data->enahanced_frame_cap)
> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
> + if (err < 0)
> + return err;
> +
> + test_pattern = data->phy_pattern;
> + if (dp_rev < 0x12) {
> + test_pattern = (test_pattern << 2) &
> +DP_LINK_QUAL_PATTERN_11_MASK;
> + err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
> +  test_pattern);
> + if (err < 0)
> + return err;
> + } else {
> + for (i = 0; i < data->num_lanes; i++) {
> + err = drm_dp_dpcd_writeb(aux,
> +  DP_LINK_QUAL_LANE0_SET + i,
> +  test_pattern);
> + if (err < 0)
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index d6e560870fb1..42a364748308 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -700,6 +700,15 @@
>  # define DP_TEST_COUNT_MASK  0xf
>  
>  #define DP_PHY_TEST_PATTERN 0x248
> +# define DP_PHY_TEST_PATTERN_SEL_MASK   0x7
> +# define DP_PHY_TEST_PATTERN_NONE   0x0
> +# define DP_PHY_TEST_PATTERN_D10_2  0x1
> +# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
> +# define DP_PHY_TEST_PATTERN_PRBS7 

Re: [Intel-gfx] [PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec

[Harry Wentland]

On 2019-12-23 12:03 p.m., Animesh Manna wrote:
> [Why]:
> Aligh with DP spec wanted to follow same naming convention.
> 
> [How]:
> Changed the macro name of the dpcd address used for getting requested
> test-pattern.
> 
> Cc: Harry Wentland 
> Cc: Alex Deucher 
> Signed-off-by: Animesh Manna 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>  include/drm/drm_dp_helper.h  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 42aa889fd0f5..1a6109be2fce 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct 
> dc_link *link)
>   /* get phy test pattern and pattern parameters from DP receiver */
>   core_link_read_dpcd(
>   link,
> - DP_TEST_PHY_PATTERN,
> + DP_PHY_TEST_PATTERN,
>   _test_pattern.raw,
>   sizeof(dpcd_test_pattern));
>   core_link_read_dpcd(
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8f8f3632e697..d6e560870fb1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -699,7 +699,7 @@
>  # define DP_TEST_CRC_SUPPORTED   (1 << 5)
>  # define DP_TEST_COUNT_MASK  0xf
>  
> -#define DP_TEST_PHY_PATTERN 0x248
> +#define DP_PHY_TEST_PATTERN 0x248
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_23_16  0x252
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add support for DP 1.4 Compliance edid corruption test (rev3)

[Harry Wentland]

On 2019-12-20 2:40 p.m., Zuo, Jerry wrote:
> Hi All:
> 
> I got CI check failures. Among those, hdmi-hpd-fast seems related, but I 
> am not sure why. Please take a brief review and help to determine if it is a 
> real false-positive again. 
> 

It looks like the hdmi-hpd-fast failures are listed under "Known
issues." I imagine that means we can ignore them.

But we also see these failures that are list as "Possible regressions"
and I'm not sure why our patch would've broken those:

 Possible regressions 

  * igt@gem_ctx_create@basic-files:
- fi-byt-j1900:   [PASS][1] -> [FAIL][2]
   [1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html
   [2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html

  * igt@i915_selftest@live_gt_heartbeat:
- fi-whl-u:   [PASS][3] -> [DMESG-FAIL][4]
   [3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-whl-u/igt@i915_selftest@live_gt_heartbeat.html
   [4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-whl-u/igt@i915_selftest@live_gt_heartbeat.html

Would love some input from Intel guys on this as we don't want to break
you with this patch.

Thanks,
Harry

> Thanks a lot.
> 
> Regards,
> Jerry
> 
> -Original Message-
> From: Patchwork  
> Sent: December 9, 2019 4:40 PM
> To: Zuo, Jerry 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.BAT: failure for drm: Add support for DP 1.4 Compliance edid 
> corruption test (rev3)
> 
> == Series Details ==
> 
> Series: drm: Add support for DP 1.4 Compliance edid corruption test (rev3)
> URL   : https://patchwork.freedesktop.org/series/70530/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_7522 -> Patchwork_15658 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_15658 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_15658, please notify your bug team to allow them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   External URL: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/index.html
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_15658:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_ctx_create@basic-files:
> - fi-byt-j1900:   [PASS][1] -> [FAIL][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html
> 
>   * igt@i915_selftest@live_gt_heartbeat:
> - fi-whl-u:   [PASS][3] -> [DMESG-FAIL][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-whl-u/igt@i915_selftest@live_gt_heartbeat.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-whl-u/igt@i915_selftest@live_gt_heartbeat.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_15658 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@i915_selftest@live_blt:
> - fi-ivb-3770:[PASS][5] -> [DMESG-FAIL][6] ([i915#725])
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-ivb-3770/igt@i915_selftest@live_blt.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-ivb-3770/igt@i915_selftest@live_blt.html
> - fi-hsw-4770:[PASS][7] -> [DMESG-FAIL][8] ([i915#725])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-hsw-4770/igt@i915_selftest@live_blt.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-hsw-4770/igt@i915_selftest@live_blt.html
> 
>   * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-kbl-7500u:   [PASS][9] -> [FAIL][10] ([fdo#111096] / [i915#323])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
> 
>   
>  Possible fixes 
> 
>   * igt@gem_exec_parallel@basic:
> - {fi-tgl-u}: [INCOMPLETE][11] ([i915#476]) -> [PASS][12]
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-tgl-u/igt@gem_exec_paral...@basic.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15658/fi-tgl-u/igt@gem_exec_paral...@basic.html
> 
>   * igt@gem_sync@basic-store-each:
> - fi-tgl-y:   [INCOMPLETE][13] ([i915#435]) -> [PASS][14]
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7522/fi-tgl-y/igt@gem_s...@basic-store-each.html
>[14]: 
> 

Re: [Intel-gfx] [PATCH v2 2/9] drm/amd/display: Fix compilation issue.

[Harry Wentland]

On 2019-12-18 10:13 a.m., Animesh Manna wrote:
> [Why]:
> Aligh with DP spec wanted to follow same naming convention.
> 
> [How]:
> Changed the macro name of the dpcd address used for getting requested
> test-pattern.
> 

Please roll this into your patch that renames the definition. All
patches should compile on their own.

Thanks,
Harry

> Cc: Harry Wentland 
> Cc: Alex Deucher 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 42aa889fd0f5..1a6109be2fce 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct 
> dc_link *link)
>   /* get phy test pattern and pattern parameters from DP receiver */
>   core_link_read_dpcd(
>   link,
> - DP_TEST_PHY_PATTERN,
> + DP_PHY_TEST_PATTERN,
>   _test_pattern.raw,
>   sizeof(dpcd_test_pattern));
>   core_link_read_dpcd(
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/9] drm/amd/display: Fix compilation issue.

[Harry Wentland]

On 2019-12-18 11:13 a.m., Manna, Animesh wrote:
> 
> On 18-12-2019 21:12, Harry Wentland wrote:
>> On 2019-12-18 10:13 a.m., Animesh Manna wrote:
>>> [Why]:
>>> Aligh with DP spec wanted to follow same naming convention.
>>>
>>> [How]:
>>> Changed the macro name of the dpcd address used for getting requested
>>> test-pattern.
>>>
>> Please roll this into your patch that renames the definition. All
>> patches should compile on their own.
> 
> 
> Thanks Harry for review, wanted to follow similar commit-description
> format followed in amd-driver compare to i915 and created a separate
> patch. Maybe is it good idea to change the patch sequence and make it as
> first patch.
> 

Thanks for looking to follow the commit style from the rest of the amd
driver but in this case we need to combine them or you'll be left with
one patch in the sequence that won't build on its own.

Harry

> Regards,
> Animesh
> 
>>
>> Thanks,
>> Harry
>>
>>> Cc: Harry Wentland 
>>> Cc: Alex Deucher 
>>> Signed-off-by: Animesh Manna 
>>> ---
>>>   drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> index 42aa889fd0f5..1a6109be2fce 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> @@ -2491,7 +2491,7 @@ static void
>>> dp_test_send_phy_test_pattern(struct dc_link *link)
>>>   /* get phy test pattern and pattern parameters from DP receiver */
>>>   core_link_read_dpcd(
>>>   link,
>>> -    DP_TEST_PHY_PATTERN,
>>> +    DP_PHY_TEST_PATTERN,
>>>   _test_pattern.raw,
>>>   sizeof(dpcd_test_pattern));
>>>   core_link_read_dpcd(
>>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/amdgpu/dm: Do not throw an error for a display with no audio

[Harry Wentland]

On 2019-11-14 3:44 p.m., Chris Wilson wrote:
> An old display with no audio may not have an EDID with a CEA block, or
> it may simply be too old to support audio. This is not a driver error,
> so don't flag it as such.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
> References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
> Signed-off-by: Chris Wilson 

Reviewed-by: Harry Wentland 

Harry

> Cc: Harry Wentland 
> Cc: Jean Delvare 
> Cc: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 --
>  1 file changed, 2 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 11e5784aa62a..04808dbecab3 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
> @@ -97,8 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
>   (struct edid *) edid->raw_edid);
>  
>   sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> - if (sad_count < 0)
> - DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
>   if (sad_count <= 0)
>   return result;
>  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Harry Wentland]

On 2019-10-23 8:00 p.m., Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
> 

Please CC Nick on these as well. Added him now.

Would it be possible to add a patch to update amdgpu to call this function?

Harry

> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_edid.c  | 49 +
>  include/drm/drm_connector.h | 25 +++
>  include/drm/drm_edid.h  |  2 ++
>  3 files changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 474ac04d5600..97dd1200773e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4707,6 +4707,52 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   }
>  }
>  
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> +   const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
> + int i;
> +
> + /*
> +  * Restrict Adaptive Sync only for dp and edp
> +  */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + timing  = >detailed_timings[i];
> + data= >data.other_data;
> + range   = >data.range;
> + /*
> +  * Check if monitor has continuous frequency mode
> +  */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> +  * Check for flag range limits only. If flag == 1 then
> +  * no additional timing information provided.
> +  * Default GTF, GTF Secondary curve and CVT are not
> +  * supported
> +  */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> + info->adaptive_sync.pixel_clock_mhz =
> + range->pixel_clock_mhz * 10;
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> +
>  /* A connector has no EDID information, so we've got no EDID to compute 
> quirks from. Reset
>   * all of the values which would have been set from EDID
>   */
> @@ -4728,6 +4774,7 @@ drm_reset_display_info(struct drm_connector *connector)
>   memset(>hdmi, 0, sizeof(info->hdmi));
>  
>   info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
>  }
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
> @@ -4743,6 +4790,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  
>   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>  
> + drm_get_adaptive_sync_limits(connector, edid);
> +
>   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>  
>   if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5f8c3389d46f..a27a84270d8d 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,26 @@ enum drm_panel_orientation {
>   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>  
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * _display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed m

Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_content_protection: check i915 and generic debugfs name for HDCP caps

[Harry Wentland]

On 2019-10-21 3:42 p.m., Bhawanpreet Lakha wrote:
> The content protection tests only start if this debugfs entry exists.
> Since the name is specific to intel driver these tests cannot be used with
> other drivers. So we should check generic debugfs name also
> 
> v2: Check i915_* if device is i915, otherwise check the generic name.
> 
> Signed-off-by: Bhawanpreet Lakha 

Reviewed-by: Harry Wentland 

Harry

> ---
>  tests/kms_content_protection.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
> index e676b60b..42fdc459 100644
> --- a/tests/kms_content_protection.c
> +++ b/tests/kms_content_protection.c
> @@ -554,7 +554,11 @@ static bool sink_hdcp_capable(igt_output_t *output)
>   if (fd < 0)
>   return false;
>  
> - debugfs_read(fd, "i915_hdcp_sink_capability", buf);
> + if (is_i915_device(data.drm_fd))
> + debugfs_read(fd, "i915_hdcp_sink_capability", buf);
> + else
> + debugfs_read(fd, "hdcp_sink_capability", buf);
> +
>   close(fd);
>  
>   igt_debug("Sink capability: %s\n", buf);
> @@ -571,7 +575,11 @@ static bool sink_hdcp2_capable(igt_output_t *output)
>   if (fd < 0)
>   return false;
>  
> - debugfs_read(fd, "i915_hdcp_sink_capability", buf);
> + if (is_i915_device(data.drm_fd))
> + debugfs_read(fd, "i915_hdcp_sink_capability", buf);
> + else
> + debugfs_read(fd, "hdcp_sink_capability", buf);
> +
>   close(fd);
>  
>   igt_debug("Sink capability: %s\n", buf);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property

[Harry Wentland]

On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> This patch adds a scaling filter mode porperty
>> to allow:
>> - A driver/HW to showcase it's scaling filter capabilities.
>> - A userspace to pick a desired effect while scaling.
>>
>> This option will be particularly useful in the scenarios where
>> Integer mode scaling is possible, and a UI client wants to pick
>> filters like Nearest-neighbor applied for non-blurry outputs.
>>
>> There was a RFC patch series published, to discus the request to enable
>> Integer mode scaling by some of the gaming communities, which can be
>> found here:
>> https://patchwork.freedesktop.org/series/66175/
>>
>> Signed-off-by: Shashank Sharma 
>> ---
>>  drivers/gpu/drm/drm_atomic_uapi.c |  4 
>>  include/drm/drm_crtc.h| 26 ++
>>  include/drm/drm_mode_config.h |  6 ++
>>  3 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 0d466d3b0809..883329453a86 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
>> *crtc,
>>  return ret;
>>  } else if (property == config->prop_vrr_enabled) {
>>  state->vrr_enabled = val;
>> +} else if (property == config->scaling_filter_property) {
>> +state->scaling_filter = val;
>>  } else if (property == config->degamma_lut_property) {
>>  ret = drm_atomic_replace_property_blob_from_id(dev,
>>  >degamma_lut,
>> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>>  *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>>  else if (property == config->prop_out_fence_ptr)
>>  *val = 0;
>> +else if (property == config->scaling_filter_property)
>> +*val = state->scaling_filter;
>>  else if (crtc->funcs->atomic_get_property)
>>  return crtc->funcs->atomic_get_property(crtc, state, property, 
>> val);
>>  else
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 5e9b15a0e8c5..94c5509474a8 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -58,6 +58,25 @@ struct device_node;
>>  struct dma_fence;
>>  struct edid;
>>  
>> +enum drm_scaling_filters {
>> +DRM_SCALING_FILTER_DEFAULT,
>> +DRM_SCALING_FILTER_MEDIUM,
>> +DRM_SCALING_FILTER_BILINEAR,
>> +DRM_SCALING_FILTER_NN,
> 
> Please use real words.
> 
>> +DRM_SCALING_FILTER_NN_IS_ONLY,
> 
> Not a big fan of this. I'd just add the explicit nearest filter
> and leave the decision whether to use it to userspace.
> 
>> +DRM_SCALING_FILTER_EDGE_ENHANCE,
>> +DRM_SCALING_FILTER_INVALID,
> 
> That invalid enum value seems entirely pointless.
> 
> This set of filters is pretty arbitrary. It doesn't even cover all
> Intel hw. I would probably just leave it at "default+linear+nearest"
> initially. Exposing more vague hw specific choices needs more though,
> and I'd prefer not to spend those brain cells until a real use case
> emerges.
> 

FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.

I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.

Harry

>> +};
>> +
>> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
>> +{ DRM_SCALING_FILTER_DEFAULT, "Default" },
>> +{ DRM_SCALING_FILTER_MEDIUM, "Medium" },
>> +{ DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
>> +{ DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
>> +{ DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
>> +{ DRM_SCALING_FILTER_INVALID, "Invalid" },
>> +};
>> +
>>  static inline int64_t U642I64(uint64_t val)
>>  {
>>  return (int64_t)*((int64_t *));
>> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>>   */
>>  u32 target_vblank;
>>  
>> +/**
>> + * @scaling_filter:
>> + *
>> + * Scaling filter mode to be applied
>> + */
>> +u32 scaling_filter;
> 
> We have an enum so should use it. The documentation should probably
> point out that this applies to full crtc scaling only, not plane
> scaling.
> 
>> +
>>  /**
>>   * @async_flip:
>>   *
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 3bcbe30339f0..efd6fd55770f 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -914,6 +914,12 @@ struct drm_mode_config {
>>   */
>>  struct drm_property *modifiers_property;
>>  
>> +/**

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

[Harry Wentland]

On 2019-09-12 2:54 a.m., Ramalingam C wrote:
> On 2019-09-12 at 00:15:32 +0000, Harry Wentland wrote:
>> Adding a couple AMD guys.
>>
>> I know this is already merged but I have a few questions after some
>> internal discussions.
>>
>> On 2019-05-07 12:27 p.m., Ramalingam C wrote:
>>> On every hdcp revocation check request SRM is read from fw file
>>> /lib/firmware/display_hdcp_srm.bin
>>>
>>
>> According to section 5 of the HDCP 2.3 spec [1] a device compliant with
>> HDCP 2.0 and higher must be capable of storing and updating the SRM in
>> non-volatile memory. Section 5.2 describes how this SRM needs to be
>> updated when a new version is served alongside protected content.
>>
>> Isn't /lib/firmware intended for static firmware making updates to the
>> folder problematic for anyone but the system's package maintainer? I've
>> heard /lib might even be treated as read-only in certain environments.
>> This would mean it'd be impossible to support HDCP 2.x on those systems.
>>
>> Wouldn't it be easier to provide a sysfs entry for SRM that allows
>> userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
>> from the HDCP implementation for non-volatile storage and (b) to pass
>> the SRM to the HDCP implementation for revocation checking?
> 
> This uAPI is decided considering below points:
> 
> userspace will handle the non-volatile storage of the SRM table and it's 
> upgrade
> with latest versions received from content providers etc.
> 
> Prior to any HDCP auth request userspace will write the latest SRM into
> the /lib/firmware.
> 
> And regarding the interface, binary sysfs based implementation [1] was 
> opposed by Greg KH.
> And after the discussion on different alternate i/fs [2] request
> firmware is choosen.
> 
> [1]. https://patchwork.freedesktop.org/patch/296442/?series=57232=5uAPI
> [2]. https://patchwork.freedesktop.org/patch/296439/?series=57232=5
> 
> I hope this addresses the questions above.
> 

Interesting discussion. Thanks for sharing.

It sounds like Greg's main concern was with the fact that DRM parses the
binary.

In our case we'll need to pass the blob to FW without touching it. A
device sysfs sounds like a better use-case for that.

On the other hand certain people are interested to have a non-FW
approach to content protection for which your approach seems to work best.

I still don't know how this solution can get HDCP 2.x certified. I was
under the impression HDCP 2.x required a protected execution environment
with stricter requirements than x86 kernel space can provide.

Harry

> -Ram
> 
> 
>>
>> [1]
>> https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf
>>
>> Thanks,
>> Harry
>>
>>> SRM table is parsed and stored at drm_hdcp.c, with functions exported
>>> for the services for revocation check from drivers (which
>>> implements the HDCP authentication)
>>>
>>> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
>>>
>>> v2:
>>>   moved the uAPI to request_firmware_direct() [Daniel]
>>> v3:
>>>   kdoc added. [Daniel]
>>>   srm_header unified and bit field definitions are removed. [Daniel]
>>>   locking improved. [Daniel]
>>>   vrl length violation is fixed. [Daniel]
>>> v4:
>>>   s/__swab16/be16_to_cpu [Daniel]
>>>   be24_to_cpu is done through a global func [Daniel]
>>>   Unused variables are removed. [Daniel]
>>>   unchecked return values are dropped from static funcs [Daniel]
>>>
>>> Signed-off-by: Ramalingam C 
>>> Acked-by: Satyeshwar Singh 
>>> Reviewed-by: Daniel Vetter 
>>> ---
>>>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>>>  drivers/gpu/drm/Makefile  |   2 +-
>>>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>>>  drivers/gpu/drm/drm_internal.h|   4 +
>>>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>>>  include/drm/drm_hdcp.h|  24 ++
>>>  6 files changed, 370 insertions(+), 1 deletion(-)
>>>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
>>>
>>> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
>>> b/Documentation/gpu/drm-kms-helpers.rst
>>> index 14102ae035dc..0fe726a6ee67 100644
>>> --- a/Documentation/gpu/drm-kms-helpers.rst
>>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>>> @@ -181,6 +181,12 @@ Panel Helper Reference
>>>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
>>> :export:
>&g

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

[Harry Wentland]

Adding a couple AMD guys.

I know this is already merged but I have a few questions after some
internal discussions.

On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
> 

According to section 5 of the HDCP 2.3 spec [1] a device compliant with
HDCP 2.0 and higher must be capable of storing and updating the SRM in
non-volatile memory. Section 5.2 describes how this SRM needs to be
updated when a new version is served alongside protected content.

Isn't /lib/firmware intended for static firmware making updates to the
folder problematic for anyone but the system's package maintainer? I've
heard /lib might even be treated as read-only in certain environments.
This would mean it'd be impossible to support HDCP 2.x on those systems.

Wouldn't it be easier to provide a sysfs entry for SRM that allows
userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
from the HDCP implementation for non-volatile storage and (b) to pass
the SRM to the HDCP implementation for revocation checking?

[1]
https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf

Thanks,
Harry

> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> v3:
>   kdoc added. [Daniel]
>   srm_header unified and bit field definitions are removed. [Daniel]
>   locking improved. [Daniel]
>   vrl length violation is fixed. [Daniel]
> v4:
>   s/__swab16/be16_to_cpu [Daniel]
>   be24_to_cpu is done through a global func [Daniel]
>   Unused variables are removed. [Daniel]
>   unchecked return values are dropped from static funcs [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Satyeshwar Singh 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>  drivers/gpu/drm/drm_internal.h|   4 +
>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>  include/drm/drm_hdcp.h|  24 ++
>  6 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
> 
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> +   :export:
> +
>  Display Port Helper Functions Reference
>  ===
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 72f5036d9bfa..dd02e9dec810 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> -   drm_atomic_uapi.o
> +   drm_atomic_uapi.o drm_hdcp.o
> 
>  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
> drm_dma.o drm_scatter.o drm_lock.o
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> new file mode 100644
> index ..5e5409505c31
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * Authors:
> + * Ramalingam C 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct hdcp_srm {
> +   u32 revoked_ksv_cnt;
> +   u8 *revoked_ksv_list;
> +
> +   /* Mutex to protect above struct member */
> +   struct mutex mutex;
> +} *srm_data;
> +
> +static inline void drm_hdcp_print_ksv(const u8 *ksv)
> +{
> +   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
> +}
> +
> +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
> +{
> +   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> +
> +   while (parsed_bytes < vrls_length) {
> +   vrl_ksv_cnt = *buf;
> +   ksv_count += vrl_ksv_cnt;
> +
> +   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> +   buf += vrl_sz;
> +   parsed_bytes 

Re: [Intel-gfx] [PATCH RESEND 03/14] drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory

[Harry Wentland]

On 2019-08-26 3:25 p.m., Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
>  1 file changed, 3 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 cb7cfa9b34f2..e872a415b409 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5144,11 +5144,12 @@ static int amdgpu_dm_connector_init(struct 
> amdgpu_display_manager *dm,
>  
>   connector_type = to_drm_connector_type(link->connector_signal);
>  
> - res = drm_connector_init(
> + res = drm_connector_init_with_ddc(
>   dm->ddev,
>   >base,
>   _dm_connector_funcs,
> - connector_type);
> + connector_type,
> + >base);
>  
>   if (res) {
>   DRM_ERROR("connector_init failed\n");
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 1/6] drm/dp_mst: Add PBN calculation for DSC modes

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> With DSC, bpp can be fractional in multiples of 1/16.
> 
> Change drm_dp_calc_pbn_mode to reflect this, adding a new
> parameter bool dsc. When this parameter is true, treat the
> bpp parameter as having units not of bits per pixel, but
> 1/16 of a bit per pixel
> 
> v2: Don't add separate function for this
> 
> Cc: amd-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Reviewed-by: Manasi Navare 
> Reviewed-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> Signed-off-by: David Francis 
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c|  2 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c| 16 
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c   |  2 +-
>  include/drm/drm_dp_mst_helper.h  |  3 +--
>  6 files changed, 17 insertions(+), 10 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 a0ed0154a9f0..abafb5221b44 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
> @@ -235,7 +235,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>  
>   /* TODO need to know link rate */
>  
> - pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
>  
>   slots = drm_dp_find_vcpi_slots(mst_mgr, pbn);
>   ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port, pbn, slots);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..3e7b7553cf4d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3534,10 +3534,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
>   * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
>   * @clock: dot clock for the mode
>   * @bpp: bpp for the mode.
> + * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
>   *
>   * This uses the formula in the spec to calculate the PBN value for a mode.
>   */
> -int drm_dp_calc_pbn_mode(int clock, int bpp)
> +int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
>  {
>   u64 kbps;
>   s64 peak_kbps;
> @@ -3555,11 +3556,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
>* peak_kbps *= (1006/1000)
>* peak_kbps *= (64/54)
>* peak_kbps *= 8convert to bytes
> +  *
> +  * If the bpp is in units of 1/16, further divide by 16. Put this
> +  * factor in the numerator rather than the denominator to avoid
> +  * integer overflow
>*/
>  
>   numerator = 64 * 1006;
>   denominator = 54 * 8 * 1000 * 1000;
>  
> + if (dsc)
> + numerator /= 16;
> +
>   kbps *= numerator;
>   peak_kbps = drm_fixp_from_fraction(kbps, denominator);
>  
> @@ -3570,19 +3578,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
>  static int test_calc_pbn_mode(void)
>  {
>   int ret;
> - ret = drm_dp_calc_pbn_mode(154000, 30);
> + ret = drm_dp_calc_pbn_mode(154000, 30, false);
>   if (ret != 689) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   154000, 30, 689, ret);
>   return -EINVAL;
>   }
> - ret = drm_dp_calc_pbn_mode(234000, 30);
> + ret = drm_dp_calc_pbn_mode(234000, 30, false);
>   if (ret != 1047) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   234000, 30, 1047, ret);
>   return -EINVAL;
>   }
> - ret = drm_dp_calc_pbn_mode(297000, 24);
> + ret = drm_dp_calc_pbn_mode(297000, 24, false);
>   if (ret != 1063) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   297000, 24, 1063, ret);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2c5ac3dd647f..4f17f61f4453 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -61,7 +61,7 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   crtc_state->pipe_bpp = bpp;
>  
>   crtc_s

Re: [Intel-gfx] [PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

[Harry Wentland]

On 2018-09-19 07:08 PM, Lyude Paul wrote:
> Currently the way that we prevent userspace from performing new modesets
> on MST connectors that have just been destroyed is rather broken.
> There's nothing in the actual DRM DP MST topology helpers that checks
> whether or not a connector still exists, instead each DRM driver does
> this on it's own, usually by returning NULL from the best_encoder
> callback which in turn, causes the atomic commit to fail.
> 
> However, this is wrong in a rather subtle way. If ->best_encoder()
> returns NULL, this makes ALL modesets involving the connector fail. This
> includes modesets from userspace that would shut off the CRTCs being
> used by the connector. Since this results in blocking any changes to a
> connector's DPMS prop, it has the sideaffect of preventing legacy
> modesetting users from ever disabling a CRTC that was previously enabled
> for use in an MST topology. An example of this, where X tries to
> change the DPMS property of an MST connector that was just detached from
> the system:
> 
> [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6]
> [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6] status updated from connected to disconnected
> [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6] disconnected
> [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
> [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
> ...
> [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, 
> DRM_IOCTL_MODE_SETPROPERTY
> [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 
> 7155ba49
> [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
> [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
> [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 
> 97a6396e state to 7155ba49
> [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all 
> current connectors for [CRTC:41:head-0] to 7155ba49
> [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
> [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
> [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added 
> [CONNECTOR:82:DP-6] 87427144 state to 7155ba49
> [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49
> [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> [CRTC:41:head-0] active changed
> [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> Updating routing for [CONNECTOR:82:DP-6]
> [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No 
> suitable encoder found for [CONNECTOR:82:DP-6]
> [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 
> 7155ba49 failed: -22
> [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic 
> state 7155ba49
> [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
> [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
> [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
> [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
> [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 
> 7155ba49
> [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
> [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
> 
> While this doesn't usually result in any errors that would be obvious to
> the user, it does result in us leaving display resources on. This in
> turn leads to unwanted sideaffects like inactive GPUs being left on
> (usually from the resulting leaked runtime PM ref).
> 
> So, provide an easier way of doing this that doesn't require breaking
> ->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
> function that DRM drivers can call in order to have CRTC enabling
> commits fail automatically if the MST port driving the connector no
> longer exists. We'll also be able to expand upon this later as well once
> we add MST fallback retraining support.
> 
> Changes since v1:
> - Use list_for_each_entry_safe in drm_dp_mst_connector_still_exists() -
>   Julia Lawall
> 
> Signed-off-by: Lyude Paul 
> Cc: Julia Lawall 
> Cc: sta...@vger.kernel.org

Whoops, missed the v2 earlier. It's still
Acked-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++
>  include/drm/drm_dp_mst_helper.h   |  3 ++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
&g

Re: [Intel-gfx] [PATCH 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()

[Harry Wentland]

On 2018-09-18 07:06 PM, Lyude Paul wrote:
> Hook this into amdgpu's atomic check for their connectors so they never
> get modesets on no-longer-present MST connectors. We'll also expand on
> this later once we add DP MST fallback retraining support.
> 
> As well, turns out that the only atomic DRM driver without the
> ->best_encoder() bug is amdgpu. Congrats AMD!
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9a300732ba37..d011a39f17b2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -294,10 +294,22 @@ static struct drm_encoder *dm_mst_best_encoder(struct 
> drm_connector *connector)
>   return _dm_connector->mst_encoder->base;
>  }
>  
> +static int
> +amdgpu_dm_mst_connector_atomic_check(struct drm_connector *connector,
> +  struct drm_connector_state *new_cstate)
> +{
> + struct amdgpu_dm_connector *aconnector =
> + to_amdgpu_dm_connector(connector);
> +
> + return drm_dp_mst_connector_atomic_check(connector, new_cstate,
> +  >mst_mgr);
> +}
> +
>  static const struct drm_connector_helper_funcs 
> dm_dp_mst_connector_helper_funcs = {
>   .get_modes = dm_dp_mst_get_modes,
>   .mode_valid = amdgpu_dm_connector_mode_valid,
>   .best_encoder = dm_mst_best_encoder,
> + .atomic_check = amdgpu_dm_mst_connector_atomic_check,
>  };
>  
>  static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

[Harry Wentland]

On 2018-09-18 07:06 PM, Lyude Paul wrote:
> Currently the way that we prevent userspace from performing new modesets
> on MST connectors that have just been destroyed is rather broken.
> There's nothing in the actual DRM DP MST topology helpers that checks
> whether or not a connector still exists, instead each DRM driver does
> this on it's own, usually by returning NULL from the best_encoder
> callback which in turn, causes the atomic commit to fail.
> 
> However, this is wrong in a rather subtle way. If ->best_encoder()
> returns NULL, this makes ALL modesets involving the connector fail. This
> includes modesets from userspace that would shut off the CRTCs being
> used by the connector. Since this results in blocking any changes to a
> connector's DPMS prop, it has the sideaffect of preventing legacy
> modesetting users from ever disabling a CRTC that was previously enabled
> for use in an MST topology. An example of this, where X tries to
> change the DPMS property of an MST connector that was just detached from
> the system:
> 
> [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6]
> [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6] status updated from connected to disconnected
> [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] 
> [CONNECTOR:82:DP-6] disconnected
> [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
> [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
> ...
> [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, 
> DRM_IOCTL_MODE_SETPROPERTY
> [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 
> 7155ba49
> [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
> [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
> [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 
> 97a6396e state to 7155ba49
> [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all 
> current connectors for [CRTC:41:head-0] to 7155ba49
> [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
> [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
> [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added 
> [CONNECTOR:82:DP-6] 87427144 state to 7155ba49
> [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 7155ba49
> [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> [CRTC:41:head-0] active changed
> [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> Updating routing for [CONNECTOR:82:DP-6]
> [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No 
> suitable encoder found for [CONNECTOR:82:DP-6]
> [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 
> 7155ba49 failed: -22
> [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic 
> state 7155ba49
> [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
> [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
> [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
> [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
> [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 
> 7155ba49
> [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
> [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
> 
> While this doesn't usually result in any errors that would be obvious to
> the user, it does result in us leaving display resources on. This in
> turn leads to unwanted sideaffects like inactive GPUs being left on
> (usually from the resulting leaked runtime PM ref).
> 
> So, provide an easier way of doing this that doesn't require breaking
> ->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
> function that DRM drivers can call in order to have CRTC enabling
> commits fail automatically if the MST port driving the connector no
> longer exists. We'll also be able to expand upon this later as well once
> we add MST fallback retraining support.
> 
> Signed-off-by: Lyude Paul 
> Cc: sta...@vger.kernel.org

This does seem like a saner way to handle the case when the MST connector is 
gone. As this doesn't currently seem to affect amdgpu directly and I therefore 
might miss something I'll leave the RB to someone else, but you have my
Acked-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++
>  include/drm/drm_dp_mst_helper.h   |  3 ++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/

Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic

[Harry Wentland]

On 2018-09-13 12:31 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Disable atomic on a per-device basis instead of for all devices.
> Made possible by the new device.driver_features thing.
> 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Harry Wentland 
> Cc: Michel Dänzer 
> Suggested-by: Michel Dänzer 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6870909da926..8c1db96be070 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>   if (ret)
>   return ret;
>  
> - /* warn the user if they mix atomic and non-atomic capable GPUs */
> - if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
> - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> - /* support atomic early so the atomic debugfs stuff gets created */
> - if (supports_atomic)
> - kms_driver.driver_features |= DRIVER_ATOMIC;
> -
>   dev = drm_dev_alloc(_driver, >dev);
>   if (IS_ERR(dev))
>   return PTR_ERR(dev);
>  
> + if (!supports_atomic)
> + dev->driver_features &= ~DRIVER_ATOMIC;
> +
>   ret = pci_enable_device(pdev);
>   if (ret)
>   goto err_free;
> @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device 
> *dev, unsigned int pipe,
>  
>  static struct drm_driver kms_driver = {
>   .driver_features =
> - DRIVER_USE_AGP |
> + DRIVER_USE_AGP | DRIVER_ATOMIC |
>   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
>   DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
>   .load = amdgpu_driver_load_kms,
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/23] drm/dsc: Define VESA Display Stream Compression Capabilities

[Harry Wentland]

On 2018-07-31 05:07 PM, Manasi Navare wrote:
> From: Gaurav K Singh 
> 
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
> 
> v4 (From Manasi)
> * Add the DSC_MUX_WORD_SIZE constants (Manasi)
> 
> v3 (From Manasi)
> * Remove the duplicate define (Suggested By:Harry Wentland)
> 
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Cc: Harry Wentland 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Gaurav K Singh 

Acked-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dsc.h | 110 
> ++
>  1 file changed, 110 insertions(+)
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 678e8e6..eda323d 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,116 @@
>  
>  /* VESA Display Stream Compression DSC 1.2 constants */
>  #define DSC_NUM_BUF_RANGES   15
> +#define DSC_MUX_WORD_SIZE_8_10_BPC   48
> +#define DSC_MUX_WORD_SIZE_12_BPC 64
> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> +  * Flag indicating to do RGB - YCoCg conversion
> +  * and back (should be 1 for RGB input)
> +  */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> +  * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> +  * outside of DSC encode/decode algorithm)
> +  */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> +  * Factor to determine if an edge is present based
> +  * on the bits produced
> +  */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16  initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation

Re: [Intel-gfx] [PATCH v2 10/23] drm/dsc: Add helpers for DSC picture parameter set infoframes

[Harry Wentland]

On 2018-07-31 05:07 PM, Manasi Navare wrote:
> According to Display Stream compression spec 1.2, the picture
> parameter set metadata is sent from source to sink device
> using the DP Secondary data packet. An infoframe is formed
> for the PPS SDP header and PPS SDP payload bytes.
> This patch adds helpers to fill the PPS SDP header
> and PPS SDP payload according to the DSC 1.2 specification.
> 
> v5:
> Do not use bitfields for DRM structs (Jani N)
> v4:
> * Use DSC constants for params that dont change across
> configurations
> v3:
> * Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
> (Daniel Vetter)
> 
> v2:
> * Add EXPORT_SYMBOL for the drm functions (Manasi)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Cc: Harry Wentland 
> Signed-off-by: Manasi Navare 

Acked-by: Harry Wentland 

Harry

> ---
>  Documentation/gpu/drm-kms-helpers.rst |  12 ++
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dsc.c | 221 
> ++
>  include/drm/drm_dsc.h |  22 
>  4 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index f9cfcdc..50bb717 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -223,6 +223,18 @@ MIPI DSI Helper Functions Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> :export:
>  
> +Display Stream Compression Helper Functions Reference
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> +   :doc: dsc helpers
> +
> +.. kernel-doc:: include/drm/drm_dsc.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> +   :export:
> +
>  Output Probing Helper Functions Reference
>  =
>  
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a6771ce..961e511 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>  drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  
> -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o 
> drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
>   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
>   drm_simple_kms_helper.o drm_modeset_helper.o \
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> new file mode 100644
> index 000..99a8794
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -0,0 +1,221 @@
> +/*
> + *Copyright © 2018 Intel Corp
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and 
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that 
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission.  The copyright holders make no representations
> + * about the suitability of this software for any purpose.  It is provided 
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS 
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF 
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + *
> + * Author:
> + * Manasi Navare 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DOC: dsc helpers
> + *
> + * These functions contain some common logic and helpers to deal with VESA
> + * Display Stream Compression standard required for DSC on Display Port/eDP 
> or
> + * MIPI display interfaces.
> + */
> +
> +/**
> + * drm_dsc_dp_pps

Re: [Intel-gfx] [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe

[Harry Wentland]

On 2018-07-31 05:07 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
> 
> Cc: Gaurav K Singh 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Cc: Harry Wentland 
> Signed-off-by: Manasi Navare 

Looks like this version basically removes the bitfield definitions and adds 
those
in the comments, compared to the review in May.

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dsc.h | 365 
> ++
>  1 file changed, 365 insertions(+)
>  create mode 100644 include/drm/drm_dsc.h
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..678e8e6
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Manasi Navare 
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include 
> +
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES   15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter 
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display
> + * stream compression encoders must communicate to decoders.
> + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields 
> in
> + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big 
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> +  * @dsc_version:
> +  * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> +  * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> +  */
> + u8 dsc_version;
> + /**
> +  * @pps_identifier:
> +  * PPS1[7:0] - Application specific identifier that can be
> +  * used to differentiate between different PPS tables.
> +  */
> + u8 pps_identifier;
> + /**
> +  * @pps_reserved:
> +  * PPS2[7:0]- RESERVED Byte
> +  */
> + u8 pps_reserved;
> + /**
> +  * @pps_3:
> +  * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> +  * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> +  * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> +  * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> +  * PPS3[7:4] - bits_per_component: Bits per component for the original
> +  * pixels of the encoded picture.
> +  * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> +  * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> +  * allowed only when dsc_minor_version = 0x2)
> +  */
> + u8 pps_3;
> + /**
> +  * @pps_4:
> +  * PPS4[1:0] -These are the most significant 2 bits of
> +  * compressed BPP bits_per_pixel[9:0] syntax element.
> +  * PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> +  * PPS4[3] - simple_422: Indicates if decoder drops samples to
> +  * reconstruct the 4:2:2 picture.
> +  * PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> +  * active.
> +  *

Re: [Intel-gfx] [PATCH] drm: Pass crtc to .best_encoder()

[Harry Wentland]

On 2018-06-26 11:01 AM, Harry Wentland wrote:
> On 2018-06-15 03:52 PM, Ville Syrjala wrote:
>> From: Ville Syrjälä 
>>
>> To pick the correct MST encoder i915 wants to know which crtc is going
>> to be feeding us. To that end let's pass the crtc to the .best_encoder()
>> hook. The atomic variant already knows the crtc via the connector state,
>> but the non-atomic hooks is still being used by the fb_helper even on
>> atomic drivers.
>>
>> This allows us to fix up the possible_crtcs bitmask for the i915 MST
>> encoders. We have one encoder for each crtc+port combination, and thus
>> we have to know both the connector and the crtc to pick the right one.
>> This has only worked so far because every MST encoder lied in its
>> possible_crtcs bitmask that they can be driven by any crtc.
>>
>> I took the easy way out and passed NULL as the crtc for all the driver
>> internal uses of .best_encoder() in the amdgpu/radeon drivers. None of
>> the other drivers have such internal uses. The other callers
>> (crtc_helper, atomic_helper, fb_helper) will pass in the proper crtc.
>> but no one besides i915 will currently look at it.
>>
>> Cc: Alex Deucher 
>> Cc: "Christian König" 
>> Cc: "David (ChunMing) Zhou" 
>> Cc: Harry Wentland 
>> Cc: amd-...@lists.freedesktop.org
>> Signed-off-by: Ville Syrjälä 
> 
> amdgpu parts are
> Acked-by: Harry Wentland 
> 

Upgrading after proper review of the entire patch

Reviewed-by: Harry Wentland 

Harry

> Harry
> 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 33 +
>>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |  3 +-
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  7 ++--
>>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  5 +--
>>  drivers/gpu/drm/ast/ast_mode.c |  3 +-
>>  drivers/gpu/drm/bochs/bochs_kms.c  |  3 +-
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  3 +-
>>  drivers/gpu/drm/bridge/tc358767.c  |  3 +-
>>  drivers/gpu/drm/cirrus/cirrus_mode.c   |  5 +--
>>  drivers/gpu/drm/drm_atomic_helper.c| 16 ++---
>>  drivers/gpu/drm/drm_crtc_helper.c  |  3 +-
>>  drivers/gpu/drm/drm_fb_helper.c| 41 
>> --
>>  drivers/gpu/drm/gma500/gma_display.c   |  3 +-
>>  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  5 +--
>>  drivers/gpu/drm/gma500/psb_intel_drv.h |  3 +-
>>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c   |  3 +-
>>  drivers/gpu/drm/i2c/tda998x_drv.c  |  3 +-
>>  drivers/gpu/drm/i915/intel_dp_mst.c|  9 +++--
>>  drivers/gpu/drm/imx/imx-ldb.c  |  5 +--
>>  drivers/gpu/drm/imx/imx-tve.c  |  5 +--
>>  drivers/gpu/drm/imx/parallel-display.c |  5 +--
>>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  3 +-
>>  drivers/gpu/drm/mgag200/mgag200_mode.c |  5 +--
>>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  3 +-
>>  drivers/gpu/drm/nouveau/dispnv50/disp.c|  3 +-
>>  drivers/gpu/drm/nouveau/nouveau_connector.c|  3 +-
>>  drivers/gpu/drm/qxl/qxl_display.c  |  3 +-
>>  drivers/gpu/drm/radeon/radeon_connectors.c | 40 
>> +++--
>>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  5 +--
>>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  3 +-
>>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  |  5 +--
>>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  5 +--
>>  drivers/gpu/drm/udl/udl_connector.c|  3 +-
>>  drivers/staging/vboxvideo/vbox_mode.c  |  5 +--
>>  include/drm/drm_atomic_helper.h|  3 +-
>>  include/drm/drm_modeset_helper_vtables.h   |  6 ++--
>>  36 files changed, 155 insertions(+), 106 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> index 8e66851eb427..3dfa50ec2589 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> @@ -135,7 +135,8 @@ int amdgpu_connector_get_monitor_bpc(struct 
>> drm_connector *connector)
>>  else {
>>  const struct drm_connector_helper_funcs 
>> *connector_funcs =
>>  connector->helper_private;
>> -struct drm_encoder *encoder =

Re: [Intel-gfx] [PATCH] drm: Pass crtc to .best_encoder()

[Harry Wentland]

On 2018-06-15 03:52 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> To pick the correct MST encoder i915 wants to know which crtc is going
> to be feeding us. To that end let's pass the crtc to the .best_encoder()
> hook. The atomic variant already knows the crtc via the connector state,
> but the non-atomic hooks is still being used by the fb_helper even on
> atomic drivers.
> 
> This allows us to fix up the possible_crtcs bitmask for the i915 MST
> encoders. We have one encoder for each crtc+port combination, and thus
> we have to know both the connector and the crtc to pick the right one.
> This has only worked so far because every MST encoder lied in its
> possible_crtcs bitmask that they can be driven by any crtc.
> 
> I took the easy way out and passed NULL as the crtc for all the driver
> internal uses of .best_encoder() in the amdgpu/radeon drivers. None of
> the other drivers have such internal uses. The other callers
> (crtc_helper, atomic_helper, fb_helper) will pass in the proper crtc.
> but no one besides i915 will currently look at it.
> 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Harry Wentland 
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä 

amdgpu parts are
Acked-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 33 +
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |  3 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  7 ++--
>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c|  5 +--
>  drivers/gpu/drm/ast/ast_mode.c |  3 +-
>  drivers/gpu/drm/bochs/bochs_kms.c  |  3 +-
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  3 +-
>  drivers/gpu/drm/bridge/tc358767.c  |  3 +-
>  drivers/gpu/drm/cirrus/cirrus_mode.c   |  5 +--
>  drivers/gpu/drm/drm_atomic_helper.c| 16 ++---
>  drivers/gpu/drm/drm_crtc_helper.c  |  3 +-
>  drivers/gpu/drm/drm_fb_helper.c| 41 
> --
>  drivers/gpu/drm/gma500/gma_display.c   |  3 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  5 +--
>  drivers/gpu/drm/gma500/psb_intel_drv.h |  3 +-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c   |  3 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  3 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c|  9 +++--
>  drivers/gpu/drm/imx/imx-ldb.c  |  5 +--
>  drivers/gpu/drm/imx/imx-tve.c  |  5 +--
>  drivers/gpu/drm/imx/parallel-display.c |  5 +--
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  3 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c |  5 +--
>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  3 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c|  3 +-
>  drivers/gpu/drm/nouveau/nouveau_connector.c|  3 +-
>  drivers/gpu/drm/qxl/qxl_display.c  |  3 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c | 40 +++--
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  5 +--
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  |  5 +--
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  5 +--
>  drivers/gpu/drm/udl/udl_connector.c|  3 +-
>  drivers/staging/vboxvideo/vbox_mode.c  |  5 +--
>  include/drm/drm_atomic_helper.h|  3 +-
>  include/drm/drm_modeset_helper_vtables.h   |  6 ++--
>  36 files changed, 155 insertions(+), 106 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 8e66851eb427..3dfa50ec2589 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -135,7 +135,8 @@ int amdgpu_connector_get_monitor_bpc(struct drm_connector 
> *connector)
>   else {
>   const struct drm_connector_helper_funcs 
> *connector_funcs =
>   connector->helper_private;
> - struct drm_encoder *encoder = 
> connector_funcs->best_encoder(connector);
> + struct drm_encoder *encoder = 
> connector_funcs->best_encoder(connector,
> + 
> NULL);
>   struct amdgpu_encoder *amdgpu_encoder = 
> to_amdgpu_encoder(encoder);
>   struct amdgpu_encoder_atom_dig *dig = 
> amdgpu_encoder->enc_priv;
>  
>

Re: [Intel-gfx] [PATCH 2/3] drm: Print bad user modes

[Harry Wentland]

On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Print out the modeline when we reject a bad user mode. Avoids having to
> guess why it was rejected.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c| 20 +---
>  drivers/gpu/drm/drm_crtc.c  |  4 +++-
>  drivers/gpu/drm/drm_crtc_internal.h |  3 +++
>  drivers/gpu/drm/drm_modes.c |  2 +-
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d7de83a6c1c2..5fe5e06062a9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -400,10 +400,24 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   memset(>mode, 0, sizeof(state->mode));
>  
>   if (blob) {
> - if (blob->length != sizeof(struct drm_mode_modeinfo) ||
> - drm_mode_convert_umode(state->crtc->dev, >mode,
> -blob->data))
> + int ret;
> +
> + if (blob->length != sizeof(struct drm_mode_modeinfo)) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] bad mode blob length: 
> %zu\n",
> +  crtc->base.id, crtc->name,
> +  blob->length);
> + return -EINVAL;
> + }
> +
> + ret = drm_mode_convert_umode(crtc->dev,
> +  >mode, blob->data);
> + if (ret) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] invalid mode (ret=%d, 
> status=%s):\n",
> +  crtc->base.id, crtc->name,
> +  ret, 
> drm_get_mode_status_name(state->mode.status));
> + drm_mode_debug_printmodeline(>mode);
>   return -EINVAL;
> + }
>  
>   state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 53828fc8d911..163d82ac7d76 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -649,7 +649,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>  
>   ret = drm_mode_convert_umode(dev, mode, _req->mode);
>   if (ret) {
> - DRM_DEBUG_KMS("Invalid mode\n");
> + DRM_DEBUG_KMS("Invalid mode (ret=%d, status=%s)\n",
> +   ret, 
> drm_get_mode_status_name(mode->status));
> + drm_mode_debug_printmodeline(mode);
>   goto out;
>   }
>  
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 5d307b23a4e6..34499800932a 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -56,6 +56,9 @@ int drm_mode_setcrtc(struct drm_device *dev,
>  int drm_modeset_register_all(struct drm_device *dev);
>  void drm_modeset_unregister_all(struct drm_device *dev);
>  
> +/* drm_modes.c */
> +const char *drm_get_mode_status_name(enum drm_mode_status status);
> +
>  /* IOCTLs */
>  int drm_mode_getresources(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index c78ca0e84ffd..7f552d5fa88e 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1257,7 +1257,7 @@ static const char * const drm_mode_status_names[] = {
>  
>  #undef MODE_STATUS
>  
> -static const char *drm_get_mode_status_name(enum drm_mode_status status)
> +const char *drm_get_mode_status_name(enum drm_mode_status status)
>  {
>   int index = status + 3;
>  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Improve debug messages

[Harry Wentland]

On 2018-06-11 03:34 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Print the id/name of the object we're dealing with. Makes it easier to
> figure out what's going on. Also toss in a few extra debug prints that
> might be useful.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c | 88 
> ++--
>  1 file changed, 61 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ee4b43b9404e..d7de83a6c1c2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -339,6 +339,7 @@ static s32 __user *get_out_fence_for_crtc(struct 
> drm_atomic_state *state,
>  int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
>const struct drm_display_mode *mode)
>  {
> + struct drm_crtc *crtc = state->crtc;
>   struct drm_mode_modeinfo umode;
>  
>   /* Early return for no change. */
> @@ -359,13 +360,13 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
> *state,
>  
>   drm_mode_copy(>mode, mode);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  mode->name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +  mode->name, crtc->base.id, crtc->name, state);
>   } else {
>   memset(>mode, 0, sizeof(state->mode));
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> -  state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +  crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -388,6 +389,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
>  int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
>struct drm_property_blob *blob)
>  {
> + struct drm_crtc *crtc = state->crtc;
> +
>   if (blob == state->mode_blob)
>   return 0;
>  
> @@ -404,12 +407,13 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>  
>   state->mode_blob = drm_property_blob_get(blob);
>   state->enable = true;
> - DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
> -  state->mode.name, state);
> + DRM_DEBUG_ATOMIC("Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> +  state->mode.name, crtc->base.id, crtc->name,
> +  state);
>   } else {
>   state->enable = false;
> - DRM_DEBUG_ATOMIC("Set [NOMODE] for CRTC state %p\n",
> -  state);
> + DRM_DEBUG_ATOMIC("Set [NOMODE] for [CRTC:%d:%s] state %p\n",
> +  crtc->base.id, crtc->name, state);
>   }
>  
>   return 0;
> @@ -539,10 +543,14 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   return -EFAULT;
>  
>   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> - } else if (crtc->funcs->atomic_set_property)
> + } else if (crtc->funcs->atomic_set_property) {
>   return crtc->funcs->atomic_set_property(crtc, state, property, 
> val);
> - else
> + } else {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] unknown property 
> [PROP:%d:%s]]\n",
> +  crtc->base.id, crtc->name,
> +  property->base.id, property->name);
>   return -EINVAL;
> + }
>  
>   return 0;
>  }
> @@ -799,8 +807,11 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
>   } else if (property == plane->alpha_property) {
>   state->alpha = val;
>   } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
> + if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask: 
> 0x%llx\n",
> +  plane->base.id, plane->name, val);
>   return -EINVAL;
> + }
>   state->rotation = val;
>   } else if (pr

Re: [Intel-gfx] [PATCH v2 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PPS header and payload bytes in an infoframe
> that can be sent to the display sink using secondary data packets
> as defined in DP 1.4 spec.
> 
> This patch series creates a new files drm_dsc.h and drm_dsc.c
> which define all the DSC related structures and helpers that
> can be called by drivers to form DSC PPS infoframes before
> enabling Display Stream compression on eDP/DP/MIPI
> 
> v2:
> *This is a v2 of the original patch series which adds kernel-doc
> hooks for the new dsc files in drm-kms-helpers.rst. (Daniel Vetter)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> Cc: Anusha Srivatsa <anusha.sriva...@intel.com>

With my comments for patch 2 and 3 addressed patches 1-3 are
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Patch 4 is
Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> 
> Gaurav K Singh (1):
>   drm/dsc: Define VESA Display Stream Compression Capabilities
> 
> Manasi Navare (3):
>   drm/dp: Define payload size for DP SDP PPS packet
>   drm/dsc: Define Display Stream Compression PPS infoframe
>   drm/dsc: Add helpers for DSC picture parameter set infoframes
> 
>  Documentation/gpu/drm-kms-helpers.rst |  12 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_dsc.c | 227 ++
>  include/drm/drm_dp_helper.h   |   1 +
>  include/drm/drm_dsc.h | 564 
> ++
>  5 files changed, 805 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
>  create mode 100644 include/drm/drm_dsc.h
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> From: Gaurav K Singh 
> 
> This defines all the DSC parameters as per the VESA DSC spec
> that will be required for DSC encoder/decoder
> 
> v2: Define this struct in DRM (From Manasi)
> * Changed the data types to u8/u16 instead of unsigned longs (Manasi)
> * Remove driver specific fields (Manasi)
> * Move this struct definition to DRM (Manasi)
> * Define DSC 1.2 parameters (Manasi)
> * Use DSC_NUM_BUF_RANGES (Manasi)
> * Call it drm_dsc_config (Manasi)
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Gaurav K Singh 
> ---
>  include/drm/drm_dsc.h | 111 
> ++
>  1 file changed, 111 insertions(+)
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 5ee72e8..04501e2 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -30,6 +30,117 @@
>  
>  #define DSC_NUM_BUF_RANGES   15
>  
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES   15

Duplicate definition of previous line.

Harry

> +
> +/* Configuration for a single Rate Control model range */
> +struct dsc_rc_range_parameters {
> + /* Min Quantization Parameters allowed for this range */
> + u8 range_min_qp;
> + /* Max Quantization Parameters allowed for this range */
> + u8 range_max_qp;
> + /* Bits/group offset to apply to target for this group */
> + u8 range_bpg_offset;
> +};
> +
> +struct drm_dsc_config {
> + /* Bits / component for previous reconstructed line buffer */
> + u8 line_buf_depth;
> + /* Bits per component to code (must be 8, 10, or 12) */
> + u8 bits_per_component;
> + /*
> +  * Flag indicating to do RGB - YCoCg conversion
> +  * and back (should be 1 for RGB input)
> +  */
> + bool convert_rgb;
> + u8 slice_count;
> + /* Slice Width */
> + u16 slice_width;
> + /* Slice Height */
> + u16 slice_height;
> + /*
> +  * 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
> +  * outside of DSC encode/decode algorithm)
> +  */
> + bool enable422;
> + /* Picture Width */
> + u16 pic_width;
> + /* Picture Height */
> + u16 pic_height;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_high;
> + /* Offset to bits/group used by RC to determine QP adjustment */
> + u8 rc_tgt_offset_low;
> + /* Bits/pixel target << 4 (ie., 4 fractional bits) */
> + u16 bits_per_pixel;
> + /*
> +  * Factor to determine if an edge is present based
> +  * on the bits produced
> +  */
> + u8 rc_edge_factor;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit1;
> + /* Slow down incrementing once the range reaches this value */
> + u8 rc_quant_incr_limit0;
> + /* Number of pixels to delay the initial transmission */
> + u16 initial_xmit_delay;
> + /* Number of pixels to delay the VLD on the decoder,not including SSM */
> + u16  initial_dec_delay;
> + /* Block prediction enable */
> + bool block_pred_enable;
> + /* Bits/group offset to use for first line of the slice */
> + u8 first_line_bpg_offset;
> + /* Value to use for RC model offset at slice start */
> + u16 initial_offset;
> + /* Thresholds defining each of the buffer ranges */
> + u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
> + /* Parameters for each of the RC ranges */
> + struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> + /* Total size of RC model */
> + u16 rc_model_size;
> + /* Minimum QP where flatness information is sent */
> + u8 flatness_min_qp;
> + /* Maximum QP where flatness information is sent */
> + u8 flatness_max_qp;
> + /* Initial value for scale factor */
> + u8 initial_scale_value;
> + /* Decrement scale factor every scale_decrement_interval groups */
> + u16 scale_decrement_interval;
> + /* Increment scale factor every scale_increment_interval groups */
> + u16 scale_increment_interval;
> + /* Non-first line BPG offset to use */
> + u16 nfl_bpg_offset;
> + /* BPG offset used to enforce slice bit */
> + u16 slice_bpg_offset;
> + /* Final RC linear transformation offset value */
> + u16 final_offset;
> + /* Enable on-off VBR (ie., disable stuffing bits) */
> + bool vbr_enable;
> + /* Mux word size (in bits) for SSM mode */
> + u8 mux_word_size;
> + /*
> +  * The (max) size in bytes of the "chunks" that are
> +  * used in slice multiplexing
> +  */
> + u16 slice_chunk_size;
> + /* Rate Control buffer siz in bits */
> + 

Re: [Intel-gfx] [PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

[Harry Wentland]

On 2018-05-14 10:05 PM, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
> 
> v2:
> * Fix the comments for kernel-doc
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Anusha Srivatsa 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_dsc.h | 437 
> ++
>  1 file changed, 437 insertions(+)
>  create mode 100644 include/drm/drm_dsc.h
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index 000..5ee72e8
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,437 @@
> +/*
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + * Manasi Navare 
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include 
> +
> +#define DSC_NUM_BUF_RANGES   15
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter 
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display 
> stream
> + * compression encoders must communicate to decoders. The PPS is encapsulated
> + * in 128 bytes (PPS 0 through PPS 127). The fields in this structure are as 
> per
> + * Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big 
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
> + /**
> +  * @dsc_version_minor:
> +  * PPS0[3:0] - Contains Minor version of DSC
> +  */
> + u8 dsc_version_minor:4;
> + /**
> +  * @dsc_version_major:
> +  * PPS0[7:4] - Contains major version of DSC
> +  */
> + u8 dsc_version_major:4;
> + /**
> +  * @pps_identifier:
> +  * PPS1[7:0] - Application specific identifier that can be
> +  * used to differentiate between different PPS tables.
> +  */
> + u8 pps_identifier;
> + /**
> +  * @pps2_reserved:
> +  * PPS2[7:0]- RESERVED Byte
> +  */
> + u8 pps2_reserved;
> + /**
> +  * @linebuf_depth:
> +  * PPS3[3:0] - Contains linebuffer bit depth used to generate
> +  * the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
> +  * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> +  * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> +  */
> + u8 linebuf_depth:4;
> + /**
> +  * @bits_per_component:
> +  * PPS3[7:4] - Bits per component fo rthe original pixels

typo: "for the"

> +  * of the encoded picture.
> +  */

Would it make sense to indicate in the comments what the values mean?

From the spec:
0x0 = 16bpc (allowed only when dsc_version_minor = 0x2).
0x8 = 8bpc.
0xA = 10bpc.
0xC = 12bpc.
0xE = 14bpc (allowed only when dsc_version_minor = 0x2).
All other encodings are RESERVED.

Harry

> + u8 bits_per_component:4;
> + /**
> +  * @bpp_high:
> +  * PPS4[1:0] - These are the most significant 2 bits of
> +  * compressed BPP bits_per_pixel[9:0] syntax element.
> +  */
> + u8 bpp_high:2;
> + /**
> +  * @vbr_enable:
> +  * PPS4[2] - 0 = VBR disabled, 1 = VBR enabled
> +  */
> + u8 vbr_enable:1;
> + /**
> +  * @simple_422:
> +  * PPS4[3] - Indicates if decoder drops samples to
> +  * reconstruct the 4:2:2 picture.
> +  */
> + u8 simple_422:1;
> + /**
> +  * @convert_rgb:
> +  * PPS4[4] - Indicates if DSC color space conversion is active
> +  */
> + u8 convert_rgb:1;
> 

Re: [Intel-gfx] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Harry Wentland]

On 2018-04-13 06:00 AM, Daniel Vetter wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
> 
> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.
> 
> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.
> 
> v2: Point at MAINTAINERS for contact info (Daniel S.)
> 
> v3:
> - Make it clear that commit rights are voluntary and that committers
>   need to acknowledge positively when they're nominated by someone
>   else (Keith).
> - Encourage committers to drop their commit rights when they're no
>   longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>   new committers (me).
> 
> v4: Typo (Petri).
> 
> v5: Typo (Sean).
> 
> v6: Wording clarifications and spelling (Jani).
> 
> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).
> 
> Acked-by: Alex Deucher <alexander.deuc...@amd.com>
> Acked-by: Arkadiusz Hiler <arkadiusz.hi...@intel.com>
> Acked-by: Daniel Stone <dan...@fooishbar.org>
> Acked-by: Eric Anholt <e...@anholt.net>
> Acked-by: Gustavo Padovan <gust...@padovan.org>
> Acked-by: Petri Latvala <petri.latv...@intel.com>

Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com>
> Cc: Ben Widawsky <b...@bwidawsk.net>
> Cc: Daniel Stone <dan...@fooishbar.org>
> Cc: Dave Airlie <airl...@gmail.com>
> Cc: Eric Anholt <e...@anholt.net>
> Cc: Gustavo Padovan <gust...@padovan.org>
> Cc: Jani Nikula <jani.nik...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Keith Packard <kei...@keithp.com>
> Cc: Kenneth Graunke <kenn...@whitecape.org>
> Cc: Kristian H. Kristensen <hoegsb...@google.com>
> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Petri Latvala <petri.latv...@intel.com>
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Cc: Sean Paul <seanp...@chromium.org>
> Reviewed-by: Keith Packard <kei...@keithp.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.
> 
> fd.o admins also plan to discuss this (and a pile of other topics and
> hosting and code of conduct) with all projects, ideally this here
> would end up as the starting point for establishing some community
> norms.
> -Daniel
> ---
>  CONTRIBUTING | 48 
>  1 file changed, 48 insertions(+)
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0180641be3aa..8a118134275c 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -51,4 +51,52 @@ A short list of contribution guidelines:
>  - Changes to the testcases are automatically tested. Take the results into
>account before merging.
>  
> +Commit rights
> +-
> +
> +Commit rights will be granted to anyone who requests them and fulfills the
> +below criteria:
> +
> +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple
> +  spelling fixes and whitespace adjustment) patches that have been merged
> +  already.
> +
> +- Are actively participating on discussions about their work (on the mailing
> +  list or IRC). This should not be interpreted as a requirement to review 
> other
> +  peoples patches but just make sure that patch submission isn't one-way
> +  communication. Cross-review is still highly encouraged.
> +
> +- Will be regularly contributing further patches. This includes regular
> +  contributors to other parts of the open source graphics stack who only
> +  do the oddball rare patch within igt itself.
> +
> +- Agrees to use their commit rights in accordance with the documented merge
> +  criteria, tools, and processes.
> +
> +Apply for an account (and any other account change requests) through
> +
> +https://www.freedesktop.org/wiki/AccountRequests/
> +
> +and please ping the maintainers if your request is

Re: [Intel-gfx] [PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

[Harry Wentland]

On 2018-04-05 12:41 PM, Daniel Vetter wrote:
> On Thu, Apr 05, 2018 at 06:13:51PM +0300, Ville Syrjala wrote:
>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>
>> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>>
>> Cc: Alex Deucher <alexander.deuc...@amd.com>
>> Cc: "Christian König" <christian.koe...@amd.com>
>> Cc: "David (ChunMing) Zhou" <david1.z...@amd.com>
>> Cc: Harry Wentland <harry.wentl...@amd.com>
>> Cc: amd-...@lists.freedesktop.org
>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>> Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
> 
> Under the assumption that all the hits outside of amdgpu/display/ are the
> legacy/non-DC/non-atomic modeset code (which looks to be the case):
> 

Yes, that's the case.

Harry

> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> 
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
>>  1 file changed, 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 e42a28e3adc5..91d048bb5574 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -3943,8 +3943,6 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>>  
>>  /* Flip */
>>  spin_lock_irqsave(>dev->event_lock, flags);
>> -/* update crtc fb */
>> -crtc->primary->fb = fb;
>>  
>>  WARN_ON(acrtc->pflip_status != AMDGPU_FLIP_NONE);
>>  WARN_ON(!acrtc_state->stream);
>> -- 
>> 2.16.1
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/23] drm/amdgpu/dc: Stop updating plane->fb

[Harry Wentland]

On 2018-03-22 11:23 AM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
> 
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: "Christian König" <christian.koe...@amd.com>
> Cc: "David (ChunMing) Zhou" <david1.z...@amd.com>
> Cc: Harry Wentland <harry.wentl...@amd.com>
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Patches 1-8 & 15 also look reasonable to me, but I'm not an expert on this. 
Feel free to add my
Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
>  1 file changed, 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 ae512ecb65ee..a8129eca6e6d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3941,8 +3941,6 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>  
>   /* Flip */
>   spin_lock_irqsave(>dev->event_lock, flags);
> - /* update crtc fb */
> - crtc->primary->fb = fb;
>  
>   WARN_ON(acrtc->pflip_status != AMDGPU_FLIP_NONE);
>   WARN_ON(!acrtc_state->stream);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

[Harry Wentland]

On 2018-03-22 01:54 PM, Emil Velikov wrote:
> Hi Ville,
> 
> On 22 March 2018 at 15:22, Ville Syrjala  
> wrote:
>> From: Ville Syrjälä 
>>
>> I really just wanted to fix i915 to re-enable its planes afer load
>> detection (a two line patch). This is what I actually ended up with
>> after I ran into a framebuffer refcount leak with said two line patch.
>>
>> I've tested this on a few i915 boxes and so far it's looking
>> good. Everything else is just compile tested.
>>
> Mostly thinking out loud:
> 
> Wondering if one cannot somehow (re)move plane->fb/crtc altogether.
> Otherwise drivers will reintroduce similar code, despite the WARNs and
> beefy documentation :-\

Wouldn't that require an atomic conversion of all remaining drivers?

Harry

> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

[Harry Wentland]

On 2018-03-06 12:13 PM, Daniel Vetter wrote:
> On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
>> On 2018-03-06 07:18 AM, Ville Syrjälä wrote:
>>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
>>>> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
>>>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>>>
>>>>> edid and display_info are protected by mode_config.mutex. Add lockdep
>>>>> asserts to make sure we're not accessing things w/o the lock.
>>>>>
>>>>> FIXME: pretty sure this will blow up with amdgpu as they seem
>>>>> to be doing edid updates even from the modeset path. Need to figure
>>>>> out what to do about that. Maybe protect the edid/display info with
>>>>> with connection_mutex instead of mode_config.mutex?
>>>>
>>>> Imo not doing EDID udpates from the modeset path is the right fix. I can't
>>>> think of any reasonable reason to do that at least. Can you point me at
>>>> the relevant amdgpu code pls (I'm lazy, sry)?
>>>
>>> It was some MST thing I believe... (should have written it down)
>>>
>>> amdgpu_dm_atomic_check() -> dm_update_crtcs_state() ->
>>> create_stream_for_sink() -> dm_dp_mst_dc_sink_create() ->
>>> get_edid/update_edid_property
>>>
>>
>> Yeah, it's because the dc_sink carries the EDID and is only created at
>> this point for us. It's bugged me ever since we did this. Might be time
>> to think of a solution to it now.
> 
> But how does this work? Userspace won't do a modeset without the EDID
> present and the modes listed, which means you'll never ever end up in
> atomic check. This really sounds rather wrong.
> 

Not sure if this works correctly with atomic userspace.

I think with legacy userspace we might rely on the get_connector call doing 
.fill_modes > drm_helper_probe_single_connector_modes > .get_modes > 
dm_dp_mst_get_modes > drm_dp_mst_get_edid

Harry


> Only idea I can come up with is that you're abusing the regular pageflip
> request as a worker thread, but that's some seriously backwards design.
> -Daniel
> 
>>
>> Harry
>>
>>>>
>>>> Otherwise I think this is a real good patch.
>>>>
>>>> Thanks, Daniel
>>>>
>>>>>
>>>>> Cc: Keith Packard <kei...@keithp.com>
>>>>> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
>>>>> Cc: Harry Wentland <harry.wentl...@amd.com>
>>>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>>> ---
>>>>>  drivers/gpu/drm/drm_connector.c| 4 
>>>>>  drivers/gpu/drm/drm_edid.c | 2 ++
>>>>>  drivers/gpu/drm/drm_probe_helper.c | 2 +-
>>>>>  3 files changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>>>> b/drivers/gpu/drm/drm_connector.c
>>>>> index 122060792b6f..a9f3536f4e94 100644
>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>> @@ -1374,6 +1374,8 @@ int drm_mode_connector_update_edid_property(struct 
>>>>> drm_connector *connector,
>>>>>   size_t size = 0;
>>>>>   int ret;
>>>>>  
>>>>> + lockdep_assert_held(>mode_config.mutex);
>>>>> +
>>>>>   /* ignore requests to set edid when overridden */
>>>>>   if (connector->override_edid)
>>>>>   return 0;
>>>>> @@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct 
>>>>> drm_connector *connector)
>>>>>  {
>>>>>   struct drm_display_info *info = >display_info;
>>>>>  
>>>>> + lockdep_assert_held(>dev->mode_config.mutex);
>>>>> +
>>>>>   memset(info, 0, sizeof(*info));
>>>>>  }
>>>>>  EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
>>>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>>>> index 618093c4a039..7f9e9236114b 100644
>>>>> --- a/drivers/gpu/drm/drm_edid.c
>>>>> +++ b/drivers/gpu/drm/drm_edid.c
>>>>> @@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector 
>>>>> *connector, const struct edid *edi
>>>>>   struct drm_display_info *info = >display_info;
>>>>>   u32 quirks = edid_get_quirks(edid);
>>>>>  
>>>>> + lockdep_assert_held(>dev->mode_config.mutex);
>>>>> +
>>>>>   info->width_mm = edid->width_cm * 10;
>>>>>   info->height_mm = edid->height_cm * 10;
>>>>>  
>>>>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>>>>> b/drivers/gpu/drm/drm_probe_helper.c
>>>>> index 7dc7e635d7e4..2a2afcf72788 100644
>>>>> --- a/drivers/gpu/drm/drm_probe_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>>>>> @@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct 
>>>>> drm_connector *connector,
>>>>>   enum drm_connector_status old_status;
>>>>>   struct drm_modeset_acquire_ctx ctx;
>>>>>  
>>>>> - WARN_ON(!mutex_is_locked(>mode_config.mutex));
>>>>> + lockdep_assert_held(>mode_config.mutex);
>>>>>  
>>>>>   drm_modeset_acquire_init(, 0);
>>>>>  
>>>>> -- 
>>>>> 2.13.6
>>>>>
>>>>
>>>> -- 
>>>> Daniel Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>>>
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

[Harry Wentland]

On 2018-03-06 07:18 AM, Ville Syrjälä wrote:
> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
>> On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>
>>> edid and display_info are protected by mode_config.mutex. Add lockdep
>>> asserts to make sure we're not accessing things w/o the lock.
>>>
>>> FIXME: pretty sure this will blow up with amdgpu as they seem
>>> to be doing edid updates even from the modeset path. Need to figure
>>> out what to do about that. Maybe protect the edid/display info with
>>> with connection_mutex instead of mode_config.mutex?
>>
>> Imo not doing EDID udpates from the modeset path is the right fix. I can't
>> think of any reasonable reason to do that at least. Can you point me at
>> the relevant amdgpu code pls (I'm lazy, sry)?
> 
> It was some MST thing I believe... (should have written it down)
> 
> amdgpu_dm_atomic_check() -> dm_update_crtcs_state() ->
> create_stream_for_sink() -> dm_dp_mst_dc_sink_create() ->
> get_edid/update_edid_property
> 

Yeah, it's because the dc_sink carries the EDID and is only created at this 
point for us. It's bugged me ever since we did this. Might be time to think of 
a solution to it now.

Harry

>>
>> Otherwise I think this is a real good patch.
>>
>> Thanks, Daniel
>>
>>>
>>> Cc: Keith Packard <kei...@keithp.com>
>>> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
>>> Cc: Harry Wentland <harry.wentl...@amd.com>
>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_connector.c| 4 
>>>  drivers/gpu/drm/drm_edid.c | 2 ++
>>>  drivers/gpu/drm/drm_probe_helper.c | 2 +-
>>>  3 files changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index 122060792b6f..a9f3536f4e94 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -1374,6 +1374,8 @@ int drm_mode_connector_update_edid_property(struct 
>>> drm_connector *connector,
>>> size_t size = 0;
>>> int ret;
>>>  
>>> +   lockdep_assert_held(>mode_config.mutex);
>>> +
>>> /* ignore requests to set edid when overridden */
>>> if (connector->override_edid)
>>> return 0;
>>> @@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct 
>>> drm_connector *connector)
>>>  {
>>> struct drm_display_info *info = >display_info;
>>>  
>>> +   lockdep_assert_held(>dev->mode_config.mutex);
>>> +
>>> memset(info, 0, sizeof(*info));
>>>  }
>>>  EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 618093c4a039..7f9e9236114b 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector 
>>> *connector, const struct edid *edi
>>> struct drm_display_info *info = >display_info;
>>> u32 quirks = edid_get_quirks(edid);
>>>  
>>> +   lockdep_assert_held(>dev->mode_config.mutex);
>>> +
>>> info->width_mm = edid->width_cm * 10;
>>> info->height_mm = edid->height_cm * 10;
>>>  
>>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>>> b/drivers/gpu/drm/drm_probe_helper.c
>>> index 7dc7e635d7e4..2a2afcf72788 100644
>>> --- a/drivers/gpu/drm/drm_probe_helper.c
>>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>>> @@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct 
>>> drm_connector *connector,
>>> enum drm_connector_status old_status;
>>> struct drm_modeset_acquire_ctx ctx;
>>>  
>>> -   WARN_ON(!mutex_is_locked(>mode_config.mutex));
>>> +   lockdep_assert_held(>mode_config.mutex);
>>>  
>>> drm_modeset_acquire_init(, 0);
>>>  
>>> -- 
>>> 2.13.6
>>>
>>
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Harry Wentland]

On 2018-03-06 05:35 AM, Daniel Vetter wrote:
> On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote:
>> On 2018-03-05 04:33 PM, Alex Deucher wrote:
>>> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
>>> <ville.syrj...@linux.intel.com> wrote:
>>>> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>>>>> Ville Syrjala <ville.syrj...@linux.intel.com> writes:
>>>>>
>>>>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>>>>
>>>>>> To make life easier for drivers, let's have the core check that the
>>>>>> requested pixel format is supported by at least one plane when creating
>>>>>> a new framebuffer.
>>>>>>
>>>>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>>>>>>  1 file changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>>>>>> b/drivers/gpu/drm/drm_framebuffer.c
>>>>>> index c0530a1af5e3..155b21e579c4 100644
>>>>>> --- a/drivers/gpu/drm/drm_framebuffer.c
>>>>>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>>>>>> @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>>>>>> return DIV_ROUND_UP(height, format->vsub);
>>>>>>  }
>>>>>>
>>>>>> +static bool planes_have_format(struct drm_device *dev, u32 format)
>>>>>> +{
>>>>>> +   struct drm_plane *plane;
>>>>>> +
>>>>>> +   /* TODO: maybe maintain a device level format list? */
>>>>>> +   drm_for_each_plane(plane, dev) {
>>>>>> +   int i;
>>>>>> +
>>>>>> +   for (i = 0; i < plane->format_count; i++) {
>>>>>> +   if (plane->format_types[i] == format)
>>>>>> +   return true;
>>>>>> +   }
>>>>>> +   }
>>>>>> +
>>>>>> +   return false;
>>>>>> +}
>>>>>> +
>>>>>>  static int framebuffer_check(struct drm_device *dev,
>>>>>>  const struct drm_mode_fb_cmd2 *r)
>>>>>>  {
>>>>>> @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>>>>>> return -EINVAL;
>>>>>> }
>>>>>>
>>>>>> +   if (!planes_have_format(dev, r->pixel_format)) {
>>>>>> +   struct drm_format_name_buf format_name;
>>>>>> +
>>>>>> +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
>>>>>> + drm_get_format_name(r->pixel_format,
>>>>>> + _name));
>>>>>> +   return -EINVAL;
>>>>>> +   }
>>>>>> +
>>>>>
>>>>> Won't this break KMS on things like the radeon driver, which doesn't do
>>>>> planes?  Maybe check if any universal planes have been registered and
>>>>> only do the check in that case?
>>>>
>>>> Hmm. I thought we add the implicit planes always. Apparently
>>>> drm_crtc_init() adds a primary with X/ARGB, but no more. So
>>>> this would break all other formats, which is probably a bit too
>>>> aggressive.
>>>>
>>>> I guess I could just skip the check in case any plane has
>>>> plane->format_default set. That should be indicating that the driver
>>>> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
>>>> Harry?
>>>
>>> Probably leftover from DC bringup?
>>
>> I'm not sure if I'm following. Which flag are we talking about?
>>
>> Is the concern the DC driver or amdgpu with DC (or radeon)?
>>
>> DC does not call drm_crtc_init(). It initializes universal planes in 
>> amdgpu_dm_initialize_drm_device() -> amdgpu_dm_plane_init().
>>
>> From a quick glance this patch looks fine by me.
> 
> From amdgpu_dm_plane_init:
> 
>   aplane->base.format_default = true;
> ^^ this is entirely bogus, pls remove.
> 

Makes sense. At one point we had a comment "for legacy code o

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Harry Wentland]

On 2018-03-06 02:51 AM, Daniel Vetter wrote:
> On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote:
>> On 2018-02-22 04:42 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>
>>> The documentation for the ctm matrix suggests a two's complement
>>> format, but at least the i915 implementation is using sign-magnitude
>>> instead. And looks like malidp is doing the same. Change the docs
>>> to match the current implementation, and change the type from __s64
>>> to __u64 to drive the point home.
>>>
>>> Cc: dri-de...@lists.freedesktop.org
>>> Cc: Mihail Atanassov <mihail.atanas...@arm.com>
>>> Cc: Liviu Dudau <liviu.du...@arm.com>
>>> Cc: Brian Starkey <brian.star...@arm.com>
>>> Cc: Mali DP Maintainers <mal...@foss.arm.com>
>>> Cc: Johnson Lin <johnson@intel.com>
>>> Cc: Uma Shankar <uma.shan...@intel.com>
>>> Cc: Shashank Sharma <shashank.sha...@intel.com>
>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>
>> Good clarification. Our new CTM implementation (1) actually assumed
>> two's complement but nobody's using it yet, so we'll patch it to
>> convert.
> 
> Another reason to start looking into igt and the tests there? That would
> have caught this too ...

There need to be new IGT tests that can actually test for signed-magnitude vs 
two's compliment differences, which would have to be tests of the CTM in some 
non-RGB colorspace where negative numbers are actually meaningful. The existing 
tests will test a negative matrix but in RGB colorspace any negative number 
will simply map to zero/black, no matter the magnitude.

I'll put such a test on our team's backlog but not sure when we'll actually get 
to it. We'd have to check if we could have a meaningful test for this with the 
current capabilities of DC.

Harry

> -Daniel
> 
>>
>> Reviewed-by: Harry Wentland <harry.wentl...@amd.com>
>>
>> (1) https://patchwork.freedesktop.org/patch/204005/
>>
>> Harry
>>
>>> ---
>>>  include/uapi/drm/drm_mode.h | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 2c575794fb52..b5d7d9e0eff5 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
>>>  };
>>>  
>>>  struct drm_color_ctm {
>>> -   /* Conversion matrix in S31.32 format. */
>>> -   __s64 matrix[9];
>>> +   /*
>>> +* Conversion matrix in S31.32 sign-magnitude
>>> +* (not two's complement!) format.
>>> +*/
>>> +   __u64 matrix[9];
>>>  };
>>>  
>>>  struct drm_color_lut {
>>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Harry Wentland]

On 2018-03-05 04:33 PM, Alex Deucher wrote:
> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
>  wrote:
>> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>>> Ville Syrjala  writes:
>>>
 From: Ville Syrjälä 

 To make life easier for drivers, let's have the core check that the
 requested pixel format is supported by at least one plane when creating
 a new framebuffer.

 Signed-off-by: Ville Syrjälä 
 ---
  drivers/gpu/drm/drm_framebuffer.c | 26 ++
  1 file changed, 26 insertions(+)

 diff --git a/drivers/gpu/drm/drm_framebuffer.c 
 b/drivers/gpu/drm/drm_framebuffer.c
 index c0530a1af5e3..155b21e579c4 100644
 --- a/drivers/gpu/drm/drm_framebuffer.c
 +++ b/drivers/gpu/drm/drm_framebuffer.c
 @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
 return DIV_ROUND_UP(height, format->vsub);
  }

 +static bool planes_have_format(struct drm_device *dev, u32 format)
 +{
 +   struct drm_plane *plane;
 +
 +   /* TODO: maybe maintain a device level format list? */
 +   drm_for_each_plane(plane, dev) {
 +   int i;
 +
 +   for (i = 0; i < plane->format_count; i++) {
 +   if (plane->format_types[i] == format)
 +   return true;
 +   }
 +   }
 +
 +   return false;
 +}
 +
  static int framebuffer_check(struct drm_device *dev,
  const struct drm_mode_fb_cmd2 *r)
  {
 @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
 return -EINVAL;
 }

 +   if (!planes_have_format(dev, r->pixel_format)) {
 +   struct drm_format_name_buf format_name;
 +
 +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
 + drm_get_format_name(r->pixel_format,
 + _name));
 +   return -EINVAL;
 +   }
 +
>>>
>>> Won't this break KMS on things like the radeon driver, which doesn't do
>>> planes?  Maybe check if any universal planes have been registered and
>>> only do the check in that case?
>>
>> Hmm. I thought we add the implicit planes always. Apparently
>> drm_crtc_init() adds a primary with X/ARGB, but no more. So
>> this would break all other formats, which is probably a bit too
>> aggressive.
>>
>> I guess I could just skip the check in case any plane has
>> plane->format_default set. That should be indicating that the driver
>> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
>> Harry?
> 
> Probably leftover from DC bringup?

I'm not sure if I'm following. Which flag are we talking about?

Is the concern the DC driver or amdgpu with DC (or radeon)?

DC does not call drm_crtc_init(). It initializes universal planes in 
amdgpu_dm_initialize_drm_device() -> amdgpu_dm_plane_init().

From a quick glance this patch looks fine by me.

Harry

> 
> Alex
> 
>>
>>>
>>> Also, "any_planes_have_format()" might be slightly more descriptive.
>>
>> Or any_plane_has_format()? Is that more englishy? :)
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Harry Wentland]

On 2018-02-22 04:42 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> The documentation for the ctm matrix suggests a two's complement
> format, but at least the i915 implementation is using sign-magnitude
> instead. And looks like malidp is doing the same. Change the docs
> to match the current implementation, and change the type from __s64
> to __u64 to drive the point home.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Mihail Atanassov <mihail.atanas...@arm.com>
> Cc: Liviu Dudau <liviu.du...@arm.com>
> Cc: Brian Starkey <brian.star...@arm.com>
> Cc: Mali DP Maintainers <mal...@foss.arm.com>
> Cc: Johnson Lin <johnson@intel.com>
> Cc: Uma Shankar <uma.shan...@intel.com>
> Cc: Shashank Sharma <shashank.sha...@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>

Good clarification. Our new CTM implementation (1) actually assumed two's 
complement but nobody's using it yet, so we'll patch it to convert.

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

(1) https://patchwork.freedesktop.org/patch/204005/

Harry

> ---
>  include/uapi/drm/drm_mode.h | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 2c575794fb52..b5d7d9e0eff5 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
>  };
>  
>  struct drm_color_ctm {
> - /* Conversion matrix in S31.32 format. */
> - __s64 matrix[9];
> + /*
> +  * Conversion matrix in S31.32 sign-magnitude
> +  * (not two's complement!) format.
> +  */
> + __u64 matrix[9];
>  };
>  
>  struct drm_color_lut {
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

[Harry Wentland]

On 2018-02-21 01:36 PM, Daniel Vetter wrote:
> On Wed, Feb 21, 2018 at 04:23:31PM +0100, Maarten Lankhorst wrote:
>> After we acquired all generic modeset locks in drm_modeset_lock_all, it's
>> unsafe acquire any other so just mark acquisition as done.
>>
>> Atomic drivers shouldn't use drm_modeset_lock_all.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> 
> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> 
> Also, I'm pretty much expecting to regret this like all the other
> ww_acquire_done patches I've acked, but where's the fun in not trying :-)
> 

This shouldn't really hurt anything, other than throw DEBUG warnings if 
DEBUG_MUTEXES is on.

Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> Cheers, Daniel
> 
>> ---
>>  drivers/gpu/drm/drm_modeset_lock.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
>> b/drivers/gpu/drm/drm_modeset_lock.c
>> index 963e23db0fe7..8a5100685875 100644
>> --- a/drivers/gpu/drm/drm_modeset_lock.c
>> +++ b/drivers/gpu/drm/drm_modeset_lock.c
>> @@ -113,6 +113,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
>>  kfree(ctx);
>>  return;
>>  }
>> +ww_acquire_done(>ww_ctx);
>>  
>>  WARN_ON(config->acquire_ctx);
>>  
>> -- 
>> 2.16.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/8] drm/atomic: Include color encoding/range in plane state dump

[Harry Wentland]

On 2018-02-19 03:28 PM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> Include color_enconding and color_range in the plane state dump.
> 
> v2: Add kerneldoc (danvet)
> 
> Cc: Harry Wentland <harry.wentl...@amd.com>
> Cc: Daniel Vetter <dan...@ffwll.ch>
> Cc: Daniel Stone <dan...@fooishbar.org>
> Cc: Russell King - ARM Linux <li...@armlinux.org.uk>
> Cc: Ilia Mirkin <imir...@alum.mit.edu>
> Cc: Hans Verkuil <hverk...@xs4all.nl>
> Cc: Uma Shankar <uma.shan...@intel.com>
> Cc: Shashank Sharma <shashank.sha...@intel.com>
> Cc: Jyri Sarha <jsa...@ti.com>
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>

Latest patches for 1-3 are
Acked-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c|  4 
>  drivers/gpu/drm/drm_color_mgmt.c| 30 ++
>  drivers/gpu/drm/drm_crtc_internal.h |  2 ++
>  3 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 452a0b0bafbc..9552052ed31a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -952,6 +952,10 @@ static void drm_atomic_plane_print_state(struct 
> drm_printer *p,
>   drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
>   drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
>   drm_printf(p, "\trotation=%x\n", state->rotation);
> + drm_printf(p, "\tcolor-encoding=%s\n",
> +drm_get_color_encoding_name(state->color_encoding));
> + drm_printf(p, "\tcolor-range=%s\n",
> +drm_get_color_range_name(state->color_range));
>  
>   if (plane->funcs->atomic_print_state)
>   plane->funcs->atomic_print_state(p, state);
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 7b0f1c2d9190..a11a838741c2 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -367,6 +367,36 @@ static const char * const color_range_name[] = {
>  };
>  
>  /**
> + * drm_get_color_encoding_name - return a string for color encoding
> + * @encoding: color encoding 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_color_encoding_name(enum drm_color_encoding encoding)
> +{
> + if (WARN_ON(encoding >= ARRAY_SIZE(color_encoding_name)))
> + return "unknown";
> +
> + return color_encoding_name[encoding];
> +}
> +
> +/**
> + * drm_get_color_range_name - return a string for color range
> + * @range: color range 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_color_range_name(enum drm_color_range range)
> +{
> + if (WARN_ON(range >= ARRAY_SIZE(color_range_name)))
> + return "unknown";
> +
> + return color_range_name[range];
> +}
> +
> +/**
>   * drm_plane_create_color_properties - color encoding related plane 
> properties
>   * @plane: plane object
>   * @supported_encodings: bitfield indicating supported color encodings
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index af00f42ba269..8ca2ffef6231 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -71,6 +71,8 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
>   void *data, struct drm_file *file_priv);
>  
>  /* drm_color_mgmt.c */
> +const char *drm_get_color_encoding_name(enum drm_color_encoding encoding);
> +const char *drm_get_color_range_name(enum drm_color_range range);
>  
>  /* IOCTLs */
>  int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Harry Wentland]

On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this down
> to u32 either fixes a potential problem or serves to add clarity in case
> the typecasting was implicitly done.
> 
> Cc: Keith Packard <kei...@keithp.com>
> Cc: Alex Deucher <alexander.deuc...@amd.com>
> Cc: Harry Wentland <harry.wentl...@amd.com>
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 38d47559f098..c2fa5d55f04e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
>   amdgpu_bo_unreserve(new_abo);
>  
>   work->base = base;
> - work->target_vblank = target - drm_crtc_vblank_count(crtc) +
> + work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
>  
>   /* we borrow the event spin lock for protecting flip_wrok */
> 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 1ce4c98385e3..b7254a29b34a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>  
>  
>   /* Prepare wait for target vblank early - before the fence-waits */
> - target_vblank = target - drm_crtc_vblank_count(crtc) +
> + target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(crtc->dev, 
> acrtc->crtc_id);
>  
>   /* TODO This might fail and hence better not used, wait
> @@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   amdgpu_dm_do_flip(
>   crtc,
>   fb,
> - drm_crtc_vblank_count(crtc) + *wait_for_vblank,
> + (uint32_t)drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
>   dm_state->context);
>   }
>  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Harry Wentland]

On 2018-02-01 05:30 AM, Maarten Lankhorst wrote:
> Op 31-01-18 om 20:57 schreef Harry Wentland:
>> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
>>> Op 29-01-18 om 16:41 schreef Leo Li:
>>>> Updated IGT results seem sane:
>>>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>>>>
>>>> Would someone be able to apply this patch?
>>>>
>>> Thanks for the reminder, pushed.
>>>
>> Thanks, Maarten. I see it in drm-misc-next.
>>
>> Would someone be able to pull this into drm-misc-fixes as well, or can I 
>> just I apply this myself with the following dim commands?
>>
>> dim checkout drm-misc-fixes
>> dim cherry-pick 1c6c6ebb
>> dim push-branch
> My bad, pushed to the right branch. :)
> 

Thanks, Maarten.

Harry
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Harry Wentland]

On 2018-01-30 05:28 AM, Maarten Lankhorst wrote:
> Op 29-01-18 om 16:41 schreef Leo Li:
>> Updated IGT results seem sane:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
>>
>> Would someone be able to apply this patch?
>>
> Thanks for the reminder, pushed.
> 

Thanks, Maarten. I see it in drm-misc-next.

Would someone be able to pull this into drm-misc-fixes as well, or can I just I 
apply this myself with the following dim commands?

dim checkout drm-misc-fixes
dim cherry-pick 1c6c6ebb
dim push-branch

Harry


> ~Maarten
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Harry Wentland]

On 2018-01-25 08:30 AM, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> 
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix the problem.
> 
> For connectors the issue is a bit more complicated as they can
> be created/destroyed at runtime due to MST. So the problem is no
> longer a purely theoretical programmer error. As the connector
> indexes are allocated via ida, we can simply limit the maximum
> value the ida is allowed to hand out. The error handling is already
> in place.
> 
> v2: Return an error to the caller (Harry)
> v3: Print a debug message so that we know what happened (Maarten)
> 
> Cc: Harry Wentland <harry.wentl...@amd.com>
> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_connector.c | 9 +++--
>  drivers/gpu/drm/drm_crtc.c  | 4 
>  drivers/gpu/drm/drm_encoder.c   | 4 
>  drivers/gpu/drm/drm_plane.c | 4 
>  4 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a7749709d..16b9c3810af2 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -205,9 +205,14 @@ int drm_connector_init(struct drm_device *dev,
>   connector->dev = dev;
>   connector->funcs = funcs;
>  
> - ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
> - if (ret < 0)
> + /* connector index is used with 32bit bitmasks */
> + ret = ida_simple_get(>connector_ida, 0, 32, GFP_KERNEL);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
> +   drm_connector_enum_list[connector_type].name,
> +   ret);
>   goto out_put;
> + }
>   connector->index = ret;
>   ret = 0;
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..5b4be382a1d7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
>   WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
>  
> + /* crtc index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_crtc >= 32))
> + return -EINVAL;
> +
>   crtc->dev = dev;
>   crtc->funcs = funcs;
>  
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 59e0ebe733f8..273e1c59c54a 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
>  {
>   int ret;
>  
> + /* encoder index is used with 32bit bitmasks */
> + if (WARN_ON(dev->mode_config.num_encoder >= 32))
> + return -EINVAL;
> +
>   ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_ENCODER);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..22b54663b6e7 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   unsigned int format_modifier_count = 0;
>   int ret;
>  
> + /* plane index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_total_plane >= 32))
> + return -EINVAL;
> +
>   ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_PLANE);
>   if (ret)
>   return ret;
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Harry Wentland]

On 2018-01-24 04:24 PM, Ville Syrjälä wrote:
> On Wed, Jan 24, 2018 at 04:01:18PM -0500, Harry Wentland wrote:
>> On 2018-01-24 01:37 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>
>>> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
>>> Naturally we can only do that if the index of those objects stays
>>> below 32. Issue a warning whenever we exceed that limit, hopefully
>>> prompting someone to fix the problem.
>>>
>>> Or should we just outright fail the object initializatio perhaps?
>>>
>>
>> This would make sense in my opinion. index >= 32 looks like it would lead to 
>> completely undefined behavior when trying to attach objects to each other.
> 
> I suppose. The counter argument is that this is basically the developer
> shooting themselves in the foot intentionally, so it's a bit hard to
> justify complicating the runtime error handling for this.
> 

True, if this needs extensive runtime error handling a WARN_ON is probably 
better.

> The connector case might be well justified though since the index there
> comes from ida, and with MST connectors can come and go as they please.
> So it might not be entirely impossible to overflow the bits there.
> 

Right, I was trying to think of a real-life case where this might happen. MST 
is a good one (although still quite rare in the vast majority of cases).

Harry

>>
>> Harry
>>
>>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 3 +++
>>>  drivers/gpu/drm/drm_crtc.c  | 3 +++
>>>  drivers/gpu/drm/drm_encoder.c   | 3 +++
>>>  drivers/gpu/drm/drm_plane.c | 3 +++
>>>  4 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index b85a7749709d..9278a81c5d54 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
>>> connector->index = ret;
>>> ret = 0;
>>>  
>>> +   /* we have 32bit connector bitmasks */
>>> +   WARN_ON(connector->index >= 32);
>>> +
>>> connector->connector_type = connector_type;
>>> connector->connector_type_id =
>>> ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index f0556e654116..e27ffa3561af 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
>>> struct drm_crtc *crtc,
>>> list_add_tail(>head, >crtc_list);
>>> crtc->index = config->num_crtc++;
>>>  
>>> +   /* we have 32bit crtc bitmasks */
>>> +   WARN_ON(crtc->index >= 32);
>>> +
>>> crtc->primary = primary;
>>> crtc->cursor = cursor;
>>> if (primary && !primary->possible_crtcs)
>>> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
>>> index 59e0ebe733f8..66d0cdd217fa 100644
>>> --- a/drivers/gpu/drm/drm_encoder.c
>>> +++ b/drivers/gpu/drm/drm_encoder.c
>>> @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
>>> list_add_tail(>head, >mode_config.encoder_list);
>>> encoder->index = dev->mode_config.num_encoder++;
>>>  
>>> +   /* we have 32bit encoder bitmasks */
>>> +   WARN_ON(encoder->index >= 32);
>>> +
>>>  out_put:
>>> if (ret)
>>> drm_mode_object_unregister(dev, >base);
>>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>>> index 2c90519576a3..0a8d807603c1 100644
>>> --- a/drivers/gpu/drm/drm_plane.c
>>> +++ b/drivers/gpu/drm/drm_plane.c
>>> @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
>>> struct drm_plane *plane,
>>> list_add_tail(>head, >plane_list);
>>> plane->index = config->num_total_plane++;
>>>  
>>> +   /* we have 32bit plane bitmasks */
>>> +   WARN_ON(plane->index >= 32);
>>> +
>>> drm_object_attach_property(>base,
>>>config->plane_type_property,
>>>plane->type);
>>>
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Harry Wentland]

On 2018-01-24 01:37 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix the problem.
> 
> Or should we just outright fail the object initializatio perhaps?
> 

This would make sense in my opinion. index >= 32 looks like it would lead to 
completely undefined behavior when trying to attach objects to each other.

Harry

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_connector.c | 3 +++
>  drivers/gpu/drm/drm_crtc.c  | 3 +++
>  drivers/gpu/drm/drm_encoder.c   | 3 +++
>  drivers/gpu/drm/drm_plane.c | 3 +++
>  4 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a7749709d..9278a81c5d54 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
>   connector->index = ret;
>   ret = 0;
>  
> + /* we have 32bit connector bitmasks */
> + WARN_ON(connector->index >= 32);
> +
>   connector->connector_type = connector_type;
>   connector->connector_type_id =
>   ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..e27ffa3561af 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   list_add_tail(>head, >crtc_list);
>   crtc->index = config->num_crtc++;
>  
> + /* we have 32bit crtc bitmasks */
> + WARN_ON(crtc->index >= 32);
> +
>   crtc->primary = primary;
>   crtc->cursor = cursor;
>   if (primary && !primary->possible_crtcs)
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 59e0ebe733f8..66d0cdd217fa 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
>   list_add_tail(>head, >mode_config.encoder_list);
>   encoder->index = dev->mode_config.num_encoder++;
>  
> + /* we have 32bit encoder bitmasks */
> + WARN_ON(encoder->index >= 32);
> +
>  out_put:
>   if (ret)
>   drm_mode_object_unregister(dev, >base);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..0a8d807603c1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   list_add_tail(>head, >plane_list);
>   plane->index = config->num_total_plane++;
>  
> + /* we have 32bit plane bitmasks */
> + WARN_ON(plane->index >= 32);
> +
>   drm_object_attach_property(>base,
>  config->plane_type_property,
>  plane->type);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

[Harry Wentland]

On 2018-01-22 05:43 PM, Manasi Navare wrote:
> Existing helpers add support upto HBR2. This patch
> adds support for HBR3 rate (8.1 Gbps) introduced as
> part of DP 1.4 specification.
> 
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>

Both patches look right according to DP 1.4 spec.

Series is
Reviewed-by: Harry Wentland <harry.wentl...@amd.com>

Harry

> ---
>  drivers/gpu/drm/drm_dp_helper.c   | 4 
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
>  include/drm/drm_dp_helper.h   | 1 +
>  3 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..ffe14ec 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -146,6 +146,8 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate)
>   return DP_LINK_BW_2_7;
>   case 54:
>   return DP_LINK_BW_5_4;
> + case 81:
> + return DP_LINK_BW_8_1;
>   }
>  }
>  EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
> @@ -161,6 +163,8 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>   return 27;
>   case DP_LINK_BW_5_4:
>   return 54;
> + case DP_LINK_BW_8_1:
> + return 81;
>   }
>  }
>  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa5..36df7df 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2087,6 +2087,9 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
>   case DP_LINK_BW_5_4:
>   *out = 10 * dp_link_count;
>   break;
> + case DP_LINK_BW_8_1:
> + *out = 15 * dp_link_count;
> + break;
>   }
>   return true;
>  }
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 9d3ce3b..c80fa92 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -334,6 +334,7 @@
>  # define DP_LINK_BW_1_62 0x06
>  # define DP_LINK_BW_2_7  0x0a
>  # define DP_LINK_BW_5_4  0x14/* 1.2 */
> +# define DP_LINK_BW_8_1  0x1e/* 1.4 */
>  
>  #define DP_LANE_COUNT_SET0x101
>  # define DP_LANE_COUNT_MASK  0x0f
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx