On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expression by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: 6d04ee9dc101 ("drm/amd/display: Restructuring and cleaning up DML")
> Cc:
On 2018-12-05 8:40 a.m., Nicholas Kazlauskas wrote:
> [Why]
> When application flip-rate is below the minimum vrr refresh rate.
>
> Variable refresh rate monitors extend the front porch duration until
> flip or timeout occurs. For cases where the application flip-rate is
>
> When the flip-rate
On 1/3/19 1:17 PM, Kuehling, Felix wrote:
On 2019-01-03 12:34 p.m., Gustavo A. R. Silva wrote:
Fix boolean expressions by using logical AND operator '&&'
instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
Fixes: c8c5e569c5b0 ("drm/amdgpu: Consolidate
Fix boolean expressions by using logical AND operator '&&'
instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
Fixes: 9a4b7d4c769e ("drm/amdgpu: Add vm context module param")
Cc: sta...@vger.kernel.org
Reviewed-by: Felix Kuehling
Signed-off-by: Gustavo A. R.
It‘s an end user. That means bisecting isn‘t possible.
— Christian
Sent from my iPhone
> On 3. Jan 2019, at 12:03, Michel Dänzer wrote:
>
>> On 2019-01-01 4:03 p.m., Christian Zigotzky wrote:
>> Hello,
>>
>> An end user reportet that his ATI FirePro 2260 doesn't work anymore with
>> the
On 2019-01-03 12:34 p.m., Gustavo A. R. Silva wrote:
> Fix boolean expressions by using logical AND operator '&&'
> instead of bitwise operator '&'.
>
> This issue was detected with the help of Coccinelle.
>
> Fixes: c8c5e569c5b0 ("drm/amdgpu: Consolidate visible vs. real vram check
> v2.")
Fix boolean expressions by using logical AND operator '&&'
instead of bitwise operator '&'.
This issue was detected with the help of Coccinelle.
Fixes: c8c5e569c5b0 ("drm/amdgpu: Consolidate visible vs. real vram check v2.")
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
---
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
>
> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
>> Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
>>> On 12/21/2018 01:37 PM, Christian König wrote:
Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
> Decauple sched threads stop and
On 2019-01-03 4:59 a.m., Christian König wrote:
> Otherwise we run into a non-retry fault on access.
>
> It seems to be a hardware bug that the executable bit has
> higher priority than the valid bit.
>
> v2: handle clears as well
>
> Signed-off-by: Christian König
> ---
>
On 2018-12-30 2:00 a.m., Yu Zhao wrote:
> Userspace may request pitch alignment that is not supported by GPU.
> Some requests 32, but GPU ignores it and uses default 64 when cpp is
> 4. If GEM object is allocated based on the smaller alignment, GPU
> DMA will go out of bound.
>
> Cc:
On 01/03/2019 03:54 AM, Koenig, Christian wrote:
> Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
>> On 12/21/2018 01:37 PM, Christian König wrote:
>>> Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy
This bug may also be related:
https://bugs.freedesktop.org/show_bug.cgi?id=109206
Alex
From: Koenig, Christian
Sent: Thursday, January 3, 2019 10:57:50 AM
To: Yu, Xiangliang; Xu, Feifei; amd-gfx@lists.freedesktop.org; Deucher,
Alexander
Subject: Re: [PATCH
> For Vega10, could you explain why it block older version fw?
I'm not very familiar with the PSP, so I don't know what exactly is
going wrong here.
Symptoms are that we get the following in dmesg:
> Jan 03 15:55:17 abel kernel: [drm] PSP loading VCE firmware
> Jan 03 15:55:17 abel kernel: [drm]
XGMI command will not load ucode, so it can't find the command failed if check
ucode at first.
For code logic, should check response status to see if command complete
successfully at first.
For Vega10, could you explain why it block older version fw?
-Original Message-
From: Christian
Hi guys,
this patch broke loading older versions of PSP firmware on Vega10.
What exactly is the background here? E.g. why do we need it? And can we
revert it ASAP?
Thanks,
Christian.
Am 18.12.18 um 03:45 schrieb Xu, Feifei:
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Hawking
Zhang
Sent: Thursday, January 3, 2019 9:00:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking
Subject: [PATCH 2/2] drm/amdgpu/psp: make get_fw_type and prep_cmd_buf to be
common
Hi Alex,
I've made a backport of that patch to linux 4.20, but didn't notice
any improvements. It looks like, from the logs with drm debug
messages, that the issue is happening after the ring tests, while
entering X session.
Thanks for your suggestion, anyway. I'll try that again once
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, January 3, 2019 1:06:56 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: hint and error out when prerequisite not
meet
Do not ignore the
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Emily Deng
Sent: Wednesday, January 2, 2019 10:58:37 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] drm/amdgpu/sriov: For finishing routine send rel event after
init failed
When init
On Thu, Jan 3, 2019 at 8:37 AM Russell, Kent wrote:
>
> These 2 variables are unused now, so remove their references.
>
> Fixes: e4ae0fc drm/amdgpu: implement gfx8 post_soft_reset
> Fixes: 5e01c09 drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings
> test sequence
>
> Change-Id:
Does this patch help by any chance?
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next=5e01c09ce3b7263d88873105f21a82eda904664b
Alex
On Thu, Jan 3, 2019 at 7:14 AM Luís Mendes wrote:
>
> Hi Christian, Alex,
>
> I've set the kernel command line with drm.debug=0xf, and I
Otherwise we run into a non-retry fault on access.
It seems to be a hardware bug that the executable bit has
higher priority than the valid bit.
v2: handle clears as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 36 ++
1 file changed,
Just remove some leftovers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 164ffc91b645..57cb3a51bda7 100644
---
On pre-gmc9 PTE prt bit is completely ignored.
Check the OpenGL spec for PRTs, writes needs to be ignored and reads
must return zero.
Not sure about Vulkan and OpenCL.
Christian.
Am 03.01.19 um 10:56 schrieb Zhou, David(ChunMing):
> Doesn't gpu check PTE prt bit first and then access va
Doesn't gpu check PTE prt bit first and then access va range?
Even wrte to dummy page, seem there still is no problem, we don't care that
content at all.
-David
> -Original Message-
> From: Christian König
> Sent: Thursday, January 03, 2019 5:54 PM
> To: Zhou, David(ChunMing) ;
Writes are then not ignored and garbage the dummy page.
Christian.
Am 03.01.19 um 10:46 schrieb Zhou, David(ChunMing):
Seems we don't need two page table, we just map every prt range to dummy page,
any problem?
-David
-Original Message-
From: Zhou, David(ChunMing)
Sent: Thursday,
Seems we don't need two page table, we just map every prt range to dummy page,
any problem?
-David
> -Original Message-
> From: Zhou, David(ChunMing)
> Sent: Thursday, January 03, 2019 5:23 PM
> To: Koenig, Christian ; amd-
> g...@lists.freedesktop.org
> Subject: RE: [PATCH 2/2]
Am 03.01.19 um 10:23 schrieb Zhou, David(ChunMing):
>
>> -Original Message-
>> From: Christian König
>> Sent: Thursday, January 03, 2019 5:05 PM
>> To: Zhou, David(ChunMing) ; Koenig, Christian
>> ; Zhou, David(ChunMing)
>> ; amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH 2/2]
> -Original Message-
> From: Christian König
> Sent: Thursday, January 03, 2019 5:05 PM
> To: Zhou, David(ChunMing) ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/amdgpu: disable vm fault irq during prt
> accessed
>
> Yes,
Yes, exactly.
Problem is that we then probably need two page tables. One for the CB/TC
and one for the SDMA.
Christian.
Am 03.01.19 um 10:02 schrieb zhoucm1:
need dummy page for that?
-David
On 2019年01月03日 17:01, Christian König wrote:
NAK, the problem is not the interrupt.
E.g.
need dummy page for that?
-David
On 2019年01月03日 17:01, Christian König wrote:
NAK, the problem is not the interrupt.
E.g. causing faults by accessing unmapped pages with the SDMA can
still crash the MC.
The key point is that SDMA can't work with PRT tiles on pre-gmc9 and
we need to
NAK, the problem is not the interrupt.
E.g. causing faults by accessing unmapped pages with the SDMA can still
crash the MC.
The key point is that SDMA can't work with PRT tiles on pre-gmc9 and we
need to forbid access on the application side.
Regards,
Christian.
Am 03.01.19 um 09:54
use DRM_WARN instead of dev_warn
Change-Id: I8ede212b5f99b1f77d0bd7499da3d85873403c7a
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 6 +-
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 6 +-
3 files changed, 15
Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
>
> On 12/21/2018 01:37 PM, Christian König wrote:
>> Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
>>> Decauple sched threads stop and start and ring mirror
>>> list handling from the policy of what to do about the
>>> guilty jobs.
>>> When
For pre-gmc9, UMD can only access unmapped PRT tile from CB/TC without
firing VM fault. Kernel would still receive the VM fault interrupt
and output the error message if SDMA is the mc_client.
GMC9 don't need the same since it handle the PRT in different way.
We cannot just skip message for SDMA,
Am 03.01.19 um 04:42 schrieb Alex Deucher:
On Wed, Jan 2, 2019 at 5:26 PM Kuehling, Felix wrote:
ifdef x86_64 specific code.
Allow enabling CONFIG_HSA_AMD on ARM64.
CC: Mark Nutter
Signed-off-by: Felix Kuehling
Acked-by: Alex Deucher
Nice to see that we finally pick up some ARM support.
Oh, good point. Completely forgot about those.
Going to fix the patch,
Christian.
Am 02.01.19 um 21:26 schrieb Kuehling, Felix:
Don't you need to update amdgpu_vm_clear_freed as well?
Regards,
Felix
On 2019-01-02 8:35 a.m., Christian König wrote:
Otherwise we run into a non-retry fault
I'm just getting up to speed again after winter vacation and have tons
of mails to dig through and a few important personal appointments coming
as well.
From skimming over it looks like it should work, but please give me at
least till Monday to take a closer look.
Christian.
Am 02.01.19 um
38 matches
Mail list logo
