1. 21 4月, 2021 8 次提交
  2. 16 4月, 2021 1 次提交
  3. 10 4月, 2021 5 次提交
    • A
      drm/amdkfd: Avoid null pointer in SMI event · 158fc08d
      Amber Lin 提交于
      Power Management IP is initialized/enabled before KFD init. When a
      thermal throttling happens before kfd_smi_init is done, calling the KFD
      SMI update function causes a stack dump by referring a NULL pointer (
      smi_clients list). Check if kfd_init is completed before calling the
      function.
      Signed-off-by: NAmber Lin <Amber.Lin@amd.com>
      Reviewed-by: NMukul Joshi <mukul.joshi@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      158fc08d
    • B
      drm/amd: use kmalloc_array over kmalloc with multiply · ccc43430
      Bernard Zhao 提交于
      Fix patch check warning:
      WARNING: Prefer kmalloc_array over kmalloc with multiply
      +	buf = kmalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);
      Signed-off-by: NBernard Zhao <bernard@vivo.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      ccc43430
    • Q
      drm/amdkfd: dqm fence memory corruption · b010affe
      Qu Huang 提交于
      Amdgpu driver uses 4-byte data type as DQM fence memory,
      and transmits GPU address of fence memory to microcode
      through query status PM4 message. However, query status
      PM4 message definition and microcode processing are all
      processed according to 8 bytes. Fence memory only allocates
      4 bytes of memory, but microcode does write 8 bytes of memory,
      so there is a memory corruption.
      
      Changes since v1:
        * Change dqm->fence_addr as a u64 pointer to fix this issue,
      also fix up query_status and amdkfd_fence_wait_timeout function
      uses 64 bit fence value to make them consistent.
      Signed-off-by: NQu Huang <jinsdb@126.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      b010affe
    • Q
      drm/amdkfd: Fix cat debugfs hang_hws file causes system crash bug · d7361021
      Qu Huang 提交于
      Here is the system crash log:
      [ 1272.884438] BUG: unable to handle kernel NULL pointer dereference at
      (null)
      [ 1272.884444] IP: [<          (null)>]           (null)
      [ 1272.884447] PGD 825b09067 PUD 8267c8067 PMD 0
      [ 1272.884452] Oops: 0010 [#1] SMP
      [ 1272.884509] CPU: 13 PID: 3485 Comm: cat Kdump: loaded Tainted: G
      [ 1272.884515] task: ffff9a38dbd4d140 ti: ffff9a37cd3b8000 task.ti:
      ffff9a37cd3b8000
      [ 1272.884517] RIP: 0010:[<0000000000000000>]  [<          (null)>]
      (null)
      [ 1272.884520] RSP: 0018:ffff9a37cd3bbe68  EFLAGS: 00010203
      [ 1272.884522] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
      0000000000014d5f
      [ 1272.884524] RDX: fffffffffffffff4 RSI: 0000000000000001 RDI:
      ffff9a38aca4d200
      [ 1272.884526] RBP: ffff9a37cd3bbed0 R08: ffff9a38dcd5f1a0 R09:
      ffff9a31ffc07300
      [ 1272.884527] R10: ffff9a31ffc07300 R11: ffffffffaddd5e9d R12:
      ffff9a38b4e0fb00
      [ 1272.884529] R13: 0000000000000001 R14: ffff9a37cd3bbf18 R15:
      ffff9a38aca4d200
      [ 1272.884532] FS:  00007feccaa67740(0000) GS:ffff9a38dcd40000(0000)
      knlGS:0000000000000000
      [ 1272.884534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 1272.884536] CR2: 0000000000000000 CR3: 00000008267c0000 CR4:
      00000000003407e0
      [ 1272.884537] Call Trace:
      [ 1272.884544]  [<ffffffffade68940>] ? seq_read+0x130/0x440
      [ 1272.884548]  [<ffffffffade40f8f>] vfs_read+0x9f/0x170
      [ 1272.884552]  [<ffffffffade41e4f>] SyS_read+0x7f/0xf0
      [ 1272.884557]  [<ffffffffae374ddb>] system_call_fastpath+0x22/0x27
      [ 1272.884558] Code:  Bad RIP value.
      [ 1272.884562] RIP  [<          (null)>]           (null)
      [ 1272.884564]  RSP <ffff9a37cd3bbe68>
      [ 1272.884566] CR2: 0000000000000000
      Signed-off-by: NQu Huang <jinsdb@126.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      d7361021
    • A
      drm/amdgpu: replace per_device_list by array · 6ae27841
      Alex Sierra 提交于
      Remove per_device_list from kfd_process and replace it with a
      kfd_process_device pointers array of MAX_GPU_INSTANCES size. This helps
      to manage the kfd_process_devices binded to a specific kfd_process.
      Also, functions used by kfd_chardev to iterate over the list were
      removed, since they are not valid anymore. Instead, it was replaced by a
      local loop iterating the array.
      Signed-off-by: NAlex Sierra <alex.sierra@amd.com>
      Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: NJonathan Kim <jonathan.kim@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6ae27841
  4. 01 4月, 2021 1 次提交
  5. 24 3月, 2021 7 次提交
  6. 10 3月, 2021 2 次提交
  7. 06 3月, 2021 2 次提交
  8. 23 2月, 2021 2 次提交
  9. 19 2月, 2021 1 次提交
  10. 10 2月, 2021 1 次提交
    • K
      drm/amdkfd: Get unique_id dynamically v2 · 11964258
      Kent Russell 提交于
      Instead of caching the value during amdgpu_device_init, just call the
      function directly. This avoids issues where the unique_id hasn't been
      saved by the time that KFD's topology snapshot is done (e.g. Arcturus).
      
      KFD's topology information from the amdgpu_device was initially cached
      at KFD initialization due to amdkfd and amdgpu being separate modules.
      Now that they are combined together, we can directly call the functions
      that we need and avoid this unnecessary duplication and complexity.
      
      As a side-effect of this change, we also remove unique_id=0 for CPUs,
      which is obviously not unique.
      
      v2: Drop previous patch printing unique_id in hex
      Signed-off-by: NKent Russell <kent.russell@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      11964258
  11. 21 1月, 2021 1 次提交
  12. 14 1月, 2021 2 次提交
  13. 09 1月, 2021 1 次提交
  14. 24 12月, 2020 1 次提交
  15. 18 12月, 2020 1 次提交
  16. 16 12月, 2020 1 次提交
  17. 11 12月, 2020 1 次提交
  18. 09 12月, 2020 2 次提交