I posted an intro set of patches to intel-gfx earlier, but I got a bit
OCD and kept going here.
https://cgit.freedesktop.org/~airlied/linux/log/?h=i915-display-struct-refa…
Mainly looking to see if this is interesting enough refactor to get it
landed, I realise it would be quite disruptive. I'd also like to see
if I missed anything really obvious, I wasn't sure whether
vbt/opregion were suitable and I may have left some stuff behind.
Dave.
[AMD Official Use Only]
Like vce/vcn does, visible VRAM is OK for ib test.
While commit a11d9ff3ebe0 ("drm/amdgpu: use GTT for
uvd_get_create/destory_msg") says VRAM is not mapped correctly in his
platform which is likely an arm64.
So lets change back to use VRAM on x86_64 platform.
Signed-off-by: xinhui pan <xinhui.pan(a)amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/…
[View More]gpu/drm/amd/amdgpu/amdgpu_uvd.c
index d451c359606a..e4b75f33ccc8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1178,7 +1178,11 @@ int amdgpu_uvd_get_create_msg(struct amdgpu_ring *ring, uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
@@ -1210,7 +1214,11 @@ int amdgpu_uvd_get_destroy_msg(struct amdgpu_ring *ring, uint32_t handle,
int r, i;
r = amdgpu_bo_create_reserved(adev, 1024, PAGE_SIZE,
+#ifdef CONFIG_X86_64
+ AMDGPU_GEM_DOMAIN_VRAM,
+#else
AMDGPU_GEM_DOMAIN_GTT,
+#endif
&bo, NULL, (void **)&msg);
if (r)
return r;
--
2.25.1
[View Less]
[AMD Official Use Only]
The ret value might be -EBUSY, caller will think lru lock is still
locked but actually NOT. So return -ENOSPC instead. Otherwise we hit
list corruption.
ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0,
caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will
be stuck as we actually did not free any BO memory. This usually happens
when the fence is not signaled for a long time.
Signed-off-by: xinhui pan <xinhui.pan(a)amd.com…
[View More]>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1fedd0eb67ba..f1367107925b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1159,9 +1159,9 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
}
if (bo->deleted) {
- ttm_bo_cleanup_refs(bo, false, false, locked);
+ ret = ttm_bo_cleanup_refs(bo, false, false, locked);
ttm_bo_put(bo);
- return 0;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
ttm_bo_move_to_pinned(bo);
@@ -1215,7 +1215,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx,
if (locked)
dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
- return ret;
+ return ret == -EBUSY ? -ENOSPC : ret;
}
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
--
2.25.1
[View Less]
[AMD Official Use Only]
A long time ago, someone reports system got hung during memory test.
In recent days, I am trying to look for or understand the potential
deadlock in ttm/amdgpu code.
This patchset aims to fix the deadlock during ttm populate.
TTM has a parameter called pages_limit, when allocated GTT memory
reaches this limit, swapout would be triggered. As ttm_bo_swapout does
not return the correct retval, populate might get hung.
UVD ib test uses GTT which might be insufficient. So …
[View More]a gpu recovery
would hung if populate hung.
I have made one drm test which alloc two GTT BOs, submit gfx copy
commands and free these BOs without waiting fence. What's more, these
gfx copy commands will cause gfx ring hang. So gpu recovery would be
triggered.
Now here is one possible deadlock case.
gpu_recovery
-> stop drm scheduler
-> asic reset
-> ib test
-> tt populate (uvd ib test)
-> ttm_bo_swapout (BO A) // this always fails as the fence of
BO A would not be signaled by schedluer or HW. Hit deadlock.
I paste the drm test patch below.
#modprobe ttm pages_limit=65536
#amdgpu_test -s 1 -t 4
---
tests/amdgpu/basic_tests.c | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbf02fee..f85ed340 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -65,13 +65,16 @@ static void amdgpu_direct_gma_test(void);
static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type);
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t *pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request);
+ struct amdgpu_cs_request *ibs_request, int sync, int repeat);
+#define amdgpu_test_exec_cs_helper(...) \
+ _amdgpu_test_exec_cs_helper(__VA_ARGS__, 1, 1)
+
CU_TestInfo basic_tests[] = {
{ "Query Info Test", amdgpu_query_info_test },
{ "Userptr Test", amdgpu_userptr_test },
@@ -1341,12 +1344,12 @@ static void amdgpu_command_submission_compute(void)
* pm4_src, resources, ib_info, and ibs_request
* submit command stream described in ibs_request and wait for this IB accomplished
*/
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+static void _amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
unsigned ip_type,
int instance, int pm4_dw, uint32_t *pm4_src,
int res_cnt, amdgpu_bo_handle *resources,
struct amdgpu_cs_ib_info *ib_info,
- struct amdgpu_cs_request *ibs_request)
+ struct amdgpu_cs_request *ibs_request, int sync, int repeat)
{
int r;
uint32_t expired;
@@ -1395,12 +1398,15 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
/* submit CS */
- r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
+ while (repeat--)
+ r = amdgpu_cs_submit(context_handle, 0, ibs_request, 1);
CU_ASSERT_EQUAL(r, 0);
r = amdgpu_bo_list_destroy(ibs_request->resources);
CU_ASSERT_EQUAL(r, 0);
+ if (!sync)
+ return;
fence_status.ip_type = ip_type;
fence_status.ip_instance = 0;
fence_status.ring = ibs_request->ring;
@@ -1667,7 +1673,7 @@ static void amdgpu_command_submission_sdma_const_fill(void)
static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
{
- const int sdma_write_length = 1024;
+ const int sdma_write_length = (255) << 20;
const int pm4_dw = 256;
amdgpu_context_handle context_handle;
amdgpu_bo_handle bo1, bo2;
@@ -1715,8 +1721,6 @@ static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
&bo1_va_handle);
CU_ASSERT_EQUAL(r, 0);
- /* set bo1 */
- memset((void*)bo1_cpu, 0xaa, sdma_write_length);
/* allocate UC bo2 for sDMA use */
r = amdgpu_bo_alloc_and_map(device_handle,
@@ -1727,8 +1731,6 @@ static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
&bo2_va_handle);
CU_ASSERT_EQUAL(r, 0);
- /* clear bo2 */
- memset((void*)bo2_cpu, 0, sdma_write_length);
resources[0] = bo1;
resources[1] = bo2;
@@ -1785,17 +1787,11 @@ static void amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
}
}
- amdgpu_test_exec_cs_helper(context_handle,
+ _amdgpu_test_exec_cs_helper(context_handle,
ip_type, ring_id,
i, pm4,
2, resources,
- ib_info, ibs_request);
-
- /* verify if SDMA test result meets with expected */
- i = 0;
- while(i < sdma_write_length) {
- CU_ASSERT_EQUAL(bo2_cpu[i++], 0xaa);
- }
+ ib_info, ibs_request, 0, 100);
r = amdgpu_bo_unmap_and_free(bo1, bo1_va_handle, bo1_mc,
sdma_write_length);
CU_ASSERT_EQUAL(r, 0);
--
xinhui pan (2):
drm/ttm: Fix a deadlock if the target BO is not idle during swap
drm/amdpgu: Use VRAM domain in UVD IB test
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 8 ++++++++
drivers/gpu/drm/ttm/ttm_bo.c | 6 +++---
2 files changed, 11 insertions(+), 3 deletions(-)
--
2.25.1
[View Less]
This patch series is for making the GPD Win Max display usable with
Linux.
The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]
The second patch is just to fix the orientation of the panel.
Changes since v1:
- rebased on drm-tip
- squashed patch 1 & 2
- picked up Reviewed-by from Hans de Goede (thanks for the review)
Changes since v2:
- rebased on drm-tip
- updated commit message
…
[View More]
When v2 was initially sent [3] Ville Syrjälä suggested that it might be
a good idea to use the ACPI _DDC method instead to get the EDID, to
cover a wider range of hardware. Unfortunately, it doesn't seem
available on GPD Win Max, so I think this work should be done
independently, and this patch series considered separately.
Change since v3:
- edits following Jani's review:
- The EDID from the opregion is now only used as a fallback: if we
cannot get any edid from the edp connector, then we attempt to get
it from the opregion. This works for the GPD Win Max.
- all other remarks should have been taken into account
- rebased on drm-tip
- added Co-developed-by
- reordered signed-off-by and reviewed-by in second patch (thanks
Maarten!)
[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454
[2]: https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1…
[3]: https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-…
Anisse Astier (2):
drm/i915/opregion: add support for mailbox #5 EDID
drm: Add orientation quirk for GPD Win Max
.../gpu/drm/drm_panel_orientation_quirks.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
drivers/gpu/drm/i915/display/intel_opregion.c | 55 ++++++++++++++++++-
drivers/gpu/drm/i915/display/intel_opregion.h | 10 ++++
4 files changed, 77 insertions(+), 1 deletion(-)
--
2.31.1
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=212469
Bug ID: 212469
Summary: plymouth animation freezes during shutdown
Product: Drivers
Version: 2.5
Kernel Version: 5.11.6
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: low
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: …
[View More]amirgi73(a)criptext.com
Regression: No
Created attachment 296125
--> https://bugzilla.kernel.org/attachment.cgi?id=296125&action=edit
plymouth animation freezes during shutdown
Overview:
plymouth animation during shutdown freezes. the system would shutdown
without
any problem.
Steps to reproduce:
with plymouth installed and lightdm-plymouth/sddm-plymouth.service enabled,
after pressing restart or shutdown button, plymouth animation appears
normally then the screen would turn off and then it turn on again, this
time it shows a frozen plymouth animation. after about 5sec the system
would shutdown/restart normally.
Expected Results:
plymouth animation will work during shutdown and won't freeze.
Build Date & Hardware:
archlinux-kernel 5.11.6 build 1
CPU: intel i5 7200u
GPU: Intel HD 620 + Nivida 940mx
Video Driver: modsettings driver for Intel HD + Nvidia-proprietary 460.67
in prime render offloading mode
DE: KDE Plasma 5.21.3
plymouth: latest git build
Additional Builds and Platforms:
this problem doesn't occur with kernel 5.10.16.
Additional Information:
see attached video bellow
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]