Signed-off-by: Stanley.Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index daf63a4c1fff..dfeaa57dd7ea 100644
--- a/drivers/gpu/drm/amd/
Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another look at this part when I don't have a massive
headache any more.
Maybe split the patch set up into different parts, something like:
1. Adding general infrastructure.
2. Ma
[AMD Official Use Only - Internal Distribution Only]
That looks better to me :) As more things get added, I don't know how long you
will be able to hold sw/hw cleanup separate and the name could confuse
eventually.
Thanks,
Lijo
___
amd-gfx mailing lis
On Wed, 28 Apr 2021, Nikola Cornij wrote:
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space must be used. Without
> doing that, the three DPCD values that differ will be wrong, leading to
> incorrect or limited func
On 2021-04-30 1:19 a.m., Lazar, Lijo wrote:
[AMD Official Use Only - Internal Distribution Only]
sysfs cleanup is a sw cleanup to me but done inside hw fini. sw/hw
separation is not strictly followed, or name it like stage1/stage2 fini.
The thing is that it was called early_fini and late_f
[AMD Official Use Only - Internal Distribution Only]
sysfs cleanup is a sw cleanup to me but done inside hw fini. sw/hw separation
is not strictly followed, or name it like stage1/stage2 fini.
Thanks,
Lijo
From: amd-gfx on behalf of Andrey
Grodzovsky
Sent: Wed
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Peng
>Ju Zhou
>Sent: Thursday, April 29, 2021 2:31 PM
>To: amd-gfx@lists.freedesktop.org
>Subject: [PATCH] drm/amdgpu: Rename the flags to eliminate ambiguity v2
[AMD Official Use Only - Internal Distribution Only]
Hi Christian
Thanks for your review, I will change it.
--
BW
Pengju Zhou
> -Original Message-
> From: Christian König
> Sent: Thursday, April 29, 2021 7:29 PM
> T
On Wed, Apr 28, 2021 at 11:13 AM Andrey Grodzovsky
wrote:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group is removed.
>
> v5: Drop IOMMU notifier and switch to lockless call to ttm_tt_unpopulate
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgp
On Thu, Apr 29, 2021 at 3:04 AM Christian König
wrote:
>
>
>
> Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
> > Some of the stuff in amdgpu_device_fini such as HW interrupts
> > disable and pending fences finilization must be done right away on
> > pci_remove while most of the stuff which relat
Am 2021-04-29 um 9:12 p.m. schrieb Zeng, Oak:
> I think part of this can be done more clean in amdgpu_device_init:
>
> r = 0;
> If (!adev->gmc.xgmi.connected_to_cpu)
> /* enable PCIE atomic ops */
> r = pci_enable_atomic_ops_to_root(adev->pdev,
>
On Thu, Apr 29, 2021 at 4:50 PM Bas Nieuwenhuizen
wrote:
>
> This reverts commit f258907fdd835e1aed6d666b00cdd0f186676b7c.
>
> Same problem as "drm/amdgpu: Verify bo size can fit framebuffer size",
> but because it gets checked earlier it now only triggers on the
> modifiers case.
>
> There are a
I think part of this can be done more clean in amdgpu_device_init:
r = 0;
If (!adev->gmc.xgmi.connected_to_cpu)
/* enable PCIE atomic ops */
r = pci_enable_atomic_ops_to_root(adev->pdev,
PCI_EXP_DEVCAP2_ATOMI
On Thu, Apr 29, 2021 at 11:27 PM Mark Yacoub wrote:
>
> On Thu, Apr 29, 2021 at 4:50 PM Bas Nieuwenhuizen
> wrote:
> >
> > This reverts commit f258907fdd835e1aed6d666b00cdd0f186676b7c.
> >
> > Same problem as "drm/amdgpu: Verify bo size can fit framebuffer size",
> > but because it gets checked e
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a l
Change history:
v10:
- Removed mistakenly added temporary file
v9:
- Actually send the changes under v8 below (missed to commit
before sending v8)
v8:
- Chaged link lanes and rate parameters to u8
v7:
- Fixed formatting
- Fixed 'unused variable' compile warning
- Fixed comment format
[why]
DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
set, Extended Base Receiver Capability DPCD space must be used. Without
doing that, the three DPCD values that differ will be wrong, leading to
incorrect or limited functionality. MST link rate, for example, could
have a l
Change history:
v9:
- Actually send the changes under v8 below (missed to commit
before sending v8)
v8:
- Chaged link lanes and rate parameters to u8
v7:
- Fixed formatting
- Fixed 'unused variable' compile warning
- Fixed comment format
v6:
- Submited from (hopefully) the correct re
This reverts commit f258907fdd835e1aed6d666b00cdd0f186676b7c.
Same problem as "drm/amdgpu: Verify bo size can fit framebuffer size",
but because it gets checked earlier it now only triggers on the
modifiers case.
There are a couple of reasons why the DRM core BO size check won't
work for AMDGPU,
On 2021-04-29 3:23 p.m., Bjorn Helgaas wrote:
On Thu, Apr 29, 2021 at 12:53:15PM -0400, Andrey Grodzovsky wrote:
On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
This is exact copy of 'USB: add support for dev_groups to
struct
On 2021-04-29 3:05 p.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
On Thu, Apr 29, 2021 at 4:22 PM Luo, Zhigang wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Thanks Alex.
>
> I will add it.
With that fixed, the series is:
Reviewed-by: Alex Deucher
>
> --Zhigang
>
> -Original Message-
> From: Alex Deucher
> Sent: April 29, 2021 4
[AMD Official Use Only - Internal Distribution Only]
Thanks Alex.
I will add it.
--Zhigang
-Original Message-
From: Alex Deucher
Sent: April 29, 2021 4:17 PM
To: Luo, Zhigang
Cc: amd-gfx list
Subject: Re: [PATCH 2/2] drm/amdgpu: Add Aldebaran virtualization support
On Thu, Apr 29,
On Thu, Apr 29, 2021 at 4:13 PM Zhigang Luo wrote:
>
> 1. add Aldebaran in virtualization detection list.
> 2. disable Aldebaran virtual display support as there is no GFX
>engine in Aldebaran.
> 3. skip TMR loading if Aldebaran is in virtualizatin mode as it
>shares the one host loaded.
>
1. add Aldebaran in virtualization detection list.
2. disable Aldebaran virtual display support as there is no GFX
engine in Aldebaran.
3. skip TMR loading if Aldebaran is in virtualizatin mode as it
shares the one host loaded.
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdgpu/amdg
update kfd_supported_devices to enable Aldebaran virtualization support
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
in
On Thu, Apr 29, 2021 at 9:40 AM Kai-Heng Feng
wrote:
>
> Screen flickers rapidly when two 4K 60Hz monitors are connected to an
> Oland card. This issue doesn't happen when one monitor is 4K 60Hz
> (pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz).
>
> The issue is gone after setti
On Thu, Apr 29, 2021 at 12:53:15PM -0400, Andrey Grodzovsky wrote:
> On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
> > On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
> > > This is exact copy of 'USB: add support for dev_groups to
> > > struct usb_device_driver' patch by Greg bu
On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
> > > > With this calling drm_dev_unpl
JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
today if there's no objections
On Wed, 2021-04-28 at 19:43 -0400, Nikola Cornij wrote:
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space must
[AMD Official Use Only - Internal Distribution Only]
Thanks, Felix.
Yes, I will sent out several patches for Aldebaran virtualization support soon.
Thanks,
Zhigang
-Original Message-
From: Kuehling, Felix
Sent: April 29, 2021 2:40 PM
To: Luo, Zhigang ; amd-gfx@lists.freedesktop.org
Subj
Am 2021-04-29 um 2:33 p.m. schrieb Zhigang Luo:
> It is Aldebaran VF device ID, for virtualization support.
>
> Signed-off-by: Zhigang Luo
This patch looks good to me.
Acked-by: Felix Kuehling
I believe you'll also need to add an entry for the VF in
kfd_supported_devices in kfd_device.c.
Rega
It is Aldebaran VF device ID, for virtualization support.
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0369d3532bf0..310e1249e64e
On 2021-04-29 3:15 a.m., Christian König wrote:
Filizing the fences? You mean finishing the fences, don't you? :)
Yes, my bad.
Andrey
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
No point calling amdgpu_fence_wait_empty before stopping the
SW scheduler otherwise there is always a cha
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another look at this part when I don't have a massive
headache any more.
Maybe split the patch set up into different parts, something like:
1. Adding general infrastructure.
2. Making sure all memory is unpolated.
3. Job and fence
On 2021-04-29 3:19 a.m., Christian König wrote:
Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:
Access to those must be prevented post pci_remove
That is certainly a no-go. We want to get rid of the kernel pointers in
BOs, not add another one.
Christian.
As we discussed internally, will
On 2021-04-28 12:53 p.m., Bjorn Helgaas wrote:
In subject:
s/PCI: add support/PCI: Add support/
to match convention ("git log --oneline drivers/pci/pci-driver.c" to
learn this).
On Wed, Apr 28, 2021 at 11:11:48AM -0400, Andrey Grodzovsky wrote:
This is exact copy of 'USB: add support for d
On 2021-04-29 12:29 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:21 p.m. schrieb Andrey Grodzovsky:
On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
So as I understand your preferred approach is that I scope any
back_end, HW specific
Am 2021-04-29 um 12:21 p.m. schrieb Andrey Grodzovsky:
>
>
> On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
>> Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
>>> So as I understand your preferred approach is that I scope any
>>> back_end, HW specific function with drm_dev_enter/exit becaus
On 2021-04-29 12:15 p.m., Felix Kuehling wrote:
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
So as I understand your preferred approach is that I scope any
back_end, HW specific function with drm_dev_enter/exit because that
where MMIO
access takes place. But besides explicit MMIO acc
Am 2021-04-29 um 12:04 p.m. schrieb Andrey Grodzovsky:
> So as I understand your preferred approach is that I scope any
> back_end, HW specific function with drm_dev_enter/exit because that
> where MMIO
> access takes place. But besides explicit MMIO access thorough
> register accessors in the HW b
On 2021-04-29 7:32 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
With this calling drm_dev_unplug will flush and block
all in flight IOCTLs
Also, add feature such that if device su
On Thu, Apr 29, 2021 at 4:11 AM Chen, Jiansong (Simon)
wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Alex,
> I notice there is already similar logic in sdma_v5_0_ring_emit_ib, do we need
> remove it?
>
I think we can also remove this from sdma_v5_0_ring_emit_ib in a
foll
>Is your robot public available?
Sorry, I started to write the robot just one week ago.
It is not strong and complete enough so it is not public available now.
But I am still working on it. If complete, it can be public available.
In fact, this patch is catched by the script called checkinclude
On Thu, Apr 29, 2021 at 2:44 AM Felix Kuehling wrote:
>
> On 2021-04-27 7:27, Fabio M. De Francesco wrote:
> > In the documentation of functions, removed excess parameters, described
> > undocumented ones, and fixed syntax errors.
> >
> > Signed-off-by: Fabio M. De Francesco
> > ---
> >
> > Chang
Well if you are bored we quite often have the problem of unused fields
in structures.
If your robot could find fields which are never read, that would be
quite helpful I think.
There probably will be a lot of false positives for things like padding,
but maybe that yields something.
Christi
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Thursday, April 29, 2021 11:18 AM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Cc: Zeng, Oak ; Errabolu, Ramesh
>
> Subject: Re: [PATCH] drm/amdkfd: report atomics suppo
Am 2021-04-29 um 11:04 a.m. schrieb Kim, Jonathan:
> [AMD Official Use Only - Internal Distribution Only]
>
>> -Original Message-
>> From: Kuehling, Felix
>> Sent: Thursday, April 29, 2021 10:49 AM
>> To: Kim, Jonathan ; amd-
>> g...@lists.freedesktop.org
>> Cc: Zeng, Oak ; Errabolu, Rames
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Thursday, April 29, 2021 10:49 AM
> To: Kim, Jonathan ; amd-
> g...@lists.freedesktop.org
> Cc: Zeng, Oak ; Errabolu, Ramesh
>
> Subject: Re: [PATCH] drm/amdkfd: report atomics suppo
Am 2021-04-29 um 5:36 a.m. schrieb Jonathan Kim:
> Link atomics support over xGMI should be reported independently of PCIe.
I don't understand this change. I don't see any code that gets executed
if (adev->gmc.xgmi.connected_to_cpu). Where is the code that reports
atomics support for this case?
A
Am 2021-04-29 um 5:34 a.m. schrieb Jonathan Kim:
> GPUs connected to CPUs over xGMI are bidirectional so set weight by a
> single hop both ways.
>
> Signed-off-by: Jonathan Kim
> Tested-by: Ramesh Errabolu
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 1 +
> 1 f
Is your robot public available?
btw, applied to amd-staging-drm-next.
Thanks
On 04/29, Jiabing Wan wrote:
>
> >Nice catch!
> >
> >Are you using any tool to identify this problem?
>
> Yes, I have a robot including many detecting scripts :)
>
> >Reviewed-by: Rodrigo Siqueira
> >
> >On 04/29,
Applied to amd-staging-drm-next.
Thanks
On 04/29, Rodrigo Siqueira wrote:
> Reviewed-by: Rodrigo Siqueira
>
> On 04/29, Wan Jiabing wrote:
> > There are two declarations of struct dc_state here.
> > Remove the later duplicate more secure.
> >
> > Signed-off-by: Wan Jiabing
> > ---
> > Changel
Reviewed-by: Rodrigo Siqueira
On 04/29, Wan Jiabing wrote:
> There are two declarations of struct dc_state here.
> Remove the later duplicate more secure.
>
> Signed-off-by: Wan Jiabing
> ---
> Changelog:
> v2:
> - Remove the later duplicate instead of the former.
> ---
> drivers/gpu/drm/amd/d
Screen flickers rapidly when two 4K 60Hz monitors are connected to an
Oland card. This issue doesn't happen when one monitor is 4K 60Hz
(pixelclock 594MHz) and another one is 4K 30Hz (pixelclock 297MHz).
The issue is gone after setting "power_dpm_force_performance_level" to
"high". Following the l
>Nice catch!
>
>Are you using any tool to identify this problem?
Yes, I have a robot including many detecting scripts :)
>Reviewed-by: Rodrigo Siqueira
>
>On 04/29, Wan Jiabing wrote:
>> In commit 482812d56698e ("drm/amd/display: Set max TTU on
>> DPG enable"), "hubp.h" was added which caused
There are two declarations of struct dc_state here.
Remove the later duplicate more secure.
Signed-off-by: Wan Jiabing
---
Changelog:
v2:
- Remove the later duplicate instead of the former.
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm
>Hi Wan,
>
>Instead of remove the first dc_state, remove the second one.
>
>Thanks
Hi Rodrigo,
Thanks for your reply.
OK, in fact, there are no functions using struct dc_state between two
struct declarations. So I think removing anyone is OK.
Remove the first one to make it more closer to user
[AMD Public Use]
Hi Dennis,
The memory allocation for ras_if is needed even the block mask is not set,
because kernel need to issue disable_feature command to RAS TA in
amdgpu_ras_late_init. e.g. to set GFX EDC mode to bypass mode.
Regards,
Hawking
-Original Message-
From: Li, Dennis
Hi Wan,
Instead of remove the first dc_state, remove the second one.
Thanks
On 04/29, Wan Jiabing wrote:
> There are two declarations of struct dc_state here.
> The later one is closer to its user. Remove the former duplicate.
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/gpu/drm/amd/display
Nice catch!
Are you using any tool to identify this problem?
Reviewed-by: Rodrigo Siqueira
On 04/29, Wan Jiabing wrote:
> In commit 482812d56698e ("drm/amd/display: Set max TTU on
> DPG enable"), "hubp.h" was added which caused the duplicate include.
> To be on the safe side, remove the later d
On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
> > With this calling drm_dev_unplug will flush and block
> > all in flight IOCTLs
> >
> > Also, add feature such that if device supports graceful unplug
> > we enclo
Am 29.04.21 um 12:26 schrieb Peng Ju Zhou:
there are 2 hubs to flush in the gmc, to make it easier
to debug when hub flush failed, refine the logs.
NAK, we can have more than just the two hubs.
See gmc_v9_0_process_interrupt:
if (entry->client_id == SOC15_IH_CLIENTID_VMC) {
On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:
> With this calling drm_dev_unplug will flush and block
> all in flight IOCTLs
>
> Also, add feature such that if device supports graceful unplug
> we enclose entire IOCTL in SRCU critical section.
>
> Signed-off-by: Andrey Grodzo
there are 2 hubs to flush in the gmc, to make it easier
to debug when hub flush failed, refine the logs.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/
KMD should not the program these registers,
so skip them in the SRIOV environment.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index
KMD should not program these registers, the value were
defined in the host, so skip them in the SRIOV environment.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mmh
use psp to program IH_RB_CNTL* if indirect access
for ih enabled in SRIOV environment.
Signed-off-by: Victor
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 19 +--
drivers/gpu/drm/amd/amdgpu/nv.c| 2 +-
2 files changed, 18 insertions(+), 3 dele
From: pengzhou
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: pengzhou
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 37 +
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 25 +
2 files changed, 24 insertions(+), 10
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 78 ++
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sd
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/a
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 42 +--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
Change RLCG/SOC15 register access interface to triage
GC/MMHUB access from MMIO to RLCG.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h | 4 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 68 --
drivers/gpu/drm/amd/amdgpu/soc15_common.h | 109 +++
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gf
Link atomics support over xGMI should be reported independently of PCIe.
Signed-off-by: Jonathan Kim
Tested-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 29 ++-
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/
GPUs connected to CPUs over xGMI are bidirectional so set weight by a
single hop both ways.
Signed-off-by: Jonathan Kim
Tested-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/d
[AMD Official Use Only - Internal Distribution Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:26 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawk
[AMD Official Use Only - Internal Distribution Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:26 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawk
[AMD Official Use Only - Internal Distribution Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:26 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawk
[AMD Official Use Only - Internal Distribution Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:26 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawk
[AMD Official Use Only - Internal Distribution Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:26 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawk
[AMD Official Use Only - Internal Distribution Only]
>>+ r = amdgpu_ras_late_init(adev, adev->hdp.ras_if,
>>+ &fs_info, &ih_info);
>>+ if (r || !amdgpu_ras_is_supported(adev, adev->hdp.ras_if->block)) {
>>+ kfree(adev->hdp.ras_if);
>>+ a
there are 2 hubs to flush in the gmc, to make it easier
to debug when hub flush failed, refine the logs.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/
KMD should not the program these registers,
so skip them in the SRIOV environment.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index
KMD should not program these registers, the value were
defined in the host, so skip them in the SRIOV environment.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mmh
use psp to program IH_RB_CNTL* if indirect access
for ih enabled in SRIOV environment.
Signed-off-by: Victor
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 19 +--
drivers/gpu/drm/amd/amdgpu/nv.c| 2 +-
2 files changed, 18 insertions(+), 3 dele
From: pengzhou
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: pengzhou
---
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 37 +
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 25 +
2 files changed, 24 insertions(+), 10
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/nv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 78 ++
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sd
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/a
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 42 +--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/am
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gf
Change RLCG/SOC15 register access interface to triage
GC/MMHUB access from MMIO to RLCG.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h | 4 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 68 --
drivers/gpu/drm/amd/amdgpu/soc15_common.h | 109 +++
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
I notice there is already similar logic in sdma_v5_0_ring_emit_ib, do we need
remove it?
Regards,
Jiansong
@@ -410,6 +410,18 @@ static void sdma_v5_0_ring_emit_ib(struct amdgpu_ring
*ring,
unsigned vmid = AMDGPU_JOB_GET_VMID
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: John Clements
-Original Message-
From: Hawking Zhang
Sent: Thursday, April 29, 2021 2:27 PM
To: Deucher, Alexander ; Li, Dennis
; Clements, John ;
amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking
Subject: [PATCH] drm/
From: Aric Cyr
This version brings along following fixes:
Anthony Koo (1):
drm/amd/display: [FW Promotion] Release 0.0.64
Aric Cyr (2):
dc: Revert commit "treat memory as a single-channel"
drm/amd/display: 3.2.134
Calvin Hou (1):
drm/amd/display: remove checking sink in is_timing_chang
From: Anthony Koo
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Wayne Lin
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/
1 - 100 of 123 matches
Mail list logo
