This patch adds a new trace event to track the PTE update
events. This specific event will provide information like:
- start and end of virtual memory mapping
- HW engine flags for the map
- physical address for mapping
This will be particularly useful for memory profiling tools
(like RMV) which a
[+amd-gfx]
Am 2020-08-19 um 12:15 p.m. schrieb Ba, Gang:
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Felix,
>
> For write point update, what is the best way to do:
Do you mean read pointer update? The hardware updates the write pointer,
the driver updates the read pointer.
>
On Thu, Aug 20, 2020 at 12:05:56PM +0800, Kuehling, Felix wrote:
>
> Am 2020-08-19 um 11:09 p.m. schrieb Huang Rui:
> > On Thu, Aug 20, 2020 at 08:18:57AM +0800, Kuehling, Felix wrote:
> >> On 2020-08-19 7:56 p.m., Huang Rui wrote:
> >>> On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wr
Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit f41ed88cbd6f025f7a683a11a74f901555fba11c:
drm/amdgpu/display: use GFP_ATOMIC in dcn20_validate_bandwidth_internal
(2020-08-10 18:09:46 -0400)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linu
Am 2020-08-19 um 11:09 p.m. schrieb Huang Rui:
> On Thu, Aug 20, 2020 at 08:18:57AM +0800, Kuehling, Felix wrote:
>> On 2020-08-19 7:56 p.m., Huang Rui wrote:
>>> On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wrote:
Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
> We still have
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Dennis Li
Sent: Thursday, August 20, 2020 08:33
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Kuehling, Felix ; Zhang,
Hawking ; Koenig, Christian
Cc: Li, Dennis
Subject: [PATCH v2] drm/
On Thu, Aug 20, 2020 at 08:18:57AM +0800, Kuehling, Felix wrote:
> On 2020-08-19 7:56 p.m., Huang Rui wrote:
> > On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wrote:
> >> Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
> >>> We still have a few iommu issues which need to address, so force
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Wang Hai
Sent: Wednesday, August 19, 2020 7:34 PM
To: Quan, Evan ; Deucher, Alexander
; Koenig, Christian ;
airl...@linux.ie; dan...@ffwll.ch
Cc: amd-gfx@lists.freedesktop.org; dri-de.
Using dev_xxx instead of DRM_xxx/pr_xxx to indicate which device
of a hive is the message for.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 81b1d9a1dca0..08548e051cc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/a
in single gpu system, if driver reenter gpu recovery,
amdgpu_device_lock_adev will return false, but hive is
nullptr now.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 82242e2f5658..81b1d9a1dca0 100644
--- a/d
clients don't need reset-lock for synchronization when no
GPU recovery.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c8aec832b244..ec11ed2a9ca4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amd
if other threads have holden the reset lock, recovery will
fail to try_lock. Therefore we introduce atomic hive->in_reset
and adev->in_gpu_reset, to avoid reentering GPU recovery.
v2:
drop "? true : false" in the definition of amdgpu_in_reset
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/dr
On Thu, Aug 20, 2020 at 08:18:57AM +0800, Kuehling, Felix wrote:
> On 2020-08-19 7:56 p.m., Huang Rui wrote:
> > On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wrote:
> >> Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
> >>> We still have a few iommu issues which need to address, so force
On 2020-08-19 7:56 p.m., Huang Rui wrote:
On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wrote:
Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
We still have a few iommu issues which need to address, so force raven
as "dgpu" path for the moment.
This is to add the fallback path to byp
On Wed, Aug 19, 2020 at 11:28:01PM +0800, Kuehling, Felix wrote:
> Am 2020-08-19 um 11:01 a.m. schrieb Huang Rui:
> > On Wed, Aug 19, 2020 at 10:36:05PM +0800, Kuehling, Felix wrote:
> >> Just for Carrizo, HDP flushing doesn't make a lot of sense because we
> >> don't use HDP to access the framebuf
On Wed, Aug 19, 2020 at 11:38:34PM +0800, Kuehling, Felix wrote:
> Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
> > We still have a few iommu issues which need to address, so force raven
> > as "dgpu" path for the moment.
> >
> > This is to add the fallback path to bypass IOMMU if IOMMU v2 is disa
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139,
v4.14.193, v4.9.232, v4.4.232.
v5.8.1: Build O
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139,
v4.14.193, v4.9.232, v4.4.232.
v5.8.1: Build O
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.1, v5.7.15, v5.4.58, v4.19.139,
v4.14.193, v4.9.232, v4.4.232.
v5.8.1: Build O
On Wed, Aug 19, 2020 at 5:58 AM Evan Quan wrote:
>
> For entering UMD stable Pstate, the operations to enter rlc_safe
> mode, disable mgcg_perfmon and disable PCIE aspm are needed. And
> the opposite operations should be performed on UMD stable Pstate
> exiting.
>
> Change-Id: Iff4aa465fd16f55a4f4
On Wed, 19 Aug 2020 at 23:44, Christian König
wrote:
>
> drm-next reverted the changes to ttm_tt_create() to do the
> NULL check inside the function, but drm-misc-next adds new
> users of this approach.
>
> Re-apply the NULL check change inside the function to fix this.
Where is this problem now?
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Hersen Wu
-Original Message-
From: Nicholas Kazlauskas
Sent: Wednesday, August 19, 2020 1:56 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wu, Hersen
Subject: [PATCH] drm/amd/display: Reject overla
NUMA auto balancing task_numa_work periodically change memory range
protection proto, in order to trigger CPU page hinting fault when CPU
access the memory later to check if that memory range need to migrate to
different NUMA node.
GPU can still access the memory after NUMA change the proto becaus
[Why]
These aren't stable on some platform configurations when driving
multiple displays, especially on higher resolution.
In particular the delay in asserting p-state and validating from
x86 outweights any power or performance benefit from the hardware
composition.
Under some configurations this
Hi,
On 13/08/2020 11:36, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in omapdrm.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/omap
Am 2020-08-19 um 7:06 a.m. schrieb Huang Rui:
> We still have a few iommu issues which need to address, so force raven
> as "dgpu" path for the moment.
>
> This is to add the fallback path to bypass IOMMU if IOMMU v2 is disabled
> or ACPI CRAT table not correct.
>
> v2: Use ignore_crat parameter to
Am 2020-08-19 um 11:01 a.m. schrieb Huang Rui:
> On Wed, Aug 19, 2020 at 10:36:05PM +0800, Kuehling, Felix wrote:
>> Just for Carrizo, HDP flushing doesn't make a lot of sense because we
>> don't use HDP to access the framebuffer.
> OK, so soc15 and later need use HDP to access the framebuffer from
On Wed, Aug 19, 2020 at 10:36:05PM +0800, Kuehling, Felix wrote:
> Just for Carrizo, HDP flushing doesn't make a lot of sense because we
> don't use HDP to access the framebuffer.
OK, so soc15 and later need use HDP to access the framebuffer from user
space. May I know why?
>
> The code you're c
Just for Carrizo, HDP flushing doesn't make a lot of sense because we
don't use HDP to access the framebuffer.
The code you're changing doesn't look Carrizo-specific, but VI-specific.
So it would affect Fiji and Polaris as well. We already support Fiji and
Polaris dGPUs with KFD, apparently withou
Carrzio also needs remap HDP_MEM_COHERENCY_FLUSH_CNTL and
HDP_REG_COHERENCY_FLUSH_CNTL to the empty page in mmio space. Then user
mode is able to do flush hdp as well. It will used for force dgpu path
on carrizo.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/vi.c | 18 +++--
On 19/08/20 7:00 pm, Christian König wrote:
> Am 19.08.20 um 15:08 schrieb Shashank Sharma:
>> On 19/08/20 6:34 pm, Christian König wrote:
>>> Am 19.08.20 um 14:37 schrieb Shashank Sharma:
On 19/08/20 6:03 pm, Christian König wrote:
> Am 19.08.20 um 14:19 schrieb Shashank Sharma:
>> O
On Wed, Aug 19, 2020 at 5:08 AM Michel Dänzer wrote:
>
> On 2020-07-22 7:12 p.m., Alex Deucher wrote:
> > On Wed, Jul 22, 2020 at 10:25 AM Michel Dänzer wrote:
> >> On 2020-07-22 3:10 p.m., Kazlauskas, Nicholas wrote:
> >>> On 2020-07-22 8:51 a.m., Daniel Vetter wrote:
> On Wed, Jul 22, 2020
Remove asic_reg/nbio/nbio_6_1_offset.h which is included more than once
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h
b/drivers/gpu/drm/amd
d dcn30 Headers (v2)") added the
four header files {dpcs,dcn}_3_0_0_{offset,sh_mask}.h as executable, i.e.,
mode 755.
Set to the usual modes for source and headers files and clean up those
mistakes. No functional change.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/t
Series is Acked-by: Nirmoy Das
On 8/19/20 11:58 AM, Evan Quan wrote:
Fulfill Navi gfx and pcie settings on umd pstate switching.
V2: temporarily skip the pcie ASPM setting considering the ASPM function
is not fully enabled yet
Change-Id: I8d746d4c25f890665feeffddf64164ed2b1f5ccc
Signed-o
Am 19.08.20 um 15:08 schrieb Shashank Sharma:
On 19/08/20 6:34 pm, Christian König wrote:
Am 19.08.20 um 14:37 schrieb Shashank Sharma:
On 19/08/20 6:03 pm, Christian König wrote:
Am 19.08.20 um 14:19 schrieb Shashank Sharma:
On 19/08/20 5:38 pm, Christian König wrote:
Am 19.08.20 um 13:52 s
On 8/19/20 2:58 PM, Christian König wrote:
Am 19.08.20 um 14:51 schrieb Shashank Sharma:
On 19/08/20 6:15 pm, Nirmoy wrote:
Hi Christian,
On 8/19/20 2:08 PM, Christian König wrote:
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:
On 19/08/20 6:34 pm, Christian König wrote:
> Am 19.08.20 um 14:37 schrieb Shashank Sharma:
>> On 19/08/20 6:03 pm, Christian König wrote:
>>> Am 19.08.20 um 14:19 schrieb Shashank Sharma:
On 19/08/20 5:38 pm, Christian König wrote:
> Am 19.08.20 um 13:52 schrieb Shashank Sharma:
>> O
Am 19.08.20 um 14:37 schrieb Shashank Sharma:
On 19/08/20 6:03 pm, Christian König wrote:
Am 19.08.20 um 14:19 schrieb Shashank Sharma:
On 19/08/20 5:38 pm, Christian König wrote:
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 s
Am 19.08.20 um 14:51 schrieb Shashank Sharma:
On 19/08/20 6:15 pm, Nirmoy wrote:
Hi Christian,
On 8/19/20 2:08 PM, Christian König wrote:
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 schrieb Shashank Sharma:
This patch adds
On 19/08/20 6:15 pm, Nirmoy wrote:
> Hi Christian,
>
> On 8/19/20 2:08 PM, Christian König wrote:
>
>> Am 19.08.20 um 13:52 schrieb Shashank Sharma:
>>> On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 schrieb Shashank Sharma:
> This patch adds a new trace event to track t
Hi Christian,
On 8/19/20 2:08 PM, Christian König wrote:
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 schrieb Shashank Sharma:
This patch adds a new trace event to track the PTE update
events. This specific event will provide
On 19/08/20 6:03 pm, Christian König wrote:
> Am 19.08.20 um 14:19 schrieb Shashank Sharma:
>> On 19/08/20 5:38 pm, Christian König wrote:
>>> Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
> Am 13.08.20 um 05:04 schrieb Shashank Sharma:
>> T
Am 19.08.20 um 14:19 schrieb Shashank Sharma:
On 19/08/20 5:38 pm, Christian König wrote:
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 schrieb Shashank Sharma:
This patch adds a new trace event to track the PTE update
events. T
On 19/08/20 5:38 pm, Christian König wrote:
> Am 19.08.20 um 13:52 schrieb Shashank Sharma:
>> On 13/08/20 1:28 pm, Christian König wrote:
>>> Am 13.08.20 um 05:04 schrieb Shashank Sharma:
This patch adds a new trace event to track the PTE update
events. This specific event will provide
Am 19.08.20 um 13:52 schrieb Shashank Sharma:
On 13/08/20 1:28 pm, Christian König wrote:
Am 13.08.20 um 05:04 schrieb Shashank Sharma:
This patch adds a new trace event to track the PTE update
events. This specific event will provide information like:
- start and end of virtual memory mapping
On 13/08/20 1:28 pm, Christian König wrote:
> Am 13.08.20 um 05:04 schrieb Shashank Sharma:
>> This patch adds a new trace event to track the PTE update
>> events. This specific event will provide information like:
>> - start and end of virtual memory mapping
>> - HW engine flags for the map
>> -
We still have a few iommu issues which need to address, so force raven
as "dgpu" path for the moment.
This is to add the fallback path to bypass IOMMU if IOMMU v2 is disabled
or ACPI CRAT table not correct.
v2: Use ignore_crat parameter to decide whether it will go with IOMMUv2.
v3: Align with ex
It's better to use inline function to wrap the iommu checking.
v2: rename the function and use another input.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 4 ++--
.../gpu/drm/amd/amdkfd/kfd
On Tue, Aug 18, 2020 at 11:15:47PM +0800, Kuehling, Felix wrote:
> Interesting. Does this actually work on Carrizo or Kaveri? I'd like to
I just found a Carrizo board, rocm info works well, and clinfo is able to
print most information. But it seems stuck in the ROCr (submit
SubmitLinearCopyCommand
Enable Navi1X MGCG perfmon setting.
Change-Id: Ifc860a798becbe372f974f7eb537a4a57ac4943f
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 16
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd
Fulfill Navi gfx and pcie settings on umd pstate switching.
V2: temporarily skip the pcie ASPM setting considering the ASPM function
is not fully enabled yet
Change-Id: I8d746d4c25f890665feeffddf64164ed2b1f5ccc
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/nv.c | 17 ++
Support NAVI10 ASPM setting.
Change-Id: I0c9410951e23b1d4a30bf8e373431dcb16a4573b
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 2 ++
drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 39
2 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm
For entering UMD stable Pstate, the operations to enter rlc_safe
mode, disable mgcg_perfmon and disable PCIE aspm are needed. And
the opposite operations should be performed on UMD stable Pstate
exiting.
Change-Id: Iff4aa465fd16f55a4f4de8ee0503997b204f8f9d
Signed-off-by: Evan Quan
---
drivers/gp
Am 19.08.20 um 11:34 schrieb Dennis Li:
if other threads have holden the reset lock, recovery will
fail to try_lock. Therefore we introduce atomic hive->in_reset
and adev->in_gpu_reset, to avoid reentering GPU recovery.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
if other threads have holden the reset lock, recovery will
fail to try_lock. Therefore we introduce atomic hive->in_reset
and adev->in_gpu_reset, to avoid reentering GPU recovery.
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
ind
On 2020-07-22 7:12 p.m., Alex Deucher wrote:
> On Wed, Jul 22, 2020 at 10:25 AM Michel Dänzer wrote:
>> On 2020-07-22 3:10 p.m., Kazlauskas, Nicholas wrote:
>>> On 2020-07-22 8:51 a.m., Daniel Vetter wrote:
On Wed, Jul 22, 2020 at 2:38 PM Michel Dänzer wrote:
>
> From: Michel Dänzer
lwahn
Reviewed-by: Christian König
---
applies cleanly on current master and next-20200819
Alex, Christian, please pick this minor non-urgent cleanup patch.
Alex is usually the one picking those up. If he misses something feel
free to ping us once more.
Thanks,
Christian.
Dennis, Jerry,
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Dennis Li
Sent: Tuesday, August 18, 2020 20:38
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Kuehling, Felix ; Zhang,
Hawking ; Koenig, Christian
Cc: Li, Dennis
Subject: [PATCH v3] drm/a
60 matches
Mail list logo
