1. 03 Dec, 2018 6 commits
  2. 30 Nov, 2018 21 commits
  3. 29 Nov, 2018 2 commits
  4. 28 Nov, 2018 11 commits
    • Young Xiao's avatar
      drm: radeon: fix overflow on 32bit systems · b3f4bdda
      Young Xiao authored
      the type mem->start is unsigned long, so this can overflow on
      32bit system, since the type addr is uint64_t.
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarYoung Xiao <YangX92@hotmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      b3f4bdda
    • Colin Ian King's avatar
      drm/amd/pp: fix spelling mistake "dependancy" -> "dependency" · ce998149
      Colin Ian King authored
      There are spelling mistakes in PP_ASSERT_WITH_CODE messages, fix these.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ce998149
    • Chris Wilson's avatar
      drm/amdgpu: Reorder uvd ring init before uvd resume · 3b34c14f
      Chris Wilson authored
      As amd_uvd_resume() accesses the uvd ring, it must be initialised first
      or else we trigger errors like:
      
      [    5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
      [    5.595969] [drm] PSP loading UVD firmware
      [    5.596266] ------------[ cut here ]------------
      [    5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint:           (null)
      [    5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
      [    5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage
      [    5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G        W         4.20.0-0.rc1.git4.1.fc30.x86_64 #1
      [    5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018
      [    5.596303] RIP: 0010:debug_print_object+0x6a/0x80
      [    5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3
      [    5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282
      [    5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006
      [    5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60
      [    5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000
      [    5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69
      [    5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000
      [    5.596313] FS:  00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000
      [    5.596314] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0
      [    5.596317] Call Trace:
      [    5.596321]  debug_object_assert_init+0x14a/0x180
      [    5.596327]  del_timer+0x2e/0x90
      [    5.596383]  amdgpu_fence_process+0x47/0x100 [amdgpu]
      [    5.596430]  amdgpu_uvd_resume+0xf6/0x120 [amdgpu]
      [    5.596475]  uvd_v7_0_sw_init+0xe0/0x280 [amdgpu]
      [    5.596523]  amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu]
      [    5.596563]  ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu]
      [    5.596604]  amdgpu_driver_load_kms+0x86/0x330 [amdgpu]
      [    5.596614]  drm_dev_register+0x115/0x150 [drm]
      [    5.596654]  amdgpu_pci_probe+0xbd/0x120 [amdgpu]
      [    5.596658]  local_pci_probe+0x41/0x90
      [    5.596661]  pci_device_probe+0x188/0x1a0
      [    5.596666]  really_probe+0xf8/0x3b0
      [    5.596669]  driver_probe_device+0xb3/0xf0
      [    5.596672]  __driver_attach+0xe1/0x110
      [    5.596674]  ? driver_probe_device+0xf0/0xf0
      [    5.596676]  bus_for_each_dev+0x79/0xc0
      [    5.596679]  bus_add_driver+0x155/0x230
      [    5.596681]  ? 0xffffffffc07d9000
      [    5.596683]  driver_register+0x6b/0xb0
      [    5.596685]  ? 0xffffffffc07d9000
      [    5.596688]  do_one_initcall+0x5d/0x2be
      [    5.596691]  ? rcu_read_lock_sched_held+0x79/0x80
      [    5.596693]  ? kmem_cache_alloc_trace+0x264/0x290
      [    5.596695]  ? do_init_module+0x22/0x210
      [    5.596698]  do_init_module+0x5a/0x210
      [    5.596701]  load_module+0x2137/0x2430
      [    5.596703]  ? lockdep_hardirqs_on+0xed/0x180
      [    5.596714]  ? __do_sys_init_module+0x150/0x1a0
      [    5.596715]  __do_sys_init_module+0x150/0x1a0
      [    5.596722]  do_syscall_64+0x60/0x1f0
      [    5.596725]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [    5.596726] RIP: 0033:0x7f762b877dee
      [    5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48
      [    5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
      [    5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee
      [    5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060
      [    5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002
      [    5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060
      [    5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000
      [    5.596740] irq event stamp: 134618
      [    5.596743] hardirqs last  enabled at (134617): [<ffffffffa513d52e>] console_unlock+0x45e/0x610
      [    5.596744] hardirqs last disabled at (134618): [<ffffffffa50037e8>] trace_hardirqs_off_thunk+0x1a/0x1c
      [    5.596746] softirqs last  enabled at (133146): [<ffffffffa5e00365>] __do_softirq+0x365/0x47c
      [    5.596748] softirqs last disabled at (133139): [<ffffffffa50c64f9>] irq_exit+0x119/0x120
      [    5.596749] ---[ end trace eaee508abfebccdc ]---
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      3b34c14f
    • Andrey Grodzovsky's avatar
      drm/amdgpu: Refactor GPU reset for XGMI hive case · 26bc5340
      Andrey Grodzovsky authored
      For XGMI hive case do reset in steps where each step iterates over
      all devs in hive. This especially important for asic reset
      since all PSP FW in hive must come up within a limited time
      (around 1 sec) to properply negotiate the link.
      Do this by  refactoring  amdgpu_device_gpu_recover and amdgpu_device_reset
      into pre_asic_reset, asic_reset and post_asic_reset functions where is part
      is exectued for all the GPUs in the hive before going to the next step.
      
      v2: Update names for amdgpu_device_lock/unlock functions.
      
      v3: Introduce per hive locking to avoid multiple resets for GPUs
          in same hive.
      v4:
      Remove delayed_workqueue()/ttm_bo_unlock_delayed_workqueue() - they
      are copy & pasted over from radeon and on amdgpu there isn't
      any reason for that any more.
      Signed-off-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      26bc5340
    • Andrey Grodzovsky's avatar
      drm/amdgpu: Expose hive adev list and xgmi_mutex · ed2bf522
      Andrey Grodzovsky authored
      It's needed for device reset of entire hive.
      
      v3:
      Add per hive lock to allow avoiding duplicate resets triggered by
      multiple members  of same hive.
      Expose amdgpu_hive_info instead of adding getter functions.
      Signed-off-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ed2bf522
    • Andrey Grodzovsky's avatar
      drm/amdgpu: Refactor amdgpu_xgmi_add_device · 5183411b
      Andrey Grodzovsky authored
      This is prep work for updating each PSP FW in hive after
      GPU reset.
      Split into build topology SW state and update each PSP FW in the hive.
      Save topology and count of XGMI devices for reuse.
      
      v2: Create seperate header for XGMI.
      Signed-off-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      5183411b
    • Nicholas Kazlauskas's avatar
      drm/amdgpu: Set FreeSync state using drm VRR properties · bb47de73
      Nicholas Kazlauskas authored
      Support for AMDGPU specific FreeSync properties and ioctls are dropped
      from amdgpu_dm in favor of supporting drm variable refresh rate
      properties.
      
      The notify_freesync and set_freesync_property functions are dropped
      from amdgpu_display_funcs.
      
      The drm vrr_capable property is now attached to any DP/HDMI connector.
      Its value is updated accordingly to the connector's FreeSync capabiltiy.
      
      The freesync_enable logic and ioctl control has has been dropped in
      favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
      fine grained atomic control over which CRTCs should support variable
      refresh rate.
      
      To handle state changes for vrr_enabled it was easiest to drop the
      forced modeset on freesync_enabled change. This patch now performs the
      required stream updates when planes are flipped.
      
      This is done for a few reasons:
      
      (1) VRR stream updates can be done in the fast update path
      
      (2) amdgpu_dm_atomic_check would need to be hacked apart to check
          desired variable refresh state and capability before the CRTC
          disable pass.
      
      (3) Performing VRR stream updates on-flip is needed for enabling BTR
          support.
      
      VRR packets and timing adjustments are now tracked and compared to
      previous values sent to the hardware.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      bb47de73
    • Nicholas Kazlauskas's avatar
      drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal · 520f08df
      Nicholas Kazlauskas authored
      When variable refresh rate is active the hardware counter can return
      a position >= vtotal. This results in a vpos being returned from
      amdgpu_display_get_crtc_scanoutpos that's a positive value. The
      positive value indicates to the caller that the display is
      currently in scanout when the display is actually still in vblank.
      
      This is because the vfront porch duration is unknown with variable
      refresh active and will end when either a page flip occurs or the
      timeout specified by the driver/display is reached.
      
      The behavior of the amdgpu_display_get_crtc_scanoutpos remains the
      same when the position is below vtotal. When the position is above
      vtotal the function will return a value that is effectively -vbl_end,
      the size of the vback porch.
      
      The only caller affected by this change is the DRM helper for
      calculating vblank timestamps. This change corrects behavior for
      calculating the page flip timestamp from being the previous timestamp
      to the calculation to the next timestamp when position >= vtotal.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      520f08df
    • Nicholas Kazlauskas's avatar
      drm: Document variable refresh properties · ab7a664f
      Nicholas Kazlauskas authored
      These include the drm_connector 'vrr_capable' and the drm_crtc
      'vrr_enabled' properties.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Acked-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ab7a664f
    • Nicholas Kazlauskas's avatar
      drm: Add vrr_enabled property to drm CRTC · 1398958c
      Nicholas Kazlauskas authored
      This patch introduces the 'vrr_enabled' CRTC property to allow
      dynamic control over variable refresh rate support for a CRTC.
      
      This property should be treated like a content hint to the driver -
      if the hardware or driver is not capable of driving variable refresh
      timings then this is not considered an error.
      
      Capability for variable refresh rate support should be determined
      by querying the vrr_capable drm connector property.
      
      It is worth noting that while the property is intended for atomic use
      it isn't filtered from legacy userspace queries. This allows for Xorg
      userspace drivers to implement support.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      1398958c
    • Nicholas Kazlauskas's avatar
      drm: Add vrr_capable property to the drm connector · ba1b0f6c
      Nicholas Kazlauskas authored
      Modern display hardware is capable of supporting variable refresh rates.
      This patch introduces the "vrr_capable" property on the connector to
      allow userspace to query support for variable refresh rates.
      
      Atomic drivers should attach this property to connectors that are
      capable of driving variable refresh rates using
      drm_connector_attach_vrr_capable_property().
      
      The value should be updated based on driver and hardware capability
      by using drm_connector_set_vrr_capable_property().
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      ba1b0f6c