[AMD Official Use Only]
> -Original Message-
> From: Tuikov, Luben
> Sent: Wednesday, July 14, 2021 1:36 AM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Alimucaj, Andi
> ; Baluja, Aaron
> Subject: Re: [PATCH] drm/amd/pm: Fix a bug communicating with the S
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
into register 90 to clear the status (and
subsequen
After reviewing the code, seem like there is a merge issue
and the logic of the code does not make any sense anymore
The code has been rewritten for single VCN enablement
Change-Id: I2c3d0bf6d7d446e2a014c83ee535b3c4bf20abf9
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
After reviewing the code, seem like there is a merge issue
and the logic of the code does not make any sense anymore
The code has been rewritten for single VCN enablement
Signed-off-by: Bokun Zhang
Change-Id: I44f3346717c418c0d66afe3da93de1275978acc5
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
Hi Christian/Felix,
If you don't have objection, it will be pushed into
amd-staging-dkms-5.11 and amd-staging-drm-next.
Thanks,
Eric
On 2021-07-13 3:17 p.m., Eric Huang wrote:
For allocations larger than 48MiB we need more than a page for the
housekeeping in the worst case resulting in the u
For allocations larger than 48MiB we need more than a page for the
housekeeping in the worst case resulting in the usual vmalloc overhead.
Try to avoid this by assuming the good case and only falling back to the
worst case if this didn't worked.
Signed-off-by: Christian König
Signed-off-by: Eric
[AMD Official Use Only]
Reviewed-by: James Zhu for the series
James Zhu
From: Gopalakrishnan, Veerabadhran (Veera)
Sent: Tuesday, July 13, 2021 2:48 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Leo ; Zhu, James ; Zhang, Boyuan
; Rao, Srinath ; Gopalakrishna
From: Veerabadhran Gopalakrishnan
Optimized the code for codec info structure initialization
Signed-off-by: Veerabadhran Gopalakrishnan
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 7 +
drivers/gpu/drm/amd/amdgpu/nv.c | 223
drivers/gpu/drm/amd/amdgpu/soc15.c |
From: Veerabadhran Gopalakrishnan
Patch 1 - Added the list of supported codecs for yellow carp in the codec query.
Patch 2 - Code optimization for the codec info structure initialization.
Veerabadhran Gopalakrishnan (2):
amdgpu/nv.c - Added video codec support for Yellow Carp
amdgpu/nv.c - O
From: Veerabadhran Gopalakrishnan
Added the supported codecs in the video capabilities query.
Signed-off-by: Veerabadhran Gopalakrishnan
---
drivers/gpu/drm/amd/amdgpu/nv.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
On 2021-07-13 3:07 a.m., Quan, Evan wrote:
> [AMD Official Use Only]
>
>
>
>> -Original Message-
>> From: Tuikov, Luben
>> Sent: Monday, July 12, 2021 11:31 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Tuikov, Luben ; Deucher, Alexander
>> ; Quan, Evan
>> Subject: [PATCH] drm/amd/pm: Fi
I am converting codes into amd-staging-drm-next. Theoretically it will
improve a lot on the latency, the size of the array allocated is 24
(PAGE_SIZE/struct drm_mm_node) with this patch, and it was 8192 before.
So the latency should be reduced by 98 us.
Regards,
Eric
On 2021-07-13 12:11 p.m.,
On 2021-07-12 10:56 p.m., Lazar, Lijo wrote:
>
> On 7/12/2021 9:00 PM, Luben Tuikov wrote:
>> This fixes a bug which if we probe a non-existing
>> I2C device, and the SMU returns 0xFF, from then on
>> we can never communicate with the SMU, because the
>> code before this patch reads and interprets
Am 2021-07-13 um 9:32 a.m. schrieb Christian König:
> For allocations larger than 48MiB we need more than a page for the
> housekeeping in the worst case resulting in the usual vmalloc overhead.
>
> Try to avoid this by assuming the good case and only falling back to the
> worst case if this didn't
Update callback signature and update implementation.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 6 ++--
drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 41 -
2 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/a
Add USBC PD FW implementation here to be used with relevant ASICs.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 66 ++
1 file changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_
System memory-based implementation for updating the
USBCPD is deprecated for switching
to LFB based implementation for all the ASICs.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 33 ++---
1 file changed, 13 insertions(+), 20 deletions(-)
di
Am 2021-07-13 um 2:57 a.m. schrieb Christian König:
>
>
> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
>> is_cow_mapping returns true for these mappings. Add a check for
>> vm_flags & VM_WRITE to avoid mmap failures on private read-o
The display core files rely on FPU operation, which requires to be
compiled with special flags. Ideally, we don't want these FPU operations
spread around the DC code; nevertheless, it happens in the current
source. This commit introduces a new directory named fpu_operations that
intends to centrali
DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the access to
kernel_fpu_begin/end.
Change since V1:
Hi,
In the display core, we utilize floats and doubles units for calculating
modesetting parameters. One side effect of our approach to use double-precision
is the fact that we spread multiple FPU access across our driver, which means
that we can accidentally clobber user space FPU state.
# Chall
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mechanism inside our DC_FP_START/END macros for
trying to alleviate this problem.
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/
To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface from other files, the compiler
might enable the use
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
>
>
>
> Am 13.07.21 um 00:06 schrieb Felix Kuehling:
> > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > is_cow_mapping returns true for these mappings. Add a check for
> > vm_flags & VM_WRITE to avoid mmap failures on priva
Zhang, Hawking would like to recall the message, "[PATCH] drm/amdgpu: Resolve
bug in UMC 6.7 UMC error offset".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[AMD Official Use Only]
Yeah, seems like switching the smtp server helps. Someone sents notes to
brahma_sw_dev.
Regards,
Hawking
From: Christian König
Sent: Tuesday, July 13, 2021 19:03
To: Zhang, Hawking ; Clements, John
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Resolv
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index bc4347a72301..a7e03bba72b3 100644
--- a/drivers/gpu/
On Mon, Jul 12, 2021 at 3:18 AM Ketsui wrote:
>
> > So far, so good; no hang in a week. I'll try the rest of the new firmware
> > as well now, will follow up if there's a hang again.
>
> I've noticed that the VM_L2_PROTECTION_FAULT_STATUS error doesn't always
> result in a hang, looking through
The previous logic is recording the amount of valid vcn instances
to use them on SRIOV, it is a hard task due to the vcn accessment is
based on the index of the vcn instance.
Check if the vcn instance enabled before do instance init.
Signed-off-by: Peng Ju Zhou
---
drivers/gpu/drm/amd/amdgpu/vc
[AMD Official Use Only]
Let's submit the quick fix first and then work out better naming styles to fix
confusing
The patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
From: Clements, John
Sent: Tuesday, July 13, 2021 17:37
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking
Subject: [PA
[AMD Official Use Only]
Submitting patch to resolve bug in UMC 6.7 error offset calculation
Thank you,
John Clements
0001-drm-amdgpu-Resolve-bug-in-UMC-6.7-UMC-error-offset-c.patch
Description: 0001-drm-amdgpu-Resolve-bug-in-UMC-6.7-UMC-error-offset-c.patch
_
For allocations larger than 48MiB we need more than a page for the
housekeeping in the worst case resulting in the usual vmalloc overhead.
Try to avoid this by assuming the good case and only falling back to the
worst case if this didn't worked.
Signed-off-by: Christian König
---
drivers/gpu/dr
Reviewed-by: Alex Deucher
On Mon, Jul 12, 2021 at 10:04 PM Jinzhou Su wrote:
>
> Add new PCI device id.
>
> Signed-off-by: Jinzhou Su
> Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/am
[AMD Official Use Only]
From: Christian König
Sent: Tuesday, July 13, 2021 3:11 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Deucher, Alexander
; Min, Frank ; Koenig, Christian
; Zhang, Hawking
Subject: Re: [RFC PATCH v2] drm/a
[Public]
Good point. I will submit a v2 to address it after display team also agrees on
this.
Regards,
Guchun
-Original Message-
From: Chen, Jiansong (Simon)
Sent: Tuesday, July 13, 2021 2:24 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Wang,
Chao-kai (Stylon) ; Kazlauskas, N
On Tue, Jul 13, 2021 at 03:00:57PM +0800, Liu, Aaron wrote:
> Remove mdelay process and use smu_cmn_send_smc_msg_with_param to send
> mode-reset message to SMC.
>
> Signed-off-by: Aaron Liu
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 10 +++---
>
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Aaron Liu
> Sent: Tuesday, July 13, 2021 3:01 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Ray
> ; Liu, Aaron
> Subject: [PATCH] drm/amd/pm: Add waiting for re
[AMD Official Use Only]
> -Original Message-
> From: Tuikov, Luben
> Sent: Monday, July 12, 2021 11:31 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Tuikov, Luben ; Deucher, Alexander
> ; Quan, Evan
> Subject: [PATCH] drm/amd/pm: Fix a bug communicating with the SMU
>
> This fixes a bu
And let me guess you "git send-email" with an AMD address doesn't work
for you either?
I think we need to ping our IT once more.
Regards,
Christian.
Am 13.07.21 um 11:39 schrieb Zhang, Hawking:
[AMD Official Use Only]
Let’s submit the quick fix first and then work out better naming
styles
Remove mdelay process and use smu_cmn_send_smc_msg_with_param to send
mode-reset message to SMC.
Signed-off-by: Aaron Liu
---
drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/yel
[AMD Official Use Only]
Is DRM_WARN more suitable for the case?
Regards,
Jiansong
-Original Message-
From: amd-gfx On Behalf Of Guchun Chen
Sent: Tuesday, July 13, 2021 1:56 PM
To: amd-gfx@lists.freedesktop.org; Wang, Chao-kai (Stylon)
; Kazlauskas, Nicholas ;
Siqueira, Rodrigo ; Yin,
[AMD Official Use Only]
Reviewed-by: Peng Ju Zhou
> -Original Message-
> From: amd-gfx On Behalf Of Sun,
> Roy
> Sent: Thursday, July 8, 2021 6:25 PM
> To: Sun, Roy ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: change the imprecise function name
>
> [AMD Official U
For the unknown CEA parse case on DMUB-enabled ASICs, dmesg will
print an error message like below, this will be captured by
automation tools as it has the word like ERROR during boot up
and treated as a false error, as it does not break bootup process.
So use DRM_INFO printing for this.
[drm:amdg
See below.
Am 13.07.21 um 10:32 schrieb Wang, Kevin(Yang):
[AMD Official Use Only]
*From:* Christian König
*Sent:* Tuesday, July 13, 2021 3:11 PM
*To:* Wang, Kevin(Yang) ;
amd-gfx@lists.freedesktop.org
*Cc:* Lazar,
modification of smu11 files
arcturus_ppt.c
sienna_cichlid_ppt.c
vangogh_ppt.c
=== Test ===
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
LOGFIL
initial modification of files
renoir_ppt.c
aldebaran_ppt.c
yellow_carp_ppt.c
=== Test ===
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
LOGFILE
=== Description ===
Replace usage of sprintf with sysfs_emit in swsmu powerplay
=== Test System ===
* DESKTOP(AMD FX-8350 + NAVI10(731F/ca), BIOS: F2)
+ ISO(Ubuntu 20.04.1 LTS)
+ Kernel(5.11.0-custom-fdoagd5f)
=== Patch Summary ===
linux: (g...@gitlab.freedesktop.org:agd5f) origin/amd-sta
initial modification of files
smu_cmn.c
navi10_ppt.c
=== Test ===
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}
LOGFILE=pp_printf.test.log
lspci
Hello Alex Deucher,
The patch 77bf762f8b30: "drm/amdgpu/acpi: unify ATCS handling (v3)"
from May 19, 2021, leads to the following static checker warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:857 amdgpu_acpi_init()
warn: this array is probably non-NULL. 'dm->backlight_dev'
dri
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 126 +---
1 file changed, 89 insertions(+), 37 deletions(-)
diff --git a/drive
Am 13.07.21 um 05:23 schrieb Kevin Wang:
1. using vram aper to access vram if possible
2. avoid MM_INDEX/MM_DATA is not working when mmio protect feature is
enabled.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 126 +---
1 file changed, 89 inser
On Mon, Jul 12, 2021 at 8:35 PM Alex Deucher wrote:
> On Mon, Jul 12, 2021 at 5:57 AM Tomasz Moń wrote:
> > I am having trouble getting Linux to run on MacBook Pro 2019 with
> > Radeon Pro Vega 20 4 GB. Basically as soon as graphical user interface
> > starts, the whole system freezes. This happe
52 matches
Mail list logo
