1. 23 4月, 2020 1 次提交
  2. 09 4月, 2020 1 次提交
    • N
      drm/amdgpu: rework sched_list generation · 1c6d567b
      Nirmoy Das 提交于
      Generate HW IP's sched_list in amdgpu_ring_init() instead of
      amdgpu_ctx.c. This makes amdgpu_ctx_init_compute_sched(),
      ring.has_high_prio and amdgpu_ctx_init_sched() unnecessary.
      This patch also stores sched_list for all HW IPs in one big
      array in struct amdgpu_device which makes amdgpu_ctx_init_entity()
      much more leaner.
      
      v2:
      fix a coding style issue
      do not use drm hw_ip const to populate amdgpu_ring_type enum
      
      v3:
      remove ctx reference and move sched array and num_sched to a struct
      use num_scheds to detect uninitialized scheduler list
      
      v4:
      use array_index_nospec for user space controlled variables
      fix possible checkpatch.pl warnings
      Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      1c6d567b
  3. 02 4月, 2020 2 次提交
  4. 10 3月, 2020 2 次提交
  5. 05 3月, 2020 1 次提交
  6. 29 2月, 2020 2 次提交
  7. 23 1月, 2020 1 次提交
  8. 17 1月, 2020 1 次提交
  9. 06 12月, 2019 2 次提交
  10. 04 12月, 2019 1 次提交
    • M
      drm/amdgpu: fix calltrace during kmd unload(v3) · 747d4f71
      Monk Liu 提交于
      issue:
      kernel would report a warning from a double unpin
      during the driver unloading on the CSB bo
      
      why:
      we unpin it during hw_fini, and there will be another
      unpin in sw_fini on CSB bo.
      
      fix:
      actually we don't need to pin/unpin it during
      hw_init/fini since it is created with kernel pinned,
      we only need to fullfill the CSB again during hw_init
      to prevent CSB/VRAM lost after S3
      
      v2:
      get_csb in init_rlc so hw_init() will make CSIB content
      back even after reset or s3
      
      v3:
      use bo_create_kernel instead of bo_create_reserved for CSB
      otherwise the bo_free_kernel() on CSB is not aligned and
      would lead to its internal reserve pending there forever
      
      take care of gfx7/8 as well
      Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
      Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
      Reviewed-by: NXiaojie Yuan <xiaojie.yuan@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      747d4f71
  11. 03 12月, 2019 1 次提交
    • M
      drm/amdgpu: fix calltrace during kmd unload(v3) · 82a829dc
      Monk Liu 提交于
      issue:
      kernel would report a warning from a double unpin
      during the driver unloading on the CSB bo
      
      why:
      we unpin it during hw_fini, and there will be another
      unpin in sw_fini on CSB bo.
      
      fix:
      actually we don't need to pin/unpin it during
      hw_init/fini since it is created with kernel pinned,
      we only need to fullfill the CSB again during hw_init
      to prevent CSB/VRAM lost after S3
      
      v2:
      get_csb in init_rlc so hw_init() will make CSIB content
      back even after reset or s3
      
      v3:
      use bo_create_kernel instead of bo_create_reserved for CSB
      otherwise the bo_free_kernel() on CSB is not aligned and
      would lead to its internal reserve pending there forever
      
      take care of gfx7/8 as well
      Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
      Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
      Reviewed-by: NXiaojie Yuan <xiaojie.yuan@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      82a829dc
  12. 14 11月, 2019 1 次提交
  13. 26 10月, 2019 1 次提交
  14. 07 8月, 2019 2 次提交
  15. 31 7月, 2019 1 次提交
  16. 19 7月, 2019 2 次提交
    • J
      drm/amdgpu: Default disable GDS for compute VMIDs · fbdc5d8d
      Joseph Greathouse 提交于
      The GDS and GWS blocks default to allowing all VMIDs to
      access all entries. Graphics VMIDs can handle setting
      these limits when the driver launches work. However,
      compute workloads under HWS control don't go through the
      kernel driver. Instead, HWS firmware should set these
      limits when a process is put into a VMID slot.
      
      Disable access to these devices by default by turning off
      all mask bits (for OA) and setting BASE=SIZE=0 (for GDS
      and GWS) for all compute VMIDs. If a process wants to use
      these resources, they can request this from the HWS
      firmware (when such capabilities are enabled). HWS will
      then handle setting the base and limit for the process when
      it is assigned to a VMID.
      
      This will also prevent user kernels from getting 'stuck' in
      GWS by accident if they write GWS-using code but HWS
      firmware is not set up to handle GWS reset. Until HWS is
      enabled to handle GWS properly, all GWS accesses will
      MEM_VIOL fault the kernel.
      
      v2: Move initialization outside of SRBM mutex
      Signed-off-by: NJoseph Greathouse <Joseph.Greathouse@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      fbdc5d8d
    • J
      drm/amdgpu: Default disable GDS for compute VMIDs · ad28e024
      Joseph Greathouse 提交于
      The GDS and GWS blocks default to allowing all VMIDs to
      access all entries. Graphics VMIDs can handle setting
      these limits when the driver launches work. However,
      compute workloads under HWS control don't go through the
      kernel driver. Instead, HWS firmware should set these
      limits when a process is put into a VMID slot.
      
      Disable access to these devices by default by turning off
      all mask bits (for OA) and setting BASE=SIZE=0 (for GDS
      and GWS) for all compute VMIDs. If a process wants to use
      these resources, they can request this from the HWS
      firmware (when such capabilities are enabled). HWS will
      then handle setting the base and limit for the process when
      it is assigned to a VMID.
      
      This will also prevent user kernels from getting 'stuck' in
      GWS by accident if they write GWS-using code but HWS
      firmware is not set up to handle GWS reset. Until HWS is
      enabled to handle GWS properly, all GWS accesses will
      MEM_VIOL fault the kernel.
      
      v2: Move initialization outside of SRBM mutex
      Signed-off-by: NJoseph Greathouse <Joseph.Greathouse@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      ad28e024
  17. 17 7月, 2019 1 次提交
  18. 06 7月, 2019 1 次提交
  19. 21 6月, 2019 3 次提交
  20. 11 6月, 2019 2 次提交
  21. 25 5月, 2019 1 次提交
  22. 20 3月, 2019 1 次提交
    • G
      drm/amdgpu/gfx_v8_0: Mark expected switch fall-through · a7dc289b
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function ‘gfx_v8_0_tiling_mode_table_init’:
      ./include/linux/device.h:1487:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
        _dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3236:3: note: in expansion of macro ‘dev_warn’
         dev_warn(adev->dev,
         ^~~~~~~~
      drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3240:2: note: here
        case CHIP_CARRIZO:
        ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      This patch is part of the ongoing efforts to enable
      -Wimplicit-fallthrough.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      a7dc289b
  23. 20 2月, 2019 1 次提交
  24. 14 2月, 2019 1 次提交
    • Y
      drm/amdgpu: Fix bugs in setting CP RB/MEC DOORBELL_RANGE registers · 74b9b3ea
      Yong Zhao 提交于
      CP_RB_DOORBELL_RANGE_LOWER/UPPER and CP_MEC_DOORBELL_RANGE_LOWER/UPPER
      are used for waking up an idle scheduler and for power gating support.
      Usually the first few doorbells in pci doorbell bar are used for RB
      and all leftover for MEC. This patch fixes the incorrect settings.
      
      Theoretically, gfx ring doorbells should come before all MEC doorbells
      to be consistent with the design. However, since the doorbell
      allocations are agreed by all and we are not free to change them, also
      considering the kernel MEC ring doorbells which are before gfx ring
      doorbells are not used often, we compromise by leaving the doorbell
      allocations unchanged.
      Signed-off-by: NYong Zhao <Yong.Zhao@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      74b9b3ea
  25. 06 2月, 2019 1 次提交
  26. 26 1月, 2019 1 次提交
  27. 15 1月, 2019 2 次提交
  28. 04 1月, 2019 1 次提交
  29. 03 1月, 2019 1 次提交
  30. 11 12月, 2018 1 次提交