1. 06 12月, 2019 1 次提交
  2. 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
  3. 26 10月, 2019 1 次提交
  4. 07 8月, 2019 2 次提交
  5. 31 7月, 2019 1 次提交
  6. 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
  7. 17 7月, 2019 1 次提交
  8. 06 7月, 2019 1 次提交
  9. 21 6月, 2019 3 次提交
  10. 11 6月, 2019 2 次提交
  11. 25 5月, 2019 1 次提交
  12. 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
  13. 20 2月, 2019 1 次提交
  14. 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
  15. 06 2月, 2019 1 次提交
  16. 26 1月, 2019 1 次提交
  17. 15 1月, 2019 2 次提交
  18. 04 1月, 2019 1 次提交
  19. 03 1月, 2019 1 次提交
  20. 11 12月, 2018 2 次提交
  21. 29 11月, 2018 1 次提交
  22. 20 11月, 2018 1 次提交
  23. 10 11月, 2018 3 次提交
  24. 06 11月, 2018 8 次提交