On 2019-09-12 2:44 a.m., S, Shirish wrote:
> define sched_policy in case CONFIG_HSA_AMD is not
> enabled, with this there is no need to check for CONFIG_HSA_AMD
> else where in driver code.
>
> Suggested-by: Felix Kuehling
> Signed-off-by: Shirish S
Reviewed-by: Felix Kuehling
> ---
>
On 2019-09-12 2:58 a.m., S, Shirish wrote:
> On 9/12/2019 3:29 AM, Kuehling, Felix wrote:
>> On 2019-09-11 2:52 a.m., S, Shirish wrote:
>>> If CONFIG_HSA_AMD is not set, build fails:
>>>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
>>> `amdgpu_device_ip_early_init':
>>>
On 2019-09-10 3:59 p.m., Russell, Kent wrote:
> This reverts commit e01f2d41895102d824c6b8f5e011dd5e286d5e8b.
>
> VG20 did not require this workaround, as the fix is in the VBIOS.
> Leave VG10/12 workaround as some older shipped cards do not have the
> VBIOS fix in place, and the kernel workaround
Reviewed by: shaoyun liu
On 2019-09-12 3:13 p.m., Cornwall, Jay wrote:
> ttmp[4:5] hold information useful to the debugger. Use ttmp[14:15]
> instead, aligning implementation with gfx9 trap handler.
>
> Signed-off-by: Jay Cornwall
> ---
> drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return on
ttmp[4:5] hold information useful to the debugger. Use ttmp[14:15]
instead, aligning implementation with gfx9 trap handler.
Signed-off-by: Jay Cornwall
---
drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 6 +++---
drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx10.asm | 10 +-
On 9/12/19 10:22 AM, Harry Wentland wrote:
On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote:
On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote:
It's otherwise properly supported, just needs exposing to userspace.
Signed-off-by: Pierre-Loup A. Griffais
I know IGT has some tests for
On 2019-09-12 1:01 p.m., Kazlauskas, Nicholas wrote:
> On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote:
>> It's otherwise properly supported, just needs exposing to userspace.
>>
>> Signed-off-by: Pierre-Loup A. Griffais
> I know IGT has some tests for plane rotation, do you happen to
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
+static int hmm_pfns_fill(unsigned long addr,
+unsigned long end,
+struct hmm_range *range,
+enum hmm_pfn_value_e value)
Nit: can we use the space a little more efficient,
On 9/12/19 1:26 AM, Christoph Hellwig wrote:
On Wed, Sep 11, 2019 at 03:28:27PM -0700, Ralph Campbell wrote:
Allow hmm_range_fault() to return success (0) when the CPU pagetable
entry points to the special shared zero page.
The caller can then handle the zero page by possibly clearing device
On 2019-09-12 12:44 p.m., Pierre-Loup A. Griffais wrote:
> It's otherwise properly supported, just needs exposing to userspace.
>
> Signed-off-by: Pierre-Loup A. Griffais
I know IGT has some tests for plane rotation, do you happen to know what
tests pass or fail when exposing this?
I think
It's otherwise properly supported, just needs exposing to userspace.
Signed-off-by: Pierre-Loup A. Griffais
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
RAS error will be triggered if the HW identified a faulty physical page,
the error comes through an interrupt where the data payload will have
information that can be translated into the bad page address, we then as
a recovery measure reset the ASIC, reserve this bad page so it cannot be
used
I dont know dkms status，anyway, we should submit this one as early as possible.
原始邮件
主题：Re: [PATCH] drm/amdgpu: resvert "disable bulk moves for now"
发件人：Christian König
收件人："Zhou, David(ChunMing)" ,amd-gfx@lists.freedesktop.org
抄送：
Just to double check: We do have that enabled
Well I still hope to avoid VRAM lost in most of the cases, but that is
really not guaranteed.
What is the bad page and why do you need to reserve it?
Christian.
Am 12.09.19 um 16:09 schrieb Grodzovsky, Andrey:
I am not sure VRAM loss happens every time, but when it does I would
assume you
Just to double check: We do have that enabled in the DKMS package for a
while and doesn't encounter any more problems with it, correct?
Thanks,
Christian.
Am 12.09.19 um 16:02 schrieb Chunming Zhou:
RB on it to go ahead.
-David
在 2019/9/12 18:15, Christian König 写道:
This reverts commit
I am not sure VRAM loss happens every time, but when it does I would
assume you would have to reserve them again as the page tables content
was lost. On the other hand I do remember we keep shadow system memory
copies of all page tables so maybe that not an issue, so yes, just try
to allocate
RB on it to go ahead.
-David
在 2019/9/12 18:15, Christian König 写道:
> This reverts commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a.
>
> The changes to fix this should have landed in 5.1.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 --
> 1 file
Am 12.09.19 um 12:27 schrieb Huang, Ray:
> On Wed, Sep 11, 2019 at 08:13:19PM +0800, Koenig, Christian wrote:
>> Am 11.09.19 um 13:50 schrieb Huang, Ray:
>>> From: Alex Deucher
>>>
>>> If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ
>>> bits of
>>> PTEs that belongs that
Hi Andrey:
Are you sure of the VRAM content loss after gpu reset? I'm not very familiar
with the detail of gpu reset and I'll do experiment to confirm the case you
mentioned.
Regards,
Tao
> -Original Message-
> From: Grodzovsky, Andrey
> Sent: 2019年9月12日 10:32
> To: Chen, Guchun ;
There are two cases of reserve error should be ignored:
1) a ras bad page has been allocated (used by someone);
2) a ras bad page has been reserved (duplicate error injection for one page);
DRM_ERROR is unnecessary for the failure of bad page reserve
Signed-off-by: Tao Zhou
---
On Wed, Sep 11, 2019 at 08:13:19PM +0800, Koenig, Christian wrote:
> Am 11.09.19 um 13:50 schrieb Huang, Ray:
> > From: Alex Deucher
> >
> > If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ
> > bits of
> > PTEs that belongs that bo should be set. Then psp is able to
This reverts commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a.
The changes to fix this should have landed in 5.1.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
On Wed, Sep 11, 2019 at 03:28:27PM -0700, Ralph Campbell wrote:
> Allow hmm_range_fault() to return success (0) when the CPU pagetable
> entry points to the special shared zero page.
> The caller can then handle the zero page by possibly clearing device
> private memory instead of DMAing a zero
Reviewed-by: Emily Deng
Best wishes
Emily Deng
>-Original Message-
>From: Zhao, Jiange
>Sent: Thursday, September 12, 2019 11:46 AM
>To: amd-gfx@lists.freedesktop.org
>Cc: Nieto, David M ; Deng, Emily
>; Koenig, Christian ;
>Zhao, Jiange
>Subject: [PATCH] drm/amdgpu: Navi10/12 VF
On 9/12/2019 3:29 AM, Kuehling, Felix wrote:
> On 2019-09-11 2:52 a.m., S, Shirish wrote:
>> If CONFIG_HSA_AMD is not set, build fails:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
>> `amdgpu_device_ip_early_init':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1626: undefined
define sched_policy in case CONFIG_HSA_AMD is not
enabled, with this there is no need to check for CONFIG_HSA_AMD
else where in driver code.
Suggested-by: Felix Kuehling
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |
27 matches
Mail list logo
