Hi Mark,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc4 next-20210604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Am 2021-06-04 um 7:10 p.m. schrieb Philip Yang:
> prange->offset is for VRAM range mm_nodes, if multiple ranges share same
> mm_nodes, migrate range back to VRAM will reuse the VRAM at offset of
> the same mm_nodes. For system memory pages_addr array, the offset is
> always 0, otherwise, update
prange->offset is for VRAM range mm_nodes, if multiple ranges share same
mm_nodes, migrate range back to VRAM will reuse the VRAM at offset of
the same mm_nodes. For system memory pages_addr array, the offset is
always 0, otherwise, update GPU mapping will use incorrect system memory
page, and
On 2021-06-04 1:01 p.m., Mark Yacoub wrote:
> From: Mark Yacoub
>
> For each CRTC state, check the size of Gamma and Degamma LUTs so
> unexpected and larger sizes wouldn't slip through.
>
> TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
>
> Signed-off-by: Mark Yacoub
> Change-Id:
On 2021-06-04 4:07 p.m., Alex Deucher wrote:
> Unused so remove them.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git
Unused so remove them.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dio_link_encoder.c
Hi Mark,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc4 next-20210604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
In SRIOV environment, KMD should access SDMA registers
with RLCG if GC indirect access flag enabled.
Using _SOC15 read/write macros ensures that they go
through RLC when the flag is enabled.
Signed-off-by: Rohit Khaire
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 70 +-
On 2021-06-04 2:16 p.m., Alex Deucher wrote:
Missing proper DC_FP_START/DC_FP_END.
Signed-off-by: Alex Deucher
Thanks for catching these.
Series is Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
---
.../drm/amd/display/dc/dcn31/dcn31_resource.c | 18 +-
Missing proper DC_FP_START/DC_FP_END.
Signed-off-by: Alex Deucher
---
.../drm/amd/display/dc/dcn31/dcn31_resource.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
Port the necessary changes from previous DCN versions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
On Fri, Jun 4, 2021 at 7:11 AM Christian König
wrote:
>
> Am 03.06.21 um 18:09 schrieb Liam Howlett:
> > Use vma_lookup() to find the VMA at a specific address. As vma_lookup()
> > will return NULL if the address is not within any VMA, the start address
> > no longer needs to be validated.
> >
>
[Public]
Reviewed-by: Alex Deucher
From: Khaire, Rohit
Sent: Friday, June 4, 2021 12:38 PM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zhang, Hawking ;
Deng, Emily ; Liu, Monk ; Zhou, Peng Ju
; Chen, Horace
Cc: Ming, Davis ; Khaire, Rohit ;
In SRIOV environment, KMD should access GC registers
with RLCG if GC indirect access flag enabled.
Using _SOC15 read/write macros ensures that they go
through RLC when flag is enabled.
Signed-off-by: Rohit Khaire
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c | 42 +--
1
The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.
$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480
Add semicolons to the __assign_str() uses without semicolon
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Rohit Khaire
Sent: Friday, June 4, 2021 11:24 AM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zhang, Hawking ;
Deng, Emily ; Liu, Monk ; Zhou, Peng Ju
; Chen, Horace
Cc: Ming, Davis
Enable this only for Sienna Cichild
since only Navi12 and Sienna Cichlid support SRIOV
Signed-off-by: Rohit Khaire
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
On Fri, Jun 4, 2021 at 3:08 PM Rohit Khaire wrote:
>
> In SRIOV environment, KMD should access SDMA registers
> with RLCG if GC indirect access flag enabled.
>
> Using _SOC15 read/write macros ensures that they go
> through RLC when the flag is enabled.
>
> Signed-off-by: Rohit Khaire
The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.
$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480
Add semicolons to the __assign_str() uses without semicolon
[AMD Official Use Only]
Thanks. I will fix that check.
Rohit
From: Deucher, Alexander
Sent: June 4, 2021 10:56 AM
To: Khaire, Rohit ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking ; Deng, Emily ; Liu, Monk
; Zhou, Peng Ju ; Chen, Horace
Cc: Ming, Davis ; Koenig, Christian
Subject: Re:
[AMD Official Use Only]
checks should be adev->asic_type >= CHIP_SIENNA_CICHLID so we cover other
gfx10.3 asics as well. With that fixed:
Reviewed-by: Alex Deucher
From: Khaire, Rohit
Sent: Friday, June 4, 2021 10:49 AM
To: amd-gfx@lists.freedesktop.org ;
RLC_CP_SCHEDULERS and RLC_SPARE_INT0 have different
offsets for Sienna Cichlid
Signed-off-by: Rohit Khaire
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
Thanks Evan and Lijo. Keep in mind that the ASIC dependent DWORD with those
bits is still being kept. That said, I have no problem with listing them out
separately in the new field as well. I'll make the ASICs that don't support
VR_MEM1/LIQUID1 map to VR_MEM0/LIQUID0 and not touch the *1 bits.
On 2021-06-04 7:31 a.m., Christian König wrote:
Am 02.06.21 um 21:18 schrieb Eric Huang:
Integrate two generic functions to determine if HDP
flush is needed for all Asics.
Signed-off-by: Eric Huang
Nice work, just one more idea below.
But patch is Reviewed-by: Christian König
either
[AMD Official Use Only]
The policy is defined by our virtualization team to guarantee end user
experience and reduce maintenance work.
Added David, virtualization team architect.
David, could you help to add more comments?
Thanks,
Zhigang
-Original Message-
From: Christian König
On 2021-06-04 9:16 a.m., Werner Sembach wrote:
> convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
> integer had the cases for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
> This commits implements the "active bpc" drm property for the Intel GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
>
On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers
> to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
>
[AMD Official Use Only]
Here is our hypervisor driver compatibility policy:
- Host.y supports Guest.y-1, Guest.y, Guest.y+1
- Guest.y supported by Host.y-1, Host.y,Host.y+1
Host driver had the feature for gfx9 2 years ago. So, this change meet our
compatibility policy.
Thanks,
Applied with the RB fixed.
Thanks!
Alex
On Fri, Jun 4, 2021 at 7:53 AM Chen Li wrote:
>
>
> I met a gpu addr bug recently and the kernel log
> tells me the pc is memcpy/memset and link register is
> radeon_uvd_resume.
>
> As we know, in some architectures, optimized memcpy/memset
> may not
Applied. Thanks!
Alex
On Fri, Jun 4, 2021 at 7:53 AM Chen Li wrote:
>
>
> Also fix some coding issues reported from sparse.
>
> Signed-off-by: Chen Li
> Acked-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
> 1 file changed, 13 insertions(+),
I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764
Since the first read-only property is now implemented for amdgpu and i915 I
wanted to collect some feedback, since the other two read-only properties will
be quite similar, I
This commits implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the
This commits implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
Change-Id: I9d513a38e8ac2af1b4bf802e1feb1a4d726fba4c
---
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
Ignore this patch, in favor of (
https://patchwork.freedesktop.org/series/91023/), which appends the commit
title with drm/amd/display.
On Fri, Jun 4, 2021 at 12:59 PM Mark Yacoub wrote:
> From: Mark Yacoub
>
> For each CRTC state, check the size of Gamma and Degamma LUTs so
> unexpected and
Applied. Thanks!
Alex
On Fri, Jun 4, 2021 at 3:03 AM Christian König
wrote:
>
> Am 03.06.21 um 05:28 schrieb Wan Jiabing:
> > Fix following coccicheck warning:
> > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1726:2-3: Unneeded semicolon
> >
> > Signed-off-by: Wan Jiabing
>
> Reviewed-by:
Applied. Thanks!
Alex
On Fri, Jun 4, 2021 at 1:05 AM Gustavo A. R. Silva
wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link:
On 6/4/2021 3:28 PM, Evan Quan wrote:
On driver loading, the ASIC is in D0 state. The bundled
audio function should be in the same state also.
Change-Id: I136e196be7633e95883a7f6c33963f7583e9bad1
Signed-off-by: Evan Quan
---
V1->V2:
- Lijo: include the code in a seperate API for better
On 6/4/2021 3:28 PM, Evan Quan wrote:
For some ASICs, the real dpm feature disablement job is handled by
PMFW during baco reset and custom pptable loading. Cached dpm feature
status need to be cleared to pair that.
Change-Id: I9e37d80e13599833301c04711b097fb37c2e41f9
Signed-off-by: Evan Quan
[Public]
Series is reviewed-by: Evan Quan
From: Lazar, Lijo
Sent: Friday, June 4, 2021 5:12 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Quan, Evan ;
Feng, Kenneth
Subject: [PATCH 3/3] drm/amd/pm: Use generic BACO function for smu11 ASICs
[Public]
Remove ASIC specific
For some ASICs, the real dpm feature disablement job is handled by
PMFW during baco reset and custom pptable loading. Cached dpm feature
status need to be cleared to pair that.
Change-Id: I9e37d80e13599833301c04711b097fb37c2e41f9
Signed-off-by: Evan Quan
---
V1->V2:
- correct the setting for
For BACO scenario, PMFW will handle the dpm features disablement
and interaction with RLC properly. Driver involvement is unnecessary
and error prone.
Change-Id: I19363fc08568be4b7d3f2ec6eba21ccf8fff6c37
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 ++-
1 file
Via the fSMC_MSG_ArmD3 message, PMFW can properly act on the
Dstate change. Driver involvement for determining the timing for
BACO enter/exit is not needed.
Change-Id: Id9ab5e308ff1873888d0acd822c71b0a303fbb01
Signed-off-by: Evan Quan
---
V1->V2:
- limit the changes for Navi1x and
As the fix by adding PPSMC_MSG_PrepareMp1ForUnload is proved to
be incomplete. Another fix(see link below) has been sent out.
Link:
https://lore.kernel.org/linux-pci/20210602021255.939090-1-evan.q...@amd.com/
Change-Id: I2a39688cdf9009885594663cd9ec99d4cfca0088
Signed-off-by: Evan Quan
---
On driver loading, the ASIC is in D0 state. The bundled
audio function should be in the same state also.
Change-Id: I136e196be7633e95883a7f6c33963f7583e9bad1
Signed-off-by: Evan Quan
---
V1->V2:
- Lijo: include the code in a seperate API for better readability
- limit the change for Navi10
Well, but are you the one defining the compatibility policy?
See usually Linux kernel code compatibility policy is that existing
stuff needs to work forever.
We could argue a bit that the hypervisor components are not open source
nor uAPI, but that argument is rather thin.
Christian.
Am
Rev 2: Fix small typo in commit message.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the cases for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git
[Public]
For smuv11, check for VF also during BACO check.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
[Public]
Remove ASIC specific functions for BACO support check. Use generic smu11
function instead.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c| 12 +---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 12 +---
[Public]
Avoid reading BIF STRAP each time for BACO capability. Read the STRAP
value while checking BACO capability in PPTable.
Signed-off-by: Lijo Lazar
---
.../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 25 -
.../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 27
On 2021-06-04 2:33 p.m., Alex Deucher wrote:
> On Fri, Jun 4, 2021 at 3:47 AM Michel Dänzer wrote:
>>
>> On 2021-05-19 3:57 p.m., Alex Deucher wrote:
>>> On Wed, May 19, 2021 at 4:48 AM Michel Dänzer wrote:
On 2021-05-19 12:05 a.m., Alex Deucher wrote:
> On Tue, May 18, 2021 at
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git
Thanks very much. I get it now.
-Original Messages-
From: "Christian König"
Sent Time: 2021-06-04 15:40:08 (Friday)
To: "Chen Lei" , "Alex Deucher"
Cc: "amd-gfx list"
Subject: Re: [BUG] Data race when use PACKET3_DMA_DATA?
Hi,
I think your problem comes from the missing
Am 04.06.21 um 10:43 schrieb Chen Li:
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix
Am 04.06.21 um 10:28 schrieb Chen Li:
On Fri, 04 Jun 2021 16:08:26 +0800,
Christian König wrote:
Am 04.06.21 um 09:53 schrieb Chen Li:
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some
On Fri, Jun 4, 2021 at 3:47 AM Michel Dänzer wrote:
>
> On 2021-05-19 3:57 p.m., Alex Deucher wrote:
> > On Wed, May 19, 2021 at 4:48 AM Michel Dänzer wrote:
> >>
> >> On 2021-05-19 12:05 a.m., Alex Deucher wrote:
> >>> On Tue, May 18, 2021 at 10:11 AM Michel Dänzer wrote:
>
> On
[Public]
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Lazar, Lijo
Sent: Friday, June 4, 2021 14:59
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Feng, Kenneth
; Wang, Kevin(Yang)
Subject: [PATCH] drm/amd/pm: Remove BACO check for aldebaran
[Public]
BACO/MACO is not
Am 03.06.21 um 14:34 schrieb Colin King:
From: Colin Ian King
The variable k is being assigned a value that is never read, the
assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
Reviewed-by: Christian König
---
On Fri, 04 Jun 2021 16:31:28 +0800,
Christian König wrote:
>
>
>
> Am 04.06.21 um 10:28 schrieb Chen Li:
> > On Fri, 04 Jun 2021 16:08:26 +0800,
> > Christian König wrote:
> >>
> >>
> >> Am 04.06.21 um 09:53 schrieb Chen Li:
> >>> I met a gpu addr bug recently and the kernel log
> >>> tells
On Fri, 04 Jun 2021 16:08:26 +0800,
Christian König wrote:
>
>
>
> Am 04.06.21 um 09:53 schrieb Chen Li:
> > I met a gpu addr bug recently and the kernel log
> > tells me the pc is memcpy/memset and link register is
> > radeon_uvd_resume.
> >
> > As we know, in some architectures, optimized
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.
BTW, amdgpu has already
Also fix some coding issues reported from sparse.
Signed-off-by: Chen Li
Acked-by: Christian König
---
drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu
Chen Li (2):
radeon: fix coding issues reported from sparse
radeon: use memcpy_to/fromio for UVD fw upload
drivers/gpu/drm/radeon/radeon_uvd.c | 30
Also fix some coding issues reported from sparse.
Signed-off-by: Chen Li
Acked-by: Christian König
---
drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix this problem.
BTW, amdgpu has already
changelog:
v1->v2: split sparse and memcp/memset fix
v2->v3: fix coding issue and misuse of le32_to_cpu
v3->v4: merge memcpy_toio's arguments to one line
Chen Li (2):
radeon: fix coding issues reported from sparse
radeon: use memcpy_to/fromio for UVD fw upload
Am 02.06.21 um 21:18 schrieb Eric Huang:
Integrate two generic functions to determine if HDP
flush is needed for all Asics.
Signed-off-by: Eric Huang
Nice work, just one more idea below.
But patch is Reviewed-by: Christian König
either way if you implement that or not.
---
I was just about to question the same thing.
It looks really good to me to have that cleaned up, but if this breaks
with older versions of the hypervisor then it is a bit questionable change.
Regards,
Christian.
Am 04.06.21 um 03:13 schrieb Deng, Emily:
Do we need to consider backward
Am 03.06.21 um 18:09 schrieb Liam Howlett:
Use vma_lookup() to find the VMA at a specific address. As vma_lookup()
will return NULL if the address is not within any VMA, the start address
no longer needs to be validated.
Signed-off-by: Liam R. Howlett
Reviewed-by: Christian König
---
[Public]
BACO/MACO is not applicable for aldebaran. Remove the redundant check.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
[AMD Official Use Only]
This patch looks good to me.
Reviewed-by: Dennis Li
-Original Message-
From: Zhang, Hawking
Sent: Friday, June 4, 2021 12:58 PM
To: amd-gfx@lists.freedesktop.org; Li, Dennis ; Deucher,
Alexander ; Kuehling, Felix
Cc: Zhang, Hawking
Subject: [PATCH]
Follow the same apporach as GFX to handle SDMA
poison consumption. Send SIGBUS to application
when receives SDMA_ECC interrupt and issue gpu
reset either mode 2 or mode 1 to get the engine
back
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 7 ++-
[AMD Official Use Only]
A modified version of 2 -
List all the possible ones and merge those which mean the same - ex:
terminology changes like THM and TEMP.
In the mail earlier, I meant to list them out separately as the intention is to
convey the throttle reason to the user- it's
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, June 3, 2021 7:04 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 4/5] drm/amd/pm: clear the cached dpm feature status
>
>
>
> On 6/3/2021 10:26 AM,
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Thursday, June 3, 2021 7:09 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 3/5] drm/amdgpu: correct the audio function initial
> Dstate
>
>
>
> On 6/3/2021
Am 04.06.21 um 09:53 schrieb Chen Li:
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix
On 2021-05-19 3:57 p.m., Alex Deucher wrote:
> On Wed, May 19, 2021 at 4:48 AM Michel Dänzer wrote:
>>
>> On 2021-05-19 12:05 a.m., Alex Deucher wrote:
>>> On Tue, May 18, 2021 at 10:11 AM Michel Dänzer wrote:
On 2021-05-17 11:33 a.m., xgqt wrote:
> Hello!
>
> I run a AMD
Hi,
I think your problem comes from the missing understanding that the
hardware is heavily pipelined.
In other words commands you send to the hardware just kick of
asynchronously processing, e.g. a CP DMA command just kicks a copy
operation but the CP then continue executing commands.
On 2021-06-03 10:53 p.m., Alex Deucher wrote:
On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie wrote:
On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote:
Please open a gitlab MR for these.
I'd really prefer these tests all get migrated out of here into igt. I
don't think libdrm_amdgpu really
Am 04.06.21 um 05:04 schrieb Chen Li:
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory. Trival memcpy_toio/memset_io
can fix
Am 04.06.21 um 05:02 schrieb Chen Li:
Also fix some coding issue reported from sparse.
Signed-off-by: Chen Li
Acked-by: Christian König
---
drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git
Am 03.06.21 um 05:28 schrieb Wan Jiabing:
Fix following coccicheck warning:
./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1726:2-3: Unneeded semicolon
Signed-off-by: Wan Jiabing
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1
[AMD Official Use Only]
Thanks Lijo and Graham. Yes, I know that only some specific ASICs support
VR_MEM1 and LIQUID1.
However, the problem is about the design:
1. should we just list those which are commonly supported by all ASICs.
2. Or we list all the possible throttlers and mask out those
88 matches
Mail list logo
