1. 28 May, 2020 31 commits
  2. 27 May, 2020 2 commits
  3. 26 May, 2020 2 commits
  4. 22 May, 2020 5 commits
    • Lyude Paul's avatar
      drm/vblank: Fix -Wformat compile warnings on some arches · 6f27e4c2
      Lyude Paul authored
      On some architectures like ppc64le and aarch64, compiling with
      -Wformat=1 will throw the following warnings:
      
        In file included from drivers/gpu/drm/drm_vblank.c:33:
        drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
        drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
        argument of type 'long long unsigned int', but argument 4 has type
        'long int' [-Wformat=]
          DRM_DEBUG_VBL("updating vblank count on crtc %u:"
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ./include/drm/drm_print.h:407:22: note: in definition of macro
        'DRM_DEBUG_VBL'
          drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
                              ^~~
        drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
                 " current=%llu, diff=%u, hw=%u hw_last=%u\n",
                           ~~~^
                           %lu
      
      So, fix that with a typecast.
      Co-developed-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200521204647.2578479-1-lyude@redhat.com
      6f27e4c2
    • Felix Kuehling's avatar
      drm/amdgpu: Sync with VM root BO when switching VM to CPU update mode · 90ca78de
      Felix Kuehling authored
      This fixes an intermittent bug where a root PD clear operation still in
      progress could overwrite a PDE update done by the CPU, resulting in a
      VM fault.
      
      Fixes: 108b4d92 ("drm/amd/amdgpu: Update VM function pointer")
      Reported-by: default avatarJay Cornwall <Jay.Cornwall@amd.com>
      Tested-by: default avatarJay Cornwall <Jay.Cornwall@amd.com>
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      90ca78de
    • Bhawanpreet Lakha's avatar
      drm/amd/display: Handle GPU reset for DC block · cdaae837
      Bhawanpreet Lakha authored
      [Why]
      Previously we used the s3 codepath for gpu reset. This can lead to issues in
      certain case where we end of waiting for fences which will never come (because
      parts of the hw are off due to gpu reset) and we end up waiting forever causing
      a deadlock.
      
      [How]
      Handle GPU reset separately from normal s3 case. We essentially need to redo
      everything we do in s3, but avoid any drm calls.
      
      For GPU reset case
      
      suspend:
      	-Acquire DC lock
      	-Cache current dc_state
      	-Commit 0 stream/planes to dc (this puts dc into a state where it can be
      	 powered off)
      	-Disable interrupts
      resume
      	-Edit cached state to force full update
      	-Commit cached state from suspend
      	-Build stream and plane updates from the cached state
      	-Commit stream/plane updates
      	-Enable interrupts
      	-Release DC lock
      
      v2:
      -Formatting
      -Release dc_state
      Signed-off-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      cdaae837
    • Alex Deucher's avatar
      drm/amdgpu: add apu flags (v2) · 54f78a76
      Alex Deucher authored
      Add some APU flags to simplify handling of different APU
      variants.  It's easier to understand the special cases
      if we use names flags rather than checking device ids and
      silicon revisions.
      
      v2: rebase on latest code
      Acked-by: default avatarEvan Quan <evan.quan@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      54f78a76
    • chen gong's avatar
      drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and raven · cbd2d08c
      chen gong authored
      [Problem description]
      1. Boot up picasso platform, launches desktop, Don't do anything (APU enter into "gfxoff" state)
      2. Remote login to platform using SSH, then type the command line:
      	sudo su -c "echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level"
      	sudo su -c "echo 2 > /sys/class/drm/card0/device/pp_dpm_sclk" (fix SCLK to 1400MHz)
      3. Move the mouse around in Window
      4. Phenomenon :  The screen frozen
      
      Tester will switch sclk level during glmark2 run time.
      APU will enter "gfxoff" state intermittently during glmark2 run time.
      The system got hanged if fix GFXCLK to 1400MHz when APU is in "gfxoff"
      state.
      
      [Debug]
      1. Fix SCLK to X MHz
      	1400: screen frozen, screen black, then OS will reboot.
      	1300: screen frozen.
      	1200: screen frozen, screen black.
      	1100: screen frozen, screen black, then OS will reboot.
      	1000: screen frozen, screen black.
      	900:  screen frozen, screen black, then OS will reboot.
      	800:  Situation Nomal, issue disappear.
      	700:  Situation Nomal, issue disappear.
      2. SBIOS setting: AMD CBS --> SMU Debug Options -->SMU Debug --> "GFX DLDO Psm Margin Control":
      	50 : Situation Nomal, issue disappear.
      	45 : Situation Nomal, issue disappear.
      	40 : Situation Nomal, issue disappear.
      	35 : Situation Nomal, issue disappear.
      	30 : screen black.
      	25 : screen frozen, then blurred screen.
      	20 : screen frozen.
      	15 : screen black.
      	10 : screen frozen.
      	5  : screen frozen, then blurred screen.
      3. Disable GFXOFF feature
      	Situation Nomal, issue disappear.
      
      [Why]
      Through a period of time debugging with Sys Eng team and SMU team, Sys
      Eng team said this is voltage/frequency marginal issue not a F/W or H/W
      bug. This experiment proves that default targetPsm [for f=1400MHz] is
      not sufficient when GFXOFF is enabled on Picasso.
      
      SMU team think it is an odd test conditions to force sclk="1400MHz" when
      GPU is in "gfxoff" state,then wake up the GFX. SCLK should be in the
      "lowest frequency" when gfxoff.
      
      [How]
      Disable gfxoff when setting manual mode.
      Enable gfxoff when setting other mode(exiting manual mode) again.
      
      By the way, from the user point of view, now that user switch to manual
      mode and force SCLK Frequency, he don't want SCLK be controlled by
      workload.It becomes meaningless to "switch to manual mode" if APU enter "gfxoff"
      due to lack of workload at this point.
      
      Tips: Same issue observed on Raven.
      Signed-off-by: default avatarchen gong <curry.gong@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      cbd2d08c