Re: [PATCH] drm/i915/selftests: Skip hangcheck selftest on DG1
On Mon, 2021-10-11 at 12:40 -0700, Matthew Brost wrote: > The hangcheck selftest blows on DG1 CI and aborts the BAT run. > Investigation is underway to root cause the failure but in the > meantime > disable to this test on DG1 to unblock CI. > > Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström
Re: [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> Use __release_guc_id (lock held) rather than release_guc_id (acquires
> lock), add lockdep annotations.
>
> 213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
> [ 213.283459]
> [ 213.283462] WARNING: possible recursive locking detected
> {{[ 213.283466] 5.15.0-rc6+ #18 Tainted: G U W }}
> [ 213.283470]
> [ 213.283472] kworker/u24:0/8 is trying to acquire lock:
> [ 213.283475] 8ffc4f6cc1e8 (>submission_state.lock){}-
> {2:2}, at: destroyed_worker_func+0x2df/0x350 [i915]
> {{[ 213.283618] }}
> {{ but task is already holding lock:}}
> [ 213.283621] 8ffc4f6cc1e8 (>submission_state.lock){}-
> {2:2}, at: destroyed_worker_func+0x4f/0x350 [i915]
> {{[ 213.283720] }}
> {{ other info that might help us debug this:}}
> [ 213.283724] Possible unsafe locking scenario:[ 213.283727] CPU0
> [ 213.283728]
> [ 213.283730] lock(>submission_state.lock);
> [ 213.283734] lock(>submission_state.lock);
> {{[ 213.283737] }}
> {{ *** DEADLOCK ***}}[ 213.283740] May be due to missing lock nesting
> notation[ 213.283744] 3 locks held by kworker/u24:0/8:
> [ 213.283747] #0: 8ffb80059d38
> ((wq_completion)events_unbound){..}-{0:0}, at:
> process_one_work+0x1f3/0x550
> [ 213.283757] #1: b509000e3e78 ((work_completion)(
> >submission_state.destroyed_worker)){..}-{0:0}, at:
> process_one_work+0x1f3/0x550
> [ 213.283766] #2: 8ffc4f6cc1e8 (
> >submission_state.lock){}-{2:2}, at:
> destroyed_worker_func+0x4f/0x350 [i915]
> {{[ 213.283860] }}
> {{ stack backtrace:}}
> [ 213.283863] CPU: 8 PID: 8 Comm: kworker/u24:0 Tainted: G U W
> 5.15.0-rc6+ #18
> [ 213.283868] Hardware name: ASUS System Product Name/PRIME B560M-A
> AC, BIOS 0403 01/26/2021
> [ 213.283873] Workqueue: events_unbound destroyed_worker_func [i915]
> [ 213.283957] Call Trace:
> [ 213.283960] dump_stack_lvl+0x57/0x72
> [ 213.283966] __lock_acquire.cold+0x191/0x2d3
> [ 213.283972] lock_acquire+0xb5/0x2b0
> [ 213.283978] ? destroyed_worker_func+0x2df/0x350 [i915]
> [ 213.284059] ? destroyed_worker_func+0x2d7/0x350 [i915]
> [ 213.284139] ? lock_release+0xb9/0x280
> [ 213.284143] _raw_spin_lock_irqsave+0x48/0x60
> [ 213.284148] ? destroyed_worker_func+0x2df/0x350 [i915]
> [ 213.284226] destroyed_worker_func+0x2df/0x350 [i915]
> [ 213.284310] process_one_work+0x270/0x550
> [ 213.284315] worker_thread+0x52/0x3b0
> [ 213.284319] ? process_one_work+0x550/0x550
> [ 213.284322] kthread+0x135/0x160
> [ 213.284326] ? set_kthread_struct+0x40/0x40
> [ 213.284331] ret_from_fork+0x1f/0x30
>
> and a bit later in the trace:
>
> {{ 227.499864] do_raw_spin_lock+0x94/0xa0}}
> [ 227.499868] _raw_spin_lock_irqsave+0x50/0x60
> [ 227.499871] ? guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
> [ 227.45] guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
> [ 227.500104] intel_guc_submission_reset_prepare+0x99/0x4b0 [i915]
> [ 227.500209] ? mark_held_locks+0x49/0x70
> [ 227.500212] intel_uc_reset_prepare+0x46/0x50 [i915]
> [ 227.500320] reset_prepare+0x78/0x90 [i915]
> [ 227.500412] __intel_gt_set_wedged.part.0+0x13/0xe0 [i915]
> [ 227.500485] intel_gt_set_wedged.part.0+0x54/0x100 [i915]
> [ 227.500556] intel_gt_set_wedged_on_fini+0x1a/0x30 [i915]
> [ 227.500622] intel_gt_driver_unregister+0x1e/0x60 [i915]
> [ 227.500694] i915_driver_remove+0x4a/0xf0 [i915]
> [ 227.500767] i915_pci_probe+0x84/0x170 [i915]
> [ 227.500838] local_pci_probe+0x42/0x80
> [ 227.500842] pci_device_probe+0xd9/0x190
> [ 227.500844] really_probe+0x1f2/0x3f0
> [ 227.500847] __driver_probe_device+0xfe/0x180
> [ 227.500848] driver_probe_device+0x1e/0x90
> [ 227.500850] __driver_attach+0xc4/0x1d0
> [ 227.500851] ? __device_attach_driver+0xe0/0xe0
> [ 227.500853] ? __device_attach_driver+0xe0/0xe0
> [ 227.500854] bus_for_each_dev+0x64/0x90
> [ 227.500856] bus_add_driver+0x12e/0x1f0
> [ 227.500857] driver_register+0x8f/0xe0
> [ 227.500859] i915_init+0x1d/0x8f [i915]
> [ 227.500934] ? 0xc144a000
> [ 227.500936] do_one_initcall+0x58/0x2d0
> [ 227.500938] ? rcu_read_lock_sched_held+0x3f/0x80
> [ 227.500940] ? kmem_cache_alloc_trace+0x238/0x2d0
> [ 227.500944] do_init_module+0x5c/0x270
> [ 227.500946] __do_sys_finit_module+0x95/0xe0
> [ 227.500949] do_syscall_64+0x38/0x90
> [ 227.500951] entry_SYSCALL_64_after_hwframe+0x44/0xae
> [ 227.500953] RIP: 0033:0x7ffa59d2ae0d
> [ 227.500954] Code: c8 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e
> fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3b 80 0c 00 f7 d8 64
> 89 01 48
> [ 227.500955] RSP: 002b:7fff320bbf48 EFLAGS: 0246 ORIG_RAX:
> 0139
> [ 227.500956] RAX: ffda RBX: 022ea710 RCX:
> 7ffa59d2ae0d
> [ 227.500957] RDX: RSI: 022e1d90 RDI:
> 0004
> [ 227.500958] RBP: 0020 R08: 7ffa59df3a60 R09:
> 0070
> [ 227.500958] R10:
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Increase timeout in requests perf selftest
On Wed, 2021-10-20 at 13:34 -0700, John Harrison wrote: > On 10/11/2021 10:57, Matthew Brost wrote: > > perf_parallel_engines is micro benchmark to test i915 request > > scheduling. The test creates a thread per physical engine and > > submits > > NOP requests and waits the requests to complete in a loop. In > > execlists > > mode this works perfectly fine as powerful CPU has enough cores to > > feed > > each engine and process the CSBs. With GuC submission the uC gets > > overwhelmed as all threads feed into a single CTB channel and the > > GuC > > gets bombarded with CSBs as contexts are immediately switched in > > and out > > on the engines due to the zero runtime of the requests. When the > > GuC is > > overwhelmed scheduling of contexts is unfair due to the nature of > > the > > GuC scheduling algorithm. This behavior is understood and deemed > > acceptable as this micro benchmark isn't close to real world use > > case. > > Increasing the timeout of wait period for requests to complete. > > This > > makes the test understand that is ok for contexts to get starved in > > this > > scenario. > > > > A future patch / cleanup may just delete these micro benchmark > > tests as > > they basically mean nothing. We care about real workloads not made > > up > > ones. > > > > Signed-off-by: Matthew Brost > Reviewed-by: John Harrison Also Reviewed-by: Thomas Hellström I think one important thing to keep in mind here is that this selftest actually *did* find a flaw, Albeit it upon analysis turned out not to be significant. But given that, user-space clients like, for example, gem_exec_suspend seems to be able to trigger similar delays as well at least to some extend with a huge amount of small requests submitted from user-space we shold probably verify at some point that this isn't exploitable by a malicious client starving other clients on the same system. /Thomas > > > --- > > drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c > > b/drivers/gpu/drm/i915/selftests/i915_request.c > > index d67710d10615..6496671a113c 100644 > > --- a/drivers/gpu/drm/i915/selftests/i915_request.c > > +++ b/drivers/gpu/drm/i915/selftests/i915_request.c > > @@ -2805,7 +2805,7 @@ static int p_sync0(void *arg) > > i915_request_add(rq); > > > > err = 0; > > - if (i915_request_wait(rq, 0, HZ / 5) < 0) > > + if (i915_request_wait(rq, 0, HZ) < 0) > > err = -ETIME; > > i915_request_put(rq); > > if (err) > > @@ -2876,7 +2876,7 @@ static int p_sync1(void *arg) > > i915_request_add(rq); > > > > err = 0; > > - if (prev && i915_request_wait(prev, 0, HZ / 5) < 0) > > + if (prev && i915_request_wait(prev, 0, HZ) < 0) > > err = -ETIME; > > i915_request_put(prev); > > prev = rq; >
[RFC PATCH 4/4] drm/msm/dp: Use DPCD 248h DP 2.0 new names/definitions
Use DP 2.0 DPCD 248h new name (LINK_QUAL_PATTERN_SELECT) and rename selected
phy test patterns to LINK_QUAL_PATTERN_*
Note: TPS4 LT pattern is CP2520 Pattern 3 (refer to DP2.0 spaces Table 3-11,
DPCD 00248h
LINK_QUAL_PATTERN_SELECT, and DP PHY 1.4 CTS - Appendix A - Compliance EYE
Pattern(CP2520; Normative))
That is why the change from DP_PHY_TEST_PATTERN_SEL_MASK to
DP_LINK_QUAL_PATTERN_CP2520_PAT_3
No functional changes
Cc: Chandan Uddaraju
Cc: Kuogee Hsieh
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++--
drivers/gpu/drm/msm/dp/dp_ctrl.c| 12 ++--
drivers/gpu/drm/msm/dp/dp_link.c| 16
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index cc2bb8295329..2076439ac2a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -690,11 +690,11 @@ void dp_catalog_ctrl_send_phy_pattern(struct dp_catalog
*dp_catalog,
DRM_DEBUG_DP("pattern: %#x\n", pattern);
switch (pattern) {
- case DP_PHY_TEST_PATTERN_D10_2:
+ case DP_LINK_QUAL_PATTERN_D10_2:
dp_write_link(catalog, REG_DP_STATE_CTRL,
DP_STATE_CTRL_LINK_TRAINING_PATTERN1);
break;
- case DP_PHY_TEST_PATTERN_ERROR_COUNT:
+ case DP_LINK_QUAL_PATTERN_ERROR_RATE:
value &= ~(1 << 16);
dp_write_link(catalog, REG_DP_HBR2_COMPLIANCE_SCRAMBLER_RESET,
value);
@@ -706,11 +706,11 @@ void dp_catalog_ctrl_send_phy_pattern(struct dp_catalog
*dp_catalog,
dp_write_link(catalog, REG_DP_STATE_CTRL,
DP_STATE_CTRL_LINK_SYMBOL_ERR_MEASURE);
break;
- case DP_PHY_TEST_PATTERN_PRBS7:
+ case DP_LINK_QUAL_PATTERN_PRBS7:
dp_write_link(catalog, REG_DP_STATE_CTRL,
DP_STATE_CTRL_LINK_PRBS7);
break;
- case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ case DP_LINK_QUAL_PATTERN_80BIT_CUSTOM:
dp_write_link(catalog, REG_DP_STATE_CTRL,
DP_STATE_CTRL_LINK_TEST_CUSTOM_PATTERN);
/* 00101010 */
@@ -723,7 +723,7 @@ void dp_catalog_ctrl_send_phy_pattern(struct dp_catalog
*dp_catalog,
dp_write_link(catalog, REG_DP_TEST_80BIT_CUSTOM_PATTERN_REG2,
0xF83E);
break;
- case DP_PHY_TEST_PATTERN_CP2520:
+ case DP_LINK_QUAL_PATTERN_CP2520_PAT_1:
value = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
value &= ~DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER;
dp_write_link(catalog, REG_DP_MAINLINK_CTRL, value);
@@ -742,7 +742,7 @@ void dp_catalog_ctrl_send_phy_pattern(struct dp_catalog
*dp_catalog,
value |= DP_MAINLINK_CTRL_ENABLE;
dp_write_link(catalog, REG_DP_MAINLINK_CTRL, value);
break;
- case DP_PHY_TEST_PATTERN_SEL_MASK:
+ case DP_LINK_QUAL_PATTERN_CP2520_PAT_3:
dp_write_link(catalog, REG_DP_MAINLINK_CTRL,
DP_MAINLINK_CTRL_ENABLE);
dp_write_link(catalog, REG_DP_STATE_CTRL,
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 62e75dc8afc6..a97f9dd03a8c 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1553,25 +1553,25 @@ static bool dp_ctrl_send_phy_test_pattern(struct
dp_ctrl_private *ctrl)
switch (pattern_sent) {
case MR_LINK_TRAINING1:
success = (pattern_requested ==
- DP_PHY_TEST_PATTERN_D10_2);
+ DP_LINK_QUAL_PATTERN_D10_2);
break;
case MR_LINK_SYMBOL_ERM:
success = ((pattern_requested ==
- DP_PHY_TEST_PATTERN_ERROR_COUNT) ||
+ DP_LINK_QUAL_PATTERN_ERROR_RATE) ||
(pattern_requested ==
- DP_PHY_TEST_PATTERN_CP2520));
+ DP_LINK_QUAL_PATTERN_CP2520_PAT_1));
break;
case MR_LINK_PRBS7:
success = (pattern_requested ==
- DP_PHY_TEST_PATTERN_PRBS7);
+ DP_LINK_QUAL_PATTERN_PRBS7);
break;
case MR_LINK_CUSTOM80:
success = (pattern_requested ==
- DP_PHY_TEST_PATTERN_80BIT_CUSTOM);
+ DP_LINK_QUAL_PATTERN_80BIT_CUSTOM);
break;
case MR_LINK_TRAINING4:
success = (pattern_requested ==
- DP_PHY_TEST_PATTERN_SEL_MASK);
+
[RFC PATCH 2/4] drm/i915/dp: Use DP 2.0 LINK_QUAL_PATTERN_* Phy test pattern definitions
Update selected phy test pattern names to use the new names/definitions of DPCD
248h in DP2.0/drm_dp_helpers.h
No functional changes
Cc: Manasi Navare
CC: Jani Nikula
Cc: Imre Deak
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f5dc2126d140..931e8083e54a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3367,27 +3367,27 @@ static void intel_dp_phy_pattern_update(struct intel_dp
*intel_dp,
u32 pattern_val;
switch (data->phy_pattern) {
- case DP_PHY_TEST_PATTERN_NONE:
+ case DP_LINK_QUAL_PATTERN_DISABLE:
DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
break;
- case DP_PHY_TEST_PATTERN_D10_2:
+ case DP_LINK_QUAL_PATTERN_D10_2:
DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
- case DP_PHY_TEST_PATTERN_ERROR_COUNT:
+ case DP_LINK_QUAL_PATTERN_ERROR_RATE:
DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE |
DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
- case DP_PHY_TEST_PATTERN_PRBS7:
+ case DP_LINK_QUAL_PATTERN_PRBS7:
DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
- case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ case DP_LINK_QUAL_PATTERN_80BIT_CUSTOM:
/*
* FIXME: Ideally pattern should come from DPCD 0x250. As
* current firmware of DPR-100 could not set it, so hardcoding
@@ -3404,7 +3404,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
*intel_dp,
DDI_DP_COMP_CTL_ENABLE |
DDI_DP_COMP_CTL_CUSTOM80);
break;
- case DP_PHY_TEST_PATTERN_CP2520:
+ case DP_LINK_QUAL_PATTERN_CP2520_PAT_1:
/*
* FIXME: Ideally pattern should come from DPCD 0x24A. As
* current firmware of DPR-100 could not set it, so hardcoding
--
2.25.1
[RFC PATCH 3/4] drm/amd/dc: Use DPCD 248h DP 2.0 new name
Use the new definition of DPCD 248h (DP_LINK_QUAL_PATTERN_SELECT) No functional changes. Cc: Harry Wentland Cc: Alex Deucher Signed-off-by: Khaled Almahallawy --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 54662d74c65a..d34187bb42dd 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -3604,7 +3604,7 @@ static void dp_test_send_phy_test_pattern(struct dc_link *link) /* get phy test pattern and pattern parameters from DP receiver */ core_link_read_dpcd( link, - DP_PHY_TEST_PATTERN, + DP_LINK_QUAL_PATTERN_SELECT, _test_pattern.raw, sizeof(dpcd_test_pattern)); core_link_read_dpcd( -- 2.25.1
[RFC PATCH 0/4] drm/dp: Use DP2.0 DPCD 248h updated register/field names for DP PHY CTS
This series updates DPCD 248h register name and PHY test patterns names to follow DP 2.0 Specs. Also updates the DP PHY CTS codes of the affected drivers (i915, amd, msm) No functional changes expected. Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency” https://groups.vesa.org/wg/AllMem/documentComment/2738 Khaled Almahallawy (4): drm/dp: Rename DPCD 248h according to DP 2.0 specs drm/i915/dp: Use DP 2.0 LINK_QUAL_PATTERN_* Phy test pattern definitions drm/amd/dc: Use DPCD 248h DP 2.0 new name drm/msm/dp: Use DPCD 248h DP 2.0 new names/definitions drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c | 6 +++--- drivers/gpu/drm/i915/display/intel_dp.c | 12 ++-- drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++-- drivers/gpu/drm/msm/dp/dp_ctrl.c | 12 ++-- drivers/gpu/drm/msm/dp/dp_link.c | 16 include/drm/drm_dp_helper.h | 13 +++-- 7 files changed, 33 insertions(+), 40 deletions(-) -- 2.25.1
[RFC PATCH 1/4] drm/dp: Rename DPCD 248h according to DP 2.0 specs
DPCD 248h name was changed from “PHY_TEST_PATTERN” in DP 1.4 to
“LINK_QUAL_PATTERN_SELECT” in DP 2.0.
Also, DPCD 248h [6:0] is the same as DPCDs 10Bh/10Ch/10Dh/10Eh [6:0]. So
removed the repeated definition of PHY patterns.
Reference: “DPCD 248h/10Bh/10Ch/10Dh/10Eh Name/Description Consistency”
https://groups.vesa.org/wg/AllMem/documentComment/2738
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 6 +++---
include/drm/drm_dp_helper.h | 13 +++--
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ada0a1ff262d..c9c928c08026 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2489,19 +2489,19 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
if (lanes & DP_ENHANCED_FRAME_CAP)
data->enhanced_frame_cap = true;
- err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
+ err = drm_dp_dpcd_readb(aux, DP_LINK_QUAL_PATTERN_SELECT,
>phy_pattern);
if (err < 0)
return err;
switch (data->phy_pattern) {
- case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ case DP_LINK_QUAL_PATTERN_80BIT_CUSTOM:
err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
>custom80, sizeof(data->custom80));
if (err < 0)
return err;
break;
- case DP_PHY_TEST_PATTERN_CP2520:
+ case DP_LINK_QUAL_PATTERN_CP2520_PAT_1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
>hbr2_reset,
sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index afdf7f4183f9..ef915bb75bb4 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -862,16 +862,9 @@ struct drm_panel;
# define DP_TEST_CRC_SUPPORTED (1 << 5)
# define DP_TEST_COUNT_MASK0xf
-#define DP_PHY_TEST_PATTERN 0x248
-# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
-# define DP_PHY_TEST_PATTERN_NONE 0x0
-# define DP_PHY_TEST_PATTERN_D10_2 0x1
-# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
-# define DP_PHY_TEST_PATTERN_PRBS7 0x3
-# define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
-
-#define DP_PHY_SQUARE_PATTERN 0x249
+#define DP_LINK_QUAL_PATTERN_SELECT 0x248
+
+#define DP_PHY_SQUARE_PATTERN 0x249
#define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
#define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
--
2.25.1
Re: [RFC PATCH 5/8] drm: start using drm_gem_trace_gpu_mem_instance
On Wed, 20 Oct 2021 20:10:24 -0700 Gurchetan Singh wrote: > @@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void > *data) > drm_gem_remove_prime_handles(obj, file_priv); > drm_vma_node_revoke(>vma_node, file_priv); > > + drm_gem_trace_gpu_mem_instance(dev, file_priv, -obj->size, false); I would suggest adding the trace_*_enabled() if statements around all these callers. -- Steve > drm_gem_object_handle_put_unlocked(obj); > > return 0;
Re: [RFC PATCH 4/8] drm: start using drm_gem_trace_gpu_mem_total
On Wed, 20 Oct 2021 20:10:23 -0700 Gurchetan Singh wrote: > - drm_gem_private_object_init(..) increases the total memory > counter. > > * All GEM objects (whether allocated or imported) seem to begin > there. > * If there's a better place/method, please do let > me know. > > - drm_gem_object_free(..) decreases the total memory counter. > > Signed-off-by: Gurchetan Singh > --- > drivers/gpu/drm/drm_gem.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 24a719b79400..528d7b29dccf 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -213,6 +213,7 @@ void drm_gem_private_object_init(struct drm_device *dev, > obj->resv = >_resv; > > drm_vma_node_reset(>vma_node); To save yourself a function call when tracing is disabled, you can add: if (trace_gpu_mem_total_enabled()) here, which is a static_branch (meaning it's not a compare and branch, but a nop when tracing is disabled, and a jmp (to the if block) when the event is enabled). > + drm_gem_trace_gpu_mem_total(dev, obj->size, false); > } > EXPORT_SYMBOL(drm_gem_private_object_init); > > @@ -1015,6 +1016,10 @@ drm_gem_object_free(struct kref *kref) > struct drm_gem_object *obj = > container_of(kref, struct drm_gem_object, refcount); > > + struct drm_device *dev = obj->dev; > + Same here. -- Steve > + drm_gem_trace_gpu_mem_total(dev, -obj->size, false); > + > if (WARN_ON(!obj->funcs->free)) > return; >
[RFC PATCH 8/8] drm: trace memory import per DRM device
- drm_gem_prime_import_dev increases the per-device import memory counter * Most drivers use it. * drivers that have a (*gem_prime_import) callback will need additional changes, which can be done if everyone likes the overall RFC. - drm_prime_gem_destroy decreases the per-device import memory counter. * All drivers seem to use it? Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/drm_prime.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 1afcae0c4038..c2057b7a63b4 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -955,6 +955,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev, obj->import_attach = attach; obj->resv = dma_buf->resv; + drm_gem_trace_gpu_mem_total(dev, obj->size, true); return obj; @@ -1055,6 +1056,7 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg) struct dma_buf_attachment *attach; struct dma_buf *dma_buf; + drm_gem_trace_gpu_mem_total(obj->dev, -obj->size, true); attach = obj->import_attach; if (sg) dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL); -- 2.25.1
[RFC PATCH 2/8] drm: add new tracepoint fields to drm_device and drm_file
For struct drm_device, add:
- mem_total
- import_mem_total
For struct drm_file, add:
- mem_instance
- import_mem_instance
Signed-off-by: Gurchetan Singh
---
include/drm/drm_device.h | 16
include/drm/drm_file.h | 16
2 files changed, 32 insertions(+)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 604b1d1b2d72..35a96bda5320 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -298,6 +298,22 @@ struct drm_device {
*/
struct drm_fb_helper *fb_helper;
+ /**
+* @mem_total:
+*
+* The total size of all GEM objects known to this DRM device. Used
+* with `gpu_mem_total` tracepoint.
+*/
+ atomic64_t mem_total;
+
+ /**
+* @import_mem_total:
+*
+* The total size of all GEM objects imported into this DRM device from
+* external exporters. Used with `gpu_mem_total` tracepoint.
+*/
+ atomic64_t import_mem_total;
+
/* Everything below here is for legacy driver, never use! */
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index a3acb7ac3550..a5b9befcf1db 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -362,6 +362,22 @@ struct drm_file {
*/
struct drm_prime_file_private prime;
+ /**
+* @mem_instance:
+*
+* The total size of all GEM objects known into this instance of the DRM
+* device. Used with `gpu_mem_instance` tracepoint.
+*/
+ atomic64_t mem_instance;
+
+ /**
+* @import_mem_instance:
+*
+* The total size of all GEM objects imported into this instance of the
+* DRM device. Used with `gpu_mem_instance` tracepoint.
+*/
+ atomic64_t import_mem_instance;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
--
2.25.1
[RFC PATCH 4/8] drm: start using drm_gem_trace_gpu_mem_total
- drm_gem_private_object_init(..) increases the total memory counter. * All GEM objects (whether allocated or imported) seem to begin there. * If there's a better place/method, please do let me know. - drm_gem_object_free(..) decreases the total memory counter. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/drm_gem.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 24a719b79400..528d7b29dccf 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -213,6 +213,7 @@ void drm_gem_private_object_init(struct drm_device *dev, obj->resv = >_resv; drm_vma_node_reset(>vma_node); + drm_gem_trace_gpu_mem_total(dev, obj->size, false); } EXPORT_SYMBOL(drm_gem_private_object_init); @@ -1015,6 +1016,10 @@ drm_gem_object_free(struct kref *kref) struct drm_gem_object *obj = container_of(kref, struct drm_gem_object, refcount); + struct drm_device *dev = obj->dev; + + drm_gem_trace_gpu_mem_total(dev, -obj->size, false); + if (WARN_ON(!obj->funcs->free)) return; -- 2.25.1
[RFC PATCH 7/8] drm: trace memory import per DRM file
- drm_gem_prime_fd_to_handle increases the per-instance imported memory counter - drm_gem_remove_prime_handles decreases the per-instance imported memory counter on non-fake imports. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/drm_gem.c | 3 +++ drivers/gpu/drm/drm_prime.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 7637be0ceb74..c07568ea8442 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -231,6 +231,9 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) drm_prime_remove_buf_handle_locked(>prime, obj->dma_buf, _real_import); + if (removed_real_import) + drm_gem_trace_gpu_mem_instance(dev, filp, -obj->size, + true); } mutex_unlock(>prime.lock); } diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 31f033ec8549..1afcae0c4038 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -349,6 +349,8 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev, dma_buf_put(dma_buf); + drm_gem_trace_gpu_mem_instance(dev, file_priv, obj->size, true); + return 0; fail: -- 2.25.1
[RFC PATCH 5/8] drm: start using drm_gem_trace_gpu_mem_instance
- drm_gem_handle_create_tail(..) increases the per instance
memory counter.
- drm_gem_object_release_handle(..) decreases the per instance
memory counter.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 528d7b29dccf..6f70419f2c90 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -298,6 +298,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
{
struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
+ struct drm_device *dev = file_priv->minor->dev;
if (obj->funcs->close)
obj->funcs->close(obj, file_priv);
@@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(>vma_node, file_priv);
+ drm_gem_trace_gpu_mem_instance(dev, file_priv, -obj->size, false);
drm_gem_object_handle_put_unlocked(obj);
return 0;
@@ -447,6 +449,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
goto err_revoke;
}
+ drm_gem_trace_gpu_mem_instance(dev, file_priv, obj->size, false);
*handlep = handle;
return 0;
--
2.25.1
[RFC PATCH 6/8] drm: track real and fake imports in drm_prime_member
Sometimes, an exported dma-buf is added to the import list.
That messes up with trace point accounting, so track real vs.
fake imports to correct this.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 5 -
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c| 18 +-
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 6f70419f2c90..7637be0ceb74 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -226,8 +226,11 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj,
struct drm_file *filp)
*/
mutex_lock(>prime.lock);
if (obj->dma_buf) {
+ struct drm_device *dev = filp->minor->dev;
+ bool removed_real_import = false;
drm_prime_remove_buf_handle_locked(>prime,
- obj->dma_buf);
+ obj->dma_buf,
+ _real_import);
}
mutex_unlock(>prime.lock);
}
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 17f3548c8ed2..40d572e46e2a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -75,8 +75,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void
*data,
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv);
void drm_prime_destroy_file_private(struct drm_prime_file_private
*prime_fpriv);
void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
- struct dma_buf *dma_buf);
-
+ struct dma_buf *dma_buf,
+ bool *removed_real_import);
/* drm_drv.c */
struct drm_minor *drm_minor_acquire(unsigned int minor_id);
void drm_minor_release(struct drm_minor *minor);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index deb23dbec8b5..31f033ec8549 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -90,13 +90,15 @@
struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
+ bool fake_import;
struct rb_node dmabuf_rb;
struct rb_node handle_rb;
};
static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
- struct dma_buf *dma_buf, uint32_t handle)
+ struct dma_buf *dma_buf, uint32_t handle,
+ bool fake_import)
{
struct drm_prime_member *member;
struct rb_node **p, *rb;
@@ -108,6 +110,7 @@ static int drm_prime_add_buf_handle(struct
drm_prime_file_private *prime_fpriv,
get_dma_buf(dma_buf);
member->dma_buf = dma_buf;
member->handle = handle;
+ member->fake_import = fake_import;
rb = NULL;
p = _fpriv->dmabufs.rb_node;
@@ -188,9 +191,11 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
}
void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
- struct dma_buf *dma_buf)
+ struct dma_buf *dma_buf,
+ bool *removed_real_import)
{
struct rb_node *rb;
+ *removed_real_import = false;
rb = prime_fpriv->dmabufs.rb_node;
while (rb) {
@@ -201,6 +206,9 @@ void drm_prime_remove_buf_handle_locked(struct
drm_prime_file_private *prime_fpr
rb_erase(>handle_rb, _fpriv->handles);
rb_erase(>dmabuf_rb, _fpriv->dmabufs);
+ if (!member->fake_import)
+ *removed_real_import = true;
+
dma_buf_put(dma_buf);
kfree(member);
return;
@@ -303,7 +311,6 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
return PTR_ERR(dma_buf);
mutex_lock(_priv->prime.lock);
-
ret = drm_prime_lookup_buf_handle(_priv->prime,
dma_buf, handle);
if (ret == 0)
@@ -315,6 +322,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
obj = dev->driver->gem_prime_import(dev, dma_buf);
else
obj = drm_gem_prime_import(dev, dma_buf);
+
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto out_unlock;
@@ -334,7 +342,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto out_put;
ret = drm_prime_add_buf_handle(_priv->prime,
- dma_buf, *handle);
+ dma_buf, *handle, false);
mutex_unlock(_priv->prime.lock);
if (ret)
goto fail;
@@ -473,7 +481,7 @@ int
[RFC PATCH 1/8] tracing/gpu: modify gpu_mem_total
The existing gpu_mem_total tracepoint [1] is not currently used by
any in-tree consumers, we should add some.
In addition, there's a desire to report imported memory via the
counters too [2].
To do this, we'll have to redefine the event to:
a) Change 'pid' to 'ctx_id'
The reason is DRM subsystem is created with GEM objects, DRM devices
and DRM files in mind. A GEM object is associated with DRM device,
and it may be shared between one or more DRM files.
Per-instance (or "context") counters make more sense than per-process
counters for DRM. For GPUs that per process counters (kgsl), this
change is backwards compatible.
b) add an "import_mem_total" field
We're just appending a field, so no problem here. Change "size" to
"mem_total" as well (name changes are backwards compatible).
[1] https://lore.kernel.org/r/20200302234840.57188-1-zzyi...@google.com/
[2] https://www.spinics.net/lists/kernel/msg4062769.html
Signed-off-by: Gurchetan Singh
---
include/trace/events/gpu_mem.h | 61 --
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/include/trace/events/gpu_mem.h b/include/trace/events/gpu_mem.h
index 26d871f96e94..198b87f50356 100644
--- a/include/trace/events/gpu_mem.h
+++ b/include/trace/events/gpu_mem.h
@@ -14,41 +14,66 @@
#include
/*
- * The gpu_memory_total event indicates that there's an update to either the
- * global or process total gpu memory counters.
+ * The gpu_mem_total event indicates that there's an update to local or
+ * global gpu memory counters.
*
- * This event should be emitted whenever the kernel device driver allocates,
- * frees, imports, unimports memory in the GPU addressable space.
+ * This event should be emitted whenever a GPU device (ctx_id == 0):
*
- * @gpu_id: This is the gpu id.
+ * 1) allocates memory.
+ * 2) frees memory.
+ * 3) imports memory from an external exporter.
*
- * @pid: Put 0 for global total, while positive pid for process total.
+ * OR when a GPU device instance (ctx_id != 0):
*
- * @size: Size of the allocation in bytes.
+ * 1) allocates or acquires a reference to memory from another instance.
+ * 2) frees or releases a reference to memory from another instance.
+ * 3) imports memory from another GPU device instance.
*
+ * When ctx_id == 0, both mem_total and import_mem_total total counters
+ * represent a global total. When ctx_id == 0, these counters represent
+ * an instance specifical total.
+ *
+ * Note allocation does not necessarily mean backing the memory with pages.
+ *
+ * @gpu_id: unique ID of the GPU.
+ *
+ * @ctx_id: an ID for specific instance of the GPU device.
+ *
+ * @mem_total: - total size of memory known to a GPU device, including
+ * imports (ctx_id == 0)
+ *- total size of memory known to a GPU device instance
+ * (ctx_id != 0)
+ *
+ * @import_mem_total: - size of memory imported from outside GPU
+ * device (ctx_id == 0)
+ * - size of memory imported into GPU device instance.
+ * (ctx_id == 0)
*/
TRACE_EVENT(gpu_mem_total,
- TP_PROTO(uint32_t gpu_id, uint32_t pid, uint64_t size),
+ TP_PROTO(u32 gpu_id, u32 ctx_id, u64 mem_total, u64 import_mem_total),
- TP_ARGS(gpu_id, pid, size),
+ TP_ARGS(gpu_id, ctx_id, mem_total, import_mem_total),
TP_STRUCT__entry(
- __field(uint32_t, gpu_id)
- __field(uint32_t, pid)
- __field(uint64_t, size)
+ __field(u32, gpu_id)
+ __field(u32, ctx_id)
+ __field(u64, mem_total)
+ __field(u64, import_mem_total)
),
TP_fast_assign(
__entry->gpu_id = gpu_id;
- __entry->pid = pid;
- __entry->size = size;
+ __entry->ctx_id = ctx_id;
+ __entry->mem_total = mem_total;
+ __entry->import_mem_total = import_mem_total;
),
- TP_printk("gpu_id=%u pid=%u size=%llu",
- __entry->gpu_id,
- __entry->pid,
- __entry->size)
+ TP_printk("gpu_id=%u, ctx_id=%u, mem total=%llu, mem import total=%llu",
+ __entry->gpu_id,
+ __entry->ctx_id,
+ __entry->mem_total,
+ __entry->import_mem_total)
);
#endif /* _TRACE_GPU_MEM_H */
--
2.25.1
[RFC PATCH 3/8] drm: add helper functions for gpu_mem_total and gpu_mem_instance
- Add helper functions for above tracepoints in the drm_gem.{h,c}
files
- Given more tracepoints, a drm_trace.* file may be started
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_gem.c | 49 +++
include/drm/drm_gem.h | 7 ++
3 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b91f0ce8154c..cef8545df1c9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -15,6 +15,7 @@ menuconfig DRM
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
select SYNC_FILE
+ select TRACE_GPU_MEM
# gallium uses SYS_kcmp for os_same_file_description() to de-duplicate
# device and dmabuf fd. Let's make sure that is available for our userspace.
select KCMP
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4dcdec6487bb..24a719b79400 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -49,6 +49,8 @@
#include
#include
+#include
+
#include "drm_internal.h"
/** @file drm_gem.c
@@ -138,6 +140,53 @@ int drm_gem_object_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_object_init);
+/**
+ * drm_gem_trace_gpu_mem_total - emit a total memory trace event
+ * @dev: drm_device to emit trace event for
+ * @delta: size change
+ * @imported: whether the imported or total memory counter should be used
+ *
+ * Emits a `gpu_mem_total` trace event with given parameters.
+ */
+void
+drm_gem_trace_gpu_mem_total(struct drm_device *dev, s64 delta, bool imported)
+{
+ if (imported)
+ atomic64_add(delta, >import_mem_total);
+ else
+ atomic64_add(delta, >mem_total);
+
+ trace_gpu_mem_total(dev->primary->index, 0,
+ atomic64_read(>mem_total),
+ atomic64_read(>import_mem_total));
+}
+EXPORT_SYMBOL(drm_gem_trace_gpu_mem_total);
+
+/**
+ * drm_gem_trace_gpu_mem_instance - emit a per instance memory trace event
+ * @dev: drm_device associated with DRM file
+ * @file: drm_file to emit event for
+ * @delta: size change
+ * @imported: whether the imported or total memory counter should be used
+ *
+ * Emits a `gpu_mem_instance` trace event with given parameters.
+ */
+void
+drm_gem_trace_gpu_mem_instance(struct drm_device *dev, struct drm_file *file,
+ s64 delta, bool imported)
+{
+ if (imported)
+ atomic64_add(delta, >import_mem_instance);
+ else
+ atomic64_add(delta, >mem_instance);
+
+ trace_gpu_mem_total(dev->primary->index,
+ file_inode(file->filp)->i_ino,
+ atomic64_read(>mem_instance),
+ atomic64_read(>import_mem_instance));
+}
+EXPORT_SYMBOL(drm_gem_trace_gpu_mem_instance);
+
/**
* drm_gem_private_object_init - initialize an allocated private GEM object
* @dev: drm_device the object should be initialized for
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 35e7f44c2a75..d61937cce222 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -342,6 +342,13 @@ struct drm_gem_object {
void drm_gem_object_release(struct drm_gem_object *obj);
void drm_gem_object_free(struct kref *kref);
+
+void drm_gem_trace_gpu_mem_total(struct drm_device *dev, s64 delta,
+bool imported);
+void drm_gem_trace_gpu_mem_instance(struct drm_device *dev,
+ struct drm_file *file,
+ s64 delta, bool imported);
+
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
void drm_gem_private_object_init(struct drm_device *dev,
--
2.25.1
[RFC PATCH 0/8] GPU memory tracepoints
This is latest iteration of GPU memory tracepoints [1]. In the past, there were questions about the "big picture" of memory accounting [2], especially given related work on dma-buf heaps and DRM cgroups [3]. Also, there was a desire for a non-driver specific solution. The great news is the dma-buf heaps work as recently landed [4]. It uses sys-fs and the plan is to use it in conjunction with the tracepoint solution [5]. We're aiming for the GPU tracepoint to calculate totals per DRM-instance (a proxy for per-process on Android) and per-DRM device. The cgroups work looks terrific too and hopefully we can deduplicate code once that's merged. Though that's abit of an implementation detail, so long as the "GPU tracepoints" + "dma-buf heap stats" plan sounds good for Android. This series modifies the GPU memory tracepoint API in a non-breaking fashion (patch 1), and adds accounting via the GEM subsystem (patches 2 --> 7). Given the multiple places where memory events happen, there's a bunch trace events scattered in various places. The hardest part is allocation, where each driver has their own API. If there's a better way, do say so. The last patch is incomplete; we would like general feedback before proceeding further. [1] https://lore.kernel.org/lkml/20200302235044.59163-1-zzyi...@google.com/ [2] https://lists.freedesktop.org/archives/dri-devel/2021-January/295120.html [3] https://www.spinics.net/lists/cgroups/msg27867.html [4] https://www.spinics.net/lists/linux-doc/msg97788.html [5] https://source.android.com/devices/graphics/implement-dma-buf-gpu-mem Gurchetan Singh (8): tracing/gpu: modify gpu_mem_total drm: add new tracepoint fields to drm_device and drm_file drm: add helper functions for gpu_mem_total and gpu_mem_instance drm: start using drm_gem_trace_gpu_mem_total drm: start using drm_gem_trace_gpu_mem_instance drm: track real and fake imports in drm_prime_member drm: trace memory import per DRM file drm: trace memory import per DRM device drivers/gpu/drm/Kconfig| 1 + drivers/gpu/drm/drm_gem.c | 65 +- drivers/gpu/drm/drm_internal.h | 4 +-- drivers/gpu/drm/drm_prime.c| 22 +--- include/drm/drm_device.h | 16 + include/drm/drm_file.h | 16 + include/drm/drm_gem.h | 7 include/trace/events/gpu_mem.h | 61 +-- 8 files changed, 166 insertions(+), 26 deletions(-) -- 2.25.1
Re: [PATCH] drm/bridge: analogix_dp: Make PSR-disable non-blocking
(Dropping Andrzej, because that address keeps bouncing. Does
MAINTAINERS and/or .mailmap need updating?)
Apologies for the double reply here, but I forgot to mention one last
thing for now:
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
>
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> > Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> > "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> > accidentally (?) set blocking=true.
>
> IIRC this wasn't accidental.
One other tip that made me think it was accidental was that today, the
|blocking| argument to analogix_dp_send_psr_spd() is always true. If
non-blocking support was intentionally dropped, it seemed like you
should have dropped the non-blocking code too. But that's a weak proof
of your intentions :)
Brian
Re: linux-next: build warning after merge of the drm-misc tree
Hi all,
On Tue, 5 Oct 2021 10:23:23 +0200 Christian König
wrote:
>
> Am 05.10.21 um 09:59 schrieb Stephen Rothwell:
> >
> > After merging the drm-misc tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/linux/dma-buf.h:456: warning: Function parameter or member 'cb_in'
> > not described in 'dma_buf'
> > include/linux/dma-buf.h:456: warning: Function parameter or member 'cb_out'
> > not described in 'dma_buf'
> >
> > Introduced by commit
> >
> >6b51b02a3a0a ("dma-buf: fix and rework dma_buf_poll v7")
>
> Thanks for the notice, going to fix this.
I am still seeing these warnings.
--
Cheers,
Stephen Rothwell
pgpu_52LvRNAd.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/bridge: analogix_dp: Make PSR-disable non-blocking
On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
> On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> > Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> > "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> > accidentally (?) set blocking=true.
>
> IIRC this wasn't accidental.
>
> The reason it became synchronous was:
> - To avoid racing a subsequent PSR entry (if exit takes a long time)
How did this work pre-commit-6c836d965bad then? I don't see any
provision for avoiding subsequent PSR entry. Or I guess that was
implicitly covered by PSR_FLUSH_TIMEOUT_MS, which means we allowed at
least 100ms between exit/entry each time, which was good enough? And
in the "new" implementation, that turned into a running average that
gets measured on each commit? So we're no longer guaranteed 100ms, and
it's even worse if we cheat the timing measurement?
I'm still not sure that "race" is truly a problem without consulting
some kind of hardware documentation though. It wouldn't surprise me if
these things are cancelable.
> - To avoid racing disable/modeset
> - We're not displaying new content while exiting PSR anyways, so there is
>minimal utility in allowing frames to be submitted
> - We're lying to userspace telling them frames are on the screen when we're
>just dropping them on the floor
>
> The actual latency gains from doing this synchronously are minimal since the
> panel will display new content as soon as it can regardless of whether the
> kernel is blocking. There is likely a perceptual difference, but that's only
> because kernel is lying to userspace and skipping frames without consent.
Hmm, you might well be right about some of the first points (I'm still
learning the DRM framework), but I'm a bit skeptical that the
perceptual difference is "only" because we're cheating in some way.
I'm not doing science here, and it's certainly not a blinded test, but
I'm nearly certain this patch cuts out approx 50-80% of the cursor lag
I see without this patch (relative to the current Chrome OS kernel). I
don't see how cheating would produce a smoother cursor movement --
we'd still be dropping frames, and the movement would appear jumpy
somewhere along the way.
In any case, I'm absolutely certain that mainline Linux performs much
much worse with PSR than the current CrOS kernel, but there are some
other potential reasons for that, such as the lack of an
input-notifier [1].
> Going back to the first line, it's entirely possible my memory is failing
> and this was accidental!
Well either way, thanks for the notes. I'll see if I can get anywhere
on proving/disproving that they are relevant, or if they can be worked
around some other way; or perhaps I can regain the lost performance
some other way. It'll be a few days before I get around to that.
Brian
[1] This got locked up in "controversy":
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20180405095000.9756-25-enric.balle...@collabora.com/
Re: [PATCH] drm/bridge: analogix_dp: Make PSR-disable non-blocking
On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote:
> Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
> accidentally (?) set blocking=true.
IIRC this wasn't accidental.
The reason it became synchronous was:
- To avoid racing a subsequent PSR entry (if exit takes a long time)
- To avoid racing disable/modeset
- We're not displaying new content while exiting PSR anyways, so there is
minimal utility in allowing frames to be submitted
- We're lying to userspace telling them frames are on the screen when we're
just dropping them on the floor
The actual latency gains from doing this synchronously are minimal since the
panel will display new content as soon as it can regardless of whether the
kernel is blocking. There is likely a perceptual difference, but that's only
because kernel is lying to userspace and skipping frames without consent.
Going back to the first line, it's entirely possible my memory is failing
and this was accidental!
Sean
>
> This can cause upwards of 60-100ms of unneeded latency when exiting
> self-refresh, which can cause very noticeable lag when, say, moving a
> cursor.
>
> Presumbaly it's OK to let the display finish exiting refresh in parallel
> with clocking out the next video frames, so we shouldn't hold up the
> atomic_enable() step. This also brings behavior in line with the
> downstream ("mainline-derived") variant of the driver currently deployed
> to Chrome OS Rockchip systems.
>
> Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin).
>
> Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
> Cc:
> Cc: Zain Wang
> Cc: Tomasz Figa
> Cc: Heiko Stuebner
> Cc: Sean Paul
> Signed-off-by: Brian Norris
> ---
> CC list is partially constructed from the commit message of the Fixed
> commit
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index b7d2e4449cfa..fbe6eb9df310 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1055,7 +1055,7 @@ static int analogix_dp_disable_psr(struct
> analogix_dp_device *dp)
> psr_vsc.db[0] = 0;
> psr_vsc.db[1] = 0;
>
> - return analogix_dp_send_psr_spd(dp, _vsc, true);
> + return analogix_dp_send_psr_spd(dp, _vsc, false);
> }
>
> /*
> --
> 2.33.0.1079.g6e70778dc9-goog
>
--
Sean Paul, Software Engineer, Google / Chromium OS
[PATCH AUTOSEL 5.14 02/26] drm/msm/a6xx: Serialize GMU communication
From: Rob Clark
[ Upstream commit f6f59072e821901d96c791864a07d57d8ec8d312 ]
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 3 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 40 +++
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b349692219b7..c95985792076 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -296,6 +296,8 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
u32 val;
int request, ack;
+ WARN_ON_ONCE(!mutex_is_locked(>lock));
+
if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return -EINVAL;
@@ -337,6 +339,8 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
{
int bit;
+ WARN_ON_ONCE(!mutex_is_locked(>lock));
+
if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return;
@@ -1478,6 +1482,8 @@ int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
if (!pdev)
return -ENODEV;
+ mutex_init(>lock);
+
gmu->dev = >dev;
of_dma_configure(gmu->dev, node, true);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 71dfa60070cc..19c1a0ddee7a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -44,6 +44,9 @@ struct a6xx_gmu_bo {
struct a6xx_gmu {
struct device *dev;
+ /* For serializing communication with the GMU: */
+ struct mutex lock;
+
struct msm_gem_address_space *aspace;
void * __iomem mmio;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 183b9f9c1b31..64586eb8cda5 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -859,7 +859,7 @@ static int a6xx_zap_shader_init(struct msm_gpu *gpu)
A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS | \
A6XX_RBBM_INT_0_MASK_UCHE_TRAP_INTR)
-static int a6xx_hw_init(struct msm_gpu *gpu)
+static int hw_init(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
@@ -1107,6 +1107,19 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
return ret;
}
+static int a6xx_hw_init(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ int ret;
+
+ mutex_lock(_gpu->gmu.lock);
+ ret = hw_init(gpu);
+ mutex_unlock(_gpu->gmu.lock);
+
+ return ret;
+}
+
static void a6xx_dump(struct msm_gpu *gpu)
{
DRM_DEV_INFO(>pdev->dev, "status: %08x\n",
@@ -1481,7 +1494,9 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
trace_msm_gpu_resume(0);
+ mutex_lock(_gpu->gmu.lock);
ret = a6xx_gmu_resume(a6xx_gpu);
+ mutex_unlock(_gpu->gmu.lock);
if (ret)
return ret;
@@ -1504,7 +1519,9 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
devfreq_suspend_device(gpu->devfreq.devfreq);
+ mutex_lock(_gpu->gmu.lock);
ret = a6xx_gmu_stop(a6xx_gpu);
+ mutex_unlock(_gpu->gmu.lock);
if (ret)
return ret;
@@ -1519,18 +1536,19 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- static DEFINE_MUTEX(perfcounter_oob);
- mutex_lock(_oob);
+ mutex_lock(_gpu->gmu.lock);
/* Force the GPU power on so we can read this register */
a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
*value = gpu_read64(gpu, REG_A6XX_CP_ALWAYS_ON_COUNTER_LO,
- REG_A6XX_CP_ALWAYS_ON_COUNTER_HI);
+ REG_A6XX_CP_ALWAYS_ON_COUNTER_HI);
a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
- mutex_unlock(_oob);
+
+ mutex_unlock(_gpu->gmu.lock);
+
return 0;
}
@@ -1594,6 +1612,16 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
return (unsigned long)busy_time;
}
+void a6xx_gpu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+
+ mutex_lock(_gpu->gmu.lock);
+ a6xx_gmu_set_freq(gpu, opp);
+ mutex_unlock(_gpu->gmu.lock);
+}
+
static struct msm_gem_address_space *
a6xx_create_address_space(struct msm_gpu *gpu, struct
[PATCH] drm/bridge: analogix_dp: Make PSR-disable non-blocking
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor
accidentally (?) set blocking=true.
This can cause upwards of 60-100ms of unneeded latency when exiting
self-refresh, which can cause very noticeable lag when, say, moving a
cursor.
Presumbaly it's OK to let the display finish exiting refresh in parallel
with clocking out the next video frames, so we shouldn't hold up the
atomic_enable() step. This also brings behavior in line with the
downstream ("mainline-derived") variant of the driver currently deployed
to Chrome OS Rockchip systems.
Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin).
Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
Cc:
Cc: Zain Wang
Cc: Tomasz Figa
Cc: Heiko Stuebner
Cc: Sean Paul
Signed-off-by: Brian Norris
---
CC list is partially constructed from the commit message of the Fixed
commit
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b7d2e4449cfa..fbe6eb9df310 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1055,7 +1055,7 @@ static int analogix_dp_disable_psr(struct
analogix_dp_device *dp)
psr_vsc.db[0] = 0;
psr_vsc.db[1] = 0;
- return analogix_dp_send_psr_spd(dp, _vsc, true);
+ return analogix_dp_send_psr_spd(dp, _vsc, false);
}
/*
--
2.33.0.1079.g6e70778dc9-goog
Re: [PATCH v3 00/10] Move vfio_ccw to the new mdev API
On Fri, Oct 01, 2021 at 02:52:41PM -0300, Jason Gunthorpe wrote: > This addresses Cornelia's remark on the earlier patch that ccw has a > confusing lifecycle. While it doesn't seem like the original attempt was > functionally wrong, the result can be made better with a lot of further > work. > > Reorganize the driver so that the mdev owns the private memory and > controls the lifecycle, not the css_driver. The memory associated with the > css_driver lifecycle is only the mdev_parent/mdev_type registration. > > Along the way we change when the sch is quiescent or not to be linked to > the open/close_device lifetime of the vfio_device, which is sort of what > it was tring to do already, just not completely. > > The troublesome racey lifecycle of the css_driver callbacks is made clear > with simple vfio_device refcounting so a callback is only delivered into a > registered vfio_device and has obvious correctness. > > Move the only per-css_driver state, the "available instance" counter, into > the core code and share that logic with many of the other drivers. The > value is kept in the mdev_type memory. > > This is on github: https://github.com/jgunthorpe/linux/commits/vfio_ccw > > v3: > - Rebase to Christoph's group work & rc3; use >vfio_register_emulated_iommu_dev() > - Remove GFP_DMA > - Order mdev_unregister_driver() symmetrically with init > - Rework what is considered a BROKEN event in fsm_close() > - NOP both CCW_EVENT_OPEN/CLOSE > - Documentation updates > - Remane goto label to err_init vfio_ccw_mdev_probe() > - Fix NULL pointer deref in mdev_device_create() > v2: https://lore.kernel.org/r/0-v2-7d3a384024cf+2060-ccw_mdev_...@nvidia.com > - Clean up the lifecycle in ccw with 7 new patches > - Rebase > v1: https://lore.kernel.org/all/7-v2-7667f42c9bad+935-vfio3_...@nvidia.com > > Jason Gunthorpe (10): > vfio/ccw: Remove unneeded GFP_DMA > vfio/ccw: Use functions for alloc/free of the vfio_ccw_private > vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions > vfio/ccw: Convert to use vfio_register_emulated_iommu_dev() IBM folks, what do you want to do with this? I would like to go ahead with these patches so we can get closer to unblocking some of the VFIO core work. These patches: > vfio/ccw: Make the FSM complete and synchronize it to the mdev > vfio/mdev: Consolidate all the device_api sysfs into the core code > vfio/mdev: Add mdev available instance checking to the core > vfio/ccw: Remove private->mdev > vfio: Export vfio_device_try_get() > vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the > mdev Where made to show how to structure this more cleanly as Cornelia asked but are not essential and IBMers could test and fix to get this cleanup when time permits.. Thoughts? Thanks, Jason
[PATCH] drm/i915/execlists: Weak parallel submission support for execlists
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for the existing (hopefully soon deprecated) bonding interface.
We perma-pin these execlists contexts to align with GuC implementation.
v2:
(John Harrison)
- Drop siblings array as num_siblings must be 1
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +++--
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
.../drm/i915/gt/intel_execlists_submission.c | 44 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 -
5 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fb33d0322960..35e87a7d0ea9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,10 +570,6 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
struct intel_engine_cs **siblings = NULL;
intel_engine_mask_t prev_mask;
- /* FIXME: This is NIY for execlists */
- if (!(intel_uc_uses_guc_submission(>gt.uc)))
- return -ENODEV;
-
if (get_user(slot, >engine_index))
return -EFAULT;
@@ -583,6 +579,12 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
if (get_user(num_siblings, >num_siblings))
return -EFAULT;
+ if (!intel_uc_uses_guc_submission(>gt.uc) && num_siblings != 1) {
+ drm_dbg(>drm, "Only 1 sibling (%d) supported in non-GuC
mode\n",
+ num_siblings);
+ return -EINVAL;
+ }
+
if (slot >= set->num_engines) {
drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
slot, set->num_engines);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5634d14052bc..1bec92e1d8e6 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -79,7 +79,8 @@ static int intel_context_active_acquire(struct intel_context
*ce)
__i915_active_acquire(>active);
- if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
+ if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine) ||
+ intel_context_is_parallel(ce))
return 0;
/* Preallocate tracking nodes */
@@ -563,7 +564,6 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
* Callers responsibility to validate that this function is used
* correctly but we use GEM_BUG_ON here ensure that they do.
*/
- GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
GEM_BUG_ON(intel_context_is_pinned(parent));
GEM_BUG_ON(intel_context_is_child(parent));
GEM_BUG_ON(intel_context_is_pinned(child));
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index bedb80057046..2865b422300d 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -927,8 +927,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
static bool ctx_single_port_submission(const struct intel_context *ce)
{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
+ return intel_context_force_single_submission(ce);
}
static bool can_merge_ctx(const struct intel_context *prev,
@@ -2598,6 +2597,46 @@ static void execlists_context_cancel_request(struct
intel_context *ce,
current->comm);
}
+static struct intel_context *
+execlists_create_parallel(struct intel_engine_cs **engines,
+ unsigned int num_siblings,
+ unsigned int width)
+{
+ struct intel_context *parent = NULL, *ce, *err;
+ int i;
+
+ GEM_BUG_ON(num_siblings != 1);
+
+ for (i = 0; i < width; ++i) {
+ ce = intel_context_create(engines[i]);
+ if (!ce) {
+ err = ERR_PTR(-ENOMEM);
+ goto unwind;
+ }
+
+ if (i == 0)
+ parent = ce;
+ else
+ intel_context_bind_parent_child(parent, ce);
+ }
+
+ parent->parallel.fence_context = dma_fence_context_alloc(1);
+
+ intel_context_set_nopreempt(parent);
+ intel_context_set_single_submission(parent);
+ for_each_child(parent, ce) {
+ intel_context_set_nopreempt(ce);
+
Re: [PATCH v3 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
On Tue, 2021-10-19 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> > This simply adds proper support for panel backlights that can be
> > controlled
> > via VESA's backlight control protocol, but which also require that we
> > enable and disable the backlight via PWM instead of via the DPCD
> > interface.
> > We also enable this by default, in order to fix some people's backlights
> > that were broken by not having this enabled.
> >
> > For reference, backlights that require this and use VESA's backlight
> > interface tend to be laptops with hybrid GPUs, but this very well may
> > change in the future.
> >
> > Signed-off-by: Lyude Paul
> > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
> > Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
> > enable/disable")
> > Cc: # v5.12+
> > ---
> > .../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index 569d17b4d00f..594fdc7453ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
> > intel_crtc_state *crtc_state,
> > struct intel_panel *panel = >panel;
> > struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
> >
> > + if (!panel->backlight.edp.vesa.info.aux_enable)
> > + panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
> > + panel-
> > >backlight.pwm_level_max);
>
> What't the story here with the non-inverted max vs. pontetially inverted
> 0 in the counterpart?
OH! Nice catch, I wonder if this explains some of the weirdness with samus-
fi-bdw…
Anyway-unfortunately I don't know the precise answer to if we're supposed to
be inverting the panel backlight level or not, so I'd say we should probably
just go with whatever the Intel HDR AUX interface is currently doing - which
is inverting the panel PWM level when needed. Will fix this in a respin
shortly
>
> > +
> > drm_edp_backlight_enable(_dp->aux,
> > >backlight.edp.vesa.info, level);
> > }
> >
> > @@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
> > struct drm_connector_state
> > struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
> >
> > drm_edp_backlight_disable(_dp->aux,
> > >backlight.edp.vesa.info);
> > +
> > + if (!panel->backlight.edp.vesa.info.aux_enable)
> > + panel->backlight.pwm_funcs->disable(old_conn_state,
> > +
> > intel_backlight_invert_pwm_level(connector, 0));
> > }
> >
> > static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
> > *connector, enum pipe pipe)
> > @@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
> > intel_connector *connector,
> > if (ret < 0)
> > return ret;
> >
> > + if (!panel->backlight.edp.vesa.info.aux_enable) {
> > + ret = panel->backlight.pwm_funcs->setup(connector, pipe);
> > + if (ret < 0) {
> > + drm_err(>drm,
> > + "Failed to setup PWM backlight controls
> > for eDP backlight: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + }
> > panel->backlight.max = panel->backlight.edp.vesa.info.max;
> > panel->backlight.min = 0;
> > if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> > @@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
> > intel_connector *connector)
> > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >
> > - /* TODO: We currently only support AUX only backlight
> > configurations, not backlights which
> > - * require a mix of PWM and AUX controls to work. In the mean
> > time, these machines typically
> > - * work just fine using normal PWM controls anyway.
> > - */
> > - if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> > - drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> > + if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> > drm_dbg_kms(>drm, "AUX Backlight Control
> > Supported!\n");
> > return true;
> > }
> > --
> > 2.31.1
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[PATCH] drm/i915/guc: Set all engine props values for GuC virtual engines
Set all engine props values for GuC virtual engines as a request can point to a virtual engine with GuC submission and these props are used all over the driver. This differs from execlists where a request can only point to a virtual engine. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 38b47e73e35d..1341752dc70e 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -4303,10 +4303,7 @@ guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count, ve->base.flags |= sibling->flags; - ve->base.props.timeslice_duration_ms = - sibling->props.timeslice_duration_ms; - ve->base.props.preempt_timeout_ms = - sibling->props.preempt_timeout_ms; + ve->base.props = sibling->props; } } -- 2.32.0
[PATCH] io-mapping: remove fallback for writecombine
The fallback was introduced in commit 80c33624e472 ("io-mapping: Fixup
for different names of writecombine") to fix the build on microblaze.
5 years later, it seems all archs now provide a pgprot_writecombine(),
so just remove the other possible fallbacks. For microblaze,
pgprot_writecombine() is available since commit 97ccedd793ac
("microblaze: Provide pgprot_device/writecombine macros for nommu").
This is build-tested on microblaze with the following hack to always
build mm/io-mapping.o and without diying on a x86-only macro
(_PAGE_CACHE_MASK)
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: linux...@kvack.org
Cc: Peter Zijlstra
Cc: Andrew Morton
Signed-off-by: Lucas De Marchi
---
include/linux/io-mapping.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e9743cfd8585..66a774d2710e 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -132,13 +132,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->base = base;
iomap->size = size;
-#if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
- iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
-#elif defined(pgprot_writecombine)
iomap->prot = pgprot_writecombine(PAGE_KERNEL);
-#else
- iomap->prot = pgprot_noncached(PAGE_KERNEL);
-#endif
return iomap;
}
--
2.33.1
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Increase timeout in requests perf selftest
On 10/11/2021 10:57, Matthew Brost wrote: perf_parallel_engines is micro benchmark to test i915 request scheduling. The test creates a thread per physical engine and submits NOP requests and waits the requests to complete in a loop. In execlists mode this works perfectly fine as powerful CPU has enough cores to feed each engine and process the CSBs. With GuC submission the uC gets overwhelmed as all threads feed into a single CTB channel and the GuC gets bombarded with CSBs as contexts are immediately switched in and out on the engines due to the zero runtime of the requests. When the GuC is overwhelmed scheduling of contexts is unfair due to the nature of the GuC scheduling algorithm. This behavior is understood and deemed acceptable as this micro benchmark isn't close to real world use case. Increasing the timeout of wait period for requests to complete. This makes the test understand that is ok for contexts to get starved in this scenario. A future patch / cleanup may just delete these micro benchmark tests as they basically mean nothing. We care about real workloads not made up ones. Signed-off-by: Matthew Brost Reviewed-by: John Harrison --- drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c index d67710d10615..6496671a113c 100644 --- a/drivers/gpu/drm/i915/selftests/i915_request.c +++ b/drivers/gpu/drm/i915/selftests/i915_request.c @@ -2805,7 +2805,7 @@ static int p_sync0(void *arg) i915_request_add(rq); err = 0; - if (i915_request_wait(rq, 0, HZ / 5) < 0) + if (i915_request_wait(rq, 0, HZ) < 0) err = -ETIME; i915_request_put(rq); if (err) @@ -2876,7 +2876,7 @@ static int p_sync1(void *arg) i915_request_add(rq); err = 0; - if (prev && i915_request_wait(prev, 0, HZ / 5) < 0) + if (prev && i915_request_wait(prev, 0, HZ) < 0) err = -ETIME; i915_request_put(prev); prev = rq;
Re: [PATCH 4/6] dma-buf: Add an API for exporting sync files (v12)
FWIW, I'm using this IOCTL in a wlroots patchset [1]. To detect support for this IOCTL, is there anything better than creating a DMA-BUF and checking for ENOTTY? I'd like to disable explicit sync at init-time if this is missing. [1]: https://github.com/swaywm/wlroots/pull/3282
[Bug 214197] [Asus G713QY] RX6800M not usable after exiting Vulkan application
https://bugzilla.kernel.org/show_bug.cgi?id=214197 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- Does this patch help? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
From: Fangzhi Zuo
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine whether to increase/reduce
payloads.
Signed-off-by: Fangzhi Zuo
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/gpu/drm/amd/display/dc/dc_stream.h| 13 +
5 files changed, 333 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8be04be19124..935a50d6e933 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2354,6 +2354,11 @@ static enum surface_update_type
check_update_surfaces_for_stream(
if (stream_update->dsc_config)
su_flags->bits.dsc_changed = 1;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update)
+ su_flags->bits.mst_bw = 1;
+#endif
+
if (su_flags->raw != 0)
overall_type = UPDATE_TYPE_FULL;
@@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc *dc,
if (stream_update->dsc_config)
dp_update_dsc_config(pipe_ctx);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update) {
+ if (stream_update->mst_bw_update->is_increase)
+ dc_link_increase_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ else
+ dc_link_reduce_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ }
+#endif
+
if (stream_update->pending_test_pattern) {
dc_link_dp_set_test_pattern(stream->link,
stream->test_pattern.type,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index e5d6cbd7ea78..b23972b6a27c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct
pipe_ctx *pipe_ctx)
static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
+#endif
const struct dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
@@ -3267,6 +3270,9 @@ static void update_mst_stream_alloc_table(
work_table[i].slot_count =
proposed_table->stream_allocations[i].slot_count;
work_table[i].stream_enc = stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc;
+#endif
}
}
@@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
struct dc_link *link = stream->link;
struct link_encoder *link_encoder = NULL;
struct stream_encoder *stream_encoder = pipe_ctx->stream_res.stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_link_encoder *hpo_dp_link_encoder = link->hpo_dp_link_enc;
+ struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
pipe_ctx->stream_res.hpo_dp_stream_enc;
+#endif
struct dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
@@ -3416,7 +3426,14 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
_table,
true)) {
update_mst_stream_alloc_table(
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ link,
+ pipe_ctx->stream_res.stream_enc,
+ pipe_ctx->stream_res.hpo_dp_stream_enc,
+ _table);
+#else
link, pipe_ctx->stream_res.stream_enc,
_table);
+#endif
}
else
DC_LOG_WARNING("Failed to update"
@@ -3430,6 +3447,20 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
link->mst_stream_alloc_table.stream_count);
for (i = 0; i < MAX_CONTROLLER_NUM;
Re: [PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
On Wed, Oct 20, 2021 at 3:50 PM Bhawanpreet Lakha
wrote:
>
> From: Fangzhi Zuo
Please include a patch description.
Alex
>
> Signed-off-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
> .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
> drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
> drivers/gpu/drm/amd/display/dc/dc_stream.h| 13 +
> 5 files changed, 333 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 8be04be19124..935a50d6e933 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -2354,6 +2354,11 @@ static enum surface_update_type
> check_update_surfaces_for_stream(
> if (stream_update->dsc_config)
> su_flags->bits.dsc_changed = 1;
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update)
> + su_flags->bits.mst_bw = 1;
> +#endif
> +
> if (su_flags->raw != 0)
> overall_type = UPDATE_TYPE_FULL;
>
> @@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc
> *dc,
> if (stream_update->dsc_config)
> dp_update_dsc_config(pipe_ctx);
>
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + if (stream_update->mst_bw_update) {
> + if (stream_update->mst_bw_update->is_increase)
> +
> dc_link_increase_mst_payload(pipe_ctx,
> stream_update->mst_bw_update->mst_stream_bw);
> + else
> + dc_link_reduce_mst_payload(pipe_ctx,
> stream_update->mst_bw_update->mst_stream_bw);
> + }
> +#endif
> +
> if (stream_update->pending_test_pattern) {
> dc_link_dp_set_test_pattern(stream->link,
> stream->test_pattern.type,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index e5d6cbd7ea78..b23972b6a27c 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct
> pipe_ctx *pipe_ctx)
> static void update_mst_stream_alloc_table(
> struct dc_link *link,
> struct stream_encoder *stream_enc,
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
> stream_enc to dio_stream_enc?
> +#endif
> const struct dp_mst_stream_allocation_table *proposed_table)
> {
> struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = {
> 0 };
> @@ -3267,6 +3270,9 @@ static void update_mst_stream_alloc_table(
> work_table[i].slot_count =
>
> proposed_table->stream_allocations[i].slot_count;
> work_table[i].stream_enc = stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc;
> +#endif
> }
> }
>
> @@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct
> pipe_ctx *pipe_ctx)
> struct dc_link *link = stream->link;
> struct link_encoder *link_encoder = NULL;
> struct stream_encoder *stream_encoder =
> pipe_ctx->stream_res.stream_enc;
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + struct hpo_dp_link_encoder *hpo_dp_link_encoder =
> link->hpo_dp_link_enc;
> + struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
> pipe_ctx->stream_res.hpo_dp_stream_enc;
> +#endif
> struct dp_mst_stream_allocation_table proposed_table = {0};
> struct fixed31_32 avg_time_slots_per_mtp;
> struct fixed31_32 pbn;
> @@ -3416,7 +3426,14 @@ enum dc_status dc_link_allocate_mst_payload(struct
> pipe_ctx *pipe_ctx)
> _table,
> true)) {
> update_mst_stream_alloc_table(
> +#if defined(CONFIG_DRM_AMD_DC_DCN)
> + link,
> + pipe_ctx->stream_res.stream_enc,
> +
> pipe_ctx->stream_res.hpo_dp_stream_enc,
> + _table);
> +#else
> link,
> pipe_ctx->stream_res.stream_enc, _table);
> +#endif
> }
> else
> DC_LOG_WARNING("Failed to update"
> @@ -3430,6 +3447,20 @@ enum dc_status dc_link_allocate_mst_payload(struct
> pipe_ctx *pipe_ctx)
> link->mst_stream_alloc_table.stream_count);
>
> for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
> +#if
[PATCH 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
v4:
*fixed typo and formatting
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
Reviewed-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +--
include/drm/drm_dp_mst_helper.h | 5 ++-
6 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr);
+ drm_dp_update_payload_part1(mst_mgr, 1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5ab3b3a46e89..857c5d15e81d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3353,6 +3353,10 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_update_payload_part1() - Execute payload update part 1
* @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
*
* This iterates over all proposed virtual channels, and tries to
* allocate space in the link for them. For 0->slots transitions,
@@ -3363,12 +3367,12 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
* after calling this the driver should generate ACT and payload
* packets.
*/
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
start_slot)
{
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
- int cur_slots = 1;
+ int cur_slots = start_slot;
bool skip;
mutex_lock(>payload_lock);
@@ -4503,6 +4507,27 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
uint8_t link_encoding_cap)
+{
+ if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+ mst_state->total_avail_slots = 64;
+ mst_state->start_slot = 0;
+ } else {
+ mst_state->total_avail_slots = 63;
+ mst_state->start_slot = 1;
+ }
+
+ DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ?
"128b/132b":"8b/10b",
+ mst_state->mgr);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
/**
* drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
* @mgr: manager for this port
@@ -5222,7 +5247,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, payload_count = 0;
+ int avail_slots = mst_state->total_avail_slots, payload_count = 0;
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -5251,7 +5276,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
}
}
drm_dbg_atomic(mgr->dev, "[MST MGR:%p] mst state %p VCPI avail=%d
used=%d\n",
-
[PATCH 3/3] drm/i915/guc/slpc: Update boost sysfs hooks for SLPC
Add a helper to sort through the SLPC/RPS cases of get/set methods.
Boost frequency will be modified as long as it is within the constraints
of RP0 and if it is different from the existing one. We will set min
freq to boost only if there is an active waiter.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rps.c | 44 +
drivers/gpu/drm/i915/gt/intel_rps.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 18 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
drivers/gpu/drm/i915/i915_sysfs.c | 21 ++
5 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 023e9c0b9f4a..19c57aac9553 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -935,6 +935,50 @@ void intel_rps_park(struct intel_rps *rps)
GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
}
+u32 intel_rps_get_boost_frequency(struct intel_rps *rps)
+{
+ struct intel_guc_slpc *slpc = rps_to_slpc(rps);
+
+ if (rps_uses_slpc(rps))
+ return slpc->boost_freq;
+ else
+ return intel_gpu_freq(rps, rps->boost_freq);
+}
+
+static int set_boost_freq(struct intel_rps *rps, u32 val)
+{
+ bool boost = false;
+
+ /* Validate against (static) hardware limits */
+ val = intel_freq_opcode(rps, val);
+ if (val < rps->min_freq || val > rps->max_freq)
+ return -EINVAL;
+
+ mutex_lock(>lock);
+ if (val != rps->boost_freq) {
+ rps->boost_freq = val;
+ boost = atomic_read(>num_waiters);
+ }
+ mutex_unlock(>lock);
+ if (boost)
+ schedule_work(>work);
+
+ return 0;
+}
+
+int intel_rps_set_boost_frequency(struct intel_rps *rps, u32 freq)
+{
+ struct intel_guc_slpc *slpc;
+
+ if (rps_uses_slpc(rps)) {
+ slpc = rps_to_slpc(rps);
+
+ return intel_guc_slpc_set_boost_freq(slpc, freq);
+ } else {
+ return set_boost_freq(rps, freq);
+ }
+}
+
void intel_rps_update_waiters(struct intel_rps *rps)
{
struct intel_guc_slpc *slpc = rps_to_slpc(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 4ca9924cb5ed..ce81094cf58e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -24,6 +24,8 @@ void intel_rps_park(struct intel_rps *rps);
void intel_rps_unpark(struct intel_rps *rps);
void intel_rps_boost(struct i915_request *rq);
void intel_rps_update_waiters(struct intel_rps *rps);
+u32 intel_rps_get_boost_frequency(struct intel_rps *rps);
+int intel_rps_set_boost_frequency(struct intel_rps *rps, u32 freq);
int intel_rps_set(struct intel_rps *rps, u8 val);
void intel_rps_mark_interactive(struct intel_rps *rps, bool interactive);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index a104371a8b79..7881bc1a5af8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -613,6 +613,24 @@ void intel_guc_slpc_boost(struct intel_guc_slpc *slpc)
slpc->num_waiters++;
}
+int intel_guc_slpc_set_boost_freq(struct intel_guc_slpc *slpc, u32 val)
+{
+ if (val < slpc->min_freq || val > slpc->rp0_freq)
+ return -EINVAL;
+
+ if (val != slpc->boost_freq) {
+ slpc->boost_freq = val;
+
+ /* Apply only if there are active waiters */
+ if (slpc->num_waiters)
+ return slpc_set_param(slpc,
+
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ slpc->boost_freq);
+ }
+
+ return 0;
+}
+
void intel_guc_slpc_update_waiters(struct intel_guc_slpc *slpc)
{
/* Return min back to the softlimit.
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
index 25093dfdea0b..d8191f2b965b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
@@ -34,6 +34,7 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc);
void intel_guc_slpc_fini(struct intel_guc_slpc *slpc);
int intel_guc_slpc_set_max_freq(struct intel_guc_slpc *slpc, u32 val);
int intel_guc_slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 val);
+int intel_guc_slpc_set_boost_freq(struct intel_guc_slpc *slpc, u32 val);
int intel_guc_slpc_get_max_freq(struct intel_guc_slpc *slpc, u32 *val);
int intel_guc_slpc_get_min_freq(struct intel_guc_slpc *slpc, u32 *val);
int intel_guc_slpc_print_info(struct intel_guc_slpc *slpc, struct drm_printer
*p);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index cdf0e9c6fd73..c62eb0c8eb45 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++
[PATCH 2/3] drm/i915/guc/slpc: Add waitboost functionality for SLPC
Add helpers in RPS code for handling SLPC and non-SLPC cases.
When a boost is requested in the SLPC case, we can ask GuC to ramp
up the frequency by setting the minimum frequency to RP0. Reset the
frequency back to the min softlimit when there are no more waiters.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rps.c | 13 ++
drivers/gpu/drm/i915/gt/intel_rps.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 28 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 2 ++
drivers/gpu/drm/i915/i915_request.c | 2 +-
5 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 172de6c9f949..023e9c0b9f4a 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -935,6 +935,16 @@ void intel_rps_park(struct intel_rps *rps)
GT_TRACE(rps_to_gt(rps), "park:%x\n", rps->cur_freq);
}
+void intel_rps_update_waiters(struct intel_rps *rps)
+{
+ struct intel_guc_slpc *slpc = rps_to_slpc(rps);
+
+ if (rps_uses_slpc(rps))
+ intel_guc_slpc_update_waiters(slpc);
+ else
+ atomic_dec(>num_waiters);
+}
+
void intel_rps_boost(struct i915_request *rq)
{
if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
@@ -944,6 +954,9 @@ void intel_rps_boost(struct i915_request *rq)
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, >fence.flags)) {
struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
+ if (rps_uses_slpc(rps))
+ return intel_guc_slpc_boost(rps_to_slpc(rps));
+
if (atomic_fetch_inc(>num_waiters))
return;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 11960d64ca82..4ca9924cb5ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -23,6 +23,7 @@ void intel_rps_disable(struct intel_rps *rps);
void intel_rps_park(struct intel_rps *rps);
void intel_rps_unpark(struct intel_rps *rps);
void intel_rps_boost(struct i915_request *rq);
+void intel_rps_update_waiters(struct intel_rps *rps);
int intel_rps_set(struct intel_rps *rps, u8 val);
void intel_rps_mark_interactive(struct intel_rps *rps, bool interactive);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 4a2acb8f2cc7..a104371a8b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -598,6 +598,34 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
return 0;
}
+void intel_guc_slpc_boost(struct intel_guc_slpc *slpc)
+{
+ /* Raise min freq to boost. It's possible that
+* this is greater than current max. But it will
+* certainly be limited by RP0. An error setting
+* the min param is not fatal.
+*/
+ if (!slpc->num_waiters)
+ slpc_set_param(slpc,
+ SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ slpc->boost_freq);
+
+ slpc->num_waiters++;
+}
+
+void intel_guc_slpc_update_waiters(struct intel_guc_slpc *slpc)
+{
+ /* Return min back to the softlimit.
+* This is called during request retire,
+* so we don't need to fail that if the
+* set_param fails.
+*/
+ if (!(--slpc->num_waiters))
+ slpc_set_param(slpc,
+ SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ slpc->min_freq_softlimit);
+}
+
int intel_guc_slpc_print_info(struct intel_guc_slpc *slpc, struct drm_printer
*p)
{
struct drm_i915_private *i915 = slpc_to_i915(slpc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
index e45054d5b9b4..25093dfdea0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
@@ -38,5 +38,7 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc *slpc,
u32 *val);
int intel_guc_slpc_get_min_freq(struct intel_guc_slpc *slpc, u32 *val);
int intel_guc_slpc_print_info(struct intel_guc_slpc *slpc, struct drm_printer
*p);
void intel_guc_pm_intrmsk_enable(struct intel_gt *gt);
+void intel_guc_slpc_boost(struct intel_guc_slpc *slpc);
+void intel_guc_slpc_update_waiters(struct intel_guc_slpc *slpc);
#endif
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2c3cd6e635b5..ef056137dbe1 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -339,7 +339,7 @@ bool i915_request_retire(struct i915_request *rq)
}
if (test_and_set_bit(I915_FENCE_FLAG_BOOST, >fence.flags))
- atomic_dec(>engine->gt->rps.num_waiters);
+ intel_rps_update_waiters(>engine->gt->rps);
[PATCH 1/3] drm/i915/guc/slpc: Define and initialize boost frequency
Boost frequency is initialized at RP0. Also define num_waiters
which can track the pending boost requests. This is set to 0 when
we enable SLPC.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 65a3e7fdb2b2..4a2acb8f2cc7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -522,6 +522,14 @@ static void slpc_get_rp_values(struct intel_guc_slpc *slpc)
GT_FREQUENCY_MULTIPLIER;
slpc->min_freq = REG_FIELD_GET(RPN_CAP_MASK, rp_state_cap) *
GT_FREQUENCY_MULTIPLIER;
+
+ slpc->boost_freq = slpc->rp0_freq;
+}
+
+static void slpc_reset_waiters(struct intel_guc_slpc *slpc)
+{
+ /* min, max and boost frequencies have all been reset */
+ slpc->num_waiters = 0;
}
/*
@@ -585,6 +593,8 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
return ret;
}
+ slpc_reset_waiters(slpc);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h
index 41d13527666f..558247d1f3ad 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.h
@@ -20,10 +20,13 @@ struct intel_guc_slpc {
u32 min_freq;
u32 rp0_freq;
u32 rp1_freq;
+ u32 boost_freq;
/* frequency softlimits */
u32 min_freq_softlimit;
u32 max_freq_softlimit;
+
+ u32 num_waiters;
};
#endif
--
2.25.0
[PATCH 0/3] drm/i915/guc/slpc: Implement waitboost for SLPC
Waitboost is a legacy feature implemented in the Host Turbo algorithm. This patch set implements it for the SLPC path. A "boost" happens when user calls gem_wait ioctl on a submission that has not landed on HW yet. GT frequency gets temporarily bumped to RP0 to allow the previous request to finish quickly. We achieve this on SLPC by setting the min frequency, SLPC will set that as the requested frequency. Like before, boost frequency is configurable through sysfs, so we can adjust it to any specific value as long as it is between [min, RP0]. Signed-off-by: Vinay Belgaumkar Vinay Belgaumkar (3): drm/i915/guc/slpc: Define and initialize boost frequency drm/i915/guc/slpc: Add waitboost functionality for SLPC drm/i915/guc/slpc: Update boost sysfs hooks for SLPC drivers/gpu/drm/i915/gt/intel_rps.c | 57 +++ drivers/gpu/drm/i915/gt/intel_rps.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 56 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 3 + .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 + drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_sysfs.c | 21 ++- 7 files changed, 127 insertions(+), 18 deletions(-) -- 2.25.0
[PATCH 4/4] drm/amd/display: Add DP 2.0 MST DM Support
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e56f73e299ef..875425ee91d0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10741,6 +10741,8 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
#if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_mst_fairness_vars vars[MAX_PIPES];
#endif
+ struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_mst_topology_mgr *mgr;
trace_amdgpu_dm_atomic_check_begin(state);
@@ -10948,6 +10950,33 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding
format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ if (!mgr->mst_state )
+ continue;
+
+ drm_connector_list_iter_begin(dev, );
+ drm_for_each_connector_iter(connector, ) {
+ int id = connector->index;
+
+ if (id == mst_state->mgr->conn_base_id) {
+ aconnector = to_amdgpu_dm_connector(connector);
+ link_coding_cap =
dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+ drm_dp_mst_update_slots(mst_state,
link_coding_cap);
+
+ break;
+ }
+ }
+ drm_connector_list_iter_end();
+
+ }
+#endif
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 9b3ad56607bb..1a68a674913c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -294,6 +294,9 @@ static ssize_t dp_link_settings_write(struct file *f, const
char __user *buf,
case LINK_RATE_RBR2:
case LINK_RATE_HIGH2:
case LINK_RATE_HIGH3:
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ case LINK_RATE_UHBR10:
+#endif
break;
default:
valid_input = false;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6169488e2011..53b5cc7b0679 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -219,6 +219,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
bool ret;
+ u8 link_coding_cap;
aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
/* Accessing the connector state is required for vcpi_slots allocation
@@ -238,6 +239,8 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
mst_port = aconnector->port;
+ link_coding_cap =
dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+
if (enable) {
ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port,
@@ -251,7 +254,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr, 1);
+ drm_dp_update_payload_part1(mst_mgr, (link_coding_cap ==
DP_CAP_ANSI_128B132B) ? 0:1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
--
2.25.1
[PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/gpu/drm/amd/display/dc/dc_stream.h| 13 +
5 files changed, 333 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8be04be19124..935a50d6e933 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2354,6 +2354,11 @@ static enum surface_update_type
check_update_surfaces_for_stream(
if (stream_update->dsc_config)
su_flags->bits.dsc_changed = 1;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update)
+ su_flags->bits.mst_bw = 1;
+#endif
+
if (su_flags->raw != 0)
overall_type = UPDATE_TYPE_FULL;
@@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc *dc,
if (stream_update->dsc_config)
dp_update_dsc_config(pipe_ctx);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update) {
+ if (stream_update->mst_bw_update->is_increase)
+ dc_link_increase_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ else
+ dc_link_reduce_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ }
+#endif
+
if (stream_update->pending_test_pattern) {
dc_link_dp_set_test_pattern(stream->link,
stream->test_pattern.type,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index e5d6cbd7ea78..b23972b6a27c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct
pipe_ctx *pipe_ctx)
static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
+#endif
const struct dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
@@ -3267,6 +3270,9 @@ static void update_mst_stream_alloc_table(
work_table[i].slot_count =
proposed_table->stream_allocations[i].slot_count;
work_table[i].stream_enc = stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc;
+#endif
}
}
@@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
struct dc_link *link = stream->link;
struct link_encoder *link_encoder = NULL;
struct stream_encoder *stream_encoder = pipe_ctx->stream_res.stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_link_encoder *hpo_dp_link_encoder = link->hpo_dp_link_enc;
+ struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
pipe_ctx->stream_res.hpo_dp_stream_enc;
+#endif
struct dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
@@ -3416,7 +3426,14 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
_table,
true)) {
update_mst_stream_alloc_table(
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ link,
+ pipe_ctx->stream_res.stream_enc,
+ pipe_ctx->stream_res.hpo_dp_stream_enc,
+ _table);
+#else
link, pipe_ctx->stream_res.stream_enc,
_table);
+#endif
}
else
DC_LOG_WARNING("Failed to update"
@@ -3430,6 +3447,20 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
link->mst_stream_alloc_table.stream_count);
for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ DC_LOG_MST("stream_enc[%d]: %p "
+ "stream[%d].hpo_dp_stream_enc: %p "
+ "stream[%d].vcp_id: %d "
+ "stream[%d].slot_count: %d\n",
+ i,
+ (void *)
[PATCH 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
v4:
*fixed typo and formatting
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
Reviewed-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 38 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +-
include/drm/drm_dp_mst_helper.h | 5 ++-
6 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr);
+ drm_dp_update_payload_part1(mst_mgr, 1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5ab3b3a46e89..82ee6791576c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3353,6 +3353,10 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_update_payload_part1() - Execute payload update part 1
* @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
*
* This iterates over all proposed virtual channels, and tries to
* allocate space in the link for them. For 0->slots transitions,
@@ -3360,15 +3364,15 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
* transitions, this writes the updated VCPIs and removes the
* remote VC payloads.
*
- * after calling this the driver should generate ACT and payload
+ *after calling this the driver should generate ACT and payload
* packets.
*/
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
start_slot)
{
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
- int cur_slots = 1;
+ int cur_slots = start_slot;
bool skip;
mutex_lock(>payload_lock);
@@ -4503,6 +4507,27 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
uint8_t link_encoding_cap)
+{
+ if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+ mst_state->total_avail_slots = 64;
+ mst_state->start_slot = 0;
+ } else {
+ mst_state->total_avail_slots = 63;
+ mst_state->start_slot = 1;
+ }
+
+ DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ?
"128b/132b":"8b/10b",
+ mst_state->mgr);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
/**
* drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
* @mgr: manager for this port
@@ -5222,7 +5247,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, payload_count = 0;
+ int avail_slots = mst_state->total_avail_slots, payload_count = 0;
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -5251,7 +5276,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
[PATCH 1/4] drm: Remove slot checks in dp mst topology during commit
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ad0795afc21c..5ab3b3a46e89 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4332,10 +4332,6 @@ static int drm_dp_init_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
{
int ret;
- /* max. time slots - one slot for MTP header */
- if (slots > 63)
- return -ENOSPC;
-
vcpi->pbn = pbn;
vcpi->aligned_pbn = slots * mgr->pbn_div;
vcpi->num_slots = slots;
@@ -4538,7 +4534,7 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
if (ret) {
- drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d max=63
ret=%d\n",
+ drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d ret=%d\n",
DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
drm_dp_mst_topology_put_port(port);
goto out;
--
2.25.1
Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
On Wed, Oct 20, 2021 at 08:40:05AM -0700, Lucas De Marchi wrote:
> On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
> > Add a helper that calls remap_pfn_range for an struct io_mapping, relying
> > on the pgprot pre-validation done when creating the mapping instead of
> > doing it at runtime.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > include/linux/io-mapping.h | 3 +++
> > mm/Kconfig | 3 +++
> > mm/Makefile| 1 +
> > mm/io-mapping.c| 29 +
> > 4 files changed, 36 insertions(+)
> > create mode 100644 mm/io-mapping.c
> >
> > diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
> > index c093e81310a9b3..e9743cfd858527 100644
> > --- a/include/linux/io-mapping.h
> > +++ b/include/linux/io-mapping.h
> > @@ -220,3 +220,6 @@ io_mapping_free(struct io_mapping *iomap)
> > }
> >
> > #endif /* _LINUX_IO_MAPPING_H */
> > +
> > +int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct
> > *vma,
> > + unsigned long addr, unsigned long pfn, unsigned long size);
>
> I'm not sure what exactly brought me to check this, but while debugging
> I noticed this outside the header guard. But then after some more checks I
> saw nothing actually selects CONFIG_IO_MAPPING because commit using
> it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use
> io_mapping_map_user"")
>
> Is this something we want to re-attempt moving to mm/ ?
Yes, it would be very good to unexport apply_to_page_range(), it's a
terrible interface to expose.
Re: [PATCH v2] drm/ttm: Do not put non-struct page memory into PUD/PMDs
On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> > I think the patch subject needs updating to reflect that we're disabling
> > PUD/PMDs completely.
> > With that fixed,
Everyone is OK with this?
drm/ttm: remove ttm_bo_vm_insert_huge()
The huge page functionality in TTM does not work safely because PUD and
PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And vmf_insert_pfn_pmd_prot() unconditionally sets
entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.
As such gup_huge_pmd() will try to deref a struct page:
head = try_grab_compound_head(pmd_page(orig), refs, flags);
and thus crash.
So, iomem cannot be installed using vmf_insert_pfn_pud/pmd_prot().
Thomas further notices that the drivers are not expecting the struct page
to be used by anything - in particular the refcount incr above will cause
them to malfunction. This means even the struct page memory cannot be
used.
Therefore everything about this is not able to fully work correctly
considering GUP_fast. Delete it entirely. It can return someday along with
a proper PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast.
Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Reviewed-by: Christian König
Reviewed-by: Thomas Hellström
Signed-off-by: Jason Gunthorpe
Re: [PATCH v4 2/7] dt-bindings: mediatek, dp: Add Display Port binding
Hi Rob, On Mon, Oct 18, 2021 at 02:38:33PM -0500, Rob Herring wrote: > On Mon, Oct 18, 2021 at 9:19 AM Markus Schneider-Pargmann > wrote: > > > > Hi Rob, > > > > On Mon, Oct 11, 2021 at 07:43:16PM -0500, Rob Herring wrote: > > > On Mon, Oct 11, 2021 at 11:46:19AM +0200, Markus Schneider-Pargmann wrote: > > > > This controller is present on several mediatek hardware. Currently > > > > mt8195 and mt8395 have this controller without a functional difference, > > > > so only one compatible field is added. > > > > > > > > The controller can have two forms, as a normal display port and as an > > > > embedded display port. > > > > > > > > Signed-off-by: Markus Schneider-Pargmann > > > > --- > > > > .../display/mediatek/mediatek,dp.yaml | 89 +++ > > > > 1 file changed, 89 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > > > > new file mode 100644 > > > > index ..f7a35962c23b > > > > --- /dev/null > > > > +++ > > > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml > > > > @@ -0,0 +1,89 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dp.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Mediatek Display Port Controller > > > > + > > > > +maintainers: > > > > + - CK Hu > > > > + - Jitao shi > > > > + > > > > +description: | > > > > + Device tree bindings for the Mediatek (embedded) Display Port > > > > controller > > > > + present on some Mediatek SoCs. > > > > + > > > > +properties: > > > > + compatible: > > > > +enum: > > > > + - mediatek,mt8195-edp_tx > > > > + - mediatek,mt8195-dp_tx > > > > > > Are these blocks different? > > > > Good point, the registers of these blocks are described in its own > > chapter each. Also I do need to distinguish between both in the driver. > > Would you suggest making this distinction differently or keep it as two > > compatibles? > > If the registers are all the same, then it should be the same > compatible. If you still need to distinguish, then you should have a > panel or connector node that will let you do that. Thank you. Good idea to check with the connector node, I have changed it as you suggested. > > Also, s/_/-/ in the compatible string. Done. Thanks, Markus
Re: Lockdep spalt on killing a processes
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this
properly.
Christian.
So we had some discussions with Christian regarding irq_work and agreed
I should look into doing it but stepping back for a sec -
Why we insist on calling the dma_fence_cb with fence->lock locked ? Is
it because of dma_fence_add_callback ?
Because we first test for DMA_FENCE_FLAG_SIGNALED_BIT and only after
that lock the fence->lock ? If so, can't we
move DMA_FENCE_FLAG_SIGNALED_BIT check inside the locked section ?
Because if in theory
we could call the cb with unlocked fence->lock (i.e. this kind of
iteration
https://elixir.bootlin.com/linux/v5.15-rc6/source/drivers/gpu/drm/ttm/ttm_resource.c#L117)
we wouldn't have the lockdep splat. And in general, is it really
the correct approach to call a third party code from a call back with
locked spinlock ? We don't know what the cb does inside
and I don't see any explicit restrictions in documentation of
dma_fence_func_t what can and cannot be done there.
Andrey
Am 01.10.21 um 17:10 schrieb Andrey Grodzovsky:
From what I see here you supposed to have actual deadlock and not
only warning, sched_fence->finished is first signaled from within
hw fence done callback (drm_sched_job_done_cb) but then again from
within it's own callback (drm_sched_entity_kill_jobs_cb) and so
looks like same fence object is recursively signaled twice. This
leads to attempt to lock fence->lock second time while it's already
locked. I don't see a need to call drm_sched_fence_finished from
within drm_sched_entity_kill_jobs_cb as this callback already registered
on sched_fence->finished fence (entity->last_scheduled ==
s_fence->finished) and hence the signaling already took place.
Andrey
On 2021-10-01 6:50 a.m., Christian König wrote:
Hey, Andrey.
while investigating some memory management problems I've got the
logdep splat below.
Looks like something is wrong with drm_sched_entity_kill_jobs_cb(),
can you investigate?
Thanks,
Christian.
[11176.741052]
[11176.741056] WARNING: possible recursive locking detected
[11176.741060] 5.15.0-rc1-00031-g9d546d600800 #171 Not tainted
[11176.741066]
[11176.741070] swapper/12/0 is trying to acquire lock:
[11176.741074] 9c337ed175a8 (>lock){-.-.}-{3:3}, at:
dma_fence_signal+0x28/0x80
[11176.741088]
but task is already holding lock:
[11176.741092] 9c337ed172a8 (>lock){-.-.}-{3:3}, at:
dma_fence_signal+0x28/0x80
[11176.741100]
other info that might help us debug this:
[11176.741104] Possible unsafe locking scenario:
[11176.741108] CPU0
[11176.741110]
[11176.741113] lock(>lock);
[11176.741118] lock(>lock);
[11176.741122]
*** DEADLOCK ***
[11176.741125] May be due to missing lock nesting notation
[11176.741128] 2 locks held by swapper/12/0:
[11176.741133] #0: 9c339c30f768
(>fence_drv.lock){-.-.}-{3:3}, at: dma_fence_signal+0x28/0x80
[11176.741142] #1: 9c337ed172a8 (>lock){-.-.}-{3:3}, at:
dma_fence_signal+0x28/0x80
[11176.741151]
stack backtrace:
[11176.741155] CPU: 12 PID: 0 Comm: swapper/12 Not tainted
5.15.0-rc1-00031-g9d546d600800 #171
[11176.741160] Hardware name: System manufacturer System Product
Name/PRIME X399-A, BIOS 0808 10/12/2018
[11176.741165] Call Trace:
[11176.741169]
[11176.741173] dump_stack_lvl+0x5b/0x74
[11176.741181] dump_stack+0x10/0x12
[11176.741186] __lock_acquire.cold+0x208/0x2df
[11176.741197] lock_acquire+0xc6/0x2d0
[11176.741204] ? dma_fence_signal+0x28/0x80
[11176.741212] _raw_spin_lock_irqsave+0x4d/0x70
[11176.741219] ? dma_fence_signal+0x28/0x80
[11176.741225] dma_fence_signal+0x28/0x80
[11176.741230] drm_sched_fence_finished+0x12/0x20 [gpu_sched]
[11176.741240] drm_sched_entity_kill_jobs_cb+0x1c/0x50 [gpu_sched]
[11176.741248] dma_fence_signal_timestamp_locked+0xac/0x1a0
[11176.741254] dma_fence_signal+0x3b/0x80
[11176.741260] drm_sched_fence_finished+0x12/0x20 [gpu_sched]
[11176.741268] drm_sched_job_done.isra.0+0x7f/0x1a0 [gpu_sched]
[11176.741277] drm_sched_job_done_cb+0x12/0x20 [gpu_sched]
[11176.741284] dma_fence_signal_timestamp_locked+0xac/0x1a0
[11176.741290] dma_fence_signal+0x3b/0x80
[11176.741296] amdgpu_fence_process+0xd1/0x140 [amdgpu]
[11176.741504] sdma_v4_0_process_trap_irq+0x8c/0xb0 [amdgpu]
[11176.741731] amdgpu_irq_dispatch+0xce/0x250 [amdgpu]
[11176.741954] amdgpu_ih_process+0x81/0x100 [amdgpu]
[11176.742174] amdgpu_irq_handler+0x26/0xa0 [amdgpu]
[11176.742393] __handle_irq_event_percpu+0x4f/0x2c0
[11176.742402] handle_irq_event_percpu+0x33/0x80
[11176.742408] handle_irq_event+0x39/0x60
[11176.742414] handle_edge_irq+0x93/0x1d0
[11176.742419] __common_interrupt+0x50/0xe0
[PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466] 5.15.0-rc6+ #18 Tainted: G U W }}
[ 213.283470]
[ 213.283472] kworker/u24:0/8 is trying to acquire lock:
[ 213.283475] 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2}, at:
destroyed_worker_func+0x2df/0x350 [i915]
{{[ 213.283618] }}
{{ but task is already holding lock:}}
[ 213.283621] 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2}, at:
destroyed_worker_func+0x4f/0x350 [i915]
{{[ 213.283720] }}
{{ other info that might help us debug this:}}
[ 213.283724] Possible unsafe locking scenario:[ 213.283727] CPU0
[ 213.283728]
[ 213.283730] lock(>submission_state.lock);
[ 213.283734] lock(>submission_state.lock);
{{[ 213.283737] }}
{{ *** DEADLOCK ***}}[ 213.283740] May be due to missing lock nesting notation[
213.283744] 3 locks held by kworker/u24:0/8:
[ 213.283747] #0: 8ffb80059d38 ((wq_completion)events_unbound){..}-{0:0},
at: process_one_work+0x1f3/0x550
[ 213.283757] #1: b509000e3e78
((work_completion)(>submission_state.destroyed_worker)){..}-{0:0}, at:
process_one_work+0x1f3/0x550
[ 213.283766] #2: 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2},
at: destroyed_worker_func+0x4f/0x350 [i915]
{{[ 213.283860] }}
{{ stack backtrace:}}
[ 213.283863] CPU: 8 PID: 8 Comm: kworker/u24:0 Tainted: G U W 5.15.0-rc6+ #18
[ 213.283868] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS
0403 01/26/2021
[ 213.283873] Workqueue: events_unbound destroyed_worker_func [i915]
[ 213.283957] Call Trace:
[ 213.283960] dump_stack_lvl+0x57/0x72
[ 213.283966] __lock_acquire.cold+0x191/0x2d3
[ 213.283972] lock_acquire+0xb5/0x2b0
[ 213.283978] ? destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284059] ? destroyed_worker_func+0x2d7/0x350 [i915]
[ 213.284139] ? lock_release+0xb9/0x280
[ 213.284143] _raw_spin_lock_irqsave+0x48/0x60
[ 213.284148] ? destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284226] destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284310] process_one_work+0x270/0x550
[ 213.284315] worker_thread+0x52/0x3b0
[ 213.284319] ? process_one_work+0x550/0x550
[ 213.284322] kthread+0x135/0x160
[ 213.284326] ? set_kthread_struct+0x40/0x40
[ 213.284331] ret_from_fork+0x1f/0x30
and a bit later in the trace:
{{ 227.499864] do_raw_spin_lock+0x94/0xa0}}
[ 227.499868] _raw_spin_lock_irqsave+0x50/0x60
[ 227.499871] ? guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
[ 227.45] guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
[ 227.500104] intel_guc_submission_reset_prepare+0x99/0x4b0 [i915]
[ 227.500209] ? mark_held_locks+0x49/0x70
[ 227.500212] intel_uc_reset_prepare+0x46/0x50 [i915]
[ 227.500320] reset_prepare+0x78/0x90 [i915]
[ 227.500412] __intel_gt_set_wedged.part.0+0x13/0xe0 [i915]
[ 227.500485] intel_gt_set_wedged.part.0+0x54/0x100 [i915]
[ 227.500556] intel_gt_set_wedged_on_fini+0x1a/0x30 [i915]
[ 227.500622] intel_gt_driver_unregister+0x1e/0x60 [i915]
[ 227.500694] i915_driver_remove+0x4a/0xf0 [i915]
[ 227.500767] i915_pci_probe+0x84/0x170 [i915]
[ 227.500838] local_pci_probe+0x42/0x80
[ 227.500842] pci_device_probe+0xd9/0x190
[ 227.500844] really_probe+0x1f2/0x3f0
[ 227.500847] __driver_probe_device+0xfe/0x180
[ 227.500848] driver_probe_device+0x1e/0x90
[ 227.500850] __driver_attach+0xc4/0x1d0
[ 227.500851] ? __device_attach_driver+0xe0/0xe0
[ 227.500853] ? __device_attach_driver+0xe0/0xe0
[ 227.500854] bus_for_each_dev+0x64/0x90
[ 227.500856] bus_add_driver+0x12e/0x1f0
[ 227.500857] driver_register+0x8f/0xe0
[ 227.500859] i915_init+0x1d/0x8f [i915]
[ 227.500934] ? 0xc144a000
[ 227.500936] do_one_initcall+0x58/0x2d0
[ 227.500938] ? rcu_read_lock_sched_held+0x3f/0x80
[ 227.500940] ? kmem_cache_alloc_trace+0x238/0x2d0
[ 227.500944] do_init_module+0x5c/0x270
[ 227.500946] __do_sys_finit_module+0x95/0xe0
[ 227.500949] do_syscall_64+0x38/0x90
[ 227.500951] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 227.500953] RIP: 0033:0x7ffa59d2ae0d
[ 227.500954] Code: c8 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8
48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
ff ff 73 01 c3 48 8b 0d 3b 80 0c 00 f7 d8 64 89 01 48
[ 227.500955] RSP: 002b:7fff320bbf48 EFLAGS: 0246 ORIG_RAX:
0139
[ 227.500956] RAX: ffda RBX: 022ea710 RCX: 7ffa59d2ae0d
[ 227.500957] RDX: RSI: 022e1d90 RDI: 0004
[ 227.500958] RBP: 0020 R08: 7ffa59df3a60 R09: 0070
[ 227.500958] R10: 022e1d90 R11: 0246 R12: 022e1d90
[ 227.500959] R13: 022e58e0 R14: 0043 R15: 022e42c0
v2:
(CI build)
- Fix build error
Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is pinned
with
Re: [PATCH 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
Awesome! So this all looks fine to me, just some formatting changes:
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63 slots available.
>
> In 128b/132b encoding format, metadata is transmitted separately
> in LLCP packet before MTP. Real data transmission starts from
> the first slot, with a total of 64 slots available.
>
> v2:
> * Move total/start slots to mst_state, and copy it to mst_mgr in
> atomic_check
>
> v3:
> * Only keep the slot info on the mst_state
> * add a start_slot parameter to the payload function, to facilitate non
> atomic drivers (this is a temporary workaround and should be removed when
> we are moving out the non atomic driver helpers)
>
> Signed-off-by: Bhawanpreet Lakha
> Signed-off-by: Fangzhi Zuo
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c | 34 ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +--
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 +--
> include/drm/drm_dp_mst_helper.h | 5 ++-
> 6 files changed, 40 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index ff0f91c93ba4..6169488e2011 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> }
>
> /* It's OK for this to fail */
> - drm_dp_update_payload_part1(mst_mgr);
> + drm_dp_update_payload_part1(mst_mgr, 1);
>
> /* mst_mgr->->payloads are VC payload notify MST branch using DPCD
> or
> * AUX message. The sequence is slot 1-63 allocated sequence for
> each
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5ab3b3a46e89..d188a5269070 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3353,6 +3353,9 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
> /**
> * drm_dp_update_payload_part1() - Execute payload update part 1
> * @mgr: manager to use.
> + * @start_slot: this is the cur slot
> + * NOTE: start_slot is a temporary workaround for non-atomic drivers,
> + * this will be removed when non-atomic mst helpers are moved out of the
> helper
We should probably add a space right before NOTE, and reformat these comments
since there's a bit of an indent at the start (unfortunately, I don't think
kdoc is smart enough to retain the indent in the documentation it generates).
> *
> * This iterates over all proposed virtual channels, and tries to
> * allocate space in the link for them. For 0->slots transitions,
> @@ -3363,12 +3366,12 @@ static int drm_dp_destroy_payload_step2(struct
> drm_dp_mst_topology_mgr *mgr,
> * after calling this the driver should generate ACT and payload
> * packets.
> */
> -int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
> +int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
> start_slot)
> {
> struct drm_dp_payload req_payload;
> struct drm_dp_mst_port *port;
> int i, j;
> - int cur_slots = 1;
> + int cur_slots = start_slot;
> bool skip;
>
> mutex_lock(>payload_lock);
> @@ -4503,6 +4506,26 @@ int drm_dp_atomic_release_vcpi_slots(struct
> drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
>
> +/**
> + * drm_dp_mst_update_slots() - updates the slot info depending on the DP
> ecoding format
> + * @mst_state: mst_state to update
> + * @link_ecoding_cap: the ecoding format on the link
> + */
> +void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
> uint8_t link_ecoding_cap)
> +{
> + if (link_ecoding_cap == DP_CAP_ANSI_128B132B) {
> + mst_state->total_avail_slots = 64;
> + mst_state->start_slot = 0;
> + } else {
> + mst_state->total_avail_slots = 63;
> + mst_state->start_slot = 1;
> + }
> +
> + DRM_DEBUG_KMS("%s ecoding format on mst_state 0x%p\n",
> + (link_ecoding_cap == DP_CAP_ANSI_128B132B) ?
> "128b/132b":"8b/10b", mst_state->mgr);
> +}
> +EXPORT_SYMBOL(drm_dp_mst_update_slots);
Some typos (s/ecoding/encoding), and also this should be reformatted to a 100
character column limit.
Other then that, nice work! After making the formatting changes I mentioned
here, you can consider this:
Reviewed-by: Lyude Paul
Since this patch series touches multiple drivers, we may want to merge this
through drm-misc-next (or maybe just
Re: [PATCH 1/4] drm: Remove slot checks in dp mst topology during commit
Reviewed-by: Lyude Paul
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> This code path is used during commit, and we dont expect things to fail
> during the commit stage, so remove this.
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index ad0795afc21c..5ab3b3a46e89 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4332,10 +4332,6 @@ static int drm_dp_init_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
> {
> int ret;
>
> - /* max. time slots - one slot for MTP header */
> - if (slots > 63)
> - return -ENOSPC;
> -
> vcpi->pbn = pbn;
> vcpi->aligned_pbn = slots * mgr->pbn_div;
> vcpi->num_slots = slots;
> @@ -4538,7 +4534,7 @@ bool drm_dp_mst_allocate_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
>
> ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
> if (ret) {
> - drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d max=63
> ret=%d\n",
> + drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d
> ret=%d\n",
> DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
> drm_dp_mst_topology_put_port(port);
> goto out;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v4 1/7] dt-bindings: mediatek,dpintf: Add DP_INTF binding
Hi Rob, On Mon, Oct 11, 2021 at 06:44:53PM -0500, Rob Herring wrote: > On Mon, 11 Oct 2021 11:46:18 +0200, Markus Schneider-Pargmann wrote: > > DP_INTF is a similar functional block to mediatek,dpi but is different > > in that it serves the DisplayPort controller on mediatek SoCs and uses > > different clocks. Therefore this patch creates a new binding file for > > this functional block. > > > > Signed-off-by: Markus Schneider-Pargmann > > --- > > > > Notes: > > Changes v3 -> v4: > > - Fixed clock names in the example as the clock patch series is merged > > into > > next now > > - Add missing ports decleration to the example > > > > Changes v1 -> v2: > > - Move the devicetree binding from mediatek,dpi into its own binding > > file. > > > > .../display/mediatek/mediatek,dpintf.yaml | 86 +++ > > 1 file changed, 86 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,dpintf.yaml > > > > Reviewed-by: Rob Herring Thanks a lot for reviewing. However I am going to recombine dpintf with dpi as Chun-Kuang helped me realize that the fdp clock is a parent of the pixel clock and therefore not a different clock. In the end the clocks are the same now for both dpi and dpintf, so no need for a separate document. Best, Markus
[PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466] 5.15.0-rc6+ #18 Tainted: G U W }}
[ 213.283470]
[ 213.283472] kworker/u24:0/8 is trying to acquire lock:
[ 213.283475] 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2}, at:
destroyed_worker_func+0x2df/0x350 [i915]
{{[ 213.283618] }}
{{ but task is already holding lock:}}
[ 213.283621] 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2}, at:
destroyed_worker_func+0x4f/0x350 [i915]
{{[ 213.283720] }}
{{ other info that might help us debug this:}}
[ 213.283724] Possible unsafe locking scenario:[ 213.283727] CPU0
[ 213.283728]
[ 213.283730] lock(>submission_state.lock);
[ 213.283734] lock(>submission_state.lock);
{{[ 213.283737] }}
{{ *** DEADLOCK ***}}[ 213.283740] May be due to missing lock nesting notation[
213.283744] 3 locks held by kworker/u24:0/8:
[ 213.283747] #0: 8ffb80059d38 ((wq_completion)events_unbound){..}-{0:0},
at: process_one_work+0x1f3/0x550
[ 213.283757] #1: b509000e3e78
((work_completion)(>submission_state.destroyed_worker)){..}-{0:0}, at:
process_one_work+0x1f3/0x550
[ 213.283766] #2: 8ffc4f6cc1e8 (>submission_state.lock){}-{2:2},
at: destroyed_worker_func+0x4f/0x350 [i915]
{{[ 213.283860] }}
{{ stack backtrace:}}
[ 213.283863] CPU: 8 PID: 8 Comm: kworker/u24:0 Tainted: G U W 5.15.0-rc6+ #18
[ 213.283868] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS
0403 01/26/2021
[ 213.283873] Workqueue: events_unbound destroyed_worker_func [i915]
[ 213.283957] Call Trace:
[ 213.283960] dump_stack_lvl+0x57/0x72
[ 213.283966] __lock_acquire.cold+0x191/0x2d3
[ 213.283972] lock_acquire+0xb5/0x2b0
[ 213.283978] ? destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284059] ? destroyed_worker_func+0x2d7/0x350 [i915]
[ 213.284139] ? lock_release+0xb9/0x280
[ 213.284143] _raw_spin_lock_irqsave+0x48/0x60
[ 213.284148] ? destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284226] destroyed_worker_func+0x2df/0x350 [i915]
[ 213.284310] process_one_work+0x270/0x550
[ 213.284315] worker_thread+0x52/0x3b0
[ 213.284319] ? process_one_work+0x550/0x550
[ 213.284322] kthread+0x135/0x160
[ 213.284326] ? set_kthread_struct+0x40/0x40
[ 213.284331] ret_from_fork+0x1f/0x30
and a bit later in the trace:
{{ 227.499864] do_raw_spin_lock+0x94/0xa0}}
[ 227.499868] _raw_spin_lock_irqsave+0x50/0x60
[ 227.499871] ? guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
[ 227.45] guc_flush_destroyed_contexts+0x4f/0xf0 [i915]
[ 227.500104] intel_guc_submission_reset_prepare+0x99/0x4b0 [i915]
[ 227.500209] ? mark_held_locks+0x49/0x70
[ 227.500212] intel_uc_reset_prepare+0x46/0x50 [i915]
[ 227.500320] reset_prepare+0x78/0x90 [i915]
[ 227.500412] __intel_gt_set_wedged.part.0+0x13/0xe0 [i915]
[ 227.500485] intel_gt_set_wedged.part.0+0x54/0x100 [i915]
[ 227.500556] intel_gt_set_wedged_on_fini+0x1a/0x30 [i915]
[ 227.500622] intel_gt_driver_unregister+0x1e/0x60 [i915]
[ 227.500694] i915_driver_remove+0x4a/0xf0 [i915]
[ 227.500767] i915_pci_probe+0x84/0x170 [i915]
[ 227.500838] local_pci_probe+0x42/0x80
[ 227.500842] pci_device_probe+0xd9/0x190
[ 227.500844] really_probe+0x1f2/0x3f0
[ 227.500847] __driver_probe_device+0xfe/0x180
[ 227.500848] driver_probe_device+0x1e/0x90
[ 227.500850] __driver_attach+0xc4/0x1d0
[ 227.500851] ? __device_attach_driver+0xe0/0xe0
[ 227.500853] ? __device_attach_driver+0xe0/0xe0
[ 227.500854] bus_for_each_dev+0x64/0x90
[ 227.500856] bus_add_driver+0x12e/0x1f0
[ 227.500857] driver_register+0x8f/0xe0
[ 227.500859] i915_init+0x1d/0x8f [i915]
[ 227.500934] ? 0xc144a000
[ 227.500936] do_one_initcall+0x58/0x2d0
[ 227.500938] ? rcu_read_lock_sched_held+0x3f/0x80
[ 227.500940] ? kmem_cache_alloc_trace+0x238/0x2d0
[ 227.500944] do_init_module+0x5c/0x270
[ 227.500946] __do_sys_finit_module+0x95/0xe0
[ 227.500949] do_syscall_64+0x38/0x90
[ 227.500951] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 227.500953] RIP: 0033:0x7ffa59d2ae0d
[ 227.500954] Code: c8 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8
48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
ff ff 73 01 c3 48 8b 0d 3b 80 0c 00 f7 d8 64 89 01 48
[ 227.500955] RSP: 002b:7fff320bbf48 EFLAGS: 0246 ORIG_RAX:
0139
[ 227.500956] RAX: ffda RBX: 022ea710 RCX: 7ffa59d2ae0d
[ 227.500957] RDX: RSI: 022e1d90 RDI: 0004
[ 227.500958] RBP: 0020 R08: 7ffa59df3a60 R09: 0070
[ 227.500958] R10: 022e1d90 R11: 0246 R12: 022e1d90
[ 227.500959] R13: 022e58e0 R14: 0043 R15: 022e42c0
Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is pinned
with GuC submission")
Signed-off-by:
Re: [PATCH v3 5/6] drm/mediatek: dpi: Add dpintf support
Hi Chun-Kuang,
On Fri, Oct 15, 2021 at 12:04:10AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年10月1日 週五 下午5:44寫道：
> >
> > dpintf is the displayport interface hardware unit. This unit is similar
> > to dpi and can reuse most of the code.
> >
> > This patch adds support for mt8195-dpintf to this dpi driver. Main
> > differences are:
> > - Some features/functional components are not available for dpintf
> >which are now excluded from code execution once is_dpintf is set
> > - dpintf can and needs to choose between different clockdividers based
> >on the clockspeed. This is done by choosing a different clock parent.
> > - There are two additional clocks that need to be managed. These are
> >only set for dpintf and will be set to NULL if not supplied. The
> >clk_* calls handle these as normal clocks then.
> > - Some register contents differ slightly between the two components. To
> >work around this I added register bits/masks with a DPINTF_ prefix
> >and use them where different.
> >
> > Based on a separate driver for dpintf created by
> > Jason-JH.Lin .
> >
> > Signed-off-by: Markus Schneider-Pargmann
> > ---
> >
> > Notes:
> > Changes RFC -> v1:
> > - Remove setting parents and fully rely on the clock tree instead which
> > already
> > models a mux at the important place.
> > - Integrated mtk_dpi dpintf changes into the mediatek drm driver.
> >
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 248
> > drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 12 +
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 +
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +-
> > 5 files changed, 218 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 4554e2de1430..87961ebf5d35 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -71,6 +71,8 @@ struct mtk_dpi {
> > void __iomem *regs;
> > struct device *dev;
> > struct clk *engine_clk;
> > + struct clk *hf_fmm_clk;
> > + struct clk *hf_fdp_clk;
> > struct clk *pixel_clk;
> > struct clk *tvd_clk;
> > int irq;
> > @@ -125,6 +127,7 @@ struct mtk_dpi_conf {
> > bool edge_sel_en;
> > const u32 *output_fmts;
> > u32 num_output_fmts;
> > + bool is_dpintf;
> > };
> >
> > static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32
> > mask)
> > @@ -153,30 +156,52 @@ static void mtk_dpi_disable(struct mtk_dpi *dpi)
> > static void mtk_dpi_config_hsync(struct mtk_dpi *dpi,
> > struct mtk_dpi_sync_param *sync)
> > {
> > - mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
> > -sync->sync_width << HPW, HPW_MASK);
> > - mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
> > -sync->back_porch << HBP, HBP_MASK);
> > - mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
> > -HFP_MASK);
> > + if (dpi->conf->is_dpintf) {
> > + mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
> > +sync->sync_width << HPW, DPINTF_HPW_MASK);
> > + mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
> > +sync->back_porch << HBP, DPINTF_HBP_MASK);
> > + mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
> > +DPINTF_HFP_MASK);
>
> define dpi->conf->hpw_mask
> define dpi->conf->hbp_mask
> define dpi->conf->hfp_mask
Thanks, I defined a dpi->conf->dimension_mask instead which I now use
for HWIDTH/HPORCH as well as VSYNC_WIDTH and VSYNC_PORCH as the only
difference is the width of the masks, not their positions. Hope that's
fine.
>
> > + } else {
> > + mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
> > +sync->sync_width << HPW, HPW_MASK);
> > + mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
> > +sync->back_porch << HBP, HBP_MASK);
> > + mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
> > +HFP_MASK);
> > + }
> > }
> >
> > static void mtk_dpi_config_vsync(struct mtk_dpi *dpi,
> > struct mtk_dpi_sync_param *sync,
> > u32 width_addr, u32 porch_addr)
> > {
> > - mtk_dpi_mask(dpi, width_addr,
> > -sync->sync_width << VSYNC_WIDTH_SHIFT,
> > -VSYNC_WIDTH_MASK);
> > mtk_dpi_mask(dpi, width_addr,
> > sync->shift_half_line << VSYNC_HALF_LINE_SHIFT,
> > VSYNC_HALF_LINE_MASK);
> > - mtk_dpi_mask(dpi, porch_addr,
> > -sync->back_porch << VSYNC_BACK_PORCH_SHIFT,
> > -VSYNC_BACK_PORCH_MASK);
> >
[PATCH] drm/msm: Fix potential NULL dereference in DPU
Add NULL checks in KMS CRTC funcs to avoid potential NULL
dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 3 +++
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 3 +++
5 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index d2457490930b..53d80572181e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -208,8 +208,16 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
dpu_kms->irq_obj.total_irqs = dpu_kms->hw_intr->total_irqs;
dpu_kms->irq_obj.irq_cb_tbl = kcalloc(dpu_kms->irq_obj.total_irqs,
sizeof(struct list_head), GFP_KERNEL);
+
+ if (!dpu_kms->irq_obj.irq_cb_tbl)
+ return;
+
dpu_kms->irq_obj.irq_counts = kcalloc(dpu_kms->irq_obj.total_irqs,
sizeof(atomic_t), GFP_KERNEL);
+
+ if (!dpu_kms->irq_obj.irq_counts)
+ return;
+
for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++) {
INIT_LIST_HEAD(_kms->irq_obj.irq_cb_tbl[i]);
atomic_set(_kms->irq_obj.irq_counts[i], 0);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 768012243b44..0a1cad0cfcc0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -921,6 +921,11 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates = kzalloc(sizeof(*pstates) * DPU_STAGE_MAX * 4, GFP_KERNEL);
+ if (!pstates) {
+ rc = -ENOMEM;
+ goto end;
+ }
+
if (!crtc_state->enable || !crtc_state->active) {
DRM_DEBUG_ATOMIC("crtc%d -> enable %d, active %d, skip
atomic_check\n",
crtc->base.id, crtc_state->enable,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index c6b69afcbac8..09751b480db5 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -92,6 +92,9 @@ static void mdp5_plane_reset(struct drm_plane *plane)
kfree(to_mdp5_plane_state(plane->state));
mdp5_state = kzalloc(sizeof(*mdp5_state), GFP_KERNEL);
+ if (!mdp5_state)
+ return;
+
if (plane->type == DRM_PLANE_TYPE_PRIMARY)
mdp5_state->base.zpos = STAGE_BASE;
else
diff --git a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
index cabe15190ec1..71e209d07120 100644
--- a/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
+++ b/drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
@@ -170,6 +170,9 @@ void msm_disp_snapshot_add_block(struct msm_disp_state
*disp_state, u32 len,
new_blk = kzalloc(sizeof(struct msm_disp_state_block), GFP_KERNEL);
+ if (!new_blk)
+ return;
+
va_start(va, fmt);
vaf.fmt = fmt;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 8a3a592da3a4..ddd23f3a4a99 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -296,6 +296,9 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu,
state->bos = kcalloc(nr,
sizeof(struct msm_gpu_state_bo), GFP_KERNEL);
+ if (!state->bos)
+ return;
+
for (i = 0; i < submit->nr_bos; i++) {
if (should_dump(submit, i)) {
msm_gpu_crashstate_get_bo(state,
submit->bos[i].obj,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] drm/msm/dsi: fix wrong type in msm_dsi_host
Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
Fixes: a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c86b5090fae6..20a92cb967d0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -115,16 +115,16 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
- u32 byte_clk_rate;
- u32 pixel_clk_rate;
- u32 esc_clk_rate;
+ unsigned long byte_clk_rate;
+ unsigned long pixel_clk_rate;
+ unsigned long esc_clk_rate;
/* DSI v2 specific clocks */
struct clk *src_clk;
struct clk *esc_clk_src;
struct clk *dsi_clk_src;
- u32 src_clk_rate;
+ unsigned long src_clk_rate;
struct gpio_desc *disp_en_gpio;
struct gpio_desc *te_gpio;
@@ -498,10 +498,10 @@ int msm_dsi_runtime_resume(struct device *dev)
int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
{
- u32 byte_intf_rate;
+ unsigned long byte_intf_rate;
int ret;
- DBG("Set clk rates: pclk=%d, byteclk=%d",
+ DBG("Set clk rates: pclk=%d, byteclk=%lu",
msm_host->mode->clock, msm_host->byte_clk_rate);
ret = dev_pm_opp_set_rate(_host->pdev->dev,
@@ -583,7 +583,7 @@ int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host)
{
int ret;
- DBG("Set clk rates: pclk=%d, byteclk=%d, esc_clk=%d, dsi_src_clk=%d",
+ DBG("Set clk rates: pclk=%d, byteclk=%lu, esc_clk=%lu, dsi_src_clk=%lu",
msm_host->mode->clock, msm_host->byte_clk_rate,
msm_host->esc_clk_rate, msm_host->src_clk_rate);
@@ -673,10 +673,10 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host
*msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static u32 dsi_get_pclk_rate(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
+static unsigned long dsi_get_pclk_rate(struct msm_dsi_host *msm_host, bool
is_bonded_dsi)
{
struct drm_display_mode *mode = msm_host->mode;
- u32 pclk_rate;
+ unsigned long pclk_rate;
pclk_rate = mode->clock * 1000;
@@ -696,7 +696,7 @@ static void dsi_calc_pclk(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
{
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- u32 pclk_rate = dsi_get_pclk_rate(msm_host, is_bonded_dsi);
+ unsigned long pclk_rate = dsi_get_pclk_rate(msm_host, is_bonded_dsi);
u64 pclk_bpp = (u64)pclk_rate * bpp;
if (lanes == 0) {
@@ -713,7 +713,7 @@ static void dsi_calc_pclk(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
msm_host->pixel_clk_rate = pclk_rate;
msm_host->byte_clk_rate = pclk_bpp;
- DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
+ DBG("pclk=%lu, bclk=%lu", msm_host->pixel_clk_rate,
msm_host->byte_clk_rate);
}
@@ -772,7 +772,7 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
msm_host->esc_clk_rate = msm_host->byte_clk_rate / esc_div;
- DBG("esc=%d, src=%d", msm_host->esc_clk_rate,
+ DBG("esc=%lu, src=%lu", msm_host->esc_clk_rate,
msm_host->src_clk_rate);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[next] [dragonboard 410c] Unable to handle kernel paging request at virtual address 00000000007c4240
Following kernel crash noticed on linux next 20211020 tag. while booting on arm64 architecture dragonboard 410c device. I see the following config is enabled in 20211020 tag builds. CONFIG_STACKDEPOT=y Crash log, [ 18.583097] Unable to handle kernel paging request at virtual address 007c4240 [ 18.583521] Mem abort info: [ 18.590286] ESR = 0x9604 [ 18.592920] EC = 0x25: DABT (current EL), IL = 32 bits [ 18.596103] SET = 0, FnV = 0 [ 18.601512] EA = 0, S1PTW = 0 [ 18.604384] FSC = 0x04: level 0 translation fault [ 18.607447] Data abort info: [ 18.612296] ISV = 0, ISS = 0x0004 [ 18.615451] CM = 0, WnR = 0 [ 18.618990] user pgtable: 4k pages, 48-bit VAs, pgdp=8b4c7000 [ 18.622054] [007c4240] pgd=, p4d= [ 18.628974] Internal error: Oops: 9604 [#1] SMP [ 18.635073] Modules linked in: adv7511 cec snd_soc_lpass_apq8016 snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_msm8916_digital qcom_camss qrtr snd_soc_apq8016_sbc videobuf2_dma_sg qcom_pon qcom_spmi_vadc snd_soc_qcom_common qcom_q6v5_mss qcom_vadc_common rtc_pm8xxx qcom_spmi_temp_alarm msm qcom_pil_info v4l2_fwnode qcom_q6v5 snd_soc_msm8916_analog qcom_sysmon qcom_common v4l2_async qnoc_msm8916 qcom_rng gpu_sched qcom_glink_smem venus_core videobuf2_memops icc_smd_rpm qmi_helpers drm_kms_helper v4l2_mem2mem mdt_loader display_connector i2c_qcom_cci videobuf2_v4l2 crct10dif_ce videobuf2_common socinfo drm rmtfs_mem fuse [ 18.672948] CPU: 0 PID: 178 Comm: kworker/u8:3 Not tainted 5.15.0-rc6-next-20211020 #1 [ 18.695000] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 18.695012] Workqueue: events_unbound deferred_probe_work_func [ 18.695033] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 18.715282] pc : __stack_depot_save+0x13c/0x4e0 [ 18.722130] lr : stack_depot_save+0x14/0x20 [ 18.726641] sp : 800014a23500 [ 18.730801] x29: 800014a23500 x28: 000f8848 x27: 800013acdf68 [ 18.734294] x26: x25: 007c4240 x24: 800014a23780 [ 18.741413] x23: 0008 x22: 800014a235b8 x21: 0008 [ 18.748530] x20: c32f8848 x19: 1038cc18 x18: [ 18.755649] x17: 80002d9f8000 x16: 800010004000 x15: c426 [ 18.762767] x14: x13: 800014a23780 x12: [ 18.769885] x11: 1038cc80 x10: 8000136e9ba0 x9 : 800014a235f4 [ 18.777003] x8 : 0001 x7 : b664620b x6 : 11a58b4a [ 18.784121] x5 : 1aa43464 x4 : 9e7d8b67 x3 : 0001 [ 18.791239] x2 : 2800 x1 : 800013acd000 x0 : f2d429d8 [ 18.798358] Call trace: [ 18.805451] __stack_depot_save+0x13c/0x4e0 [ 18.807716] stack_depot_save+0x14/0x20 [ 18.811881] __drm_stack_depot_save+0x44/0x70 [drm] [ 18.815710] modeset_lock.part.0+0xe0/0x1a4 [drm] [ 18.820571] drm_modeset_lock_all_ctx+0x2d4/0x334 [drm] [ 18.825435] drm_client_firmware_config.constprop.0.isra.0+0xc0/0x5d0 [drm] [ 18.830478] drm_client_modeset_probe+0x328/0xbb0 [drm] [ 18.837413] __drm_fb_helper_initial_config_and_unlock+0x54/0x5b4 [drm_kms_helper] [ 18.842633] drm_fb_helper_initial_config+0x5c/0x70 [drm_kms_helper] [ 18.850266] msm_fbdev_init+0x98/0x100 [msm] [ 18.856767] msm_drm_bind+0x650/0x720 [msm] [ 18.861021] try_to_bring_up_master+0x230/0x320 [ 18.864926] __component_add+0xc8/0x1c4 [ 18.869435] component_add+0x20/0x30 [ 18.873253] mdp5_dev_probe+0xe0/0x11c [msm] [ 18.877077] platform_probe+0x74/0xf0 [ 18.881328] really_probe+0xc4/0x470 [ 18.884883] __driver_probe_device+0x11c/0x190 [ 18.888534] driver_probe_device+0x48/0x110 [ 18.892786] __device_attach_driver+0xa4/0x140 [ 18.896869] bus_for_each_drv+0x84/0xe0 [ 18.901380] __device_attach+0xe4/0x1c0 [ 18.905112] device_initial_probe+0x20/0x30 [ 18.908932] bus_probe_device+0xac/0xb4 [ 18.913098] deferred_probe_work_func+0xc8/0x120 [ 18.916920] process_one_work+0x280/0x6a0 [ 18.921780] worker_thread+0x80/0x454 [ 18.925683] kthread+0x178/0x184 [ 18.929326] ret_from_fork+0x10/0x20 [ 18.932634] Code: d37d4e99 92404e9c f940077a 8b190359 (c8dfff33) [ 18.936203] ---[ end trace 3e289b724840642d ]--- Full log, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20211020/testrun/6177937/suite/linux-log-parser/test/check-kernel-oops-3786583/log https://lkft.validation.linaro.org/scheduler/job/3786583#L2549 Build config: https://builds.tuxbuild.com/1zlLlQrUyHVr1MQ1gcler3dKaE6/config Reported-by: Linux Kernel Functional Testing steps to reproduce: 1) https://builds.tuxbuild.com/1zlLlQrUyHVr1MQ1gcler3dKaE6/tuxmake_reproducer.sh 2) Boot db410c device -- Linaro LKFT https://lkft.linaro.org
[PATCH v2 6/7] drm/bridge: Drop drm_bridge_chain_mode_fixup
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_bridge.c | 37
include/drm/drm_bridge.h | 3 ---
2 files changed, 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 7a57d6816105..57a864d9a87f 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -406,43 +406,6 @@ void drm_bridge_detach(struct drm_bridge *bridge)
* needed, in order to gradually transition to the new model.
*/
-/**
- * drm_bridge_chain_mode_fixup - fixup proposed mode for all bridges in the
- * encoder chain
- * @bridge: bridge control structure
- * @mode: desired mode to be set for the bridge
- * @adjusted_mode: updated mode that works for this bridge
- *
- * Calls _bridge_funcs.mode_fixup for all the bridges in the
- * encoder chain, starting from the first bridge to the last.
- *
- * Note: the bridge passed should be the one closest to the encoder
- *
- * RETURNS:
- * true on success, false on failure
- */
-bool drm_bridge_chain_mode_fixup(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
- struct drm_encoder *encoder;
-
- if (!bridge)
- return true;
-
- encoder = bridge->encoder;
- list_for_each_entry_from(bridge, >bridge_chain, chain_node) {
- if (!bridge->funcs->mode_fixup)
- continue;
-
- if (!bridge->funcs->mode_fixup(bridge, mode, adjusted_mode))
- return false;
- }
-
- return true;
-}
-EXPORT_SYMBOL(drm_bridge_chain_mode_fixup);
-
/**
* drm_bridge_chain_mode_valid - validate the mode against all bridges in the
* encoder chain.
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index f1eb71ff5379..c8d07bd27f63 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -837,9 +837,6 @@ drm_bridge_chain_get_first_bridge(struct drm_encoder
*encoder)
#define drm_for_each_bridge_in_chain(encoder, bridge) \
list_for_each_entry(bridge, &(encoder)->bridge_chain, chain_node)
-bool drm_bridge_chain_mode_fixup(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode);
enum drm_mode_status
drm_bridge_chain_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
--
2.30.2
[PATCH v2 3/7] drm/bridge: Add drm_atomic_get_new_crtc_for_bridge() helper
drm_atomic_get_new_crtc_for_bridge() will be used by bridge
drivers to provide easy access to the mode from the
drm_bridge_funcs operations.
The helper will be useful in the conversion to the atomic
operations of struct drm_bridge_funcs.
v2:
- Renamed to drm_atomic_get_new_crtc_for_bridge (Maxime)
- Use atomic_state, not bridge_State (Maxime)
- Drop WARN on crtc_state as it is a valid case (Maxime)
- Added small code snip to help readers
- Updated description, fixed kernel-doc and exported the symbol
Signed-off-by: Sam Ravnborg
Suggested-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 42
include/drm/drm_atomic.h | 3 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff1416cd609a..8b107194b157 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1134,6 +1134,48 @@ drm_atomic_get_new_bridge_state(struct drm_atomic_state
*state,
}
EXPORT_SYMBOL(drm_atomic_get_new_bridge_state);
+/**
+ * drm_atomic_get_new_crtc_for_bridge - get new crtc_state for the bridge
+ * @state: state of the bridge
+ * @bridge: bridge object
+ *
+ * This function is often used in the drm_bridge_funcs operations
+ * to provide easy access to the mode like this:
+ *
+ * .. code-block:: c
+ *
+ * crtc_state =
drm_atomic_get_new_crtc_for_bridge(old_bridge_state->base.state,
+ * bridge);
+ * if (crtc_state) {
+ * mode = _state->mode;
+ * ...
+ *
+ * If no connector can be looked up or if no connector state is available
+ * then this will be logged using WARN().
+ *
+ * Returns:
+ * The drm_crtc_state for the given bridge/state, or NULL
+ * if no crtc_state could be looked up.
+ */
+const struct drm_crtc_state *
+drm_atomic_get_new_crtc_for_bridge(struct drm_atomic_state *state,
+ struct drm_bridge *bridge)
+{
+ const struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ if (WARN_ON(!connector))
+ return NULL;
+
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ if (WARN_ON(!conn_state || !conn_state->crtc))
+ return NULL;
+
+ return drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+}
+EXPORT_SYMBOL(drm_atomic_get_new_crtc_for_bridge);
+
/**
* drm_atomic_add_encoder_bridges - add bridges attached to an encoder
* @state: atomic state
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 1701c2128a5c..f861d73296cc 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -1119,5 +1119,8 @@ drm_atomic_get_old_bridge_state(struct drm_atomic_state
*state,
struct drm_bridge_state *
drm_atomic_get_new_bridge_state(struct drm_atomic_state *state,
struct drm_bridge *bridge);
+const struct drm_crtc_state *
+drm_atomic_get_new_crtc_for_bridge(struct drm_atomic_state *state,
+ struct drm_bridge *bridge);
#endif /* DRM_ATOMIC_H_ */
--
2.30.2
[PATCH v2 7/7] drm/todo: Add bridge related todo items
- deprecated callbacks in drm_bridge_funcs - move connector creation to display drivers v2: - Updated descriptions in todo.rst Signed-off-by: Sam Ravnborg Acked-by: Maxime Ripard Cc: Laurent Pinchart Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- Documentation/gpu/todo.rst | 49 ++ 1 file changed, 49 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 60d1d7ee0719..17c03e7c41e5 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -463,6 +463,55 @@ Contact: Thomas Zimmermann , Christian König, Daniel Vette Level: Intermediate +Drop use of deprecated operations in bridge drivers +-- + + drm_bridge_funcs contains a number of deprecated operations +which use can be replaced by the atomic variants. + +The following is more or less 1:1 replacements whit the arguments +and names adjusted: +* pre_enable => atomic_pre_enable +* enable => atomic_enable +* disable => atomic_disable +* post_disable => atomic_post_disable + +* mode_set is no longer required and the implementation shall be merged + with atomic_enable. + +* mode_fixup => atomic_check + mode_fixup() was created a long time ago, when we were supposed to have + a single bridge at the output of the CRTC. The bridge could then instruct + the CRTC to output a different mode than what the display requires. + Now that we have support for multiple bridges, it's not as straightforward, + and we've so far just pretended to ignore the problem. The .mode_fixup() + operation is used and abused, and just telling people to use .atomic_check() + will likely make things worse as that operation has access to the full atomic + commit and can alter the mode of pretty much anything. We need to define clear + semantics for .atomic_check() in bridges. + + +Contact: bridge maintainers, Sam Ravnborg , + Laurent Pinchart + +Level: Beginner or intermediate (depending on the driver) + +Move connector creation to display drivers +-- + +With the introduction of chained bridges the creation of connectors are moved +to the display drivers. The flag DRM_BRIDGE_ATTACH_NO_CONNECTOR is used to +signal to the bridge driver that no connector shall be created and that the +display driver will take care. Display drivers will in most cases be able to +utilise drm_bridge_connector_init() for all the logic. + +Step 1 is to have all bridge drivers supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR. +Step 2 is to move connector creation to all relevant display drivers, utilizing +the drm_bridge_connector where possible. + +Contact: Sam Ravnborg , bridge and/or driver maintainer(s) + +Level: Intermediate or advanced (depending on the driver) Core refactorings = -- 2.30.2
[PATCH v2 4/7] drm/bridge: lontium-lt9611: Use atomic variants of drm_bridge_funcs
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
Use of mode_set is deprecated - merge the functionality with
atomic_enable()
v2:
- Added check if crtc_state is NULL (Maxime)
- Updated to use drm_atomic_get_new_crtc_for_bridge()
Signed-off-by: Sam Ravnborg
Cc: Maxime Ripard
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 75 +++--
1 file changed, 33 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 29b1ce2140ab..cdc3d5f8dcac 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -700,9 +700,23 @@ lt9611_connector_mode_valid(struct drm_connector
*connector,
}
/* bridge funcs */
-static void lt9611_bridge_enable(struct drm_bridge *bridge)
+static void lt9611_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
+ const struct drm_display_mode *mode;
+ const struct drm_crtc_state *crtc_state;
+ struct hdmi_avi_infoframe avi_frame;
+ int ret;
+
+ crtc_state =
drm_atomic_get_new_crtc_for_bridge(old_bridge_state->base.state,
+ bridge);
+ if (!crtc_state) {
+ dev_err(lt9611->dev, "no crtc_state available\n");
+ return;
+ }
+
+ mode = _state->mode;
if (lt9611_power_on(lt9611)) {
dev_err(lt9611->dev, "power on failed\n");
@@ -719,9 +733,21 @@ static void lt9611_bridge_enable(struct drm_bridge *bridge)
/* Enable HDMI output */
regmap_write(lt9611->regmap, 0x8130, 0xea);
+
+ lt9611_mipi_input_digital(lt9611, mode);
+ lt9611_pll_setup(lt9611, mode);
+ lt9611_mipi_video_setup(lt9611, mode);
+ lt9611_pcr_setup(lt9611, mode);
+
+ ret = drm_hdmi_avi_infoframe_from_display_mode(_frame,
+ >connector,
+ mode);
+ if (!ret)
+ lt9611->vic = avi_frame.video_code;
}
-static void lt9611_bridge_disable(struct drm_bridge *bridge)
+static void lt9611_bridge_atomic_disable(struct drm_bridge *bridge,
+struct drm_bridge_state
*old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
int ret;
@@ -877,48 +903,14 @@ static enum drm_mode_status
lt9611_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
-static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
-{
- struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
-
- if (!lt9611->sleep)
- return;
-
- lt9611_reset(lt9611);
- regmap_write(lt9611->regmap, 0x80ee, 0x01);
-
- lt9611->sleep = false;
-}
-
-static void lt9611_bridge_post_disable(struct drm_bridge *bridge)
+static void lt9611_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
lt9611_sleep_setup(lt9611);
}
-static void lt9611_bridge_mode_set(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- const struct drm_display_mode *adj_mode)
-{
- struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
- struct hdmi_avi_infoframe avi_frame;
- int ret;
-
- lt9611_bridge_pre_enable(bridge);
-
- lt9611_mipi_input_digital(lt9611, mode);
- lt9611_pll_setup(lt9611, mode);
- lt9611_mipi_video_setup(lt9611, mode);
- lt9611_pcr_setup(lt9611, mode);
-
- ret = drm_hdmi_avi_infoframe_from_display_mode(_frame,
- >connector,
- mode);
- if (!ret)
- lt9611->vic = avi_frame.video_code;
-}
-
static enum drm_connector_status lt9611_bridge_detect(struct drm_bridge
*bridge)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
@@ -954,10 +946,9 @@ static const struct drm_bridge_funcs lt9611_bridge_funcs =
{
.attach = lt9611_bridge_attach,
.detach = lt9611_bridge_detach,
.mode_valid = lt9611_bridge_mode_valid,
- .enable = lt9611_bridge_enable,
- .disable = lt9611_bridge_disable,
- .post_disable = lt9611_bridge_post_disable,
- .mode_set = lt9611_bridge_mode_set,
+ .atomic_enable = lt9611_bridge_atomic_enable,
+ .atomic_disable = lt9611_bridge_atomic_disable,
+ .atomic_post_disable = lt9611_bridge_atomic_post_disable,
[PATCH v2 5/7] drm/mediatek: Drop chain_mode_fixup call in mode_valid()
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could see this call was included in the original
version of the driver so there was no help there to find out why it was
added in the first place. But a lot has changed since the initial driver
were added and is seems safe to remove the call now.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: Dafna Hirschfeld
Cc: linux-media...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 5838c44cbf6f..bade1cbd782d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1208,22 +1208,11 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge
*bridge,
const struct drm_display_mode *mode)
{
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
- struct drm_bridge *next_bridge;
dev_dbg(hdmi->dev, "xres=%d, yres=%d, refresh=%d, intl=%d clock=%d\n",
mode->hdisplay, mode->vdisplay, drm_mode_vrefresh(mode),
!!(mode->flags & DRM_MODE_FLAG_INTERLACE), mode->clock * 1000);
- next_bridge = drm_bridge_get_next_bridge(>bridge);
- if (next_bridge) {
- struct drm_display_mode adjusted_mode;
-
- drm_mode_copy(_mode, mode);
- if (!drm_bridge_chain_mode_fixup(next_bridge, mode,
-_mode))
- return MODE_BAD;
- }
-
if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
return MODE_BAD;
--
2.30.2
[PATCH v2 2/7] drm/bridge: Drop unused drm_bridge_chain functions
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_bridge.c | 110 ---
include/drm/drm_bridge.h | 28 -
2 files changed, 138 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c96847fc0ebc..7a57d6816105 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -485,61 +485,6 @@ drm_bridge_chain_mode_valid(struct drm_bridge *bridge,
}
EXPORT_SYMBOL(drm_bridge_chain_mode_valid);
-/**
- * drm_bridge_chain_disable - disables all bridges in the encoder chain
- * @bridge: bridge control structure
- *
- * Calls _bridge_funcs.disable op for all the bridges in the encoder
- * chain, starting from the last bridge to the first. These are called before
- * calling the encoder's prepare op.
- *
- * Note: the bridge passed should be the one closest to the encoder
- */
-void drm_bridge_chain_disable(struct drm_bridge *bridge)
-{
- struct drm_encoder *encoder;
- struct drm_bridge *iter;
-
- if (!bridge)
- return;
-
- encoder = bridge->encoder;
- list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
- if (iter->funcs->disable)
- iter->funcs->disable(iter);
-
- if (iter == bridge)
- break;
- }
-}
-EXPORT_SYMBOL(drm_bridge_chain_disable);
-
-/**
- * drm_bridge_chain_post_disable - cleans up after disabling all bridges in the
- *encoder chain
- * @bridge: bridge control structure
- *
- * Calls _bridge_funcs.post_disable op for all the bridges in the
- * encoder chain, starting from the first bridge to the last. These are called
- * after completing the encoder's prepare op.
- *
- * Note: the bridge passed should be the one closest to the encoder
- */
-void drm_bridge_chain_post_disable(struct drm_bridge *bridge)
-{
- struct drm_encoder *encoder;
-
- if (!bridge)
- return;
-
- encoder = bridge->encoder;
- list_for_each_entry_from(bridge, >bridge_chain, chain_node) {
- if (bridge->funcs->post_disable)
- bridge->funcs->post_disable(bridge);
- }
-}
-EXPORT_SYMBOL(drm_bridge_chain_post_disable);
-
/**
* drm_bridge_chain_mode_set - set proposed mode for all bridges in the
*encoder chain
@@ -569,61 +514,6 @@ void drm_bridge_chain_mode_set(struct drm_bridge *bridge,
}
EXPORT_SYMBOL(drm_bridge_chain_mode_set);
-/**
- * drm_bridge_chain_pre_enable - prepares for enabling all bridges in the
- * encoder chain
- * @bridge: bridge control structure
- *
- * Calls _bridge_funcs.pre_enable op for all the bridges in the encoder
- * chain, starting from the last bridge to the first. These are called
- * before calling the encoder's commit op.
- *
- * Note: the bridge passed should be the one closest to the encoder
- */
-void drm_bridge_chain_pre_enable(struct drm_bridge *bridge)
-{
- struct drm_encoder *encoder;
- struct drm_bridge *iter;
-
- if (!bridge)
- return;
-
- encoder = bridge->encoder;
- list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
- if (iter->funcs->pre_enable)
- iter->funcs->pre_enable(iter);
-
- if (iter == bridge)
- break;
- }
-}
-EXPORT_SYMBOL(drm_bridge_chain_pre_enable);
-
-/**
- * drm_bridge_chain_enable - enables all bridges in the encoder chain
- * @bridge: bridge control structure
- *
- * Calls _bridge_funcs.enable op for all the bridges in the encoder
- * chain, starting from the first bridge to the last. These are called
- * after completing the encoder's commit op.
- *
- * Note that the bridge passed should be the one closest to the encoder
- */
-void drm_bridge_chain_enable(struct drm_bridge *bridge)
-{
- struct drm_encoder *encoder;
-
- if (!bridge)
- return;
-
- encoder = bridge->encoder;
- list_for_each_entry_from(bridge, >bridge_chain, chain_node) {
- if (bridge->funcs->enable)
- bridge->funcs->enable(bridge);
- }
-}
-EXPORT_SYMBOL(drm_bridge_chain_enable);
-
/**
* drm_atomic_bridge_chain_disable - disables all bridges in the encoder chain
* @bridge: bridge control structure
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 061d87313fac..f1eb71ff5379 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -297,12 +297,6
[PATCH v2 1/7] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v2:
- Added a few more people to cc: (Jitao, Enric, Philip) to increase
possibility to get test feedback
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Jitao Shi
Cc: Enric Balletbo i Serra
Cc: Philip Chen
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/parade-ps8640.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 3aaa90913bf8..0b620afe99c0 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -376,7 +376,8 @@ static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
ps_bridge->powered = false;
}
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_atomic_pre_enable(struct drm_bridge *bridge,
+struct drm_bridge_state *old_bridge_state)
{
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
@@ -388,7 +389,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
ps8640_bridge_poweroff(ps_bridge);
}
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state
*old_bridge_state)
{
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
@@ -489,7 +491,7 @@ static struct edid *ps8640_bridge_get_edid(struct
drm_bridge *bridge,
* EDID, for this chip, we need to do a full poweron, otherwise it will
* fail.
*/
- drm_bridge_chain_pre_enable(bridge);
+ drm_atomic_bridge_chain_pre_enable(bridge, connector->state->state);
edid = drm_get_edid(connector,
ps_bridge->page[PAGE0_DP_CNTL]->adapter);
@@ -499,7 +501,7 @@ static struct edid *ps8640_bridge_get_edid(struct
drm_bridge *bridge,
* before, return the chip to its original power state.
*/
if (poweroff)
- drm_bridge_chain_post_disable(bridge);
+ drm_atomic_bridge_chain_post_disable(bridge,
connector->state->state);
return edid;
}
@@ -508,8 +510,8 @@ static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
.detach = ps8640_bridge_detach,
.get_edid = ps8640_bridge_get_edid,
- .post_disable = ps8640_post_disable,
- .pre_enable = ps8640_pre_enable,
+ .atomic_post_disable = ps8640_atomic_post_disable,
+ .atomic_pre_enable = ps8640_atomic_pre_enable,
};
static int ps8640_probe(struct i2c_client *client)
--
2.30.2
PATCH [v2 0/7] drm/bridge: Drop deprecated functions
Over time we have accumulated some deprecated functions etc. in drm_bridge. This patch-set starts to move over to the atomic variants and deletes what is not used anymore. There was only one user of the non-atomic drm_bridge_chain functions in parade-ps8640 - migrate it to the atomic variants and delete the non-atomic drm_bridge_chain functions. There was only one user of drm_bridge_chain_mode_fixup in mediatk. The use in the mediatek driver was wrong and with the single user gone we could also delete this function. Added a few todo items. Next step is to migrate the easy bridge drivers to use the atomic variants of drm_bridge_funcs operations. The easy ones are the drivers wihtout mode_set or mode_fixup. I have something typed up already, but wanted feedback on this patchset before sending out additional patches. v2: v2 have been long in the coming as I wanted to wait until I started to have some spare time for linux stuff again, and thus time to address any comments timely. - Added Maxime's r-b (from old thread, so using old mail address [1]) - Fixed several small issues in patch 3 that introduces a new helper - Added a few more folks on cc in hope to see some testing Sam [1] https://lore.kernel.org/dri-devel/20210722062246.2512666-1-...@ravnborg.org/ Sam Ravnborg (7): drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs drm/bridge: Drop unused drm_bridge_chain functions drm/bridge: Add drm_atomic_get_new_crtc_for_bridge() helper drm/bridge: lontium-lt9611: Use atomic variants of drm_bridge_funcs drm/mediatek: Drop chain_mode_fixup call in mode_valid() drm/bridge: Drop drm_bridge_chain_mode_fixup drm/todo: Add bridge related todo items Documentation/gpu/todo.rst | 49 +++ drivers/gpu/drm/bridge/lontium-lt9611.c | 75 +++- drivers/gpu/drm/bridge/parade-ps8640.c | 14 +-- drivers/gpu/drm/drm_atomic.c| 42 + drivers/gpu/drm/drm_bridge.c| 147 drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 --- include/drm/drm_atomic.h| 3 + include/drm/drm_bridge.h| 31 --- 8 files changed, 135 insertions(+), 237 deletions(-)
[PATCH] drm/msm: Fix potential NULL dereference in DPU SSPP
Move initialization of sblk in _sspp_subblk_offset() after NULL check to
avoid potential NULL pointer dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 69eed7932486..f9460672176a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -138,11 +138,13 @@ static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
u32 *idx)
{
int rc = 0;
- const struct dpu_sspp_sub_blks *sblk = ctx->cap->sblk;
+ const struct dpu_sspp_sub_blks *sblk;
- if (!ctx)
+ if (!ctx || !ctx->cap || !ctx->cap->sblk)
return -EINVAL;
+ sblk = ctx->cap->sblk;
+
switch (s_id) {
case DPU_SSPP_SRC:
*idx = sblk->src_blk.base;
@@ -419,7 +421,7 @@ static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe
*ctx,
(void)pe;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, ) || !sspp
- || !scaler3_cfg || !ctx || !ctx->cap || !ctx->cap->sblk)
+ || !scaler3_cfg)
return;
dpu_hw_setup_scaler3(>hw, scaler3_cfg, idx,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] MAINTAINERS: Update email of Andrzej Hajda
On 18/10/2021 23:13, Andrzej Hajda wrote: > Beside updating email, the patch updates maintainers > of Samsung drivers. > > Signed-off-by: Andrzej Hajda > --- > .mailmap| 1 + > MAINTAINERS | 13 - > 2 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/.mailmap b/.mailmap > index 4f6e37da60589..4283a86f70d26 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -40,6 +40,7 @@ Andrew Vasquez > Andrey Konovalov > Andrey Ryabinin > Andrey Ryabinin > +Andrzej Hajda > Andy Adamson > Antoine Tenart > Antoine Tenart > diff --git a/MAINTAINERS b/MAINTAINERS > index 54cd05d3aab65..e3fadb4ebced3 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2546,7 +2546,7 @@ N: s3c64xx > N: s5pv210 > > ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT > -M: Andrzej Hajda > +M: Łukasz Stelmach > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > L: linux-me...@vger.kernel.org > S: Maintained > @@ -2570,7 +2570,8 @@ S: Maintained > F: drivers/media/platform/s5p-jpeg/ > > ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT > -M: Andrzej Hajda > +M: Marek Szyprowski > +M: Andrzej Hajda > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > L: linux-me...@vger.kernel.org > S: Maintained > @@ -6254,7 +6255,7 @@ F: Documentation/devicetree/bindings/display/atmel/ > F: drivers/gpu/drm/atmel-hlcdc/ > > DRM DRIVERS FOR BRIDGE CHIPS > -M: Andrzej Hajda > +M: Andrzej Hajda > M: Neil Armstrong > M: Robert Foss > R: Laurent Pinchart > @@ -16748,13 +16749,15 @@ F: > Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml > F: drivers/nfc/s3fwrn5 Acked-by: Neil Armstrong > > SAMSUNG S5C73M3 CAMERA DRIVER > -M: Andrzej Hajda > +M: Sylwester Nawrocki > +M: Andrzej Hajda > L: linux-me...@vger.kernel.org > S: Supported > F: drivers/media/i2c/s5c73m3/* > > SAMSUNG S5K5BAF CAMERA DRIVER > -M: Andrzej Hajda > +M: Sylwester Nawrocki > +M: Andrzej Hajda > L: linux-me...@vger.kernel.org > S: Supported > F: drivers/media/i2c/s5k5baf.c >
Re: [PATCH] drm/ttm: fix memleak in ttm_transfered_destroy
Am 20.10.21 um 19:43 schrieb Alex Deucher: On Wed, Oct 20, 2021 at 1:32 PM Christian König wrote: We need to cleanup the fences for ghost objects as well. Signed-off-by: Christian König CC: Does this fix this bug? https://bugzilla.kernel.org/show_bug.cgi?id=214029 Yeah, I was already adding that patch to the bug report as potential fix. Christian. Alex --- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 82af095f6b81..f37a8c53b35f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -190,6 +190,7 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) struct ttm_transfer_obj *fbo; fbo = container_of(bo, struct ttm_transfer_obj, base); + dma_resv_fini(>base.base._resv); ttm_bo_put(fbo->bo); kfree(fbo); } -- 2.25.1
[Bug 214029] [bisected] [amdgpu] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 --- Comment #19 from Christian König (christian.koe...@amd.com) --- Created attachment 299277 --> https://bugzilla.kernel.org/attachment.cgi?id=299277=edit Potential fix -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm/ttm: fix memleak in ttm_transfered_destroy
On Wed, Oct 20, 2021 at 1:32 PM Christian König wrote: > > We need to cleanup the fences for ghost objects as well. > > Signed-off-by: Christian König > CC: Does this fix this bug? https://bugzilla.kernel.org/show_bug.cgi?id=214029 Alex > --- > drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > b/drivers/gpu/drm/ttm/ttm_bo_util.c > index 82af095f6b81..f37a8c53b35f 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -190,6 +190,7 @@ static void ttm_transfered_destroy(struct > ttm_buffer_object *bo) > struct ttm_transfer_obj *fbo; > > fbo = container_of(bo, struct ttm_transfer_obj, base); > + dma_resv_fini(>base.base._resv); > ttm_bo_put(fbo->bo); > kfree(fbo); > } > -- > 2.25.1 >
Re: [PATCH v2 2/2] dt-bindings: Add SC7280 compatible string
Hi,
On Wed, Oct 20, 2021 at 5:14 AM Sankeerth Billakanti
wrote:
>
> From: Sankeerth Billakanti
>
> The Qualcomm SC7280 platform supports an eDP controller, add
> compatible string for it to dp-controller.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> 1 file changed, 1 insertion(+)
I think you ignored some of the feedback that was given on v1. Perhaps
you could go back and re-read that feedback? See the replies to:
https://lore.kernel.org/r/1628726882-27841-3-git-send-email-sbill...@codeaurora.org/
For one, ${SUBJECT} needs updating. It's probably as simple as adding
the "msm/dp" tag, like:
dt-bindings: msm/dp: Add SC7280 compatible string
For another, Stephen requested that you add "sc7280-dp" too.
[PATCH] drm/ttm: fix memleak in ttm_transfered_destroy
We need to cleanup the fences for ghost objects as well. Signed-off-by: Christian König CC: --- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index 82af095f6b81..f37a8c53b35f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -190,6 +190,7 @@ static void ttm_transfered_destroy(struct ttm_buffer_object *bo) struct ttm_transfer_obj *fbo; fbo = container_of(bo, struct ttm_transfer_obj, base); + dma_resv_fini(>base.base._resv); ttm_bo_put(fbo->bo); kfree(fbo); } -- 2.25.1
[PATCH v2] MAINTAINERS: Fixup drm-misc website link
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html gives HTTP 404, and https://01.org/linuxgraphics/gfx-docs/maintainer-tools/ redirects to freedesktop.org now. Let's save people the pain of figuring that out. Signed-off-by: Brian Norris Reviewed-by: Sean Paul --- Changes in v2: - Correct the patch description text MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 100d7f93a15b..811d8d3e35fb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6158,7 +6158,7 @@ M:Maarten Lankhorst M: Maxime Ripard M: Thomas Zimmermann S: Maintained -W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html +W: https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/gpu/ F: drivers/gpu/drm/* -- 2.33.0.1079.g6e70778dc9-goog
Re: [PATCH] MAINTAINERS: Fixup drm-misc website link
On Tue, Oct 19, 2021 at 5:59 PM Brian Norris wrote: > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html gives > HTTP 404, and https://drm.pages.freedesktop.org/maintainer-tools/ > redirects to freedesktop.org now. With a dash of irony, I actually listed the wrong URLs in the description. (I used the properly-redirected ones, and claimed that they were the broken ones.) I'll send a v2, so a maintainer doesn't have to fix that up for me. Brian
Re: [PATCH v1 2/2] mm: remove extra ZONE_DEVICE struct page refcount
On Wed, Oct 20, 2021 at 10:09 AM Joao Martins wrote: > > On 10/19/21 20:21, Dan Williams wrote: > > On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote: > >> > >> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote: > >>> On 10/19/21 00:06, Jason Gunthorpe wrote: > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote: > > >> device-dax uses PUD, along with TTM, they are the only places. I'm not > >> sure TTM is a real place though. > > > > I was setting device-dax aside because it can use Joao's changes to > > get compound-page support. > > Ideally, but that ideas in that patch series have been floating around > for a long time now.. > > >>> The current status of the series misses a Rb on patches 6,7,10,12-14. > >>> Well, patch 8 too should now drop its tag, considering the latest > >>> discussion. > >>> > >>> If it helps moving things forward I could split my series further into: > >>> > >>> 1) the compound page introduction (patches 1-7) of my aforementioned > >>> series > >>> 2) vmemmap deduplication for memory gains (patches 9-14) > >>> 3) gup improvements (patch 8 and gup-slow improvements) > >> > >> I would split it, yes.. > >> > >> I think we can see a general consensus that making compound_head/etc > >> work consistently with how THP uses it will provide value and > >> opportunity for optimization going forward. > >> > > I'll go do that. Meanwhile, I'll wait a couple days for Dan to review the > dax subsystem patches (6 & 7), or otherwise send them over. > > >>> Whats the benefit between preventing longterm at start > >>> versus only after mounting the filesystem? Or is the intended future > >>> purpose > >>> to pass more context into an holder potential future callback e.g. nack > >>> longterm > >>> pins on a page basis? > >> > >> I understood Dan's remark that the device-dax path allows > >> FOLL_LONGTERM and the FSDAX path does not ? > >> > >> Which, IIRC, today is signaled basd on vma properties and in all cases > >> fast-gup is denied. > > > > Yeah, I forgot that 7af75561e171 eliminated any possibility of > > longterm-gup-fast for device-dax, let's not disturb that status quo. > > > I am slightly confused by this comment -- the status quo is what we are > questioning here -- And we talked about changing that in the past too > (thread below), that longterm-gup-fast was an oversight that that commit > was only applicable to fsdax. [Maybe this is just my english confusion] No, you have it correct. However that "regression" has gone unnoticed, so unless there is data showing that gup-fast on device-dax is critical for longterm page pinning workflows I'm ok for longterm to continue to trigger gup-slow.
[PATCH v2] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
That change attempted to improve the DRM drivers fbdev emulation device
names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
But unfortunately, there are user-space programs such as pm-utils that
match against the fbdev names and so broke after the mentioned commit.
Since the names in /proc/fb are used by tools that consider it an uAPI,
let's restore the old names even when this lead to silly names like the
one mentioned above.
Fixes: b3484d2b03e4 ("drm/fb-helper: improve DRM fbdev emulation device names")
Reported-by: Johannes Stezenbach
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Ville Syrjälä
---
Changes in v2:
- Add a comment explaining that the current /proc/fb names are an uAPI.
- Add a Fixes: tag so it can be cherry-picked by stable kernels.
- Add Ville Syrjälä's Reviewed-by tag.
drivers/gpu/drm/drm_fb_helper.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8e7a124d6c5a..22bf690910b2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1743,7 +1743,13 @@ void drm_fb_helper_fill_info(struct fb_info *info,
sizes->fb_width, sizes->fb_height);
info->par = fb_helper;
- snprintf(info->fix.id, sizeof(info->fix.id), "%s",
+ /*
+* The DRM drivers fbdev emulation device name can be confusing if the
+* driver name also has a "drm" suffix on it. Leading to names such as
+* "simpledrmdrmfb" in /proc/fb. Unfortunately, it's an uAPI and can't
+* be changed due user-space tools (e.g: pm-utils) matching against it.
+*/
+ snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
fb_helper->dev->driver->name);
}
--
2.31.1
Re: [PATCH] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
Hello Daniel, On 10/13/21 14:27, Daniel Vetter wrote: >>> >>> info->par = fb_helper; >>> - snprintf(info->fix.id, sizeof(info->fix.id), "%s", > > Please add a comment here that drmfb is uapi because pm-utils matches > against it ... > Sure, I'll do that and send a v2. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH 2/3] dt-bindings: ili9881c: add rotation property
Allow the standard rotation property from panel-common for ILI9881C based panels. Signed-off-by: John Keeping --- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index 032bae7891ad..c5d1df680858 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -25,6 +25,7 @@ properties: power-supply: true reg: true reset-gpios: true + rotation: true required: - compatible -- 2.33.1
[PATCH 0/3] drm/panel: ilitek-ili9881c: Read panel orientation
Support the "rotation" DT property for ILI9881C based panels. The first patch is a fix for the binding, then the usual binding update followed by the corresponding driver update. John Keeping (3): dt-bindings: ili9881c: add missing panel-common inheritance dt-bindings: ili9881c: add rotation property drm/panel: ilitek-ili9881c: Read panel orientation .../bindings/display/panel/ilitek,ili9881c.yaml | 4 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 11 +++ 2 files changed, 15 insertions(+) -- 2.33.1
[PATCH 3/3] drm/panel: ilitek-ili9881c: Read panel orientation
The panel orientation needs to parsed from a device-tree and assigned to
the panel's connector in order to make orientation property available to
userspace. That's what this patch does for ILI9881C based panels.
Signed-off-by: John Keeping
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index d68c52bd53c2..ba30d11547ad 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -52,6 +52,8 @@ struct ili9881c {
struct regulator*power;
struct gpio_desc*reset;
+
+ enum drm_panel_orientation orientation;
};
#define ILI9881C_SWITCH_PAGE_INSTR(_page) \
@@ -851,6 +853,8 @@ static int ili9881c_get_modes(struct drm_panel *panel,
connector->display_info.width_mm = mode->width_mm;
connector->display_info.height_mm = mode->height_mm;
+ drm_connector_set_panel_orientation(connector, ctx->orientation);
+
return 1;
}
@@ -887,6 +891,13 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return dev_err_probe(>dev, PTR_ERR(ctx->reset),
"Couldn't get our reset GPIO\n");
+ ret = of_drm_get_panel_orientation(dsi->dev.of_node, >orientation);
+ if (ret) {
+ dev_err(>dev, "%pOF: failed to get orientation: %d\n",
+ dsi->dev.of_node, ret);
+ return ret;
+ }
+
ret = drm_panel_of_backlight(>panel);
if (ret)
return ret;
--
2.33.1
[PATCH 1/3] dt-bindings: ili9881c: add missing panel-common inheritance
The properties below refer to items in panel-common.yaml, which means that needs to be referenced in the schema. Signed-off-by: John Keeping --- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index 07789d554889..032bae7891ad 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -9,6 +9,9 @@ title: Ilitek ILI9881c based MIPI-DSI panels maintainers: - Maxime Ripard +allOf: + - $ref: panel-common.yaml# + properties: compatible: items: -- 2.33.1
Re: [Intel-gfx] [PATCH 2/4] mm: add a io_mapping_map_user helper
On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
Add a helper that calls remap_pfn_range for an struct io_mapping, relying
on the pgprot pre-validation done when creating the mapping instead of
doing it at runtime.
Signed-off-by: Christoph Hellwig
---
include/linux/io-mapping.h | 3 +++
mm/Kconfig | 3 +++
mm/Makefile| 1 +
mm/io-mapping.c| 29 +
4 files changed, 36 insertions(+)
create mode 100644 mm/io-mapping.c
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index c093e81310a9b3..e9743cfd858527 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -220,3 +220,6 @@ io_mapping_free(struct io_mapping *iomap)
}
#endif /* _LINUX_IO_MAPPING_H */
+
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+ unsigned long addr, unsigned long pfn, unsigned long size);
I'm not sure what exactly brought me to check this, but while debugging
I noticed this outside the header guard. But then after some more checks I
saw nothing actually selects CONFIG_IO_MAPPING because commit using
it was reverted in commit 0e4fe0c9f2f9 ("Revert "i915: use
io_mapping_map_user"")
Is this something we want to re-attempt moving to mm/ ?
thanks
Lucas De Marchi
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b9506..6b0f2cfbfac0f3 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -872,4 +872,7 @@ config MAPPING_DIRTY_HELPERS
config KMAP_LOCAL
bool
+# struct io_mapping based helper. Selected by drivers that need them
+config IO_MAPPING
+ bool
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index 72227b24a61688..c0135e385984bb 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -120,3 +120,4 @@ obj-$(CONFIG_MEMFD_CREATE) += memfd.o
obj-$(CONFIG_MAPPING_DIRTY_HELPERS) += mapping_dirty_helpers.o
obj-$(CONFIG_PTDUMP_CORE) += ptdump.o
obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
+obj-$(CONFIG_IO_MAPPING) += io-mapping.o
diff --git a/mm/io-mapping.c b/mm/io-mapping.c
new file mode 100644
index 00..01b3627999304e
--- /dev/null
+++ b/mm/io-mapping.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+
+/**
+ * io_mapping_map_user - remap an I/O mapping to userspace
+ * @iomap: the source io_mapping
+ * @vma: user vma to map to
+ * @addr: target user address to start at
+ * @pfn: physical address of kernel memory
+ * @size: size of map area
+ *
+ * Note: this is only safe if the mm semaphore is held when called.
+ */
+int io_mapping_map_user(struct io_mapping *iomap, struct vm_area_struct *vma,
+ unsigned long addr, unsigned long pfn, unsigned long size)
+{
+ vm_flags_t expected_flags = VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+
+ if (WARN_ON_ONCE((vma->vm_flags & expected_flags) != expected_flags))
+ return -EINVAL;
+
+ /* We rely on prevalidation of the io-mapping to skip track_pfn(). */
+ return remap_pfn_range_notrack(vma, addr, pfn, size,
+ __pgprot((pgprot_val(iomap->prot) & _PAGE_CACHE_MASK) |
+(pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK)));
+}
+EXPORT_SYMBOL_GPL(io_mapping_map_user);
--
2.30.1
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Bug 214621] WARNING: CPU: 3 PID: 521 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0xb64/0xe40 [ttm]
https://bugzilla.kernel.org/show_bug.cgi?id=214621 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- *** This bug has been marked as a duplicate of bug 213983 *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213983] WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm]
https://bugzilla.kernel.org/show_bug.cgi?id=213983 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- *** Bug 214621 has been marked as a duplicate of this bug. *** -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > While the pages can't be swapped out, they can be discarded by the > shrinker. > Normally such objects are marked with __I915_MADV_PURGED, which can't > be > unset, and therefore requires a new object. For kernel internal > objects > this is not true, since the madv hint is reset for our special > volatile > objects, such that we can re-acquire new pages, if so desired, > without > needing a new object. As a result we should probably be paranoid here > and put the object back into the CPU domain when discarding the > pages, > and also correctly set cache_dirty, if required. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Thomas Hellström
Re: [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > Just like we do for internal objects. Also just use > i915_gem_object_set_cache_coherency() here. No need for over-flushing > on > LLC platforms. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > Reivewed-by: Thomas Hellström
Re: [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
On 10/18/21 19:45, Matthew Auld wrote: Add some details around non-LLC platforms and cflushing, when dealing with the flush-on-acquire, which is potentially security sensitive. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Daniel Vetter --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 11 .../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++ 2 files changed, 38 insertions(+) Lgtm. Reviewed-by: Thomas Hellström
Re: [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
On 10/18/21 19:45, Matthew Auld wrote: On non-LLC platforms, force the flush-on-acquire if this is ever swapped-in. Our async flush path is not trust worthy enough yet(and happens in the wrong order), and with some tricks it's conceivable for userspace to change the cache-level to I915_CACHE_NONE after the pages are swapped-in, and since execbuf binds the object before doing the async flush, there is a potential race window. Reviewed-by: Thomas Hellström
Re: [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
On 10/18/21 19:45, Matthew Auld wrote: Even though userptr objects are always coherent with the GPU, with no way for userspace to change this with the set_caching ioctl, even on non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which might permit reading the contents of main memory directly. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Thomas Hellström diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 887aca9e8dd2..3173c9f9a040 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj) goto err; } - sg_page_sizes = i915_sg_dma_sizes(st->sgl); + WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE)); + if (i915_gem_object_can_bypass_llc(obj)) + obj->cache_dirty = true; + sg_page_sizes = i915_sg_dma_sizes(st->sgl); __i915_gem_object_set_pages(obj, st, sg_page_sizes); return 0;
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.14.6 |5.14.13 --- Comment #22 from Andreas (icedragon...@web.de) --- Interessting idea with the DP 1.2 support. I have tested around with disabling the 1.2 DP support on my LCD, but this only decrease the FPS from 60Hz down to 30Hz on 4k scree-size. But also with disabled DP 1.2 support (of the LCD) and/or with decreasing the screen size to full-hd only - did not help: the issue is still persistent and is still reproducible until the latest main-line kernel 5.14.13 (5.14.14 testing in the next days). -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > As pointed out by Thomas, we likely need to flush the pages here if > the > GPU can read the page contents directly from main memory. Underneath > we > don't know what the sg_table is pointing to, so just add a > wbinvd_on_all_cpus() here, for now. > > Reported-by: Thomas Hellström > Signed-off-by: Matthew Auld > Cc: Thomas Hellström Reviewed-by: Thomas Hellström
Re: [PATCH 3/9] drm/i915: extract bypass-llc check into helper
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > It looks like we will need this in some more places, so extract as a > helper. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 > ++ > drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 + > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +- > 3 files changed, 28 insertions(+), 16 deletions(-) > Reviewed-by: Thomas Hellström
Re: [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > These are userspace objects, so mark them as such. In a later patch > it's > useful to determine how paranoid we need to be when managing cache > flushes. In theory no functional changes. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Thomas Hellström
Re: [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote: > These are userspace objects, so mark them as such. In a later patch > it's > useful to determine how paranoid we need to be when managing cache > flushes. In theory no functional changes. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > Reviewed-by: Thomas Hellström
Re: [PATCH v9 6/8] drm/i915/ttm: move shrinker management into adjust_lru
On Mon, 2021-10-18 at 10:10 +0100, Matthew Auld wrote:
> We currently just evict lmem objects to system memory when under
> memory
> pressure. For this case we might lack the usual object mm.pages,
> which
> effectively hides the pages from the i915-gem shrinker, until we
> actually "attach" the TT to the object, or in the case of lmem-only
> objects it just gets migrated back to lmem when touched again.
>
> For all cases we can just adjust the i915 shrinker LRU each time we
> also
> adjust the TTM LRU. The two cases we care about are:
>
> 1) When something is moved by TTM, including when initially
> populating
> an object. Importantly this covers the case where TTM moves
> something from
> lmem <-> smem, outside of the normal get_pages() interface,
> which
> should still ensure the shmem pages underneath are reclaimable.
>
> 2) When calling into i915_gem_object_unlock(). The unlock should
> ensure the object is removed from the shinker LRU, if it was
> indeed
> swapped out, or just purged, when the shrinker drops the object
> lock.
>
> v2(Thomas):
> - Handle managing the shrinker LRU in adjust_lru, where it is
> always
> safe to touch the object.
> v3(Thomas):
> - Pretty much a re-write. This time piggy back off the shrink_pin
> stuff, which actually seems to fit quite well for what we want
> here.
> v4(Thomas):
> - Just use a simple boolean for tracking ttm_shrinkable.
> v5:
> - Ensure we call adjust_lru when faulting the object, to ensure the
> pages are visible to the shrinker, if needed.
> - Add back the adjust_lru when in i915_ttm_move (Thomas)
> v6(Reported-by: kernel test robot ):
> - Remove unused i915_tt
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Reviewed-by: Thomas Hellström #v4
R-B also for v6. Note that this may clash with a recent patch by Jason
Gunthorpe that removes the last argument of ttm_bo_vm_fault_reserved().
/Thomas
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 ++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 14 ++-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 45 --
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 87 -
> --
> 5 files changed, 137 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index e641db297e0e..3eac8cf2ae10 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -294,6 +294,12 @@ i915_gem_object_is_shrinkable(const struct
> drm_i915_gem_object *obj)
> return i915_gem_object_type_has(obj,
> I915_GEM_OBJECT_IS_SHRINKABLE);
> }
>
> +static inline bool
> +i915_gem_object_has_self_managed_shrink_list(const struct
> drm_i915_gem_object *obj)
> +{
> + return i915_gem_object_type_has(obj,
> I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST);
> +}
> +
> static inline bool
> i915_gem_object_is_proxy(const struct drm_i915_gem_object *obj)
> {
> @@ -531,6 +537,8 @@ i915_gem_object_pin_to_display_plane(struct
> drm_i915_gem_object *obj,
>
> void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object
> *obj);
> void i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
> +void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object
> *obj);
> +void __i915_gem_object_make_purgeable(struct drm_i915_gem_object
> *obj);
> void i915_gem_object_make_purgeable(struct drm_i915_gem_object
> *obj);
>
> static inline bool cpu_write_needs_clflush(struct
> drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index f4233c4e8d2e..5718a09f5533 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -34,9 +34,11 @@ struct i915_lut_handle {
>
> struct drm_i915_gem_object_ops {
> unsigned int flags;
> -#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
> -#define I915_GEM_OBJECT_IS_PROXY BIT(2)
> -#define I915_GEM_OBJECT_NO_MMAPBIT(3)
> +#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
> +/* Skip the shrinker management in set_pages/unset_pages */
> +#define I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST BIT(2)
> +#define I915_GEM_OBJECT_IS_PROXY BIT(3)
> +#define
> I915_GEM_OBJECT_NO_MMAPBIT(4)
>
> /* Interface between the GEM object and its backing storage.
> * get_pages() is called once prior to the use of the
> associated set
> @@ -485,6 +487,12 @@ struct drm_i915_gem_object {
> */
> atomic_t shrink_pin;
>
> + /**
> + * @ttm_shrinkable: True when the object is using
> shmem pages
> + * underneath. Protected by the object lock.
> + */
> +
[PATCH 3/4] drm/amd/display: Add DP 2.0 MST DC Support
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/gpu/drm/amd/display/dc/dc_stream.h| 13 +
5 files changed, 333 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8be04be19124..935a50d6e933 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -2354,6 +2354,11 @@ static enum surface_update_type
check_update_surfaces_for_stream(
if (stream_update->dsc_config)
su_flags->bits.dsc_changed = 1;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update)
+ su_flags->bits.mst_bw = 1;
+#endif
+
if (su_flags->raw != 0)
overall_type = UPDATE_TYPE_FULL;
@@ -2731,6 +2736,15 @@ static void commit_planes_do_stream_update(struct dc *dc,
if (stream_update->dsc_config)
dp_update_dsc_config(pipe_ctx);
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ if (stream_update->mst_bw_update) {
+ if (stream_update->mst_bw_update->is_increase)
+ dc_link_increase_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ else
+ dc_link_reduce_mst_payload(pipe_ctx,
stream_update->mst_bw_update->mst_stream_bw);
+ }
+#endif
+
if (stream_update->pending_test_pattern) {
dc_link_dp_set_test_pattern(stream->link,
stream->test_pattern.type,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index e5d6cbd7ea78..b23972b6a27c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3232,6 +3232,9 @@ static struct fixed31_32 get_pbn_from_timing(struct
pipe_ctx *pipe_ctx)
static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
+#endif
const struct dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
@@ -3267,6 +3270,9 @@ static void update_mst_stream_alloc_table(
work_table[i].slot_count =
proposed_table->stream_allocations[i].slot_count;
work_table[i].stream_enc = stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ work_table[i].hpo_dp_stream_enc = hpo_dp_stream_enc;
+#endif
}
}
@@ -3389,6 +3395,10 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
struct dc_link *link = stream->link;
struct link_encoder *link_encoder = NULL;
struct stream_encoder *stream_encoder = pipe_ctx->stream_res.stream_enc;
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ struct hpo_dp_link_encoder *hpo_dp_link_encoder = link->hpo_dp_link_enc;
+ struct hpo_dp_stream_encoder *hpo_dp_stream_encoder =
pipe_ctx->stream_res.hpo_dp_stream_enc;
+#endif
struct dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
@@ -3416,7 +3426,14 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
_table,
true)) {
update_mst_stream_alloc_table(
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ link,
+ pipe_ctx->stream_res.stream_enc,
+ pipe_ctx->stream_res.hpo_dp_stream_enc,
+ _table);
+#else
link, pipe_ctx->stream_res.stream_enc,
_table);
+#endif
}
else
DC_LOG_WARNING("Failed to update"
@@ -3430,6 +3447,20 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
link->mst_stream_alloc_table.stream_count);
for (i = 0; i < MAX_CONTROLLER_NUM; i++) {
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ DC_LOG_MST("stream_enc[%d]: %p "
+ "stream[%d].hpo_dp_stream_enc: %p "
+ "stream[%d].vcp_id: %d "
+ "stream[%d].slot_count: %d\n",
+ i,
+ (void *)
[PATCH 1/4] drm: Remove slot checks in dp mst topology during commit
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ad0795afc21c..5ab3b3a46e89 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4332,10 +4332,6 @@ static int drm_dp_init_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
{
int ret;
- /* max. time slots - one slot for MTP header */
- if (slots > 63)
- return -ENOSPC;
-
vcpi->pbn = pbn;
vcpi->aligned_pbn = slots * mgr->pbn_div;
vcpi->num_slots = slots;
@@ -4538,7 +4534,7 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
if (ret) {
- drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d max=63
ret=%d\n",
+ drm_dbg_kms(mgr->dev, "failed to init vcpi slots=%d ret=%d\n",
DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
drm_dp_mst_topology_put_port(port);
goto out;
--
2.25.1
[PATCH 4/4] drm/amd/display: Add DP 2.0 MST DM Support
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e56f73e299ef..875425ee91d0 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10741,6 +10741,8 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
#if defined(CONFIG_DRM_AMD_DC_DCN)
struct dsc_mst_fairness_vars vars[MAX_PIPES];
#endif
+ struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_mst_topology_mgr *mgr;
trace_amdgpu_dm_atomic_check_begin(state);
@@ -10948,6 +10950,33 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
lock_and_validation_needed = true;
}
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ /* set the slot info for each mst_state based on the link encoding
format */
+ for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+ struct amdgpu_dm_connector *aconnector;
+ struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
+ u8 link_coding_cap;
+
+ if (!mgr->mst_state )
+ continue;
+
+ drm_connector_list_iter_begin(dev, );
+ drm_for_each_connector_iter(connector, ) {
+ int id = connector->index;
+
+ if (id == mst_state->mgr->conn_base_id) {
+ aconnector = to_amdgpu_dm_connector(connector);
+ link_coding_cap =
dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+ drm_dp_mst_update_slots(mst_state,
link_coding_cap);
+
+ break;
+ }
+ }
+ drm_connector_list_iter_end();
+
+ }
+#endif
/**
* Streams and planes are reset when there are changes that affect
* bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 9b3ad56607bb..1a68a674913c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -294,6 +294,9 @@ static ssize_t dp_link_settings_write(struct file *f, const
char __user *buf,
case LINK_RATE_RBR2:
case LINK_RATE_HIGH2:
case LINK_RATE_HIGH3:
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+ case LINK_RATE_UHBR10:
+#endif
break;
default:
valid_input = false;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6169488e2011..53b5cc7b0679 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -219,6 +219,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
struct drm_dp_mst_topology_mgr *mst_mgr;
struct drm_dp_mst_port *mst_port;
bool ret;
+ u8 link_coding_cap;
aconnector = (struct amdgpu_dm_connector *)stream->dm_stream_context;
/* Accessing the connector state is required for vcpi_slots allocation
@@ -238,6 +239,8 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
mst_port = aconnector->port;
+ link_coding_cap =
dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+
if (enable) {
ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port,
@@ -251,7 +254,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr, 1);
+ drm_dp_update_payload_part1(mst_mgr, (link_coding_cap ==
DP_CAP_ANSI_128B132B) ? 0:1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
--
2.25.1
[PATCH 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 34 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +--
include/drm/drm_dp_mst_helper.h | 5 ++-
6 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr);
+ drm_dp_update_payload_part1(mst_mgr, 1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5ab3b3a46e89..d188a5269070 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3353,6 +3353,9 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_update_payload_part1() - Execute payload update part 1
* @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the
helper
*
* This iterates over all proposed virtual channels, and tries to
* allocate space in the link for them. For 0->slots transitions,
@@ -3363,12 +3366,12 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
* after calling this the driver should generate ACT and payload
* packets.
*/
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
start_slot)
{
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
- int cur_slots = 1;
+ int cur_slots = start_slot;
bool skip;
mutex_lock(>payload_lock);
@@ -4503,6 +4506,26 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP
ecoding format
+ * @mst_state: mst_state to update
+ * @link_ecoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
uint8_t link_ecoding_cap)
+{
+ if (link_ecoding_cap == DP_CAP_ANSI_128B132B) {
+ mst_state->total_avail_slots = 64;
+ mst_state->start_slot = 0;
+ } else {
+ mst_state->total_avail_slots = 63;
+ mst_state->start_slot = 1;
+ }
+
+ DRM_DEBUG_KMS("%s ecoding format on mst_state 0x%p\n",
+ (link_ecoding_cap == DP_CAP_ANSI_128B132B) ?
"128b/132b":"8b/10b", mst_state->mgr);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
/**
* drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
* @mgr: manager for this port
@@ -5222,7 +5245,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, payload_count = 0;
+ int avail_slots = mst_state->total_avail_slots, payload_count = 0;
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -5251,7 +5274,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
}
}
drm_dbg_atomic(mgr->dev, "[MST MGR:%p] mst state %p VCPI avail=%d
used=%d\n",
- mgr, mst_state, avail_slots, 63 - avail_slots);
+ mgr,
Re: [PATCH v2] drm/ttm: Do not put non-struct page memory into PUD/PMDs
On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote: > Follow up question: If we resurrect this in the proper way (and in that case > only for x86_64) is there something we need to pay particular attention to > WRT the ZONE_DEVICE refcounting fixing you mention above? Similar to PTE it should be completely separated from ZONE_DEVICE. Seeing the special bit set at any level should trigger all page table walkers to never try to get a struct page. Today some of the page table walkers are trying to do this with vma_is_special(), all of those should end up being the Pxx_SPECIAL test instead. Jason
