date:20210104

Applied the series.  Thanks!

Alex

On Mon, Jan 4, 2021 at 4:17 PM Kazlauskas, Nicholas
 wrote:
>
> On 2020-12-28 1:50 p.m., Mario Kleiner wrote:
> > The hw supports fp16, this is not only useful for HDR,
> > but also for standard dynamic range displays, because
> > it allows to get more precise color reproduction with
> > about 11 - 12 bpc linear precision in the unorm range
> > 0.0 - 1.0.
> >
> > Working fp16 scanout+display (and HDR over HDMI) was
> > verified on a DCE-8 asic, so i assume that the more
> > recent DCE-10/11 will work equally well, now that
> > format-specific plane scaling constraints are properly
> > enforced, e.g., the inability of fp16 to scale on older
> > hw like DCE-8 to DCE-11.
> >
> > Signed-off-by: Mario Kleiner 
>
> Reviewed-by: Nicholas Kazlauskas 
>
> Regards,
> Nicholas Kazlauskas
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 2 +-
> >   drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
> >   drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c   | 2 +-
> >   3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> > index 8ab9d6c79808..f20ed05a5050 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> > @@ -385,7 +385,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
> >   },
> >
> >   .max_upscale_factor = {
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > index 3f63822b8e28..af208f9bd03b 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
> >   },
> >
> >   .max_upscale_factor = {
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> > index 390a0fa37239..26fe25caa281 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
> > @@ -402,7 +402,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
> >   },
> >
> >   .max_upscale_factor = {
> >
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently accept DCC for multiplane formats.


On 2020-12-29 9:54 a.m., Deucher, Alexander wrote:

[AMD Public Use]


I don't know if these fixes related to modifiers make sense in the 
pre-modifier code base.  Bas, Nick?


Alex


Mesa should be the only userspace trying to make use of DCC and it 
doesn't do it for video formats. From the kernel side of things we've 
also never supported this and you'd get corruption on the screen if you 
tried.


It's a "fix" for both pre-modifiers and post-modifiers code.

Regards,
Nicholas Kazlauskas



*From:* amd-gfx  on behalf of 
Sasha Levin 

*Sent:* Tuesday, December 22, 2020 9:16 PM
*To:* linux-ker...@vger.kernel.org ; 
sta...@vger.kernel.org 
*Cc:* Sasha Levin ; dri-de...@lists.freedesktop.org 
; amd-gfx@lists.freedesktop.org 
; Bas Nieuwenhuizen 
; Deucher, Alexander 
; Kazlauskas, Nicholas 

*Subject:* [PATCH AUTOSEL 5.4 006/130] drm/amd/display: Do not silently 
accept DCC for multiplane formats.

From: Bas Nieuwenhuizen 

[ Upstream commit b35ce7b364ec80b54f48a8fdf9fb74667774d2da ]

Silently accepting it could result in corruption.

Signed-off-by: Bas Nieuwenhuizen 
Reviewed-by: Alex Deucher 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

index d2dd387c95d86..ce70c42a2c3ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2734,7 +2734,7 @@ fill_plane_dcc_attributes(struct amdgpu_device *adev,
  return 0;

  if (format >= SURFACE_PIXEL_FORMAT_VIDEO_BEGIN)
-   return 0;
+   return -EINVAL;

  if (!dc->cap_funcs.get_dcc_compression_cap)
  return -EINVAL;
--
2.27.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cfb9f2581393f494acd1708d8a6e905fc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63744286704415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZYz1FjTl6SoWX1B91t0McdUai%2FzRF9C8uBmE%2BNQNod4%3Dreserved=0 



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

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-8/10/11.


On 2020-12-28 1:50 p.m., Mario Kleiner wrote:

The hw supports fp16, this is not only useful for HDR,
but also for standard dynamic range displays, because
it allows to get more precise color reproduction with
about 11 - 12 bpc linear precision in the unorm range
0.0 - 1.0.

Working fp16 scanout+display (and HDR over HDMI) was
verified on a DCE-8 asic, so i assume that the more
recent DCE-10/11 will work equally well, now that
format-specific plane scaling constraints are properly
enforced, e.g., the inability of fp16 to scale on older
hw like DCE-8 to DCE-11.

Signed-off-by: Mario Kleiner 


Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 2 +-
  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
  drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c   | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
index 8ab9d6c79808..f20ed05a5050 100644
--- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
@@ -385,7 +385,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  	.max_upscale_factor = {

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 3f63822b8e28..af208f9bd03b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  		.max_upscale_factor = {

diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
index 390a0fa37239..26fe25caa281 100644
--- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c
@@ -402,7 +402,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  	.max_upscale_factor = {




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

Re: [PATCH 1/2] drm/amd/display: Check plane scaling against format specific hw plane caps.


On 2020-12-28 1:50 p.m., Mario Kleiner wrote:

This takes hw constraints specific to pixel formats into account,
e.g., the inability of older hw to scale fp16 format framebuffers.

It should now allow safely to enable fp16 formats also on DCE-8,
DCE-10, DCE-11.0

Signed-off-by: Mario Kleiner 


Reviewed-by: Nicholas Kazlauskas 

I think we're fine with equating all the planes as equal since we don't 
expose underlay support on DCE.


Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 81 +--
  1 file changed, 73 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2c4dbdeec46a..a3745cd8a459 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3759,10 +3759,53 @@ static const struct drm_encoder_funcs 
amdgpu_dm_encoder_funcs = {
  };
  
  
+static void get_min_max_dc_plane_scaling(struct drm_device *dev,

+struct drm_framebuffer *fb,
+int *min_downscale, int *max_upscale)
+{
+   struct amdgpu_device *adev = drm_to_adev(dev);
+   struct dc *dc = adev->dm.dc;
+   /* Caps for all supported planes are the same on DCE and DCN 1 - 3 */
+   struct dc_plane_cap *plane_cap = >caps.planes[0];
+
+   switch (fb->format->format) {
+   case DRM_FORMAT_P010:
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV21:
+   *max_upscale = plane_cap->max_upscale_factor.nv12;
+   *min_downscale = plane_cap->max_downscale_factor.nv12;
+   break;
+
+   case DRM_FORMAT_XRGB16161616F:
+   case DRM_FORMAT_ARGB16161616F:
+   case DRM_FORMAT_XBGR16161616F:
+   case DRM_FORMAT_ABGR16161616F:
+   *max_upscale = plane_cap->max_upscale_factor.fp16;
+   *min_downscale = plane_cap->max_downscale_factor.fp16;
+   break;
+
+   default:
+   *max_upscale = plane_cap->max_upscale_factor.argb;
+   *min_downscale = plane_cap->max_downscale_factor.argb;
+   break;
+   }
+
+   /*
+* A factor of 1 in the plane_cap means to not allow scaling, ie. use a
+* scaling factor of 1.0 == 1000 units.
+*/
+   if (*max_upscale == 1)
+   *max_upscale = 1000;
+
+   if (*min_downscale == 1)
+   *min_downscale = 1000;
+}
+
+
  static int fill_dc_scaling_info(const struct drm_plane_state *state,
struct dc_scaling_info *scaling_info)
  {
-   int scale_w, scale_h;
+   int scale_w, scale_h, min_downscale, max_upscale;
  
  	memset(scaling_info, 0, sizeof(*scaling_info));
  
@@ -3794,17 +3837,25 @@ static int fill_dc_scaling_info(const struct drm_plane_state *state,

/* DRM doesn't specify clipping on destination output. */
scaling_info->clip_rect = scaling_info->dst_rect;
  
-	/* TODO: Validate scaling per-format with DC plane caps */

+   /* Validate scaling per-format with DC plane caps */
+   if (state->plane && state->plane->dev && state->fb) {
+   get_min_max_dc_plane_scaling(state->plane->dev, state->fb,
+_downscale, _upscale);
+   } else {
+   min_downscale = 250;
+   max_upscale = 16000;
+   }
+
scale_w = scaling_info->dst_rect.width * 1000 /
  scaling_info->src_rect.width;
  
-	if (scale_w < 250 || scale_w > 16000)

+   if (scale_w < min_downscale || scale_w > max_upscale)
return -EINVAL;
  
  	scale_h = scaling_info->dst_rect.height * 1000 /

  scaling_info->src_rect.height;
  
-	if (scale_h < 250 || scale_h > 16000)

+   if (scale_h < min_downscale || scale_h > max_upscale)
return -EINVAL;
  
  	/*

@@ -6424,12 +6475,26 @@ static void dm_plane_helper_cleanup_fb(struct drm_plane 
*plane,
  static int dm_plane_helper_check_state(struct drm_plane_state *state,
   struct drm_crtc_state *new_crtc_state)
  {
-   int max_downscale = 0;
-   int max_upscale = INT_MAX;
+   struct drm_framebuffer *fb = state->fb;
+   int min_downscale, max_upscale;
+   int min_scale = 0;
+   int max_scale = INT_MAX;
+
+   /* Plane enabled? Get min/max allowed scaling factors from plane caps. 
*/
+   if (fb && state->crtc) {
+   get_min_max_dc_plane_scaling(state->crtc->dev, fb,
+_downscale, _upscale);
+   /*
+* Convert to drm convention: 16.16 fixed point, instead of dc's
+* 1.0 == 1000. Also drm scaling is src/dst instead of dc's
+* dst/src, so min_scale = 1.0 / max_upscale, etc.
+*/
+   min_scale = (1000 << 16) / max_upscale;
+

[PATCH v3 2/3] drm/amd/display: Add freesync video modes based on preferred modes

[Why]
If experimental freesync video mode module parameter is enabled, add
few extra display modes into the driver's mode list corresponding to common
video frame rates. When userspace sets these modes, no modeset will be
performed (if current mode was one of freesync modes or the base freesync mode
based off which timings have been generated for the rest of the freesync modes)
since these modes only differ from the base mode with front porch timing.

Signed-off-by: Aurabindo Pillai 
Acked-by: Christian König 
Reviewed-by: Shashank Sharma 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 170 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   2 +
 2 files changed, 172 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 245bd1284e5f..aaef2fb528fd 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5174,6 +5174,59 @@ static void dm_enable_per_frame_crtc_master_sync(struct 
dc_state *context)
set_master_stream(context->streams, context->stream_count);
 }
 
+static struct drm_display_mode *
+get_highest_refresh_rate_mode(struct amdgpu_dm_connector *aconnector,
+ bool use_probed_modes)
+{
+   struct drm_display_mode *m, *m_pref = NULL;
+   u16 current_refresh, highest_refresh;
+   struct list_head *list_head = use_probed_modes ?
+   
>base.probed_modes :
+   >base.modes;
+
+   if (aconnector->freesync_vid_base.clock != 0)
+   return >freesync_vid_base;
+
+   /* Find the preferred mode */
+   list_for_each_entry (m, list_head, head) {
+   if (m->type & DRM_MODE_TYPE_PREFERRED) {
+   m_pref = m;
+   break;
+   }
+   }
+
+   if (!m_pref) {
+   /* Probably an EDID with no preferred mode. Fallback to first 
entry */
+   m_pref = list_first_entry_or_null(
+   >base.modes, struct drm_display_mode, head);
+   if (!m_pref) {
+   DRM_DEBUG_DRIVER("No preferred mode found in EDID\n");
+   return NULL;
+   }
+   }
+
+   highest_refresh = drm_mode_vrefresh(m_pref);
+
+   /*
+* Find the mode with highest refresh rate with same resolution.
+* For some monitors, preferred mode is not the mode with highest
+* supported refresh rate.
+*/
+   list_for_each_entry (m, list_head, head) {
+   current_refresh  = drm_mode_vrefresh(m);
+
+   if (m->hdisplay == m_pref->hdisplay &&
+   m->vdisplay == m_pref->vdisplay &&
+   highest_refresh < current_refresh) {
+   highest_refresh = current_refresh;
+   m_pref = m;
+   }
+   }
+
+   aconnector->freesync_vid_base = *m_pref;
+   return m_pref;
+}
+
 static struct dc_stream_state *
 create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -6999,6 +7052,122 @@ static void amdgpu_dm_connector_ddc_get_modes(struct 
drm_connector *connector,
}
 }
 
+static bool is_duplicate_mode(struct amdgpu_dm_connector *aconnector,
+ struct drm_display_mode *mode)
+{
+   struct drm_display_mode *m;
+
+   list_for_each_entry (m, >base.probed_modes, head) {
+   if (drm_mode_equal(m, mode))
+   return true;
+   }
+
+   return false;
+}
+
+static uint add_fs_modes(struct amdgpu_dm_connector *aconnector,
+struct detailed_data_monitor_range *range)
+{
+   const struct drm_display_mode *m;
+   struct drm_display_mode *new_mode;
+   uint i;
+   uint32_t new_modes_count = 0;
+
+   /* Standard FPS values
+*
+* 23.976   - TV/NTSC
+* 24   - Cinema
+* 25   - TV/PAL
+* 29.97- TV/NTSC
+* 30   - TV/NTSC
+* 48   - Cinema HFR
+* 50   - TV/PAL
+* 60   - Commonly used
+* 48,72,96 - Multiples of 24
+*/
+   const uint32_t common_rates[] = { 23976, 24000, 25000, 29970, 3,
+48000, 5, 6, 72000, 96000 };
+
+   /*
+* Find mode with highest refresh rate with the same resolution
+* as the preferred mode. Some monitors report a preferred mode
+* with lower resolution than the highest refresh rate supported.
+*/
+
+   m = get_highest_refresh_rate_mode(aconnector, true);
+   if (!m)
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(common_rates); i++) {
+   uint64_t target_vtotal, target_vtotal_diff;
+   uint64_t num,

[PATCH v3 3/3] drm/amd/display: Skip modeset for front porch change

[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same stream.

Signed-off-by: Aurabindo Pillai 
Acked-by: Christian König 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 219 +++---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
 2 files changed, 188 insertions(+), 32 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 aaef2fb528fd..315756207f0f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -213,6 +213,9 @@ static bool amdgpu_dm_psr_disable_all(struct 
amdgpu_display_manager *dm);
 static const struct drm_format_info *
 amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
 
+static bool
+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
 /*
  * dm_vblank_get_counter
  *
@@ -4940,7 +4943,8 @@ static void fill_stream_properties_from_drm_display_mode(
const struct drm_connector *connector,
const struct drm_connector_state *connector_state,
const struct dc_stream_state *old_stream,
-   int requested_bpc)
+   int requested_bpc,
+   bool is_in_modeset)
 {
struct dc_crtc_timing *timing_out = >timing;
const struct drm_display_info *info = >display_info;
@@ -4995,19 +4999,28 @@ static void 
fill_stream_properties_from_drm_display_mode(
timing_out->hdmi_vic = hv_frame.vic;
}
 
-   timing_out->h_addressable = mode_in->crtc_hdisplay;
-   timing_out->h_total = mode_in->crtc_htotal;
-   timing_out->h_sync_width =
-   mode_in->crtc_hsync_end - mode_in->crtc_hsync_start;
-   timing_out->h_front_porch =
-   mode_in->crtc_hsync_start - mode_in->crtc_hdisplay;
-   timing_out->v_total = mode_in->crtc_vtotal;
-   timing_out->v_addressable = mode_in->crtc_vdisplay;
-   timing_out->v_front_porch =
-   mode_in->crtc_vsync_start - mode_in->crtc_vdisplay;
-   timing_out->v_sync_width =
-   mode_in->crtc_vsync_end - mode_in->crtc_vsync_start;
-   timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+   if (is_in_modeset) {
+   timing_out->h_addressable = mode_in->hdisplay;
+   timing_out->h_total = mode_in->htotal;
+   timing_out->h_sync_width = mode_in->hsync_end - 
mode_in->hsync_start;
+   timing_out->h_front_porch = mode_in->hsync_start - 
mode_in->hdisplay;
+   timing_out->v_total = mode_in->vtotal;
+   timing_out->v_addressable = mode_in->vdisplay;
+   timing_out->v_front_porch = mode_in->vsync_start - 
mode_in->vdisplay;
+   timing_out->v_sync_width = mode_in->vsync_end - 
mode_in->vsync_start;
+   timing_out->pix_clk_100hz = mode_in->clock * 10;
+   } else {
+   timing_out->h_addressable = mode_in->crtc_hdisplay;
+   timing_out->h_total = mode_in->crtc_htotal;
+   timing_out->h_sync_width = mode_in->crtc_hsync_end - 
mode_in->crtc_hsync_start;
+   timing_out->h_front_porch = mode_in->crtc_hsync_start - 
mode_in->crtc_hdisplay;
+   timing_out->v_total = mode_in->crtc_vtotal;
+   timing_out->v_addressable = mode_in->crtc_vdisplay;
+   timing_out->v_front_porch = mode_in->crtc_vsync_start - 
mode_in->crtc_vdisplay;
+   timing_out->v_sync_width = mode_in->crtc_vsync_end - 
mode_in->crtc_vsync_start;
+   timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+   }
+
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
stream->output_color_space = get_output_color_space(timing_out);
@@ -5227,6 +5240,33 @@ get_highest_refresh_rate_mode(struct amdgpu_dm_connector 
*aconnector,
return m_pref;
 }
 
+static bool is_freesync_video_mode(struct drm_display_mode *mode,
+  struct amdgpu_dm_connector *aconnector)
+{
+   struct drm_display_mode *high_mode;
+   int timing_diff;
+
+   high_mode = get_highest_refresh_rate_mode(aconnector, false);
+   if (!high_mode || !mode)
+   return false;
+
+   timing_diff = high_mode->vtotal - mode->vtotal;
+
+   if (high_mode->clock == 0 || high_mode->clock != mode->clock ||
+   high_mode->hdisplay != mode->hdisplay ||
+   high_mode->vdisplay != mode->vdisplay ||
+   high_mode->hsync_start != mode->hsync_start ||
+   high_mode->hsync_end != mode->hsync_end ||
+   high_mode->htotal != mode->htotal ||
+   high_mode->hskew != mode->hskew ||
+   high_mode->vscan !=

[PATCH v3 1/3] drm/amd/display: Add module parameter for freesync video mode

[Why]
Adds a module parameter to enable experimental freesync video mode modeset
optimization. Enabling this mode allows the driver to skip a full modeset when
freesync compatible modes are requested by the userspace. This paramters also
adds some standard modes based on the connected monitor's VRR range.

Signed-off-by: Aurabindo Pillai 
Acked-by: Christian König 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 100a431f0792..12b13a90eddf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -177,6 +177,7 @@ extern int amdgpu_gpu_recovery;
 extern int amdgpu_emu_mode;
 extern uint amdgpu_smu_memory_pool_size;
 extern uint amdgpu_dc_feature_mask;
+extern uint amdgpu_exp_freesync_vid_mode;
 extern uint amdgpu_dc_debug_mask;
 extern uint amdgpu_dm_abm_level;
 extern struct amdgpu_mgpu_info mgpu_info;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b48d7a3c2a11..2badbc8b2294 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -158,6 +158,7 @@ int amdgpu_mes;
 int amdgpu_noretry = -1;
 int amdgpu_force_asic_type = -1;
 int amdgpu_tmz;
+uint amdgpu_exp_freesync_vid_mode;
 int amdgpu_reset_method = -1; /* auto */
 int amdgpu_num_kcq = -1;
 
@@ -786,6 +787,17 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 
0444);
 MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = 
on)");
 module_param_named(tmz, amdgpu_tmz, int, 0444);
 
+/**
+ * DOC: experimental_freesync_video (uint)
+ * Enabled the optimization to adjust front porch timing to achieve seamless 
mode change experience
+ * when setting a freesync supported mode for which full modeset is not needed.
+ * The default value: 0 (off).
+ */
+MODULE_PARM_DESC(
+   freesync_video,
+   "Enable freesync modesetting optimization feature (0 = off (default), 1 
= on)");
+module_param_named(freesync_video, amdgpu_exp_freesync_vid_mode, uint, 0444);
+
 /**
  * DOC: reset_method (int)
  * GPU reset method (-1 = auto (default), 0 = legacy, 1 = mode0, 2 = mode1, 3 
= mode2, 4 = baco)
-- 
2.30.0

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

[PATCH v3 0/3] Experimental freesync video mode optimization

Changes in V4
=

1) Add module parameter for freesync video mode

* Change module parameter name to freesync_video

2) Add freesync video modes based on preferred modes:

* Cosmetic fixes
* Added comments about all modes being added by the driver.

3) Skip modeset for front porch change

* Added more conditions for checking freesync video mode

Changes in V3
=

1) Add freesync video modes based on preferred modes:

* Cache base freesync video mode during the first iteration to avoid
  iterating over modelist again later.
* Add mode for 60 fps videos

2) Skip modeset for front porch change

* Fixes for bug exposed by caching of modes.

Changes in V2
=

1) Add freesync video modes based on preferred modes:

* Remove check for connector type before adding freesync compatible
  modes as VRR support is being checked, and there is no reason to block
  freesync video support on eDP.
* use drm_mode_equal() instead of creating same functionality.
* Additional null pointer deference check
* Removed unnecessary variables.
* Cosmetic fixes.

2) Skip modeset for front porch change

* Remove _FSV string being appended to freesync video modes so as to not
  define new policies or break existing application that might use the
  mode name to figure out mode resolution.
* Remove unnecessary variables
* Cosmetic fixes.

--

This patchset enables freesync video mode usecase where the userspace
can request a freesync compatible video mode such that switching to this
mode does not trigger blanking.

This feature is guarded by a module parameter which is disabled by
default. Enabling this paramters adds additional modes to the driver
modelist, and also enables the optimization to skip modeset when using
one of these modes.

--

Aurabindo Pillai (3):
  drm/amd/display: Add module parameter for freesync video mode
  drm/amd/display: Add freesync video modes based on preferred modes
  drm/amd/display: Skip modeset for front porch change

 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  12 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 389 --
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
 4 files changed, 373 insertions(+), 32 deletions(-)

-- 
2.30.0

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

Re: [PATCH v2 2/3] drm/amd/display: Add freesync video modes based on preferred modes

On Mon, 2021-01-04 at 11:06 -0500, Kazlauskas, Nicholas wrote:
> On 2020-12-11 12:54 a.m., Shashank Sharma wrote:
> > 
> > On 11/12/20 12:18 am, Aurabindo Pillai wrote:
> > > [Why]
> > > If experimental freesync video mode module parameter is enabled,
> > > add
> > > few extra display modes into the driver's mode list corresponding
> > > to common
> > > video frame rates. When userspace sets these modes, no modeset
> > > will be
> > > performed (if current mode was one of freesync modes or the base
> > > freesync mode
> > > based off which timings have been generated for the rest of the
> > > freesync modes)
> > > since these modes only differ from the base mode with front porch
> > > timing.
> > > 
> > > Signed-off-by: Aurabindo Pillai 
> > > ---
> > >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 167
> > > ++
> > >   1 file changed, 167 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > index fbff8d693e03..d15453b400d2 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -5178,6 +5178,54 @@ static void
> > > dm_enable_per_frame_crtc_master_sync(struct dc_state *context)
> > > set_master_stream(context->streams, context-
> > > >stream_count);
> > >   }
> > >   
> > > +static struct drm_display_mode *
> > > +get_highest_refresh_rate_mode(struct amdgpu_dm_connector
> > > *aconnector,
> > > + bool use_probed_modes)
> > > +{
> > > +   struct drm_display_mode *m, *m_high = NULL;
> > I would prefer m_high to be renamed as m_pref, indicating it's the
> > preferred mode
> > > +   u16 current_refresh, highest_refresh;
> > > +   struct list_head *list_head = use_probed_modes ?
> > > +   
> > > >base.probed_modes :
> > > +   
> > > >base.modes;
> > > +   /* Find the preferred mode */
> > > +   list_for_each_entry (m, list_head, head) {
> > > +   if (!(m->type & DRM_MODE_TYPE_PREFERRED))
> > > +   continue;
> > > +
> > > +   m_high = m;
> > > +   highest_refresh = drm_mode_vrefresh(m_high);
> > > +   break;
> > > +   }
> > > +
> > > +   if (!m_high) {
> > > +   /* Probably an EDID with no preferred mode.
> > > Fallback to first entry */
> > > +   m_high = list_first_entry_or_null(
> > > >base.modes,
> > > + struct
> > > drm_display_mode, head);
> > > +   if (!m_high)
> > > +   return NULL;
> > > +   else
> > > +   highest_refresh =
> > > drm_mode_vrefresh(m_high);
> > > +   }
> > > +
> > 
> > Optional cleanup suggested below makes code more readable:
> > 
> > 
> > /* Find the preferred mode */
> > 
> > list_for_each_entry (m, list_head, head) {
> >  if (m->type & DRM_MODE_TYPE_PREFERRED) {
> >      m_pref = m;
> >      break;
> >  }
> > }
> > 
> > if (!m_pref) {
> >  /* Probably an EDID with no preferred mode. Fallback to first
> > entry */
> >  m_pref = list_first_entry_or_null(>base.modes,
> >                                    struct drm_display_mode,
> > head);
> >  if (!m_pref) {
> >      DRM_DEBUG_DRIVER("No preferred mode found in EDID\n");
> >      return NULL;
> >  }
> > }
> > 
> > highest_refresh = drm_mode_vrefresh(m_pref);
> 
> Agreed with this cleanup - naming is confusing as is.

This was fixed in latest revision.

> 
> > > +   /*
> > > +    * Find the mode with highest refresh rate with same
> > > resolution.
> > > +    * For some monitors, preferred mode is not the mode with
> > > highest
> > > +    * supported refresh rate.
> > > +    */
> > > +   list_for_each_entry (m, list_head, head) {
> > > +   current_refresh  = drm_mode_vrefresh(m);
> > > +
> > > +   if (m->hdisplay == m_high->hdisplay &&
> > > +   m->vdisplay == m_high->vdisplay &&
> > > +   highest_refresh < current_refresh) {
> > > +   highest_refresh = current_refresh;
> > > +   m_high = m;
> > > +   }
> > > +   }
> > > +
> > > +   return m_high;
> > > +}
> > > +
> > >   static struct dc_stream_state *
> > >   create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
> > >    const struct drm_display_mode *drm_mode,
> > > @@ -7006,6 +7054,124 @@ static void
> > > amdgpu_dm_connector_ddc_get_modes(struct drm_connector
> > > *connector,
> > > }
> > >   }
> > >   
> > > +static bool is_duplicate_mode(struct amdgpu_dm_connector
> > > *aconnector,
> > > + struct drm_display_mode *mode)
> > > +{
> > > +   struct drm_display_mode *m;
> >

Re: [PATCH] drm: Check actual format for legacy pageflip.

2021-01-04 Thread Liu, Zhan

[AMD Official Use Only - Internal Distribution Only]

+ Ville

On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner  wrote:
>
> On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
>  wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> > implicit modifiers to explicit modifiers with multiple planes.
> >
> > I checked other drivers and it doesn't look like they end up triggering
> > this case so I think this is safe to relax.
> >
> > Signed-off-by: Bas Nieuwenhuizen 
> > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted 
> > metadata.")
> > ---
> >  drivers/gpu/drm/drm_plane.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index e6231947f987..f5085990cfac 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > if (ret)
> > goto out;
> >
> > -   if (old_fb->format != fb->format) {
> > +   if (old_fb->format->format != fb->format->format) {
>

I agree with this patch, though considering the original way was made by Ville, 
I will wait for Ville's input first. Adding my "Acked-by" here.

This patch is:
Acked-by: Zhan Liu 

> This was btw. the original way before Ville made it more strict about
> 4 years ago, to catch issues related to tiling, and more complex
> layouts, like the dcc tiling/retiling introduced by your modifier
> patches. That's why I hope my alternative patch is a good solution for
> atomic drivers while keeping the strictness for potential legacy
> drivers.
>
> -mario
>
> > DRM_DEBUG_KMS("Page flip is not allowed to change frame 
> > buffer format.\n");
> > ret = -EINVAL;
> > goto out;
> > --
> > 2.29.2
> >
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change

On Mon, 2021-01-04 at 11:16 -0500, Kazlauskas, Nicholas wrote:
> On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote:
> > [Why]
> > Inorder to enable freesync video mode, driver adds extra
> > modes based on preferred modes for common freesync frame rates.
> > When commiting these mode changes, a full modeset is not needed.
> > If the change in only in the front porch timing value, skip full
> > modeset and continue using the same stream.
> > 
> > Signed-off-by: Aurabindo Pillai 
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169
> > --
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
> >   2 files changed, 153 insertions(+), 17 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 f699a3d41cad..c8c72887906a 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct
> > amdgpu_display_manager *dm);
> >   static const struct drm_format_info *
> >   amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
> >   
> > +static bool
> > +is_timing_unchanged_for_freesync(struct drm_crtc_state
> > *old_crtc_state,
> > +    struct drm_crtc_state
> > *new_crtc_state);
> >   /*
> >    * dm_vblank_get_counter
> >    *
> > @@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const
> > struct drm_display_mode *src_mode,
> >   static void
> >   decide_crtc_timing_for_drm_display_mode(struct drm_display_mode
> > *drm_mode,
> > const struct
> > drm_display_mode *native_mode,
> > -   bool scale_enabled)
> > +   bool scale_enabled, bool
> > fs_mode)
> >   {
> > +   if (fs_mode)
> > +   return;
> > +
> > if (scale_enabled) {
> > copy_crtc_timing_for_drm_display_mode(native_mode,
> > drm_mode);
> > } else if (native_mode->clock == drm_mode->clock &&
> > @@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct
> > amdgpu_dm_connector *aconnector,
> > return m_high;
> >   }
> >   
> > +static bool is_freesync_video_mode(struct drm_display_mode *mode,
> > +  struct amdgpu_dm_connector
> > *aconnector)
> > +{
> > +   struct drm_display_mode *high_mode;
> > +
> > +   high_mode = get_highest_freesync_mode(aconnector, false);
> > +   if (!high_mode)
> > +   return false;
> > +
> > +   if (high_mode->clock == 0 ||
> > +   high_mode->hdisplay != mode->hdisplay ||
> > +   high_mode->clock != mode->clock ||
> > +   !mode)
> > +   return false;
> > +   else
> > +   return true;
> > +}
> > +
> 
> Need to check that the other parameters are the same:
> - hsync_start
> - hsync_end
> - htotal
> - hskew
> - vdisplay
> - vscan
> 
> etc.

Will do.

> 
> >   static struct dc_stream_state *
> >   create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
> >    const struct drm_display_mode *drm_mode,
> > @@ -5253,17 +5277,21 @@ create_stream_for_sink(struct
> > amdgpu_dm_connector *aconnector,
> > const struct drm_connector_state *con_state =
> > dm_state ? _state->base : NULL;
> > struct dc_stream_state *stream = NULL;
> > -   struct drm_display_mode mode = *drm_mode;
> > +   struct drm_display_mode saved_mode, mode = *drm_mode;
> > +   struct drm_display_mode *freesync_mode = NULL;
> > bool native_mode_found = false;
> > bool scale = dm_state ? (dm_state->scaling != RMX_OFF) :
> > false;
> > int mode_refresh;
> > int preferred_refresh = 0;
> > +   bool is_fs_vid_mode = 0;
> >   #if defined(CONFIG_DRM_AMD_DC_DCN)
> > struct dsc_dec_dpcd_caps dsc_caps;
> >   #endif
> > uint32_t link_bandwidth_kbps;
> > -
> > struct dc_sink *sink = NULL;
> > +
> > +   memset(_mode, 0, sizeof(struct drm_display_mode));
> > +
> > if (aconnector == NULL) {
> > DRM_ERROR("aconnector is NULL!\n");
> > return stream;
> > @@ -5316,20 +5344,33 @@ create_stream_for_sink(struct
> > amdgpu_dm_connector *aconnector,
> >  */
> > DRM_DEBUG_DRIVER("No preferred mode found\n");
> > } else {
> > +   is_fs_vid_mode = is_freesync_video_mode(,
> > aconnector);
> > +   if (is_fs_vid_mode) {
> > +   freesync_mode =
> > get_highest_freesync_mode(aconnector, false);
> > +   if (freesync_mode) {
> > +   saved_mode = mode;
> > +   mode = *freesync_mode;
> > +   }
> > +   }
> > +
> > decide_crtc_timing_for_drm_display_mode(
> >

Re: Couple of issues with amdgpu on my WX4100


Am 04.01.21 um 19:43 schrieb Alex Williamson:

On Mon, 4 Jan 2021 18:39:33 +0100
Christian König  wrote:


Am 04.01.21 um 17:45 schrieb Alex Williamson:

On Mon, 4 Jan 2021 12:34:34 +0100
Christian König  wrote:
  
[SNIP]

That's a rather bad idea. See our GPUs for example return way more than
they actually need.

E.g. a Polaris usually returns 4GiB even when only 2GiB are installed,
because 4GiB is just the maximum amount of RAM you can put together with
the ASIC on a board.

Would the driver fail or misbehave if the BAR is sized larger than the
amount of memory on the card or is memory size determined independently
of BAR size?


Uff, good question. I have no idea.

At least the Linux driver should behave well, but no idea about the 
Windows driver stack.



Some devices even return a mask of all 1 even when they need only 2MiB,
resulting in nearly 1TiB of wasted address space with this approach.

Ugh.  I'm afraid to ask why a device with a 2MiB BAR would implement a
REBAR capability, but I guess we really can't make any assumptions
about the breadth of SKUs that ASIC might support (or sanity of the
designers).


It's a standard feature for FPGAs these days since how much BAR you need 
depends on what you load on it, and that in turn usually only happens 
after the OS is already started and you fire up your development 
environment.



We could probe to determine the maximum size the host can support and
potentially emulate the capability to remove sizes that we can't
allocate, but without any ability for the device to reject a size
advertised as supported via the capability protocol it makes me nervous
how we can guarantee the resources are available when the user
re-configures the device.  That might mean we'd need to reserve the
resources, up to what the host can support, regardless of what the
device can actually use.  I'm not sure how else to know how much to
reserve without device specific code in vfio-pci.  Thanks,


Well in the FPGA case I outlined above you don't really know how much 
BAR you need until the setup is completed.


E.g. you could need one BAR with just 2MiB and another with 128GB, or 
two with 64GB or That's the reason why somebody came up with the 
REBAR standard in the first place.


I think I can summarize that static resizing might work for some devices 
like our GPUs, but it doesn't solve the problem in general.


Regards,
Christian.



Alex



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

Re: Couple of issues with amdgpu on my WX4100

2021-01-04 Thread Alex Williamson

On Mon, 4 Jan 2021 18:39:33 +0100
Christian König  wrote:

> Am 04.01.21 um 17:45 schrieb Alex Williamson:
> > On Mon, 4 Jan 2021 12:34:34 +0100
> > Christian König  wrote:
> >  
> >> Hi Maxim,
> >>
> >> I can't help with the display related stuff. Probably best approach to
> >> get this fixes would be to open up a bug tracker for this on FDO.
> >>
> >> But I'm the one who implemented the resizeable BAR support and your
> >> analysis of the problem sounds about correct to me.
> >>
> >> The reason why this works on Linux is most likely because we restore the
> >> BAR size on resume (and maybe during initial boot as well).
> >>
> >> See this patch for reference:
> >>
> >> commit d3252ace0bc652a1a24446b6a549f969bf99
> >> Author: Christian König 
> >> Date:   Fri Jun 29 19:54:55 2018 -0500
> >>
> >>       PCI: Restore resized BAR state on resume
> >>
> >>       Resize BARs after resume to the expected size again.
> >>
> >>       BugLink: 
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D199959data=04%7C01%7Cchristian.koenig%40amd.com%7C942176d2e6aa4a4f3a4208d8b0d032bd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637453755549960615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3rsR%2Fx4uTpjtXFNqlJyFBteMmZMjWf3Neci7lUlkh88%3Dreserved=0
> >>       Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
> >>       Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
> >>       Signed-off-by: Christian König 
> >>       Signed-off-by: Bjorn Helgaas 
> >>       CC: sta...@vger.kernel.org  # v4.15+
> >>
> >>
> >> It should be trivial to add this to the reset module as well. Most
> >> likely even completely vendor independent since I'm not sure what a bus
> >> reset will do to this configuration and restoring it all the time should
> >> be the most defensive approach.  
> > Hmm, this should already be used by the bus/slot reset path:
> >
> > pci_bus_restore_locked()/pci_slot_restore_locked()
> >   pci_dev_restore()
> >pci_restore_state()
> > pci_restore_rebar_state()
> >
> > VFIO support for resizeable BARs has been on my todo list, but I don't
> > have access to any systems that have both a capable device and >4G
> > decoding enabled in the BIOS.  If we have a consistent view of the BAR
> > size after the BARs are expanded, I'm not sure why it doesn't just
> > work.  FWIW, QEMU currently hides the REBAR capability to the guest
> > because the kernel driver doesn't support emulation through config
> > space (ie. it's read-only, which the spec doesn't support).  
> 
> In this case the guest shouldn't be able to change the config at all and 
> I have no idea what's going wrong here.
> 
> > AIUI, resource allocation can fail when enabling REBAR support, which
> > is a problem if the failure occurs on the host but not the guest since
> > we have no means via the hardware protocol to expose such a condition.
> > Therefore the model I was considering for vfio-pci would be to simply
> > pre-enable REBAR at the max size.  
> 
> That's a rather bad idea. See our GPUs for example return way more than 
> they actually need.
> 
> E.g. a Polaris usually returns 4GiB even when only 2GiB are installed, 
> because 4GiB is just the maximum amount of RAM you can put together with 
> the ASIC on a board.

Would the driver fail or misbehave if the BAR is sized larger than the
amount of memory on the card or is memory size determined independently
of BAR size?
 
> Some devices even return a mask of all 1 even when they need only 2MiB, 
> resulting in nearly 1TiB of wasted address space with this approach.

Ugh.  I'm afraid to ask why a device with a 2MiB BAR would implement a
REBAR capability, but I guess we really can't make any assumptions
about the breadth of SKUs that ASIC might support (or sanity of the
designers).

We could probe to determine the maximum size the host can support and
potentially emulate the capability to remove sizes that we can't
allocate, but without any ability for the device to reject a size
advertised as supported via the capability protocol it makes me nervous
how we can guarantee the resources are available when the user
re-configures the device.  That might mean we'd need to reserve the
resources, up to what the host can support, regardless of what the
device can actually use.  I'm not sure how else to know how much to
reserve without device specific code in vfio-pci.  Thanks,

Alex

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

Re: [PATCH] drm: Check actual format for legacy pageflip.

2021-01-04 Thread Bas Nieuwenhuizen

+ Ville

On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner  wrote:
>
> On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
>  wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> > implicit modifiers to explicit modifiers with multiple planes.
> >
> > I checked other drivers and it doesn't look like they end up triggering
> > this case so I think this is safe to relax.
> >
> > Signed-off-by: Bas Nieuwenhuizen 
> > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted 
> > metadata.")
> > ---
> >  drivers/gpu/drm/drm_plane.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index e6231947f987..f5085990cfac 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > if (ret)
> > goto out;
> >
> > -   if (old_fb->format != fb->format) {
> > +   if (old_fb->format->format != fb->format->format) {
>
> This was btw. the original way before Ville made it more strict about
> 4 years ago, to catch issues related to tiling, and more complex
> layouts, like the dcc tiling/retiling introduced by your modifier
> patches. That's why I hope my alternative patch is a good solution for
> atomic drivers while keeping the strictness for potential legacy
> drivers.
>
> -mario
>
> > DRM_DEBUG_KMS("Page flip is not allowed to change frame 
> > buffer format.\n");
> > ret = -EINVAL;
> > goto out;
> > --
> > 2.29.2
> >
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs (v2)

Make sure the copy succeeded.  Also fixes a warning.

v2: fix the error check

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 455978781380..b033344c5ce2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -101,7 +101,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
return -EINVAL;
 
memset(str,  0, sizeof(str));
-   copy_from_user(str, buf, size);
+   ret = copy_from_user(str, buf, size);
+   if (ret)
+   return -EFAULT;
 
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0) {
-- 
2.29.2

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

Re: [PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs


Am 04.01.21 um 18:43 schrieb Alex Deucher:

Make sure the copy succeeded.  Also fixes a warning.

Signed-off-by: Alex Deucher 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 455978781380..1f98ce4e56f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -101,7 +101,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
return -EINVAL;
  
  	memset(str,  0, sizeof(str));

-   copy_from_user(str, buf, size);
+   ret = copy_from_user(str, buf, size);
+   if (ret >= size)
+   return -EINVAL;


IIRC copy_from_user return the number of bytes which couldn't be copied.

E.g. theta should be if (ret) return -EFAULT.

Christian.

  
  	ret = pm_runtime_get_sync(dev->dev);

if (ret < 0) {


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

[PATCH] drm/amdgpu: check the result of copy_from_user in secure display debugfs

Make sure the copy succeeded.  Also fixes a warning.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
index 455978781380..1f98ce4e56f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c
@@ -101,7 +101,9 @@ static ssize_t amdgpu_securedisplay_debugfs_write(struct 
file *f, const char __u
return -EINVAL;
 
memset(str,  0, sizeof(str));
-   copy_from_user(str, buf, size);
+   ret = copy_from_user(str, buf, size);
+   if (ret >= size)
+   return -EINVAL;
 
ret = pm_runtime_get_sync(dev->dev);
if (ret < 0) {
-- 
2.29.2

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

Re: Couple of issues with amdgpu on my WX4100

Am 04.01.21 um 17:45 schrieb Alex Williamson:

On Mon, 4 Jan 2021 12:34:34 +0100
Christian König wrote:

Hi Maxim,

I can't help with the display related stuff. Probably best approach to
get this fixes would be to open up a bug tracker for this on FDO.

But I'm the one who implemented the resizeable BAR support and your
analysis of the problem sounds about correct to me.

The reason why this works on Linux is most likely because we restore the
BAR size on resume (and maybe during initial boot as well).

See this patch for reference:

commit d3252ace0bc652a1a24446b6a549f969bf99
Author: Christian König
Date: Fri Jun 29 19:54:55 2018 -0500

PCI: Restore resized BAR state on resume

Resize BARs after resume to the expected size again.

BugLink:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D199959data=04%7C01%7Cchristian.koenig%40amd.com%7C942176d2e6aa4a4f3a4208d8b0d032bd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637453755549960615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3rsR%2Fx4uTpjtXFNqlJyFBteMmZMjWf3Neci7lUlkh88%3Dreserved=0
Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
Signed-off-by: Christian König
Signed-off-by: Bjorn Helgaas
CC: sta...@vger.kernel.org # v4.15+

It should be trivial to add this to the reset module as well. Most
likely even completely vendor independent since I'm not sure what a bus
reset will do to this configuration and restoring it all the time should
be the most defensive approach.

Hmm, this should already be used by the bus/slot reset path:

pci_bus_restore_locked()/pci_slot_restore_locked()
pci_dev_restore()
pci_restore_state()
pci_restore_rebar_state()

VFIO support for resizeable BARs has been on my todo list, but I don't
have access to any systems that have both a capable device and >4G
decoding enabled in the BIOS. If we have a consistent view of the BAR
size after the BARs are expanded, I'm not sure why it doesn't just
work. FWIW, QEMU currently hides the REBAR capability to the guest
because the kernel driver doesn't support emulation through config
space (ie. it's read-only, which the spec doesn't support).

In this case the guest shouldn't be able to change the config at all and
I have no idea what's going wrong here.

AIUI, resource allocation can fail when enabling REBAR support, which
is a problem if the failure occurs on the host but not the guest since
we have no means via the hardware protocol to expose such a condition.
Therefore the model I was considering for vfio-pci would be to simply
pre-enable REBAR at the max size.

That's a rather bad idea. See our GPUs for example return way more than
they actually need.

E.g. a Polaris usually returns 4GiB even when only 2GiB are installed,
because 4GiB is just the maximum amount of RAM you can put together with
the ASIC on a board.

Some devices even return a mask of all 1 even when they need only 2MiB,
resulting in nearly 1TiB of wasted address space with this approach.

Regards,
Christian.

It might be sufficiently safe to
test BAR expansion on initialization and then allow user control, but
I'm concerned that resource availability could change while already in
use by the user. Thanks,

Alex

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

Re: [PATCH] drm: Check actual format for legacy pageflip.

On Sat, Jan 2, 2021 at 9:02 AM Bas Nieuwenhuizen
 wrote:
>
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
>
> I checked other drivers and it doesn't look like they end up triggering
> this case so I think this is safe to relax.
>
> Signed-off-by: Bas Nieuwenhuizen 
> Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted 
> metadata.")

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index e6231947f987..f5085990cfac 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> if (ret)
> goto out;
>
> -   if (old_fb->format != fb->format) {
> +   if (old_fb->format->format != fb->format->format) {
> DRM_DEBUG_KMS("Page flip is not allowed to change frame 
> buffer format.\n");
> ret = -EINVAL;
> goto out;
> --
> 2.29.2
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: fix comparison pointer to bool warning in dc.c

On Tue, Dec 29, 2020 at 4:42 AM Tian Tao  wrote:
>
> Fixes coccicheck warning:
> drivers/gpu/drm/amd/display/dc/core/dc.c:1543:12-19: WARNING: Comparison
> to bool
> drivers/gpu/drm/amd/display/dc/core/dc.c:1496:14-42: WARNING: Comparison
> to bool
> drivers/gpu/drm/amd/display/dc/core/dc.c:971:15-48: WARNING: Comparison
> to bool
> drivers/gpu/drm/amd/display/dc/core/dc.c:976:15-44: WARNING: Comparison
> to bool
>
> Signed-off-by: Tian Tao 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 58eb0d6..ea28b75 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -968,12 +968,12 @@ struct dc *dc_create(const struct dc_init_data 
> *init_params)
> goto alloc_fail;
>
> if (init_params->dce_environment == DCE_ENV_VIRTUAL_HW) {
> -   if (false == dc_construct_ctx(dc, init_params)) {
> +   if (!dc_construct_ctx(dc, init_params)) {
> dc_destruct(dc);
> goto construct_fail;
> }
> } else {
> -   if (false == dc_construct(dc, init_params)) {
> +   if (!dc_construct(dc, init_params)) {
> dc_destruct(dc);
> goto construct_fail;
> }
> @@ -1493,7 +1493,7 @@ bool dc_commit_state(struct dc *dc, struct dc_state 
> *context)
> enum dc_status result = DC_ERROR_UNEXPECTED;
> int i;
>
> -   if (false == context_changed(dc, context))
> +   if (!context_changed(dc, context))
> return DC_OK;
>
> DC_LOG_DC("%s: %d streams\n",
> @@ -1540,7 +1540,7 @@ bool dc_acquire_release_mpc_3dlut(
> if (found_pipe_idx) {
> if (acquire && pool->funcs->acquire_post_bldn_3dlut)
> ret = 
> pool->funcs->acquire_post_bldn_3dlut(res_ctx, pool, mpcc_id, lut, shaper);
> -   else if (acquire == false && 
> pool->funcs->release_post_bldn_3dlut)
> +   else if (!acquire && 
> pool->funcs->release_post_bldn_3dlut)
> ret = 
> pool->funcs->release_post_bldn_3dlut(res_ctx, pool, lut, shaper);
> }
> }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Enable fp16 display support for DCE8+, next try.

On Mon, Dec 28, 2020 at 1:51 PM Mario Kleiner
 wrote:
>
> Hi and happy post-christmas!
>
> I wrote a patch 1/1 that now checks plane scaling factors against
> the pixel-format specific limits in the asic specific dc_plane_cap
> structures during atomic check and other appropriate places.
>
> This should prevent things like asking for scaling on fp16 framebuffers
> if the hw can't do that. Hopefully this will now allow to safely enable
> fp16 scanout also on older asic's like DCE-11.0, DCE-10 and DCE-8.
> Patch 2/2 enables those DCE's now for fp16.
>
> I used some quickly hacked up of IGT test kms_plane_scaling, manually
> hacking the src fb size to make sure the patch correctly accepts or
> rejects atomic commits based on allowable scaling factors for rgbx/a
> 8 bit, 10, and fp16.
>
> This fp16 support has been successfully tested with a Sea Islands /
> DCE-8 laptop. I also confirmed that at least basic HDR signalling
> over HDMI works for that DCE-8 machine with a HDR monitor. For this
> i used the amdvlk driver which exposes fp16 since a while on supported
> hw.

Patches look good to me, but I'd like to get some feedback from the
display folks as well.

>
> There are other bugs in DC wrt. DCE-8 though, which didn't prevent
> my testing, but may be worth looking into. My DCE-8 machine scrambles
> the video output picture somewhat under Vulkan (radv and admvlk) if the
> output signal precision isn't 8 bpc, ie. on 6 bpc (eDP laptop panel)
> and 10 bpc, 12 bpc (HDMI deep color on external HDR monitor).
>
> Another fun thing is getting a black screen if DC is enabled on at least
> Linux 5.10+ (but not if i use the classic kms code in amdgpu-kms). If
> i recompile the driver with a Ubuntu kconfig for Linux 5.9, the 5.10
> kernel works, and the only obvious DC related difference is that DC's
> new SI / DCE-6 asic support is disabled at compile time.

Fixed here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bdeff12a96c9a5da95c8d11fefd145eb165e32a
Patch should be in stable for 5.10 as well.

Alex
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if condition

Applied.  Thanks!

Alex

On Sun, Dec 27, 2020 at 3:56 PM Chenyang Li  wrote:
>
> Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H".
>
> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> Signed-off-by: Chenyang Li 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index ee9480d14cbc..86cfb3d55477 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> @@ -21,7 +21,7 @@
>   *
>   */
>
> -#if !defined(_AMDGPU_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
> +#if !defined(_AMDGPU_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
>  #define _AMDGPU_TRACE_H_
>
>  #include 
> --
> 2.29.2
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH -next] gpu/drm/radeon: use DIV_ROUND_UP macro to do calculation

On Wed, Dec 23, 2020 at 2:06 AM Zheng Yongjun  wrote:
>
> Don't open-code DIV_ROUND_UP() kernel macro.
>
> Signed-off-by: Zheng Yongjun 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/radeon/r600_cs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 390a9621604a..a3aea5329712 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -219,7 +219,7 @@ int r600_fmt_get_nblocksx(u32 format, u32 w)
> if (bw == 0)
> return 0;
>
> -   return (w + bw - 1) / bw;
> +   return DIV_ROUND_UP(w, bw);
>  }
>
>  int r600_fmt_get_nblocksy(u32 format, u32 h)
> @@ -233,7 +233,7 @@ int r600_fmt_get_nblocksy(u32 format, u32 h)
> if (bh == 0)
> return 0;
>
> -   return (h + bh - 1) / bh;
> +   return DIV_ROUND_UP(h, bh);
>  }
>
>  struct array_mode_checker {
> --
> 2.22.0
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/radeon:avoid null pointer dereference when dev is not bound

On Sun, Dec 27, 2020 at 3:56 PM Defang Bo  wrote:
>
> [Why]
> Similar to commit<0fa375e6>. If the set_state/can_switch code access the 
> drm_device when dev is not bound,
> a null pointer dereference can happen.
>
> [How]
> Add sanity checks to prevent it.
>
> Signed-off-by: Defang Bo 

Are you actually hitting this or is this just defensive?  I don't
think we can actually get into a state where this would be a problem.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 266e3cb..50a1a60 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1224,6 +1224,9 @@ static void radeon_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
>  {
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> +   if (!dev)
> +   return;
> +
> if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
> return;
>
> @@ -1257,6 +1260,9 @@ static void radeon_switcheroo_set_state(struct pci_dev 
> *pdev, enum vga_switchero
>  static bool radeon_switcheroo_can_switch(struct pci_dev *pdev)
>  {
> struct drm_device *dev = pci_get_drvdata(pdev);
> +
> +   if (!dev)
> +   return false;
>
> /*
>  * FIXME: open_count is protected by drm_global_mutex but that would 
> lead to
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: remove useless else if

On Mon, Dec 21, 2020 at 9:40 AM Tian Tao  wrote:
>
> Fix the following coccinelle report:
> drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c:1357:6-8:
> WARNING: possible condition with no effect (if == else)
>
> Signed-off-by: Tian Tao 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c
> index 808c4dc..504f2a4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c
> @@ -1354,8 +1354,6 @@ static bool dcn302_resource_construct(
>
> if (dc->ctx->dce_environment == DCE_ENV_PRODUCTION_DRV)
> dc->debug = debug_defaults_drv;
> -   else if (dc->ctx->dce_environment == DCE_ENV_FPGA_MAXIMUS)
> -   dc->debug = debug_defaults_diags;
> else
> dc->debug = debug_defaults_diags;
>
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: remove unused including

On Thu, Dec 31, 2020 at 5:42 AM Tian Tao  wrote:
>
> Remove including  that don't need it.
>
> Signed-off-by: Tian Tao 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 1 -
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c   | 1 -
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 -
>  3 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5675c1f..3255531 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -60,7 +60,6 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index f6f487e..3244a6e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -25,7 +25,6 @@
>
>  #include 
>  #include 
> -#include 
>  #include 
>
>  #include 
> 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 8ab0b90..5b0a4a7 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
> @@ -23,7 +23,6 @@
>   *
>   */
>
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu: fix potential memory leak during navi12 deinitialization

On Thu, Dec 31, 2020 at 4:06 AM Jiawei Gu  wrote:
>
> Navi12 HDCP & DTM deinitialization needs continue to free bo if already
> created though initialized flag is not set.
>
> Signed-off-by: Jiawei Gu 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index b44b46dd60f2..4956fbd512d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -1316,8 +1316,12 @@ static int psp_hdcp_terminate(struct psp_context *psp)
> if (amdgpu_sriov_vf(psp->adev))
> return 0;
>
> -   if (!psp->hdcp_context.hdcp_initialized)
> -   return 0;
> +   if (!psp->hdcp_context.hdcp_initialized) {
> +   if (psp->hdcp_context.hdcp_shared_buf)
> +   goto out;
> +   else
> +   return 0;
> +   }
>
> ret = psp_hdcp_unload(psp);
> if (ret)
> @@ -1325,6 +1329,7 @@ static int psp_hdcp_terminate(struct psp_context *psp)
>
> psp->hdcp_context.hdcp_initialized = false;
>
> +out:
> /* free hdcp shared memory */
> amdgpu_bo_free_kernel(>hdcp_context.hdcp_shared_bo,
>   >hdcp_context.hdcp_shared_mc_addr,
> @@ -1463,8 +1468,12 @@ static int psp_dtm_terminate(struct psp_context *psp)
> if (amdgpu_sriov_vf(psp->adev))
> return 0;
>
> -   if (!psp->dtm_context.dtm_initialized)
> -   return 0;
> +   if (!psp->dtm_context.dtm_initialized) {
> +   if (psp->dtm_context.dtm_shared_buf)
> +   goto out;
> +   else
> +   return 0;
> +   }
>
> ret = psp_dtm_unload(psp);
> if (ret)
> @@ -1472,6 +1481,7 @@ static int psp_dtm_terminate(struct psp_context *psp)
>
> psp->dtm_context.dtm_initialized = false;
>
> +out:
> /* free hdcp shared memory */
> amdgpu_bo_free_kernel(>dtm_context.dtm_shared_bo,
>   >dtm_context.dtm_shared_mc_addr,
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Couple of issues with amdgpu on my WX4100

2021-01-04 Thread Alex Williamson

On Mon, 4 Jan 2021 12:34:34 +0100
Christian König  wrote:

> Hi Maxim,
> 
> I can't help with the display related stuff. Probably best approach to 
> get this fixes would be to open up a bug tracker for this on FDO.
> 
> But I'm the one who implemented the resizeable BAR support and your 
> analysis of the problem sounds about correct to me.
> 
> The reason why this works on Linux is most likely because we restore the 
> BAR size on resume (and maybe during initial boot as well).
> 
> See this patch for reference:
> 
> commit d3252ace0bc652a1a24446b6a549f969bf99
> Author: Christian König 
> Date:   Fri Jun 29 19:54:55 2018 -0500
> 
>      PCI: Restore resized BAR state on resume
> 
>      Resize BARs after resume to the expected size again.
> 
>      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
>      Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
>      Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
>      Signed-off-by: Christian König 
>      Signed-off-by: Bjorn Helgaas 
>      CC: sta...@vger.kernel.org  # v4.15+
> 
> 
> It should be trivial to add this to the reset module as well. Most 
> likely even completely vendor independent since I'm not sure what a bus 
> reset will do to this configuration and restoring it all the time should 
> be the most defensive approach.

Hmm, this should already be used by the bus/slot reset path:

pci_bus_restore_locked()/pci_slot_restore_locked()
 pci_dev_restore()
  pci_restore_state()
   pci_restore_rebar_state()

VFIO support for resizeable BARs has been on my todo list, but I don't
have access to any systems that have both a capable device and >4G
decoding enabled in the BIOS.  If we have a consistent view of the BAR
size after the BARs are expanded, I'm not sure why it doesn't just
work.  FWIW, QEMU currently hides the REBAR capability to the guest
because the kernel driver doesn't support emulation through config
space (ie. it's read-only, which the spec doesn't support).

AIUI, resource allocation can fail when enabling REBAR support, which
is a problem if the failure occurs on the host but not the guest since
we have no means via the hardware protocol to expose such a condition.
Therefore the model I was considering for vfio-pci would be to simply
pre-enable REBAR at the max size.  It might be sufficiently safe to
test BAR expansion on initialization and then allow user control, but
I'm concerned that resource availability could change while already in
use by the user.  Thanks,

Alex

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

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

2021-01-04 Thread Ard Biesheuvel

On Mon, 4 Jan 2021 at 17:27, Alex Deucher  wrote:
>
> On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
> >
> > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> > >
> > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> > > >
> > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > > > >
> > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > > >
> > > > > Simply disabling -mgeneral-regs-only left and right is risky, given 
> > > > > that
> > > > > the standard AArch64 ABI permits the use of FP/SIMD registers 
> > > > > anywhere,
> > > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > > other uses of the FP/SIMD register file that have nothing to do with 
> > > > > the
> > > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > > and kernel_neon_end() around the code that does use FP is not 
> > > > > sufficient
> > > > > here, the problem is in all the other code that may be emitted with
> > > > > references to SIMD registers in it.
> > > > >
> > > > > So the only way to do this properly is to put all floating point code 
> > > > > in
> > > > > a separate compilation unit, and only compile that unit with
> > > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > > something that should be reconsidered entirely.
> > > > >
> > > > > Cc: Catalin Marinas 
> > > > > Cc: Will Deacon 
> > > > > Cc: Dave Martin 
> > > > > Cc: Rob Herring 
> > > > > Cc: Leo Li 
> > > > > Cc: Alex Deucher 
> > > > > Cc: "Christian König" 
> > > > > Cc: David Airlie 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Daniel Kolesa 
> > > > > Cc: amd-gfx@lists.freedesktop.org
> > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > Signed-off-by: Ard Biesheuvel 
> > > >
> > > > Can rebase this on Linus' master branch?  There were a number of new
> > > > asics added which copy pasted the ARM64 support.
> > > >
> > >
> > > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > > on top of mainline is not going to fix the other code that was added.
> > > Or are you asking me to go and find the patches (how many?) that added
> > > new ASICs and fix them for arm64?
> > >
> > > Note that this code is critically broken, as it may corrupt user
> > > process state arbitrarily. So if new code was added that contains the
> > > same bug, it should be reverted so that the respective authors can fix
> > > it and resubmit.
> > >
> >
> > Is this simply about dropping the newly added references to
> > $(dml_rcflags) from the Makefile? Because that is quite trivial ...
>
> Yes, I was thinking something like the attached patch.
>

Cheers, that builds fine with v5.11-rc2/defconfig plus CONFIG_DRM_AMDGPU=m
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use

2021-01-04 Thread Andrey Grodzovsky

Hey Daniel, back from vacation and going over our last long thread i think you 
didn't reply

to my last question bellow (Or at least I can't find it).

Andrey

On 12/17/20 4:13 PM, Andrey Grodzovsky wrote:

Ok, so I assumed that with vmap_local you were trying to solve the problem of
quick reinsertion
of another device into same MMIO range that my driver still points too but
actually are you trying to solve
the issue of exported dma buffers outliving the device ? For this we have
drm_device refcount in the GEM layer
i think.

That's completely different lifetime problems. Don't mix them up :-)
One problem is the hardware disappearing, and for that we _have_ to
guarantee timeliness, or otherwise the pci subsystem gets pissed
(since like you say, a new device might show up and need it's mmio
bars assigned to io ranges). The other is lifetim of the software
objects we use as interfaces, both from userspace and from other
kernel drivers. There we fundamentally can't enforce timely cleanup,
and have to resort to refcounting.



So regarding the second issue, as I mentioned above, don't we already use 
drm_dev_get/put
for exported BOs ? Earlier in this discussion you mentioned that we are ok for 
dma buffers since
we already have the refcounting at the GEM layer and the real life cycle 
problem we have is the dma_fences
for which there is no drm_dev refcounting. Seems to me then that vmap_local is 
superfluous because
of the recounting we already have for exported dma_bufs and for dma_fences it 
won't help.


Andrey 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"

On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel  wrote:
>
> On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel  wrote:
> >
> > On Wed, 16 Dec 2020 at 19:00, Alex Deucher  wrote:
> > >
> > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel  wrote:
> > > >
> > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa.
> > > >
> > > > Simply disabling -mgeneral-regs-only left and right is risky, given that
> > > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
> > > > and GCC is known to use SIMD registers for spilling, and may invent
> > > > other uses of the FP/SIMD register file that have nothing to do with the
> > > > floating point code in question. Note that putting kernel_neon_begin()
> > > > and kernel_neon_end() around the code that does use FP is not sufficient
> > > > here, the problem is in all the other code that may be emitted with
> > > > references to SIMD registers in it.
> > > >
> > > > So the only way to do this properly is to put all floating point code in
> > > > a separate compilation unit, and only compile that unit with
> > > > -mgeneral-regs-only. But perhaps the use of floating point here is
> > > > something that should be reconsidered entirely.
> > > >
> > > > Cc: Catalin Marinas 
> > > > Cc: Will Deacon 
> > > > Cc: Dave Martin 
> > > > Cc: Rob Herring 
> > > > Cc: Leo Li 
> > > > Cc: Alex Deucher 
> > > > Cc: "Christian König" 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Cc: Daniel Kolesa 
> > > > Cc: amd-gfx@lists.freedesktop.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Signed-off-by: Ard Biesheuvel 
> > >
> > > Can rebase this on Linus' master branch?  There were a number of new
> > > asics added which copy pasted the ARM64 support.
> > >
> >
> > Not sure what you are asking me here. Reverting commit c38d444e44badc5
> > on top of mainline is not going to fix the other code that was added.
> > Or are you asking me to go and find the patches (how many?) that added
> > new ASICs and fix them for arm64?
> >
> > Note that this code is critically broken, as it may corrupt user
> > process state arbitrarily. So if new code was added that contains the
> > same bug, it should be reverted so that the respective authors can fix
> > it and resubmit.
> >
>
> Is this simply about dropping the newly added references to
> $(dml_rcflags) from the Makefile? Because that is quite trivial ...

Yes, I was thinking something like the attached patch.

Alex
From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 4 Jan 2021 11:24:20 -0500
Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64

From Ard:

"Simply disabling -mgeneral-regs-only left and right is risky, given that
the standard AArch64 ABI permits the use of FP/SIMD registers anywhere,
and GCC is known to use SIMD registers for spilling, and may invent
other uses of the FP/SIMD register file that have nothing to do with the
floating point code in question. Note that putting kernel_neon_begin()
and kernel_neon_end() around the code that does use FP is not sufficient
here, the problem is in all the other code that may be emitted with
references to SIMD registers in it.

So the only way to do this properly is to put all floating point code in
a separate compilation unit, and only compile that unit with
-mgeneral-regs-only."

Disable support until the code can be properly refactored to support this
properly on aarch64.

Reported-by: Ard Biesheuvel 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/Kconfig   |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  4 
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   | 21 ---
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  7 ---
 .../drm/amd/display/dc/dcn10/dcn10_resource.c |  7 ---
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  5 -
 .../gpu/drm/amd/display/dc/dcn301/Makefile|  4 
 .../gpu/drm/amd/display/dc/dcn302/Makefile|  4 
 drivers/gpu/drm/amd/display/dc/dml/Makefile   |  4 
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  4 
 drivers/gpu/drm/amd/display/dc/os_types.h |  4 
 13 files changed, 1 insertion(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig
index 797b5d4b43e5..e509a175ed17 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
 	bool "AMD DC - Enable new display engine"
 	default y
 	select SND_HDA_COMPONENT if SND_HDA_CORE
-	select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+	select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
 	help
 	  Choose this option if you want to use the new display engine
 	  support for AMDGPU. This adds

Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change


On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote:

[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes for common freesync frame rates.
When commiting these mode changes, a full modeset is not needed.
If the change in only in the front porch timing value, skip full
modeset and continue using the same stream.

Signed-off-by: Aurabindo Pillai 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 169 --
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   1 +
  2 files changed, 153 insertions(+), 17 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 f699a3d41cad..c8c72887906a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -217,6 +217,9 @@ static bool amdgpu_dm_psr_disable_all(struct 
amdgpu_display_manager *dm);
  static const struct drm_format_info *
  amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
  
+static bool

+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+struct drm_crtc_state *new_crtc_state);
  /*
   * dm_vblank_get_counter
   *
@@ -5096,8 +5099,11 @@ copy_crtc_timing_for_drm_display_mode(const struct 
drm_display_mode *src_mode,
  static void
  decide_crtc_timing_for_drm_display_mode(struct drm_display_mode *drm_mode,
const struct drm_display_mode 
*native_mode,
-   bool scale_enabled)
+   bool scale_enabled, bool fs_mode)
  {
+   if (fs_mode)
+   return;
+
if (scale_enabled) {
copy_crtc_timing_for_drm_display_mode(native_mode, drm_mode);
} else if (native_mode->clock == drm_mode->clock &&
@@ -5241,6 +5247,24 @@ get_highest_freesync_mode(struct amdgpu_dm_connector 
*aconnector,
return m_high;
  }
  
+static bool is_freesync_video_mode(struct drm_display_mode *mode,

+  struct amdgpu_dm_connector *aconnector)
+{
+   struct drm_display_mode *high_mode;
+
+   high_mode = get_highest_freesync_mode(aconnector, false);
+   if (!high_mode)
+   return false;
+
+   if (high_mode->clock == 0 ||
+   high_mode->hdisplay != mode->hdisplay ||
+   high_mode->clock != mode->clock ||
+   !mode)
+   return false;
+   else
+   return true;
+}
+


Need to check that the other parameters are the same:
- hsync_start
- hsync_end
- htotal
- hskew
- vdisplay
- vscan

etc.


  static struct dc_stream_state *
  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -5253,17 +5277,21 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
const struct drm_connector_state *con_state =
dm_state ? _state->base : NULL;
struct dc_stream_state *stream = NULL;
-   struct drm_display_mode mode = *drm_mode;
+   struct drm_display_mode saved_mode, mode = *drm_mode;
+   struct drm_display_mode *freesync_mode = NULL;
bool native_mode_found = false;
bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
int mode_refresh;
int preferred_refresh = 0;
+   bool is_fs_vid_mode = 0;
  #if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_dec_dpcd_caps dsc_caps;
  #endif
uint32_t link_bandwidth_kbps;
-
struct dc_sink *sink = NULL;
+
+   memset(_mode, 0, sizeof(struct drm_display_mode));
+
if (aconnector == NULL) {
DRM_ERROR("aconnector is NULL!\n");
return stream;
@@ -5316,20 +5344,33 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
 */
DRM_DEBUG_DRIVER("No preferred mode found\n");
} else {
+   is_fs_vid_mode = is_freesync_video_mode(, aconnector);
+   if (is_fs_vid_mode) {
+   freesync_mode = get_highest_freesync_mode(aconnector, 
false);
+   if (freesync_mode) {
+   saved_mode = mode;
+   mode = *freesync_mode;
+   }
+   }
+
decide_crtc_timing_for_drm_display_mode(
, preferred_mode,
-   dm_state ? (dm_state->scaling != RMX_OFF) : 
false);
+   dm_state ? (dm_state->scaling != RMX_OFF) : 
false,
+   freesync_mode ? true : false);


I don't think we need an additional flag here - scaling/freesync behave 
the same, maybe just rename the variable in the function.


Regards,
Nicholas Kazlauskas


preferred_refresh = drm_mode_vrefresh(preferred_mode);
}
  
  	if (!dm_state)

Re: [PATCH v2 2/3] drm/amd/display: Add freesync video modes based on preferred modes


On 2020-12-11 12:54 a.m., Shashank Sharma wrote:


On 11/12/20 12:18 am, Aurabindo Pillai wrote:

[Why]
If experimental freesync video mode module parameter is enabled, add
few extra display modes into the driver's mode list corresponding to common
video frame rates. When userspace sets these modes, no modeset will be
performed (if current mode was one of freesync modes or the base freesync mode
based off which timings have been generated for the rest of the freesync modes)
since these modes only differ from the base mode with front porch timing.

Signed-off-by: Aurabindo Pillai 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 167 ++
  1 file changed, 167 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fbff8d693e03..d15453b400d2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5178,6 +5178,54 @@ static void dm_enable_per_frame_crtc_master_sync(struct 
dc_state *context)
set_master_stream(context->streams, context->stream_count);
  }
  
+static struct drm_display_mode *

+get_highest_refresh_rate_mode(struct amdgpu_dm_connector *aconnector,
+ bool use_probed_modes)
+{
+   struct drm_display_mode *m, *m_high = NULL;

I would prefer m_high to be renamed as m_pref, indicating it's the preferred 
mode

+   u16 current_refresh, highest_refresh;
+   struct list_head *list_head = use_probed_modes ?
+   
>base.probed_modes :
+   >base.modes;
+   /* Find the preferred mode */
+   list_for_each_entry (m, list_head, head) {
+   if (!(m->type & DRM_MODE_TYPE_PREFERRED))
+   continue;
+
+   m_high = m;
+   highest_refresh = drm_mode_vrefresh(m_high);
+   break;
+   }
+
+   if (!m_high) {
+   /* Probably an EDID with no preferred mode. Fallback to first 
entry */
+   m_high = list_first_entry_or_null(>base.modes,
+ struct drm_display_mode, 
head);
+   if (!m_high)
+   return NULL;
+   else
+   highest_refresh = drm_mode_vrefresh(m_high);
+   }
+


Optional cleanup suggested below makes code more readable:


/* Find the preferred mode */

list_for_each_entry (m, list_head, head) {
     if (m->type & DRM_MODE_TYPE_PREFERRED) {
         m_pref = m;
         break;
     }
}

if (!m_pref) {
     /* Probably an EDID with no preferred mode. Fallback to first entry */
     m_pref = list_first_entry_or_null(>base.modes,
                                       struct drm_display_mode, head);
     if (!m_pref) {
         DRM_DEBUG_DRIVER("No preferred mode found in EDID\n");
         return NULL;
     }
}

highest_refresh = drm_mode_vrefresh(m_pref);


Agreed with this cleanup - naming is confusing as is.


+   /*
+* Find the mode with highest refresh rate with same resolution.
+* For some monitors, preferred mode is not the mode with highest
+* supported refresh rate.
+*/
+   list_for_each_entry (m, list_head, head) {
+   current_refresh  = drm_mode_vrefresh(m);
+
+   if (m->hdisplay == m_high->hdisplay &&
+   m->vdisplay == m_high->vdisplay &&
+   highest_refresh < current_refresh) {
+   highest_refresh = current_refresh;
+   m_high = m;
+   }
+   }
+
+   return m_high;
+}
+
  static struct dc_stream_state *
  create_stream_for_sink(struct amdgpu_dm_connector *aconnector,
   const struct drm_display_mode *drm_mode,
@@ -7006,6 +7054,124 @@ static void amdgpu_dm_connector_ddc_get_modes(struct 
drm_connector *connector,
}
  }
  
+static bool is_duplicate_mode(struct amdgpu_dm_connector *aconnector,

+ struct drm_display_mode *mode)
+{
+   struct drm_display_mode *m;
+
+   list_for_each_entry (m, >base.probed_modes, head) {
+   if (drm_mode_equal(m, mode))
+   return true;
+   }
+
+   return false;
+}
+
+static uint add_fs_modes(struct amdgpu_dm_connector *aconnector,
+struct detailed_data_monitor_range *range)
+{
+   const struct drm_display_mode *m, *m_save;
+   struct drm_display_mode *new_mode;
+   uint i;
+   uint64_t target_vtotal, target_vtotal_diff;
+   uint32_t new_modes_count = 0;
+   uint64_t num, den;

num, den, target_vtotal, target_vtotal_diff can go inside the 
list_for_each_entry() loop;

+
+   /* Standard FPS values
+*
+* 23.976 - TV/NTSC
+* 24 - Cinema
+* 25 - TV/PAL
+* 29.97  - TV/NTSC
+* 30 - TV/NTSC
+

Re: [PATCH 1/3] drm/amd/display: Add module parameter for freesync video mode


On 2020-12-09 9:45 p.m., Aurabindo Pillai wrote:

[Why]
Adds a module parameter to enable experimental freesync video mode modeset
optimization. Enabling this mode allows the driver to skip a full modeset when
freesync compatible modes are requested by the userspace. This paramters also
adds some standard modes based on the connected monitor's VRR range.

Signed-off-by: Aurabindo Pillai 


Reviewed-by: Nicholas Kazlauskas 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 
  2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 83ac06a3ec05..efbfee93c359 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -177,6 +177,7 @@ extern int amdgpu_gpu_recovery;
  extern int amdgpu_emu_mode;
  extern uint amdgpu_smu_memory_pool_size;
  extern uint amdgpu_dc_feature_mask;
+extern uint amdgpu_exp_freesync_vid_mode;
  extern uint amdgpu_dc_debug_mask;
  extern uint amdgpu_dm_abm_level;
  extern struct amdgpu_mgpu_info mgpu_info;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b2a1dd7581bf..ece51ecd53d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -158,6 +158,7 @@ int amdgpu_mes;
  int amdgpu_noretry = -1;
  int amdgpu_force_asic_type = -1;
  int amdgpu_tmz;
+uint amdgpu_exp_freesync_vid_mode;
  int amdgpu_reset_method = -1; /* auto */
  int amdgpu_num_kcq = -1;
  
@@ -786,6 +787,17 @@ module_param_named(abmlevel, amdgpu_dm_abm_level, uint, 0444);

  MODULE_PARM_DESC(tmz, "Enable TMZ feature (-1 = auto, 0 = off (default), 1 = 
on)");
  module_param_named(tmz, amdgpu_tmz, int, 0444);
  
+/**

+ * DOC: experimental_freesync_video (uint)
+ * Enabled the optimization to adjust front porch timing to achieve seamless 
mode change experience
+ * when setting a freesync supported mode for which full modeset is not needed.
+ * The default value: 0 (off).
+ */
+MODULE_PARM_DESC(
+   experimental_freesync_video,
+   "Enable freesync modesetting optimization feature (0 = off (default), 1 = 
on)");
+module_param_named(experimental_freesync_video, amdgpu_exp_freesync_vid_mode, 
uint, 0444);
+
  /**
   * DOC: reset_method (int)
   * GPU reset method (-1 = auto (default), 0 = legacy, 1 = mode0, 2 = mode1, 3 
= mode2, 4 = baco)



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

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

SOLVED

I opened a ticket here:

https://gitlab.freedesktop.org/drm/amd/-/issues/1425

and they suggested, at the end, the same hint (amdgpu.dc=1).

... which, I was sure, I already tried with no results. Maybe I just
misspelled it, and it didn't work.

It's working now, thank you so much for your help.





On Mon, Jan 4, 2021 at 3:01 PM Deucher, Alexander 
wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
> You might try enabling DC (the newer modesetting infrastructure).  Append
> amdgpu.dc=1 to the kernel command line in grub.
>
> Alex
>
> --
> *From:* Davide Corrado 
> *Sent:* Saturday, January 2, 2021 1:50 PM
> *To:* Deucher, Alexander 
> *Cc:* Koenig, Christian ; airl...@linux.ie <
> airl...@linux.ie>; dan...@ffwll.ch ;
> amd-gfx@lists.freedesktop.org ;
> dri-de...@lists.freedesktop.org ;
> linux-ker...@vger.kernel.org 
> *Subject:* amdgpu does not support 3840x2160@30Hz on kaveri apu
>
> hello, I'd like to report this issue that I am having since I updated my
> display (samsung U28E590). The amdgpu does not support the native
> resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI
> connection (I tried both, same results), the maximum supported refresh is
> 30Hz, so I'm stuck with that (don't have a displayport). The radeon module
> works fine, I'm having this issue just when I use amdgpu (which I'd like
> to, because performance is better).
>
> Some info of my hardware:
>
> cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
> kernel version (I tried different ones and different linux distros, same
> results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
> Monitor: Samsung U28E590.
>
> description:
> If I boot the system using amdgpu and no video mode selection, the system
> boots but I don't get a screen during boot and in wayland. I can connect
> using ssh, so the system is running fine, just no display; If I force a
> full HD resolution with "video:" in the kernel line, I can see the boot
> process but the screen disappears when wayland starts (because the default
> resolution is 3840x2160@30Hz). Using a full HD monitor results in no
> issues, so it must be related to this very 4k resolution.
>
> As I have already stated, radeon module works with the same
> software/hardware configuration.
> thanks you so much for your time :-)
>
> --
> Davide Corrado
> UNIX Team Leader
>
> Via Abramo Lincoln, 25
> 20129 Milano
>
> Tel +39 3474259950
>


-- 
Davide Corrado
UNIX Team Leader

Via Abramo Lincoln, 25
20129 Milano

Tel +39 3474259950
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Btw, should the driver switch to the lower supported resolution then?

Il Lun 4 Gen 2021, 13:04 Davide Corrado  ha
scritto:

> Hello. This resolution is supported by the Apu and the motherboard specs.
> Will try what you suggest and let you know
>
> Il Lun 4 Gen 2021, 12:10 Christian König 
> ha scritto:
>
>> Hi Davide,
>>
>> adding a few of our AMD display people.
>>
>> In general as already suggested by others opening a bug report to track
>> this is the right thing to do.
>>
>> In the past we had a few bug reports like this because amdgpu is more
>> strict in checking hardware limitations.
>>
>> For example it can be that your HDMI port on the board can only handle a
>> certain maximum pixel clock, but radeon is ignoring this while amdgpu isn't.
>>
>> What you can try to do is to manually override the used mode, e.g. copy
>> the modeline used when radeon is active and manually add that using xrandr
>> when amdgpu is active and see if it works or not.
>>
>> Regards,
>> Christian.
>>
>> Am 02.01.21 um 19:50 schrieb Davide Corrado:
>>
>> hello, I'd like to report this issue that I am having since I updated my
>> display (samsung U28E590). The amdgpu does not support the native
>> resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI
>> connection (I tried both, same results), the maximum supported refresh is
>> 30Hz, so I'm stuck with that (don't have a displayport). The radeon module
>> works fine, I'm having this issue just when I use amdgpu (which I'd like
>> to, because performance is better).
>>
>> Some info of my hardware:
>>
>> cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
>> kernel version (I tried different ones and different linux distros, same
>> results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020
>> x86_64 x86_64 x86_64 GNU/Linux
>> Monitor: Samsung U28E590.
>>
>> description:
>> If I boot the system using amdgpu and no video mode selection, the system
>> boots but I don't get a screen during boot and in wayland. I can connect
>> using ssh, so the system is running fine, just no display; If I force a
>> full HD resolution with "video:" in the kernel line, I can see the boot
>> process but the screen disappears when wayland starts (because the default
>> resolution is 3840x2160@30Hz). Using a full HD monitor results in no
>> issues, so it must be related to this very 4k resolution.
>>
>> As I have already stated, radeon module works with the same
>> software/hardware configuration.
>> thanks you so much for your time :-)
>>
>> --
>> Davide Corrado
>> UNIX Team Leader
>>
>> Via Abramo Lincoln, 25
>> 20129 Milano
>>
>> Tel +39 3474259950
>>
>> ___
>> amd-gfx mailing 
>> listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

Hello. This resolution is supported by the Apu and the motherboard specs.
Will try what you suggest and let you know

Il Lun 4 Gen 2021, 12:10 Christian König 
ha scritto:

> Hi Davide,
>
> adding a few of our AMD display people.
>
> In general as already suggested by others opening a bug report to track
> this is the right thing to do.
>
> In the past we had a few bug reports like this because amdgpu is more
> strict in checking hardware limitations.
>
> For example it can be that your HDMI port on the board can only handle a
> certain maximum pixel clock, but radeon is ignoring this while amdgpu isn't.
>
> What you can try to do is to manually override the used mode, e.g. copy
> the modeline used when radeon is active and manually add that using xrandr
> when amdgpu is active and see if it works or not.
>
> Regards,
> Christian.
>
> Am 02.01.21 um 19:50 schrieb Davide Corrado:
>
> hello, I'd like to report this issue that I am having since I updated my
> display (samsung U28E590). The amdgpu does not support the native
> resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI
> connection (I tried both, same results), the maximum supported refresh is
> 30Hz, so I'm stuck with that (don't have a displayport). The radeon module
> works fine, I'm having this issue just when I use amdgpu (which I'd like
> to, because performance is better).
>
> Some info of my hardware:
>
> cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
> kernel version (I tried different ones and different linux distros, same
> results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
> Monitor: Samsung U28E590.
>
> description:
> If I boot the system using amdgpu and no video mode selection, the system
> boots but I don't get a screen during boot and in wayland. I can connect
> using ssh, so the system is running fine, just no display; If I force a
> full HD resolution with "video:" in the kernel line, I can see the boot
> process but the screen disappears when wayland starts (because the default
> resolution is 3840x2160@30Hz). Using a full HD monitor results in no
> issues, so it must be related to this very 4k resolution.
>
> As I have already stated, radeon module works with the same
> software/hardware configuration.
> thanks you so much for your time :-)
>
> --
> Davide Corrado
> UNIX Team Leader
>
> Via Abramo Lincoln, 25
> 20129 Milano
>
> Tel +39 3474259950
>
> ___
> amd-gfx mailing 
> listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

2021-01-04 Thread Deucher, Alexander

[AMD Official Use Only - Internal Distribution Only]

You might try enabling DC (the newer modesetting infrastructure).  Append 
amdgpu.dc=1 to the kernel command line in grub.

Alex


From: Davide Corrado 
Sent: Saturday, January 2, 2021 1:50 PM
To: Deucher, Alexander 
Cc: Koenig, Christian ; airl...@linux.ie 
; dan...@ffwll.ch ; 
amd-gfx@lists.freedesktop.org ; 
dri-de...@lists.freedesktop.org ; 
linux-ker...@vger.kernel.org 
Subject: amdgpu does not support 3840x2160@30Hz on kaveri apu

hello, I'd like to report this issue that I am having since I updated my 
display (samsung U28E590). The amdgpu does not support the native resolution of 
my new monitor, which is 3840x2160. Using a HDMI or DVI connection (I tried 
both, same results), the maximum supported refresh is 30Hz, so I'm stuck with 
that (don't have a displayport). The radeon module works fine, I'm having this 
issue just when I use amdgpu (which I'd like to, because performance is better).

Some info of my hardware:

cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
kernel version (I tried different ones and different linux distros, same 
results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 x86_64 
x86_64 x86_64 GNU/Linux
Monitor: Samsung U28E590.

description:
If I boot the system using amdgpu and no video mode selection, the system boots 
but I don't get a screen during boot and in wayland. I can connect using ssh, 
so the system is running fine, just no display; If I force a full HD resolution 
with "video:" in the kernel line, I can see the boot process but the screen 
disappears when wayland starts (because the default resolution is 
3840x2160@30Hz). Using a full HD monitor results in no issues, so it must be 
related to this very 4k resolution.

As I have already stated, radeon module works with the same software/hardware 
configuration.
thanks you so much for your time :-)

--
Davide Corrado
UNIX Team Leader

Via Abramo Lincoln, 25
20129 Milano

Tel +39 3474259950
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu


Yes, absolutely. Do you only get a black screen?

That would certainly be a rather big bug.

Christian.

Am 04.01.21 um 13:37 schrieb Davide Corrado:

Btw, should the driver switch to the lower supported resolution then?

Il Lun 4 Gen 2021, 13:04 Davide Corrado > ha scritto:


Hello. This resolution is supported by the Apu and the motherboard
specs. Will try what you suggest and let you know

Il Lun 4 Gen 2021, 12:10 Christian König
mailto:ckoenig.leichtzumer...@gmail.com>> ha scritto:

Hi Davide,

adding a few of our AMD display people.

In general as already suggested by others opening a bug report
to track this is the right thing to do.

In the past we had a few bug reports like this because amdgpu
is more strict in checking hardware limitations.

For example it can be that your HDMI port on the board can
only handle a certain maximum pixel clock, but radeon is
ignoring this while amdgpu isn't.

What you can try to do is to manually override the used mode,
e.g. copy the modeline used when radeon is active and manually
add that using xrandr when amdgpu is active and see if it
works or not.

Regards,
Christian.

Am 02.01.21 um 19:50 schrieb Davide Corrado:

hello, I'd like to report this issue that I am having since I
updated my display (samsung U28E590). The amdgpu does not
support the native resolution of my new monitor, which is
3840x2160/./ Using a HDMI or DVI connection (I tried both,
same results), the maximum supported refresh is 30Hz, so I'm
stuck with that (don't have a displayport). The radeon module
works fine, I'm having this issue just when I use amdgpu
(which I'd like to, because performance is better).

Some info of my hardware:

cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
kernel version (I tried different ones and different linux
distros, same results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon
Dec 21 14:08:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Monitor: Samsung U28E590.

description:
If I boot the system using amdgpu and no video mode
selection, the system boots but I don't get a screen during
boot and in wayland. I can connect using ssh, so the system
is running fine, just no display; If I force a full HD
resolution with "video:" in the kernel line, I can see the
boot process but the screen disappears when wayland starts
(because the default resolution is 3840x2160@30Hz). Using a
full HD monitor results in no issues, so it must be related
to this very 4k resolution.

As I have already stated, radeon module works with the same
software/hardware configuration.
thanks you so much for your time :-)

-- 
Davide Corrado

UNIX Team Leader

Via Abramo Lincoln, 25
20129 Milano

Tel +39 3474259950

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





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

Re: [PATCH 5/5] drm/amdgpu: remove redundant logic related HDP


Looks like a nice cleanup to me.

Just one question: We have a flush_hdp and invalidate_hdp callback in 
the asic structure as well.


Would it make sense to replace those as well in the long term?

Thanks,
Christian.

Am 28.12.20 um 10:18 schrieb Likun Gao:

From: Likun Gao 

Remove hdp_flush function from amdgpu_nbio struct as it have been unfied
into hdp struct.
Remove the include about hdp register which was not used.

Signed-off-by: Likun Gao 
Change-Id: I7b1ce7424a97efe82ccb6ce63505e724530715ac
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h |  1 -
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c|  1 -
  drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c   | 10 --
  drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c   | 13 -
  drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c   | 10 --
  drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c   | 10 --
  drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c   | 10 --
  drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c   |  1 -
  drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c   |  1 -
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c|  1 -
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c|  1 -
  11 files changed, 59 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
index e62cc0e1a5ad..4ba0024aedf1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
@@ -57,7 +57,6 @@ struct amdgpu_nbio_funcs {
u32 (*get_pcie_port_data_offset)(struct amdgpu_device *adev);
u32 (*get_rev_id)(struct amdgpu_device *adev);
void (*mc_access_enable)(struct amdgpu_device *adev, bool enable);
-   void (*hdp_flush)(struct amdgpu_device *adev, struct amdgpu_ring *ring);
u32 (*get_memsize)(struct amdgpu_device *adev);
void (*sdma_doorbell_range)(struct amdgpu_device *adev, int instance,
bool use_doorbell, int doorbell_index, int 
doorbell_size);
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 5f4805e4d04a..a896e3d0fcf8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -38,7 +38,6 @@
  #include "gc/gc_9_0_sh_mask.h"
  
  #include "vega10_enum.h"

-#include "hdp/hdp_4_0_offset.h"
  
  #include "soc15_common.h"

  #include "clearstate_gfx9.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
index b5c3db16c2b0..b860f1c7b5b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c
@@ -80,15 +80,6 @@ static void nbio_v2_3_mc_access_enable(struct amdgpu_device 
*adev, bool enable)
WREG32_SOC15(NBIO, 0, mmBIF_FB_EN, 0);
  }
  
-static void nbio_v2_3_hdp_flush(struct amdgpu_device *adev,

-   struct amdgpu_ring *ring)
-{
-   if (!ring || !ring->funcs->emit_wreg)
-   WREG32_NO_KIQ((adev->rmmio_remap.reg_offset + 
KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0);
-   else
-   amdgpu_ring_emit_wreg(ring, (adev->rmmio_remap.reg_offset + 
KFD_MMIO_REMAP_HDP_MEM_FLUSH_CNTL) >> 2, 0);
-}
-
  static u32 nbio_v2_3_get_memsize(struct amdgpu_device *adev)
  {
return RREG32_SOC15(NBIO, 0, mmRCC_DEV0_EPF0_RCC_CONFIG_MEMSIZE);
@@ -366,7 +357,6 @@ const struct amdgpu_nbio_funcs nbio_v2_3_funcs = {
.get_pcie_data_offset = nbio_v2_3_get_pcie_data_offset,
.get_rev_id = nbio_v2_3_get_rev_id,
.mc_access_enable = nbio_v2_3_mc_access_enable,
-   .hdp_flush = nbio_v2_3_hdp_flush,
.get_memsize = nbio_v2_3_get_memsize,
.sdma_doorbell_range = nbio_v2_3_sdma_doorbell_range,
.vcn_doorbell_range = nbio_v2_3_vcn_doorbell_range,
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c
index d2f1fe55d388..8427f10712ff 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c
@@ -50,18 +50,6 @@ static void nbio_v6_1_mc_access_enable(struct amdgpu_device 
*adev, bool enable)
WREG32_SOC15(NBIO, 0, mmBIF_FB_EN, 0);
  }
  
-static void nbio_v6_1_hdp_flush(struct amdgpu_device *adev,

-   struct amdgpu_ring *ring)
-{
-   if (!ring || !ring->funcs->emit_wreg)
-   WREG32_SOC15_NO_KIQ(NBIO, 0,
-   mmBIF_BX_PF0_HDP_MEM_COHERENCY_FLUSH_CNTL,
-   0);
-   else
-   amdgpu_ring_emit_wreg(ring, SOC15_REG_OFFSET(
-   NBIO, 0, mmBIF_BX_PF0_HDP_MEM_COHERENCY_FLUSH_CNTL), 0);
-}
-
  static u32 nbio_v6_1_get_memsize(struct amdgpu_device *adev)
  {
return RREG32_SOC15(NBIO, 0, mmRCC_PF_0_0_RCC_CONFIG_MEMSIZE);
@@ -266,7 +254,6 @@ const struct amdgpu_nbio_funcs nbio_v6_1_funcs = {
.get_pcie_data_offset = nbio_v6_1_get_pcie_data_offset,
.get_rev_id = nbio_v6_1_get_rev_id,
.mc_access_enable = nbio_v6_1_mc_access_enable,
-   .hdp_flush =

Re: Couple of issues with amdgpu on my WX4100


Hi Maxim,

I can't help with the display related stuff. Probably best approach to 
get this fixes would be to open up a bug tracker for this on FDO.


But I'm the one who implemented the resizeable BAR support and your 
analysis of the problem sounds about correct to me.


The reason why this works on Linux is most likely because we restore the 
BAR size on resume (and maybe during initial boot as well).


See this patch for reference:

commit d3252ace0bc652a1a24446b6a549f969bf99
Author: Christian König 
Date:   Fri Jun 29 19:54:55 2018 -0500

    PCI: Restore resized BAR state on resume

    Resize BARs after resume to the expected size again.

    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199959
    Fixes: d6895ad39f3b ("drm/amdgpu: resize VRAM BAR for CPU access v6")
    Fixes: 276b738deb5b ("PCI: Add resizable BAR infrastructure")
    Signed-off-by: Christian König 
    Signed-off-by: Bjorn Helgaas 
    CC: sta...@vger.kernel.org  # v4.15+


It should be trivial to add this to the reset module as well. Most 
likely even completely vendor independent since I'm not sure what a bus 
reset will do to this configuration and restoring it all the time should 
be the most defensive approach.


Let me know if you got any more questions on this.

Regards,
Christian.

Am 02.01.21 um 23:42 schrieb Maxim Levitsky:

Hi!

I am using this card for about a year and I would like first to say thanks
for open source driver that you made for it, for the big navi
and for the threadripper which brought back fun to the computing.

I bought that card primary to use as a host GPU in VFIO enabled multi-seat
system I am building, and recently I was able (with a minor issue I managed to
solve, more about it later) to pass that GPU to both linux and windows guest
mostly flawlessly.
  
I do have experience in kernel development, and debugging so I am willing

to test patches, etc. Any help is welcome!
  
So these are the issues:
  
1.(the biggest issue): The amdgpu driver often crashes when plugging an input.


I tested this now on purpose with 'amdgpu.dc=1' by slowly plugging and 
unplugging
an input connector while I wait for the output to stabilize between each cycle,
and still the issue reproduced after a dozen (or so) tries.
(It only happens when I plug the connector, and never happens when I unplug it)

Then I unloaded the amdgpu driver and loaded it again with dc=0.
This does sort of work but takes a lot of time. The dmesg output is attached
(amdgpu_dc1_plug_bug.txt)
  
I did try to increase the number of tries in dm_helpers_read_local_edid, to

something silly like 1000, but no luck.
  
I also tried to remove the code below the

'Abort detection for non-DP connectors if we have no EDID'
Also no luck.


This bug pretty much makes it impossible to use the card daily as is
since I do connect/disconnect monitors often, especially due to VFIO usage.
  
2. I found out that running without the new DC framework (amdgpu.dc=0) solves

issue 1 completely (but costs HDMI sound - HDMI sound only works with 
amdgpu.dc=1)

I am using this card like that for about at least half an year and haven't had
a single connector plug/unplug related crash.

Issue 2 however is that in this mode (I haven't tried to reproduce this
with amdgpu.dc=1 yet), sometimes when I unbind the amdgpu driver
the amdgpu complains about a leaked connector and crashes a bit later on.
I haven't yet tracked the combination of things needed
to trigger this, but it did happen to me about 3 times already.
  
I did put a WARN_ON(1) to __drm_connector_put_safe, to see who

is the caller that triggers the delayed work that frees the connector when it is
too late.

I attached a backtrace with the above WARN_ON and the crash 
(connector_leak_bug.txt)
I also attached the script 'amdgpu_unbind' for the reference that I use to 
unbind
the amdgpu driver.
  
3. When doing VFIO passthrough of this card, I found out that it doesn't

suffer that much from the reset bug. As long as I shut down the guest
in clean manner, I can start it again). The vendor_reset module however
makes the reset work even when I shut down the guest right in the middle
of a 3D app running and I tested it many times.
  
_However_ this only works if I never load the amdgpu linux driver.

Otherwise a windows guest still boots but all 3D apps in it crash very early.

I tried both the stock drivers that windows auto installs and latest AMD
workstation drivers from AMD site.

Linux guests do work.
  
I found out that amdgpu driver resizes the device bars (I have TRX40 platform,

so I don't know if this platform supports the AMD Smart Memory or not,
but according to lspci the device does support resizable BARs).

If I patch the amdgpu's bar resize out, then, the windows guest _does_ work
regardless if I loaded amdgpu prior or not. Linux guests also still work.
I haven't measured the performance impact of this.

For debugging this, I did try to hide the PCI_EXT_CAP_ID_REBAR capability
from the VM,

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu


Hi Davide,

adding a few of our AMD display people.

In general as already suggested by others opening a bug report to track 
this is the right thing to do.


In the past we had a few bug reports like this because amdgpu is more 
strict in checking hardware limitations.


For example it can be that your HDMI port on the board can only handle a 
certain maximum pixel clock, but radeon is ignoring this while amdgpu isn't.


What you can try to do is to manually override the used mode, e.g. copy 
the modeline used when radeon is active and manually add that using 
xrandr when amdgpu is active and see if it works or not.


Regards,
Christian.

Am 02.01.21 um 19:50 schrieb Davide Corrado:
hello, I'd like to report this issue that I am having since I updated 
my display (samsung U28E590). The amdgpu does not support the native 
resolution of my new monitor, which is 3840x2160/./ Using a HDMI or 
DVI connection (I tried both, same results), the maximum supported 
refresh is 30Hz, so I'm stuck with that (don't have a displayport). 
The radeon module works fine, I'm having this issue just when I use 
amdgpu (which I'd like to, because performance is better).


Some info of my hardware:

cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
kernel version (I tried different ones and different linux distros, 
same results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 
2020 x86_64 x86_64 x86_64 GNU/Linux

Monitor: Samsung U28E590.

description:
If I boot the system using amdgpu and no video mode selection, the 
system boots but I don't get a screen during boot and in wayland. I 
can connect using ssh, so the system is running fine, just no display; 
If I force a full HD resolution with "video:" in the kernel line, I 
can see the boot process but the screen disappears when wayland starts 
(because the default resolution is 3840x2160@30Hz). Using a full HD 
monitor results in no issues, so it must be related to this very 4k 
resolution.


As I have already stated, radeon module works with the same 
software/hardware configuration.

thanks you so much for your time :-)

--
Davide Corrado
UNIX Team Leader

Via Abramo Lincoln, 25
20129 Milano

Tel +39 3474259950

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


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

Re: [PATCH] drm: Check actual format for legacy pageflip.


Am 02.01.21 um 15:02 schrieb Bas Nieuwenhuizen:

With modifiers one can actually have different format_info structs
for the same format, which now matters for AMDGPU since we convert
implicit modifiers to explicit modifiers with multiple planes.

I checked other drivers and it doesn't look like they end up triggering
this case so I think this is safe to relax.

Signed-off-by: Bas Nieuwenhuizen 
Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted 
metadata.")


I don't know the details of the code at all, but from a high level point 
of view that makes much more sense than the original patch.


Acked-by: Christian König 


---
  drivers/gpu/drm/drm_plane.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e6231947f987..f5085990cfac 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (ret)
goto out;
  
-	if (old_fb->format != fb->format) {

+   if (old_fb->format->format != fb->format->format) {
DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer 
format.\n");
ret = -EINVAL;
goto out;


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

Re: [PATCH] drm: Check actual format for legacy pageflip.

2021-01-04 Thread Pierre-Eric Pelloux-Prayer

Hi Bas,

On 02/01/2021 15:02, Bas Nieuwenhuizen wrote:
> With modifiers one can actually have different format_info structs
> for the same format, which now matters for AMDGPU since we convert
> implicit modifiers to explicit modifiers with multiple planes.
> 
> I checked other drivers and it doesn't look like they end up triggering
> this case so I think this is safe to relax.

This patch fixes https://gitlab.freedesktop.org/drm/amd/-/issues/1379:

   Tested-by: Pierre-Eric Pelloux-Prayer 

Thanks!
P-E

> 
> Signed-off-by: Bas Nieuwenhuizen 
> Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted 
> metadata.")
> ---
>  drivers/gpu/drm/drm_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index e6231947f987..f5085990cfac 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   if (ret)
>   goto out;
>  
> - if (old_fb->format != fb->format) {
> + if (old_fb->format->format != fb->format->format) {
>   DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer 
> format.\n");
>   ret = -EINVAL;
>   goto out;
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm/amdgpu: remove redundant include of navi10_enum

2021-01-04 Thread Zhang, Hawking

[AMD Public Use]

Reviewed-by: Hawking Zhang 

Regards,
Hawking
-Original Message-
From: Gao, Likun  
Sent: Monday, January 4, 2021 17:33
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Gao, Likun 
Subject: [PATCH] drm/amdgpu: remove redundant include of navi10_enum

From: Likun Gao 

Remove unnecessary include of navi10_enum header file.

Signed-off-by: Likun Gao 
Change-Id: Id9697d0cf68339b3005b634ab5cf2f7bc39e47ef
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c   | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 1 -
 drivers/gpu/drm/amd/amdgpu/athub_v2_0.c  | 1 -
 drivers/gpu/drm/amd/amdgpu/athub_v2_1.c  | 1 -
 4 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 1529815838f7..fa7e8ff72dfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -23,7 +23,6 @@
 #include "amdgpu_amdkfd.h"
 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
-#include "navi10_enum.h"
 #include "athub/athub_2_0_0_offset.h"
 #include "athub/athub_2_0_0_sh_mask.h"
 #include "oss/osssys_5_0_0_offset.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
index 50016bf9c427..fad3b91f74f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
@@ -24,7 +24,6 @@
 #include "amdgpu_amdkfd.h"
 #include "gc/gc_10_3_0_offset.h"
 #include "gc/gc_10_3_0_sh_mask.h"
-#include "navi10_enum.h"
 #include "oss/osssys_5_0_0_offset.h"
 #include "oss/osssys_5_0_0_sh_mask.h"
 #include "soc15_common.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c 
b/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
index 921a69abda55..5b90efd6f6d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
@@ -27,7 +27,6 @@
 #include "athub/athub_2_0_0_offset.h"
 #include "athub/athub_2_0_0_sh_mask.h"
 #include "athub/athub_2_0_0_default.h"
-#include "navi10_enum.h"
 
 #include "soc15_common.h"
 
diff --git a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c 
b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
index 66c183ddd43e..7b1b18350bf9 100644
--- a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
@@ -26,7 +26,6 @@
 
 #include "athub/athub_2_1_0_offset.h"
 #include "athub/athub_2_1_0_sh_mask.h"
-#include "navi10_enum.h"
 
 #include "soc15_common.h"
 
-- 
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: remove redundant include of navi10_enum

2021-01-04 Thread Likun Gao

From: Likun Gao 

Remove unnecessary include of navi10_enum header file.

Signed-off-by: Likun Gao 
Change-Id: Id9697d0cf68339b3005b634ab5cf2f7bc39e47ef
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c   | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 1 -
 drivers/gpu/drm/amd/amdgpu/athub_v2_0.c  | 1 -
 drivers/gpu/drm/amd/amdgpu/athub_v2_1.c  | 1 -
 4 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 1529815838f7..fa7e8ff72dfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -23,7 +23,6 @@
 #include "amdgpu_amdkfd.h"
 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
-#include "navi10_enum.h"
 #include "athub/athub_2_0_0_offset.h"
 #include "athub/athub_2_0_0_sh_mask.h"
 #include "oss/osssys_5_0_0_offset.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
index 50016bf9c427..fad3b91f74f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c
@@ -24,7 +24,6 @@
 #include "amdgpu_amdkfd.h"
 #include "gc/gc_10_3_0_offset.h"
 #include "gc/gc_10_3_0_sh_mask.h"
-#include "navi10_enum.h"
 #include "oss/osssys_5_0_0_offset.h"
 #include "oss/osssys_5_0_0_sh_mask.h"
 #include "soc15_common.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c 
b/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
index 921a69abda55..5b90efd6f6d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/athub_v2_0.c
@@ -27,7 +27,6 @@
 #include "athub/athub_2_0_0_offset.h"
 #include "athub/athub_2_0_0_sh_mask.h"
 #include "athub/athub_2_0_0_default.h"
-#include "navi10_enum.h"
 
 #include "soc15_common.h"
 
diff --git a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c 
b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
index 66c183ddd43e..7b1b18350bf9 100644
--- a/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/athub_v2_1.c
@@ -26,7 +26,6 @@
 
 #include "athub/athub_2_1_0_offset.h"
 #include "athub/athub_2_1_0_sh_mask.h"
-#include "navi10_enum.h"
 
 #include "soc15_common.h"
 
-- 
2.25.1

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

Bug: RX 580 screen goes dark after switching monitor to different input and back

2021-01-04 Thread Davin McCall

Hi, I would like to report the following issue which begain with kernel
5.4.86.

Please let me know if I should also file a bug in bugzilla.

Note that I have narrowed it down to the change which causes the issue
(e1b1f10c3404c8d40c45c3a6846d304fd403fa2c in linux-5.4 series, upstream
a135a1b4c4db1f3b8cbed9676a40ede39feb3362).

I am happy to try patches and help debug in any way I can.

Regards,

Davin McCall


[1.] One line summary of the problem:

RX 580 screen goes dark after switching monitor to different input and back

[2.] Full description of the problem/report:

I have an RX 580 graphics adapter connected via displayport to my
monitor. When I switch the monitor to a different input and then back,
the display remains dark. The following appears in the dmesg output:

Jan  4 10:28:04 localhost vmunix: [drm:dce112_get_pix_clk_dividers
[amdgpu]] *ERROR* dce112_get_pix_clk_dividers: Invalid parameters!!
Jan  4 10:28:04 localhost vmunix: [drm:dm_restore_drm_connector_state
[amdgpu]] *ERROR* Restoring old state failed with -22

This happens with kernel 5.4.86 but not 5.4.85 and can be reproduced
reliably.

I have narrowed it down to the following change:

commit e1b1f10c3404c8d40c45c3a6846d304fd403fa2c
Author: Stylon Wang 
Date:   Tue Nov 10 15:40:06 2020 +0800

drm/amd/display: Fix memory leaks in S3 resume

commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362 upstream.

EDID parsing in S3 resume pushes new display modes
to probed_modes list but doesn't consolidate to actual
mode list. This creates a race condition when
amdgpu_dm_connector_ddc_get_modes() re-initializes the
list head without walking the list and results in  memory leak.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209987
Acked-by: Harry Wentland 
Acked-by: Alex Deucher 
Reviewed-by: Nicholas Kazlauskas 
Signed-off-by: Stylon Wang 
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 


[3.] Keywords (i.e., modules, networking, kernel):

amdgpu

[4.] Kernel information

kernel compiled from source with custom configuration

[4.1.] Kernel version (from /proc/version):

Linux version 5.4.86 (root@dragon) (gcc version 9.3.0 (GCC)) #1 SMP
PREEMPT Mon Jan 4 13:06:47 AEST 2021

[4.2.] Kernel .config file:

... Is 4k lines long. I'm going to assume it's not really wanted here?
Can supply on request.

[5.] Most recent kernel version which did not have the bug:

5.4.85

[6.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/admin-guide/oops-tracing.rst)

N/A

[7.] A small shell script or example program which triggers the
 problem (if possible)

N/A

[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)

Linux dragon 5.4.86 #1 SMP PREEMPT Mon Jan 4 13:06:47 AEST 2021 x86_64
GNU/Linux

GNU C       9.3.0
GNU Make        4.2.1
Binutils        2.35.1
Util-linux      2.36.1
Mount       2.36.1
Module-init-tools       21
E2fsprogs       1.44.4
PPP     2.4.4
Linux C Library     2.32
Dynamic linker (ldd)    2.32
Linux C++ Library       9.3.0
Procps      3.2.7
Net-tools       1.9.4
Kbd     2.0.4
Console-tools       2.0.4
Sh-utils        8.32
Udev        228
Wireless-tools      29
Modules Loaded      aesni_intel amdgpu backlight cfbcopyarea
cfbfillrect cfbimgblt cfg80211 cryptd crypto_simd drm drm_kms_helper
drm_panel_orientation_quirks fb fbdev fb_sys_fops font glue_helper
gpu_sched i2c_algo_bit i2c_core snd_hda_codec snd_hda_codec_generic
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_intel
snd_intel_nhlt syscopyarea sysfillrect sysimgblt ttm video

[8.2.] Processor information (from /proc/cpuinfo):

processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 60
model name    : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
stepping    : 3
microcode    : 0x24
cpu MHz        : 4389.681
cache size    : 8192 KB
physical id    : 0
siblings    : 8
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2
x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault
invpcid_single tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
mds

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu