date:20210622

Re: [Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-22 Thread Pekka Paalanen

On Fri, 18 Jun 2021 11:11:08 +0200
Werner Sembach  wrote:

> Add a new general drm property "active color range" which can be used by
> graphic drivers to report the used color range back to userspace.
> 
> There was no way to check which color range got actually used on a given
> monitor. To surely predict this, one must know the exact capabilities of
> the monitor and what the default behaviour of the used driver is. This
> property helps eliminating the guessing at this point.
> 
> In the future, automatic color calibration for screens might also depend on
> this information being available.
> 
> Signed-off-by: Werner Sembach 
> ---
>  drivers/gpu/drm/drm_connector.c | 59 +
>  include/drm/drm_connector.h | 27 +++
>  2 files changed, 86 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 684d7abdf0eb..818de58d972f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
> drm_active_color_format_enum_list[] = {
>   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>  };
>  
> +static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
> + { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
> + { DRM_MODE_COLOR_RANGE_FULL, "Full" },
> + { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },

Doesn't "limited" mean different numbers on RGB vs. Y vs. CbCr? I have
a vague recollection that at least one of them was different from the
others.

Documenting DRM_MODE_COLOR_RANGE_UNSET as "unspecified/default" while
the string for it is "Unknown" seems inconsistent to me. I would
recommend to avoid the word "default" because "reset to defaults" might
become a thing one day, and that probably is not the same default as
here.

Is there actually a case for "unknown"? How can it be not known? Or
does it mean "not applicable"?

Otherwise looks good to me.


Thanks,
pq


> +};
> +
>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>drm_dp_subconnector_enum_list)
>  
> @@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list 
> dp_colorspaces[] = {
>   *   drm_connector_attach_active_color_format_property() to install this
>   *   property.
>   *
> + * active color range:
> + *   This read-only property tells userspace the color range actually used by
> + *   the hardware display engine on "the cable" on a connector. The chosen
> + *   value depends on hardware capabilities of the monitor and the used color
> + *   format. Drivers shall use
> + *   drm_connector_attach_active_color_range_property() to install this
> + *   property.
> + *
>   * Connectors also have one standardized atomic property:
>   *
>   * CRTC_ID:
> @@ -2264,6 +2278,51 @@ void 
> drm_connector_set_active_color_format_property(struct drm_connector *connec
>  }
>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>  
> +/**
> + * drm_connector_attach_active_color_range_property - attach "active color 
> range" property
> + * @connector: connector to attach active color range property on.
> + *
> + * This is used to check the applied color range on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_color_range_property(struct drm_connector 
> *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + if (!connector->active_color_range_property) {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
> "active color range",
> + 
> drm_active_color_range_enum_list,
> + 
> ARRAY_SIZE(drm_active_color_range_enum_list));
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->active_color_range_property = prop;
> + drm_object_attach_property(&connector->base, prop, 
> DRM_MODE_COLOR_RANGE_UNSET);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
> +
> +/**
> + * drm_connector_set_active_color_range_property - sets the active color 
> range property for a
> + * connector
> + * @connector: drm connector
> + * @active_color_range: color range for the connector currently active on 
> "the cable"
> + *
> + * Should be used by atomic drivers to update the active color range over a 
> connector.
> + */
> +void drm_connector_set_active_color_range_property(struct drm_connector 
> *connector,
> +enum drm_mode_color_range 
> active_color_range)
> +{
> + drm_object_property_set_value(&connector->base, 
> connector->active_color_range_property,
> +   active_color_range);
> +}
> +EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
> +
>  /**
>   * drm_connector_attach_hdr_output_metadata_

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-22 Thread Pekka Paalanen

On Fri, 18 Jun 2021 11:11:11 +0200
Werner Sembach  wrote:

> Add a new general drm property "preferred color format" which can be used
> by userspace to tell the graphic drivers to which color format to use.
> 
> Possible options are:
> - auto (default/current behaviour)
> - rgb
> - ycbcr444
> - ycbcr422 (not supported by both amdgpu and i915)
> - 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 deceptible to interference.
> 
> In the future, automatic color calibration for screens might also depend on
> this option being available.
> 
> Signed-off-by: Werner Sembach 
> ---
>  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 | 17 ++
>  4 files changed, 72 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index bc3487964fb5..90d62f305257 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -687,6 +687,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->preferred_color_format !=
> + new_connector_state->preferred_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 438e9585b225..c536f5e22016 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>  fence_ptr);
>   } else if (property == connector->max_bpc_property) {
>   state->max_requested_bpc = val;
> + } else if (property == connector->preferred_color_format_property) {
> + state->preferred_color_format = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = 0;
>   } else if (property == connector->max_bpc_property) {
>   *val = state->max_requested_bpc;
> + } else if (property == connector->preferred_color_format_property) {
> + *val = state->preferred_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 818de58d972f..aea03dd02e33 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -889,6 +889,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_preferred_color_format_enum_list[] = {
> + { 0, "auto" },
> + { DRM_COLOR_FORMAT_RGB444, "rgb" },
> + { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
> + { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
> + { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
> +};
> +
>  static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = 
> {
>   { 0, "unknown" },
>   { DRM_COLOR_FORMAT_RGB444, "rgb" },
> @@ -1219,11 +1227,19 @@ static const struct drm_prop_enum_list 
> dp_colorspaces[] = {
>   *   Drivers shall use drm_connector_attach_active_bpc_property() to install
>   *   this property.
>   *
> + * preferred color format:
> + *   This property is used by userspace to change the used color format. When
> + *   used the driver will use the selected format if valid for the hardware,
> + *   sink, and current resolution and refresh rate combination. Drivers to
> + *   use the function drm_connector_attach_preferred_color_format_property()
> + *   to create and attach the property to the connector during
> + *   initialization.
> + *
>   * active color format:
>   *   This read-only property tells userspace the color format actually used
>   *   by the hardware

Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-22 Thread Pekka Paalanen

On Fri, 18 Jun 2021 11:11:14 +0200
Werner Sembach  wrote:

> Add "Broadcast RGB" to general drm context so that more drivers besides
> i915 and gma500 can implement it without duplicating code.
> 
> Userspace can use this property to tell the graphic driver to use full or
> limited color range for a given connector, overwriting the default
> behaviour/automatic detection.
> 
> Possible options are:
> - Automatic (default/current behaviour)
> - Full
> - Limited 16:235
> 
> In theory the driver should be able to automatically detect the monitors
> capabilities, but because of flawed standard implementations in Monitors,
> this might fail. In this case a manual overwrite is required to not have
> washed out colors or lose details in very dark or bright scenes.
> 
> Signed-off-by: Werner Sembach 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>  drivers/gpu/drm/drm_connector.c | 43 +
>  include/drm/drm_connector.h | 16 +++
>  4 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 90d62f305257..0c89d32efbd0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (old_connector_state->preferred_color_format !=
>   new_connector_state->preferred_color_format)
>   new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->preferred_color_range !=
> + new_connector_state->preferred_color_range)
> + 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 c536f5e22016..c589bb1a8163 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->max_requested_bpc = val;
>   } else if (property == connector->preferred_color_format_property) {
>   state->preferred_color_format = val;
> + } else if (property == connector->preferred_color_range_property) {
> + state->preferred_color_range = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->max_requested_bpc;
>   } else if (property == connector->preferred_color_format_property) {
>   *val = state->preferred_color_format;
> + } else if (property == connector->preferred_color_range_property) {
> + *val = state->preferred_color_range;
>   } 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 aea03dd02e33..9bc596638613 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
> drm_active_color_format_enum_list[] = {
>   { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>  };
>  
> +static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] 
> = {
> + { DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
> + { DRM_MODE_COLOR_RANGE_FULL, "Full" },
> + { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },

Hi,

the same question here about these numbers as I asked on the "active
color range" property.

> +};
> +
>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
>   { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>   { DRM_MODE_COLOR_RANGE_FULL, "Full" },
> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list 
> dp_colorspaces[] = {
>   *   drm_connector_attach_active_color_format_property() to install this
>   *   property.
>   *
> + * Broadcast RGB:
> + *   This property is used by userspace to change the used color range. When
> + *   used the driver will use the selected range if valid for the current
> + *   color format. Drivers to use the function
> + *   drm_connector_attach_preferred_color_format_property() to create and
> + *   attach the property to the connector during initialization.

An important detail to document here is: does userspace need to
take care that pixel data at the connector will already match the set
range, or will the driver program the hardware to produce the set range?

If the former, then

Re: [Intel-gfx] [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-22 Thread Pekka Paalanen

On Fri, 18 Jun 2021 11:11:16 +0200
Werner Sembach  wrote:

> This commit implements the "Broadcast RGB" drm property for the AMD GPU
> driver.
> 
> Signed-off-by: Werner Sembach 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 9ffd2f9d3d75..c5dbf948a47a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
>  }
>  
>  static enum dc_color_space
> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
> +enum drm_mode_color_range preferred_color_range)
>  {
>   enum dc_color_space color_space = COLOR_SPACE_SRGB;
>  
> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing 
> *dc_crtc_timing)
>* respectively
>*/
>   if (dc_crtc_timing->pix_clk_100hz > 270300) {
> - if (dc_crtc_timing->flags.Y_ONLY)
> + if (dc_crtc_timing->flags.Y_ONLY
> + || preferred_color_range ==
> + 
> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>   color_space =
>   COLOR_SPACE_YCBCR709_LIMITED;
>   else
>   color_space = COLOR_SPACE_YCBCR709;

Hi,

does this mean that amdgpu would be using a property named "Broadcast
RGB" to control the range of YCbCr too?

That is surprising. If this is truly wanted, then the documentation of
"Broadcast RGB" must say that it applies to YCbCr too.

Does amdgpu do the same as intel wrt. to the question about whose
responsibility it is to make the pixels at the connector to match the
set range?


Thanks,
pq

>   } else {
> - if (dc_crtc_timing->flags.Y_ONLY)
> + if (dc_crtc_timing->flags.Y_ONLY
> + || preferred_color_range ==
> + 
> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>   color_space =
>   COLOR_SPACE_YCBCR601_LIMITED;
>   else
> @@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing 
> *dc_crtc_timing)
>   }
>   break;
>   case PIXEL_ENCODING_RGB:
> - color_space = COLOR_SPACE_SRGB;
> + if (preferred_color_range == 
> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
> + color_space = COLOR_SPACE_SRGB_LIMITED;
> + else
> + color_space = COLOR_SPACE_SRGB;
>   break;
>  
>   default:
> @@ -5429,7 +5437,10 @@ static void 
> fill_stream_properties_from_drm_display_mode(
>  
>   timing_out->aspect_ratio = get_aspect_ratio(mode_in);
>  
> - stream->output_color_space = get_output_color_space(timing_out);
> + stream->output_color_space = get_output_color_space(timing_out,
> + connector_state ?
> + 
> connector_state->preferred_color_range :
> + 
> DRM_MODE_COLOR_RANGE_UNSET);
>  
>   stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>   stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
> @@ -7780,6 +7791,7 @@ void amdgpu_dm_connector_init_helper(struct 
> amdgpu_display_manager *dm,
>   drm_connector_attach_active_bpc_property(&aconnector->base, 8, 
> 16);
>   
> drm_connector_attach_preferred_color_format_property(&aconnector->base);
>   
> drm_connector_attach_active_color_format_property(&aconnector->base);
> + 
> drm_connector_attach_preferred_color_range_property(&aconnector->base);
>   
> drm_connector_attach_active_color_range_property(&aconnector->base);
>   }
>  
> 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 2563788ba95a..80e1389fd0ec 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
> @@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
> *mgr,
>   if (connector->active_color_format_property)
>   
> drm_connector_attach_active_color_format_property(&aconnector->base);
>  
> + connector->preferred_color_range_property = 
> master->base.preferred_color_range_property;
> + if (con

[Intel-gfx] [PATCH] Revert "drm: add a locked version of drm_is_current_master"

2021-06-22 Thread Daniel Vetter

This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.

Unfortunately this inverts the locking hierarchy, so back to the
drawing board. Full lockdep splat below:

==
WARNING: possible circular locking dependency detected
5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted
--
kms_frontbuffer/1087 is trying to acquire lock:
88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: 
drm_is_current_master+0x1b/0x40
but task is already holding lock:
88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
drm_mode_getconnector+0x1c6/0x4a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&dev->mode_config.mutex){+.+.}-{3:3}:
   __mutex_lock+0xab/0x970
   drm_client_modeset_probe+0x22e/0xca0
   __drm_fb_helper_initial_config_and_unlock+0x42/0x540
   intel_fbdev_initial_config+0xf/0x20 [i915]
   async_run_entry_fn+0x28/0x130
   process_one_work+0x26d/0x5c0
   worker_thread+0x37/0x380
   kthread+0x144/0x170
   ret_from_fork+0x1f/0x30
-> #1 (&client->modeset_mutex){+.+.}-{3:3}:
   __mutex_lock+0xab/0x970
   drm_client_modeset_commit_locked+0x1c/0x180
   drm_client_modeset_commit+0x1c/0x40
   __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
   drm_fb_helper_set_par+0x34/0x40
   intel_fbdev_set_par+0x11/0x40 [i915]
   fbcon_init+0x270/0x4f0
   visual_init+0xc6/0x130
   do_bind_con_driver+0x1e5/0x2d0
   do_take_over_console+0x10e/0x180
   do_fbcon_takeover+0x53/0xb0
   register_framebuffer+0x22d/0x310
   __drm_fb_helper_initial_config_and_unlock+0x36c/0x540
   intel_fbdev_initial_config+0xf/0x20 [i915]
   async_run_entry_fn+0x28/0x130
   process_one_work+0x26d/0x5c0
   worker_thread+0x37/0x380
   kthread+0x144/0x170
   ret_from_fork+0x1f/0x30
-> #0 (&dev->master_mutex){+.+.}-{3:3}:
   __lock_acquire+0x151e/0x2590
   lock_acquire+0xd1/0x3d0
   __mutex_lock+0xab/0x970
   drm_is_current_master+0x1b/0x40
   drm_mode_getconnector+0x37e/0x4a0
   drm_ioctl_kernel+0xa8/0xf0
   drm_ioctl+0x1e8/0x390
   __x64_sys_ioctl+0x6a/0xa0
   do_syscall_64+0x39/0xb0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> 
&dev->mode_config.mutex
 Possible unsafe locking scenario:
   CPU0CPU1
   
  lock(&dev->mode_config.mutex);
   lock(&client->modeset_mutex);
   lock(&dev->mode_config.mutex);
  lock(&dev->master_mutex);
*** DEADLOCK ***
1 lock held by kms_frontbuffer/1087:
 #0: 88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
drm_mode_getconnector+0x1c6/0x4a0
stack backtrace:
CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ 
#1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM 
PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
Call Trace:
 dump_stack+0x7f/0xad
 check_noncircular+0x12e/0x150
 __lock_acquire+0x151e/0x2590
 lock_acquire+0xd1/0x3d0
 __mutex_lock+0xab/0x970
 drm_is_current_master+0x1b/0x40
 drm_mode_getconnector+0x37e/0x4a0
 drm_ioctl_kernel+0xa8/0xf0
 drm_ioctl+0x1e8/0x390
 __x64_sys_ioctl+0x6a/0xa0
 do_syscall_64+0x39/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

daniel@phenom:~/linux/drm-misc-fixes$ dim fixes 
1815d9c86e3090477fbde066ff314a7e9721ee0f
Fixes: 1815d9c86e30 ("drm: add a locked version of drm_is_current_master")
Cc: Desmond Cheong Zhi Xi 
Cc: Emil Velikov 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c | 51 ++
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 86d4b72e95cb..232abbba3686 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -61,35 +61,6 @@
  * trusted clients.
  */
 
-static bool drm_is_current_master_locked(struct drm_file *fpriv)
-{
-   lockdep_assert_held_once(&fpriv->master->dev->master_mutex);
-
-   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
-}
-
-/**
- * drm_is_current_master - checks whether @priv is the current master
- * @fpriv: DRM file private
- *
- * Checks whether @fpriv is current master on its device. This decides whether 
a
- * client is allowed to run DRM_MASTER IOCTLs.
- *
- * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
- * - the current master is assumed to own the non-shareable display hardware.
- */
-bool drm_is_current_master(struct drm_file *fpriv)
-{
-   bool ret;
-
-   mutex_lock(&fpriv->master->dev->master_m

Re: [Intel-gfx] [PATCH] Revert "drm: add a locked version of drm_is_current_master"

2021-06-22 Thread Petri Latvala

On Tue, Jun 22, 2021 at 09:54:09AM +0200, Daniel Vetter wrote:
> This reverts commit 1815d9c86e3090477fbde066ff314a7e9721ee0f.
> 
> Unfortunately this inverts the locking hierarchy, so back to the
> drawing board. Full lockdep splat below:
> 
> ==
> WARNING: possible circular locking dependency detected
> 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted
> --
> kms_frontbuffer/1087 is trying to acquire lock:
> 88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: 
> drm_is_current_master+0x1b/0x40
> but task is already holding lock:
> 88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
> drm_mode_getconnector+0x1c6/0x4a0
> which lock already depends on the new lock.
> the existing dependency chain (in reverse order) is:
> -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}:
>__mutex_lock+0xab/0x970
>drm_client_modeset_probe+0x22e/0xca0
>__drm_fb_helper_initial_config_and_unlock+0x42/0x540
>intel_fbdev_initial_config+0xf/0x20 [i915]
>async_run_entry_fn+0x28/0x130
>process_one_work+0x26d/0x5c0
>worker_thread+0x37/0x380
>kthread+0x144/0x170
>ret_from_fork+0x1f/0x30
> -> #1 (&client->modeset_mutex){+.+.}-{3:3}:
>__mutex_lock+0xab/0x970
>drm_client_modeset_commit_locked+0x1c/0x180
>drm_client_modeset_commit+0x1c/0x40
>__drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
>drm_fb_helper_set_par+0x34/0x40
>intel_fbdev_set_par+0x11/0x40 [i915]
>fbcon_init+0x270/0x4f0
>visual_init+0xc6/0x130
>do_bind_con_driver+0x1e5/0x2d0
>do_take_over_console+0x10e/0x180
>do_fbcon_takeover+0x53/0xb0
>register_framebuffer+0x22d/0x310
>__drm_fb_helper_initial_config_and_unlock+0x36c/0x540
>intel_fbdev_initial_config+0xf/0x20 [i915]
>async_run_entry_fn+0x28/0x130
>process_one_work+0x26d/0x5c0
>worker_thread+0x37/0x380
>kthread+0x144/0x170
>ret_from_fork+0x1f/0x30
> -> #0 (&dev->master_mutex){+.+.}-{3:3}:
>__lock_acquire+0x151e/0x2590
>lock_acquire+0xd1/0x3d0
>__mutex_lock+0xab/0x970
>drm_is_current_master+0x1b/0x40
>drm_mode_getconnector+0x37e/0x4a0
>drm_ioctl_kernel+0xa8/0xf0
>drm_ioctl+0x1e8/0x390
>__x64_sys_ioctl+0x6a/0xa0
>do_syscall_64+0x39/0xb0
>entry_SYSCALL_64_after_hwframe+0x44/0xae
> other info that might help us debug this:
> Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> 
> &dev->mode_config.mutex
>  Possible unsafe locking scenario:
>CPU0CPU1
>
>   lock(&dev->mode_config.mutex);
>lock(&client->modeset_mutex);
>lock(&dev->mode_config.mutex);
>   lock(&dev->master_mutex);
> *** DEADLOCK ***
> 1 lock held by kms_frontbuffer/1087:
>  #0: 88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
> drm_mode_getconnector+0x1c6/0x4a0
> stack backtrace:
> CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 
> 5.13.0-rc7-CI-CI_DRM_10254+ #1
> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 
> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
> Call Trace:
>  dump_stack+0x7f/0xad
>  check_noncircular+0x12e/0x150
>  __lock_acquire+0x151e/0x2590
>  lock_acquire+0xd1/0x3d0
>  __mutex_lock+0xab/0x970
>  drm_is_current_master+0x1b/0x40
>  drm_mode_getconnector+0x37e/0x4a0
>  drm_ioctl_kernel+0xa8/0xf0
>  drm_ioctl+0x1e8/0x390
>  __x64_sys_ioctl+0x6a/0xa0
>  do_syscall_64+0x39/0xb0
>  entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> daniel@phenom:~/linux/drm-misc-fixes$ dim fixes 
> 1815d9c86e3090477fbde066ff314a7e9721ee0f
> Fixes: 1815d9c86e30 ("drm: add a locked version of drm_is_current_master")
> Cc: Desmond Cheong Zhi Xi 
> Cc: Emil Velikov 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 


You have your "dim fixes" command line in the commit message.

This goes through Intel's CI shortly, if it agrees with this then

Testcase: igt/debugfs_test/read_all_entries
Acked-by: Petri Latvala 


> ---
>  drivers/gpu/drm/drm_auth.c | 51 ++
>  1 file changed, 19 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 86d4b72e95cb..232abbba3686 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -61,35 +61,6 @@
>   * trusted clients.
>   */
>  
> -static bool drm_is_current_master_locked(struct drm_file *fpriv)
> -{
> - lockdep_assert_held_once(&fpriv->master->dev->master_mutex);
> -
> - return fpriv->is_master && drm_lease_owner(fpriv->master) == 
> fpriv->minor->dev->master;
> -}
> -
> -/**
> - * drm_is_curr

[Intel-gfx] [PATCH] drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Jani Nikula

From: Matt Atwood 

intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
use before intel_encoder->type is set. This causes incorrect max source
rate to be used for display 11+. On EHL and JSL, HBR3 is used instead of
HBR2, and on the other affected platforms, HBR2 is used instead of HBR3.

Move intel_dp_set_source_rates() to after intel_encoder->type is
set. Add comment to intel_dp_is_edp() describing unsafe usages. Cleanup
intel_dp_init_connector() while at it.

Note: The same change was originally added as commit 680c45c767f6
("drm/i915/dp: Correctly advertise HBR3 for GEN11+"), but later reverted
due to issues in CI in commit d3913019602e ("Revert "drm/i915/dp:
Correctly advertise HBR3 for GEN11+"").

v2: Alter intel_dp_set_source_rates final position (Ville/Manasi).
Remove outdated comment (Ville).
Slight optimization of control flow in intel_dp_init_connector.
Slight rewording in commit message.

Cc: Uma Shankar 
Signed-off-by: Matt Atwood 
Reviewed-by: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
[Jani: Expand on the commit message.]
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6cc03b9e4321..41130aa4b191 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -100,6 +100,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
  *
  * If a CPU or PCH DP output is attached to an eDP panel, this function
  * will return true, and false otherwise.
+ *
+ * This function is not safe to use prior to encoder type being set.
  */
 bool intel_dp_is_edp(struct intel_dp *intel_dp)
 {
@@ -5301,8 +5303,6 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
 intel_encoder->base.name))
return false;
 
-   intel_dp_set_source_rates(intel_dp);
-
intel_dp->reset_link_params = true;
intel_dp->pps.pps_pipe = INVALID_PIPE;
intel_dp->pps.active_pipe = INVALID_PIPE;
@@ -5318,28 +5318,22 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
 */
drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
type = DRM_MODE_CONNECTOR_eDP;
+   intel_encoder->type = INTEL_OUTPUT_EDP;
+
+   /* eDP only on port B and/or C on vlv/chv */
+   if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
+ IS_CHERRYVIEW(dev_priv)) &&
+   port != PORT_B && port != PORT_C))
+   return false;
} else {
type = DRM_MODE_CONNECTOR_DisplayPort;
}
 
+   intel_dp_set_source_rates(intel_dp);
+
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
 
-   /*
-* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
-* for DP the encoder type can be set by the caller to
-* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
-*/
-   if (type == DRM_MODE_CONNECTOR_eDP)
-   intel_encoder->type = INTEL_OUTPUT_EDP;
-
-   /* eDP only on port B and/or C on vlv/chv */
-   if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
- IS_CHERRYVIEW(dev_priv)) &&
-   intel_dp_is_edp(intel_dp) &&
-   port != PORT_B && port != PORT_C))
-   return false;
-
drm_dbg_kms(&dev_priv->drm,
"Adding %s connector on [ENCODER:%d:%s]\n",
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Jani Nikula


N.b. we need to figure out what the reported TGL CI issues were that
caused this to be reverted originally. Looks like there was no
follow-up?

BR,
Jani.


On Tue, 22 Jun 2021, Jani Nikula  wrote:
> From: Matt Atwood 
>
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> use before intel_encoder->type is set. This causes incorrect max source
> rate to be used for display 11+. On EHL and JSL, HBR3 is used instead of
> HBR2, and on the other affected platforms, HBR2 is used instead of HBR3.
>
> Move intel_dp_set_source_rates() to after intel_encoder->type is
> set. Add comment to intel_dp_is_edp() describing unsafe usages. Cleanup
> intel_dp_init_connector() while at it.
>
> Note: The same change was originally added as commit 680c45c767f6
> ("drm/i915/dp: Correctly advertise HBR3 for GEN11+"), but later reverted
> due to issues in CI in commit d3913019602e ("Revert "drm/i915/dp:
> Correctly advertise HBR3 for GEN11+"").
>
> v2: Alter intel_dp_set_source_rates final position (Ville/Manasi).
> Remove outdated comment (Ville).
> Slight optimization of control flow in intel_dp_init_connector.
> Slight rewording in commit message.
>
> Cc: Uma Shankar 
> Signed-off-by: Matt Atwood 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> [Jani: Expand on the commit message.]
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
>  1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6cc03b9e4321..41130aa4b191 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -100,6 +100,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
>   *
>   * If a CPU or PCH DP output is attached to an eDP panel, this function
>   * will return true, and false otherwise.
> + *
> + * This function is not safe to use prior to encoder type being set.
>   */
>  bool intel_dp_is_edp(struct intel_dp *intel_dp)
>  {
> @@ -5301,8 +5303,6 @@ intel_dp_init_connector(struct intel_digital_port 
> *dig_port,
>intel_encoder->base.name))
>   return false;
>  
> - intel_dp_set_source_rates(intel_dp);
> -
>   intel_dp->reset_link_params = true;
>   intel_dp->pps.pps_pipe = INVALID_PIPE;
>   intel_dp->pps.active_pipe = INVALID_PIPE;
> @@ -5318,28 +5318,22 @@ intel_dp_init_connector(struct intel_digital_port 
> *dig_port,
>*/
>   drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
>   type = DRM_MODE_CONNECTOR_eDP;
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> +   IS_CHERRYVIEW(dev_priv)) &&
> + port != PORT_B && port != PORT_C))
> + return false;
>   } else {
>   type = DRM_MODE_CONNECTOR_DisplayPort;
>   }
>  
> + intel_dp_set_source_rates(intel_dp);
> +
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
>  
> - /*
> -  * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> -  * for DP the encoder type can be set by the caller to
> -  * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> -  */
> - if (type == DRM_MODE_CONNECTOR_eDP)
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> -   IS_CHERRYVIEW(dev_priv)) &&
> - intel_dp_is_edp(intel_dp) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> -
>   drm_dbg_kms(&dev_priv->drm,
>   "Adding %s connector on [ENCODER:%d:%s]\n",
>   type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Shankar, Uma



> -Original Message-
> From: Nikula, Jani 
> Sent: Tuesday, June 22, 2021 1:57 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Atwood, Matthew S
> ; Shankar, Uma ; Ville
> Syrjälä ; Souza, Jose 
> Subject: [PATCH] drm/i915/dp: Fix eDP max rate for display 11+
> 
> From: Matt Atwood 
> 
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to use 
> before
> intel_encoder->type is set. This causes incorrect max source rate to be used 
> for
> display 11+. On EHL and JSL, HBR3 is used instead of HBR2, and on the other
> affected platforms, HBR2 is used instead of HBR3.
> 
> Move intel_dp_set_source_rates() to after intel_encoder->type is set. Add 
> comment
> to intel_dp_is_edp() describing unsafe usages. Cleanup
> intel_dp_init_connector() while at it.
> 
> Note: The same change was originally added as commit 680c45c767f6
> ("drm/i915/dp: Correctly advertise HBR3 for GEN11+"), but later reverted due 
> to
> issues in CI in commit d3913019602e ("Revert "drm/i915/dp:
> Correctly advertise HBR3 for GEN11+"").
> 
> v2: Alter intel_dp_set_source_rates final position (Ville/Manasi).
> Remove outdated comment (Ville).
> Slight optimization of control flow in intel_dp_init_connector.
> Slight rewording in commit message.

Thanks Jani for digging into this.
Change looks good to me.
Reviewed-by: Uma Shankar 

We can go ahead for merge, once we get more details on the regression which was 
identified causing its revert.
A full CI run may help. For me, I don't see any reason it should cause 
regression.

Regards,
Uma Shankar
> Cc: Uma Shankar 
> Signed-off-by: Matt Atwood 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> [Jani: Expand on the commit message.]
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
>  1 file changed, 11 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6cc03b9e4321..41130aa4b191 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -100,6 +100,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
>   *
>   * If a CPU or PCH DP output is attached to an eDP panel, this function
>   * will return true, and false otherwise.
> + *
> + * This function is not safe to use prior to encoder type being set.
>   */
>  bool intel_dp_is_edp(struct intel_dp *intel_dp)  { @@ -5301,8 +5303,6 @@
> intel_dp_init_connector(struct intel_digital_port *dig_port,
>intel_encoder->base.name))
>   return false;
> 
> - intel_dp_set_source_rates(intel_dp);
> -
>   intel_dp->reset_link_params = true;
>   intel_dp->pps.pps_pipe = INVALID_PIPE;
>   intel_dp->pps.active_pipe = INVALID_PIPE; @@ -5318,28 +5318,22 @@
> intel_dp_init_connector(struct intel_digital_port *dig_port,
>*/
>   drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
>   type = DRM_MODE_CONNECTOR_eDP;
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> +   IS_CHERRYVIEW(dev_priv)) &&
> + port != PORT_B && port != PORT_C))
> + return false;
>   } else {
>   type = DRM_MODE_CONNECTOR_DisplayPort;
>   }
> 
> + intel_dp_set_source_rates(intel_dp);
> +
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
> 
> - /*
> -  * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> -  * for DP the encoder type can be set by the caller to
> -  * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> -  */
> - if (type == DRM_MODE_CONNECTOR_eDP)
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> -   IS_CHERRYVIEW(dev_priv)) &&
> - intel_dp_is_edp(intel_dp) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> -
>   drm_dbg_kms(&dev_priv->drm,
>   "Adding %s connector on [ENCODER:%d:%s]\n",
>   type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> --
> 2.20.1

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm: add a locked version of drm_is_current_master"

2021-06-22 Thread Patchwork

== Series Details ==

Series: Revert "drm: add a locked version of drm_is_current_master"
URL   : https://patchwork.freedesktop.org/series/91758/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
44a4f4b18c74 Revert "drm: add a locked version of drm_is_current_master"
-:92: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#92: 
daniel@phenom:~/linux/drm-misc-fixes$ dim fixes 
1815d9c86e3090477fbde066ff314a7e9721ee0f

-:92: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 1815d9c86e30 ("drm: add a locked 
version of drm_is_current_master")'
#92: 
daniel@phenom:~/linux/drm-misc-fixes$ dim fixes 
1815d9c86e3090477fbde066ff314a7e9721ee0f

-:193: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 1 errors, 2 warnings, 0 checks, 81 lines checked


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

Re: [Intel-gfx] [PATCH v4 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property

2021-06-22 Thread Werner Sembach

Am 22.06.21 um 09:29 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:16 +0200
> Werner Sembach  wrote:
>
>> This commit implements the "Broadcast RGB" drm property for the AMD GPU
>> driver.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  4 
>>  2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 9ffd2f9d3d75..c5dbf948a47a 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -5252,7 +5252,8 @@ get_aspect_ratio(const struct drm_display_mode 
>> *mode_in)
>>  }
>>  
>>  static enum dc_color_space
>> -get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
>> +get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
>> +   enum drm_mode_color_range preferred_color_range)
>>  {
>>  enum dc_color_space color_space = COLOR_SPACE_SRGB;
>>  
>> @@ -5267,13 +5268,17 @@ get_output_color_space(const struct dc_crtc_timing 
>> *dc_crtc_timing)
>>   * respectively
>>   */
>>  if (dc_crtc_timing->pix_clk_100hz > 270300) {
>> -if (dc_crtc_timing->flags.Y_ONLY)
>> +if (dc_crtc_timing->flags.Y_ONLY
>> +|| preferred_color_range ==
>> +
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  color_space =
>>  COLOR_SPACE_YCBCR709_LIMITED;
>>  else
>>  color_space = COLOR_SPACE_YCBCR709;
> Hi,
>
> does this mean that amdgpu would be using a property named "Broadcast
> RGB" to control the range of YCbCr too?

Yes, because I avoided creating a new property, but I'm not really happy with 
it either.

Possibility 1: Use "Broadcast RGB" for Y'CbCr too and clarify in documentation
    - still confusing name
    - limited does not mean something a little bit different for Y'CbCr and not 
strictly 16-235:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization
 , but name
of option is given by preexisting property

Possibility 2: Deprecate "Broadcast RGB" and a a more neutral sounding 
"preferred color range", with the more neutral
sounding "limited" option instead of "Limited 16:235"
    - What's the relation between the 2? pq mentioned on the amdgpu gitlab that 
there is a posibility for userspace to
have only the new or the old one shown
    - Alternatively ignore "Broadcast RGB" when "preferred color range" is set 
and have them coexist?

>
> That is surprising. If this is truly wanted, then the documentation of
> "Broadcast RGB" must say that it applies to YCbCr too.
>
> Does amdgpu do the same as intel wrt. to the question about whose
> responsibility it is to make the pixels at the connector to match the
> set range?

I guess the kernel driver does the conversion, but i have to check for both.

For Intel I did not change the behavior of Boradcast RGB, but i think it's not 
clearly specified in the docs where the
conversion happens.

>
>
> Thanks,
> pq
>
>>  } else {
>> -if (dc_crtc_timing->flags.Y_ONLY)
>> +if (dc_crtc_timing->flags.Y_ONLY
>> +|| preferred_color_range ==
>> +
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>>  color_space =
>>  COLOR_SPACE_YCBCR601_LIMITED;
>>  else
>> @@ -5283,7 +5288,10 @@ get_output_color_space(const struct dc_crtc_timing 
>> *dc_crtc_timing)
>>  }
>>  break;
>>  case PIXEL_ENCODING_RGB:
>> -color_space = COLOR_SPACE_SRGB;
>> +if (preferred_color_range == 
>> DRM_MODE_COLOR_RANGE_LIMITED_16_235)
>> +color_space = COLOR_SPACE_SRGB_LIMITED;
>> +else
>> +color_space = COLOR_SPACE_SRGB;
>>  break;
>>  
>>  default:
>> @@ -5429,7 +5437,10 @@ static void 
>> fill_stream_properties_from_drm_display_mode(
>>  
>>  timing_out->aspect_ratio = get_aspect_ratio(mode_in);
>>  
>> -stream->output_color_space = get_output_color_space(timing_out);
>> +stream->output_color_space = get_output_color_space(timing_out,
>> +connector_state ?
>> +
>> connector_state->preferred_color_range :
>> +
>> DRM_MODE_COLOR_RANGE_UNSET);
>>  
>>  stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>>  stream->out_transfer_func->tf = TRANSFER_FUNCTION_SR

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm: add a locked version of drm_is_current_master"

2021-06-22 Thread Patchwork

== Series Details ==

Series: Revert "drm: add a locked version of drm_is_current_master"
URL   : https://patchwork.freedesktop.org/series/91758/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10259 -> Patchwork_20424


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20424:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s3:
- {fi-dg1-1}: NOTRUN -> [FAIL][1] +65 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-dg1-1/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live@gt_lrc:
- {fi-dg1-1}: NOTRUN -> [DMESG-FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-dg1-1/igt@i915_selftest@live@gt_lrc.html

  * igt@kms_addfb_basic@invalid-get-prop:
- {fi-dg1-1}: NOTRUN -> [WARN][3] +6 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-dg1-1/igt@kms_addfb_ba...@invalid-get-prop.html

  * igt@prime_vgem@basic-fence-flip:
- {fi-dg1-1}: NOTRUN -> [SKIP][4] +41 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-dg1-1/igt@prime_v...@basic-fence-flip.html

  
Known issues


  Here are the changes found in Patchwork_20424 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][5] ([fdo#109271]) +49 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@amdgpu/amd_basic@query-info:
- fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +28 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-glk-dsi/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-kbl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +59 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-kbl-guc/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][8] ([fdo#109271]) +27 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html
- fi-kbl-7500u:   NOTRUN -> [SKIP][9] ([fdo#109271]) +28 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-kbl-7500u/igt@amdgpu/amd_ba...@semaphore.html
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#109315]) 
+17 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_basic@userptr:
- fi-cfl-8700k:   NOTRUN -> [SKIP][11] ([fdo#109271]) +26 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-cfl-8700k/igt@amdgpu/amd_ba...@userptr.html

  * igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-icl-y:   NOTRUN -> [SKIP][12] ([fdo#109315]) +17 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-icl-y/igt@amdgpu/amd_cs_...@fork-compute0.html

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> [SKIP][13] ([fdo#109271]) +35 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-ilk-650/igt@amdgpu/amd_cs_...@nop-compute0.html

  * igt@amdgpu/amd_cs_nop@sync-compute0:
- fi-kbl-r:   NOTRUN -> [SKIP][14] ([fdo#109271]) +21 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html
- fi-cml-u2:  NOTRUN -> [SKIP][15] ([fdo#109315]) +17 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-cml-u2/igt@amdgpu/amd_cs_...@sync-compute0.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-cfl-guc: NOTRUN -> [SKIP][16] ([fdo#109271]) +26 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-cfl-guc/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-x1275:   NOTRUN -> [SKIP][17] ([fdo#109271]) +26 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html
- fi-ivb-3770:NOTRUN -> [SKIP][18] ([fdo#109271]) +31 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/fi-ivb-3770/igt@amdgpu/amd_pr...@amd-to-i915.html

  * igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m:   NOTRUN -> [SKIP][19] ([fdo#109271]) +37 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-ti

[Intel-gfx] [PATCH v7 0/3] drm/i915: Move system memory to TTM for discrete

2021-06-22 Thread Thomas Hellström

Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.

Patch 2 deals with updating the i915 gem bookkeeping after a TTM move,
Patch 3 moves system over from shmem to TTM for discrete

Note that the mock device doesn't consider itself discrete so the TTM
system path is not checked by the mock selftests.

v2:
- Style fixes (reported by Matthew Auld)
- Drop the last patch (migration) It needs selftests and some additional work.
- Unconditionally add VM_IO at mmap time.

v3:
- More style fixes (reported by Matthew Auld)
- Don't overfill the busy placement vector (reported by Matthew Auld)

v4:
- Remove confusion around shrinkable objects (reported by Matthew Auld)

v5:
- Remove confusion around shrinkable objects again, but this time in the
  correct patch. (reported by Matthew Auld)

v6:
- One patch already committed.
- Introduce a __i915_gem_object_is_lmem() to be used in situations where we
  know that a fence that can't currently signal keeps the object from being
  migrated or evicted.
- Rebase on accelerated TTM moves
- Fix TODO:s for supporting system memory with TTM.
- Update the object GEM region after a TTM move if compatible.
- Move a couple of warnings for shmem on DGFX.

v7:
- Just updated a commit message with version history under dashes.

Thomas Hellström (3):
  drm/i915: Update object placement flags to be mutable
  drm/i915/ttm: Adjust gem flags and caching settings after a move
  drm/i915/ttm: Use TTM for system memory

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  |  22 ++
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |   2 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  12 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  38 
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  14 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 194 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   5 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|   3 +-
 drivers/gpu/drm/i915/i915_drv.h   |   3 -
 drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   7 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   8 +
 20 files changed, 265 insertions(+), 95 deletions(-)

-- 
2.31.1

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

[Intel-gfx] [PATCH v7 2/3] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-22 Thread Thomas Hellström

After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v6:
- Rebase on accelerated ttm moves.
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 143 ++--
 1 file changed, 107 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index b5dd3b7037f4..966b292d07da 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -91,6 +91,26 @@ static int i915_ttm_err_to_gem(int err)
return err;
 }
 
+static bool gpu_binds_iomem(struct ttm_resource *mem)
+{
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
+static bool cpu_maps_iomem(struct ttm_resource *mem)
+{
+   /* Once / if we support GGTT, this is also false for cached ttm_tts */
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
+static enum i915_cache_level
+i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
+struct ttm_tt *ttm)
+{
+   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) && !gpu_binds_iomem(res) &&
+   ttm->caching == ttm_cached) ? I915_CACHE_LLC :
+   I915_CACHE_NONE;
+}
+
 static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
 
 static enum ttm_caching
@@ -248,6 +268,35 @@ static void i915_ttm_free_cached_io_st(struct 
drm_i915_gem_object *obj)
obj->ttm.cached_io_st = NULL;
 }
 
+static void
+i915_ttm_adjust_domains_after_move(struct drm_i915_gem_object *obj)
+{
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+
+   if (cpu_maps_iomem(bo->resource) || bo->ttm->caching != ttm_cached) {
+   obj->write_domain = I915_GEM_DOMAIN_WC;
+   obj->read_domains = I915_GEM_DOMAIN_WC;
+   } else {
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   }
+}
+
+static void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj)
+{
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   unsigned int cache_level;
+
+   obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
+
+   obj->mem_flags |= cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
+
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
+  bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+}
+
 static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
@@ -263,8 +312,10 @@ static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 
/* TTM's purge interface. Note that we might be reentering. */
ret = ttm_bo_validate(bo, &place, &ctx);
-
if (!ret) {
+   obj->write_domain = 0;
+   obj->read_domains = 0;
+   i915_ttm_adjust_gem_after_move(obj);
i915_ttm_free_cached_io_st(obj);
obj->mm.madv = __I915_MADV_PURGED;
}
@@ -347,12 +398,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 struct ttm_resource *res)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
-   struct ttm_resource_manager *man =
-   ttm_manager_type(bo->bdev, res->mem_type);
 
-   if (man->use_tt)
+   if (!gpu_binds_iomem(res))
return i915_ttm_tt_get_st(bo->ttm);
 
+   /*
+* If CPU mapping differs, we need to add the ttm_tt pages to
+* the resulting st. Might make sense for GGTT.
+*/
+   GEM_WARN_ON(!cpu_maps_iomem(res));
return intel_region_ttm_resource_to_st(obj->mm.region, res);
 }
 
@@ -367,23 +421,25 @@ static int i915_ttm_accel_move(struct ttm_buffer_object 
*bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct sg_table *src_st;
struct i915_request *rq;
+   struct ttm_tt *ttm = bo->ttm;
+   enum i915_cache_level src_level, dst_level;
int ret;
 
if (!i915->gt.migrate.context)
return -EINVAL;
 
-   if (!bo->ttm || !ttm_tt_is_populated(bo->ttm)) {
+   dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
+   if (!ttm || !ttm_tt_is_populated(ttm)) {
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
 
-   if (bo->ttm &&
-

[Intel-gfx] [PATCH v7 1/3] drm/i915: Update object placement flags to be mutable

2021-06-22 Thread Thomas Hellström

The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. The flags
will change during migration under the object lock.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
  and TTM. Since the bo might be migrated while the VMA is still alive,
  there is no sense, whether or not it maps iomem might change.
v6:
- Introduce a __i915_gem_object_is_lmem() to be used in situations where we
  know that a fence that can't currently signal keeps the object from being
  migrated or evicted.
- Move a couple of shmem warnings for DGFX to a later patch where we
  actually move system memory to TTM.
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 22 +++
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |  2 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 12 +++---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 38 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 14 ++-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  7 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |  4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  5 +--
 .../drm/i915/gem/selftests/i915_gem_mman.c|  4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|  3 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 17 files changed, 101 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..13b217f75055 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -177,8 +177,8 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
return ERR_PTR(-ENOMEM);
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
-   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class,
-I915_BO_ALLOC_STRUCT_PAGE);
+   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class, 
0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
 
/*
 * Mark the object as volatile, such that the pages are marked as
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index d539dffa1554..41d5182cd367 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -71,6 +71,28 @@ bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
  mr->type == INTEL_MEMORY_STOLEN_LOCAL);
 }
 
+/**
+ * __i915_gem_object_is_lmem - Whether the object is resident in
+ * lmem while in the fence signaling critical path.
+ * @obj: The object to check.
+ *
+ * This function is intended to be called from within the fence signaling
+ * path where the fence keeps the object from being migrated. For example
+ * during gpu reset or similar.
+ *
+ * Return: Whether the object is resident in lmem.
+ */
+bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
+{
+   struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+#ifdef CONFIG_LOCKDEP
+   GEM_WARN_ON(dma_resv_test_signaled(obj->base.resv, true));
+#endif
+   return mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
+}
+
 struct drm_i915_gem_object *
 i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index ea76fd11ccb0..27a611deba47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -21,6 +21,8 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
 
 bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
 
+bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
+
 struct drm_i915_gem_object *
 i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2fd155742bd2..6497a2dbdab9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -684,7 +684,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i91

[Intel-gfx] [PATCH v7 3/3] drm/i915/ttm: Use TTM for system memory

2021-06-22 Thread Thomas Hellström

For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very elaborate shrinker for that memory.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
v6:
- Fix TODO:s for supporting system memory with TTM.
- Update the object GEM region after a TTM move if compatible.
- Add a couple of warnings for shmem on DGFX.
---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 51 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 --
 drivers/gpu/drm/i915/intel_memory_region.c |  7 ++-
 drivers/gpu/drm/i915/intel_memory_region.h |  8 
 5 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 7aa1c95c7b7d..3648ae1d6628 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -284,6 +284,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
bool needs_clflush)
 {
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
 
if (obj->mm.madv == I915_MADV_DONTNEED)
obj->mm.dirty = false;
@@ -302,6 +303,7 @@ void i915_gem_object_put_pages_shmem(struct 
drm_i915_gem_object *obj, struct sg_
struct pagevec pvec;
struct page *page;
 
+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
__i915_gem_object_release_shmem(obj, pages, true);
 
i915_gem_gtt_finish_pages(obj, pages);
@@ -560,6 +562,7 @@ i915_gem_object_create_shmem_from_data(struct 
drm_i915_private *dev_priv,
resource_size_t offset;
int err;
 
+   GEM_WARN_ON(IS_DGFX(dev_priv));
obj = i915_gem_object_create_shmem(dev_priv, round_up(size, PAGE_SIZE));
if (IS_ERR(obj))
return obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 966b292d07da..07097f150065 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -286,6 +286,25 @@ static void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
unsigned int cache_level;
+   unsigned int i;
+
+   /*
+* If object was moved to an allowable region, update the object
+* region to consider it migrated. Note that if it's currently not
+* in an allowable region, it's evicted and we don't update the
+* object region.
+*/
+   if (intel_region_to_ttm_type(obj->mm.region) != bo->resource->mem_type) 
{
+   for (i = 0; i < obj->mm.n_placements; ++i) {
+   struct intel_memory_region *mr = obj->mm.placements[i];
+
+   if (intel_region_to_ttm_type(mr) == 
bo->resource->mem_type &&
+   mr != obj->mm.region) {
+   intel_memory_region_put(obj->mm.region);
+   obj->mm.region = intel_memory_region_get(mr);
+   }
+   }
+   }
 
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
 
@@ -615,13 +634,6 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
*obj)
/* Move to the requested placement. */
i915_ttm_placement_from_obj(obj, &requested, busy, &placement);
 
-   /*
-* For now we support LMEM only with TTM.
-* TODO: Remove with system support
-*/
-   GEM_BUG_ON(requested.mem_type < I915_PL_LMEM0 ||
-  busy[0].mem_type < I915_PL_LMEM0);
-
/* First try only the requested placement. No eviction. */
real_num_busy = fetch_and_zero(&placement.num_busy_placement);
ret = ttm_bo_validate(bo, &placement, &ctx);
@@ -635,9 +647,6 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
*obj)
ret == -EAGAIN)
return ret;
 
-   /* TODO: Remove this when we support system as TTM. */
-   real_num_busy = 1;
-
/*
 * If the initial attempt fails, allow all accepted placements,
 * evicting if necessary.
@@ -872,3 +881,25 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 
return 0;
 }
+
+static const struct intel_memory_region_ops ttm_system_region_ops = {
+   .init_object = __i915_gem_ttm_object_init,
+};
+
+struct intel_memory_region *
+i915_gem_ttm_system_setup(struct drm_i915_private *i915,
+ u16 type, u16 instance)

[Intel-gfx] [PATCH V4] drm/i915/gen11: Disable cursor clock gating in HDR mode

2021-06-22 Thread Tejas Upadhyay

Display underrun in HDR mode when cursor is enabled.
RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h.
As per W/A 1604331009, Disable cursor clock gating in HDR mode.

Bspec : 33451

Changes since V3:
- Disable WA when not in HDR mode or cursor plane not active - Ville
- Extract required args from crtc_state - Ville
- Create HDR mode API using bdw_set_pipemisc ref - Ville
- Tested with HDR video as well full setmode, WA applies and disables
Changes since V2:
- Made it general gen11 WA
- Removed WA needed check
- Added cursor plane active check
- Once WA enable, software will not disable
Changes since V1:
- Modified way CLKGATE_DIS_PSL bit 28 was modified

Cc: Souza Jose 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/display/intel_display.c | 27 
 drivers/gpu/drm/i915/i915_reg.h  |  5 
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..e1ea03b918df 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -358,6 +358,13 @@ static void intel_update_czclk(struct drm_i915_private 
*dev_priv)
dev_priv->czclk_freq);
 }
 
+static bool
+is_hdr_mode(const struct intel_crtc_state *crtc_state)
+{
+   return (crtc_state->active_planes & ~(icl_hdr_plane_mask() |
+   BIT(PLANE_CURSOR))) == 0;
+}
+
 /* WA Display #0827: Gen9:all */
 static void
 skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
@@ -383,6 +390,23 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, 
enum pipe pipe,
   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~DPFR_GATING_DIS);
 }
 
+/* Wa_1604331009:icl,jsl,ehl */
+   static void
+icl_wa_cursorclkgating(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+   if (is_hdr_mode(crtc_state) &&
+   crtc_state->active_planes & BIT(PLANE_CURSOR) &&
+   IS_GEN(dev_priv, 11))
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(crtc->pipe),
+CURSOR_GATING_DIS, CURSOR_GATING_DIS);
+   else
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(crtc->pipe),
+CURSOR_GATING_DIS, 0);
+}
+
 static bool
 is_trans_port_sync_slave(const struct intel_crtc_state *crtc_state)
 {
@@ -2939,6 +2963,9 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,
needs_scalerclk_wa(new_crtc_state))
icl_wa_scalerclkgating(dev_priv, pipe, true);
 
+   /* Wa_1604331009:icl,jsl,ehl */
+   icl_wa_cursorclkgating(new_crtc_state);
+
/*
 * Vblank time updates from the shadow to live plane control register
 * are blocked if the memory self-refresh mode is active at that
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c857fafb8a30..703d708c773e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4235,6 +4235,11 @@ enum {
 #define INF_UNIT_LEVEL_CLKGATE _MMIO(0x9560)
 #define   CGPSF_CLKGATE_DIS(1 << 3)
 
+/*
+ * GEN11 clock gating regs
+ */
+#define   CURSOR_GATING_DISBIT(28)
+
 /*
  * Display engine regs
  */
-- 
2.31.1

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

Re: [Intel-gfx] [PATCH v7 2/3] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-22 Thread Matthew Auld

On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
 wrote:
>
> After a TTM move or object init we need to update the i915 gem flags and
> caching settings to reflect the new placement. Currently caching settings
> are not changed during the lifetime of an object, although that might
> change moving forward if we run into performance issues or issues with
> WC system page allocations.
> Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
> various ways we previously used to detect this.
> Finally, initialize the TTM object reserved to be able to update
> flags and caching before anyone else gets hold of the object.
>
> Signed-off-by: Thomas Hellström 
> Reviewed-by: Matthew Auld 
> ---
> v6:
> - Rebase on accelerated ttm moves.
> ---



> @@ -775,14 +845,13 @@ int __i915_gem_ttm_object_init(struct 
> intel_memory_region *mem,
> i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
> i915_gem_object_init_memory_region(obj, mem);
> i915_gem_object_make_unshrinkable(obj);
> -   obj->read_domains = I915_GEM_DOMAIN_WC | I915_GEM_DOMAIN_GTT;
> -   obj->mem_flags |= I915_BO_FLAG_IOMEM;
> -   i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
> INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | 
> __GFP_NOWARN);
> mutex_init(&obj->ttm.get_io_page.lock);
> bo_type = (obj->flags & I915_BO_ALLOC_USER) ? ttm_bo_type_device :
> ttm_bo_type_kernel;
>
> +   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
> +
> /*
>  * If this function fails, it will call the destructor, but
>  * our caller still owns the object. So no freeing in the
> @@ -790,14 +859,16 @@ int __i915_gem_ttm_object_init(struct 
> intel_memory_region *mem,
>  * Similarly, in delayed_destroy, we can't call ttm_bo_put()
>  * until successful initialization.
>  */
> -   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
> -   ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
> - bo_type, &i915_sys_placement,
> - mem->min_page_size >> PAGE_SHIFT,
> - true, NULL, NULL, i915_ttm_bo_destroy);
> -   if (!ret)
> -   obj->ttm.created = true;
> -
> -   /* i915 wants -ENXIO when out of memory region space. */
> -   return i915_ttm_err_to_gem(ret);
> +   ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), size,
> +  bo_type, &i915_sys_placement, 1,

mem->min_page_size >> PAGE_SHIFT? Although just realised that looks
iffy since it only considers the current region, when it should
consider all future placements. I wonder if it makes sense to make
page_alignment part of ttm_place? Anyway, it doesn't matter for this
series.

> +  &ctx, NULL, NULL, i915_ttm_bo_destroy);
> +   if (ret)
> +   return i915_ttm_err_to_gem(ret);
> +
> +   obj->ttm.created = true;
> +   i915_ttm_adjust_domains_after_move(obj);
> +   i915_ttm_adjust_gem_after_move(obj);
> +   i915_gem_object_unlock(obj);
> +
> +   return 0;
>  }
> --
> 2.31.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 v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-22 Thread Werner Sembach



Am 22.06.21 um 09:00 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:08 +0200
> Werner Sembach  wrote:
>
>> Add a new general drm property "active color range" which can be used by
>> graphic drivers to report the used color range back to userspace.
>>
>> There was no way to check which color range got actually used on a given
>> monitor. To surely predict this, one must know the exact capabilities of
>> the monitor and what the default behaviour of the used driver is. This
>> property helps eliminating the guessing at this point.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 59 +
>>  include/drm/drm_connector.h | 27 +++
>>  2 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index 684d7abdf0eb..818de58d972f 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -897,6 +897,12 @@ static const struct drm_prop_enum_list 
>> drm_active_color_format_enum_list[] = {
>>  { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = 
>> {
>> +{ DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>> +{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Doesn't "limited" mean different numbers on RGB vs. Y vs. CbCr? I have
> a vague recollection that at least one of them was different from the
> others.

Yes, seems like it does:
https://www.kernel.org/doc/html/v5.12/userspace-api/media/v4l/colorspaces-defs.html#c.V4L.v4l2_quantization

I carried the option names over from "Broadcast RGB", see my other e-mail for 
more details.

>
> Documenting DRM_MODE_COLOR_RANGE_UNSET as "unspecified/default" while
> the string for it is "Unknown" seems inconsistent to me. I would
> recommend to avoid the word "default" because "reset to defaults" might
> become a thing one day, and that probably is not the same default as
> here.
>
> Is there actually a case for "unknown"? How can it be not known? Or
> does it mean "not applicable"?

Unknown is when no monitor is connected or is when the connector/monitor is 
disabled.

It also is the initial value when the driver fails to correctly set the 
property. This shouldn't happen, but I'm
wondering if I should still introduce an _ERROR state instead for this case?

I will rename it, maybe "unset" to match the enum? "not applicable" also fits 
if either the error state is defined or
not necessary.

>
> Otherwise looks good to me.
>
>
> Thanks,
> pq
>
>
>> +};
>> +
>>  DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>>   drm_dp_subconnector_enum_list)
>>  
>> @@ -1221,6 +1227,14 @@ static const struct drm_prop_enum_list 
>> dp_colorspaces[] = {
>>   *  drm_connector_attach_active_color_format_property() to install this
>>   *  property.
>>   *
>> + * active color range:
>> + *  This read-only property tells userspace the color range actually used by
>> + *  the hardware display engine on "the cable" on a connector. The chosen
>> + *  value depends on hardware capabilities of the monitor and the used color
>> + *  format. Drivers shall use
>> + *  drm_connector_attach_active_color_range_property() to install this
>> + *  property.
>> + *
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2264,6 +2278,51 @@ void 
>> drm_connector_set_active_color_format_property(struct drm_connector *connec
>>  }
>>  EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
>>  
>> +/**
>> + * drm_connector_attach_active_color_range_property - attach "active color 
>> range" property
>> + * @connector: connector to attach active color range property on.
>> + *
>> + * This is used to check the applied color range on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_color_range_property(struct drm_connector 
>> *connector)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_property *prop;
>> +
>> +if (!connector->active_color_range_property) {
>> +prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "active color range",
>> +
>> drm_active_color_range_enum_list,
>> +
>> ARRAY_SIZE(drm_active_color_range_enum_list));
>> +if (!prop)
>> +return -ENOMEM;
>> +
>> +connector->active_color_range_property = prop;
>> +drm_object_attach_property(&connector->base, prop, 
>> DRM_MODE_COLOR_RANGE_UNSET);
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
>> +
>> +/**
>> + * drm_connector_set_ac

Re: [Intel-gfx] [PATCH v4 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context

2021-06-22 Thread Werner Sembach

Am 22.06.21 um 09:25 schrieb Pekka Paalanen:
> On Fri, 18 Jun 2021 11:11:14 +0200
> Werner Sembach  wrote:
>
>> Add "Broadcast RGB" to general drm context so that more drivers besides
>> i915 and gma500 can implement it without duplicating code.
>>
>> Userspace can use this property to tell the graphic driver to use full or
>> limited color range for a given connector, overwriting the default
>> behaviour/automatic detection.
>>
>> Possible options are:
>> - Automatic (default/current behaviour)
>> - Full
>> - Limited 16:235
>>
>> In theory the driver should be able to automatically detect the monitors
>> capabilities, but because of flawed standard implementations in Monitors,
>> this might fail. In this case a manual overwrite is required to not have
>> washed out colors or lose details in very dark or bright scenes.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c |  4 +++
>>  drivers/gpu/drm/drm_atomic_uapi.c   |  4 +++
>>  drivers/gpu/drm/drm_connector.c | 43 +
>>  include/drm/drm_connector.h | 16 +++
>>  4 files changed, 67 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 90d62f305257..0c89d32efbd0 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  if (old_connector_state->preferred_color_format !=
>>  new_connector_state->preferred_color_format)
>>  new_crtc_state->connectors_changed = true;
>> +
>> +if (old_connector_state->preferred_color_range !=
>> +new_connector_state->preferred_color_range)
>> +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 c536f5e22016..c589bb1a8163 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct 
>> drm_connector *connector,
>>  state->max_requested_bpc = val;
>>  } else if (property == connector->preferred_color_format_property) {
>>  state->preferred_color_format = val;
>> +} else if (property == connector->preferred_color_range_property) {
>> +state->preferred_color_range = val;
>>  } else if (connector->funcs->atomic_set_property) {
>>  return connector->funcs->atomic_set_property(connector,
>>  state, property, val);
>> @@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector 
>> *connector,
>>  *val = state->max_requested_bpc;
>>  } else if (property == connector->preferred_color_format_property) {
>>  *val = state->preferred_color_format;
>> +} else if (property == connector->preferred_color_range_property) {
>> +*val = state->preferred_color_range;
>>  } 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 aea03dd02e33..9bc596638613 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -905,6 +905,12 @@ static const struct drm_prop_enum_list 
>> drm_active_color_format_enum_list[] = {
>>  { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
>>  };
>>  
>> +static const struct drm_prop_enum_list 
>> drm_preferred_color_range_enum_list[] = {
>> +{ DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
>> +{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> +{ DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
> Hi,
>
> the same question here about these numbers as I asked on the "active
> color range" property.
>
>> +};
>> +
>>  static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = 
>> {
>>  { DRM_MODE_COLOR_RANGE_UNSET, "Unknown" },
>>  { DRM_MODE_COLOR_RANGE_FULL, "Full" },
>> @@ -1243,6 +1249,13 @@ static const struct drm_prop_enum_list 
>> dp_colorspaces[] = {
>>   *  drm_connector_attach_active_color_format_property() to install this
>>   *  property.
>>   *
>> + * Broadcast RGB:
>> + *  This property is used by userspace to change the used color range. When
>> + *  used the driver will use the selected range if valid for the current
>> + *  color format. Drivers to use the function
>> + *  drm_connector_attach_preferred_color_format_property() to create and
>> + *  attach the property to the connector during initialization.
> An important detail to document here is: does userspace need to
> take care that pixel data at the connector

[Intel-gfx] [PATCH] drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Matthew Auld

Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c5deb8b7227c..5d894bba6430 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -753,6 +753,25 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
 }
 
+static u64 i915_gem_object_page_size(struct drm_i915_gem_object *obj)
+{
+   u64 page_size;
+   int i;
+
+   if (!obj->mm.n_placements)
+   return obj->mm.region->min_page_size;
+
+   page_size = 0;
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   struct intel_memory_region *mr = obj->mm.placements[i];
+
+   page_size = max_t(u64, mr->min_page_size, page_size);
+   }
+
+   GEM_BUG_ON(!page_size);
+   return page_size;
+}
+
 /**
  * __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
  * @mem: The initial memory region for the object.
@@ -793,7 +812,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
  bo_type, &i915_sys_placement,
- mem->min_page_size >> PAGE_SHIFT,
+ i915_gem_object_page_size(obj) >> PAGE_SHIFT,
  true, NULL, NULL, i915_ttm_bo_destroy);
if (!ret)
obj->ttm.created = true;
-- 
2.26.3

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

Re: [Intel-gfx] [PATCH v7 2/3] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-22 Thread Thomas Hellström



On 6/22/21 11:44 AM, Matthew Auld wrote:

On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
 wrote:

After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v6:
- Rebase on accelerated ttm moves.
---




@@ -775,14 +845,13 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
 i915_gem_object_init_memory_region(obj, mem);
 i915_gem_object_make_unshrinkable(obj);
-   obj->read_domains = I915_GEM_DOMAIN_WC | I915_GEM_DOMAIN_GTT;
-   obj->mem_flags |= I915_BO_FLAG_IOMEM;
-   i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
 INIT_RADIX_TREE(&obj->ttm.get_io_page.radix, GFP_KERNEL | 
__GFP_NOWARN);
 mutex_init(&obj->ttm.get_io_page.lock);
 bo_type = (obj->flags & I915_BO_ALLOC_USER) ? ttm_bo_type_device :
 ttm_bo_type_kernel;

+   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
+
 /*
  * If this function fails, it will call the destructor, but
  * our caller still owns the object. So no freeing in the
@@ -790,14 +859,16 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
  * Similarly, in delayed_destroy, we can't call ttm_bo_put()
  * until successful initialization.
  */
-   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
-   ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement,
- mem->min_page_size >> PAGE_SHIFT,
- true, NULL, NULL, i915_ttm_bo_destroy);
-   if (!ret)
-   obj->ttm.created = true;
-
-   /* i915 wants -ENXIO when out of memory region space. */
-   return i915_ttm_err_to_gem(ret);
+   ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), size,
+  bo_type, &i915_sys_placement, 1,

mem->min_page_size >> PAGE_SHIFT? Although just realised that looks
iffy since it only considers the current region, when it should
consider all future placements. I wonder if it makes sense to make
page_alignment part of ttm_place? Anyway, it doesn't matter for this
series.


Good catch. Yes completely agree it should be part of ttm_place. But 
extending ttm_place and audit all drivers to always clear unused parts 
of ttm_place is a big task.


But it's also the case that the region manager is allowed to enforce an 
alignment, unknown to us here, so we might want to take that approach to 
begin with?


/Thomas


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

Re: [Intel-gfx] [PATCH] drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Thomas Hellström



On 6/22/21 11:58 AM, Matthew Auld wrote:

Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 21 -
  1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c5deb8b7227c..5d894bba6430 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -753,6 +753,25 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
  }
  
+static u64 i915_gem_object_page_size(struct drm_i915_gem_object *obj)

+{
+   u64 page_size;
+   int i;
+
+   if (!obj->mm.n_placements)
+   return obj->mm.region->min_page_size;
+
+   page_size = 0;
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   struct intel_memory_region *mr = obj->mm.placements[i];
+
+   page_size = max_t(u64, mr->min_page_size, page_size);
+   }
+
+   GEM_BUG_ON(!page_size);
+   return page_size;
+}
+
  /**
   * __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
   * @mem: The initial memory region for the object.
@@ -793,7 +812,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
  bo_type, &i915_sys_placement,
- mem->min_page_size >> PAGE_SHIFT,
+ i915_gem_object_page_size(obj) >> PAGE_SHIFT,


Hmm, can't we just have the buddy manager silently enforce its 
min_page_size?


/Thomas


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/dp: Fix eDP max rate for display 11+
URL   : https://patchwork.freedesktop.org/series/91764/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
acf045305774 drm/i915/dp: Fix eDP max rate for display 11+
-:20: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d3913019602e ("Revert 
"drm/i915/dp: Correctly advertise HBR3 for GEN11+"")'
#20: 
due to issues in CI in commit d3913019602e ("Revert "drm/i915/dp:

total: 1 errors, 0 warnings, 0 checks, 53 lines checked


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm: add a locked version of drm_is_current_master"

2021-06-22 Thread Patchwork

== Series Details ==

Series: Revert "drm: add a locked version of drm_is_current_master"
URL   : https://patchwork.freedesktop.org/series/91758/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10259_full -> Patchwork_20424_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20424_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20424_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20424_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_mmap_gtt@basic-small-bo-tiledy:
- shard-glk:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-glk5/igt@gem_mmap_...@basic-small-bo-tiledy.html

  * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs:
- shard-skl:  NOTRUN -> [INCOMPLETE][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-skl7/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytileccs.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs}:
- shard-tglb: NOTRUN -> [SKIP][3] +100 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb1/igt@kms_ccs@pipe-a-bad-pixel-format-y_tiled_gen12_mc_ccs.html

  * {igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc}:
- shard-skl:  NOTRUN -> [FAIL][4] +4 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-skl2/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html

  
Known issues


  Here are the changes found in Patchwork_20424_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111827])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb1/igt@feature_discov...@chamelium.html
- shard-iclb: NOTRUN -> [SKIP][6] ([fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-iclb6/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@display-3x:
- shard-iclb: NOTRUN -> [SKIP][7] ([i915#1839]) +3 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-iclb7/igt@feature_discov...@display-3x.html

  * igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#1839]) +3 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb5/igt@feature_discov...@display-4x.html

  * igt@gem_create@create-massive:
- shard-iclb: NOTRUN -> [DMESG-WARN][9] ([i915#3002]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-iclb3/igt@gem_cre...@create-massive.html
- shard-snb:  NOTRUN -> [DMESG-WARN][10] ([i915#3002]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-snb6/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-tglb: NOTRUN -> [SKIP][11] ([fdo#109314])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb7/igt@gem_ctx_pa...@set-priority-not-supported.html
- shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109314])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-iclb2/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1099]) +13 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_sseu@invalid-sseu:
- shard-tglb: NOTRUN -> [SKIP][14] ([i915#280]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb7/igt@gem_ctx_s...@invalid-sseu.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: NOTRUN -> [TIMEOUT][15] ([i915#2369] / [i915#3063])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-tglb7/igt@gem_...@unwedge-stress.html
- shard-iclb: NOTRUN -> [TIMEOUT][16] ([i915#2369] / [i915#2481] / 
[i915#3070])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-iclb1/igt@gem_...@unwedge-stress.html
- shard-snb:  NOTRUN -> [FAIL][17] ([i915#3354])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20424/shard-snb6/igt@gem_...@unwedge-stress.html

  * igt@gem_ex

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915/ttm: Use TTM for system memory

2021-06-22 Thread Matthew Auld

On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
 wrote:
>
> For discrete, use TTM for both cached and WC system memory. That means
> we currently rely on the TTM memory accounting / shrinker. For cached
> system memory we should consider remaining shmem-backed, which can be
> implemented from our ttm_tt_populate callback. We can then also reuse our
> own very elaborate shrinker for that memory.
>
> Signed-off-by: Thomas Hellström 
> Reviewed-by: Matthew Auld 
> ---
> v2:
> - Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
> v3:
> - Commit message typo fix
> v6:
> - Fix TODO:s for supporting system memory with TTM.
> - Update the object GEM region after a TTM move if compatible.
> - Add a couple of warnings for shmem on DGFX.
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  |  3 ++
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 51 +-
>  drivers/gpu/drm/i915/i915_drv.h|  3 --
>  drivers/gpu/drm/i915/intel_memory_region.c |  7 ++-
>  drivers/gpu/drm/i915/intel_memory_region.h |  8 
>  5 files changed, 58 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 7aa1c95c7b7d..3648ae1d6628 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -284,6 +284,7 @@ __i915_gem_object_release_shmem(struct 
> drm_i915_gem_object *obj,
> bool needs_clflush)
>  {
> GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
> +   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
>
> if (obj->mm.madv == I915_MADV_DONTNEED)
> obj->mm.dirty = false;
> @@ -302,6 +303,7 @@ void i915_gem_object_put_pages_shmem(struct 
> drm_i915_gem_object *obj, struct sg_
> struct pagevec pvec;
> struct page *page;
>
> +   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
> __i915_gem_object_release_shmem(obj, pages, true);
>
> i915_gem_gtt_finish_pages(obj, pages);
> @@ -560,6 +562,7 @@ i915_gem_object_create_shmem_from_data(struct 
> drm_i915_private *dev_priv,
> resource_size_t offset;
> int err;
>
> +   GEM_WARN_ON(IS_DGFX(dev_priv));
> obj = i915_gem_object_create_shmem(dev_priv, round_up(size, 
> PAGE_SIZE));
> if (IS_ERR(obj))
> return obj;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 966b292d07da..07097f150065 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -286,6 +286,25 @@ static void i915_ttm_adjust_gem_after_move(struct 
> drm_i915_gem_object *obj)
>  {
> struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> unsigned int cache_level;
> +   unsigned int i;
> +
> +   /*
> +* If object was moved to an allowable region, update the object
> +* region to consider it migrated. Note that if it's currently not
> +* in an allowable region, it's evicted and we don't update the
> +* object region.
> +*/
> +   if (intel_region_to_ttm_type(obj->mm.region) != 
> bo->resource->mem_type) {
> +   for (i = 0; i < obj->mm.n_placements; ++i) {
> +   struct intel_memory_region *mr = 
> obj->mm.placements[i];
> +
> +   if (intel_region_to_ttm_type(mr) == 
> bo->resource->mem_type &&
> +   mr != obj->mm.region) {
> +   intel_memory_region_put(obj->mm.region);
> +   obj->mm.region = intel_memory_region_get(mr);

break;?

i915_gem_object_{init, release}_memory_region?

There is also the region_link stuff, but I guess we can nuke that?


> +   }
> +   }
> +   }
>
> obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
>
> @@ -615,13 +634,6 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
> *obj)
> /* Move to the requested placement. */
> i915_ttm_placement_from_obj(obj, &requested, busy, &placement);
>
> -   /*
> -* For now we support LMEM only with TTM.
> -* TODO: Remove with system support
> -*/
> -   GEM_BUG_ON(requested.mem_type < I915_PL_LMEM0 ||
> -  busy[0].mem_type < I915_PL_LMEM0);
> -
> /* First try only the requested placement. No eviction. */
> real_num_busy = fetch_and_zero(&placement.num_busy_placement);
> ret = ttm_bo_validate(bo, &placement, &ctx);
> @@ -635,9 +647,6 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
> *obj)
> ret == -EAGAIN)
> return ret;
>
> -   /* TODO: Remove this when we support system as TTM. */
> -   real_num_busy = 1;
> -
> /*
>  * If the initial attempt fails, allow all accepted 
> placements,
>

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915/ttm: Use TTM for system memory

2021-06-22 Thread Thomas Hellström



On 6/22/21 12:55 PM, Matthew Auld wrote:

On Tue, 22 Jun 2021 at 10:34, Thomas Hellström
 wrote:

For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very elaborate shrinker for that memory.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
v6:
- Fix TODO:s for supporting system memory with TTM.
- Update the object GEM region after a TTM move if compatible.
- Add a couple of warnings for shmem on DGFX.
---
  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  |  3 ++
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 51 +-
  drivers/gpu/drm/i915/i915_drv.h|  3 --
  drivers/gpu/drm/i915/intel_memory_region.c |  7 ++-
  drivers/gpu/drm/i915/intel_memory_region.h |  8 
  5 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 7aa1c95c7b7d..3648ae1d6628 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -284,6 +284,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
 bool needs_clflush)
  {
 GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));

 if (obj->mm.madv == I915_MADV_DONTNEED)
 obj->mm.dirty = false;
@@ -302,6 +303,7 @@ void i915_gem_object_put_pages_shmem(struct 
drm_i915_gem_object *obj, struct sg_
 struct pagevec pvec;
 struct page *page;

+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
 __i915_gem_object_release_shmem(obj, pages, true);

 i915_gem_gtt_finish_pages(obj, pages);
@@ -560,6 +562,7 @@ i915_gem_object_create_shmem_from_data(struct 
drm_i915_private *dev_priv,
 resource_size_t offset;
 int err;

+   GEM_WARN_ON(IS_DGFX(dev_priv));
 obj = i915_gem_object_create_shmem(dev_priv, round_up(size, 
PAGE_SIZE));
 if (IS_ERR(obj))
 return obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 966b292d07da..07097f150065 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -286,6 +286,25 @@ static void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
  {
 struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
 unsigned int cache_level;
+   unsigned int i;
+
+   /*
+* If object was moved to an allowable region, update the object
+* region to consider it migrated. Note that if it's currently not
+* in an allowable region, it's evicted and we don't update the
+* object region.
+*/
+   if (intel_region_to_ttm_type(obj->mm.region) != bo->resource->mem_type) 
{
+   for (i = 0; i < obj->mm.n_placements; ++i) {
+   struct intel_memory_region *mr = obj->mm.placements[i];
+
+   if (intel_region_to_ttm_type(mr) == bo->resource->mem_type 
&&
+   mr != obj->mm.region) {
+   intel_memory_region_put(obj->mm.region);
+   obj->mm.region = intel_memory_region_get(mr);

break;?

i915_gem_object_{init, release}_memory_region?

There is also the region_link stuff, but I guess we can nuke that?


Ah, yes, I'll fix that up. I think we will actually need that for 
suspend/resume, as the TTM LRU lists aren't sufficient...


Thanks for reviewing!

/Thomas


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/dp: Fix eDP max rate for display 11+
URL   : https://patchwork.freedesktop.org/series/91764/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20425


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/index.html

Known issues


  Here are the changes found in Patchwork_20425 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][1] ([fdo#109271]) +24 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271]) +7 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6700k2:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#533])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [INCOMPLETE][4] ([i915#146] / [i915#2405]) -> 
[PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10261 -> Patchwork_20425

  CI-20190529: 20190529
  CI_DRM_10261: 132b189b72a94328f17fd70321bfe63e5b4208e9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20425: acf045305774fd990a2ea57fe20d99ed4bdf3bec @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

acf045305774 drm/i915/dp: Fix eDP max rate for display 11+

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev7)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL   : https://patchwork.freedesktop.org/series/90898/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gem/i915_gem_ttm.c:808:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?
-O:drivers/gpu/drm/i915/gem/i915_gem_ttm.c:733:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move system memory to TTM for discrete (rev7)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL   : https://patchwork.freedesktop.org/series/90898/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20426


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20426:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_parallel@engines@userptr:
- {fi-dg1-1}: [FAIL][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-dg1-1/igt@gem_exec_parallel@engi...@userptr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-dg1-1/igt@gem_exec_parallel@engi...@userptr.html

  * igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-jsl-1/igt@i915_selftest@live@gt_pm.html

  * igt@runner@aborted:
- {fi-dg1-1}: NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-dg1-1/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_20426 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][6] ([fdo#109271]) +24 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271]) +4 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6700k2:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [INCOMPLETE][9] ([i915#146] / [i915#2405]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 38)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10261 -> Patchwork_20426

  CI-20190529: 20190529
  CI_DRM_10261: 132b189b72a94328f17fd70321bfe63e5b4208e9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20426: 324152868ec7f72345a32b8729031558529929fe @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

324152868ec7 drm/i915/ttm: Use TTM for system memory
4e479fc2ee7c drm/i915/ttm: Adjust gem flags and caching settings after a move
181ccb1c4076 drm/i915: Update object placement flags to be mutable

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace

2021-06-22 Thread Simon Ser

On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach  
wrote:

> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.

I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
enum entry. User-space should ignore the prop on these disconnected
connectors anyways.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Matthew Auld

On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
 wrote:
>
>
> On 6/22/21 11:58 AM, Matthew Auld wrote:
> > Just checking the current region is not enough, if we later migrate the
> > object somewhere else. For example if the placements are {SMEM, LMEM},
> > then we might get this wrong. Another idea might be to make the
> > page_alignment part of the ttm_place, instead of the BO.
> >
> > Signed-off-by: Matthew Auld 
> > Cc: Thomas Hellström 
> > ---
> >   drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 21 -
> >   1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index c5deb8b7227c..5d894bba6430 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -753,6 +753,25 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
> >   call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
> >   }
> >
> > +static u64 i915_gem_object_page_size(struct drm_i915_gem_object *obj)
> > +{
> > + u64 page_size;
> > + int i;
> > +
> > + if (!obj->mm.n_placements)
> > + return obj->mm.region->min_page_size;
> > +
> > + page_size = 0;
> > + for (i = 0; i < obj->mm.n_placements; i++) {
> > + struct intel_memory_region *mr = obj->mm.placements[i];
> > +
> > + page_size = max_t(u64, mr->min_page_size, page_size);
> > + }
> > +
> > + GEM_BUG_ON(!page_size);
> > + return page_size;
> > +}
> > +
> >   /**
> >* __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
> >* @mem: The initial memory region for the object.
> > @@ -793,7 +812,7 @@ int __i915_gem_ttm_object_init(struct 
> > intel_memory_region *mem,
> >   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
> >   ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
> > bo_type, &i915_sys_placement,
> > -   mem->min_page_size >> PAGE_SHIFT,
> > +   i915_gem_object_page_size(obj) >> PAGE_SHIFT,
>
> Hmm, can't we just have the buddy manager silently enforce its
> min_page_size?

Maybe, but we need some way of overriding it for all of our page-table
allocations(and some other stuff also), so being able to control the
page_alignment at the object level here seems reasonable? Could maybe
pass it through with create_lmem_with_page_size(..., page_size)? Ok,
it might be best to first type it and then see how it will all fit
together.


>
> /Thomas
>
>
> ___
> 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] drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Thomas Hellström



On 6/22/21 2:15 PM, Matthew Auld wrote:

On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
 wrote:


On 6/22/21 11:58 AM, Matthew Auld wrote:

Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
   drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 21 -
   1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c5deb8b7227c..5d894bba6430 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -753,6 +753,25 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
   call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
   }

+static u64 i915_gem_object_page_size(struct drm_i915_gem_object *obj)
+{
+ u64 page_size;
+ int i;
+
+ if (!obj->mm.n_placements)
+ return obj->mm.region->min_page_size;
+
+ page_size = 0;
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ struct intel_memory_region *mr = obj->mm.placements[i];
+
+ page_size = max_t(u64, mr->min_page_size, page_size);
+ }
+
+ GEM_BUG_ON(!page_size);
+ return page_size;
+}
+
   /**
* __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
* @mem: The initial memory region for the object.
@@ -793,7 +812,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
   ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
 bo_type, &i915_sys_placement,
-   mem->min_page_size >> PAGE_SHIFT,
+   i915_gem_object_page_size(obj) >> PAGE_SHIFT,

Hmm, can't we just have the buddy manager silently enforce its
min_page_size?

Maybe, but we need some way of overriding it for all of our page-table
allocations(and some other stuff also), so being able to control the
page_alignment at the object level here seems reasonable? Could maybe
pass it through with create_lmem_with_page_size(..., page_size)? Ok,
it might be best to first type it and then see how it will all fit
together.

Hmm, OK, I'm not 100% sure what the various requirements are here on the 
object level. But for region requirements, I think we've historically 
enforced that through the manager, taking also the bo->page_alignment 
into account and applying the larger of the two,


There is an example in vmw_thp_insert_aligned().

/Thomas


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

Re: [Intel-gfx] [PATCH] drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Matthew Auld


On 22/06/2021 13:29, Thomas Hellström wrote:


On 6/22/21 2:15 PM, Matthew Auld wrote:

On Tue, 22 Jun 2021 at 11:11, Thomas Hellström
 wrote:


On 6/22/21 11:58 AM, Matthew Auld wrote:

Just checking the current region is not enough, if we later migrate the
object somewhere else. For example if the placements are {SMEM, LMEM},
then we might get this wrong. Another idea might be to make the
page_alignment part of the ttm_place, instead of the BO.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
---
   drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 21 -
   1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c

index c5deb8b7227c..5d894bba6430 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -753,6 +753,25 @@ void i915_ttm_bo_destroy(struct 
ttm_buffer_object *bo)

   call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
   }

+static u64 i915_gem_object_page_size(struct drm_i915_gem_object *obj)
+{
+ u64 page_size;
+ int i;
+
+ if (!obj->mm.n_placements)
+ return obj->mm.region->min_page_size;
+
+ page_size = 0;
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ struct intel_memory_region *mr = obj->mm.placements[i];
+
+ page_size = max_t(u64, mr->min_page_size, page_size);
+ }
+
+ GEM_BUG_ON(!page_size);
+ return page_size;
+}
+
   /**
    * __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem 
object

    * @mem: The initial memory region for the object.
@@ -793,7 +812,7 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,

   obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
   ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
 bo_type, &i915_sys_placement,
-   mem->min_page_size >> PAGE_SHIFT,
+   i915_gem_object_page_size(obj) >> PAGE_SHIFT,

Hmm, can't we just have the buddy manager silently enforce its
min_page_size?

Maybe, but we need some way of overriding it for all of our page-table
allocations(and some other stuff also), so being able to control the
page_alignment at the object level here seems reasonable? Could maybe
pass it through with create_lmem_with_page_size(..., page_size)? Ok,
it might be best to first type it and then see how it will all fit
together.

Hmm, OK, I'm not 100% sure what the various requirements are here on the 
object level. But for region requirements, I think we've historically 
enforced that through the manager, taking also the bo->page_alignment 
into account and applying the larger of the two,


There is an example in vmw_thp_insert_aligned().


Yeah, so for our use case we need to support page_alignment < 
min_page_size, for page-tables(4K). I guess pushing the min_page_size 
into buddy_man, and then letting page_alignment override that, with the 
added caveat that it can be smaller could work. Otherwise just using 
mm.chunk_size would already fit the bill quite nicely.




/Thomas



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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Fix eDP max rate for display 11+

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/dp: Fix eDP max rate for display 11+
URL   : https://patchwork.freedesktop.org/series/91764/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20425_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20425_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20425_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20425_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk5/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-glk6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
Known issues


  Here are the changes found in Patchwork_20425_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#1888] / [i915#3160])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk7/igt@gem_cre...@create-clear.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-glk2/igt@gem_cre...@create-clear.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#198])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-skl5/igt@gem_ctx_isolation@preservation...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-skl8/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-iclb8/igt@gem_...@in-flight-contexts-10ms.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-iclb1/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-kbl4/igt@gem_...@in-flight-suspend.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-kbl7/igt@gem_...@in-flight-suspend.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#2369] / 
[i915#3063])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-tglb8/igt@gem_...@unwedge-stress.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-tglb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][14] -> [INCOMPLETE][15] ([i915#2369])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-skl5/igt@gem_exec_capture@p...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-skl8/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar 
issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#307])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-glk:  [PASS][22] -> [FAIL][23] ([i915#307])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk5/igt@gem_mmap_...@cpuset-medium-copy-odd.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20425/shard

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Disable cursor clock gating in HDR mode (rev2)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/gen11: Disable cursor clock gating in HDR mode (rev2)
URL   : https://patchwork.freedesktop.org/series/91674/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20427


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20427 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20427, 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_20427/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20427:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-bdw-5557u/igt@run...@aborted.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s3:
- {fi-ehl-2}: [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-ehl-2/igt@gem_exec_susp...@basic-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-ehl-2/igt@gem_exec_susp...@basic-s3.html

  
Known issues


  Here are the changes found in Patchwork_20427 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][4] ([fdo#109271]) +24 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271]) +12 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6700k2:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][7] ([i915#192] / [i915#193] / 
[i915#194] / [i915#2505])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [INCOMPLETE][8] ([i915#146] / [i915#2405]) -> 
[PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
  [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
  [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 37)
--

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-apl-guc fi-snb-2520m 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10261 -> Patchwork_20427

  CI-20190529: 20190529
  CI_DRM_10261: 132b189b72a94328f17fd70321bfe63e5b4208e9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20427: 8aaf8e7a39d13775853b775d6992fb44d5b10125 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8aaf8e7a39d1 drm/i915/gen11: Disable cursor clock gating in HDR mode

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20427/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/ttm: consider all placements for the page alignment
URL   : https://patchwork.freedesktop.org/series/91771/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10261 -> Patchwork_20428


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/index.html

Known issues


  Here are the changes found in Patchwork_20428 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][1] ([fdo#109271]) +24 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6700k2:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#533])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2:  [INCOMPLETE][3] ([i915#146] / [i915#2405]) -> 
[PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 
fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10261 -> Patchwork_20428

  CI-20190529: 20190529
  CI_DRM_10261: 132b189b72a94328f17fd70321bfe63e5b4208e9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20428: 67e27a0991ed4f46ec11cfa727d7c7de543981e0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

67e27a0991ed drm/i915/ttm: consider all placements for the page alignment

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: keep backlight_enable on until turn eDP display off

2021-06-22 Thread Lee Shawn C

This workaround is specific for a particular panel on Google
chromebook project. When user space daemon enter idle state.
It request adjust brightness to 0, turn backlight_enable signal
off and keep eDP main link active.

On general LCD, this behavior might not be a problem.
But on this panel, its tcon would expect source to execute
full eDP power off sequence after drop backlight_enable signal.
Without eDP power off sequence. Even source try to turn
backlight_enable signal on and restore proper brightness level.
This panel is not able to light on again.

This WA ignored the request from user space daemon to disable
backlight_enable signal and keep it on always. When user space
request kernel to turn eDP display off, kernel driver still
can control backlight_enable signal properly. It would not
impact standard eDP power off sequence.

Cc: Ville Syrjala 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Cooper Chiou 

Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_panel.c  |  4 ++-
 drivers/gpu/drm/i915/display/intel_quirks.c | 34 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7d7a60b4d2de..0212b53d932b 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1311,6 +1311,7 @@ static void intel_panel_set_backlight(const struct 
drm_connector_state *conn_sta
 static int intel_backlight_device_update_status(struct backlight_device *bd)
 {
struct intel_connector *connector = bl_get_data(bd);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
struct drm_device *dev = connector->base.dev;
 
@@ -1330,7 +1331,8 @@ static int intel_backlight_device_update_status(struct 
backlight_device *bd)
if (panel->backlight.power) {
bool enable = bd->props.power == FB_BLANK_UNBLANK &&
bd->props.brightness != 0;
-   panel->backlight.power(connector, enable);
+   if (enable || !(dev_priv->quirks & 
QUIRK_KEEP_BACKLIGHT_ENABLE_ON))
+   panel->backlight.power(connector, enable);
}
} else {
bd->props.power = FB_BLANK_POWERDOWN;
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 98dd787b00e3..ed57b083edbb 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,12 @@ static void quirk_increase_ddi_disabled_time(struct 
drm_i915_private *i915)
drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
 }
 
+static void quirk_keep_backlight_enable_on(struct drm_i915_private *i915)
+{
+   i915->quirks |= QUIRK_KEEP_BACKLIGHT_ENABLE_ON;
+   drm_info(&i915->drm, "applying keep backlight enable on quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -72,6 +78,12 @@ static int intel_dmi_reverse_brightness(const struct 
dmi_system_id *id)
return 1;
 }
 
+static int backlight_wa_callback(const struct dmi_system_id *id)
+{
+   DRM_INFO("This is WA to ignore backlight off to prevent OLED panel 
issue on %s device\n", id->ident);
+   return 1;
+}
+
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -96,6 +108,28 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_invert_brightness,
},
+   {
+   .dmi_id_list = &(const struct dmi_system_id[]) {
+   {
+   .callback = backlight_wa_callback,
+   .ident = "Google Lillipup",
+   .matches = {DMI_MATCH(DMI_BOARD_VENDOR, 
"Google"),
+   DMI_MATCH(DMI_BOARD_NAME, "Lindar"),
+   DMI_MATCH(DMI_PRODUCT_SKU, 
"sku524294"),
+   },
+   },
+   {
+   .callback = backlight_wa_callback,
+   .ident = "Google Lillipup",
+   .matches = {DMI_MATCH(DMI_BOARD_VENDOR, 
"Google"),
+   DMI_MATCH(DMI_BOARD_NAME, "Lindar"),
+   DMI_MATCH(DMI_PRODUCT_SKU, 
"sku524295"),
+   },
+   },
+   { }
+   },
+   .hook = quirk_keep_backlight_enable_on,
+   },
 };
 
 static struct intel_quirk intel_quirks[] = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gp

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move system memory to TTM for discrete (rev7)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev7)
URL   : https://patchwork.freedesktop.org/series/90898/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20426_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_20426_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-kbl:  NOTRUN -> [DMESG-WARN][1] ([i915#180])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-kbl7/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +5 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-tglb1/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-glk4/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][11] -> [FAIL][12] ([i915#307])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-apl8/igt@gem_pr...@exhaustion.html
- shard-snb:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-snb2/igt@gem_pr...@exhaustion.html
- shard-kbl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-kbl6/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@vma-merge:
- shard-skl:  NOTRUN -> [FAIL][17] ([i915#3318])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-skl4/igt@gem_userptr_bl...@vma-merge.html

  * igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: NOTRUN -> [WARN][18] ([i915#1804] / [i915#2684])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-iclb6/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271]) +210 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-apl1/igt@i915_pm_...@modeset-pc8-residency-stress.html

  * igt@i915_selftest@mock@requests:
- shard-skl:  NOTRUN -> [INCOMPLETE][20] ([i915#198])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-skl9/igt@i915_selftest@m...@requests.html

  * igt@kms_big_fb@linear-32bpp-rotate-180:
- shard-glk:  [PASS][21] -> [DMESG-WARN][22] ([i915#118] / 
[i915#95])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk5/igt@kms_big...@linear-32bpp-rotate-180.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20426/shard-glk1/igt@kms_big...@linear-32bpp-rotate-180.html

  * igt@kms_chamelium@dp-crc-fast:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109284] / [fdo#111827]) +1 
similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/

Re: [Intel-gfx] [PATCH v2] drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc

2021-06-22 Thread Jani Nikula

On Mon, 21 Jun 2021, "Navare, Manasi"  wrote:
> Reviewed-by: Manasi Navare 

Thanks, pushed to drm-intel-next.

BR,
Jani


-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: keep backlight_enable on until turn eDP display off

2021-06-22 Thread Jani Nikula

On Tue, 22 Jun 2021, Lee Shawn C  wrote:
> This workaround is specific for a particular panel on Google
> chromebook project. When user space daemon enter idle state.
> It request adjust brightness to 0, turn backlight_enable signal
> off and keep eDP main link active.
>
> On general LCD, this behavior might not be a problem.
> But on this panel, its tcon would expect source to execute
> full eDP power off sequence after drop backlight_enable signal.
> Without eDP power off sequence. Even source try to turn
> backlight_enable signal on and restore proper brightness level.
> This panel is not able to light on again.
>
> This WA ignored the request from user space daemon to disable
> backlight_enable signal and keep it on always. When user space
> request kernel to turn eDP display off, kernel driver still
> can control backlight_enable signal properly. It would not
> impact standard eDP power off sequence.
>
> Cc: Ville Syrjala 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Cc: Cooper Chiou 
>
> Signed-off-by: Lee Shawn C 
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c  |  4 ++-
>  drivers/gpu/drm/i915/display/intel_quirks.c | 34 +
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 7d7a60b4d2de..0212b53d932b 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1311,6 +1311,7 @@ static void intel_panel_set_backlight(const struct 
> drm_connector_state *conn_sta
>  static int intel_backlight_device_update_status(struct backlight_device *bd)
>  {
>   struct intel_connector *connector = bl_get_data(bd);
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = &connector->panel;
>   struct drm_device *dev = connector->base.dev;
>  
> @@ -1330,7 +1331,8 @@ static int intel_backlight_device_update_status(struct 
> backlight_device *bd)
>   if (panel->backlight.power) {
>   bool enable = bd->props.power == FB_BLANK_UNBLANK &&
>   bd->props.brightness != 0;
> - panel->backlight.power(connector, enable);
> + if (enable || !(dev_priv->quirks & 
> QUIRK_KEEP_BACKLIGHT_ENABLE_ON))
> + panel->backlight.power(connector, enable);

We'll want to avoid the hook altogether in this case, instead of
complicating the logic even more. Something like:

--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5286,7 +5286,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}
 
intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
-   intel_connector->panel.backlight.power = intel_pps_backlight_power;
+   if (!(dev_priv->quirks & QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK))
+   intel_connector->panel.backlight.power = 
intel_pps_backlight_power;
intel_panel_setup_backlight(connector, pipe);
 
if (fixed_mode) {

---

Please adjust the quirk name and debug logs accordingly.

Truth be told I'd rather nuke the hook completely. But it was a request
from Chrome to have this lightweight sub-state to black out the display,
without mode set, using the panel power sequencer in cases where we
can't set the backlight PWM to 0.

Hmm. Is the brightness controlled using PWM or DPCD? We probably
shouldn't do this at all when the brightness control is done using DPCD.

BR,
Jani.


>   }
>   } else {
>   bd->props.power = FB_BLANK_POWERDOWN;
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index 98dd787b00e3..ed57b083edbb 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -53,6 +53,12 @@ static void quirk_increase_ddi_disabled_time(struct 
> drm_i915_private *i915)
>   drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
>  }
>  
> +static void quirk_keep_backlight_enable_on(struct drm_i915_private *i915)
> +{
> + i915->quirks |= QUIRK_KEEP_BACKLIGHT_ENABLE_ON;
> + drm_info(&i915->drm, "applying keep backlight enable on quirk\n");
> +}
> +
>  struct intel_quirk {
>   int device;
>   int subsystem_vendor;
> @@ -72,6 +78,12 @@ static int intel_dmi_reverse_brightness(const struct 
> dmi_system_id *id)
>   return 1;
>  }
>  
> +static int backlight_wa_callback(const struct dmi_system_id *id)
> +{
> + DRM_INFO("This is WA to ignore backlight off to prevent OLED panel 
> issue on %s device\n", id->ident);
> + return 1;
> +}
> +
>  static const struct intel_dmi_quirk intel_dmi_quirks[] = {
>   {
>   .dmi_id_list = &(const struct dmi_system_id[]) {
> @@ -96,6 +108,28 @@ static const struct intel_dmi_quir

Re: [Intel-gfx] [PATCH] ALSA: hda: Release display power reference during shutdown/reboot

2021-06-22 Thread Takashi Iwai

On Mon, 21 Jun 2021 19:44:15 +0200,
Imre Deak wrote:
> 
> Make sure the HDA driver's display power reference is released during
> shutdown/reboot.
> 
> During the shutdown/reboot sequence the pci device core calls the
> pm_runtime_resume handler for all devices before calling the driver's
> shutdown callback and so the HDA driver's runtime resume callback will
> acquire a display power reference (on HSW/BDW). This triggers a power
> reference held WARN on HSW/BDW in the i915 driver's subsequent shutdown
> handler, which expects all display power references to be released by
> that time.
> 
> Since the HDA controller is stopped in the shutdown handler in any case,
> let's follow here the same sequence as the one during runtime suspend.
> This will also reset the HDA link and drop the display power reference,
> getting rid of the above WARN.

As kbuild bot suggested, __azx_runtime_suspend() is defined only with
CONFIG_PM.  We need either moving the function out of ifdef CONFIG_PM
block, or having CONFIG_PM conditional call there.

I myself have no much preference,  but maybe the latter can be easier
to be cherry-picked to stable kernels.


thanks,

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ttm: consider all placements for the page alignment

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915/ttm: consider all placements for the page alignment
URL   : https://patchwork.freedesktop.org/series/91771/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10261_full -> Patchwork_20428_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_20428_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#2369] / [i915#3063])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-tglb8/igt@gem_...@unwedge-stress.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-tglb3/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-kbl1/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk4/igt@gem_exec_fair@basic-n...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-glk2/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +4 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk:  [PASS][11] -> [DMESG-WARN][12] ([i915#118] / 
[i915#95]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10261/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-glk3/igt@gem_exec_whis...@basic-queues-forked-all.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][13] ([i915#2658])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-apl3/igt@gem_pr...@exhaustion.html
- shard-kbl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-kbl1/igt@gem_pr...@exhaustion.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: NOTRUN -> [WARN][16] ([i915#2684])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-iclb8/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
- shard-apl:  NOTRUN -> [SKIP][17] ([fdo#109271]) +183 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-apl8/igt@i915_pm_...@modeset-pc8-residency-stress.html

  * igt@kms_chamelium@dp-crc-fast:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109284] / [fdo#111827]) +1 
similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-iclb8/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-storm-disable:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +3 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-skl8/igt@kms_chamel...@hdmi-hpd-storm-disable.html

  * igt@kms_chamelium@hdmi-hpd-with-enabled-mode:
- shard-snb:  NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) 
+11 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-snb2/igt@kms_chamel...@hdmi-hpd-with-enabled-mode.html

  * igt@kms_chamelium@vga-hpd-for-each-pipe:
- shard-kbl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +6 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20428/shard-kbl1/igt@kms_chamel...@vga-hpd-for-each-pipe.html

  * igt@kms_color@pipe-c-ctm-red-to-blue:
- shard-skl:  [PAS

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: keep backlight_enable on until turn eDP display off (rev2)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: keep backlight_enable on until turn eDP display off (rev2)
URL   : https://patchwork.freedesktop.org/series/91780/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/display/intel_dp.o
drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_edp_init_connector’:
drivers/gpu/drm/i915/display/intel_dp.c:5241:27: error: 
‘QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK’ undeclared (first use in this function); 
did you mean ‘QUIRK_BACKLIGHT_PRESENT’?
  if (!(dev_priv->quirks & QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK))
   ^
   QUIRK_BACKLIGHT_PRESENT
drivers/gpu/drm/i915/display/intel_dp.c:5241:27: note: each undeclared 
identifier is reported only once for each function it appears in
scripts/Makefile.build:272: recipe for target 
'drivers/gpu/drm/i915/display/intel_dp.o' failed
make[4]: *** [drivers/gpu/drm/i915/display/intel_dp.o] Error 1
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1847: recipe for target 'drivers' failed
make: *** [drivers] Error 2


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

Re: [Intel-gfx] [PATCH] drm/i915: keep backlight_enable on until turn eDP display off

2021-06-22 Thread Lee, Shawn C



On Tue, 22 Jun 2021, 10:18 PM, Jani Nikula  wrote:
>On Tue, 22 Jun 2021, Lee Shawn C  wrote:
>> This workaround is specific for a particular panel on Google 
>> chromebook project. When user space daemon enter idle state.
>> It request adjust brightness to 0, turn backlight_enable signal off 
>> and keep eDP main link active.
>>
>> On general LCD, this behavior might not be a problem.
>> But on this panel, its tcon would expect source to execute full eDP 
>> power off sequence after drop backlight_enable signal.
>> Without eDP power off sequence. Even source try to turn 
>> backlight_enable signal on and restore proper brightness level.
>> This panel is not able to light on again.
>>
>> This WA ignored the request from user space daemon to disable 
>> backlight_enable signal and keep it on always. When user space request 
>> kernel to turn eDP display off, kernel driver still can control 
>> backlight_enable signal properly. It would not impact standard eDP 
>> power off sequence.
>>
>> Cc: Ville Syrjala 
>> Cc: Imre Deak 
>> Cc: Jani Nikula 
>> Cc: Cooper Chiou 
>>
>> Signed-off-by: Lee Shawn C 
>> ---
>>  drivers/gpu/drm/i915/display/intel_panel.c  |  4 ++-  
>> drivers/gpu/drm/i915/display/intel_quirks.c | 34 +
>>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
>> b/drivers/gpu/drm/i915/display/intel_panel.c
>> index 7d7a60b4d2de..0212b53d932b 100644
>> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> @@ -1311,6 +1311,7 @@ static void intel_panel_set_backlight(const 
>> struct drm_connector_state *conn_sta  static int 
>> intel_backlight_device_update_status(struct backlight_device *bd)  {
>>  struct intel_connector *connector = bl_get_data(bd);
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>>  struct intel_panel *panel = &connector->panel;
>>  struct drm_device *dev = connector->base.dev;
>>  
>> @@ -1330,7 +1331,8 @@ static int intel_backlight_device_update_status(struct 
>> backlight_device *bd)
>>  if (panel->backlight.power) {
>>  bool enable = bd->props.power == FB_BLANK_UNBLANK &&
>>  bd->props.brightness != 0;
>> -panel->backlight.power(connector, enable);
>> +if (enable || !(dev_priv->quirks & 
>> QUIRK_KEEP_BACKLIGHT_ENABLE_ON))
>> +panel->backlight.power(connector, enable);
>
>We'll want to avoid the hook altogether in this case, instead of complicating 
>the logic even more. Something like:
>
>--- a/drivers/gpu/drm/i915/display/intel_dp.c
>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
>@@ -5286,7 +5286,8 @@ static bool intel_edp_init_connector(struct intel_dp 
>*intel_dp,
>   }
> 
>   intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
>-  intel_connector->panel.backlight.power = intel_pps_backlight_power;
>+  if (!(dev_priv->quirks & QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK))
>+  intel_connector->panel.backlight.power = 
>intel_pps_backlight_power;
>   intel_panel_setup_backlight(connector, pipe);
> 
>   if (fixed_mode) {
>
>---
>
>Please adjust the quirk name and debug logs accordingly.
>

Thanks! I will modify the quirk name and debug messages later.

>Truth be told I'd rather nuke the hook completely. But it was a request from 
>Chrome to have this lightweight sub-state to black out the display, without 
>mode set, using the panel power sequencer in cases where we can't set the 
>backlight PWM to 0.
>
>Hmm. Is the brightness controlled using PWM or DPCD? We probably shouldn't do 
>this at all when the brightness control is done using DPCD.

This panel refer to soc's backlight_enable signal to enable backlight. But 
adjust brightness via DPCD aux interface.
If source turn backlight_enable signal off, panel tcon await source execute 
full eDP power off sequence to disable local display.
And panel's backlight is not able to turn on again.

Best regards,
Shawn

>
>BR,
>Jani.
>
>
>>  }
>>  } else {
>>  bd->props.power = FB_BLANK_POWERDOWN; diff --git 
>> a/drivers/gpu/drm/i915/display/intel_quirks.c 
>> b/drivers/gpu/drm/i915/display/intel_quirks.c
>> index 98dd787b00e3..ed57b083edbb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
>> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
>> @@ -53,6 +53,12 @@ static void quirk_increase_ddi_disabled_time(struct 
>> drm_i915_private *i915)
>>  drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");  }
>>  
>> +static void quirk_keep_backlight_enable_on(struct drm_i915_private 
>> +*i915) {
>> +i915->quirks |= QUIRK_KEEP_BACKLIGHT_ENABLE_ON;
>> +drm_info(&i915->drm, "applying keep backlight enable on quirk\n"); }
>> +
>>  struct intel_quirk {
>>  int device;
>>  int subsystem_ve

[Intel-gfx] [PATCH v3] drm/i915: keep backlight_enable on until turn eDP display off

2021-06-22 Thread Lee Shawn C

This workaround is specific for a particular panel on Google
chromebook project. When user space daemon enter idle state.
It request adjust brightness to 0, turn backlight_enable signal
off and keep eDP main link active.

On general LCD, this behavior might not be a problem.
But on this panel, its tcon would expect source to execute
full eDP power off sequence after drop backlight_enable signal.
Without eDP power off sequence. Even source try to turn
backlight_enable signal on and restore proper brightness level.
This panel is not able to light on again.

This WA ignored the request from user space daemon to disable
backlight_enable signal and keep it on always. When user space
request kernel to turn eDP display off, kernel driver still
can control backlight_enable signal properly. It would not
impact standard eDP power off sequence.

v2: modify the quirk name and debug messages.
unregister backlight.power callback for specific device.

Cc: Ville Syrjala 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Cooper Chiou 

Signed-off-by: Lee Shawn C 
---
 drivers/gpu/drm/i915/display/intel_dp.c |  3 +-
 drivers/gpu/drm/i915/display/intel_quirks.c | 34 +
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6cc03b9e4321..d3312b9bcc6f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5238,7 +5238,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}
 
intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
-   intel_connector->panel.backlight.power = intel_pps_backlight_power;
+   if (!(dev_priv->quirks & QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK))
+   intel_connector->panel.backlight.power = 
intel_pps_backlight_power;
intel_panel_setup_backlight(connector, pipe);
 
if (fixed_mode) {
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 98dd787b00e3..5f3cb006db01 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,12 @@ static void quirk_increase_ddi_disabled_time(struct 
drm_i915_private *i915)
drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
 }
 
+static void quirk_no_pps_backlight_power_hook(struct drm_i915_private *i915)
+{
+   i915->quirks |= QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK;
+   drm_info(&i915->drm, "Applying no pps backlight power quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -72,6 +78,12 @@ static int intel_dmi_reverse_brightness(const struct 
dmi_system_id *id)
return 1;
 }
 
+static int intel_dmi_no_pps_backlight(const struct dmi_system_id *id)
+{
+   DRM_INFO("This workaround prevented panel backlight issue on %s 
device\n", id->ident);
+   return 1;
+}
+
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -96,6 +108,28 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_invert_brightness,
},
+   {
+   .dmi_id_list = &(const struct dmi_system_id[]) {
+   {
+   .callback = intel_dmi_no_pps_backlight,
+   .ident = "Google Lillipup",
+   .matches = {DMI_MATCH(DMI_BOARD_VENDOR, 
"Google"),
+   DMI_MATCH(DMI_BOARD_NAME, "Lindar"),
+   DMI_MATCH(DMI_PRODUCT_SKU, 
"sku524294"),
+   },
+   },
+   {
+   .callback = intel_dmi_no_pps_backlight,
+   .ident = "Google Lillipup",
+   .matches = {DMI_MATCH(DMI_BOARD_VENDOR, 
"Google"),
+   DMI_MATCH(DMI_BOARD_NAME, "Lindar"),
+   DMI_MATCH(DMI_PRODUCT_SKU, 
"sku524295"),
+   },
+   },
+   { }
+   },
+   .hook = quirk_no_pps_backlight_power_hook,
+   },
 };
 
 static struct intel_quirk intel_quirks[] = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01e11fe38642..5a065be0792a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -467,6 +467,7 @@ struct i915_drrs {
 #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
 #define QUIRK_INCREASE_T12_DELAY (1<<6)
 #define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
+#define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
 
 struct intel_fbdev;
 struct intel_fbc_work;
-- 
2.17.1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: keep backlight_enable on until turn eDP display off (rev3)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL   : https://patchwork.freedesktop.org/series/91780/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9d04638ef39d drm/i915: keep backlight_enable on until turn eDP display off
-:115: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#115: FILE: drivers/gpu/drm/i915/i915_drv.h:470:
+#define QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK (1<<8)
 ^

total: 0 errors, 0 warnings, 1 checks, 68 lines checked


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: keep backlight_enable on until turn eDP display off (rev3)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL   : https://patchwork.freedesktop.org/series/91780/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10262 -> Patchwork_20430


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/index.html


Changes
---

  No changes found


Participating hosts (43 -> 39)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10262 -> Patchwork_20430

  CI-20190529: 20190529
  CI_DRM_10262: 56fd29b5c9b4b66818fc768e87dadea323babc1f @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20430: 9d04638ef39d4663002c6ba97298903b8eb66466 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9d04638ef39d drm/i915: keep backlight_enable on until turn eDP display off

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 00/15] implicit fencing/dma-resv rules for shared buffers

2021-06-22 Thread Daniel Vetter

Hi all,

After many bits have been spilled on dri-devel discussion this I think
we're converging on a consensus understanding of where we are, and it's
time to resubmit patches.

This is essentially v2 of

https://lore.kernel.org/dri-devel/20210521090959.1663703-7-daniel.vet...@ffwll.ch/

but a lot has changed:

- Christian fixed up amdgpu with a much more competent patch.

- I used the entire audit I've done in that patch to instead improve the
  documentation. That's the first 3 patches.

- panfrost patches fixed (hopefully, testing would be appreciated)

- drm/tiny patch fixed

- I've also thrown an RFC on top at the end for what I think amdgpu should
  be doing. Probably really, really buggy, so beware :-)

Review on the entire pile except the very last RFC very much appreciated.

Note that this does not, by far, fix all the various issues in handling
dma_buf.resv fences. This is just the part I had mostly ready already, and
which didn't take long to refresh and rebase. The other part is checking
whether drivers do anything funny that breaks the cross driver contract in
how they handle dependencies the get from the dma_buf.resv. I know they
do, but the full audit is not yet done.

Cheers, Daniel

Daniel Vetter (15):
  dma-resv: Fix kerneldoc
  dma-buf: Switch to inline kerneldoc
  dma-buf: Document dma-buf implicit fencing/resv fencing rules
  drm/panfrost: Shrink sched_lock
  drm/panfrost: Use xarray and helpers for depedency tracking
  drm/panfrost: Fix implicit sync
  drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default
  drm/: drm_gem_plane_helper_prepare_fb is now the default
  drm/armada: Remove prepare/cleanup_fb hooks
  drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
  drm/omap: Follow implicit fencing in prepare_fb
  drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default
  drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
  drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
  RFC: drm/amdgpu: Implement a proper implicit fencing uapi

 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  21 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|   6 +
 drivers/gpu/drm/armada/armada_overlay.c   |   2 -
 drivers/gpu/drm/armada/armada_plane.c |  29 
 drivers/gpu/drm/armada/armada_plane.h |   2 -
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c  |   1 -
 drivers/gpu/drm/ast/ast_mode.c|   3 +-
 drivers/gpu/drm/drm_atomic_helper.c   |  10 ++
 drivers/gpu/drm/drm_gem.c |   3 +
 drivers/gpu/drm/drm_gem_atomic_helper.c   |   3 +
 drivers/gpu/drm/drm_simple_kms_helper.c   |  12 +-
 drivers/gpu/drm/gud/gud_drv.c |   1 -
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|   3 +-
 drivers/gpu/drm/imx/dcss/dcss-plane.c |   1 -
 drivers/gpu/drm/imx/ipuv3-plane.c |   1 -
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |   1 -
 drivers/gpu/drm/ingenic/ingenic-ipu.c |   1 -
 drivers/gpu/drm/mcde/mcde_display.c   |   1 -
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  |   1 -
 drivers/gpu/drm/meson/meson_overlay.c |   1 -
 drivers/gpu/drm/meson/meson_plane.c   |   1 -
 drivers/gpu/drm/mxsfb/mxsfb_kms.c |   2 -
 drivers/gpu/drm/omapdrm/omap_plane.c  |   3 +
 drivers/gpu/drm/panfrost/panfrost_drv.c   |  41 +++--
 drivers/gpu/drm/panfrost/panfrost_job.c   |  71 -
 drivers/gpu/drm/panfrost/panfrost_job.h   |   8 +-
 drivers/gpu/drm/pl111/pl111_display.c |   1 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |   1 -
 drivers/gpu/drm/stm/ltdc.c|   1 -
 drivers/gpu/drm/sun4i/sun4i_layer.c   |   1 -
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c|   1 -
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c|   1 -
 drivers/gpu/drm/tidss/tidss_plane.c   |   1 -
 drivers/gpu/drm/tiny/hx8357d.c|   1 -
 drivers/gpu/drm/tiny/ili9225.c|   1 -
 drivers/gpu/drm/tiny/ili9341.c|   1 -
 drivers/gpu/drm/tiny/ili9486.c|   1 -
 drivers/gpu/drm/tiny/mi0283qt.c   |   1 -
 drivers/gpu/drm/tiny/repaper.c|   1 -
 drivers/gpu/drm/tiny/st7586.c |   1 -
 drivers/gpu/drm/tiny/st7735r.c|   1 -
 drivers/gpu/drm/tve200/tve200_display.c   |   1 -
 drivers/gpu/drm/vboxvideo/vbox_mode.c |   3 +-
 drivers/gpu/drm/xen/xen_drm_front_kms.c   |   1 -
 include/drm/drm_gem_vram_helper.h |  12 ++
 include/drm/drm_modeset_helper_vtables.h  |   7 +-
 include/drm/drm_simple_kms_helper.h   |   7 +-
 include/linux/dma-buf.h   | 146 +++---
 include/linux/dma-resv.h  |   2 +-
 include/uapi/drm/amdgpu_drm.h |  10 ++
 51 files changed, 270 insertions(+), 170 deletions(-)

-- 
2.32.0.rc2

___

[Intel-gfx] [PATCH 03/15] dma-buf: Document dma-buf implicit fencing/resv fencing rules

2021-06-22 Thread Daniel Vetter

Docs for struct dma_resv are fairly clear:

"A reservation object can have attached one exclusive fence (normally
associated with write operations) or N shared fences (read
operations)."

https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects

Furthermore a review across all of upstream.

First of render drivers and how they set implicit fences:

- nouveau follows this contract, see in validate_fini_no_ticket()

nouveau_bo_fence(nvbo, fence, !!b->write_domains);

  and that last boolean controls whether the exclusive or shared fence
  slot is used.

- radeon follows this contract by setting

p->relocs[i].tv.num_shared = !r->write_domain;

  in radeon_cs_parser_relocs(), which ensures that the call to
  ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the
  right thing.

- vmwgfx seems to follow this contract with the shotgun approach of
  always setting ttm_val_buf->num_shared = 0, which means
  ttm_eu_fence_buffer_objects() will only use the exclusive slot.

- etnaviv follows this contract, as can be trivially seen by looking
  at submit_attach_object_fences()

- i915 is a bit a convoluted maze with multiple paths leading to
  i915_vma_move_to_active(). Which sets the exclusive flag if
  EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for
  softpin mode, or through the write_domain when using relocations. It
  follows this contract.

- lima follows this contract, see lima_gem_submit() which sets the
  exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that
  bo

- msm follows this contract, see msm_gpu_submit() which sets the
  exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer

- panfrost follows this contract with the shotgun approach of just
  always setting the exclusive fence, see
  panfrost_attach_object_fences(). Benefits of a single engine I guess

- v3d follows this contract with the same shotgun approach in
  v3d_attach_fences_and_unlock_reservation(), but it has at least an
  XXX comment that maybe this should be improved

- v4c uses the same shotgun approach of always setting an exclusive
  fence, see vc4_update_bo_seqnos()

- vgem also follows this contract, see vgem_fence_attach_ioctl() and
  the VGEM_FENCE_WRITE. This is used in some igts to validate prime
  sharing with i915.ko without the need of a 2nd gpu

- vritio follows this contract again with the shotgun approach of
  always setting an exclusive fence, see virtio_gpu_array_add_fence()

This covers the setting of the exclusive fences when writing.

Synchronizing against the exclusive fence is a lot more tricky, and I
only spot checked a few:

- i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all
  implicit dependencies (which is used by vulkan)

- etnaviv does this. Implicit dependencies are collected in
  submit_fence_sync(), again with an opt-out flag
  ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in
  etnaviv_sched_dependency which is the
  drm_sched_backend_ops->dependency callback.

- v4c seems to not do much here, maybe gets away with it by not having
  a scheduler and only a single engine. Since all newer broadcom chips than
  the OG vc4 use v3d for rendering, which follows this contract, the
  impact of this issue is fairly small.

- v3d does this using the drm_gem_fence_array_add_implicit() helper,
  which then it's drm_sched_backend_ops->dependency callback
  v3d_job_dependency() picks up.

- panfrost is nice here and tracks the implicit fences in
  panfrost_job->implicit_fences, which again the
  drm_sched_backend_ops->dependency callback panfrost_job_dependency()
  picks up. It is mildly questionable though since it only picks up
  exclusive fences in panfrost_acquire_object_fences(), but not buggy
  in practice because it also always sets the exclusive fence. It
  should pick up both sets of fences, just in case there's ever going
  to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a
  pcie port and a real gpu, which might actually happen eventually. A
  bug, but easy to fix. Should probably use the
  drm_gem_fence_array_add_implicit() helper.

- lima is nice an easy, uses drm_gem_fence_array_add_implicit() and
  the same schema as v3d.

- msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
  but because it doesn't use the drm/scheduler it handles fences from
  the wrong context with a synchronous dma_fence_wait. See
  submit_fence_sync() leading to msm_gem_sync_object(). Investing into
  a scheduler might be a good idea.

- all the remaining drivers are ttm based, where I hope they do
  appropriately obey implicit fences already. I didn't do the full
  audit there because a) not follow the contract would confuse ttm
  quite well and b) reading non-standard scheduler and submit code
  which isn't based on drm/scheduler is a pain.

Onwards to the display side.

- Any driver using the drm_gem_plane_helper_prepare_fb() helper will
  correctly. Overwhelm

[Intel-gfx] [PATCH 02/15] dma-buf: Switch to inline kerneldoc

2021-06-22 Thread Daniel Vetter

Also review & update everything while we're at it.

This is prep work to smash a ton of stuff into the kerneldoc for
@resv.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Alex Deucher 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Nirmoy Das 
Cc: Deepak R Varma 
Cc: Chen Li 
Cc: Kevin Wang 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 include/linux/dma-buf.h | 107 +++-
 1 file changed, 83 insertions(+), 24 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 92eec38a03aa..6d18b9e448b9 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -289,28 +289,6 @@ struct dma_buf_ops {
 
 /**
  * struct dma_buf - shared buffer object
- * @size: size of the buffer; invariant over the lifetime of the buffer.
- * @file: file pointer used for sharing buffers across, and for refcounting.
- * @attachments: list of dma_buf_attachment that denotes all devices attached,
- *   protected by dma_resv lock.
- * @ops: dma_buf_ops associated with this buffer object.
- * @lock: used internally to serialize list manipulation, attach/detach and
- *vmap/unmap
- * @vmapping_counter: used internally to refcnt the vmaps
- * @vmap_ptr: the current vmap ptr if vmapping_counter > 0
- * @exp_name: name of the exporter; useful for debugging.
- * @name: userspace-provided name; useful for accounting and debugging,
- *protected by @resv.
- * @name_lock: spinlock to protect name access
- * @owner: pointer to exporter module; used for refcounting when exporter is a
- * kernel module.
- * @list_node: node for dma_buf accounting and debugging.
- * @priv: exporter specific private data for this buffer object.
- * @resv: reservation object linked to this dma-buf
- * @poll: for userspace poll support
- * @cb_excl: for userspace poll support
- * @cb_shared: for userspace poll support
- * @sysfs_entry: for exposing information about this buffer in sysfs.
  * The attachment_uid member of @sysfs_entry is protected by dma_resv lock
  * and is incremented on each attach.
  *
@@ -324,24 +302,100 @@ struct dma_buf_ops {
  * Device DMA access is handled by the separate &struct dma_buf_attachment.
  */
 struct dma_buf {
+   /**
+* @size:
+*
+* Size of the buffer; invariant over the lifetime of the buffer.
+*/
size_t size;
+
+   /**
+* @file:
+*
+* File pointer used for sharing buffers across, and for refcounting.
+* See dma_buf_get() and dma_buf_put().
+*/
struct file *file;
+
+   /**
+* @attachments:
+*
+* List of dma_buf_attachment that denotes all devices attached,
+* protected by &dma_resv lock @resv.
+*/
struct list_head attachments;
+
+   /** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
+
+   /**
+* @lock:
+*
+* Used internally to serialize list manipulation, attach/detach and
+* vmap/unmap. Note that in many cases this is superseeded by
+* dma_resv_lock() on @resv.
+*/
struct mutex lock;
+
+   /**
+* @vmapping_counter:
+*
+* Used internally to refcnt the vmaps returned by dma_buf_vmap().
+* Protected by @lock.
+*/
unsigned vmapping_counter;
+
+   /**
+* @vmap_ptr:
+* The current vmap ptr if @vmapping_counter > 0. Protected by @lock.
+*/
struct dma_buf_map vmap_ptr;
+
+   /**
+* @exp_name:
+*
+* Name of the exporter; useful for debugging. See the
+* DMA_BUF_SET_NAME IOCTL.
+*/
const char *exp_name;
+
+   /**
+* @name:
+*
+* Userspace-provided name; useful for accounting and debugging,
+* protected by dma_resv_lock() on @resv and @name_lock for read access.
+*/
const char *name;
+
+   /** @name_lock: Spinlock to protect name acces for read access. */
spinlock_t name_lock;
+
+   /**
+* @owner:
+*
+* Pointer to exporter module; used for refcounting when exporter is a
+* kernel module.
+*/
struct module *owner;
+
+   /** @list_node: node for dma_buf accounting and debugging. */
struct list_head list_node;
+
+   /** @priv: exporter specific private data for this buffer object. */
void *priv;
+
+   /**
+* @resv:
+*
+* Reservation object linked to this dma-buf.
+*/
struct dma_resv *resv;
 
-   /* poll support */
+   /** @poll: for userspace poll support */
wait_queue_head_t poll;
 
+   /** @cb_excl: for userspace poll support */
+   /** @cb_shared: for userspace poll support */
struct dma_buf_poll_cb_t {
struct dma_fence_cb cb;
wait_queue_head_t *poll;
@@ -34

[Intel-gfx] [PATCH 01/15] dma-resv: Fix kerneldoc

2021-06-22 Thread Daniel Vetter

Oversight from

commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
Author: Christian König 
Date:   Mon May 10 16:14:09 2021 +0200

dma-buf: rename and cleanup dma_resv_get_excl v3

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 include/linux/dma-resv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 562b885cf9c3..e1ca2080a1ff 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -212,7 +212,7 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
 }
 
 /**
- * dma_resv_exclusive - return the object's exclusive fence
+ * dma_resv_excl_fence - return the object's exclusive fence
  * @obj: the reservation object
  *
  * Returns the exclusive fence (if any). Caller must either hold the objects
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 04/15] drm/panfrost: Shrink sched_lock

2021-06-22 Thread Daniel Vetter

drm/scheduler requires a lock between _init and _push_job, but the
reservation lock dance doesn't. So shrink the critical section a
notch.

v2: Lucas pointed out how this should really work, I got it all wrong
in v1.

Signed-off-by: Daniel Vetter 
Cc: Lucas Stach 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 2df3e999a38d..38f8580c19f1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -224,14 +224,13 @@ int panfrost_job_push(struct panfrost_job *job)
struct ww_acquire_ctx acquire_ctx;
int ret = 0;
 
-   mutex_lock(&pfdev->sched_lock);
 
ret = drm_gem_lock_reservations(job->bos, job->bo_count,
&acquire_ctx);
-   if (ret) {
-   mutex_unlock(&pfdev->sched_lock);
+   if (ret)
return ret;
-   }
+
+   mutex_lock(&pfdev->sched_lock);
 
ret = drm_sched_job_init(&job->base, entity, NULL);
if (ret) {
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 05/15] drm/panfrost: Use xarray and helpers for depedency tracking

2021-06-22 Thread Daniel Vetter

More consistency and prep work for the next patch.

Aside: I wonder whether we shouldn't just move this entire xarray
business into the scheduler so that not everyone has to reinvent the
same wheels. Cc'ing some scheduler people for this too.

v2: Correctly handle sched_lock since Lucas pointed out it's needed.

v3: Rebase, dma_resv_get_excl_unlocked got renamed

v4: Don't leak job references on failure (Steven).

Cc: Lucas Stach 
Cc: "Christian König" 
Cc: Luben Tuikov 
Cc: Alex Deucher 
Cc: Lee Jones 
Cc: Steven Price 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Alyssa Rosenzweig 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 41 +++-
 drivers/gpu/drm/panfrost/panfrost_job.c | 65 +++--
 drivers/gpu/drm/panfrost/panfrost_job.h |  8 ++-
 3 files changed, 49 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 075ec0ef746c..3ee828f1e7a5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -138,12 +138,6 @@ panfrost_lookup_bos(struct drm_device *dev,
if (!job->bo_count)
return 0;
 
-   job->implicit_fences = kvmalloc_array(job->bo_count,
- sizeof(struct dma_fence *),
- GFP_KERNEL | __GFP_ZERO);
-   if (!job->implicit_fences)
-   return -ENOMEM;
-
ret = drm_gem_objects_lookup(file_priv,
 (void __user *)(uintptr_t)args->bo_handles,
 job->bo_count, &job->bos);
@@ -174,7 +168,7 @@ panfrost_lookup_bos(struct drm_device *dev,
 }
 
 /**
- * panfrost_copy_in_sync() - Sets up job->in_fences[] with the sync objects
+ * panfrost_copy_in_sync() - Sets up job->deps with the sync objects
  * referenced by the job.
  * @dev: DRM device
  * @file_priv: DRM file for this fd
@@ -194,22 +188,14 @@ panfrost_copy_in_sync(struct drm_device *dev,
 {
u32 *handles;
int ret = 0;
-   int i;
+   int i, in_fence_count;
 
-   job->in_fence_count = args->in_sync_count;
+   in_fence_count = args->in_sync_count;
 
-   if (!job->in_fence_count)
+   if (!in_fence_count)
return 0;
 
-   job->in_fences = kvmalloc_array(job->in_fence_count,
-   sizeof(struct dma_fence *),
-   GFP_KERNEL | __GFP_ZERO);
-   if (!job->in_fences) {
-   DRM_DEBUG("Failed to allocate job in fences\n");
-   return -ENOMEM;
-   }
-
-   handles = kvmalloc_array(job->in_fence_count, sizeof(u32), GFP_KERNEL);
+   handles = kvmalloc_array(in_fence_count, sizeof(u32), GFP_KERNEL);
if (!handles) {
ret = -ENOMEM;
DRM_DEBUG("Failed to allocate incoming syncobj handles\n");
@@ -218,16 +204,23 @@ panfrost_copy_in_sync(struct drm_device *dev,
 
if (copy_from_user(handles,
   (void __user *)(uintptr_t)args->in_syncs,
-  job->in_fence_count * sizeof(u32))) {
+  in_fence_count * sizeof(u32))) {
ret = -EFAULT;
DRM_DEBUG("Failed to copy in syncobj handles\n");
goto fail;
}
 
-   for (i = 0; i < job->in_fence_count; i++) {
+   for (i = 0; i < in_fence_count; i++) {
+   struct dma_fence *fence;
+
ret = drm_syncobj_find_fence(file_priv, handles[i], 0, 0,
-&job->in_fences[i]);
-   if (ret == -EINVAL)
+&fence);
+   if (ret)
+   goto fail;
+
+   ret = drm_gem_fence_array_add(&job->deps, fence);
+
+   if (ret)
goto fail;
}
 
@@ -265,6 +258,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev, 
void *data,
 
kref_init(&job->refcount);
 
+   xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
+
job->pfdev = pfdev;
job->jc = args->jc;
job->requirements = args->requirements;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 38f8580c19f1..71cd43fa1b36 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -196,14 +196,21 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
 }
 
-static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
-  int bo_count,
-  struct dma_fence **implicit_fences)
+static int panfrost_acquire_object_fences(struct drm_gem_object **bos,
+

[Intel-gfx] [PATCH 06/15] drm/panfrost: Fix implicit sync

2021-06-22 Thread Daniel Vetter

Currently this has no practial relevance I think because there's not
many who can pull off a setup with panfrost and another gpu in the
same system. But the rules are that if you're setting an exclusive
fence, indicating a gpu write access in the implicit fencing system,
then you need to wait for all fences, not just the previous exclusive
fence.

panfrost against itself has no problem, because it always sets the
exclusive fence (but that's probably something that will need to be
fixed for vulkan and/or multi-engine gpus, or you'll suffer badly).
Also no problem with that against display.

With the prep work done to switch over to the dependency helpers this
is now a oneliner.

Signed-off-by: Daniel Vetter 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 drivers/gpu/drm/panfrost/panfrost_job.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 71cd43fa1b36..ef004d587dc4 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -203,9 +203,8 @@ static int panfrost_acquire_object_fences(struct 
drm_gem_object **bos,
int i, ret;
 
for (i = 0; i < bo_count; i++) {
-   struct dma_fence *fence = 
dma_resv_get_excl_unlocked(bos[i]->resv);
-
-   ret = drm_gem_fence_array_add(deps, fence);
+   /* panfrost always uses write mode in its current uapi */
+   ret = drm_gem_fence_array_add_implicit(deps, bos[i], true);
if (ret)
return ret;
}
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 07/15] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default

2021-06-22 Thread Daniel Vetter

There's a bunch of atomic drivers who don't do this quite correctly,
luckily most of them aren't in wide use or people would have noticed
the tearing.

By making this the default we avoid the constant audit pain and can
additionally remove a ton of lines from vfuncs for a bit more clarity
in smaller drivers.

While at it complain if there's a cleanup_fb hook but no prepare_fb
hook, because that makes no sense. I haven't found any driver which
violates this, but better safe than sorry.

Subsequent patches will reap the benefits.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 10 ++
 drivers/gpu/drm/drm_gem_atomic_helper.c  |  3 +++
 include/drm/drm_modeset_helper_vtables.h |  7 +--
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 531f2374b072..9f6c5f21c4d6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2408,6 +2409,15 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,
ret = funcs->prepare_fb(plane, new_plane_state);
if (ret)
goto fail;
+   } else {
+   WARN_ON_ONCE(funcs->cleanup_fb);
+
+   if (!drm_core_check_feature(dev, DRIVER_GEM))
+   continue;
+
+   ret = drm_gem_plane_helper_prepare_fb(plane, 
new_plane_state);
+   if (ret)
+   goto fail;
}
}
 
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c 
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index a27135084ae5..bc9396f2a0ed 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -135,6 +135,9 @@
  * GEM based framebuffer drivers which have their buffers always pinned in
  * memory.
  *
+ * This function is the default implementation for GEM drivers of
+ * &drm_plane_helper_funcs.prepare_fb if no callback is provided.
+ *
  * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
  * explicit fencing in atomic modeset updates.
  */
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index f3a4b47b3986..4e727261dca5 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1178,8 +1178,11 @@ struct drm_plane_helper_funcs {
 * equivalent functionality should be implemented through private
 * members in the plane structure.
 *
-* Drivers which always have their buffers pinned should use
-* drm_gem_plane_helper_prepare_fb() for this hook.
+* For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook
+* set drm_gem_plane_helper_prepare_fb() is called automatically to
+* implement this. Other drivers which need additional plane processing
+* can call drm_gem_plane_helper_prepare_fb() from their @prepare_fb
+* hook.
 *
 * The helpers will call @cleanup_fb with matching arguments for every
 * successful call to this hook.
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 08/15] drm/: drm_gem_plane_helper_prepare_fb is now the default

2021-06-22 Thread Daniel Vetter

No need to set it explicitly.

Acked-by: Heiko Stuebner 
Acked-by: Paul Cercueil 
Acked-by: Jernej Skrabec 
Acked-by: Chun-Kuang Hu 
Acked-by: Martin Blumenstingl 
Acked-by: Tomi Valkeinen 
Acked-by: Philippe Cornu 
Acked-by: Lucas Stach 
Signed-off-by: Daniel Vetter 
Cc: Laurentiu Palcu 
Cc: Lucas Stach 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: Philipp Zabel 
Cc: Paul Cercueil 
Cc: Chun-Kuang Hu 
Cc: Matthias Brugger 
Cc: Neil Armstrong 
Cc: Kevin Hilman 
Cc: Jerome Brunet 
Cc: Martin Blumenstingl 
Cc: Marek Vasut 
Cc: Stefan Agner 
Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Jernej Skrabec 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-su...@lists.linux.dev
---
 drivers/gpu/drm/imx/dcss/dcss-plane.c   | 1 -
 drivers/gpu/drm/imx/ipuv3-plane.c   | 1 -
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c   | 1 -
 drivers/gpu/drm/ingenic/ingenic-ipu.c   | 1 -
 drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 -
 drivers/gpu/drm/meson/meson_overlay.c   | 1 -
 drivers/gpu/drm/meson/meson_plane.c | 1 -
 drivers/gpu/drm/mxsfb/mxsfb_kms.c   | 2 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 -
 drivers/gpu/drm/stm/ltdc.c  | 1 -
 drivers/gpu/drm/sun4i/sun4i_layer.c | 1 -
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c  | 1 -
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c  | 1 -
 drivers/gpu/drm/tidss/tidss_plane.c | 1 -
 14 files changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-plane.c 
b/drivers/gpu/drm/imx/dcss/dcss-plane.c
index 044d3bdf313c..ac45d54acd4e 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-plane.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-plane.c
@@ -361,7 +361,6 @@ static void dcss_plane_atomic_disable(struct drm_plane 
*plane,
 }
 
 static const struct drm_plane_helper_funcs dcss_plane_helper_funcs = {
-   .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = dcss_plane_atomic_check,
.atomic_update = dcss_plane_atomic_update,
.atomic_disable = dcss_plane_atomic_disable,
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 8710f55d2579..ef114b6aa691 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -772,7 +772,6 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {
-   .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = ipu_plane_atomic_check,
.atomic_disable = ipu_plane_atomic_disable,
.atomic_update = ipu_plane_atomic_update,
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 5244f4763477..c296472164d9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -830,7 +830,6 @@ static const struct drm_plane_helper_funcs 
ingenic_drm_plane_helper_funcs = {
.atomic_update  = ingenic_drm_plane_atomic_update,
.atomic_check   = ingenic_drm_plane_atomic_check,
.atomic_disable = ingenic_drm_plane_atomic_disable,
-   .prepare_fb = drm_gem_plane_helper_prepare_fb,
 };
 
 static const struct drm_crtc_helper_funcs ingenic_drm_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c 
b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index 61b6d9fdbba1..aeb8a757d213 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -625,7 +625,6 @@ static const struct drm_plane_helper_funcs 
ingenic_ipu_plane_helper_funcs = {
.atomic_update  = ingenic_ipu_plane_atomic_update,
.atomic_check   = ingenic_ipu_plane_atomic_check,
.atomic_disable = ingenic_ipu_plane_atomic_disable,
-   .prepare_fb = drm_gem_plane_helper_prepare_fb,
 };
 
 static int
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index b5582dcf564c..1667a7e7de38 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -227,7 +227,6 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
-   .prepare_fb = drm_gem_plane_helper_prepare_fb,
.atomic_check = mtk_plane_atomic_check,
.atomic_update = mtk_plane_atomic_update,
.atomic_disable = mtk_plane_atomic_disable,
diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index

[Intel-gfx] [PATCH 09/15] drm/armada: Remove prepare/cleanup_fb hooks

2021-06-22 Thread Daniel Vetter

All they do is refcount the fb, which the atomic helpers already do.

This is was necessary with the legacy helpers and I guess just carry
over in the conversion. drm_plane_state always has a full reference
for its ->fb pointer during its entire lifetime,
see __drm_atomic_helper_plane_destroy_state()

Signed-off-by: Daniel Vetter 
Cc: Russell King 
---
 drivers/gpu/drm/armada/armada_overlay.c |  2 --
 drivers/gpu/drm/armada/armada_plane.c   | 29 -
 drivers/gpu/drm/armada/armada_plane.h   |  2 --
 3 files changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index d3e3e5fdc390..424250535fed 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -247,8 +247,6 @@ static void armada_drm_overlay_plane_atomic_disable(struct 
drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs armada_overlay_plane_helper_funcs = 
{
-   .prepare_fb = armada_drm_plane_prepare_fb,
-   .cleanup_fb = armada_drm_plane_cleanup_fb,
.atomic_check   = armada_drm_plane_atomic_check,
.atomic_update  = armada_drm_overlay_plane_atomic_update,
.atomic_disable = armada_drm_overlay_plane_atomic_disable,
diff --git a/drivers/gpu/drm/armada/armada_plane.c 
b/drivers/gpu/drm/armada/armada_plane.c
index 40f5c34fb4d8..1c56a2883b91 100644
--- a/drivers/gpu/drm/armada/armada_plane.c
+++ b/drivers/gpu/drm/armada/armada_plane.c
@@ -78,33 +78,6 @@ void armada_drm_plane_calc(struct drm_plane_state *state, 
u32 addrs[2][3],
}
 }
 
-int armada_drm_plane_prepare_fb(struct drm_plane *plane,
-   struct drm_plane_state *state)
-{
-   DRM_DEBUG_KMS("[PLANE:%d:%s] [FB:%d]\n",
-   plane->base.id, plane->name,
-   state->fb ? state->fb->base.id : 0);
-
-   /*
-* Take a reference on the new framebuffer - we want to
-* hold on to it while the hardware is displaying it.
-*/
-   if (state->fb)
-   drm_framebuffer_get(state->fb);
-   return 0;
-}
-
-void armada_drm_plane_cleanup_fb(struct drm_plane *plane,
-   struct drm_plane_state *old_state)
-{
-   DRM_DEBUG_KMS("[PLANE:%d:%s] [FB:%d]\n",
-   plane->base.id, plane->name,
-   old_state->fb ? old_state->fb->base.id : 0);
-
-   if (old_state->fb)
-   drm_framebuffer_put(old_state->fb);
-}
-
 int armada_drm_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
 {
@@ -282,8 +255,6 @@ static void armada_drm_primary_plane_atomic_disable(struct 
drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs armada_primary_plane_helper_funcs = 
{
-   .prepare_fb = armada_drm_plane_prepare_fb,
-   .cleanup_fb = armada_drm_plane_cleanup_fb,
.atomic_check   = armada_drm_plane_atomic_check,
.atomic_update  = armada_drm_primary_plane_atomic_update,
.atomic_disable = armada_drm_primary_plane_atomic_disable,
diff --git a/drivers/gpu/drm/armada/armada_plane.h 
b/drivers/gpu/drm/armada/armada_plane.h
index 51dab8d8da22..368415c609a6 100644
--- a/drivers/gpu/drm/armada/armada_plane.h
+++ b/drivers/gpu/drm/armada/armada_plane.h
@@ -21,8 +21,6 @@ struct armada_plane_state {
 
 void armada_drm_plane_calc(struct drm_plane_state *state, u32 addrs[2][3],
u16 pitches[3], bool interlaced);
-int armada_drm_plane_prepare_fb(struct drm_plane *plane,
-   struct drm_plane_state *state);
 void armada_drm_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *old_state);
 int armada_drm_plane_atomic_check(struct drm_plane *plane,
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 10/15] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS

2021-06-22 Thread Daniel Vetter

Like we have for the shadow helpers too, and roll it out to drivers.

Acked-by: Tian Tao 
Signed-off-by: Daniel Vetter 
Cc: Dave Airlie 
Cc: Thomas Zimmermann 
Cc: Hans de Goede 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Tian Tao 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/ast/ast_mode.c |  3 +--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c |  3 +--
 drivers/gpu/drm/vboxvideo/vbox_mode.c  |  3 +--
 include/drm/drm_gem_vram_helper.h  | 12 
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e5996ae03c49..f5d58c3088fe 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -612,8 +612,7 @@ ast_primary_plane_helper_atomic_disable(struct drm_plane 
*plane,
 }
 
 static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = {
-   .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
-   .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+   DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
.atomic_check = ast_primary_plane_helper_atomic_check,
.atomic_update = ast_primary_plane_helper_atomic_update,
.atomic_disable = ast_primary_plane_helper_atomic_disable,
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 29b8332b2bca..ccf80e369b4b 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -158,8 +158,7 @@ static const struct drm_plane_funcs hibmc_plane_funcs = {
 };
 
 static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = {
-   .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
-   .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+   DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
.atomic_check = hibmc_plane_atomic_check,
.atomic_update = hibmc_plane_atomic_update,
 };
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c 
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index 964381d55fc1..972c83b720aa 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -488,8 +488,7 @@ static const struct drm_plane_helper_funcs 
vbox_primary_helper_funcs = {
.atomic_check = vbox_primary_atomic_check,
.atomic_update = vbox_primary_atomic_update,
.atomic_disable = vbox_primary_atomic_disable,
-   .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
-   .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+   DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
 };
 
 static const struct drm_plane_funcs vbox_primary_plane_funcs = {
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 27ed7e9243b9..f48d181c824b 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -124,6 +124,18 @@ void
 drm_gem_vram_plane_helper_cleanup_fb(struct drm_plane *plane,
 struct drm_plane_state *old_state);
 
+/**
+ * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
+ * Initializes struct drm_plane_helper_funcs for VRAM handling
+ *
+ * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This
+ * macro initializes struct drm_plane_helper_funcs to use the respective helper
+ * functions.
+ */
+#define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \
+   .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \
+   .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb
+
 /*
  * Helpers for struct drm_simple_display_pipe_funcs
  */
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 13/15] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default

2021-06-22 Thread Daniel Vetter

Goes through all the drivers and deletes the default hook since it's
the default now.

Acked-by: David Lechner 
Acked-by: Noralf Trønnes 
Acked-by: Oleksandr Andrushchenko 
Acked-by: Linus Walleij 
Signed-off-by: Daniel Vetter 
Cc: Joel Stanley 
Cc: Andrew Jeffery 
Cc: "Noralf Trønnes" 
Cc: Linus Walleij 
Cc: Emma Anholt 
Cc: David Lechner 
Cc: Kamlesh Gurudasani 
Cc: Oleksandr Andrushchenko 
Cc: Daniel Vetter 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Sam Ravnborg 
Cc: Alex Deucher 
Cc: Andy Shevchenko 
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xenproject.org
---
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 -
 drivers/gpu/drm/gud/gud_drv.c| 1 -
 drivers/gpu/drm/mcde/mcde_display.c  | 1 -
 drivers/gpu/drm/pl111/pl111_display.c| 1 -
 drivers/gpu/drm/tiny/hx8357d.c   | 1 -
 drivers/gpu/drm/tiny/ili9225.c   | 1 -
 drivers/gpu/drm/tiny/ili9341.c   | 1 -
 drivers/gpu/drm/tiny/ili9486.c   | 1 -
 drivers/gpu/drm/tiny/mi0283qt.c  | 1 -
 drivers/gpu/drm/tiny/repaper.c   | 1 -
 drivers/gpu/drm/tiny/st7586.c| 1 -
 drivers/gpu/drm/tiny/st7735r.c   | 1 -
 drivers/gpu/drm/tve200/tve200_display.c  | 1 -
 drivers/gpu/drm/xen/xen_drm_front_kms.c  | 1 -
 14 files changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 098f96d4d50d..827e62c1daba 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -220,7 +220,6 @@ static const struct drm_simple_display_pipe_funcs 
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
.enable_vblank  = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
 };
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index e8b672dc9832..1925df9c0fb7 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -364,7 +364,6 @@ static void gud_debugfs_init(struct drm_minor *minor)
 static const struct drm_simple_display_pipe_funcs gud_pipe_funcs = {
.check  = gud_pipe_check,
.update = gud_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static const struct drm_mode_config_funcs gud_mode_config_funcs = {
diff --git a/drivers/gpu/drm/mcde/mcde_display.c 
b/drivers/gpu/drm/mcde/mcde_display.c
index 4ddc55d58f38..ce12a36e2db4 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -1479,7 +1479,6 @@ static struct drm_simple_display_pipe_funcs 
mcde_display_funcs = {
.update = mcde_display_update,
.enable_vblank = mcde_display_enable_vblank,
.disable_vblank = mcde_display_disable_vblank,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 int mcde_display_init(struct drm_device *drm)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 6fd7f13f1aca..b5a8859739a2 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -440,7 +440,6 @@ static struct drm_simple_display_pipe_funcs 
pl111_display_funcs = {
.enable = pl111_display_enable,
.disable = pl111_display_disable,
.update = pl111_display_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static int pl111_clk_div_choose_div(struct clk_hw *hw, unsigned long rate,
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index da5df93450de..9b33c05732aa 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -184,7 +184,6 @@ static const struct drm_simple_display_pipe_funcs 
hx8357d_pipe_funcs = {
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static const struct drm_display_mode yx350hv15_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 69265d8a3beb..976d3209f164 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -328,7 +328,6 @@ static const struct drm_simple_display_pipe_funcs 
ili9225_pipe_funcs = {
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = ili9225_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static const struct drm_display_mode ili9225_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index ad9ce7b4f76f..37e0c33399c8 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -140,7 +140,6 @@ static const struct drm_simple_displ

[Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add

2021-06-22 Thread Daniel Vetter

Spotted while trying to convert panfrost to these.

Signed-off-by: Daniel Vetter 
Cc: "Christian König" 
Cc: Lucas Stach 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ba2e64ed8b47..68deb1de8235 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations);
  * @fence_array: array of dma_fence * for the job to block on.
  * @fence: the dma_fence to add to the list of dependencies.
  *
+ * This functions consumes the reference for @fence both on success and error
+ * cases.
+ *
  * Returns:
  * 0 on success, or an error on failing to expand the array.
  */
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 12/15] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

2021-06-22 Thread Daniel Vetter

It's tedious to review this all the time, and my audit showed that
arcpgu actually forgot to set this.

Make this the default and stop worrying.

Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
strange combinations of hooks: cleanup_fb without prepare_fb doesn't
make sense, and since simpler drivers are all new they better be GEM
based drivers.

v2: Warn and bail when it's _not_ a GEM driver (Noralf)

Cc: Noralf Trønnes 
Acked-by: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 12 ++--
 include/drm/drm_simple_kms_helper.h |  7 +--
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0b095a313c44..735f4f34bcc4 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -225,8 +227,14 @@ static int drm_simple_kms_plane_prepare_fb(struct 
drm_plane *plane,
struct drm_simple_display_pipe *pipe;
 
pipe = container_of(plane, struct drm_simple_display_pipe, plane);
-   if (!pipe->funcs || !pipe->funcs->prepare_fb)
-   return 0;
+   if (!pipe->funcs || !pipe->funcs->prepare_fb) {
+   if (WARN_ON_ONCE(!drm_core_check_feature(plane->dev, 
DRIVER_GEM)))
+   return 0;
+
+   WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb);
+
+   return drm_gem_simple_display_pipe_prepare_fb(pipe, state);
+   }
 
return pipe->funcs->prepare_fb(pipe, state);
 }
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index ef9944e9c5fc..363a9a8c3587 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -116,8 +116,11 @@ struct drm_simple_display_pipe_funcs {
 * the documentation for the &drm_plane_helper_funcs.prepare_fb hook for
 * more details.
 *
-* Drivers which always have their buffers pinned should use
-* drm_gem_simple_display_pipe_prepare_fb() for this hook.
+* For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook
+* set drm_gem_simple_display_pipe_prepare_fb() is called automatically
+* to implement this. Other drivers which need additional plane
+* processing can call drm_gem_simple_display_pipe_prepare_fb() from
+* their @prepare_fb hook.
 */
int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
  struct drm_plane_state *plane_state);
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 11/15] drm/omap: Follow implicit fencing in prepare_fb

2021-06-22 Thread Daniel Vetter

I guess no one ever tried running omap together with lima or panfrost,
not even sure that's possible. Anyway for consistency, fix this.

Reviewed-by: Tomi Valkeinen 
Signed-off-by: Daniel Vetter 
Cc: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 801da917507d..512af976b7e9 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "omap_dmm_tiler.h"
@@ -29,6 +30,8 @@ static int omap_plane_prepare_fb(struct drm_plane *plane,
if (!new_state->fb)
return 0;
 
+   drm_gem_plane_helper_prepare_fb(plane, new_state);
+
return omap_framebuffer_pin(new_state->fb);
 }
 
-- 
2.32.0.rc2

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

[Intel-gfx] [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi

2021-06-22 Thread Daniel Vetter

WARNING: Absolutely untested beyond "gcc isn't dying in agony".

Implicit fencing done properly needs to treat the implicit fencing
slots like a funny kind of IPC mailbox. In other words it needs to be
explicitly. This is the only way it will mesh well with explicit
fencing userspace like vk, and it's also the bare minimum required to
be able to manage anything else that wants to use the same buffer on
multiple engines in parallel, and still be able to share it through
implicit sync.

amdgpu completely lacks such an uapi. Fix this.

Luckily the concept of ignoring implicit fences exists already, and
takes care of all the complexities of making sure that non-optional
fences (like bo moves) are not ignored. This support was added in

commit 177ae09b5d699a5ebd1cafcee78889db968abf54
Author: Andres Rodriguez 
Date:   Fri Sep 15 20:44:06 2017 -0400

drm/amdgpu: introduce AMDGPU_GEM_CREATE_EXPLICIT_SYNC v2

Unfortuantely it's the wrong semantics, because it's a bo flag and
disables implicit sync on an allocated buffer completely.

We _do_ want implicit sync, but control it explicitly. For this we
need a flag on the drm_file, so that a given userspace (like vulkan)
can manage the implicit sync slots explicitly. The other side of the
pipeline (compositor, other process or just different stage in a media
pipeline in the same process) can then either do the same, or fully
participate in the implicit sync as implemented by the kernel by
default.

By building on the existing flag for buffers we avoid any issues with
opening up additional security concerns - anything this new flag here
allows is already.

All drivers which supports this concept of a userspace-specific
opt-out of implicit sync have a flag in their CS ioctl, but in reality
that turned out to be a bit too inflexible. See the discussion below,
let's try to do a bit better for amdgpu.

This alone only allows us to completely avoid any stalls due to
implicit sync, it does not yet allow us to use implicit sync as a
strange form of IPC for sync_file.

For that we need two more pieces:

- a way to get the current implicit sync fences out of a buffer. Could
  be done in a driver ioctl, but everyone needs this, and generally a
  dma-buf is involved anyway to establish the sharing. So an ioctl on
  the dma-buf makes a ton more sense:

  
https://lore.kernel.org/dri-devel/20210520190007.534046-4-ja...@jlekstrand.net/

  Current drivers in upstream solves this by having the opt-out flag
  on their CS ioctl. This has the downside that very often the CS
  which must actually stall for the implicit fence is run a while
  after the implicit fence point was logically sampled per the api
  spec (vk passes an explicit syncobj around for that afaiui), and so
  results in oversync. Converting the implicit sync fences into a
  snap-shot sync_file is actually accurate.

- Simillar we need to be able to set the exclusive implicit fence.
  Current drivers again do this with a CS ioctl flag, with again the
  same problems that the time the CS happens additional dependencies
  have been added. An explicit ioctl to only insert a sync_file (while
  respecting the rules for how exclusive and shared fence slots must
  be update in struct dma_resv) is much better. This is proposed here:

  
https://lore.kernel.org/dri-devel/20210520190007.534046-5-ja...@jlekstrand.net/

These three pieces together allow userspace to fully control implicit
fencing and remove all unecessary stall points due to them.

Well, as much as the implicit fencing model fundamentally allows:
There is only one set of fences, you can only choose to sync against
only writers (exclusive slot), or everyone. Hence suballocating
multiple buffers or anything else like this is fundamentally not
possible, and can only be fixed by a proper explicit fencing model.

Aside from that caveat this model gets implicit fencing as closely to
explicit fencing semantics as possible:

On the actual implementation I opted for a simple setparam ioctl, no
locking (just atomic reads/writes) for simplicity. There is a nice
flag parameter in the VM ioctl which we could use, except:
- it's not checked, so userspace likely passes garbage
- there's already a comment that userspace _does_ pass garbage in the
  priority field
So yeah unfortunately this flag parameter for setting vm flags is
useless, and we need to hack up a new one.

v2: Explain why a new SETPARAM (Jason)

v3: Bas noticed I forgot to hook up the dependency-side shortcut. We
need both, or this doesn't do much.

v4: Rebase over the amdgpu patch to always set the implicit sync
fences.

Cc: mesa-...@lists.freedesktop.org
Cc: Bas Nieuwenhuizen 
Cc: Dave Airlie 
Cc: Rob Clark 
Cc: Kristian H. Kristensen 
Cc: Michel Dänzer 
Cc: Daniel Stone 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Alex Deucher 
Cc: Daniel Vetter 
Cc: Deepak R Varma 
Cc: Chen Li 
Cc: Kevin Wang 
Cc: Dennis Li 
Cc: Luben Tuikov 
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/a

Re: [Intel-gfx] New uAPI for color management proposal and feedback request

2021-06-22 Thread Werner Sembach


Am 19.05.21 um 11:34 schrieb Pekka Paalanen:
> On Wed, 12 May 2021 16:04:16 +0300
> Ville Syrjälä  wrote:
>
>> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
>>> Hello,
>>>
>>> In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm 
>>> properties I propose 4 new properties:
>>> "preferred pixel encoding", "active color depth", "active color range", and 
>>> "active pixel encoding"
>>>
>>>
>>> Motivation:
>>>
>>> Current monitors have a variety pixel encodings available: RGB, YCbCr 
>>> 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0.
>>>
>>> In addition they might be full or limited RGB range and the monitors accept 
>>> different bit depths.
>>>
>>> Currently the kernel driver for AMD and Intel GPUs automatically configure 
>>> the color settings automatically with little
>>> to no influence of the user. However there are several real world scenarios 
>>> where the user might disagree with the
>>> default chosen by the drivers and wants to set his or her own preference.
>>>
>>> Some examples:
>>>
>>> 1. While RGB and YCbCr 4:4:4 in theory carry the same amount of color 
>>> information, some screens might look better on one
>>> than the other because of bad internal conversion. The driver currently 
>>> however has a fixed default that is chosen if
>>> available (RGB for Intel and YCbCr 4:4:4 for AMD). The only way to change 
>>> this currently is by editing and overloading
>>> the edid reported by the monitor to the kernel.
>>>
>>> 2. RGB and YCbCr 4:4:4 need a higher port clock then YCbCr 4:2:0. Some 
>>> hardware might report that it supports the higher
>>> port clock, but because of bad shielding on the PC, the cable, or the 
>>> monitor the screen cuts out every few seconds when
>>> RGB or YCbCr 4:4:4 encoding is used, while YCbCr 4:2:0 might just work fine 
>>> without changing hardware. The drivers
>>> currently however always default to the "best available" option even if it 
>>> might be broken.
>>>
>>> 3. Some screens natively only supporting 8-bit color, simulate 10-Bit color 
>>> by rapidly switching between 2 adjacent
>>> colors. They advertise themselves to the kernel as 10-bit monitors but the 
>>> user might not like the "fake" 10-bit effect
>>> and prefer running at the native 8-bit per color.
>>>
>>> 4. Some screens are falsely classified as full RGB range wile they actually 
>>> use limited RGB range. This results in
>>> washed out colors in dark and bright scenes. A user override can be helpful 
>>> to manually fix this issue when it occurs.
>>>
>>> There already exist several requests, discussion, and patches regarding the 
>>> thematic:
>>>
>>> - https://gitlab.freedesktop.org/drm/amd/-/issues/476
>>>
>>> - https://gitlab.freedesktop.org/drm/amd/-/issues/1548
>>>
>>> - https://lkml.org/lkml/2021/5/7/695
>>>
>>> - https://lkml.org/lkml/2021/5/11/416
>>>
> ...
>
>>> Adoption:
>>>
>>> A KDE dev wants to implement the settings in the KDE settings GUI:
>>> https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
>>>
>>> Tuxedo Computers (my employer) wants to implement the settings desktop 
>>> environment agnostic in Tuxedo Control Center. I
>>> will start work on this in parallel to implementing the new kernel code.  
>> I suspect everyone would be happier to accept new uapi if we had
>> multiple compositors signed up to implement it.
> I think having Weston support for these would be good, but for now it
> won't be much of an UI: just weston.ini to set, and the log to see what
> happened.

Since a first version of the patch set is now feature complete, please let me 
know if a MR regarding this is started.

Thanks

>
> However, knowing what happened is going to be important for color
> calibration auditing:
> https://gitlab.freedesktop.org/wayland/weston/-/issues/467
>
> Yes, please, very much for read-only properties for the feedback part.
> Properties that both userspace and kernel will write are hard to deal
> with in general.
>
> Btw. "max bpc" I can kind of guess that conversion from framebuffer
> format to the wire bpc happens automatically and only as the final
> step, but "Broadcast RGB" is more complicated: is the output from the
> abstract pixel pipeline sent as-is and "Broadcast RGB" is just another
> inforframe bit to the monitor, or does "Broadcast RGB" setting actually
> change what happens in the pixel pipeline *and* set infoframe bits?
>
> My vague recollection is that framebuffer was always assumed to be in
> full range, and then if "Broadcast RGB" was set to limited range, the
> driver would mangle the pixel pipeline to convert from full to limited
> range. This means that it would be impossible to have limited range
> data in a framebuffer, or there might be a double-conversion by
> userspace programming a LUT for limited->full and then the driver
> adding full->limited. I'm also confused how full/limited works when
> framebuffer is in RGB/YCbCr and the monitor wire format is in RGB/YCbCr
> and there may be RGB->YCbCR or YCbCR->RGB conver

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for implicit fencing/dma-resv rules for shared buffers

2021-06-22 Thread Patchwork

== Series Details ==

Series: implicit fencing/dma-resv rules for shared buffers
URL   : https://patchwork.freedesktop.org/series/91789/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fa13cbf232a0 dma-resv: Fix kerneldoc
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 6edbd6abb783 ("dma-buf: rename 
and cleanup dma_resv_get_excl v3")'
#11: 
commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9

-:35: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 1 errors, 1 warnings, 0 checks, 8 lines checked
d3ab5dc6443a dma-buf: Switch to inline kerneldoc
-:94: WARNING:TYPO_SPELLING: 'superseeded' may be misspelled - perhaps 
'superseded'?
#94: FILE: include/linux/dma-buf.h:335:
+* vmap/unmap. Note that in many cases this is superseeded by
   ^^^

-:175: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 2 warnings, 0 checks, 142 lines checked
0589bfb59341 dma-buf: Document dma-buf implicit fencing/resv fencing rules
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#15: 
https://dri.freedesktop.org/docs/drm/driver-api/dma-buf.html#reservation-objects

-:140: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit 
<12+ chars of sha1> ("")' - ie: 'commit 049aca4363d8 ("drm/amdgpu: 
fix using shared fence for exported BOs v2")'
#140: 
commit 049aca4363d8af87cab8d53de5401602db3b

-:155: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit 
<12+ chars of sha1> ("")' - ie: 'commit 9b495a588799 ("dma-buf: add 
poll support, v3")'
#155: 
commit 9b495a5887994a6d74d5c261d012083a92b94738

-:183: WARNING:REPEATED_WORD: Possible repeated word: 'to'
#183: 
  writes, and a per-bo flag to to skip implicit fencing in the CS

-:200: WARNING:TYPO_SPELLING: 'wont' may be misspelled - perhaps 'won't'?
#200: 
  wont notice the perf impact. I think we can ignore LTS distros who
  

-:233: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit 
<12+ chars of sha1> ("")' - ie: 'commit 8c505bdc9c8b ("drm/amdgpu: 
rework dma_resv handling v3")'
#233: 
commit 8c505bdc9c8b955223b054e34a0be9c3d841cd20 (drm-misc/drm-misc-next)

-:313: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 3 errors, 4 warnings, 0 checks, 45 lines checked
2662cbf1df91 drm/panfrost: Shrink sched_lock
-:41: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 17 lines checked
804e59e3e0f4 drm/panfrost: Use xarray and helpers for depedency tracking
-:254: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 197 lines checked
370f17f25d5e drm/panfrost: Fix implicit sync
-:49: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 11 lines checked
d7729f8bfaf7 drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default
-:87: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 44 lines checked
c761bfef9a8f drm/: drm_gem_plane_helper_prepare_fb is now the default
-:231: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 104 lines checked
a8e5d51acf68 drm/armada: Remove prepare/cleanup_fb hooks
-:88: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 57 lines checked
829aa12253aa drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
-:84: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 45 lines checked
07b7f877328f drm/omap: Follow implicit fencing in prepare_fb
-:33: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: 
Daniel Vetter '

total: 0 errors, 1 warnings, 0 checks, 15 lines checked
c2d4255f903b drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as 
default
-:78: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address 
mismatch: 'From: Daniel Vetter ' != 'Signed-

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for implicit fencing/dma-resv rules for shared buffers

2021-06-22 Thread Patchwork

== Series Details ==

Series: implicit fencing/dma-resv rules for shared buffers
URL   : https://patchwork.freedesktop.org/series/91789/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gem/i915_gem_ttm.c:733:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/selftests/test-drm_damage_helper.c:244:25: warning: Using 
plain integer as NULL pointer
+drivers/gpu/drm/selftests/test-drm_damage_helper.c:268:23: warning: Using 
plain integer as NULL pointer
+drivers/gpu/drm/ttm/ttm_bo.c:1157:9: warning: context imbalance in 
'ttm_bo_swapout' - unexpected unlock
+drivers/gpu/drm/ttm/ttm_bo.c:309:28: warning: context imbalance in 
'ttm_bo_cleanup_refs' - unexpected unlock
+drivers/gpu/drm/ttm/ttm_bo.c:367:27: warning: context imbalance in 
'ttm_bo_delayed_delete' - different lock contexts for basic block
+drivers/gpu/drm/ttm/ttm_bo.c:633:5: warning: context imbalance in 
'ttm_mem_evict_first' - wrong count at exit
+drivers/gpu/drm/ttm/ttm_bo_util.c:281:38:expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:281:38:got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:281:38: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:284:38:expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:284:38:got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:284:38: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:287:38:expected void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:287:38:got void [noderef] __iomem *
+drivers/gpu/drm/ttm/ttm_bo_util.c:287:38: warning: incorrect type in 
assignment (different address spaces)
+drivers/gpu/drm/ttm/ttm_bo_util.c:367:28:expected void volatile [noderef] 
__iomem *addr
+drivers/gpu/drm/ttm/ttm_bo_util.c:367:28:got void *virtual
+drivers/gpu/drm/ttm/ttm_bo_util.c:367:28: warning: incorrect type in argument 
1 (different address spaces)
+drivers/gpu/drm/ttm/ttm_device.c:130:5: warning: context imbalance in 
'ttm_device_swapout' - wrong count at exit
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/seqlock.h:840:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:840:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:866:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinloc

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: keep backlight_enable on until turn eDP display off (rev3)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: keep backlight_enable on until turn eDP display off (rev3)
URL   : https://patchwork.freedesktop.org/series/91780/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10262_full -> Patchwork_20430_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_20430_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-iclb2/igt@feature_discov...@psr2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-iclb7/igt@feature_discov...@psr2.html

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#1888] / [i915#3160])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-glk5/igt@gem_cre...@create-clear.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-glk8/igt@gem_cre...@create-clear.html

  * igt@gem_ctx_persistence@engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][6] ([i915#3354])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-snb2/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-deadline:
- shard-apl:  NOTRUN -> [FAIL][7] ([i915#2846])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-apl6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109283])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-iclb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][15] ([i915#3633])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-apl6/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#307])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-glk3/igt@gem_mmap_...@big-copy-xy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-glk1/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#307] / [i915#3468]) 
+1 similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-glk6/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][21] -> [FAIL][22] ([i915#307])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_mmap_offset@clear:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#3160])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10262/shard-skl3/igt@gem_mmap_off...@clear.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20430/shard-skl5/igt@gem_mmap_off...@clear.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][25] ([i915#2658])
   [25]: 
https://intel-gfx-ci.01.o

[Intel-gfx] ✓ Fi.CI.BAT: success for implicit fencing/dma-resv rules for shared buffers

2021-06-22 Thread Patchwork

== Series Details ==

Series: implicit fencing/dma-resv rules for shared buffers
URL   : https://patchwork.freedesktop.org/series/91789/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10263 -> Patchwork_20431


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/index.html

Known issues


  Here are the changes found in Patchwork_20431 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +15 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-7567u:   [PASS][2] -> [DMESG-FAIL][3] ([i915#2291] / 
[i915#541])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/fi-kbl-7567u/igt@i915_selftest@live@gt_heartbeat.html

  * igt@runner@aborted:
- fi-skl-guc: NOTRUN -> [FAIL][4] ([i915#2426] / [i915#3363])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/fi-skl-guc/igt@run...@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Participating hosts (43 -> 39)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10263 -> Patchwork_20431

  CI-20190529: 20190529
  CI_DRM_10263: 5b5e458879485ea4eb87d4208b95a33ee5437fcc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20431: 76d518e4d7e7790bd832f6d103b8e6a309750710 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

76d518e4d7e7 RFC: drm/amdgpu: Implement a proper implicit fencing uapi
15977ff8b76f drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
2ac97cd30e0f drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default
c2d4255f903b drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as 
default
07b7f877328f drm/omap: Follow implicit fencing in prepare_fb
829aa12253aa drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
a8e5d51acf68 drm/armada: Remove prepare/cleanup_fb hooks
c761bfef9a8f drm/: drm_gem_plane_helper_prepare_fb is now the default
d7729f8bfaf7 drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default
370f17f25d5e drm/panfrost: Fix implicit sync
804e59e3e0f4 drm/panfrost: Use xarray and helpers for depedency tracking
2662cbf1df91 drm/panfrost: Shrink sched_lock
0589bfb59341 dma-buf: Document dma-buf implicit fencing/resv fencing rules
d3ab5dc6443a dma-buf: Switch to inline kerneldoc
fa13cbf232a0 dma-resv: Fix kerneldoc

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] dma-resv: Fix kerneldoc

2021-06-22 Thread Alex Deucher

On Tue, Jun 22, 2021 at 12:55 PM Daniel Vetter  wrote:
>
> Oversight from
>
> commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> Author: Christian König 
> Date:   Mon May 10 16:14:09 2021 +0200
>
> dma-buf: rename and cleanup dma_resv_get_excl v3
>
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org

Reviewed-by: Alex Deucher 

> ---
>  include/linux/dma-resv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> index 562b885cf9c3..e1ca2080a1ff 100644
> --- a/include/linux/dma-resv.h
> +++ b/include/linux/dma-resv.h
> @@ -212,7 +212,7 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
>  }
>
>  /**
> - * dma_resv_exclusive - return the object's exclusive fence
> + * dma_resv_excl_fence - return the object's exclusive fence
>   * @obj: the reservation object
>   *
>   * Returns the exclusive fence (if any). Caller must either hold the objects
> --
> 2.32.0.rc2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/15] dma-buf: Switch to inline kerneldoc

2021-06-22 Thread Alex Deucher

On Tue, Jun 22, 2021 at 12:55 PM Daniel Vetter  wrote:
>
> Also review & update everything while we're at it.
>
> This is prep work to smash a ton of stuff into the kerneldoc for
> @resv.
>
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Nirmoy Das 
> Cc: Deepak R Varma 
> Cc: Chen Li 
> Cc: Kevin Wang 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  include/linux/dma-buf.h | 107 +++-
>  1 file changed, 83 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 92eec38a03aa..6d18b9e448b9 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -289,28 +289,6 @@ struct dma_buf_ops {
>
>  /**
>   * struct dma_buf - shared buffer object
> - * @size: size of the buffer; invariant over the lifetime of the buffer.
> - * @file: file pointer used for sharing buffers across, and for refcounting.
> - * @attachments: list of dma_buf_attachment that denotes all devices 
> attached,
> - *   protected by dma_resv lock.
> - * @ops: dma_buf_ops associated with this buffer object.
> - * @lock: used internally to serialize list manipulation, attach/detach and
> - *vmap/unmap
> - * @vmapping_counter: used internally to refcnt the vmaps
> - * @vmap_ptr: the current vmap ptr if vmapping_counter > 0
> - * @exp_name: name of the exporter; useful for debugging.
> - * @name: userspace-provided name; useful for accounting and debugging,
> - *protected by @resv.
> - * @name_lock: spinlock to protect name access
> - * @owner: pointer to exporter module; used for refcounting when exporter is 
> a
> - * kernel module.
> - * @list_node: node for dma_buf accounting and debugging.
> - * @priv: exporter specific private data for this buffer object.
> - * @resv: reservation object linked to this dma-buf
> - * @poll: for userspace poll support
> - * @cb_excl: for userspace poll support
> - * @cb_shared: for userspace poll support
> - * @sysfs_entry: for exposing information about this buffer in sysfs.
>   * The attachment_uid member of @sysfs_entry is protected by dma_resv lock
>   * and is incremented on each attach.
>   *
> @@ -324,24 +302,100 @@ struct dma_buf_ops {
>   * Device DMA access is handled by the separate &struct dma_buf_attachment.
>   */
>  struct dma_buf {
> +   /**
> +* @size:
> +*
> +* Size of the buffer; invariant over the lifetime of the buffer.
> +*/
> size_t size;
> +
> +   /**
> +* @file:
> +*
> +* File pointer used for sharing buffers across, and for refcounting.
> +* See dma_buf_get() and dma_buf_put().
> +*/
> struct file *file;
> +
> +   /**
> +* @attachments:
> +*
> +* List of dma_buf_attachment that denotes all devices attached,
> +* protected by &dma_resv lock @resv.
> +*/
> struct list_head attachments;
> +
> +   /** @ops: dma_buf_ops associated with this buffer object. */

For consistency you may want to format this like:
/**
  * @ops:
  *
  * dma_buf_ops associated with this buffer object.
  */

> const struct dma_buf_ops *ops;
> +
> +   /**
> +* @lock:
> +*
> +* Used internally to serialize list manipulation, attach/detach and
> +* vmap/unmap. Note that in many cases this is superseeded by
> +* dma_resv_lock() on @resv.
> +*/
> struct mutex lock;
> +
> +   /**
> +* @vmapping_counter:
> +*
> +* Used internally to refcnt the vmaps returned by dma_buf_vmap().
> +* Protected by @lock.
> +*/
> unsigned vmapping_counter;
> +
> +   /**
> +* @vmap_ptr:
> +* The current vmap ptr if @vmapping_counter > 0. Protected by @lock.
> +*/

Same comment as above.

> struct dma_buf_map vmap_ptr;
> +
> +   /**
> +* @exp_name:
> +*
> +* Name of the exporter; useful for debugging. See the
> +* DMA_BUF_SET_NAME IOCTL.
> +*/
> const char *exp_name;
> +
> +   /**
> +* @name:
> +*
> +* Userspace-provided name; useful for accounting and debugging,
> +* protected by dma_resv_lock() on @resv and @name_lock for read 
> access.
> +*/
> const char *name;
> +
> +   /** @name_lock: Spinlock to protect name acces for read access. */
> spinlock_t name_lock;
> +
> +   /**
> +* @owner:
> +*
> +* Pointer to exporter module; used for refcounting when exporter is a
> +* kernel module.
> +*/
> struct module *owner;
> +
> +   /** @list_node: node for dma_buf accounting and debugging. */

and here.

> struct list_head list_node;
> +
> +   /** @priv: exporter specific private data for this buffer object. */

Re: [Intel-gfx] [PATCH 02/15] dma-buf: Switch to inline kerneldoc

2021-06-22 Thread Sam Ravnborg

Hi Daniel.

On Tue, Jun 22, 2021 at 06:54:58PM +0200, Daniel Vetter wrote:
> Also review & update everything while we're at it.
> 
> This is prep work to smash a ton of stuff into the kerneldoc for
> @resv.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Nirmoy Das 
> Cc: Deepak R Varma 
> Cc: Chen Li 
> Cc: Kevin Wang 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  include/linux/dma-buf.h | 107 +++-
>  1 file changed, 83 insertions(+), 24 deletions(-)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 92eec38a03aa..6d18b9e448b9 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -289,28 +289,6 @@ struct dma_buf_ops {
>  
>  /**
>   * struct dma_buf - shared buffer object
> - * @size: size of the buffer; invariant over the lifetime of the buffer.
> - * @file: file pointer used for sharing buffers across, and for refcounting.
> - * @attachments: list of dma_buf_attachment that denotes all devices 
> attached,
> - *   protected by dma_resv lock.
> - * @ops: dma_buf_ops associated with this buffer object.
> - * @lock: used internally to serialize list manipulation, attach/detach and
> - *vmap/unmap
> - * @vmapping_counter: used internally to refcnt the vmaps
> - * @vmap_ptr: the current vmap ptr if vmapping_counter > 0
> - * @exp_name: name of the exporter; useful for debugging.
> - * @name: userspace-provided name; useful for accounting and debugging,
> - *protected by @resv.
> - * @name_lock: spinlock to protect name access
> - * @owner: pointer to exporter module; used for refcounting when exporter is 
> a
> - * kernel module.
> - * @list_node: node for dma_buf accounting and debugging.
> - * @priv: exporter specific private data for this buffer object.
> - * @resv: reservation object linked to this dma-buf
> - * @poll: for userspace poll support
> - * @cb_excl: for userspace poll support
> - * @cb_shared: for userspace poll support
> - * @sysfs_entry: for exposing information about this buffer in sysfs.

This sentence
>   * The attachment_uid member of @sysfs_entry is protected by dma_resv lock
>   * and is incremented on each attach.
belongs to the paragraph describing sysfs_entry and should be moved too.
Or maybe reworded and then document all fields in dma_buf_sysfs_entry?

With this fixed:
Acked-by: Sam Ravnborg 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] dma-resv: Fix kerneldoc

2021-06-22 Thread Sam Ravnborg

Hi Daniel,

On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> Oversight from
> 
> commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> Author: Christian König 
> Date:   Mon May 10 16:14:09 2021 +0200

this is what we uses Fixes: ... for.

It looks wrong to hide it in the description.

Sam

> 
> dma-buf: rename and cleanup dma_resv_get_excl v3
> 
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
>  include/linux/dma-resv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> index 562b885cf9c3..e1ca2080a1ff 100644
> --- a/include/linux/dma-resv.h
> +++ b/include/linux/dma-resv.h
> @@ -212,7 +212,7 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
>  }
>  
>  /**
> - * dma_resv_exclusive - return the object's exclusive fence
> + * dma_resv_excl_fence - return the object's exclusive fence
>   * @obj: the reservation object
>   *
>   * Returns the exclusive fence (if any). Caller must either hold the objects
> -- 
> 2.32.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/15] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default

2021-06-22 Thread Sam Ravnborg

Hi Daniel,

On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> There's a bunch of atomic drivers who don't do this quite correctly,
> luckily most of them aren't in wide use or people would have noticed
> the tearing.
> 
> By making this the default we avoid the constant audit pain and can
> additionally remove a ton of lines from vfuncs for a bit more clarity
> in smaller drivers.
> 
> While at it complain if there's a cleanup_fb hook but no prepare_fb
> hook, because that makes no sense. I haven't found any driver which
> violates this, but better safe than sorry.
> 
> Subsequent patches will reap the benefits.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  | 10 ++
>  drivers/gpu/drm/drm_gem_atomic_helper.c  |  3 +++
>  include/drm/drm_modeset_helper_vtables.h |  7 +--
>  3 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 531f2374b072..9f6c5f21c4d6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2408,6 +2409,15 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
> *dev,
>   ret = funcs->prepare_fb(plane, new_plane_state);
>   if (ret)
>   goto fail;
> + } else {
> + WARN_ON_ONCE(funcs->cleanup_fb);
> +
> + if (!drm_core_check_feature(dev, DRIVER_GEM))
> + continue;
> +
> + ret = drm_gem_plane_helper_prepare_fb(plane, 
> new_plane_state);
> + if (ret)
> + goto fail;
>   }
>   }
>  
> diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c 
> b/drivers/gpu/drm/drm_gem_atomic_helper.c
> index a27135084ae5..bc9396f2a0ed 100644
> --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> @@ -135,6 +135,9 @@
>   * GEM based framebuffer drivers which have their buffers always pinned in
>   * memory.
>   *
> + * This function is the default implementation for GEM drivers of
> + * &drm_plane_helper_funcs.prepare_fb if no callback is provided.
> + *
>   * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
>   * explicit fencing in atomic modeset updates.
>   */
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index f3a4b47b3986..4e727261dca5 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1178,8 +1178,11 @@ struct drm_plane_helper_funcs {
>* equivalent functionality should be implemented through private
>* members in the plane structure.
>*
> -  * Drivers which always have their buffers pinned should use
> -  * drm_gem_plane_helper_prepare_fb() for this hook.
> +  * For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook
s/not/nor/ ??
> +  * set drm_gem_plane_helper_prepare_fb() is called automatically to
  ^add comma?
> +  * implement this.


Leave cleanup_fb out of the description to make it more readable.
In the description of cleanup_fb you can document that it is wrong to
have it without a matcching prepare_fb if you feel for it.

Sam


 * Other drivers which need additional plane processing
> +  * can call drm_gem_plane_helper_prepare_fb() from their @prepare_fb
> +  * hook.
>*
>* The helpers will call @cleanup_fb with matching arguments for every
>* successful call to this hook.
> -- 
> 2.32.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for implicit fencing/dma-resv rules for shared buffers

2021-06-22 Thread Patchwork

== Series Details ==

Series: implicit fencing/dma-resv rules for shared buffers
URL   : https://patchwork.freedesktop.org/series/91789/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10263_full -> Patchwork_20431_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20431_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20431_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20431_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_cursor_legacy@all-pipes-torture-bo:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-tglb3/igt@kms_cursor_leg...@all-pipes-torture-bo.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-tglb6/igt@kms_cursor_leg...@all-pipes-torture-bo.html

  
Known issues


  Here are the changes found in Patchwork_20431_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#180]) +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@process:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-snb6/igt@gem_ctx_persiste...@process.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-glk7/igt@gem_exec_fair@basic-p...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-skl:  [PASS][10] -> [FAIL][11] ([i915#307])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-skl2/igt@gem_mmap_...@big-copy-xy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-skl8/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#307])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-apl3/igt@gem_pr...@exhaustion.html
- shard-snb:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-snb7/igt@gem_pr...@exhaustion.html

  * igt@gen7_exec_parse@basic-offset:
- shard-apl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +226 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-apl1/igt@gen7_exec_pa...@basic-offset.html

  * igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: NOTRUN -> [WARN][17] ([i915#1804] / [i915#2684])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-iclb7/igt@i915_pm_rc6_reside...@rc6-fence.html

  * igt@i915_suspend@debugfs-reader:
- shard-kbl:  [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-kbl7/igt@i915_susp...@debugfs-reader.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-kbl2/igt@i915_susp...@debugfs-reader.html

  * igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#2521])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-skl10/igt@kms_async_fl...@alternate-sync-async-flip.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20431/shard-skl10/igt@kms_async_fl...@alternate-sync-async-flip.html

  *

Re: [Intel-gfx] [PATCH 12/15] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default

2021-06-22 Thread Sam Ravnborg

Hi Daniel,

On Tue, Jun 22, 2021 at 06:55:08PM +0200, Daniel Vetter wrote:
> It's tedious to review this all the time, and my audit showed that
> arcpgu actually forgot to set this.
> 
> Make this the default and stop worrying.
> 
> Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
> strange combinations of hooks: cleanup_fb without prepare_fb doesn't
> make sense, and since simpler drivers are all new they better be GEM
> based drivers.
> 
> v2: Warn and bail when it's _not_ a GEM driver (Noralf)
> 
> Cc: Noralf Trønnes 
> Acked-by: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 12 ++--
>  include/drm/drm_simple_kms_helper.h |  7 +--
>  2 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0b095a313c44..735f4f34bcc4 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -9,6 +9,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -225,8 +227,14 @@ static int drm_simple_kms_plane_prepare_fb(struct 
> drm_plane *plane,
>   struct drm_simple_display_pipe *pipe;
>  
>   pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> - if (!pipe->funcs || !pipe->funcs->prepare_fb)
> - return 0;
> + if (!pipe->funcs || !pipe->funcs->prepare_fb) {
> + if (WARN_ON_ONCE(!drm_core_check_feature(plane->dev, 
> DRIVER_GEM)))
> + return 0;
> +
> + WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb);
> +
> + return drm_gem_simple_display_pipe_prepare_fb(pipe, state);
> + }
>  
>   return pipe->funcs->prepare_fb(pipe, state);
>  }
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index ef9944e9c5fc..363a9a8c3587 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -116,8 +116,11 @@ struct drm_simple_display_pipe_funcs {
>* the documentation for the &drm_plane_helper_funcs.prepare_fb hook for
>* more details.
>*
> -  * Drivers which always have their buffers pinned should use
> -  * drm_gem_simple_display_pipe_prepare_fb() for this hook.
> +  * For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook
> +  * set drm_gem_simple_display_pipe_prepare_fb() is called automatically
> +  * to implement this.
Same comments like before.

Sam

 * Other drivers which need additional plane
> +  * processing can call drm_gem_simple_display_pipe_prepare_fb() from
> +  * their @prepare_fb hook.
>*/
>   int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *plane_state);
> -- 
> 2.32.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/15] dma-resv: Fix kerneldoc

2021-06-22 Thread Daniel Vetter

On Tue, Jun 22, 2021 at 8:50 PM Sam Ravnborg  wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:54:57PM +0200, Daniel Vetter wrote:
> > Oversight from
> >
> > commit 6edbd6abb783d54f6ac4c3ed5cd9e50cff6c15e9
> > Author: Christian König 
> > Date:   Mon May 10 16:14:09 2021 +0200
>
> this is what we uses Fixes: ... for.
>
> It looks wrong to hide it in the description.

I've honestly become a bit vary of using Fixes: for docs/comments
because the stable autoselect bots are _really_ keen on picking up
anything with a Fixes: line in it. And that feels a bit like nonsense.
-Daniel

>
> Sam
>
> >
> > dma-buf: rename and cleanup dma_resv_get_excl v3
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: "Christian König" 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > ---
> >  include/linux/dma-resv.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> > index 562b885cf9c3..e1ca2080a1ff 100644
> > --- a/include/linux/dma-resv.h
> > +++ b/include/linux/dma-resv.h
> > @@ -212,7 +212,7 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
> >  }
> >
> >  /**
> > - * dma_resv_exclusive - return the object's exclusive fence
> > + * dma_resv_excl_fence - return the object's exclusive fence
> >   * @obj: the reservation object
> >   *
> >   * Returns the exclusive fence (if any). Caller must either hold the 
> > objects
> > --
> > 2.32.0.rc2



-- 
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 02/15] dma-buf: Switch to inline kerneldoc

2021-06-22 Thread Daniel Vetter

On Tue, Jun 22, 2021 at 9:01 PM Sam Ravnborg  wrote:
>
> Hi Daniel.
>
> On Tue, Jun 22, 2021 at 06:54:58PM +0200, Daniel Vetter wrote:
> > Also review & update everything while we're at it.
> >
> > This is prep work to smash a ton of stuff into the kerneldoc for
> > @resv.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: "Christian König" 
> > Cc: Alex Deucher 
> > Cc: Daniel Vetter 
> > Cc: Dave Airlie 
> > Cc: Nirmoy Das 
> > Cc: Deepak R Varma 
> > Cc: Chen Li 
> > Cc: Kevin Wang 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > ---
> >  include/linux/dma-buf.h | 107 +++-
> >  1 file changed, 83 insertions(+), 24 deletions(-)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 92eec38a03aa..6d18b9e448b9 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -289,28 +289,6 @@ struct dma_buf_ops {
> >
> >  /**
> >   * struct dma_buf - shared buffer object
> > - * @size: size of the buffer; invariant over the lifetime of the buffer.
> > - * @file: file pointer used for sharing buffers across, and for 
> > refcounting.
> > - * @attachments: list of dma_buf_attachment that denotes all devices 
> > attached,
> > - *   protected by dma_resv lock.
> > - * @ops: dma_buf_ops associated with this buffer object.
> > - * @lock: used internally to serialize list manipulation, attach/detach and
> > - *vmap/unmap
> > - * @vmapping_counter: used internally to refcnt the vmaps
> > - * @vmap_ptr: the current vmap ptr if vmapping_counter > 0
> > - * @exp_name: name of the exporter; useful for debugging.
> > - * @name: userspace-provided name; useful for accounting and debugging,
> > - *protected by @resv.
> > - * @name_lock: spinlock to protect name access
> > - * @owner: pointer to exporter module; used for refcounting when exporter 
> > is a
> > - * kernel module.
> > - * @list_node: node for dma_buf accounting and debugging.
> > - * @priv: exporter specific private data for this buffer object.
> > - * @resv: reservation object linked to this dma-buf
> > - * @poll: for userspace poll support
> > - * @cb_excl: for userspace poll support
> > - * @cb_shared: for userspace poll support
> > - * @sysfs_entry: for exposing information about this buffer in sysfs.
>
> This sentence
> >   * The attachment_uid member of @sysfs_entry is protected by dma_resv lock
> >   * and is incremented on each attach.
> belongs to the paragraph describing sysfs_entry and should be moved too.
> Or maybe reworded and then document all fields in dma_buf_sysfs_entry?

Unfortunately kerneldoc lost the ability to document embedded
structs/unions. At least last time I checked, it's a bit a bikeshed.
So I'd need to pull the entire struct out. I'll just move it since
it's indeed misplaced.

> With this fixed:
> Acked-by: Sam Ravnborg 

Thanks for taking a look.
-Daniel
-- 
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] ALSA: hda: Release display power reference during shutdown/reboot

2021-06-22 Thread Imre Deak

On Tue, Jun 22, 2021 at 04:18:14PM +0200, Takashi Iwai wrote:
> On Mon, 21 Jun 2021 19:44:15 +0200,
> Imre Deak wrote:
> > 
> > Make sure the HDA driver's display power reference is released during
> > shutdown/reboot.
> > 
> > During the shutdown/reboot sequence the pci device core calls the
> > pm_runtime_resume handler for all devices before calling the driver's
> > shutdown callback and so the HDA driver's runtime resume callback will
> > acquire a display power reference (on HSW/BDW). This triggers a power
> > reference held WARN on HSW/BDW in the i915 driver's subsequent shutdown
> > handler, which expects all display power references to be released by
> > that time.
> > 
> > Since the HDA controller is stopped in the shutdown handler in any case,
> > let's follow here the same sequence as the one during runtime suspend.
> > This will also reset the HDA link and drop the display power reference,
> > getting rid of the above WARN.
> 
> As kbuild bot suggested, __azx_runtime_suspend() is defined only with
> CONFIG_PM.  We need either moving the function out of ifdef CONFIG_PM
> block, or having CONFIG_PM conditional call there.

Thanks, missed that. I think we need to drop the power ref in the !CONFIG_PM
case as well (since AFAICS then the ref is held after the device is probed), so
I'd move __azx_runtime_suspend() out of the CONFIG_PM block (and perhaps rename
it to azx_shutdown_chip).

> I myself have no much preference,  but maybe the latter can be easier
> to be cherry-picked to stable kernels.

To my knowledge this only fixes the book-keeping in the i915 driver, so
not sure if it's a stable material.

Trying things now with !CONFIG_PM, I noticed that the HDA codec would still
keep a separate power reference (which was dropped for me with CONFIG_PM, as
the codec was runtime suspended). To fix that we'd need something like the
following (on top of the above changes in a separate patch), any
comments on it?:

diff --git a/include/sound/core.h b/include/sound/core.h
index c4ade121727df..5228dec658ad6 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -61,6 +61,7 @@ struct snd_device_ops {
int (*dev_free)(struct snd_device *dev);
int (*dev_register)(struct snd_device *dev);
int (*dev_disconnect)(struct snd_device *dev);
+   void (*dev_shutdown)(struct snd_device *dev);
 };
 
 struct snd_device {
@@ -314,6 +315,7 @@ void snd_device_disconnect(struct snd_card *card, void 
*device_data);
 void snd_device_disconnect_all(struct snd_card *card);
 void snd_device_free(struct snd_card *card, void *device_data);
 void snd_device_free_all(struct snd_card *card);
+void snd_device_shutdown_all(struct snd_card *card);
 int snd_device_get_state(struct snd_card *card, void *device_data);
 
 /* isadma.c */
diff --git a/sound/core/device.c b/sound/core/device.c
index bf0b04a7ee797..7c695f8a72f5b 100644
--- a/sound/core/device.c
+++ b/sound/core/device.c
@@ -238,6 +238,17 @@ void snd_device_free_all(struct snd_card *card)
__snd_device_free(dev);
 }
 
+void snd_device_shutdown_all(struct snd_card *card)
+{
+   struct snd_device *dev;
+
+   list_for_each_entry_reverse(dev, &card->devices, list) {
+   if (dev->ops->dev_shutdown)
+   dev->ops->dev_shutdown(dev);
+   }
+}
+EXPORT_SYMBOL_GPL(snd_device_shutdown_all);
+
 /**
  * snd_device_get_state - Get the current state of the given device
  * @card: the card instance
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 5462f771c2f90..6da105bc57f58 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -866,6 +866,13 @@ static void snd_hda_codec_dev_release(struct device *dev)
kfree(codec);
 }
 
+static void snd_hda_codec_dev_shutdown(struct snd_device *device)
+{
+   struct hda_codec *codec = device->device_data;
+
+   codec_display_power(codec, false);
+}
+
 #define DEV_NAME_LEN 31
 
 static int snd_hda_codec_device_init(struct hda_bus *bus, struct snd_card 
*card,
@@ -930,6 +937,7 @@ int snd_hda_codec_device_new(struct hda_bus *bus, struct 
snd_card *card,
static const struct snd_device_ops dev_ops = {
.dev_register = snd_hda_codec_dev_register,
.dev_free = snd_hda_codec_dev_free,
+   .dev_shutdown = snd_hda_codec_dev_shutdown,
};
 
dev_dbg(card->dev, "%s: entry\n", __func__);
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index f5ab0b682adcc..6ca05c6633fc6 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2382,8 +2382,10 @@ static void azx_shutdown(struct pci_dev *pci)
if (!card)
return;
chip = card->private_data;
-   if (chip && chip->running)
+   if (chip && chip->running) {
+   snd_device_shutdown_all(card);
azx_shutdown_chip(chip);
+   }
 }
 
 /* PCI IDs */

> thanks,
> 
> Takashi
___

[Intel-gfx] ✗ Fi.CI.BUILD: failure for ALSA: hda: Release display power reference during shutdown/reboot (rev2)

2021-06-22 Thread Patchwork

== Series Details ==

Series: ALSA: hda: Release display power reference during shutdown/reboot (rev2)
URL   : https://patchwork.freedesktop.org/series/91742/
State : failure

== Summary ==

Applying: ALSA: hda: Release display power reference during shutdown/reboot
error: sha1 information is lacking or useless (sound/pci/hda/hda_intel.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 ALSA: hda: Release display power reference during 
shutdown/reboot
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

Re: [Intel-gfx] [PATCH 07/15] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default

2021-06-22 Thread Daniel Vetter

On Tue, Jun 22, 2021 at 9:10 PM Sam Ravnborg  wrote:
>
> Hi Daniel,
>
> On Tue, Jun 22, 2021 at 06:55:03PM +0200, Daniel Vetter wrote:
> > There's a bunch of atomic drivers who don't do this quite correctly,
> > luckily most of them aren't in wide use or people would have noticed
> > the tearing.
> >
> > By making this the default we avoid the constant audit pain and can
> > additionally remove a ton of lines from vfuncs for a bit more clarity
> > in smaller drivers.
> >
> > While at it complain if there's a cleanup_fb hook but no prepare_fb
> > hook, because that makes no sense. I haven't found any driver which
> > violates this, but better safe than sorry.
> >
> > Subsequent patches will reap the benefits.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 10 ++
> >  drivers/gpu/drm/drm_gem_atomic_helper.c  |  3 +++
> >  include/drm/drm_modeset_helper_vtables.h |  7 +--
> >  3 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 531f2374b072..9f6c5f21c4d6 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -35,6 +35,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -2408,6 +2409,15 @@ int drm_atomic_helper_prepare_planes(struct 
> > drm_device *dev,
> >   ret = funcs->prepare_fb(plane, new_plane_state);
> >   if (ret)
> >   goto fail;
> > + } else {
> > + WARN_ON_ONCE(funcs->cleanup_fb);
> > +
> > + if (!drm_core_check_feature(dev, DRIVER_GEM))
> > + continue;
> > +
> > + ret = drm_gem_plane_helper_prepare_fb(plane, 
> > new_plane_state);
> > + if (ret)
> > + goto fail;
> >   }
> >   }
> >
> > diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c 
> > b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > index a27135084ae5..bc9396f2a0ed 100644
> > --- a/drivers/gpu/drm/drm_gem_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
> > @@ -135,6 +135,9 @@
> >   * GEM based framebuffer drivers which have their buffers always pinned in
> >   * memory.
> >   *
> > + * This function is the default implementation for GEM drivers of
> > + * &drm_plane_helper_funcs.prepare_fb if no callback is provided.
> > + *
> >   * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
> >   * explicit fencing in atomic modeset updates.
> >   */
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index f3a4b47b3986..4e727261dca5 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -1178,8 +1178,11 @@ struct drm_plane_helper_funcs {
> >* equivalent functionality should be implemented through private
> >* members in the plane structure.
> >*
> > -  * Drivers which always have their buffers pinned should use
> > -  * drm_gem_plane_helper_prepare_fb() for this hook.
> > +  * For GEM drivers who neither have a @prepare_fb not @cleanup_fb hook
> s/not/nor/ ??

Yup.

> > +  * set drm_gem_plane_helper_prepare_fb() is called automatically to
>   ^add comma?
> > +  * implement this.
>
>
> Leave cleanup_fb out of the description to make it more readable.

With the not->nor typo fixed, why does this make it more readable?
Afaiui neither ... nor ... is fairly standard English, and I really
want to make this the default only if you specify absolutely no plane
fb handling of your own.

> In the description of cleanup_fb you can document that it is wrong to
> have it without a matcching prepare_fb if you feel for it.

So the reason I didn't document things that way is that imo the
"cleanup_fb  but not prepare_fb" case is just nonsense. But I also
didn't want to accidentally paper over bugs where people set only
cleanup_fb and forget to hook up the other one, hence the warning. But
if you think we should explain that in docs, I guess I can shuffle it
around. Just feel like specifying everything in the comments doesn't
help the readability of the docs.
-Daniel

>
> Sam
>
>
>  * Other drivers which need additional plane processing
> > +  * can call drm_gem_plane_helper_prepare_fb() from their @prepare_fb
> > +  * hook.
> >*
> >* The helpers will call @cleanup_fb with matching arguments for every
> >* successful call to this hook.
> > --
> > 2.32.0.rc2



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-g

[Intel-gfx] [PATCH 1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12

2021-06-22 Thread Lucas De Marchi

We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
Instead spec says to add 3usec (as opposed to 2) to each valid level
when punit replies 0 to level 0.

So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set
the proper adjustement value when handling WaWmMemoryReadLatency.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_dram.c |  3 +--
 drivers/gpu/drm/i915/intel_pm.c   | 13 +++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dram.c 
b/drivers/gpu/drm/i915/intel_dram.c
index 50fdea84ba70..879b0f007be3 100644
--- a/drivers/gpu/drm/i915/intel_dram.c
+++ b/drivers/gpu/drm/i915/intel_dram.c
@@ -484,8 +484,7 @@ static int gen11_get_dram_info(struct drm_i915_private 
*i915)
 
 static int gen12_get_dram_info(struct drm_i915_private *i915)
 {
-   /* Always needed for GEN12+ */
-   i915->dram_info.wm_lv_0_adjust_needed = true;
+   i915->dram_info.wm_lv_0_adjust_needed = false;
 
return icl_pcode_read_mem_global_info(i915);
 }
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ef8d9b2284b3..be2931d54b95 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2911,18 +2911,20 @@ static void intel_read_wm_latency(struct 
drm_i915_private *dev_priv,
}
 
/*
-* WaWmMemoryReadLatency:skl+,glk
+* WaWmMemoryReadLatency
 *
 * punit doesn't take into account the read latency so we need
-* to add 2us to the various latency levels we retrieve from the
-* punit when level 0 response data us 0us.
+* to add proper adjustement to each valid level we retrieve
+* from the punit when level 0 response data is 0us.
 */
if (wm[0] == 0) {
-   wm[0] += 2;
+   u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
+
+   wm[0] += adjust;
for (level = 1; level <= max_level; level++) {
if (wm[level] == 0)
break;
-   wm[level] += 2;
+   wm[level] += adjust;
}
}
 
@@ -2934,7 +2936,6 @@ static void intel_read_wm_latency(struct drm_i915_private 
*dev_priv,
 */
if (dev_priv->dram_info.wm_lv_0_adjust_needed)
wm[0] += 1;
-
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
 
-- 
2.31.1

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

[Intel-gfx] [PATCH 2/2] drm/i915/display: use max_level to control loop

2021-06-22 Thread Lucas De Marchi

Since we are already loop through the levels to sanitize them, mark what
is the real max_level so it can be used in subsequent loop. This makes
it simpler to later add the adjsutement latency to "valid levels". No
change in behavior, just makes the code easier to follow.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_pm.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index be2931d54b95..6b6474d4f204 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2906,6 +2906,9 @@ static void intel_read_wm_latency(struct drm_i915_private 
*dev_priv,
if (wm[level] == 0) {
for (i = level + 1; i <= max_level; i++)
wm[i] = 0;
+
+   max_level = level - 1;
+
break;
}
}
@@ -2920,12 +2923,8 @@ static void intel_read_wm_latency(struct 
drm_i915_private *dev_priv,
if (wm[0] == 0) {
u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
 
-   wm[0] += adjust;
-   for (level = 1; level <= max_level; level++) {
-   if (wm[level] == 0)
-   break;
+   for (level = 0; level <= max_level; level++)
wm[level] += adjust;
-   }
}
 
/*
-- 
2.31.1

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

Re: [Intel-gfx] [PATCH] drm/i915: return DRIVER_NAME for the fence driver name

2021-06-22 Thread Mason, Michael W

This fixes the NULL pointer dereference in i915_fence_get_driver_name(), 
but now it crashes in i915_fence_get_timeline with another NULL pointer
dereference. It attempts to use i915_gem_context.name, which apparently
also hasn't been initialized

static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
{
const struct i915_gem_context *ctx;

/*
 * The timeline struct (as part of the ppgtt underneath a context)
 * may be freed when the request is no longer in use by the GPU.
 * We could extend the life of a context to beyond that of all
 * fences, possibly keeping the hw resource around indefinitely,
 * or we just give them a false name. Since
 * dma_fence_ops.get_timeline_name is a debug feature, the occasional
 * lie seems justifiable.
 */
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return "signaled";

ctx = i915_request_gem_context(to_request(fence));
if (!ctx)
return "[" DRIVER_NAME "]";

return ctx->name;
}

<1>[  414.327761] BUG: kernel NULL pointer dereference, address: 
0020
<1>[  414.327766] #PF: supervisor read access in kernel mode
<1>[  414.327768] #PF: error_code(0x) - not-present page
<6>[  414.327769] PGD 0 P4D 0
<4>[  414.327772] Oops:  [#1] PREEMPT SMP NOPTI
<4>[  414.327774] CPU: 3 PID: 1866 Comm: chrome Tainted: G U
5.4.125 #2
<4>[  414.327776] Hardware name: Google Voxel/Voxel, BIOS 
Google_Voxel.13913.0.0 04/12/2021
<4>[  414.327781] RIP: 0010:i915_fence_get_timeline_name+0x1d/0x37
<4>[  414.327783] Code: 55 48 89 e5 48 c7 c0 ee d1 72 bd 5d c3 0f 1f 44 00 00 
55 48 89 e5 48 8b 4f 30 48 c7 c0 b4 49 72 bd f6 c1 01 75 1c 48 8b 47 60 <48> 8b 
40 20 48 85 c0 74 08 48 05 30 01 00 00 eb 07 48 c7 c0 79 7b
<4>[  414.327785] RSP: 0018:a4a300d177b8 EFLAGS: 00010246
<4>[  414.327787] RAX:  RBX: bd7a8680 RCX: 

<4>[  414.327788] RDX: 9c27b3b0f4c0 RSI: 9c27b3b0f480 RDI: 
9c27b3b0f480
<4>[  414.327789] RBP: a4a300d177b8 R08:  R09: 
0004
<4>[  414.327791] R10: 0001 R11: bca45536 R12: 
0005
<4>[  414.327792] R13: 0004 R14: 9c27b6c79bb0 R15: 
9c27b3b0f480
<4>[  414.327794] FS:  7898a2965e00() GS:9c27b7f8() 
knlGS:
<4>[  414.327795] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  414.327797] CR2: 0020 CR3: 00022ded2006 CR4: 
00762ee0
<4>[  414.327798] PKRU: 5554
<4>[  414.327799] Call Trace:
<4>[  414.327804]  trace_event_raw_event_dma_fence+0xc9/0x1e5
<4>[  414.327807]  dma_fence_init+0xa6/0xca
<4>[  414.327809]  __i915_request_ctor+0x7f/0xa9
<4>[  414.327812]  setup_object+0x88/0x8a
<4>[  414.327815]  new_slab+0x22e/0x429
<4>[  414.327817]  ___slab_alloc+0x2c8/0x42e
<4>[  414.327820]  ? __i915_request_create+0x68/0x238
<4>[  414.327822]  ? __i915_request_create+0x68/0x238
<4>[  414.327824]  __slab_alloc+0x3c/0x5f
<4>[  414.327826]  kmem_cache_alloc+0x19b/0x201
<4>[  414.327828]  __i915_request_create+0x68/0x238
<4>[  414.327830]  i915_request_create+0x8a/0xca
<4>[  414.327833]  i915_gem_do_execbuffer+0x12f9/0x1830
<4>[  414.327837]  i915_gem_execbuffer2_ioctl+0x157/0x398
<4>[  414.327839]  ? i915_gem_do_execbuffer+0x1830/0x1830
<4>[  414.327840]  drm_ioctl_kernel+0x94/0xf6
<4>[  414.327842]  drm_ioctl+0x276/0x39b
<4>[  414.327845]  ? i915_gem_do_execbuffer+0x1830/0x1830
<4>[  414.327847]  do_vfs_ioctl+0x4f4/0x771
<4>[  414.327849]  ksys_ioctl+0x58/0x83
<4>[  414.327851]  __x64_sys_ioctl+0x1a/0x1e
<4>[  414.327853]  do_syscall_64+0x54/0x7e
<4>[  414.327856]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
<4>[  414.327859] RIP: 0033:0x7898a2f88f07

> -Original Message-
> From: Auld, Matthew 
> Sent: Wednesday, June 16, 2021 5:29 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Mason, Michael W
> ; Daniel Vetter 
> Subject: [PATCH] drm/i915: return DRIVER_NAME for the fence driver name
> 
> The first tracepoint for a request is trace_dma_fence_init which is called in
> the ctor before we have properly setup the request->engine. So if it's a non-
> recycled request the rq->engine might be NULL, or some garbage value,
> which leads to a crash.
> 
> Since we are not permitted to use kmem_cache_zalloc() here with
> SLAB_TYPESAFE_BY_RCU, one approach is simply to return DRIVER_NAME.
> We can then revisit this later if we decide to get rid of
> SLAB_TYPESAFE_BY_RCU.
> 
> Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring
> seqno")
> Signed-off-by: Matthew Auld 
> Cc: Michael Mason 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 1014c71cf7f5..55fa94bde22e 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_requ

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12

2021-06-22 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on 
display ver >= 12
URL   : https://patchwork.freedesktop.org/series/91791/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10263 -> Patchwork_20433


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/index.html

Known issues


  Here are the changes found in Patchwork_20433 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
  [i915#750]: https://gitlab.freedesktop.org/drm/intel/issues/750


Participating hosts (43 -> 39)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10263 -> Patchwork_20433

  CI-20190529: 20190529
  CI_DRM_10263: 5b5e458879485ea4eb87d4208b95a33ee5437fcc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20433: aa8203c26b33bf9be5342c9a728d2ebe1450094a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

aa8203c26b33 drm/i915/display: use max_level to control loop
d54be848fa4e drm/i915/display: fix level 0 adjustement on display ver >= 12

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12

2021-06-22 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on 
display ver >= 12
URL   : https://patchwork.freedesktop.org/series/91791/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10263_full -> Patchwork_20433_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20433_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20433_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20433_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_dc@dc5-psr:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-iclb4/igt@i915_pm...@dc5-psr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb8/igt@i915_pm...@dc5-psr.html

  * igt@kms_vblank@pipe-c-ts-continuation-idle-hang:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-tglb1/igt@kms_vbl...@pipe-c-ts-continuation-idle-hang.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-tglb7/igt@kms_vbl...@pipe-c-ts-continuation-idle-hang.html

  
 Warnings 

  * igt@runner@aborted:
- shard-iclb: ([FAIL][5], [FAIL][6], [FAIL][7]) ([i915#1814] / 
[i915#3002]) -> ([FAIL][8], [FAIL][9], [FAIL][10]) ([i915#3002])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-iclb3/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-iclb1/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-iclb2/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb8/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb8/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb2/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_20433_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-apl7/igt@gem_ctx_isolation@preservation...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@gem_ctx_persistence@legacy-engines-queued:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][14] -> [SKIP][15] ([fdo#109271])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-apl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-apl:  NOTRUN -> [FAIL][16] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_mmap_gtt@cpuset-medium-copy-xy:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2428])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-iclb7/igt@gem_mmap_...@cpuset-medium-copy-xy.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][19] -> [FAIL][20] ([i915#644])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10263/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][21] ([i915#2658])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-apl3/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-snb:  NOTRUN -> [WARN][22] ([i915#2658])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20433/shard-snb5/igt@gem_pwr...@basic-exhaustion.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][23] -> [FAIL][

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12

2021-06-22 Thread Matt Roper

On Tue, Jun 22, 2021 at 02:22:09PM -0700, Lucas De Marchi wrote:
> We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
> Instead spec says to add 3usec (as opposed to 2) to each valid level
> when punit replies 0 to level 0.
> 
> So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set
> the proper adjustement value when handling WaWmMemoryReadLatency.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_dram.c |  3 +--
>  drivers/gpu/drm/i915/intel_pm.c   | 13 +++--
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dram.c 
> b/drivers/gpu/drm/i915/intel_dram.c
> index 50fdea84ba70..879b0f007be3 100644
> --- a/drivers/gpu/drm/i915/intel_dram.c
> +++ b/drivers/gpu/drm/i915/intel_dram.c
> @@ -484,8 +484,7 @@ static int gen11_get_dram_info(struct drm_i915_private 
> *i915)
>  
>  static int gen12_get_dram_info(struct drm_i915_private *i915)
>  {
> - /* Always needed for GEN12+ */
> - i915->dram_info.wm_lv_0_adjust_needed = true;
> + i915->dram_info.wm_lv_0_adjust_needed = false;
>  
>   return icl_pcode_read_mem_global_info(i915);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ef8d9b2284b3..be2931d54b95 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2911,18 +2911,20 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>   }
>  
>   /*
> -  * WaWmMemoryReadLatency:skl+,glk
> +  * WaWmMemoryReadLatency
>*
>* punit doesn't take into account the read latency so we need
> -  * to add 2us to the various latency levels we retrieve from the
> -  * punit when level 0 response data us 0us.
> +  * to add proper adjustement to each valid level we retrieve
> +  * from the punit when level 0 response data is 0us.
>*/
>   if (wm[0] == 0) {
> - wm[0] += 2;
> + u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
> +
> + wm[0] += adjust;
>   for (level = 1; level <= max_level; level++) {
>   if (wm[level] == 0)
>   break;
> - wm[level] += 2;
> + wm[level] += adjust;
>   }
>   }
>  
> @@ -2934,7 +2936,6 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>*/
>   if (dev_priv->dram_info.wm_lv_0_adjust_needed)
>   wm[0] += 1;
> -
>   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
>  
> -- 
> 2.31.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: use max_level to control loop

2021-06-22 Thread Matt Roper

On Tue, Jun 22, 2021 at 02:22:10PM -0700, Lucas De Marchi wrote:
> Since we are already loop through the levels to sanitize them, mark what
> is the real max_level so it can be used in subsequent loop. This makes
> it simpler to later add the adjsutement latency to "valid levels". No

Minor typo in "adjustment."

Reviewed-by: Matt Roper 

> change in behavior, just makes the code easier to follow.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index be2931d54b95..6b6474d4f204 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2906,6 +2906,9 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>   if (wm[level] == 0) {
>   for (i = level + 1; i <= max_level; i++)
>   wm[i] = 0;
> +
> + max_level = level - 1;
> +
>   break;
>   }
>   }
> @@ -2920,12 +2923,8 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>   if (wm[0] == 0) {
>   u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
>  
> - wm[0] += adjust;
> - for (level = 1; level <= max_level; level++) {
> - if (wm[level] == 0)
> - break;
> + for (level = 0; level <= max_level; level++)
>   wm[level] += adjust;
> - }
>   }
>  
>   /*
> -- 
> 2.31.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12

2021-06-22 Thread Matt Roper

On Tue, Jun 22, 2021 at 04:28:14PM -0700, Matt Roper wrote:
> On Tue, Jun 22, 2021 at 02:22:09PM -0700, Lucas De Marchi wrote:
> > We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
> > Instead spec says to add 3usec (as opposed to 2) to each valid level
> > when punit replies 0 to level 0.
> > 
> > So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set
> > the proper adjustement value when handling WaWmMemoryReadLatency.
> > 
> > Signed-off-by: Lucas De Marchi 
> 
> Reviewed-by: Matt Roper 

Might also be worth adding

Bspec: 49326, 4381

to the commit message while applying.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dram.c |  3 +--
> >  drivers/gpu/drm/i915/intel_pm.c   | 13 +++--
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dram.c 
> > b/drivers/gpu/drm/i915/intel_dram.c
> > index 50fdea84ba70..879b0f007be3 100644
> > --- a/drivers/gpu/drm/i915/intel_dram.c
> > +++ b/drivers/gpu/drm/i915/intel_dram.c
> > @@ -484,8 +484,7 @@ static int gen11_get_dram_info(struct drm_i915_private 
> > *i915)
> >  
> >  static int gen12_get_dram_info(struct drm_i915_private *i915)
> >  {
> > -   /* Always needed for GEN12+ */
> > -   i915->dram_info.wm_lv_0_adjust_needed = true;
> > +   i915->dram_info.wm_lv_0_adjust_needed = false;
> >  
> > return icl_pcode_read_mem_global_info(i915);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ef8d9b2284b3..be2931d54b95 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2911,18 +2911,20 @@ static void intel_read_wm_latency(struct 
> > drm_i915_private *dev_priv,
> > }
> >  
> > /*
> > -* WaWmMemoryReadLatency:skl+,glk
> > +* WaWmMemoryReadLatency
> >  *
> >  * punit doesn't take into account the read latency so we need
> > -* to add 2us to the various latency levels we retrieve from the
> > -* punit when level 0 response data us 0us.
> > +* to add proper adjustement to each valid level we retrieve
> > +* from the punit when level 0 response data is 0us.
> >  */
> > if (wm[0] == 0) {
> > -   wm[0] += 2;
> > +   u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
> > +
> > +   wm[0] += adjust;
> > for (level = 1; level <= max_level; level++) {
> > if (wm[level] == 0)
> > break;
> > -   wm[level] += 2;
> > +   wm[level] += adjust;
> > }
> > }
> >  
> > @@ -2934,7 +2936,6 @@ static void intel_read_wm_latency(struct 
> > drm_i915_private *dev_priv,
> >  */
> > if (dev_priv->dram_info.wm_lv_0_adjust_needed)
> > wm[0] += 1;
> > -
> > } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
> >  
> > -- 
> > 2.31.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Allow mdev drivers to directly create the vfio_device (v4)

2021-06-22 Thread Alex Williamson

On Tue, 22 Jun 2021 21:05:50 -0300
Jason Gunthorpe  wrote:

> On Thu, Jun 17, 2021 at 04:22:08PM +0200, Christoph Hellwig wrote:
> > This is my alternative take on this series from Jason:
> > 
> > https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
> > 
> > The mdev/vfio parts are exactly the same, but this solves the driver core
> > changes for the direct probing without the in/out flag that Greg hated,
> > which cause a little more work, but probably make the result better.  
> 
> I did some testing and it looks good, thanks
> 
> I see Alex has this in hch-mdev-direct-v4 in linux-next now, so
> expecting this to be in the next merge window?

Yeah, sorry I didn't send out an "applied" note, end of the day
yesterday and forgot today.  My bad.  I expect this to go into v5.14
given the acks and Greg's deferral for the driver-core changes to go
through the vfio tree.  Speak now, or... Thanks,

Alex

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

[Intel-gfx] [PATCH v8 0/3] drm/i915: Move system memory to TTM for discrete

2021-06-22 Thread Thomas Hellström

Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.

Patch 2 deals with updating the i915 gem bookkeeping after a TTM move,
Patch 3 moves system over from shmem to TTM for discrete

Note that the mock device doesn't consider itself discrete so the TTM
system path is not checked by the mock selftests.

v2:
- Style fixes (reported by Matthew Auld)
- Drop the last patch (migration) It needs selftests and some additional work.
- Unconditionally add VM_IO at mmap time.

v3:
- More style fixes (reported by Matthew Auld)
- Don't overfill the busy placement vector (reported by Matthew Auld)

v4:
- Remove confusion around shrinkable objects (reported by Matthew Auld)

v5:
- Remove confusion around shrinkable objects again, but this time in the
  correct patch. (reported by Matthew Auld)

v6:
- One patch already committed.
- Introduce a __i915_gem_object_is_lmem() to be used in situations where we
  know that a fence that can't currently signal keeps the object from being
  migrated or evicted.
- Rebase on accelerated TTM moves
- Fix TODO:s for supporting system memory with TTM.
- Update the object GEM region after a TTM move if compatible.
- Move a couple of warnings for shmem on DGFX.

v7:
- Just updated a commit message with version history under dashes.

v8:
- Reinstate alignment at ttm_bo_init_reserved() time. (Reported by
  Matthew Auld).
- When changing regions, also move the object to the new region list
  and break early. (Reported by Matthew Auld).
- Don't flag the object as contiguous based on the current region min
  pages size.

Thomas Hellström (3):
  drm/i915: Update object placement flags to be mutable
  drm/i915/ttm: Adjust gem flags and caching settings after a move
  drm/i915/ttm: Use TTM for system memory

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  |  22 ++
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |   2 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  12 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  38 
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  14 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_region.c|   4 -
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 196 ++
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   5 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|   3 +-
 drivers/gpu/drm/i915/i915_drv.h   |   3 -
 drivers/gpu/drm/i915/i915_gpu_error.c |   2 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   7 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   8 +
 21 files changed, 267 insertions(+), 99 deletions(-)

-- 
2.31.1

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

[Intel-gfx] [PATCH v8 2/3] drm/i915/ttm: Adjust gem flags and caching settings after a move

2021-06-22 Thread Thomas Hellström

After a TTM move or object init we need to update the i915 gem flags and
caching settings to reflect the new placement. Currently caching settings
are not changed during the lifetime of an object, although that might
change moving forward if we run into performance issues or issues with
WC system page allocations.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v6:
- Rebase on accelerated ttm moves.
v8:
- Reinstate alignment at ttm_bo_init_reserved() time. (Reported by
  Matthew Auld).
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 144 ++--
 1 file changed, 108 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index b5dd3b7037f4..a1dc592c11bc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -91,6 +91,26 @@ static int i915_ttm_err_to_gem(int err)
return err;
 }
 
+static bool gpu_binds_iomem(struct ttm_resource *mem)
+{
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
+static bool cpu_maps_iomem(struct ttm_resource *mem)
+{
+   /* Once / if we support GGTT, this is also false for cached ttm_tts */
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
+static enum i915_cache_level
+i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
+struct ttm_tt *ttm)
+{
+   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) && !gpu_binds_iomem(res) &&
+   ttm->caching == ttm_cached) ? I915_CACHE_LLC :
+   I915_CACHE_NONE;
+}
+
 static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
 
 static enum ttm_caching
@@ -248,6 +268,35 @@ static void i915_ttm_free_cached_io_st(struct 
drm_i915_gem_object *obj)
obj->ttm.cached_io_st = NULL;
 }
 
+static void
+i915_ttm_adjust_domains_after_move(struct drm_i915_gem_object *obj)
+{
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+
+   if (cpu_maps_iomem(bo->resource) || bo->ttm->caching != ttm_cached) {
+   obj->write_domain = I915_GEM_DOMAIN_WC;
+   obj->read_domains = I915_GEM_DOMAIN_WC;
+   } else {
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   }
+}
+
+static void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj)
+{
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   unsigned int cache_level;
+
+   obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
+
+   obj->mem_flags |= cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
+
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
+  bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+}
+
 static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
@@ -263,8 +312,10 @@ static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 
/* TTM's purge interface. Note that we might be reentering. */
ret = ttm_bo_validate(bo, &place, &ctx);
-
if (!ret) {
+   obj->write_domain = 0;
+   obj->read_domains = 0;
+   i915_ttm_adjust_gem_after_move(obj);
i915_ttm_free_cached_io_st(obj);
obj->mm.madv = __I915_MADV_PURGED;
}
@@ -347,12 +398,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 struct ttm_resource *res)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
-   struct ttm_resource_manager *man =
-   ttm_manager_type(bo->bdev, res->mem_type);
 
-   if (man->use_tt)
+   if (!gpu_binds_iomem(res))
return i915_ttm_tt_get_st(bo->ttm);
 
+   /*
+* If CPU mapping differs, we need to add the ttm_tt pages to
+* the resulting st. Might make sense for GGTT.
+*/
+   GEM_WARN_ON(!cpu_maps_iomem(res));
return intel_region_ttm_resource_to_st(obj->mm.region, res);
 }
 
@@ -367,23 +421,25 @@ static int i915_ttm_accel_move(struct ttm_buffer_object 
*bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct sg_table *src_st;
struct i915_request *rq;
+   struct ttm_tt *ttm = bo->ttm;
+   enum i915_cache_level src_level, dst_level;
int ret;
 
if (!i915->gt.migrate.context)
return -EINVAL;
 
-   if (!bo->ttm || !ttm_tt_is_populated(bo->ttm)) {
+   dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
+   if (!ttm || !ttm_tt_is_populated(ttm)) {
if (bo->type == ttm_bo_type_kern

[Intel-gfx] [PATCH v8 1/3] drm/i915: Update object placement flags to be mutable

2021-06-22 Thread Thomas Hellström

The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. The flags
will change during migration under the object lock.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
  and TTM. Since the bo might be migrated while the VMA is still alive,
  there is no sense, whether or not it maps iomem might change.
v6:
- Introduce a __i915_gem_object_is_lmem() to be used in situations where we
  know that a fence that can't currently signal keeps the object from being
  migrated or evicted.
- Move a couple of shmem warnings for DGFX to a later patch where we
  actually move system memory to TTM.
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 22 +++
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h  |  2 +
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 12 +++---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 38 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 14 ++-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  7 ++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |  4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  5 +--
 .../drm/i915/gem/selftests/i915_gem_mman.c|  4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|  3 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 17 files changed, 101 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..13b217f75055 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -177,8 +177,8 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
return ERR_PTR(-ENOMEM);
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
-   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class,
-I915_BO_ALLOC_STRUCT_PAGE);
+   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class, 
0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
 
/*
 * Mark the object as volatile, such that the pages are marked as
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index d539dffa1554..41d5182cd367 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -71,6 +71,28 @@ bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
  mr->type == INTEL_MEMORY_STOLEN_LOCAL);
 }
 
+/**
+ * __i915_gem_object_is_lmem - Whether the object is resident in
+ * lmem while in the fence signaling critical path.
+ * @obj: The object to check.
+ *
+ * This function is intended to be called from within the fence signaling
+ * path where the fence keeps the object from being migrated. For example
+ * during gpu reset or similar.
+ *
+ * Return: Whether the object is resident in lmem.
+ */
+bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
+{
+   struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
+
+#ifdef CONFIG_LOCKDEP
+   GEM_WARN_ON(dma_resv_test_signaled(obj->base.resv, true));
+#endif
+   return mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
+}
+
 struct drm_i915_gem_object *
 i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index ea76fd11ccb0..27a611deba47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -21,6 +21,8 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
 
 bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
 
+bool __i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
+
 struct drm_i915_gem_object *
 i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2fd155742bd2..6497a2dbdab9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -684,7 +684,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i91

[Intel-gfx] [PATCH v8 3/3] drm/i915/ttm: Use TTM for system memory

2021-06-22 Thread Thomas Hellström

For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate callback. We can then also reuse our
own very elaborate shrinker for that memory.

If an object is evicted to a gem allowable region, we will now consider
the object migrated, and we flip the gem region and move the object to a
different region list. Since we are now changing gem regions, we can't
any longer rely on the CONTIGUOUS flag being set based on the region
min page size, so remove that flag update. If we want to reintroduce it,
we need to put it in the mutable flags.

Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
v3:
- Commit message typo fix
v6:
- Fix TODO:s for supporting system memory with TTM.
- Update the object GEM region after a TTM move if compatible.
- Add a couple of warnings for shmem on DGFX.
v8:
- When changing regions, also move the object to the new region list
  (Reported by Matthew Auld).
---
 drivers/gpu/drm/i915/gem/i915_gem_region.c |  4 --
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 52 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 --
 drivers/gpu/drm/i915/intel_memory_region.c |  7 ++-
 drivers/gpu/drm/i915/intel_memory_region.h |  8 
 6 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index d1f1840540dd..4925563018b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -13,11 +13,7 @@ void i915_gem_object_init_memory_region(struct 
drm_i915_gem_object *obj,
 {
obj->mm.region = intel_memory_region_get(mem);
 
-   if (obj->base.size <= mem->min_page_size)
-   obj->flags |= I915_BO_ALLOC_CONTIGUOUS;
-
mutex_lock(&mem->objects.lock);
-
list_add(&obj->mm.region_link, &mem->objects.list);
mutex_unlock(&mem->objects.lock);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 7aa1c95c7b7d..3648ae1d6628 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -284,6 +284,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object 
*obj,
bool needs_clflush)
 {
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
 
if (obj->mm.madv == I915_MADV_DONTNEED)
obj->mm.dirty = false;
@@ -302,6 +303,7 @@ void i915_gem_object_put_pages_shmem(struct 
drm_i915_gem_object *obj, struct sg_
struct pagevec pvec;
struct page *page;
 
+   GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
__i915_gem_object_release_shmem(obj, pages, true);
 
i915_gem_gtt_finish_pages(obj, pages);
@@ -560,6 +562,7 @@ i915_gem_object_create_shmem_from_data(struct 
drm_i915_private *dev_priv,
resource_size_t offset;
int err;
 
+   GEM_WARN_ON(IS_DGFX(dev_priv));
obj = i915_gem_object_create_shmem(dev_priv, round_up(size, PAGE_SIZE));
if (IS_ERR(obj))
return obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index a1dc592c11bc..3641a6c7b3d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -286,6 +286,26 @@ static void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
unsigned int cache_level;
+   unsigned int i;
+
+   /*
+* If object was moved to an allowable region, update the object
+* region to consider it migrated. Note that if it's currently not
+* in an allowable region, it's evicted and we don't update the
+* object region.
+*/
+   if (intel_region_to_ttm_type(obj->mm.region) != bo->resource->mem_type) 
{
+   for (i = 0; i < obj->mm.n_placements; ++i) {
+   struct intel_memory_region *mr = obj->mm.placements[i];
+
+   if (intel_region_to_ttm_type(mr) == 
bo->resource->mem_type &&
+   mr != obj->mm.region) {
+   i915_gem_object_release_memory_region(obj);
+   i915_gem_object_init_memory_region(obj, mr);
+   break;
+   }
+   }
+   }
 
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
 
@@ -615,13 +635,6 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
*obj)
/* Move to the requested placement. */
i915_ttm_placement_from_obj

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev8)

2021-06-22 Thread Patchwork

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev8)
URL   : https://patchwork.freedesktop.org/series/90898/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gem/i915_gem_ttm.c:809:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?
-O:drivers/gpu/drm/i915/gem/i915_gem_ttm.c:733:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?


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

95 matches

Mail list logo