Am 05.01.22 um 08:34 schrieb JingWen Chen:
On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
On 2022-01-04 6:36 a.m., Christian König wrote:
Am 04.01.22 um 11:49 schrieb Liu, Monk:
[AMD Official Use Only]
See the FLR request from the hypervisor is just another source of signaling the
need for
On 2022/1/5 上午12:56, Andrey Grodzovsky wrote:
>
> On 2022-01-04 6:36 a.m., Christian König wrote:
>> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>>> [AMD Official Use Only]
>>>
> See the FLR request from the hypervisor is just another source of
> signaling the need for a reset, similar to
On 2022/1/4 下午7:36, Christian König wrote:
> Am 04.01.22 um 11:49 schrieb Liu, Monk:
>> [AMD Official Use Only]
>>
See the FLR request from the hypervisor is just another source of
signaling the need for a reset, similar to each job timeout on each queue.
Otherwise you have a
Patch: 3efb17ae7e92 ("drm/amdgpu: Call amdgpu_device_unmap_mmio() if device
is unplugged to prevent crash in GPU initialization failure") makes call to
amdgpu_device_unmap_mmio() conditioned on device unplugged. This patch unmaps
MMIO mappings even when device is not unplugged.
Signed-off-by:
[AMD Official Use Only]
I see, I didn't notice you already have this implemented . so the flr_work
routine itself is synced now, in this case , I agree it should be safe to
remove the in_gpu_reset and reset_semm in the flr_work.
Regards
Shaoyun.liu
-Original Message-
From:
On 2022-01-04 12:13 p.m., Liu, Shaoyun wrote:
[AMD Official Use Only]
I mostly agree with the sequences Christian described . Just one thing might
need to discuss here. For FLR notified from host, in new sequenceas
described , driver need to reply the READY_TO_RESET in the workitem
On Tue, Jan 4, 2022 at 12:26 PM Limonciello, Mario
wrote:
>
> [AMD Official Use Only]
>
>
>
> Maybe it was used more widely previously?
>
> The only place that I found it in use was amdgpu_device_evict_resources.
>
>
>
> From: Deucher, Alexander
> Sent: Tuesday, January 4, 2022 11:24
> To:
[+Adrian]
Am 2021-12-23 um 2:05 a.m. schrieb Christian König:
> Am 22.12.21 um 21:53 schrieb Daniel Vetter:
>> On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
>>
>> [SNIP]
>> Still sounds funky. I think minimally we should have an ack from CRIU
>> developers that this is
[AMD Official Use Only]
Maybe it was used more widely previously?
The only place that I found it in use was amdgpu_device_evict_resources.
From: Deucher, Alexander
Sent: Tuesday, January 4, 2022 11:24
To: Limonciello, Mario ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgpu:
[AMD Official Use Only]
I don't think this will work properly. The in_s3 flag was mainly for runtime
pm vs system suspend. I'm not sure if in_s0ix is properly handled everywhere
we check in_s3.
Alex
From: amd-gfx on behalf of Mario
Limonciello
Sent:
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Mario
Limonciello
Sent: Monday, January 3, 2022 10:23 AM
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario
Subject: [PATCH 1/2] drm/amdgpu: explicitly check for s0ix when evicting
[AMD Official Use Only]
I mostly agree with the sequences Christian described . Just one thing might
need to discuss here. For FLR notified from host, in new sequenceas
described , driver need to reply the READY_TO_RESET in the workitem from a
reset work queue which means inside
On 2022-01-04 6:36 a.m., Christian König wrote:
Am 04.01.22 um 11:49 schrieb Liu, Monk:
[AMD Official Use Only]
See the FLR request from the hypervisor is just another source of
signaling the need for a reset, similar to each job timeout on each
queue. Otherwise you have a race condition
* Alex Sierra [211206 14:00]:
> Device Coherent type uses device memory that is coherently accesible by
> the CPU. This could be shown as SP (special purpose) memory range
> at the BIOS-e820 memory enumeration. If no SP memory is supported in
> system, this could be faked by setting
On 2022-01-04 10:33, Mario Limonciello wrote:
> The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
> hard hang on HPD") causes a regression in s0ix where the system will
> fail to resume properly. This may be because an HPD was active the last
> time clocks were updated but
On 2022-01-03 9:30 p.m., Leslie Shi wrote:
If the driver loads failed during hw_init(), delay unmapping MMIO VRAM to
amdgpu_ttm_fini().
Its prevents accessing invalid memory address in vcn_v3_0_sw_fini().
Signed-off-by: Leslie Shi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16
The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
hard hang on HPD") causes a regression in s0ix where the system will
fail to resume properly. This may be because an HPD was active the last
time clocks were updated but clocks didn't get updated again during s0ix.
So add an extra
On 26/12/2021 22:24, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
On 26/12/2021 22:24, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation
Am 04.01.22 um 11:49 schrieb Liu, Monk:
[AMD Official Use Only]
See the FLR request from the hypervisor is just another source of signaling the
need for a reset, similar to each job timeout on each queue. Otherwise you have
a race condition between the hypervisor and the scheduler.
No it's
[AMD Official Use Only]
>> See the FLR request from the hypervisor is just another source of signaling
>> the need for a reset, similar to each job timeout on each queue. Otherwise
>> you have a race condition between the hypervisor and the scheduler.
No it's not, FLR from hypervisor is just to
Hi Jingwen,
well what I mean is that we need to adjust the implementation in amdgpu
to actually match the requirements.
Could be that the reset sequence is questionable in general, but I doubt
so at least for now.
See the FLR request from the hypervisor is just another source of
signaling
Hi Christian,
I'm not sure what do you mean by "we need to change SRIOV not the driver".
Do you mean we should change the reset sequence in SRIOV? This will be a huge
change for our SRIOV solution.
>From my point of view, we can directly use
amdgpu_device_lock_adev and amdgpu_device_unlock_adev
[AMD Official Use Only]
The series is:
Reviewed-by: Tao Zhou
Please make sure basic RAS tests are successful before submit the series.
> -Original Message-
> From: Chai, Thomas
> Sent: Wednesday, December 29, 2021 2:32 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ;
24 matches
Mail list logo
