> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Monk Liu
> Sent: Wednesday, September 20, 2017 5:28 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chen, Horace; Liu, Monk
> Subject: [PATCH] drm/amdgpu/sriov:fix driver unloading bug
>
> Fix h
> -Original Message-
> From: Thomas Meyer [mailto:tho...@m3y3r.de]
> Sent: Thursday, September 21, 2017 2:34 AM
> To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATC
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Wednesday, September 20, 2017 10:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amd/powerplay: refine
> phm_register_thermal_interrupt interfac
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Li, Samuel
> Sent: Wednesday, September 20, 2017 11:44 AM
> To: Koenig, Christian; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH v2 1/1] drm/amdgpu: Add gem_prime_mmap support
>
> > Wha
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Wednesday, September 20, 2017 7:44 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 00/18] refine smumgr code in powerplay
>
> the smumgr layer is redun
On 09/21/2017 10:56 AM, Evan Quan wrote:
Change-Id: I28e9ca38b68234d0325a5b8a01d135649939c0af
Signed-off-by: Evan Quan
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgp
SRIOV doesn't implement PMC capability of PCIe, so it can't update
power state by reading PMC register.
Currently, amdgpu driver doesn't disable pci device when removing
driver, the enable_cnt of pci device will not be decrease to 0.
When reloading driver, pci_enable_device will do nothing as
enab
currently, not all asics implement this callback function
so not return error to avoid powerplay initialize failed
in those asices
Change-Id: I492b7ab54eebcc0d84c169edc0d5876c4529c619
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 6 +++---
1 file changed, 3 i
Change-Id: I28e9ca38b68234d0325a5b8a01d135649939c0af
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 99147f5..621699
When uninitializing a kernel queue.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
b/drivers/gpu
From: Yong Zhao
There are already CHIP_* definitions under amd_shared.h file on amdgpu
side, so KFD should reuse them rather than defining new ones.
Using enum for asic type requires default cases on switch statements
to prevent compiler warnings. WARN on unsupported ASICs. It should never
get t
Small self-contained KFD fixes that don't introduce any new
functionality or features. These may be suitable to include in
drm-fixes for 4.14.
v2:
- Rebased on gabbayo/amdkfd-next
- Addressed code review feedback
- Dropped "Set /dev/kfd permissions to 0666 by default"
Felix Kuehling (3):
drm/am
From: Yong Zhao
The idea is to let kfd init and resume function share the same code path
as much as possible, rather than to have two copies of almost identical
code. That way improves the code readability and maintainability.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Reviewed-by:
To avoid spamming the log.
Signed-off-by: Felix Kuehling
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 5 -
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
b/driver
From: Yong Zhao
When we do suspend/resume through "sudo pm-suspend" while there is
HSA activity running, upon resume we will encounter HWS hanging, which
is caused by memory read/write failures. The root cause is that when
suspend, we neglected to unbind pasid from kfd device.
Another major chan
From: Yong Zhao
Several functions in DQM are shared between cpsch and nocpsch code.
Remove the misleading _nocpsch suffix from their names.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Reviewed-by: Oded Gabbay
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 24 +++-
From: Yong Zhao
The hard-coded values related to VMID were removed in KFD, as those
values can be calculated in the KFD initialization function.
v2: remove unnecessary local variable
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Reviewed-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdk
From: Yong Zhao
Avoid intermediate negative numbers when doing calculations with a mix
of signed and unsigned variables where implicit conversions can lead
to unexpected results.
When kernel queue buffer wraps around to 0, we need to check that rptr
won't be overwritten by the new packet.
Signe
From: Yong Zhao
The timeout in milliseconds should not be regarded as jiffies. This
commit fixed that.
v2:
- use msecs_to_jiffies
- change timeout_ms parameter to unsigned int to match msecs_to_jiffies
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_
Adjust latencies and timeouts for dequeueing with HWS and consolidate
them in one place. Make them longer to allow long running waves to
complete without causing a timeout. The timeout is twice as long as the
latency plus some buffer to make sure we don't detect a timeout
prematurely.
Change timeo
> The waiting done here is only for the shared fence to switch from explicitly
> to
> implicitly synchronization for correct interaction with the Intel driver.
Actually here it is going to wait for all fences,
94 ret = reservation_object_wait_timeout_rcu(bo->tbo.resv, true...
> ttm_bo_val
Am 20.09.2017 um 19:47 schrieb Li, Samuel:
No that isn't correct. Pinning just notes that the BO shouldn't be moved any
more. It doesn't wait for anything.
It does. The following is from amdgpu_gem_prime_pin(),
91 * Wait for all shared fences to complete before we switch to future
92
> No that isn't correct. Pinning just notes that the BO shouldn't be moved any
> more. It doesn't wait for anything.
It does. The following is from amdgpu_gem_prime_pin(),
91 * Wait for all shared fences to complete before we switch to future
92 * use of exclusive fence on this
Am 20.09.2017 um 19:34 schrieb Li, Samuel:
If that is what this callback should do then this implementation would be
incorrect. Pinning doesn't wait for any GPU operation to finish.
During pining, it will all the fences to finish. That shall be OK.
No that isn't correct. Pinning just notes tha
Since newer asics have IP blocks with the same register we must specify both.
Signed-off-by: Tom St Denis
---
doc/umr.1| 2 +-
src/app/main.c | 3 ++-
src/app/umr_lookup.c | 33 -
3 files changed, 27 insertions(+), 11 deletions(-)
diff --git a
> If that is what this callback should do then this implementation would be
> incorrect. Pinning doesn't wait for any GPU operation to finish.
During pining, it will all the fences to finish. That shall be OK.
Sam
> -Original Message-
> From: Koenig, Christian
> Sent: Wednesday, Septem
Am 20.09.2017 um 17:44 schrieb Li, Samuel:
What happens when another thread is using amdgpu_dmabuf_ops to call
begin_cpu_access/end_cpu_access when you are fixing it up again?
Right, that is an issue.
A simple "if (!amdgpu_dmabuf_ops.begin_cpu_access)" should be able to
deal with that.
I
> What happens when another thread is using amdgpu_dmabuf_ops to call
> begin_cpu_access/end_cpu_access when you are fixing it up again?
Right, that is an issue.
> I would just completely drop the two callbacks, pinning is not necessary for
> CPU access and thinking more about it it actually has s
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/lib/chash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/lib/chash.c b/drivers/gpu/drm/amd/lib/chash.c
index e07e6f3..b8e45f3 100644
--- a/drivers/gpu/drm/amd/lib/chash.c
+++ b/drivers/gpu/drm/amd
the PHM_WAIT_VFPF_INDIRECT_FIELD
is irrelated to SMU, so move to hwmgr.h
and rename to PHM_WAIT_VFPF_INDIRECT_FIELD
Signed-off-by: Rex Zhu
Change-Id: I477150e82cf6b1401dedbe1976c58a304713f767
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 14 ++
drivers/gpu/drm/amd/po
repeated defining in hwmgr.h
Change-Id: Id4fdbdb7df727516d9bdb2ca6c621b97b5ce509f
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 5 -
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 2 +-
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
rename SMU_WAIT_FIELD_UNEQUAL to
PHM_WAIT_FIELD_UNEQUAL and move to hwmgr.h
Change-Id: I21c66d3bf3108a61292bae4e7a2546c6d4f9a628
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 14 ++
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 14
repeated defining in hwmgr.h
Signed-off-by: Rex Zhu
Change-Id: I1fb2f768f17cf1e9fc5c03d5bb03b8b6d99281cd
---
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
b/drivers/gpu/dr
Change-Id: I722ecb827144adf42b149e41595580ca8d4385ae
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 31 --
drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 87 ---
2 files changed, 118 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerp
repeated defining in hwmgr.h
Signed-off-by: Rex Zhu
Change-Id: I870d69fe778204300f46db93ad6ae6811e12af86
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 2 --
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c| 2 +-
drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 2 +-
dri
repeated defining in hwmgr.h
use PHM_WAIT_INDIRECT_FIELD instand.
Change-Id: I4c06638c4fb2af2bae18a0c0f4f825b555f2bea3
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 11 ---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 2 +-
drivers/gpu/drm
repeated defining in hwmgr.h
Signed-off-by: Rex Zhu
Change-Id: I62316f35417784c4cf30a75e148bd1895a184a5b
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 5 -
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 12 ++--
2 files changed, 6 insertions(+), 11 deletions(-)
diff -
repeated defining in hwmgr.h
Change-Id: I03b1adfb164d43e9f33e6442f666c013f2e98a05
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 6 --
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 14 +++---
.../gpu/drm/amd/powerplay/smumgr/polaris10_
the macro is as same as PHM_WRITE_INDIRECT_FIELD
Change-Id: I62389ad2d699530e3a7d6a81f7427c21fd88b7be
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 15 ---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 4 ++--
drivers/gpu/drm/amd/powerp
Am 20.09.2017 um 13:42 schrieb Tom St Denis:
We discovered that on some devices even with iommu enabled
you can access all of system memory through the iommu translation.
Therefore, we revert the read method to the translation only service
and drop the write method completely.
Signed-off-by: To
the macro is as same as PHM_WRITE_FIELD
Signed-off-by: Rex Zhu
Change-Id: I678e6277b6d582ab6a651a5fba07989634bf1aee
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 3 ---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 6 +++---
drivers/gpu/drm/amd/powerplay/smumgr/iceland_s
the SMUM_WAIT_INDIRECT_FIELD_UNEQUAL
is irrelated to SMU, so move to hwmgr.h
and rename to PHM_WAIT_INDIRECT_FIELD_UNEQUAL
Signed-off-by: Rex Zhu
Change-Id: Ieeb89b022edc9f3897c39641dd00e7409aa0faf9
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 13 +
drivers/gpu/drm/am
the SMUM_WAIT_VFPF_INDIRECT_FIELD_UNEQUAL
is irrelated to SMU, so move to hwmgr.h
and rename to
PHM_WAIT_VFPF_INDIRECT_FIELD_UNEQUAL
Signed-off-by: Rex Zhu
Change-Id: I2036309e8dd4cc3b211ae06a3d0ddfd9f16a92e7
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 13 +
driver
Change-Id: I81163535116224db66b20d0afe33909aa1d4bf11
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h| 4 ++--
drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smumgr.h
Change-Id: I37f87d31c8467b1c8b9a2bfa5e40083634f19fdb
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 42 --
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 10 --
drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c | 2 +-
drivers/gpu/d
Change-Id: I82f9d6e6d59609d47124e868c53e1cc7717c45d1
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index f4b6f0e..dc37dd9 1
Am 20.09.2017 um 11:31 schrieb Monk Liu:
fix missing finish uvd enc_ring.
v2:
since the adev pointer check in already in ring_fini
so drop the check outsider
Change-Id: Ib74237ca5adcb3b128c9b751fced0b7db7b09e86
Signed-off-by: Monk Liu
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/
the smumgr layer is redundant in powerplay.
so delete struct smumgr, move smu callback functions and
backend data to hwmgr.
the macros SMUM_* in smumgr.h is functionally repeated
with macros PHM_* in hwmgr.h, and the macros is irrelated
to smu. so delete the macros in smumgr.h
Rex Zhu (18):
drm/
(v3): Use original version of iova file but add support for
non-iommu hosts.
Signed-off-by: Tom St Denis
---
src/lib/CMakeLists.txt | 1 -
src/lib/close_asic.c | 2 +-
src/lib/discover.c | 3 +
src/lib/free_maps.c| 44 -
src/lib/read_vram.c| 169 ++---
This reverts commit 0e1c378fce66db833e08770d888dda1c5ec7936a.
---
src/lib/CMakeLists.txt | 1 +
src/lib/close_asic.c | 2 +-
src/lib/discover.c | 3 -
src/lib/free_maps.c| 44 ++
src/lib/read_vram.c| 218 -
src/umr.h
We discovered that on some devices even with iommu enabled
you can access all of system memory through the iommu translation.
Therefore, we revert the read method to the translation only service
and drop the write method completely.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amd
On 20/09/17 03:07 AM, Christian König wrote:
Am 19.09.2017 um 23:38 schrieb Tom St Denis:
On 19/09/17 02:33 PM, Christian König wrote:
[root@carrizo ~]# xxd -l 1024 -s 0xC
/sys/kernel/debug/dri/0/amdgpu_iova
Actually 0xC is a special address, e.g. video BIOS if I'm not
completely mis
this fix memory leak due to request_firmware after driver
unloaded
Change-Id: I7b4724deea0a095189c344eea3801e456e9cced0
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 6 ++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 20
drivers/gpu/drm/amd/amdgpu/s
fix missing finish uvd enc_ring.
v2:
since the adev pointer check in already in ring_fini
so drop the check outsider
Change-Id: Ib74237ca5adcb3b128c9b751fced0b7db7b09e86
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4
1 file changed, 4 insertions(+)
diff --git a/dr
Fix hypervisor save_vf fail issue which hit after guest drv unloaded.
the reason of SAVE_VF will fail is:
KIQ and KCQ still active after drv unloaded, RLCV will command CPC
to run MQD (to save current status) on all queues if they are still active
the fix is to unmap KCQ and disable KIQ/HIQ in gf
Am 19.09.2017 um 22:23 schrieb Felix Kuehling:
Signed-off-by: Felix Kuehling
Acked-by: Christian König for both.
---
drivers/gpu/drm/amd/lib/chash.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/lib/chash.c b/drive
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Eric Huang
> Sent: Tuesday, September 19, 2017 2:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: [PATCH 0/4] some changes for thermal interrupts
>
> Eric Huang (4
On 09/20/2017 02:22 PM, Evan Quan wrote:
Change-Id: I96cd1d463a5743f918a03cad5160ea0bbd908ad0
Signed-off-by: Evan Quan
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v
Am 19.09.2017 um 23:38 schrieb Tom St Denis:
On 19/09/17 02:33 PM, Christian König wrote:
[root@carrizo ~]# xxd -l 1024 -s 0xC
/sys/kernel/debug/dri/0/amdgpu_iova
Actually 0xC is a special address, e.g. video BIOS if I'm not
completely mistaken.
Not sure why that would be mapped by
59 matches
Mail list logo