From: David Yat Sin
When doing a restore on a different node, the gpu_id's on the restore
node may be different. But the user space application will still refer
use the original gpu_id's in the ioctl calls. Adding code to create a
gpu id mapping so that kfd can determine actual gpu_id during the
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue
with the same CU mask value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I1822fa2488f90365dfe7a3c5971a2ed6c0046b4a
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 160 +--
From: David Yat Sin
Dump contents of queue control stacks on CRIU dump and restore them
during CRIU restore.
(rajneesh: rebased to 5.11 and fixed merge conflict)
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: David Yat Sin
Change-Id: Ia1f38f3d4309e1f026981b16d26306672f3bf266
---
From: David Yat Sin
Dump contents of queue MQD's on CRIU dump and restore them during CRIU
restore.
Signed-off-by: David Yat Sin
Change-Id: If54f892fb6cb8a5bde8a993891dad0dbb997c239
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 35 --
From: Rajneesh Bhardwaj
This reverts commit 12ebe2b9df192a2a8580cd9ee3e9940c116913c8.
This is just a temporary work around and will be dropped later.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: David Yat Sin
Add support to existing CRIU ioctl's to save and restore events during
criu checkpoint and restore.
Signed-off-by: David Yat Sin
Change-Id: I1635b1fa91a81abcbd19290cb88c8ca142c390e0
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 185 ---
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same queue id value used during CRIU dump. Adding a new private
structure queue_restore_data to store queue restore information.
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: David Yat Sin
Change-Id:
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same sdma id value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I8ed667edb8b9b7b5089e59b78de9be80493a2808
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 +
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same doorbell id value used during CRIU dump.
Signed-off-by: David Yat Sin
Change-Id: I6a79de1f8c760d5a9d28e7951740296f2f8796a7
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1 +
From: David Yat Sin
Add support to existing CRIU ioctl's to save number of queues and queue
properties for each queue during checkpoint and re-create queues on restore.
Signed-off-by: David Yat Sin
Change-Id: Ifcd5e8359f492eef015867f354f44146dd1b6848
---
From: Rajneesh Bhardwaj
This adds support to create userptr BOs on restore and introduces a new
ioctl to restart memory notifiers for the restored userptr BOs.
When doing CRIU restore MMU notifications can happen anytime after we call
amdgpu_mn_register. Prevent MMU notifications until we reach
From: Rajneesh Bhardwaj
This implements the KFD CRIU Restore ioctl that lays the basic
foundation for the CRIU restore operation. It provides support to
create the buffer objects corresponding to Non-Paged system memory
mapped for GPU and/or CPU access and lays basic foundation for the
userptrs
From: Rajneesh Bhardwaj
This adds support to discover the buffer objects that belong to a
process being checkpointed. The data corresponding to these buffer
objects is returned to user space plugin running under criu master
context which then stores this info to recreate these buffer objects
From: Rajneesh Bhardwaj
Checkpoint-Restore in userspace (CRIU) is a powerful tool that can
snapshot a running process and later restore it on same or a remote
machine but expects the processes that have a device file (e.g. GPU)
associated with them, provide necessary driver support to assist
From: Rajneesh Bhardwaj
This IOCTL is expected to be called as a precursor to the actual
Checkpoint operation. This does the basic discovery into the target
process seized by CRIU and relays the information to the userspace that
utilizes it to start the Checkpoint operation via another dedicated
This patch series is a prototype for supporting CRIU for ROCm
applications. More work is needed before this can be upstreamed and
released, including a new ioctl API that is extensible without breaking
the ABI.
The user mode code to go with this can be found at
From: Rajneesh Bhardwaj
Update rock-rel_defconfig for monolithic kernel release that enables
CRIU support with kfd.
Signed-off-by: Rajneesh Bhardwaj
(cherry picked from commit 4a6d309a82648a23a4fc0add83013ac6db6187d5)
Change-Id: Ie6fe1e44285f4fccc17092baee664e8d784851fa
---
From: Rajneesh Bhardwaj
- Update debug config for Checkpoint-Restore (CR) support
- Also include necessary options for CR with docker containers.
Signed-off-by: Rajneesh Bhardwaj
Change-Id: Ie993f9b99553d46c48c60a5a1c054de0d923bc86
---
arch/x86/configs/rock-dbg_defconfig | 53
We have been working on a prototype supporting CRIU (Checkpoint/Restore
In Userspace) for accelerated compute applications running on AMD GPUs
using ROCm (Radeon Open Compute Platform). We're happy to finally share
this work publicly to solicit feedback and advice. The end-goal is to
get this work
Am 2021-04-28 um 11:11 a.m. schrieb Eric Huang:
> In NPS4 BIOS we need to find the closest numa node when creating
> topology io link between cpu and gpu, if PCI driver doesn't set
> it.
>
> Signed-off-by: Eric Huang
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 94 ++-
[AMD Official Use Only - Internal Distribution Only]
I'll fix the dpcd part to use kHz on Monday
My apologies as well, not only for coming up with the wrong patch in first
place, but also for missing to CC all the maintainers.
-Original Message-
From: Lyude Paul
Sent: Friday, April
Alright - I had Ville double check this and give their A-B on IRC (I just need
to fix the open coded link_rate_to_bw() here). Since this got broken on drm-
misc-next I'm going to go ahead and push the fix there, since I'm not going to
be around next Monday or Tuesday and I don't want to leave i915
Am 2021-04-30 um 4:51 p.m. schrieb Jonathan Kim:
> As pci_atomics_device_to_root check is a host to device support check,
> the device xgmi hive setup status is irrelevant to setting the NO_ATOMICS
> gpu flags so move it under the correct host-device check condition.
I think that's still not
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
v2:
- Use local variabale for improved code readability
- Fix the comment to point to the correct sub-directory
Nikola Cornij (1):
drm/i915: Use the
Reviewed-by: Oak Zeng
Regards,
Oak
On 2021-04-30, 5:10 AM, "amd-gfx on behalf of Felix Kuehling"
wrote:
This function is only used in this source file.
Reported-by: kernel test robot
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2
On Fri, 2021-04-30 at 17:22 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
>
[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.
[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.
Fixes: 98025a62cb00 ("drm/dp_mst: Use
This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.
Change history:
v1:
- Initial
Nikola Cornij (1):
drm/dp_mst: Use the correct max source link rate for i915
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
1 file changed, 2
As pci_atomics_device_to_root check is a host to device support check,
the device xgmi hive setup status is irrelevant to setting the NO_ATOMICS
gpu flags so move it under the correct host-device check condition.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 --
[AMD Public Use]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, on the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Friday, April 30, 2021 2:55 PM
> To: Zeng, Oak ; Kim, Jonathan
> ; amd-gfx@lists.freedesktop.org; Cornwall, Jay
>
> Cc: Errabolu, Ramesh
> Subject: Re: [PATCH] drm/amdkfd: report
Am 2021-04-30 um 2:16 p.m. schrieb Zeng, Oak:
> Sorry I should be clearer.
>
> dev->gpu->pci_atomic_requested is set to the value of
> adev->have_atomics_support - see function amdgpu_amdkfd_have_atomics_support.
> adev->have_atomics_support is set through function
>
From: Tom Rix
Static analysis reports this problem
amdgpu_pm.c:478:16: warning: The right operand of '<' is a garbage value
for (i = 0; i < data.nums; i++) {
^ ~
In some cases data is not set. Initialize to 0 and flag not setting
data as an error with the existing
Sorry I should be clearer.
dev->gpu->pci_atomic_requested is set to the value of
adev->have_atomics_support - see function amdgpu_amdkfd_have_atomics_support.
adev->have_atomics_support is set through function
pci_enable_atomic_ops_to_root currently in amdgpu_device_init - I don't think
this
[AMD Official Use Only - Internal Distribution Only]
Thanks, Felix. The change looks good for me.
--Zhigang
-Original Message-
From: Kuehling, Felix
Sent: April 30, 2021 1:45 PM
To: Luo, Zhigang ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/1] drm/amdgpu: Add a new device ID
It just took me two minutes to do this myself. The commit is up for
review on Gerrit:
http://gerrit-git.amd.com/c/compute/ec/libhsakmt/+/518573. Please review
and test this.
Regards,
Felix
Am 2021-04-29 um 2:46 p.m. schrieb Luo, Zhigang:
> [AMD Official Use Only - Internal Distribution Only]
On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 04:34:55PM -0400, Andrey Grodzovsky wrote:
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
Vangogh follows other APUs, but also allows core clock adjustments.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
APUs only support adjusting the SCLK domain.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 4e459ef632ef..cbd38f2be958 100644
---
On 4/30/21 10:26, Deucher, Alexander wrote:
> [AMD Public Use]
>
> + Gustavo, amd-gfx
>
>> -Original Message-
>> From: Christian Zigotzky
>> Sent: Friday, April 30, 2021 8:00 AM
>> To: gustavo...@kernel.org; Deucher, Alexander
>>
>> Cc: R.T.Dickinson ; Darren Stevens > zone.net>;
On 2021-04-30 2:47 a.m., Christian König wrote:
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,
[AMD Public Use]
+ Gustavo, amd-gfx
> -Original Message-
> From: Christian Zigotzky
> Sent: Friday, April 30, 2021 8:00 AM
> To: gustavo...@kernel.org; Deucher, Alexander
>
> Cc: R.T.Dickinson ; Darren Stevens zone.net>; mad skateman ; linuxppc-dev
> ; Olof Johansson ;
> Maling
Series is Tested-by: Nirmoy Das
On 4/27/21 12:54 PM, Christian König wrote:
Now that we found the underlying problem we can re-apply this patch.
This reverts commit 867fee7f8821ff42e7308088cf0c3450ac49c17c.
v2: rebase on KFD changes
Signed-off-by: Christian König
---
Am 30.04.21 um 16:57 schrieb Felix Kuehling:
Am 2021-04-30 um 9:50 a.m. schrieb Christian König:
Am 30.04.21 um 15:45 schrieb Felix Kuehling:
Am 2021-04-30 um 4:54 a.m. schrieb Christian König:
Am 30.04.21 um 10:32 schrieb Felix Kuehling:
Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
Am 2021-04-30 um 9:50 a.m. schrieb Christian König:
>
>
> Am 30.04.21 um 15:45 schrieb Felix Kuehling:
>> Am 2021-04-30 um 4:54 a.m. schrieb Christian König:
>>>
>>> Am 30.04.21 um 10:32 schrieb Felix Kuehling:
Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
> Now that we found the
The current DP MST hotplug handling sequence adds new remote
sinks during the MST plug-in, but it doesn't removes it during
the unplug, which results into saturation of sink count after
2 contineous hotplugs (dual monitor scenario).
This patch adds a clean-up sequence during the hot-unplug
The current DP MST hotplug handling sequence adds new remote
sinks during the MST plug-in, but it doesn't removes it during
the unplug, which results into saturation of sink count after
2 contineous hotplugs (dual monitor scenario).
This patch adds a clean-up sequence during the hot-unplug
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
Changes from v1:
- Rebased on latest drm-misc-next tag
---
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v2:
- Rebased on current drm-misc-next
Changes from v1:
- New patch
---
ping...
On 2021-04-28 11:11 a.m., Eric Huang wrote:
In NPS4 BIOS we need to find the closest numa node when creating
topology io link between cpu and gpu, if PCI driver doesn't set
it.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 94 ++-
1
Am 30.04.21 um 15:45 schrieb Felix Kuehling:
Am 2021-04-30 um 4:54 a.m. schrieb Christian König:
Am 30.04.21 um 10:32 schrieb Felix Kuehling:
Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
Now that we found the underlying problem we can re-apply this patch.
This reverts commit
Am 2021-04-30 um 4:54 a.m. schrieb Christian König:
>
>
> Am 30.04.21 um 10:32 schrieb Felix Kuehling:
>> Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
>>> Now that we found the underlying problem we can re-apply this patch.
>>>
>>> This reverts commit
Fix below htmldocs build warning:
"warning: Excess function parameter 'vm_context' description in
'amdgpu_vm_init'"
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
On 2021-04-29 10:50 p.m., 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 couple
Am 30.04.21 um 15:32 schrieb Nirmoy Das:
Fix below htmldocs build warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2808:
warning: Excess function parameter 'vm_context' description in 'amdgpu_vm_init'
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
Fix below htmldocs build warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2808:
warning: Excess function parameter 'vm_context' description in 'amdgpu_vm_init'
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On 4/30/21 2:56 PM, Christian König wrote:
Hi,
Am 30.04.21 um 14:52 schrieb Rodrigo Siqueira:
Hi,
On 04/30, Nirmoy Das wrote:
Fixes: 49020fc1f5("drm/amdgpu: cleanup amdgpu_vm_init()")
Just for curiosity, do we need the Fixes tag for this?
It's indeed a bit overkill.
The purpose of the
Lgtm
Reviewed-by: Rodrigo Siqueira
On 04/30, Felix Kuehling wrote:
> This function is only used in this source file.
>
> Reported-by: kernel test robot
> Signed-off-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Hi,
Am 30.04.21 um 14:52 schrieb Rodrigo Siqueira:
Hi,
On 04/30, Nirmoy Das wrote:
Fixes: 49020fc1f5("drm/amdgpu: cleanup amdgpu_vm_init()")
Just for curiosity, do we need the Fixes tag for this?
It's indeed a bit overkill.
The purpose of the Fixes tag is to mark bug fixes for specific
Hi,
On 04/30, Nirmoy Das wrote:
> Fixes: 49020fc1f5("drm/amdgpu: cleanup amdgpu_vm_init()")
Just for curiosity, do we need the Fixes tag for this?
How about adding the warning/error message that this patch fixes? I
think this can be useful for other people searching for a similar fix in
the git
Fixes: 49020fc1f5("drm/amdgpu: cleanup amdgpu_vm_init()")
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index dae51992c607..f2513be72980
Hello Pekka,
On 30/04/21 15:13, Pekka Paalanen wrote:
> On Wed, 28 Apr 2021 13:24:27 +0530
> Shashank Sharma wrote:
>
>> Assuming these details, A compositor will look for DRM color properties like
>> these:
>>
>> 1. Degamma plane property : To make buffers linear for Gamut mapping
>>
>> 2.
On Thu, Apr 29, 2021 at 04:34:55PM -0400, Andrey Grodzovsky wrote:
>
>
> 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
[AMD Public Use]
Please remove the redundant aisc type check: adev->asic_type == CHIP_VEGA20.
The board ID should be good enough for this case.
Other than that, the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Stanley.Yang
Sent: Friday, April 30,
On Wed, 28 Apr 2021 13:24:27 +0530
Shashank Sharma wrote:
> Assuming these details, A compositor will look for DRM color properties like
> these:
>
> 1. Degamma plane property : To make buffers linear for Gamut mapping
>
> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020
This function is only used in this source file.
Reported-by: kernel test robot
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
On Mon, 26 Apr 2021 22:08:55 +0300
Ville Syrjälä wrote:
> On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote:
> > On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
> > > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> > >> From: Bhawanpreet Lakha
> > >>
> > >> Add
Am 30.04.21 um 10:32 schrieb Felix Kuehling:
Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
Now that we found the underlying problem we can re-apply this patch.
This reverts commit 867fee7f8821ff42e7308088cf0c3450ac49c17c.
v2: rebase on KFD changes
Signed-off-by: Christian König
Am 2021-04-27 um 6:54 a.m. schrieb Christian König:
> Now that we found the underlying problem we can re-apply this patch.
>
> This reverts commit 867fee7f8821ff42e7308088cf0c3450ac49c17c.
>
> v2: rebase on KFD changes
>
> Signed-off-by: Christian König
Acked-by: Felix Kuehling
> ---
>
[AMD Official Use Only - Internal Distribution Only]
Maybe the title can be more specific like:
drm/amdgpu: force enable gfx ras in hw_support for vega20 ws
With above modified.
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Stanley.Yang
Sent: Friday, April 30,
Screen flickers rapidly when two 4K 60Hz monitors are in use. 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 indication, we found
On Thu, 29 Apr 2021, Lyude Paul wrote:
> JFYI Jani and Ben: I will be pushing this patch to drm-misc-next sometime
> today if there's no objections
Thanks for the heads-up, I think this breaks i915. See my review
comments elsewhere in the thread.
BR,
Jani.
>
> On Wed, 2021-04-28 at 19:43
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
---
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.
78 matches
Mail list logo
