Reviewed-by: Likun Gao
-Original Message-
From: Evan Quan
Sent: Tuesday, January 08, 2019 12:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Gao, Likun ; Feng, Kenneth ; Quan,
Evan
Subject: [PATCH] drm/amd/powerplay: drop the unnecessary uclk hard min setting
Since soft min setting is
Acked-by: Alex Deucher
On Mon, Jan 7, 2019 at 11:28 PM Evan Quan wrote:
>
> Since soft min setting is enough. Hard min setting is redundant.
>
> Change-Id: I758386085f227bad94148ec0b38776312b6f5b25
> Reported-by: Likun Gao
> Signed-off-by: Evan Quan
> ---
>
Since soft min setting is enough. Hard min setting is redundant.
Change-Id: I758386085f227bad94148ec0b38776312b6f5b25
Reported-by: Likun Gao
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
Looks good to me, Reviewed-by: Chunming Zhou
> -Original Message-
> From: amd-gfx On Behalf Of
> Marek Ol?ák
> Sent: Tuesday, January 08, 2019 3:31 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH libdrm] amdgpu: add a faster BO list API
>
> From: Marek Olšák
>
> ---
>
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
otherwise it could be exploited to reveal sensitive data.
This fix is not done in a common code path
Reviewed-by: Alex Deucher
On Mon, Jan 7, 2019 at 9:36 PM Evan Quan wrote:
>
> Make sure the clock level enforced is within the allowed
> ranges.
>
> Change-Id: If69a8512121c0c94818ab698595502e17569d4c7
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 14
Make sure the clock level enforced is within the allowed
ranges.
Change-Id: If69a8512121c0c94818ab698595502e17569d4c7
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
On 2019-01-07 9:21 a.m., Christian König wrote:
> Am 14.12.18 um 22:10 schrieb Yang, Philip:
>> Use HMM helper function hmm_vma_fault() to get physical pages backing
>> userptr and start CPU page table update track of those pages. Then use
>> hmm_vma_range_done() to check if those pages are
drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something
This is an ugly one unfortunately. Currently, all DRM drivers supporting
atomic modesetting will save the state that userspace had set before
suspending, then attempt to restore that state on resume. This probably
worked very well at one point, like many other things, until DP MST came
into the
Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
compiler warnings for drivers ignoring the return code of
drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix
this again in the future for someone else's driver.
Cc: Jerry Zuo
Lyude Paul (3):
drm/amdgpu:
Since I've had to fix two cases of drivers not checking the return code
from this function, let's make the compiler complain so this doesn't
come up again in the future.
Signed-off-by: Lyude Paul
Cc: Jerry Zuo
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
ifdef x86_64 specific code.
Allow enabling CONFIG_HSA_AMD on ARM64.
v2: Fixed a compiler warning due to an unused variable
CC: Mark Nutter
Signed-off-by: Felix Kuehling
Acked-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdkfd/Kconfig| 4 ++--
Reviewed-by: Andrey Grodzovsky
Andrey
On 01/07/2019 12:31 PM, StDenis, Tom wrote:
> v2: Move locks around in other functions so that this
> function can stand on its own. Also only hold the hive
> specific lock for add/remove device instead of the driver
> global lock so you can't add/remove
On 2019-01-04 7:35 a.m., Russell, Kent wrote:
> Add a sysfs file that reports the number of bytes transmitted and
> received in the last second. This can be used to approximate the PCIe
> bandwidth usage over the last second.
>
> Change-Id: I6c82fe1cb17726825736512990fa64f5c1489861
>
On 01/07/2019 09:13 AM, Christian König wrote:
> Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
>>
>> On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
>>> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
> On 12/21/2018 01:37 PM,
From: Marek Olšák
---
amdgpu/amdgpu-symbol-check | 3 ++
amdgpu/amdgpu.h| 56 +-
amdgpu/amdgpu_bo.c | 36
amdgpu/amdgpu_cs.c | 25 +
4 files changed, 119 insertions(+), 1 deletion(-)
diff
On Mon, Jan 7, 2019 at 6:53 AM Russell, Kent wrote:
>
> Did you mean on APU+dGPU, or just straight APU? The file currently returns 0s
> on my Carrizo. The event values are the same on CZ as they are for the dGPU
> ASICs, so it might just be that it's not supported since it's not going
>
I see 'no active waves' print meaning it's not shader hang.
We can try and estimate around which commands the hang occurred - in
addition to what you already print please also dump
sudo umr -O many,bits -r *.*.mmGRBM_STATUS* && sudo umr -O many,bits
-r *.*.mmCP_EOP_* && sudo umr -O many,bits
On 1/7/19 10:53 AM, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
> To reduce indent in dm_update_crtcs, and to make it operate on single
> instances.
>
> [How]
> Move iteration of plane states into atomic_check.
> No functional change is intended.
>
> Signed-off-by: Leo Li
Series is:
v2: Move locks around in other functions so that this
function can stand on its own. Also only hold the hive
specific lock for add/remove device instead of the driver
global lock so you can't add/remove devices in parallel from
one hive.
v3: add reset_lock
Signed-off-by: Tom St Denis
---
On 01/07/2019 12:03 PM, StDenis, Tom wrote:
> On 2019-01-07 12:00 p.m., Grodzovsky, Andrey wrote:
>>
>> On 01/07/2019 11:53 AM, StDenis, Tom wrote:
>>> On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
On 01/07/2019 11:36 AM, StDenis, Tom wrote:
> On 2019-01-07 11:33 a.m., Grodzovsky,
On 2019-01-07 12:00 p.m., Grodzovsky, Andrey wrote:
>
>
> On 01/07/2019 11:53 AM, StDenis, Tom wrote:
>> On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
>>>
>>> On 01/07/2019 11:36 AM, StDenis, Tom wrote:
On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
> On 01/07/2019 11:16 AM,
On 01/07/2019 11:53 AM, StDenis, Tom wrote:
> On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
>>
>> On 01/07/2019 11:36 AM, StDenis, Tom wrote:
>>> On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
> I think it's reasonable to use the
On 2019-01-07 11:51 a.m., Grodzovsky, Andrey wrote:
>
>
> On 01/07/2019 11:36 AM, StDenis, Tom wrote:
>> On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
>>>
>>> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
I think it's reasonable to use the hive specific lock for hive specific
On 01/07/2019 11:36 AM, StDenis, Tom wrote:
> On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
>>
>> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
>>> I think it's reasonable to use the hive specific lock for hive specific
>>> functions.
>>> The changes is acked-by Shaoyun.liu <
On 2019-01-07 11:33 a.m., Grodzovsky, Andrey wrote:
>
>
> On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
>> I think it's reasonable to use the hive specific lock for hive specific
>> functions.
>> The changes is acked-by Shaoyun.liu < shaoyun@amd.com>
>>
>> -Original Message-
>>
On 01/07/2019 11:16 AM, Liu, Shaoyun wrote:
> I think it's reasonable to use the hive specific lock for hive specific
> functions.
> The changes is acked-by Shaoyun.liu < shaoyun@amd.com>
>
> -Original Message-
> From: amd-gfx On Behalf Of StDenis,
> Tom
> Sent: Monday, January
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Liu, Shaoyun
Sent: Monday, January 7, 2019 11:01:51 AM
To: amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Add message print when unable to get valid hive
Ping ...
-Original Message-
I think it's reasonable to use the hive specific lock for hive specific
functions.
The changes is acked-by Shaoyun.liu < shaoyun@amd.com>
-Original Message-
From: amd-gfx On Behalf Of StDenis, Tom
Sent: Monday, January 7, 2019 10:16 AM
To: amd-gfx@lists.freedesktop.org
Cc:
Ping ...
-Original Message-
From: Liu, Shaoyun
Sent: Friday, January 4, 2019 1:29 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu: Add message print when unable to get valid hive
Add message print out and return -EINVAL when driver can not get valid
From: Leo Li
[Why]
To reduce indentation of dm_update_planes, and to make it operate on
single plane instances.
[How]
Move iteration of plane states into atomic_check.
No functional change is intended.
Signed-off-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 220
From: Leo Li
[Why]
To reduce indent in dm_update_crtcs, and to make it operate on single
instances.
[How]
Move iteration of plane states into atomic_check.
No functional change is intended.
Signed-off-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 341
On 2019-01-07 4:21 p.m., Mikhail Gavrilov wrote:
> On Mon, 7 Jan 2019 at 15:09, Michel Dänzer wrote:
>>
>> Is this reproducible with commit 674e78acae0d ("drm/amd/display: Add
>> fast path for cursor plane updates") + the patch above?
>
> Yes. I am sure I am able reproduce issue:
> All new dmesg
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Monday, January 7, 2019 7:05:56 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; Quan, Evan; Freehill, Chris
Subject: [PATCH 2/2] drm/amd/powerplay: create
v2: Move locks around in other functions so that this
function can stand on its own. Also only hold the hive
specific lock for add/remove device instead of the driver
global lock so you can't add/remove devices in parallel from
one hive.
Signed-off-by: Tom St Denis
---
Fix spelling mistake: "lenght" -> "length"
Signed-off-by: Matteo Croce
---
drivers/gpu/drm/amd/include/atombios.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/atombios.h
b/drivers/gpu/drm/amd/include/atombios.h
index 7931502fa54f..8ba21747b40a
Am 07.01.19 um 16:03 schrieb Michel Dänzer:
On 2019-01-07 2:45 p.m., Christian König wrote:
We hit a problem with IOMMU with that. Disable until we have time to
debug further.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ---
1 file changed, 3 deletions(-)
On 2019-01-07 2:45 p.m., Christian König wrote:
> We hit a problem with IOMMU with that. Disable until we have time to
> debug further.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git
Self NAK this ... calling functions take the same lock
We should remove the locks from the callers so this function is thread
safe on its own...
Tom
On 2019-01-07 10:00 a.m., StDenis, Tom wrote:
> Signed-off-by: Tom St Denis
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 8a8bc60cb6b4..587a5f73ae8c 100644
---
Am 14.12.18 um 22:10 schrieb Yang, Philip:
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
On 12/21/2018 01:37 PM, Christian König wrote:
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
We hit a problem with IOMMU with that. Disable until we have time to
debug further.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Since pp_od_clk_voltage device file is for OD related sysfs operations.
Change-Id: I13e95b4bd2ffb93b1cd5d272dd27171ab38dbe57
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git
For those ASICs with no overdrive capabilities, the OD support flag
will be reset.
Change-Id: I8b75ad27ec0035b80de555840ba496bc273fee08
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Did you mean on APU+dGPU, or just straight APU? The file currently returns 0s
on my Carrizo. The event values are the same on CZ as they are for the dGPU
ASICs, so it might just be that it's not supported since it's not going through
the physical PCIe bus on the board. I have tested it on
On 2019-01-06 11:26 p.m., Mikhail Gavrilov wrote:
> On Sat, 5 Jan 2019 at 01:13, Mikhail Gavrilov
> wrote:
>>
>> On Fri, 4 Jan 2019 at 23:02, Michel Dänzer wrote:
>>>
>>> On 2019-01-04 4:24 p.m., Alex Deucher wrote:
On Fri, Jan 4, 2019 at 9:52 AM Mikhail Gavrilov
wrote:
>
> Hi
On 2019-01-07 5:00 a.m., Yu Zhao wrote:
> On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
>> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses default 64 when cpp is
>>>
On Thu, Jan 03, 2019 at 05:33:19PM +0100, Michel Dänzer wrote:
> On 2018-12-30 2:00 a.m., Yu Zhao wrote:
> > Userspace may request pitch alignment that is not supported by GPU.
> > Some requests 32, but GPU ignores it and uses default 64 when cpp is
> > 4. If GEM object is allocated based on the
51 matches
Mail list logo
