On 2021-07-13 10:01 p.m., Quan, Evan wrote:
> [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
Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
image that looks like it has an effective resolution of 1920x1080 but
scaled up in
Hi Eric,
feel free to push into amd-staging-dkms-5.11, but please don't push it
into amd-staging-drm-next.
The later will just cause a merge failure which Alex needs to resolve
manually.
I can take care of pushing to amd-staging-drm-next as soon as that is
rebased on latest upstream.
Reg
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> 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-only or
> PROT_NONE mappings.
>
> v2: prot
On Wed, Jul 14, 2021 at 12:44:00PM +0200, Daniel Vetter wrote:
> On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> > 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 mm
On Wed, Jul 14, 2021 at 12:51:15PM +0200, Christian König wrote:
> Am 14.07.21 um 12:44 schrieb Daniel Vetter:
> > On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> > > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > > is_cow_mapping returns true for these mapping
Am 13.07.21 um 18:11 schrieb Felix Kuehling:
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 fallin
Am 14.07.21 um 11:41 schrieb Pan, Xinhui:
2021年7月14日 16:33，Christian König 写道：
Hi Eric,
feel free to push into amd-staging-dkms-5.11, but please don't push it into
amd-staging-drm-next.
The later will just cause a merge failure which Alex needs to resolve manually.
I can take care of pushin
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_WARN printing for this.
[drm:amdg
Am 13.07.21 um 17:28 schrieb Alex Deucher:
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
This patch is to update the golden setting for vangogh.
Signed-off-by: Xiaojian Du
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 705fa3027199..9144836798c5 1006
> 2021年7月14日 16:33，Christian König 写道：
>
> Hi Eric,
>
> feel free to push into amd-staging-dkms-5.11, but please don't push it into
> amd-staging-drm-next.
>
> The later will just cause a merge failure which Alex needs to resolve
> manually.
>
> I can take care of pushing to amd-staging-dr
On Tue, Jul 13, 2021 at 6:31 AM Peng Ju Zhou wrote:
>
> 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.
Am 14.07.21 um 12:44 schrieb Daniel Vetter:
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
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-on
On Tue, Jul 13, 2021 at 11:30 AM Andrey Grodzovsky
wrote:
>
> Update callback signature and update implementation.
>
> Signed-off-by: Andrey Grodzovsky
I think the order of patches 1 and 2 should be flipped or maybe they
should be squashed together to avoid breaking the interface in the
interim
On Mon, Jul 12, 2021 at 10:56 PM 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
On Tue, Jul 13, 2021 at 10:01 PM Quan, Evan wrote:
>
> [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
Am 14.07.21 um 17:25 schrieb Oak Zeng:
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware
On Wed, Jul 14, 2021 at 11:25 AM Oak Zeng wrote:
>
> The printing message "PSP loading VCN firmware" is mis-leading because
> people might think driver is loading VCN firmware. Actually when this
> message is printed, driver is just preparing some VCN ucode, not loading
> VCN firmware yet. The act
On Wed, Jul 14, 2021 at 11:25 AM Oak Zeng wrote:
>
> Function name "psp_np_fw_load" is not proper as people don't
> know _np_fw_ means "non psp firmware". Change the function
> name to psp_load_non_psp_fw for better understanding. Same
> thing for function psp_execute_np_fw_load.
>
> Signed-off-by
Am 14.07.21 um 13:15 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 12:51:15PM +0200, Christian König wrote:
Am 14.07.21 um 12:44 schrieb Daniel Vetter:
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
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 direct
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
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
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
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
[AMD Official Use Only]
Hi Guchun,
This patch looks good to me.
Regards
Stylon Wang
MTS Software Development Eng. | AMD
Display Solution Team
O +(886) 2-3789-3667 ext. 23667 C +(886) 921-897-142
-
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
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 fro
Am 30.06.21 um 17:10 schrieb Werner Sembach:
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++
Am 06.07.21 um 09:09 schrieb Pekka Paalanen:
On Mon, 5 Jul 2021 17:49:42 +0200
Werner Sembach wrote:
Am 01.07.21 um 15:24 schrieb Pekka Paalanen:
On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach wrote:
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:20:18 +0200
We
Am 01.07.21 um 13:30 schrieb Werner Sembach:
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach wrote:
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
Am 28.06.21 um 19:03 schrieb Werner Se
Am 30.06.21 um 17:10 schrieb Werner Sembach:
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
[AMD Official Use Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Xiaojian Du
Sent: Wednesday, July 14, 2021 5:32 AM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Du, Xiaojian
Subject: [PATCH] drm/amdgpu: update the golden setting for vangogh
From: Colin Ian King
Struct element usTMax is being assigned a hard coded value that
is never read and it is being re-assigned a new value immediately
afterwards. The assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/
On 2021-07-14 4:39 a.m., Guchun Chen wrote:
> 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 pr
Hi Felix,
I was not able to reproduce the VM fault issue of SWDEV-249241, which is
the only regression reported on MI200. So the patch is valid to review.
Please take a look.
Thanks,
Eric
On 2021-07-09 1:45 a.m., Chen, Guchun wrote:
[Public]
Original patch will cause regressions on Aldebar
Correction inline.
On 2021-07-14 11:22 a.m., Eric Huang wrote:
Hi Felix,
I was not able to reproduce the VM fault issue of SWDEV-292611(not
SWDEV-249241), which is the only regression reported on MI200. So the
patch is valid to review. Please take a look.
Thanks,
Eric
On 2021-07-09 1:45 a.
Function name "psp_np_fw_load" is not proper as people don't
know _np_fw_ means "non psp firmware". Change the function
name to psp_load_non_psp_fw for better understanding. Same
thing for function psp_execute_np_fw_load.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 16 +
Oak Zeng (3):
drm/amdkfd: Disallow debugfs to hang hws when GPU is resetting
drm/amdgpu: Fix a printing message
drm/amdgpu: Change a few function names
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 16
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/
The printing message "PSP loading VCN firmware" is mis-leading because
people might think driver is loading VCN firmware. Actually when this
message is printed, driver is just preparing some VCN ucode, not loading
VCN firmware yet. The actual VCN firmware loading will be in the PSP block
hw_init. F
If GPU is during a resetting cycle, writing to GPU can cause
unpredictable protection fault, see below call trace. Disallow using kfd debugfs
hang_hws to hang hws if GPU is resetting.
[12808.234114] general protection fault: [#1] SMP NOPTI
[12808.234119] CPU: 13 PID: 6334 Comm: tee Tainted: G
Am 2021-07-08 um 3:53 p.m. schrieb Eric Huang:
> It is to workaround HW bug on other Asics and based on
> reverting two commits:
> drm/amdkfd: Add heavy-weight TLB flush after unmapping
> drm/amdkfd: Add memory sync before TLB flush on unmap
>
> Signed-off-by: Eric Huang
Reviewed-by: Felix Ku
Am 2021-07-14 um 11:25 a.m. schrieb Oak Zeng:
> If GPU is during a resetting cycle, writing to GPU can cause
> unpredictable protection fault, see below call trace. Disallow using kfd
> debugfs
> hang_hws to hang hws if GPU is resetting.
>
> [12808.234114] general protection fault: [#1] SMP N
Am 2021-07-14 um 6:51 a.m. schrieb Christian König:
> Am 14.07.21 um 12:44 schrieb Daniel Vetter:
>> On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
>>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
>>> is_cow_mapping returns true for these mappings. Add a check for
Hi! As some of you might already be aware, after helping out X.org
project the previous years with regards to student outreach, Trevor
decided to retire from this position in hopes that someone else will be
able to step up and take on these responsibilities. As such, we're
trying to find people who
On 2021-07-14 11:22 a.m., Alex Deucher wrote:
> On Tue, Jul 13, 2021 at 10:01 PM Quan, Evan wrote:
>> [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: Deuch
On 2021-07-14 11:19 a.m., Alex Deucher wrote:
> On Mon, Jul 12, 2021 at 10:56 PM 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
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
On platforms that support multiple backlights, register
each one separately. This lets us manage them independently
rather than registering a single backlight and applying the
same settings to both.
v2: fix typo:
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/a
On Tue, Jul 13, 2021 at 10:40:30AM -0400, Alex Deucher wrote:
> 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_PROTECTI
Hi Dave, Daniel,
Fixes for 5.14. The big change here is unifying the SMU13 code. This was
new code added in 5.14 to support Yellow Carp, but we've since cleaned it
up and removed a lot of duplication, so better to merge it now to facilitate
any bug fixes in the future that need to go back to thi
[AMD Official Use Only]
Reviewed-by: Monk Liu
You might need @Liu, Leo's review as well
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wedne
Hi Alex,
On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Fixes for 5.14. The big change here is unifying the SMU13 code. This was
> new code added in 5.14 to support Yellow Carp, but we've since cleaned it
> up and removed a lot of duplication, so better to
[Public]
Hi Alex,
Is DRM_DEV_INFO more suitable than dev_info as far as DRM subsystem is
concerned? Thanks!
Regards,
Jiansong
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, July 14, 2021 11:48 PM
To: Zeng, Oak
Cc: Xu, Feifei ; Kuehling, Felix ;
Liu, Leo ;
[Public]
I think it's more consistent to use dev_info since we already use that pretty
extensively in the driver.
Alex
From: amd-gfx on behalf of Chen,
Jiansong (Simon)
Sent: Wednesday, July 14, 2021 10:51 PM
To: Alex Deucher ; Zeng, Oak
Cc: Xu, Feifei ; Kue
[Public]
Ok, I see. Thanks!
Regards,
Jiansong
From: Deucher, Alexander
Sent: Thursday, July 15, 2021 10:55 AM
To: Chen, Jiansong (Simon) ; Alex Deucher
; Zeng, Oak
Cc: Xu, Feifei ; Kuehling, Felix ;
Liu, Leo ; amd-gfx list ;
Zhang, Hawking
Subject: Re: [PATCH 2/3] drm/amdgpu: Fix a printing
54 matches
Mail list logo
