[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/108170/ State : warning == Summary == Error: dim checkpatch failed 3b7f8723c12c drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup b68f0f0f4f51 drm/i915/pps: Enabled 2nd pps for dual EDP scenario -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: TODO: For dual EDP scenario and panel type invalid (=255), special condition total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/108170/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:1
[Intel-gfx] [PATCH 1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
Simplified pps_get_register() which use get_pps_idx() hook to derive the
pps instance and get_pps_idx() will be initialized at pps_init().
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_pps.c | 12 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..b78b29951241 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1693,6 +1693,7 @@ struct intel_dp {
u8 (*preemph_max)(struct intel_dp *intel_dp);
u8 (*voltage_max)(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
+ int (*get_pps_idx)(struct intel_dp *intel_dp);
/* Displayport compliance testing */
struct intel_dp_compliance compliance;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index 21944f5bf3a8..4e770218e29f 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -362,15 +362,10 @@ static void intel_pps_get_registers(struct intel_dp
*intel_dp,
struct pps_registers *regs)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- int pps_idx = 0;
+ int pps_idx = intel_dp->get_pps_idx(intel_dp);
memset(regs, 0, sizeof(*regs));
- if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
- pps_idx = bxt_power_sequencer_idx(intel_dp);
- else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- pps_idx = vlv_power_sequencer_pipe(intel_dp);
-
regs->pp_ctrl = PP_CONTROL(pps_idx);
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
@@ -1432,6 +1427,11 @@ void intel_pps_init(struct intel_dp *intel_dp)
intel_dp->pps.initializing = true;
INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
+ if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
+ intel_dp->get_pps_idx = bxt_power_sequencer_idx;
+ else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+ intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
+
pps_init_timestamps(intel_dp);
with_intel_pps_lock(intel_dp, wakeref) {
--
2.29.0
[Intel-gfx] [PATCH 2/2] drm/i915/pps: Enabled 2nd pps for dual EDP scenario
>From display gen12 onwards to support dual EDP two instances of pps added. Currently backlight controller and pps instance can be mapped together for a specific panel. Extended support for gen12 for dual EDP usage. TODO: For dual EDP scenario and panel type invalid (=255), special condition check to be added to reject or initialize the panel specific stuff earlier. Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/display/intel_pps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c index 4e770218e29f..a9ed1214a167 100644 --- a/drivers/gpu/drm/i915/display/intel_pps.c +++ b/drivers/gpu/drm/i915/display/intel_pps.c @@ -1427,7 +1427,7 @@ void intel_pps_init(struct intel_dp *intel_dp) intel_dp->pps.initializing = true; INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work); - if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915) || DISPLAY_VER(i915) >= 12) intel_dp->get_pps_idx = bxt_power_sequencer_idx; else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) intel_dp->get_pps_idx = vlv_power_sequencer_pipe; -- 2.29.0
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details ==
Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as
part of pps_get_register() cleanup
URL : https://patchwork.freedesktop.org/series/108170/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12074 -> Patchwork_108170v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108170v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108170v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/index.html
Participating hosts (44 -> 40)
--
Missing(4): fi-cml-u2 fi-rkl-11600 fi-bdw-samus bat-dg2-8
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108170v1:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-skl-6600u/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-kbl-7567u: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-kbl-7567u/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-kbl-7567u/igt@i915_module_l...@load.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {fi-jsl-1}: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-jsl-1/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-jsl-1/igt@i915_module_l...@load.html
- {fi-ehl-2}: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-ehl-2/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-ehl-2/igt@i915_module_l...@load.html
- {bat-rplp-1}: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-rplp-1/igt@i915_module_l...@load.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/bat-rplp-1/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_108170v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][11] -> [INCOMPLETE][12] ([i915#4418])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][13] -> [INCOMPLETE][14] ([i915#4785])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][15] -> [DMESG-FAIL][16] ([i915#4528])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-hsw-4770/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#2403] /
[i915#4312])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-blb-e6850/igt@run...@aborted.html
- fi-skl-6600u: NOTRUN -> [FAIL][21] ([i915#4312] / [i915#6599])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108170v1/fi-skl-6600u/igt@run...@aborted.html
- fi-kbl-7567u: NOTRUN -> [FAIL][22] ([i915#4312] / [i915#6219])
[22]:
htt
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/108171/ State : warning == Summary == Error: dim checkpatch failed ce1c2ba61b63 drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup a121d8efc764 drm/i915/pps: Enabled 2nd pps for dual EDP scenario -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: TODO: For dual EDP scenario and panel type invalid (=255), special condition total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details == Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup URL : https://patchwork.freedesktop.org/series/108171/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:1
Re: [Intel-gfx] [PATCH 1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
On Tue, 06 Sep 2022, Animesh Manna wrote:
> Simplified pps_get_register() which use get_pps_idx() hook to derive the
> pps instance and get_pps_idx() will be initialized at pps_init().
Please use the imperative mood, i.e. "add" in subject, "simplify" here.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> drivers/gpu/drm/i915/display/intel_pps.c | 12 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 0da9b208d56e..b78b29951241 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1693,6 +1693,7 @@ struct intel_dp {
> u8 (*preemph_max)(struct intel_dp *intel_dp);
> u8 (*voltage_max)(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
> + int (*get_pps_idx)(struct intel_dp *intel_dp);
>
> /* Displayport compliance testing */
> struct intel_dp_compliance compliance;
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 21944f5bf3a8..4e770218e29f 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -362,15 +362,10 @@ static void intel_pps_get_registers(struct intel_dp
> *intel_dp,
> struct pps_registers *regs)
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - int pps_idx = 0;
> + int pps_idx = intel_dp->get_pps_idx(intel_dp);
>
> memset(regs, 0, sizeof(*regs));
>
> - if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
> - pps_idx = bxt_power_sequencer_idx(intel_dp);
> - else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - pps_idx = vlv_power_sequencer_pipe(intel_dp);
> -
> regs->pp_ctrl = PP_CONTROL(pps_idx);
> regs->pp_stat = PP_STATUS(pps_idx);
> regs->pp_on = PP_ON_DELAYS(pps_idx);
> @@ -1432,6 +1427,11 @@ void intel_pps_init(struct intel_dp *intel_dp)
> intel_dp->pps.initializing = true;
> INIT_DELAYED_WORK(&intel_dp->pps.panel_vdd_work, edp_panel_vdd_work);
>
> + if (IS_GEMINILAKE(i915) || IS_BROXTON(i915))
> + intel_dp->get_pps_idx = bxt_power_sequencer_idx;
> + else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> + intel_dp->get_pps_idx = vlv_power_sequencer_pipe;
> +
> pps_init_timestamps(intel_dp);
>
> with_intel_pps_lock(intel_dp, wakeref) {
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as part of pps_get_register() cleanup
== Series Details ==
Series: series starting with [1/2] drm/i915/pps: added get_pps_idx() hook as
part of pps_get_register() cleanup
URL : https://patchwork.freedesktop.org/series/108171/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12074 -> Patchwork_108171v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108171v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108171v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/index.html
Participating hosts (44 -> 42)
--
Additional (1): fi-icl-u2
Missing(3): fi-cml-u2 fi-bdw-samus fi-hsw-4770
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108171v1:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-kbl-7567u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-kbl-7567u/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-kbl-7567u/igt@i915_module_l...@load.html
- fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-skl-6600u/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-skl-6600u/igt@i915_module_l...@load.html
- fi-icl-u2: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-icl-u2/igt@i915_module_l...@load.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {fi-jsl-1}: [PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-jsl-1/igt@i915_module_l...@load.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-jsl-1/igt@i915_module_l...@load.html
- {bat-rplp-1}: [PASS][8] -> [DMESG-WARN][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-rplp-1/igt@i915_module_l...@load.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/bat-rplp-1/igt@i915_module_l...@load.html
- {fi-ehl-2}: [PASS][10] -> [INCOMPLETE][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-ehl-2/igt@i915_module_l...@load.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-ehl-2/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_108171v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-kbl-7567u: NOTRUN -> [FAIL][15] ([i915#4312] / [i915#6219])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-kbl-7567u/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#2403] /
[i915#4312])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-blb-e6850/igt@run...@aborted.html
- fi-skl-6600u: NOTRUN -> [FAIL][17] ([i915#4312] / [i915#6599])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2: NOTRUN -> [FAIL][18] ([i915#4312] / [i915#6599])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-8}:[INCOMPLETE][19] ([i915#6580]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-dg2-8/igt@i915_selftest@live@gt_lrc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108171v1/bat-dg2-8/igt@i915_selftest@live@gt_lrc.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][21] ([fdo#103375]) -> [INCOMPLETE][22]
([i915#5982])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/xelpmp: Expose media as another GT
On 03-09-2022 05:02, Matt Roper wrote:
> Xe_LPM+ platforms have "standalone media." I.e., the media unit is
> designed as an additional GT with its own engine list, GuC, forcewake,
> etc. Let's allow platforms to include media GTs in their device info.
>
> v2:
> - Simplify GSI register handling and split it out to a separate patch
>for ease of review. (Daniele)
>
> Cc: Aravind Iddamsetty
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +
> drivers/gpu/drm/i915/gt/intel_sa_media.c | 39
> drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
> drivers/gpu/drm/i915/i915_pci.c | 15 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 4 +++
> 7 files changed, 83 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
> create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 522ef9b4aff3..e83e4cd46968 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -123,6 +123,7 @@ gt-y += \
> gt/intel_ring.o \
> gt/intel_ring_submission.o \
> gt/intel_rps.o \
> + gt/intel_sa_media.o \
> gt/intel_sseu.o \
> gt/intel_sseu_debugfs.o \
> gt/intel_timeline.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index d414785003cc..fb2c56777480 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1578,4 +1578,12 @@
>
> #define GEN12_SFC_DONE(n)_MMIO(0x1cc000 + (n) * 0x1000)
>
> +/*
> + * Standalone Media's non-engine GT registers are located at their regular GT
> + * offsets plus 0x38. This extra offset is stored inside the
> intel_uncore
> + * structure so that the existing code can be used for both GTs without
> + * modification.
> + */
> +#define MTL_MEDIA_GSI_BASE 0x38
> +
> #endif /* __INTEL_GT_REGS__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c
> b/drivers/gpu/drm/i915/gt/intel_sa_media.c
> new file mode 100644
> index ..8c5c519457cc
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
> @@ -0,0 +1,39 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +
> +#include "i915_drv.h"
> +#include "gt/intel_gt.h"
> +#include "gt/intel_sa_media.h"
> +
> +int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
> +u32 gsi_offset)
> +{
> + struct drm_i915_private *i915 = gt->i915;
> + struct intel_uncore *uncore;
> +
> + uncore = drmm_kzalloc(&i915->drm, sizeof(*uncore), GFP_KERNEL);
> + if (!uncore)
> + return -ENOMEM;
> +
> + uncore->gsi_offset = gsi_offset;
> +
> + intel_gt_common_init_early(gt);
> + intel_uncore_init_early(uncore, gt);
> +
> + /*
> + * Standalone media shares the general MMIO space with the primary
> + * GT. We'll re-use the primary GT's mapping.
> + */
> + uncore->regs = i915->uncore.regs;
> + if (drm_WARN_ON(&i915->drm, uncore->regs == NULL))
> + return -EIO;
> +
> + gt->uncore = uncore;
> + gt->phys_addr = phys_addr;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.h
> b/drivers/gpu/drm/i915/gt/intel_sa_media.h
> new file mode 100644
> index ..3afb310de932
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/intel_sa_media.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +#ifndef __INTEL_SA_MEDIA__
> +#define __INTEL_SA_MEDIA__
> +
> +#include
> +
> +struct intel_gt;
> +
> +int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
> +u32 gsi_offset);
> +
> +#endif /* __INTEL_SA_MEDIA_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 26b25d9434d6..18d3722331e4 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -26,6 +26,9 @@
> #include
> #include
>
> +#include "gt/intel_gt_regs.h"
> +#include "gt/intel_sa_media.h"
> +
> #include "i915_driver.h"
> #include "i915_drv.h"
> #include "i915_pci.h"
> @@ -1115,6 +1118,17 @@ static const struct intel_device_info pvc_info = {
> .display.has_cdclk_crawl = 1, \
> .__runtime.fbc_mask = BIT(INTEL_FBC_A) | BIT(INTEL_FBC_B)
>
> +static const struct intel_gt_definition xelpmp_extra_gt[] = {
> + {
> + .type = GT_MEDIA,
> + .name = "Standalone Media GT",
> + .setup = intel_sa_mediagt_setup,
> + .gsi_offset = MTL_MEDIA_GSI_BASE,
> + .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2)
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Equation changed for sending start/stop on prior line
> -Original Message- > From: Hogander, Jouni > Sent: Monday, September 5, 2022 1:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Hogander, Jouni ; Kahola, Mika > ; Souza, Jose > Subject: [PATCH 1/2] drm/i915/psr: Equation changed for sending start/stop on > prior line > > Equation for sending start/end SDP prior to the SU region start/end has > changed. Update used formula. > > Bspec: 49274 > > Cc: Mika Kahola > Cc: José Roberto de Souza Reviewed-by: Mika Kahola > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 079b7d3d0c53..6f03bf16d6f4 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -805,8 +805,8 @@ static bool > _compute_psr2_sdp_prior_scanline_indication(struct intel_dp *intel_d > hblank_total = adjusted_mode->crtc_hblank_end - adjusted_mode- > >crtc_hblank_start; > hblank_ns = div_u64(100ULL * hblank_total, adjusted_mode- > >crtc_clock); > > - /* From spec: (72 / number of lanes) * 1000 / symbol clock frequency > MHz */ > - req_ns = (72 / crtc_state->lane_count) * 1000 / (crtc_state->port_clock > / 1000); > + /* From spec: ((60 / number of lanes) + 11) * 1000 / symbol clock > frequency MHz */ > + req_ns = ((60 / crtc_state->lane_count) + 11) * 1000 / > +(crtc_state->port_clock / 1000); > > if ((hblank_ns - req_ns) > 100) > return true; > -- > 2.34.1
Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Disable PSR2 when SDP is sent on prior line
> -Original Message- > From: Hogander, Jouni > Sent: Monday, September 5, 2022 1:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Hogander, Jouni ; Kahola, Mika > ; Souza, Jose > Subject: [PATCH 2/2] drm/i915/psr: Disable PSR2 when SDP is sent on prior line > > Selective update doesn't work if SU start address is 0 and start/end SDP is > configured to be sent prior to SU start/end lines. PSR2 has to be disabled in > this > case for Alder Lake. > > HSDES: 22012279113 > > Cc: Mika Kahola > Cc: José Roberto de Souza Reviewed-by: Mika Kahola > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 6f03bf16d6f4..90d7cdd743be 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -811,7 +811,8 @@ static bool > _compute_psr2_sdp_prior_scanline_indication(struct intel_dp *intel_d > if ((hblank_ns - req_ns) > 100) > return true; > > - if (DISPLAY_VER(dev_priv) < 13 || intel_dp->edp_dpcd[0] < > DP_EDP_14b) > + /* Not supported <13 / Wa_22012279113:adl-p */ > + if (DISPLAY_VER(dev_priv) <= 13 || intel_dp->edp_dpcd[0] < > DP_EDP_14b) > return false; > > crtc_state->req_psr2_sdp_prior_scanline = true; > -- > 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915: prevent integer overflow in query_engine_info()
Hi Dan,
On 01/09/2022 16:38, Dan Carpenter wrote:
This code uses struct_size() but it stores the result in an int so the
integer overflow checks are not effective. Record the types as size_t
to prevent the size from being truncated.
Fixes: bf3c50837506 ("drm/i915/query: Use struct_size() helper")
Signed-off-by: Dan Carpenter
---
I do not know if the integer overflow can happen. This is a hardenning
patch just like the conversion to struct_size().
It can't since num_uabi_engines in "len = struct_size(query_ptr,
engines, num_uabi_engines);" is max double digits and sizeof(struct
drm_i915_engine_info) is 56 bytes on a glance.
Nevertheless hardening is almost always beneficial so no fundamental
complaints. Just that this patch I think leaves some parts unresolved.
Mostly that copy_query_item now can implicitly truncate in "return
total_length" and likewise query_engine_info in "return ret;".
Maybe we could add, on top of your patch, something like:
static int copy_query_item(void *query_hdr, size_t query_sz,
- u32 total_length,
+ size_t total_length,
struct drm_i915_query_item *query_item)
{
+ if (overflows_type(query_sz, query_item->length) ||
+ overflows_type(total_length, query_item->length))
+ return -ERANGE; /* ??? */
+
(query->item_length is s32 so matches the int return type.)
And change all variables holding result of copy_query_item to size_t.
Don't know, it could be it's an overkill. More opinions?
Regards,
Tvrtko
drivers/gpu/drm/i915/i915_query.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 6ec9c9fb7b0d..43a499fbdc8d 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -13,7 +13,7 @@
#include
static int copy_query_item(void *query_hdr, size_t query_sz,
- u32 total_length,
+ size_t total_length,
struct drm_i915_query_item *query_item)
{
if (query_item->length == 0)
@@ -135,7 +135,8 @@ query_engine_info(struct drm_i915_private *i915,
struct drm_i915_engine_info info = { };
unsigned int num_uabi_engines = 0;
struct intel_engine_cs *engine;
- int len, ret;
+ size_t len;
+ int ret;
if (query_item->flags)
return -EINVAL;
Re: [Intel-gfx] [PATCH v2 01/15] vfio: Add helpers for unifying vfio_device life cycle
What is the point? This adds indirect calls, and actually creates more boilerplate code in the drivers. i.g. when using this code there is more, and harder to read code.
[Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
drm_dp_atomic_find_vcpi_slots no longer exists and needs
to be used as drm_dp_atomic_find_time_slots.
Also rename the function itself.
Signed-off-by: Stanislav Lisovskiy
Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to separate
function")
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 8869b7707cda..54a7b31162c2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -44,7 +44,7 @@
#include "intel_hotplug.h"
#include "skl_scaler.h"
-static int intel_dp_mst_find_vcpi_slots_for_bpp(struct intel_encoder *encoder,
+static int intel_dp_mst_find_time_slots_for_bpp(struct intel_encoder *encoder,
struct intel_crtc_state
*crtc_state,
int max_bpp,
int min_bpp,
@@ -64,7 +64,6 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct
intel_encoder *encoder,
&crtc_state->hw.adjusted_mode;
int bpp, slots = -EINVAL;
int ret = 0;
- int pbn_div;
mst_state = drm_atomic_get_mst_topology_state(state,
&intel_dp->mst_mgr);
if (IS_ERR(mst_state))
@@ -73,9 +72,9 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct
intel_encoder *encoder,
crtc_state->lane_count = limits->max_lane_count;
crtc_state->port_clock = limits->max_rate;
- pbn_div = drm_dp_get_vc_payload_bw(&intel_dp->mst_mgr,
- crtc_state->port_clock,
- crtc_state->lane_count);
+ mst_state->pbn_div = drm_dp_get_vc_payload_bw(&intel_dp->mst_mgr,
+ crtc_state->port_clock,
+ crtc_state->lane_count);
for (bpp = max_bpp; bpp >= min_bpp; bpp -= step) {
crtc_state->pipe_bpp = bpp;
@@ -84,10 +83,9 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct
intel_encoder *encoder,
dsc ? bpp << 4 :
crtc_state->pipe_bpp,
dsc);
- slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
+ slots = drm_dp_atomic_find_time_slots(state, &intel_dp->mst_mgr,
connector->port,
- crtc_state->pbn,
- pbn_div);
+ crtc_state->pbn);
if (slots == -EDEADLK)
return slots;
@@ -126,7 +124,7 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
bool constant_n = drm_dp_has_quirk(&intel_dp->desc,
DP_DPCD_QUIRK_CONSTANT_N);
int slots = -EINVAL;
- slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state,
limits->max_bpp,
+ slots = intel_dp_mst_find_time_slots_for_bpp(encoder, crtc_state,
limits->max_bpp,
limits->min_bpp, limits,
conn_state, 2 * 3, false);
@@ -184,7 +182,7 @@ static int intel_dp_dsc_mst_compute_link_config(struct
intel_encoder *encoder,
drm_dbg_kms(&i915->drm, "DSC Sink supported min bpp %d max bpp %d\n",
min_bpp, max_bpp);
- slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state,
max_bpp,
+ slots = intel_dp_mst_find_time_slots_for_bpp(encoder, crtc_state,
max_bpp,
min_bpp, limits,
conn_state, 2 * 3, true);
--
2.37.3
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
== Series Details == Series: drm/i915: Fix intel_dp_atomic_find_vcpi_slots function URL : https://patchwork.freedesktop.org/series/108184/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/108184/revisions/1/mbox/ not applied Applying: drm/i915: Fix intel_dp_atomic_find_vcpi_slots function Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_dp_mst.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_dp_mst.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_dp_mst.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Fix intel_dp_atomic_find_vcpi_slots function When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/uncore: Add GSI offset to uncore
On 03-09-2022 05:02, Matt Roper wrote:
> GT non-engine registers (referred to as "GSI" registers by the spec)
> have the same relative offsets on standalone media as they do on the
> primary GT, just with an additional "GSI offset" added to their MMIO
> address. If we store this GSI offset in the standalone media's
> intel_uncore structure, it can be automatically applied to all GSI reg
> reads/writes that happen on that GT, allowing us to re-use our existing
> GT code with minimal changes.
>
> Forcewake and shadowed register tables for the media GT (which will be
> added in a future patch) are listed as final addresses that already
> include the GSI offset, so we also need to add the GSI offset before
> doing lookups of registers in one of those tables.
>
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 17 ++---
> drivers/gpu/drm/i915/intel_device_info.h | 4 +++-
> drivers/gpu/drm/i915/intel_uncore.c | 10 --
> drivers/gpu/drm/i915/intel_uncore.h | 22 --
> 4 files changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index fbb5e32979a4..a6ed11b933eb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -776,10 +776,20 @@ void intel_gt_driver_late_release_all(struct
> drm_i915_private *i915)
> }
> }
>
> -static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
> +/*
> + * Note: the gsi_offset parameter here isn't used, but we want to keep the
> + * function signature equivalent to gtdef->setup() so that it can be plugged
> + * in when we enabled remote tiles in the future.
> + */
> +static int intel_gt_tile_setup(struct intel_gt *gt,
> +phys_addr_t phys_addr,
> +u32 gsi_offset)
> {
> int ret;
>
> + /* GSI offset is only applicable for media GTs */
> + drm_WARN_ON(>->i915->drm, gsi_offset);
> +
> if (!gt_is_root(gt)) {
> struct intel_uncore *uncore;
>
> @@ -832,7 +842,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
>
> drm_dbg(&i915->drm, "Setting up %s\n", gt->name);
> - ret = intel_gt_tile_setup(gt, phys_addr);
> + ret = intel_gt_tile_setup(gt, phys_addr, 0);
> if (ret)
> return ret;
>
> @@ -865,7 +875,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
> goto err;
> }
>
> - ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
> +gtdef->gsi_offset);
> if (ret)
> goto err;
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index b408ce384cd7..85e0ef0e91b1 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -254,8 +254,10 @@ struct intel_gt_definition {
> enum intel_gt_type type;
> char *name;
> int (*setup)(struct intel_gt *gt,
> - phys_addr_t phys_addr);
> + phys_addr_t phys_addr,
> + u32 gsi_offset);
> u32 mapping_base;
> + u32 gsi_offset;
> intel_engine_mask_t engine_mask;
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 33bdcbc77ab2..ecb02421502d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -927,6 +927,9 @@ find_fw_domain(struct intel_uncore *uncore, u32 offset)
> {
> const struct intel_forcewake_range *entry;
>
> + if (IS_GSI_REG(offset))
> + offset += uncore->gsi_offset;
> +
> entry = BSEARCH(offset,
> uncore->fw_domains_table,
> uncore->fw_domains_table_entries,
> @@ -1142,6 +1145,9 @@ static bool is_shadowed(struct intel_uncore *uncore,
> u32 offset)
> if (drm_WARN_ON(&uncore->i915->drm, !uncore->shadowed_reg_table))
> return false;
>
> + if (IS_GSI_REG(offset))
> + offset += uncore->gsi_offset;
> +
> return BSEARCH(offset,
> uncore->shadowed_reg_table,
> uncore->shadowed_reg_table_entries,
> @@ -1994,8 +2000,8 @@ static int __fw_domain_init(struct intel_uncore *uncore,
>
> d->uncore = uncore;
> d->wake_count = 0;
> - d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
> - d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack);
> + d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set) +
> uncore->gsi_offset;
> + d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack) +
> uncore->gsi_offset;
>
>
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On 05.09.2022 19:44, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: On 05.09.2022 13:48, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: In case of ICL and older generations disabling plane and/or disabling async update is always performed on vblank, It should only be broken on bdw-glk (see. need_async_flip_disable_wa). On CFL it is reported every drmtip run: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html ... On APL it is less frequent, probably due to other bugs preventing run of this test, last seen at: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html Similar for SKL: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html I am not sure if I correctly read the docs but [1] says that 9th bit of PLANE_CFG (Async Address Update Enable) is "not double buffered and the changes will apply immediately" only for ICL, JSL, LKF1. It got broken in bdw and fixed again in icl. So the change is not necessary in case of icl_plane_disable_arm. [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 but if async update is enabled PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF when plane is still enabled can cause DMAR/PIPE errors. On the other side PLANE_SURF is used to arm plane registers - we need to write to it to trigger update on VBLANK, writting current value should be safe - the buffer address is valid till vblank. I think you're effectively saying that somehow the async flip disable w/a is not kicking in sometimes. I was not aware of existence of this w/a and I am little lost in figuring out how this w/a can prevent zeroing PLANE_SURF too early. When it works as designed it should: 1. turn off the async flip bit 2. wait for vblank so that gets latched 3. do the sync plane update/disable normally After debugging this terra incognita, I've figured out that plane states are not populated in intel_crtc_async_flip_disable_wa so for_each_old_intel_plane_in_state does not iterate over affected planes and w/a does not work at all. I have no idea where affected plane states should be added. Adding them to the beginning of intel_atomic_check helped, but this is just blind shot: @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device *dev, new_crtc_state->uapi.mode_changed = true; if (new_crtc_state->uapi.scaling_filter != old_crtc_state->uapi.scaling_filter) new_crtc_state->uapi.mode_changed = true; + + ret = intel_atomic_add_affected_planes(state, crtc); + if (ret) + goto fail; } intel_vrr_check_modeset(state); ret = drm_atomic_helper_check_modeset(dev, &state->base); Let me know if there is better place/way to handle it. Regards Andrzej
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > > On 05.09.2022 19:44, Ville Syrjälä wrote: > > On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > >> > >> On 05.09.2022 13:48, Ville Syrjälä wrote: > >>> On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > In case of ICL and older generations disabling plane and/or disabling > async update is always performed on vblank, > >>> It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > >> On CFL it is reported every drmtip run: > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > >> ... > >> On APL it is less frequent, probably due to other bugs preventing run of > >> this test, last seen at: > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > >> Similar for SKL: > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > >> > >> I am not sure if I correctly read the docs but [1] says that 9th bit of > >> PLANE_CFG (Async Address Update Enable) is "not double buffered and the > >> changes will apply immediately" only for ICL, JSL, LKF1. > > It got broken in bdw and fixed again in icl. > > > >> So the change is not necessary in case of icl_plane_disable_arm. > >> > >> [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > but if async update is enabled > PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF > when plane is still enabled can cause DMAR/PIPE errors. > On the other side PLANE_SURF is used to arm plane registers - we need to > write to it to trigger update on VBLANK, writting current value should > be safe - the buffer address is valid till vblank. > >>> I think you're effectively saying that somehow the async > >>> flip disable w/a is not kicking in sometimes. > >> I was not aware of existence of this w/a and I am little lost in > >> figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > When it works as designed it should: > > 1. turn off the async flip bit > > 2. wait for vblank so that gets latched > > 3. do the sync plane update/disable normally > > After debugging this terra incognita, I've figured out that plane states > are not populated in intel_crtc_async_flip_disable_wa > so for_each_old_intel_plane_in_state does not iterate over affected > planes and w/a does not work at all. > I have no idea where affected plane states should be added. > Adding them to the beginning of intel_atomic_check helped, but this is > just blind shot: > > @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > *dev, > new_crtc_state->uapi.mode_changed = true; > > if (new_crtc_state->uapi.scaling_filter != > old_crtc_state->uapi.scaling_filter) > new_crtc_state->uapi.mode_changed = true; > + > + ret = intel_atomic_add_affected_planes(state, crtc); > + if (ret) > + goto fail; > } > > intel_vrr_check_modeset(state); > > ret = drm_atomic_helper_check_modeset(dev, &state->base); ^ This guy should be adding them for any crtc that has been flagged for modeset ahead of time. For modesets flagged later we have to add them by hand (eg. in intel_modeset_all_pipes()). For normal plane updates the relevant planes are already added when the property values are updated. > > > Let me know if there is better place/way to handle it. > > Regards > Andrzej -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 02:22:38PM +0300, Ville Syrjälä wrote: > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > > > > > On 05.09.2022 19:44, Ville Syrjälä wrote: > > > On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > > >> > > >> On 05.09.2022 13:48, Ville Syrjälä wrote: > > >>> On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > > In case of ICL and older generations disabling plane and/or disabling > > async update is always performed on vblank, > > >>> It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > > >> On CFL it is reported every drmtip run: > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > >> ... > > >> On APL it is less frequent, probably due to other bugs preventing run of > > >> this test, last seen at: > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > >> Similar for SKL: > > >> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > >> > > >> I am not sure if I correctly read the docs but [1] says that 9th bit of > > >> PLANE_CFG (Async Address Update Enable) is "not double buffered and the > > >> changes will apply immediately" only for ICL, JSL, LKF1. > > > It got broken in bdw and fixed again in icl. > > > > > >> So the change is not necessary in case of icl_plane_disable_arm. > > >> > > >> [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > > but if async update is enabled > > PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF > > when plane is still enabled can cause DMAR/PIPE errors. > > On the other side PLANE_SURF is used to arm plane registers - we need > > to > > write to it to trigger update on VBLANK, writting current value should > > be safe - the buffer address is valid till vblank. > > >>> I think you're effectively saying that somehow the async > > >>> flip disable w/a is not kicking in sometimes. > > >> I was not aware of existence of this w/a and I am little lost in > > >> figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > > When it works as designed it should: > > > 1. turn off the async flip bit > > > 2. wait for vblank so that gets latched > > > 3. do the sync plane update/disable normally > > > > After debugging this terra incognita, I've figured out that plane states > > are not populated in intel_crtc_async_flip_disable_wa > > so for_each_old_intel_plane_in_state does not iterate over affected > > planes and w/a does not work at all. > > I have no idea where affected plane states should be added. > > Adding them to the beginning of intel_atomic_check helped, but this is > > just blind shot: > > > > @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > > *dev, > > new_crtc_state->uapi.mode_changed = true; > > > > if (new_crtc_state->uapi.scaling_filter != > > old_crtc_state->uapi.scaling_filter) > > new_crtc_state->uapi.mode_changed = true; > > + > > + ret = intel_atomic_add_affected_planes(state, crtc); > > + if (ret) > > + goto fail; > > } > > > > intel_vrr_check_modeset(state); > > > > ret = drm_atomic_helper_check_modeset(dev, &state->base); > ^ > This guy should be adding them for any crtc that has been flagged > for modeset ahead of time. For modesets flagged later we have to > add them by hand (eg. in intel_modeset_all_pipes()). > > For normal plane updates the relevant planes are already added > when the property values are updated. Hmm. Not having in the state doesn't really make sense because then we wouldn't have called the disable hook for the plane anyway. I guess one theory would be that update_mask is somehow stale. I did see one weird assert_plane() failure on one of my machines recently so that could also be pointing to the same thing. But I've not had time to investigate that one yet. I did type up a preliminary patch to see if we might catch something funny, but haven't tried feeding it to ci yet: diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c index dd876dbbaa39..f8ca3854357
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Fix intel_dp_atomic_find_vcpi_slots function (rev2)
== Series Details == Series: drm/i915: Fix intel_dp_atomic_find_vcpi_slots function (rev2) URL : https://patchwork.freedesktop.org/series/108184/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/108184/revisions/2/mbox/ not applied Applying: drm/i915: Fix intel_dp_atomic_find_vcpi_slots function Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_dp_mst.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_dp_mst.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_dp_mst.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Fix intel_dp_atomic_find_vcpi_slots function When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
> drm_dp_atomic_find_vcpi_slots no longer exists and needs
> to be used as drm_dp_atomic_find_time_slots.
> Also rename the function itself.
>
> Signed-off-by: Stanislav Lisovskiy
> Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to separate
> function")
The problem only exists in drm-tip. You need to revert the
bad merge from rerere-cache and redo it.
And please always test build drm-tip after solving merge conflicts!
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v4 04/11] drm/i915/mtl: Define engine context layouts
On 01.09.2022 23:03, Radhakrishna Sripada wrote:
> From: Matt Roper
>
> The part of the media and blitter engine contexts that we care about for
> setting up an initial state are the same on MTL as they were on DG2
> (and PVC), so we need to update the driver conditions to re-use the DG2
> context table.
>
> For render/compute engines, the part of the context images are nearly
> the same, although the layout had a very slight change --- one POSH
> register was removed and the placement of some LRI/noops adjusted
> slightly to compensate.
>
> v2:
> - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala)
> - Drop unused registers in mtl rcs offsets.(Bala)
>
> Bspec: 46261, 46260, 45585
> Cc: Balasubramani Vivekanandan
> Signed-off-by: Matt Roper
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 81 -
> 1 file changed, 79 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 070cec4ff8a4..ecb030ee39cd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -264,6 +264,38 @@ static const u8 dg2_xcs_offsets[] = {
> END
> };
>
> +static const u8 mtl_xcs_offsets[] = {
> + NOP(1),
> + LRI(13, POSTED),
> + REG16(0x244),
> + REG(0x034),
> + REG(0x030),
> + REG(0x038),
> + REG(0x03c),
> + REG(0x168),
> + REG(0x140),
> + REG(0x110),
> + REG(0x1c0),
> + REG(0x1c4),
> + REG(0x1c8),
> + REG(0x180),
> + REG16(0x2b4),
Comparing Bspec 45585, there are few NOP missing here
> +
> + NOP(1),
> + LRI(9, POSTED),
> + REG16(0x3a8),
> + REG16(0x28c),
> + REG16(0x288),
> + REG16(0x284),
> + REG16(0x280),
> + REG16(0x27c),
> + REG16(0x278),
> + REG16(0x274),
> + REG16(0x270),
> +
> + END
> +};
> +
> static const u8 gen8_rcs_offsets[] = {
> NOP(1),
> LRI(14, POSTED),
> @@ -606,6 +638,47 @@ static const u8 dg2_rcs_offsets[] = {
> END
> };
>
> +static const u8 mtl_rcs_offsets[] = {
> + NOP(1),
> + LRI(13, POSTED),
> + REG16(0x244),
> + REG(0x034),
> + REG(0x030),
> + REG(0x038),
> + REG(0x03c),
> + REG(0x168),
> + REG(0x140),
> + REG(0x110),
> + REG(0x1c0),
> + REG(0x1c4),
> + REG(0x1c8),
> + REG(0x180),
> + REG16(0x2b4),
> +
> + NOP(1),
> + LRI(9, POSTED),
> + REG16(0x3a8),
> + REG16(0x28c),
> + REG16(0x288),
> + REG16(0x284),
> + REG16(0x280),
> + REG16(0x27c),
> + REG16(0x278),
> + REG16(0x274),
> + REG16(0x270),
> +
> + NOP(2),
> + LRI(2, POSTED),
> + REG16(0x5a8),
> + REG16(0x5ac),
> +
> + NOP(6),
> + LRI(1, 0),
> + REG(0x0c8),
> +
> + END
> +};
> +
> #undef END
> #undef REG16
> #undef REG
> @@ -624,7 +697,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
> *engine)
> !intel_engine_has_relative_mmio(engine));
>
> if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE) {
> - if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
> + return mtl_rcs_offsets;
> + else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> return dg2_rcs_offsets;
> else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
> return xehp_rcs_offsets;
> @@ -637,7 +712,9 @@ static const u8 *reg_offsets(const struct intel_engine_cs
> *engine)
> else
> return gen8_rcs_offsets;
> } else {
> - if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70))
> + return mtl_xcs_offsets;
> + else if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 55))
> return dg2_xcs_offsets;
> else if (GRAPHICS_VER(engine->i915) >= 12)
> return gen12_xcs_offsets;
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
> > drm_dp_atomic_find_vcpi_slots no longer exists and needs
> > to be used as drm_dp_atomic_find_time_slots.
> > Also rename the function itself.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to
> > separate function")
>
> The problem only exists in drm-tip. You need to revert the
> bad merge from rerere-cache and redo it.
>
> And please always test build drm-tip after solving merge conflicts!
I would really like to figure out how it did end like that.
Here is the sequence of what I've been doing:
1) There was a series supposed to be merged which had this new
change already in place i.e using drm_dp_atomic_find_time_slots.
2) Then using dim tools I started pushing according to workflow:
a) dim update-branches
b) dim checkout drm-intel-next
c) wget those series mbox and run dim apply-branch drm-intel-next
Got conflict: it was complaining about those changes around
drm_dp_atomic_find_time_slots and after some checking I figured
out that drm_dp_atomic_find_time_slots doesn't exist anymore.
Here probably was my bad, as I wrongly assumed that those changes
were probably reverted as it was also mentioned, that there was
regression because of those.
So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
back instead of drm_dp_atomic_find_time_slots _and_ actually
built it even.
d) I run dim push-branch drm-intel-next, it did complain about merge
conflict again with drm-intel-next which I fixed and results were
pushed.
I should have build at this moment as well probably.
Then I noticed that this function drm_dp_atomic_find_vcpi_slots
doesn't exist in drm. So basically patches should have been pushed
as they were initially, but why the conflict appeared initially - that is
my
question.
Stan
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH v2 23/41] drm/atomic-helper: Add an analog TV atomic_check implementation
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The analog TV connector drivers share some atomic_check logic, and the new
>
> TV standard property have created a bunch of new constraints that needs to
>
> be shared across drivers too.
>
>
>
> Let's create an atomic_check helper for those use cases.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
>
> index 0373c3dc824b..d64733c6aae3 100644
>
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
>
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
>
> @@ -556,6 +556,42 @@ void drm_atomic_helper_connector_tv_reset(struct
> drm_connector *connector)
>
> }
>
> EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
>
>
>
> +/**
>
> + * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector
> state
>
> + * @connector: DRM Connector
>
> + * @state: the DRM State object
>
> + *
>
> + * Checks the state object to see if the requested state is valid for an
>
> + * analog TV connector.
>
> + *
>
> + * Returns:
>
> + * Zero for success, a negative error code on error.
>
> + */
>
> +int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
>
> + struct drm_atomic_state *state)
>
> +{
>
> + struct drm_connector_state *old_conn_state =
>
> + drm_atomic_get_old_connector_state(state, connector);
>
> + struct drm_connector_state *new_conn_state =
>
> + drm_atomic_get_new_connector_state(state, connector);
>
> + struct drm_crtc_state *crtc_state;
>
> + struct drm_crtc *crtc;
>
> +
>
> + crtc = new_conn_state->crtc;
>
> + if (!crtc)
>
> + return 0;
>
> +
>
> + crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
>
> + if (!crtc_state)
>
> + return -EINVAL;
>
> +
>
> + if (old_conn_state->tv.mode != new_conn_state->tv.mode)
>
> + crtc_state->mode_changed = true;
>
If you can expand this check then I can use it in gud:
if (old_conn_state->tv.margins.left != new_conn_state->tv.margins.left
||
old_conn_state->tv.margins.right !=
new_conn_state->tv.margins.right ||
old_conn_state->tv.margins.top != new_conn_state->tv.margins.top ||
old_conn_state->tv.margins.bottom !=
new_conn_state->tv.margins.bottom ||
old_conn_state->tv.mode != new_conn_state->tv.mode ||
old_conn_state->tv.brightness != new_conn_state->tv.brightness ||
old_conn_state->tv.contrast != new_conn_state->tv.contrast ||
old_conn_state->tv.flicker_reduction !=
new_conn_state->tv.flicker_reduction ||
old_conn_state->tv.overscan != new_conn_state->tv.overscan ||
old_conn_state->tv.saturation != new_conn_state->tv.saturation ||
old_conn_state->tv.hue != new_conn_state->tv.hue)
crtc_state->connectors_changed = true;
With that considered:
Reviewed-by: Noralf Trønnes
> +
>
> + return 0;
>
> +}
>
> +EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
>
> +
>
> /**
>
> * __drm_atomic_helper_connector_duplicate_state - copy atomic connector
> state
>
> * @connector: connector object
>
> diff --git a/include/drm/drm_atomic_state_helper.h
> b/include/drm/drm_atomic_state_helper.h
>
> index c8fbce795ee7..b9740edb2658 100644
>
> --- a/include/drm/drm_atomic_state_helper.h
>
> +++ b/include/drm/drm_atomic_state_helper.h
>
> @@ -26,6 +26,7 @@
>
>
>
> #include
>
>
>
> +struct drm_atomic_state;
>
> struct drm_bridge;
>
> struct drm_bridge_state;
>
> struct drm_crtc;
>
> @@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct
> drm_connector *connector,
>
>struct drm_connector_state
> *conn_state);
>
> void drm_atomic_helper_connector_reset(struct drm_connector *connector);
>
> void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
>
> +int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
>
> + struct drm_atomic_state *state);
>
> void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector
> *connector);
>
> void
>
> __drm_atomic_helper_connector_duplicate_state(struct drm_connector
> *connector,
>
>
>
[Intel-gfx] [PATCH v4 01/21] dma-buf: Add unlocked variant of vmapping functions
Add unlocked variant of dma_buf_vmap/vunmap() that will be utilized
by drivers that don't take the reservation lock explicitly.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 38 ++
include/linux/dma-buf.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 1c912255c5d6..5e4459bb1a6f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1424,6 +1424,28 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct
iosys_map *map)
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
+/**
+ * dma_buf_vmap_unlocked - Create virtual mapping for the buffer object into
kernel
+ * address space. Same restrictions as for vmap and friends apply.
+ * @dmabuf:[in]buffer to vmap
+ * @map: [out] returns the vmap pointer
+ *
+ * Unlocked version of dma_buf_vmap()
+ *
+ * Returns 0 on success, or a negative errno code otherwise.
+ */
+int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
+{
+ int ret;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+ ret = dma_buf_vmap(dmabuf, map);
+ dma_resv_unlock(dmabuf->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_vmap_unlocked, DMA_BUF);
+
/**
* dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
* @dmabuf:[in]buffer to vunmap
@@ -1448,6 +1470,22 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
iosys_map *map)
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
+/**
+ * dma_buf_vunmap_unlocked - Unmap a vmap obtained by dma_buf_vmap.
+ * @dmabuf:[in]buffer to vunmap
+ * @map: [in]vmap pointer to vunmap
+ */
+void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map)
+{
+ if (WARN_ON(!dmabuf))
+ return;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+ dma_buf_vunmap(dmabuf, map);
+ dma_resv_unlock(dmabuf->resv);
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 71731796c8c3..8daa054dd7fe 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -632,4 +632,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map);
void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map);
+int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
+void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, struct iosys_map *map);
#endif /* __DMA_BUF_H__ */
--
2.37.2
Re: [Intel-gfx] [PATCH v2 06/41] drm/connector: Rename legacy TV property
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The current tv_mode has driver-specific values that don't allow to
>
> easily share code using it, either at the userspace or kernel level.
>
>
>
> Since we're going to introduce a new, generic, property that fit the
>
> same purpose, let's rename this one to legacy_tv_mode to make it
>
> obvious we should move away from it.
>
>
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>
> index 1d5e3cccb9e3..5cfad8b6ad83 100644
>
> --- a/include/drm/drm_connector.h
>
> +++ b/include/drm/drm_connector.h
>
> @@ -695,7 +695,7 @@ struct drm_connector_tv_margins {
>
> * @select_subconnector: selected subconnector
>
> * @subconnector: detected subconnector
>
> * @margins: TV margins
>
> - * @mode: TV mode
>
> + * @legacy_mode: Legacy TV mode, driver specific value
>
> * @brightness: brightness in percent
>
> * @contrast: contrast in percent
>
> * @flicker_reduction: flicker reduction in percent
>
> @@ -707,7 +707,7 @@ struct drm_tv_connector_state {
>
> enum drm_mode_subconnector select_subconnector;
>
> enum drm_mode_subconnector subconnector;
>
> struct drm_connector_tv_margins margins;
>
> - unsigned int mode;
>
> + unsigned int legacy_mode;
I suggest you do a build of the affected drivers after adding this patch
to make sure you have changed all mode -> legacy_mode occurrences
_before_ adding back mode in a later patch.
A simple grep gave me these:
drivers/gpu/drm/vc4/vc4_vec.c:
vc4_vec_tv_modes[state->tv.mode].mode);
drivers/gpu/drm/vc4/vc4_vec.c: vec->tv_mode =
&vc4_vec_tv_modes[conn_state->tv.mode];
drivers/gpu/drm/vc4/vc4_vec.c: vec_mode =
&vc4_vec_tv_modes[conn_state->tv.mode];
drivers/gpu/drm/i915/display/intel_tv.c:int format =
conn_state->tv.mode;
drivers/gpu/drm/i915/display/intel_tv.c:
connector->state->tv.mode = i;
drivers/gpu/drm/i915/display/intel_tv.c:if (old_state->tv.mode
!= new_state->tv.mode ||
drivers/gpu/drm/i915/display/intel_tv.c:state->tv.mode =
initial_mode;
drivers/gpu/drm/i915/display/intel_tv.c:
state->tv.mode);
drivers/gpu/drm/i915/display/intel_sdvo.c: format_map = 1 <<
conn_state->tv.mode;
drivers/gpu/drm/i915/display/intel_sdvo.c: format_map = 1 <<
conn_state->tv.mode;
drivers/gpu/drm/i915/display/intel_sdvo.c: if
(state->tv.mode == intel_sdvo_connector->tv_format_supported[i]) {
drivers/gpu/drm/i915/display/intel_sdvo.c: state->tv.mode =
intel_sdvo_connector->tv_format_supported[val];
drivers/gpu/drm/i915/display/intel_sdvo.c:
intel_sdvo_connector->base.base.state->tv.mode =
intel_sdvo_connector->tv_format_supported[0];
Not so easy to grep for is this in gud:
static unsigned int *gud_connector_tv_state_val(u16 prop, struct
drm_tv_connector_state *state)
{
switch (prop) {
...
case GUD_PROPERTY_TV_MODE:
return &state->mode;
Noralf.
>
> unsigned int brightness;
>
> unsigned int contrast;
>
> unsigned int flicker_reduction;
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>
> index 6b5e01295348..35a827175c24 100644
>
> --- a/include/drm/drm_mode_config.h
>
> +++ b/include/drm/drm_mode_config.h
>
> @@ -714,11 +714,13 @@ struct drm_mode_config {
>
>* between different TV connector types.
>
>*/
>
> struct drm_property *tv_select_subconnector_property;
>
> +
>
> /**
>
> - * @tv_mode_property: Optional TV property to select
>
> + * @legacy_tv_mode_property: Optional TV property to select
>
>* the output TV mode.
>
>*/
>
> - struct drm_property *tv_mode_property;
>
> + struct drm_property *legacy_tv_mode_property;
>
> +
>
> /**
>
>* @tv_left_margin_property: Optional TV property to set the left
>
>* margin (expressed in pixels).
>
>
>
Re: [Intel-gfx] [PATCH v2 22/41] drm/atomic-helper: Add a TV properties reset helper
Den 29.08.2022 15.11, skrev Maxime Ripard: > The drm_tv_create_properties() function will create a bunch of properties, > > but it's up to each and every driver using that function to properly reset > > the state of these properties leading to inconsistent behaviours. > > > > Let's create a helper that will take care of it. > > > > Signed-off-by: Maxime Ripard > Reviewed-by: Noralf Trønnes
Re: [Intel-gfx] [PATCH 01/15] vfio: Add helpers for unifying vfio_device life cycle
Reviewed-by: Tony Krowiak
I have a couple of review comments, but nothing critical that would
prevent my r-b.
On 8/27/22 1:10 PM, Kevin Tian wrote:
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfio_alloc_device()
- vfio_put_device()
Drivers can register @init/@release callbacks to manage any private
state wrapping the vfio_device.
However vfio-ccw doesn't fit this model due to a life cycle mess
that its private structure mixes both parent and mdev info hence must
be allocated/free'ed outside of the life cycle of vfio device.
Per prior discussions this won't be fixed in short term by IBM folks.
Instead of waiting introduce another helper vfio_init_device() so ccw
can call it to initialize a pre-allocated vfio_device.
Further implication of the ccw trick is that vfio_device cannot be
free'ed uniformly in vfio core. Instead, require *EVERY* driver to
implement @release and free vfio_device inside. Then ccw can choose
to delay the free at its own discretion.
Another trick down the road is that kvzalloc() is used to accommodate
the need of gvt which uses vzalloc() while all others use kzalloc().
So drivers should call a helper vfio_free_device() to free the
vfio_device instead of assuming that kfree() or vfree() is appliable.
Later once the ccw mess is fixed we can remove those tricks and
fully handle structure alloc/free in vfio core.
Existing vfio_{un}init_group_dev() will be deprecated after all
existing usages are converted to the new model.
Suggested-by: Jason Gunthorpe
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/vfio/vfio_main.c | 92
include/linux/vfio.h | 25 ++-
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 7cb56c382c97..af8aad116f2b 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -496,6 +496,98 @@ void vfio_uninit_group_dev(struct vfio_device *device)
}
EXPORT_SYMBOL_GPL(vfio_uninit_group_dev);
+/*
+ * Alloc and initialize vfio_device so it can be registered to vfio
+ * core.
+ *
+ * Drivers should use the wrapper vfio_alloc_device() for allocation.
+ * @size is the size of the structure to be allocated, including any
+ * private data used by the driver.
It seems the purpose of the wrapper is to ensure that the object being
allocated has as its first field a struct vfio_device object and to
return its container. Why not just make that a requirement for this
function - which I would rename vfio_alloc_device - and document it in
the prologue? The caller can then cast the return pointer or use
container_of.
+ *
+ * Driver may provide an @init callback to cover device private data.
+ *
+ * Use vfio_put_device() to release the structure after success return.
+ */
+struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
+ const struct vfio_device_ops *ops)
+{
+ struct vfio_device *device;
+ int ret;
+
+ if (WARN_ON(size < sizeof(struct vfio_device)))
+ return ERR_PTR(-EINVAL);
+
+ device = kvzalloc(size, GFP_KERNEL);
+ if (!device)
+ return ERR_PTR(-ENOMEM);
+
+ ret = vfio_init_device(device, dev, ops);
+ if (ret)
+ goto out_free;
+ return device;
+
+out_free:
+ kvfree(device);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(_vfio_alloc_device);
+
+/*
+ * Initialize a vfio_device so it can be registered to vfio core.
+ *
+ * Only vfio-ccw driver should call this interface.
+ */
+int vfio_init_device(struct vfio_device *device, struct device *dev,
+const struct vfio_device_ops *ops)
+{
+ int ret;
+
+ vfio_init_group_dev(device, dev, ops);
+
+ if (ops->init) {
+ ret = ops->init(device);
+ if (ret)
+ goto out_uninit;
+ }
+
+ kref_init(&device->kref);
+ return 0;
+
+out_uninit:
+ vfio_uninit_group_dev(device);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_init_device);
+
+/*
+ * The helper called by driver @release callback to free the device
+ * structure. Drivers which don't have private data to clean can
+ * simply use this helper as its @release.
+ */
+void vfio_free_device(struct vfio_device *device)
+{
+ kvfree(device);
+}
+EXPORT_SYMBOL_GPL(vfio_free_device);
+
+/* Release helper called by vfio_put_device() */
+void vfio_device_release(struct kref *kref)
+{
+ struct vfio_device *device =
+ container_of(kref, struct vfio_device, kref);
+
+ vfio_uninit_group_dev(device);
+
+ /*
+* kvfree() cannot be done here due to a life cycle mess in
+* vfio-ccw. Before the ccw part is f
[Intel-gfx] [PATCH v4 05/21] drm/armada: Prepare to dynamic dma-buf locking specification
Prepare Armada driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/armada/armada_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 5430265ad458..26d10065d534 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -66,8 +66,8 @@ void armada_gem_free_object(struct drm_gem_object *obj)
if (dobj->obj.import_attach) {
/* We only ever display imported data */
if (dobj->sgt)
- dma_buf_unmap_attachment(dobj->obj.import_attach,
-dobj->sgt, DMA_TO_DEVICE);
+
dma_buf_unmap_attachment_unlocked(dobj->obj.import_attach,
+ dobj->sgt,
DMA_TO_DEVICE);
drm_prime_gem_destroy(&dobj->obj, NULL);
}
@@ -539,8 +539,8 @@ int armada_gem_map_import(struct armada_gem_object *dobj)
{
int ret;
- dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,
- DMA_TO_DEVICE);
+ dobj->sgt = dma_buf_map_attachment_unlocked(dobj->obj.import_attach,
+ DMA_TO_DEVICE);
if (IS_ERR(dobj->sgt)) {
ret = PTR_ERR(dobj->sgt);
dobj->sgt = NULL;
--
2.37.2
[Intel-gfx] [PATCH v4 13/21] media: videobuf2: Prepare to dynamic dma-buf locking specification
Prepare V4L2 memory allocators to the common dynamic dma-buf locking
convention by starting to use the unlocked versions of dma-buf API
functions.
Acked-by: Tomasz Figa
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 ++-
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 6 +++---
3 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 678b359717c4..79f4d8301fbb 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -101,7 +101,7 @@ static void *vb2_dc_vaddr(struct vb2_buffer *vb, void
*buf_priv)
if (buf->db_attach) {
struct iosys_map map;
- if (!dma_buf_vmap(buf->db_attach->dmabuf, &map))
+ if (!dma_buf_vmap_unlocked(buf->db_attach->dmabuf, &map))
buf->vaddr = map.vaddr;
return buf->vaddr;
@@ -711,7 +711,7 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
}
/* get the associated scatterlist for this buffer */
- sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -722,7 +722,8 @@ static int vb2_dc_map_dmabuf(void *mem_priv)
if (contig_size < buf->size) {
pr_err("contiguous chunk is too small %lu/%lu\n",
contig_size, buf->size);
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt,
+ buf->dma_dir);
return -EFAULT;
}
@@ -750,10 +751,10 @@ static void vb2_dc_unmap_dmabuf(void *mem_priv)
}
if (buf->vaddr) {
- dma_buf_vunmap(buf->db_attach->dmabuf, &map);
+ dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, &map);
buf->vaddr = NULL;
}
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
buf->dma_addr = 0;
buf->dma_sgt = NULL;
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index fa69158a65b1..36ecdea8d707 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -309,7 +309,7 @@ static void *vb2_dma_sg_vaddr(struct vb2_buffer *vb, void
*buf_priv)
if (!buf->vaddr) {
if (buf->db_attach) {
- ret = dma_buf_vmap(buf->db_attach->dmabuf, &map);
+ ret = dma_buf_vmap_unlocked(buf->db_attach->dmabuf,
&map);
buf->vaddr = ret ? NULL : map.vaddr;
} else {
buf->vaddr = vm_map_ram(buf->pages, buf->num_pages, -1);
@@ -565,7 +565,7 @@ static int vb2_dma_sg_map_dmabuf(void *mem_priv)
}
/* get the associated scatterlist for this buffer */
- sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(buf->db_attach, buf->dma_dir);
if (IS_ERR(sgt)) {
pr_err("Error getting dmabuf scatterlist\n");
return -EINVAL;
@@ -594,10 +594,10 @@ static void vb2_dma_sg_unmap_dmabuf(void *mem_priv)
}
if (buf->vaddr) {
- dma_buf_vunmap(buf->db_attach->dmabuf, &map);
+ dma_buf_vunmap_unlocked(buf->db_attach->dmabuf, &map);
buf->vaddr = NULL;
}
- dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir);
+ dma_buf_unmap_attachment_unlocked(buf->db_attach, sgt, buf->dma_dir);
buf->dma_sgt = NULL;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 948152f1596b..7831bf545874 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -376,7 +376,7 @@ static int vb2_vmalloc_map_dmabuf(void *mem_priv)
struct iosys_map map;
int ret;
- ret = dma_buf_vmap(buf->dbuf, &map);
+ ret = dma_buf_vmap_unlocked(buf->dbuf, &map);
if (ret)
return -EFAULT;
buf->vaddr = map.vaddr;
@@ -389,7 +389,7 @@ static void vb2_vmalloc_unmap_dmabuf(void *mem_priv)
struct vb2_vmalloc_buf *buf = mem_priv;
struct iosys_map map = IOSYS_MAP_INIT_VADDR(buf->vaddr);
- dma_buf_vunmap(buf->dbuf, &map);
+ dma_buf_vunmap_unlocked(buf->dbuf, &map);
buf->vaddr
[Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
Prepare i915 driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions
and handling cases where importer now holds the reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12
.../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..07eee1c09aaf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf,
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
void *vaddr;
- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 389e9f157ca5..7e2a9b02526c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
continue;
}
+ /*
+* dma_buf_unmap_attachment() requires reservation to be
+* locked. The imported GEM shouldn't share reservation lock,
+* so it's safe to take the lock.
+*/
+ if (obj->base.import_attach)
+ i915_gem_object_lock(obj, NULL);
+
__i915_gem_object_pages_fini(obj);
+
+ if (obj->base.import_attach)
+ i915_gem_object_unlock(obj);
+
__i915_gem_free_object(obj);
/* But keep the pointer alive for RCU-protected lookups */
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 62c61af77a42..9e3ed634aa0e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
goto out_import;
}
- st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);
+ st = dma_buf_map_attachment_unlocked(import_attach, DMA_BIDIRECTIONAL);
if (IS_ERR(st)) {
err = PTR_ERR(st);
goto out_detach;
@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
timeout = -ETIME;
}
err = timeout > 0 ? 0 : timeout;
- dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(import_attach, st, DMA_BIDIRECTIONAL);
out_detach:
dma_buf_detach(dmabuf, import_attach);
out_import:
@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
goto out_obj;
}
- err = dma_buf_vmap(dmabuf, &map);
+ err = dma_buf_vmap_unlocked(dmabuf, &map);
dma_map = err ? NULL : map.vaddr;
if (!dma_map) {
pr_err("dma_buf_vmap failed\n");
@@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
err = 0;
out_dma_map:
- dma_buf_vunmap(dmabuf, &map);
+ dma_buf_vunmap_unlocked(dmabuf, &map);
out_obj:
i915_gem_object_put(obj);
out_dmabuf:
@@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
- err = dma_buf_vmap(dmabuf, &map);
+ err = dma_buf_vmap_unlocked(dmabuf, &map);
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
}
memset(ptr, 0xc5, PAGE_SIZE);
- dma_buf_vunmap(dmabuf, &map);
+ dma_buf_vunmap_unlocked(dmabuf, &map);
obj = to_intel_bo(i915_gem_prime_import(&i915->drm, dmabuf));
if (IS_ERR(obj)) {
@@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
}
i915_gem_object_put(obj);
- err = dma_buf_vmap(dmabuf, &map);
+ err = dma_buf_vmap_unlocked(dmabuf, &map);
ptr = err ? NULL : map.vaddr;
if (!ptr) {
pr_err("dma_buf_vmap failed\n");
@@ -435,7 +435,7 @@ static int igt_dmabuf_export_vmap(void *arg)
memset(ptr, 0xc5, dmabuf->size);
err = 0;
- dma_buf_vunmap(dmabuf, &map);
+ dma_buf_vunmap_unlocked(dmabuf, &map);
out:
dma_buf_put(dmabuf);
return err;
--
2.37.2
Re: [Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements
Den 01.09.2022 21.35, skrev Noralf Trønnes: > > > I have finally found a workaround for my kernel hangs. > > Dom had a look at my kernel and found that the VideoCore was fine, and > he said this: > >> That suggests cause of lockup was on arm side rather than VC side. >> >> But it's hard to diagnose further. Once you've had a peripheral not >> respond, the AXI bus locks up and no further operations are possible. >> Usual causes of this are required clocks being stopped or domains >> disabled and then trying to access the hardware. >> > > So when I got this on my 64-bit build: > > [ 166.702171] SError Interrupt on CPU1, code 0xbf02 -- SError > [ 166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: GW > 5.19.0-rc6-00096-gba7973977976-dirty #1 > [ 166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) > [ 166.702206] Workqueue: events_freezable_power_ thermal_zone_device_check > [ 166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [ 166.702242] pc : regmap_mmio_read32le+0x10/0x28 > [ 166.702261] lr : regmap_mmio_read+0x44/0x70 > ... > [ 166.702606] bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal] > > I wondered if that reg read was stalled due to a clock being stopped. > > Lo and behold, disabling runtime pm and keeping the vec clock running > all the time fixed it[1]. > > I don't know what the problem is, but at least I can now test this patchset. > > [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065 > It turns out I didn't have to disable runtime pm: https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2 Noralf.
Re: [Intel-gfx] [PATCH v2 31/41] drm/vc4: vec: Use TV Reset implementation
Den 29.08.2022 15.11, skrev Maxime Ripard: > The analog TV properties created by the drm_mode_create_tv_properties() are > > not properly initialised at reset. Let's switch our implementation to call > > drm_atomic_helper_connector_tv_reset(). > > > > Signed-off-by: Maxime Ripard > Reviewed-by: Noralf Trønnes
[Intel-gfx] [PATCH v4 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification
Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by asserting that the reservation lock is held. Acked-by: Christian König Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 51fb69048853..ceea4839c641 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1449,6 +1449,8 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) if (WARN_ON(!dmabuf)) return -EINVAL; + dma_resv_assert_held(dmabuf->resv); + if (!dmabuf->ops->vmap) return -EINVAL; @@ -1509,6 +1511,8 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) if (WARN_ON(!dmabuf)) return; + dma_resv_assert_held(dmabuf->resv); + BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr)); BUG_ON(dmabuf->vmapping_counter == 0); BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map)); -- 2.37.2
[Intel-gfx] [PATCH v4 20/21] media: videobuf2: Stop using internal dma-buf lock
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
3 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 79f4d8301fbb..555bd40fa472 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = &db_attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = &attach->sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 36ecdea8d707..36981a5b5c53 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dma_sg_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = &db_attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = &attach->sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 7831bf545874..41db707e43a4 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_vmalloc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = &db_attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = &attach->sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
--
2.37.2
Re: [Intel-gfx] [PATCH v2 28/41] drm/vc4: vec: Fix timings for VEC modes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> From: Mateusz Kwiatkowski
>
>
>
> This commit fixes vertical timings of the VEC (composite output) modes
>
> to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R
>
> standards.
>
>
>
> Previous timings were actually defined as 502 and 601 lines, resulting
>
> in non-standard 62.69 Hz and 52 Hz signals being generated,
>
> respectively.
>
>
>
> Signed-off-by: Mateusz Kwiatkowski
>
> Signed-off-by: Maxime Ripard
>
>
Acked-by: Noralf Trønnes
Re: [Intel-gfx] [PATCH v2 25/41] drm/vc4: vec: Convert to atomic helpers
Den 29.08.2022 15.11, skrev Maxime Ripard: > The VC4 VEC driver still uses legacy enable and disable hook > > implementation. Let's convert to the atomic variants. > > > > Signed-off-by: Maxime Ripard > Reviewed-by: Noralf Trønnes
[Intel-gfx] [PATCH v4 21/21] dma-buf: Remove obsoleted internal lock
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 14 --
include/linux/dma-buf.h | 9 -
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 97ce884fad76..772fdd9eeed8 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(&dmabuf->lock);
INIT_LIST_HEAD(&dmabuf->attachments);
mutex_lock(&db_list.lock);
@@ -1502,7 +1501,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
int dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map)
{
struct iosys_map ptr;
- int ret = 0;
+ int ret;
iosys_map_clear(map);
@@ -1514,28 +1513,25 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct
iosys_map *map)
if (!dmabuf->ops->vmap)
return -EINVAL;
- mutex_lock(&dmabuf->lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr));
*map = dmabuf->vmap_ptr;
- goto out_unlock;
+ return 0;
}
BUG_ON(iosys_map_is_set(&dmabuf->vmap_ptr));
ret = dmabuf->ops->vmap(dmabuf, &ptr);
if (WARN_ON_ONCE(ret))
- goto out_unlock;
+ return ret;
dmabuf->vmap_ptr = ptr;
dmabuf->vmapping_counter = 1;
*map = dmabuf->vmap_ptr;
-out_unlock:
- mutex_unlock(&dmabuf->lock);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vmap, DMA_BUF);
@@ -1577,13 +1573,11 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
iosys_map *map)
BUG_ON(dmabuf->vmapping_counter == 0);
BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map));
- mutex_lock(&dmabuf->lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(&dmabuf->vmap_ptr);
}
- mutex_unlock(&dmabuf->lock);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index f11b5bbc2f37..6fa8d4e29719 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
--
2.37.2
Re: [Intel-gfx] [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandagatla
--srini
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
Re: [Intel-gfx] [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention
Hello Christian, On 9/1/22 10:49, Christian König wrote: > Hi Dmitry, > > I've gone over this multiple times now and while it is still possible > that we missed something I think that this should land now. Thank you very much for the review! > The whole topic is just to complicated that we can 100% sure guarantee > that there isn't anything wrong with the locking, but lockdep and driver > testing should allow us to quickly find remaining issues. At least the most popular drivers should be okay. If anyone will find issue introduced by this series, then indeed shouldn't be a problem to fix it later on. > Do you have commit rights to drm-misc-next or should I push it? I got the drm-misc commit right two weeks ago, haven't pushed anything there yet. Please let me try to do the push. I'll let you know if any kind of help will be needed from you. I'll wait for more acks/r-bs and then do the push. -- Best regards, Dmitry
Re: [Intel-gfx] [PATCH 01/15] vfio: Add helpers for unifying vfio_device life cycle
On 8/30/22 11:10 AM, Jason Gunthorpe wrote: On Tue, Aug 30, 2022 at 09:42:42AM -0400, Anthony Krowiak wrote: +/* + * Alloc and initialize vfio_device so it can be registered to vfio + * core. + * + * Drivers should use the wrapper vfio_alloc_device() for allocation. + * @size is the size of the structure to be allocated, including any + * private data used by the driver. It seems the purpose of the wrapper is to ensure that the object being allocated has as its first field a struct vfio_device object and to return its container. Why not just make that a requirement for this function - which I would rename vfio_alloc_device - and document it in the prologue? The caller can then cast the return pointer or use container_of. There are three fairly common patterns for this kind of thing 1) The caller open codes everything: driver_struct = kzalloc() core_init(&driver_struct->core) 2) Some 'get priv' / 'get data' is used instead of container_of(): core_struct = core_alloc(sizeof(*driver_struct)) driver_struct = core_get_priv(core_struct) 3) The allocations and initialization are consolidated in the core, but we continue to use container_of() driver_struct = core_alloc(typeof(*driver_struct)) #1 has a general drawback that people routinely mess up the lifecycle model and get really confused about when to do kfree() vs put(), creating bugs. #2 has a general drawback of not using container_of() at all, and being a bit confusing in some cases #3 has the general drawback of being a bit magical, but solves 1 and 2's problems. I would not fix the struct layout without the BUILD_BUG_ON because someone will accidently change the order and that becomes a subtle runtime error - so at a minimum the wrapper macro has to exist to check that. If you want to allow a dynamic struct layout and avoid the pitfall of exposing the user to kalloc/kfree, then you still need the macro, and it does some more complicated offset stuff. Having the wrapper macro be entirely type safe is appealing and reduces code in the drivers, IMHO. Tell it what type you are initing and get back init'd memory for that type that you always, always free with a put operation. Sounds reasonable, okay I'm buying. Jason
[Intel-gfx] [PATCH v4 18/21] dma-buf: Move dma_buf_mmap() to dynamic locking specification
Move dma_buf_mmap() function to the dynamic locking specification by
taking the reservation lock. Neither of the today's drivers take the
reservation lock within the mmap() callback, hence it's safe to enforce
the locking.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 8e928fe6e8df..d9130486cb8f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1389,6 +1389,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1409,7 +1411,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_lock(dmabuf->resv, NULL);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+ dma_resv_unlock(dmabuf->resv);
+
+ return ret;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
--
2.37.2
Re: [Intel-gfx] [PATCH v2 29/41] drm/vc4: vec: Switch for common modes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Now that the core has a definition for the 525 and 625 lines analog TV
>
> modes, let's switch to it for vc4.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>
> index d1d40b69279e..63e4e617e321 100644
>
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
>
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
>
> @@ -224,38 +224,24 @@ static const struct debugfs_reg32 vec_regs[] = {
>
> VC4_REG32(VEC_DAC_MISC),
>
> };
>
>
>
> -static const struct drm_display_mode ntsc_mode = {
>
> - DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
>
> - 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
>
> - 480, 480 + 7, 480 + 7 + 6, 525, 0,
>
> - DRM_MODE_FLAG_INTERLACE)
>
> -};
>
> -
>
> -static const struct drm_display_mode pal_mode = {
>
> - DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
>
> - 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
>
> - 576, 576 + 4, 576 + 4 + 6, 625, 0,
>
> - DRM_MODE_FLAG_INTERLACE)
>
> -};
>
> -
>
> static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>
> [VC4_VEC_TV_MODE_NTSC] = {
>
> - .mode = &ntsc_mode,
>
> + .mode = &drm_mode_480i,
>
I can't find drm_mode_480i anywhere, maybe the compiler doesn't complain
since you remove the reference in a later patch?
Noralf.
> .config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_NTSC_J] = {
>
> - .mode = &ntsc_mode,
>
> + .mode = &drm_mode_480i,
>
> .config0 = VEC_CONFIG0_NTSC_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_PAL] = {
>
> - .mode = &pal_mode,
>
> + .mode = &drm_mode_576i,
>
> .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_PAL_M] = {
>
> - .mode = &pal_mode,
>
> + .mode = &drm_mode_576i,
>
> .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
>
> .custom_freq = 0x223b61d1,
>
>
>
[Intel-gfx] [PATCH v4 16/21] dma-buf: Move dma_buf_attach() to dynamic locking specification
Move dma-buf attachment API functions to the dynamic locking specification
by taking the reservation lock around the mapping operations. The strict
locking convention prevents deadlock situations for dma-buf importers and
exporters.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ceea4839c641..073942bf5ae9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -858,8 +858,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -872,8 +872,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
@@ -889,8 +888,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dmabuf->ops->unpin(attach);
err_unlock:
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_unlock(attach->dmabuf->resv);
+ dma_resv_unlock(attach->dmabuf->resv);
dma_buf_detach(dmabuf, attach);
return ERR_PTR(ret);
@@ -936,21 +934,19 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
if (WARN_ON(!dmabuf || !attach))
return;
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+
if (attach->sgt) {
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_lock(attach->dmabuf->resv, NULL);
__unmap_dma_buf(attach, attach->sgt, attach->dir);
- if (dma_buf_is_dynamic(attach->dmabuf)) {
+ if (dma_buf_is_dynamic(attach->dmabuf))
dmabuf->ops->unpin(attach);
- dma_resv_unlock(attach->dmabuf->resv);
- }
}
-
- dma_resv_lock(dmabuf->resv, NULL);
list_del(&attach->node);
+
dma_resv_unlock(dmabuf->resv);
+
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
--
2.37.2
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
Hi Greg,
Alex has explained how we figured out the patch. We did analyze the
code and found it possible to reach the vulnerability code. But we
have no physical device in hand to test the driver. So we'd like to
discuss with developers to see if the issue exists or not.
Best regards,
Zheng Wang.
Greg KH 于2022年9月5日周一 16:04写道：
>
> On Mon, Sep 05, 2022 at 03:46:09PM +0800, Zheng Hacker wrote:
> > I rewrote the letter. Hope it works.
> >
> > There is a double-free security bug in split_2MB_gtt_entry.
> >
> > Here is a calling chain :
> > ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
> > kfree(spt). But the caller does not notice that, and it will call
> > ppgtt_free_spt again in error path.
> >
> > Fix this by returning the result of ppgtt_invalidate_spt to
> > split_2MB_gtt_entry.
> >
> > Signed-off-by: Zheng Wang
> >
> > ---
> > drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> > index ce0eb03709c3..9f14fded8c0c 100644
> > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu
> > *vgpu,
> > ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
> > sub_index,
> >PAGE_SIZE, &dma_addr);
> > if (ret) {
> > - ppgtt_invalidate_spt(spt);
> > + ret = ppgtt_invalidate_spt(spt);
> > return ret;
>
> But now you just lost the original error, shouldn't this succeed even if
> intel_gvt_dma_map_guest_page() failed?
>
> And how are you causing intel_gvt_dma_map_guest_page() to fail in a real
> system?
>
> thanks,
>
> greg k-h
[Intel-gfx] [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention
Hello, This series moves all drivers to a dynamic dma-buf locking specification. >From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v4: - Added dma_buf_mmap() to the "locking convention" documentation, which was missed by accident in v3. - Added acks from Christian König, Tomasz Figa and Hans Verkuil that they gave to couple v3 patches. - Dropped the "_unlocked" postfix from function names that don't have the locked variant, as was requested by Christian König. - Factored out the per-driver preparations into separate patches to ease reviewing of the changes, which is now doable without the global dma-buf functions renaming. - Factored out the dynamic locking convention enforcements into separate patches which add the final dma_resv_assert_held(dmabuf->resv) to the dma-buf API functions. v3: - Factored out dma_buf_mmap_unlocked() and attachment functions into aseparate patches, like was suggested by Christian König. - Corrected and factored out dma-buf locking documentation into a separate patch, like was suggested by Christian König. - Intel driver dropped the reservation locking fews days ago from its BO-release code path, but we need that locking for the imported GEMs because in the end that code path unmaps the imported GEM. So I added back the locking needed by the imported GEMs, updating the "dma-buf attachment locking specification" patch appropriately. - Tested Nouveau+Intel dma-buf import/export combo. - Tested udmabuf import to i915/Nouveau/AMDGPU. - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed to switch to locked dma-buf vmapping in the drm/gem: Take reservation lock for vmap/vunmap operations" patch. In a result invalidated the Christian's r-b that he gave to v2. - Added locked dma-buf vmap/vunmap functions that are needed for fixing vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. I actually had this change stashed for the drm-shmem shrinker patchset, but then realized that it's already needed by the dma-buf patches. Also improved my tests to better cover these code paths. v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (21): dma-buf: Add unlocked variant of vmapping functions dma-buf: Add unlocked variant of attachment-mapping functions drm/gem: Take reservation lock for vmap/vunmap operations drm/prime: Prepare to dynamic dma-buf locking specification drm/armada: Prepare to dynamic dma-buf locking specification drm/i915: Prepare to dynamic dma-buf locking specification drm/omapdrm: Prepare to dynamic dma-buf locking specification drm/tegra: Prepare to dynamic dma-buf locking specification drm/etnaviv: Prepare to dynamic dma-buf locking specification RDMA/umem: Prepare to dynamic dma-buf locking specification misc: fastrpc: Prepare to dynamic dma-buf locking specification xen/gntdev: Prepare to dynamic dma-buf locking specification media: videobuf2: Prepare to dynamic dma-buf locking specification media: tegra-vde: Prepare to dynamic dma-buf locking specification dma-buf: Move dma_buf_vmap() to dynamic locking specification dma-buf: Move dma_buf_attach() to dynamic locking specification dma-buf: Move dma_buf_map_attachment() to dynamic locking specification dma-buf: Move dma_buf_mmap() to dynamic locking specification dma-buf: Document dynamic locking convention media: videobuf2: Stop using internal dma-buf lock dma-buf: Remove obsoleted internal lock Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 211 +++--- drivers/gpu/drm/armada/armada_gem.c | 8 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 24 ++ drivers/gpu/drm/drm_gem_dma_helper.c
[Intel-gfx] [PATCH v4 10/21] RDMA/umem: Prepare to dynamic dma-buf locking specification
Prepare InfiniBand drivers to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/infiniband/core/umem_dmabuf.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c index 04c04e6d24c3..43b26bc12288 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -26,7 +26,8 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) if (umem_dmabuf->sgt) goto wait_fence; - sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL); + sgt = dma_buf_map_attachment_unlocked(umem_dmabuf->attach, + DMA_BIDIRECTIONAL); if (IS_ERR(sgt)) return PTR_ERR(sgt); @@ -102,8 +103,8 @@ void ib_umem_dmabuf_unmap_pages(struct ib_umem_dmabuf *umem_dmabuf) umem_dmabuf->last_sg_trim = 0; } - dma_buf_unmap_attachment(umem_dmabuf->attach, umem_dmabuf->sgt, -DMA_BIDIRECTIONAL); + dma_buf_unmap_attachment_unlocked(umem_dmabuf->attach, umem_dmabuf->sgt, + DMA_BIDIRECTIONAL); umem_dmabuf->sgt = NULL; } -- 2.37.2
Re: [Intel-gfx] [PATCH v2 20/41] drm/modes: Properly generate a drm_display_mode from a named mode
Hi Maxime, > + if (!named_mode->tv_mode) > + continue; As mentioned in the previous email replying to 19/41, this makes it impossible to specify DRM_MODE_TV_MODE_NTSC_443 as currently defined in the named mode successfully. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
>
> 625-lines modes in their drivers.
>
>
>
> Since those modes are fairly standard, and that we'll need to use them
>
> in more places in the future, it makes sense to move their definition
>
> into the core framework.
>
>
>
> However, analog display usually have fairly loose timings requirements,
>
> the only discrete parameters being the total number of lines and pixel
>
> clock frequency. Thus, we created a function that will create a display
>
> mode from the standard, the pixel frequency and the active area.
>
>
>
> Signed-off-by: Maxime Ripard
>
On a 32-bit build I'm getting bogus modes:
[ 249.57] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1]
[ 249.600198] [drm:drm_mode_debug_printmodeline] Modeline "720x480i":
17143 13500 720 308 372 3 480 499 505 525 0x40 0x1a
[ 249.600292] [drm:drm_mode_prune_invalid] Not using 720x480i mode:
H_ILLEGAL
[ 249.600317] [drm:drm_mode_debug_printmodeline] Modeline "720x576i": 0
13500 720 302 366 0 576 597 603 625 0x40 0x1a
[ 249.600349] [drm:drm_mode_prune_invalid] Not using 720x576i mode:
H_ILLEGAL
[ 249.600374] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1] probed modes :
[ 249.600453] [drm:drm_mode_debug_printmodeline] Modeline "720x240i":
60 27800 720 736 808 896 240 241 244 516 0x20 0x6
It's fine on 64-bit.
Noralf.
>
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>
> index 304004fb80aa..ee581ee17171 100644
>
> --- a/drivers/gpu/drm/drm_modes.c
>
> +++ b/drivers/gpu/drm/drm_modes.c
>
> @@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector
> *connector,
>
> }
>
> EXPORT_SYMBOL(drm_mode_probed_add);
>
>
>
> +enum drm_mode_analog {
>
> + DRM_MODE_ANALOG_NTSC,
>
> + DRM_MODE_ANALOG_PAL,
>
> +};
>
> +
>
> +/*
>
> + * The timings come from:
>
> + * -
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
>
> + * -
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
>
> + * -
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
>
> + */
>
> +#define NTSC_LINE_DURATION_NS63556U
>
> +#define NTSC_LINES_NUMBER525
>
> +
>
> +#define NTSC_HBLK_DURATION_TYP_NS10900U
>
> +#define NTSC_HBLK_DURATION_MIN_NS(NTSC_HBLK_DURATION_TYP_NS - 200)
>
> +#define NTSC_HBLK_DURATION_MAX_NS(NTSC_HBLK_DURATION_TYP_NS + 200)
>
> +
>
> +#define NTSC_HACT_DURATION_TYP_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_TYP_NS)
>
> +#define NTSC_HACT_DURATION_MIN_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MAX_NS)
>
> +#define NTSC_HACT_DURATION_MAX_NS(NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MIN_NS)
>
> +
>
> +#define NTSC_HFP_DURATION_TYP_NS 1500
>
> +#define NTSC_HFP_DURATION_MIN_NS 1270
>
> +#define NTSC_HFP_DURATION_MAX_NS 2220
>
> +
>
> +#define NTSC_HSLEN_DURATION_TYP_NS 4700
>
> +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
>
> +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
>
> +
>
> +#define NTSC_HBP_DURATION_TYP_NS 4700
>
> +
>
> +/*
>
> + * I couldn't find the actual tolerance for the back porch, so let's
>
> + * just reuse the sync length ones.
>
> + */
>
> +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
>
> +#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
>
> +
>
> +#define PAL_LINE_DURATION_NS 64000U
>
> +#define PAL_LINES_NUMBER 625
>
> +
>
> +#define PAL_HACT_DURATION_TYP_NS 51950U
>
> +#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
>
> +#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
>
> +
>
> +#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_TYP_NS)
>
> +#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MAX_NS)
>
> +#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
> PAL_HACT_DURATION_MIN_NS)
>
> +
>
> +#define PAL_HFP_DURATION_TYP_NS 1650
>
> +#define PAL_HFP_DURATION_MIN_NS (PAL_HFP_DURATION_TYP_NS - 100)
>
> +#define PAL_HFP_DURATION_MAX_NS (PAL_HFP_DURATION_TYP_NS + 400)
>
> +
>
> +#define PAL_HSLEN_DURATION_TYP_NS4700
>
> +#define PAL_HSLEN_DURATION_MIN_NS(PAL_HSLEN_DURATION_TYP_NS - 200)
>
> +#define PAL_HSLEN_DURATION_MAX_NS(PAL_HSLEN_DURATION_TYP_NS + 200)
>
> +
>
> +#define PAL_HBP_DURATION_TYP_NS 5700
>
> +#define PAL_HBP_DURATION_MIN_NS (PAL_HBP_DURATION_TYP_NS - 200)
>
> +#define PAL_HBP_DURATION_MAX_NS (PAL_HBP_DURATION_TYP_NS + 200)
>
> +
>
> +#define PAL_VFP_INTERLACE_LINES 5
>
> +#define PAL_VSLEN_INTERLACE_LIN
[Intel-gfx] [PATCH v4 07/21] drm/omapdrm: Prepare to dynamic dma-buf locking specification
Prepare OMAP DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 393f82e26927..8e194dbc9506 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -125,7 +125,7 @@ struct drm_gem_object *omap_gem_prime_import(struct
drm_device *dev,
get_dma_buf(dma_buf);
- sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -142,7 +142,7 @@ struct drm_gem_object *omap_gem_prime_import(struct
drm_device *dev,
return obj;
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_TO_DEVICE);
fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);
--
2.37.2
[Intel-gfx] [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification
Prepare Etnaviv driver to the common dynamic dma-buf locking convention by starting to use the unlocked versions of dma-buf API functions. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index 3fa2da149639..7031db145a77 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr); if (etnaviv_obj->vaddr) - dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, &map); + dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, &map); /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: -- 2.37.2
[Intel-gfx] [PATCH v4 12/21] xen/gntdev: Prepare to dynamic dma-buf locking specification
Prepare gntdev driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/xen/gntdev-dmabuf.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 940e5e9e8a54..4440e626b797 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -600,7 +600,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
gntdev_dmabuf->u.imp.attach = attach;
- sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = ERR_CAST(sgt);
goto fail_detach;
@@ -658,7 +658,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct
device *dev,
fail_end_access:
dmabuf_imp_end_foreign_access(gntdev_dmabuf->u.imp.refs, count);
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
fail_detach:
dma_buf_detach(dma_buf, attach);
fail_free_obj:
@@ -708,8 +708,8 @@ static int dmabuf_imp_release(struct gntdev_dmabuf_priv
*priv, u32 fd)
attach = gntdev_dmabuf->u.imp.attach;
if (gntdev_dmabuf->u.imp.sgt)
- dma_buf_unmap_attachment(attach, gntdev_dmabuf->u.imp.sgt,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach,
gntdev_dmabuf->u.imp.sgt,
+ DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
dma_buf_put(dma_buf);
--
2.37.2
Re: [Intel-gfx] [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification
On 9/1/22 09:45, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare i915 driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions
>> and handling cases where importer now holds the reservation lock.
>>
>> Signed-off-by: Dmitry Osipenko
>
> Acked-by: Christian König , but it's probably
> best if somebody from the Intel guys take a look as well.
+ Chris Wilson, who touched locks of __i915_gem_free_objects() recently
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
>> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12
>> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16
>> 3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index f5062d0c6333..07eee1c09aaf 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>> *dma_buf,
>> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>> void *vaddr;
>> - vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> + vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
>> if (IS_ERR(vaddr))
>> return PTR_ERR(vaddr);
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 389e9f157ca5..7e2a9b02526c 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>> drm_i915_private *i915,
>> continue;
>> }
>> + /*
>> + * dma_buf_unmap_attachment() requires reservation to be
>> + * locked. The imported GEM shouldn't share reservation lock,
>> + * so it's safe to take the lock.
>> + */
>> + if (obj->base.import_attach)
>> + i915_gem_object_lock(obj, NULL);
>> +
>> __i915_gem_object_pages_fini(obj);
>> +
>> + if (obj->base.import_attach)
>> + i915_gem_object_unlock(obj);
>> +
>> __i915_gem_free_object(obj);
>> /* But keep the pointer alive for RCU-protected lookups */
>> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> index 62c61af77a42..9e3ed634aa0e 100644
>> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> @@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>> goto out_import;
>> }
>> - st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);
>> + st = dma_buf_map_attachment_unlocked(import_attach,
>> DMA_BIDIRECTIONAL);
>> if (IS_ERR(st)) {
>> err = PTR_ERR(st);
>> goto out_detach;
>> @@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>> timeout = -ETIME;
>> }
>> err = timeout > 0 ? 0 : timeout;
>> - dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
>> + dma_buf_unmap_attachment_unlocked(import_attach, st,
>> DMA_BIDIRECTIONAL);
>> out_detach:
>> dma_buf_detach(dmabuf, import_attach);
>> out_import:
>> @@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
>> goto out_obj;
>> }
>> - err = dma_buf_vmap(dmabuf, &map);
>> + err = dma_buf_vmap_unlocked(dmabuf, &map);
>> dma_map = err ? NULL : map.vaddr;
>> if (!dma_map) {
>> pr_err("dma_buf_vmap failed\n");
>> @@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
>> err = 0;
>> out_dma_map:
>> - dma_buf_vunmap(dmabuf, &map);
>> + dma_buf_vunmap_unlocked(dmabuf, &map);
>> out_obj:
>> i915_gem_object_put(obj);
>> out_dmabuf:
>> @@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>> if (IS_ERR(dmabuf))
>> return PTR_ERR(dmabuf);
>> - err = dma_buf_vmap(dmabuf, &map);
>> + err = dma_buf_vmap_unlocked(dmabuf, &map);
>> ptr = err ? NULL : map.vaddr;
>> if (!ptr) {
>> pr_err("dma_buf_vmap failed\n");
>> @@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>> }
>> memset(ptr, 0xc5, PAGE_SIZE);
>> - dma_buf_vunmap(dmabuf, &map);
>> + dma_buf_vunmap_unlocked(dmabuf, &map);
>> obj = to_intel_bo(i915_gem_prime_import(&i915->drm, dmabuf));
>> if (IS_ERR(obj)) {
>> @@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
>> }
>> i915_gem_object_put(obj);
>> - err = dma_buf_vmap(dmabuf, &map);
>> + err = dma_buf_vmap_unlocked(dmabuf, &map);
>> ptr = err ? NULL : map.vaddr;
>> if (!ptr) {
>> pr_err("dma_buf_vmap fa
Re: [Intel-gfx] [PATCH v2 32/41] drm/vc4: vec: Convert to the new TV mode property
Hi Maxime,
I tested your patchset on my Pi and it mostly works. Good work! However,
I noticed a couple of issues.
> -static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
> - struct drm_crtc_state *crtc_state,
> - struct drm_connector_state *conn_state)
> -{
> - const struct vc4_vec_tv_mode *vec_mode;
> -
> - vec_mode = &vc4_vec_tv_modes[conn_state->tv.mode];
> -
> - if (conn_state->crtc &&
> - !drm_mode_equal(vec_mode->mode, &crtc_state->adjusted_mode))
> - return -EINVAL;
> -
> - return 0;
> -}
I may have said it myself that we should allow custom modelines without too
much validation. The VC4 and VEC, however, have some considerable limitations
when it comes to the modelines that they can reliably output.
In particular, attempting to use "50 Hz" timings in NTSC/PAL-M modes (or
"60 Hz" in PAL/SECAM modes) results in a weirdly skewed image. Here's how it
may look like:
https://user-images.githubusercontent.com/4499762/187575940-736e7262-c82d-42f3-a2d8-f309cbd51139.png
This is because if the CRTC does not trigger the sync pulses within an
acceptable time window, the VEC apparently generates them itself. This causes
the VEC sync pulses (which go onto the wire) not quite line up with the ones
from the modeline, which results in what you see on the screenshot.
I once wrote a validation function based on extensive testing of what
produces a sensible output and what doesn't. You can find it here:
https://github.com/raspberrypi/linux/pull/4406/commits/15c0c51. I think it
might be a good idea to include something like that - even though I know it's
somewhat ugly.
(BTW, those %2 checks on vertical timings in that linked commit can be ignored;
those values are divided by 2 for interlaced modes anyway. Those checks were
intended to ensure proper odd-first or even-first timings; I'm not sure if your
code calculates those in the same way)
> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> {
> - struct drm_connector_state *state = connector->state;
> struct drm_display_mode *mode;
> + int count = 0;
>
> - mode = drm_mode_duplicate(connector->dev,
> - vc4_vec_tv_modes[state->tv.mode].mode);
> + mode = drm_mode_analog_ntsc_480i(connector->dev);
> if (!mode) {
> DRM_ERROR("Failed to create a new display mode\n");
> return -ENOMEM;
> }
>
> drm_mode_probed_add(connector, mode);
> + count += 1;
>
> - return 1;
> + mode = drm_mode_analog_pal_576i(connector->dev);
> + if (!mode) {
> + DRM_ERROR("Failed to create a new display mode\n");
> + return -ENOMEM;
> + }
> +
> + drm_mode_probed_add(connector, mode);
> + count += 1;
> +
> + return count;
> +}
Xorg is pretty confused by these modes being reported like that. The 576i mode
is *always* preferred, presumably because of the higher resolution. If the NTSC
mode is set (via the kernel cmdline or just due to it being the default), this
results in a mess on the screen - exactly the same thing as on the screenshot
linked above.
Note that drm_helper_probe_add_cmdline_mode() *does* add the
DRM_MODE_TYPE_USERDEF flag to the 480i mode, having detected it as preferred
on the command line - but Xorg does not seem to care about that.
I remember Noralf suggesting setting DRM_MODE_TYPE_PREFERRED for the mode that
corresponds to the currently chosen tv_mode - that would fix the problem.
An alternative would be to _not_ add the "opposite" mode at all, like the
current default Raspberry Pi OS kernel behaves.
Note that if you decide to add the modeline validation like I suggested in the
comment above, then without setting the preferred mode properly, Xorg will just
give up and sit on a blank screen until you run xrandr from another terminal
if tv_mode incompatible with 576i is selected.
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 32/41] drm/vc4: vec: Convert to the new TV mode property
Den 29.08.2022 15.11, skrev Maxime Ripard:
> Now that the core can deal fine with analog TV modes, let's convert the vc4
>
> VEC driver to leverage those new features.
>
>
>
> We've added some backward compatibility to support the old TV mode property
>
> and translate it into the new TV norm property.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>
> index ba6f81908923..58286acf4b9e 100644
>
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
>
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -192,7 +200,7 @@ enum vc4_vec_tv_mode_id {
>
> };
>
>
>
> struct vc4_vec_tv_mode {
>
> - const struct drm_display_mode *mode;
>
> + unsigned int mode;
>
> u32 config0;
>
> u32 config1;
>
> u32 custom_freq;
>
> @@ -226,28 +234,50 @@ static const struct debugfs_reg32 vec_regs[] = {
>
> };
>
>
>
> static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>
> - [VC4_VEC_TV_MODE_NTSC] = {
>
> - .mode = &drm_mode_480i,
>
> + {
>
> + .mode = DRM_MODE_TV_MODE_NTSC_M,
>
> .config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> - [VC4_VEC_TV_MODE_NTSC_J] = {
>
> - .mode = &drm_mode_480i,
>
> + {
>
> + .mode = DRM_MODE_TV_MODE_NTSC_J,
>
> .config0 = VEC_CONFIG0_NTSC_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> - [VC4_VEC_TV_MODE_PAL] = {
>
> - .mode = &drm_mode_576i,
>
> + {
>
> + .mode = DRM_MODE_TV_MODE_PAL_B,
>
> .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> - [VC4_VEC_TV_MODE_PAL_M] = {
>
> - .mode = &drm_mode_480i,
>
> + {
>
> + .mode = DRM_MODE_TV_MODE_PAL_M,
>
> .config0 = VEC_CONFIG0_PAL_M_STD,
>
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> };
>
>
>
> +static inline const struct vc4_vec_tv_mode *
>
> +vc4_vec_tv_mode_lookup(unsigned int mode)
>
> +{
>
> + unsigned int i;
>
> +
>
> + for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
>
> + const struct vc4_vec_tv_mode *tv_mode = &vc4_vec_tv_modes[i];
>
> +
>
> + if (tv_mode->mode == mode)
>
> + return tv_mode;
>
> + }
>
> +
>
> + return NULL;
>
> +}
>
> +
>
> +static const struct drm_prop_enum_list tv_mode_names[] = {
Maybe call it legacy_tv_mode_enums?
>
> + { VC4_VEC_TV_MODE_NTSC, "NTSC", },
>
> + { VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
>
> + { VC4_VEC_TV_MODE_PAL, "PAL", },
>
> + { VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
If you use DRM_MODE_TV_MODE_* here you don't need to translate the value
using the switch statement in get/set property, you can use the value
directly to get/set tv.mode.
Noralf.
>
> +};
Re: [Intel-gfx] [PATCH v2 27/41] drm/vc4: vec: Remove redundant atomic_mode_set
Den 29.08.2022 15.11, skrev Maxime Ripard:
> From: Mateusz Kwiatkowski
>
>
>
> Let's remove the superfluous tv_mode field, which was redundant with the
>
> mode field in struct drm_tv_connector_state.
>
>
>
> Signed-off-by: Mateusz Kwiatkowski
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>
> index 9a37c3fcc295..4d7bc7c20704 100644
>
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
>
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
>
> @@ -171,8 +171,6 @@ struct vc4_vec {
>
>
>
> struct clk *clock;
>
>
>
> - const struct vc4_vec_tv_mode *tv_mode;
>
> -
>
> struct debugfs_regset32 regset;
>
> };
>
>
>
> @@ -316,7 +314,6 @@ static int vc4_vec_connector_init(struct drm_device *dev,
> struct vc4_vec *vec)
>
> drm_object_attach_property(&connector->base,
>
> dev->mode_config.legacy_tv_mode_property,
>
> VC4_VEC_TV_MODE_NTSC);
>
> - vec->tv_mode = &vc4_vec_tv_modes[VC4_VEC_TV_MODE_NTSC];
>
>
>
> drm_connector_attach_encoder(connector, &vec->encoder.base);
>
>
>
> @@ -360,6 +357,11 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
>
> {
>
> struct drm_device *drm = encoder->dev;
>
> struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
>
> + struct drm_connector *connector = &vec->connector;
>
> + struct drm_connector_state *conn_state =
>
> + drm_atomic_get_new_connector_state(state, connector);
>
> + const struct vc4_vec_tv_mode *tv_mode =
>
> + &vc4_vec_tv_modes[conn_state->tv.mode];
>
> int idx, ret;
>
>
>
> if (!drm_dev_enter(drm, &idx))
>
> @@ -418,15 +420,14 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
>
> /* Mask all interrupts. */
>
> VEC_WRITE(VEC_MASK0, 0);
>
>
>
> - VEC_WRITE(VEC_CONFIG0, vec->tv_mode->config0);
>
> - VEC_WRITE(VEC_CONFIG1, vec->tv_mode->config1);
>
> + VEC_WRITE(VEC_CONFIG0, tv_mode->config0);
>
> + VEC_WRITE(VEC_CONFIG1, tv_mode->config1);
>
>
>
> - if (vec->tv_mode->custom_freq != 0) {
>
> + if (tv_mode->custom_freq != 0) {
>
> VEC_WRITE(VEC_FREQ3_2,
>
> - (vec->tv_mode->custom_freq >> 16) &
>
> - 0x);
>
> + (tv_mode->custom_freq >> 16) & 0x);
>
> VEC_WRITE(VEC_FREQ1_0,
>
> - vec->tv_mode->custom_freq & 0x);
>
> + tv_mode->custom_freq & 0x);
>
Nit: This patch will be smaller if you add the tv_mode variable to the
previous patch.
Reviewed-by: Noralf Trønnes
> }
>
>
>
> VEC_WRITE(VEC_DAC_MISC,
>
> @@ -442,15 +443,6 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
>
> drm_dev_exit(idx);
>
> }
>
>
>
> -static void vc4_vec_encoder_atomic_mode_set(struct drm_encoder *encoder,
>
> - struct drm_crtc_state *crtc_state,
>
> - struct drm_connector_state *conn_state)
>
> -{
>
> - struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
>
> -
>
> - vec->tv_mode = &vc4_vec_tv_modes[conn_state->tv.mode];
>
> -}
>
> -
>
> static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
>
> struct drm_crtc_state *crtc_state,
>
> struct drm_connector_state *conn_state)
>
> @@ -470,7 +462,6 @@ static const struct drm_encoder_helper_funcs
> vc4_vec_encoder_helper_funcs = {
>
> .atomic_check = vc4_vec_encoder_atomic_check,
>
> .atomic_disable = vc4_vec_encoder_disable,
>
> .atomic_enable = vc4_vec_encoder_enable,
>
> - .atomic_mode_set = vc4_vec_encoder_atomic_mode_set,
>
> };
>
>
>
> static int vc4_vec_late_register(struct drm_encoder *encoder)
>
>
>
Re: [Intel-gfx] [PATCH 09/15] vfio/ap: Use the new device life cycle helpers
Reviewed-by: Tony Krowiak
On 8/27/22 1:10 PM, Kevin Tian wrote:
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 6c8c41fac4e1..803aadfd0876 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -684,42 +684,44 @@ static bool vfio_ap_mdev_filter_matrix(unsigned long
*apm, unsigned long *aqm,
AP_DOMAINS);
}
-static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+static int vfio_ap_mdev_init_dev(struct vfio_device *vdev)
{
- struct ap_matrix_mdev *matrix_mdev;
- int ret;
+ struct ap_matrix_mdev *matrix_mdev =
+ container_of(vdev, struct ap_matrix_mdev, vdev);
if ((atomic_dec_if_positive(&matrix_dev->available_instances) < 0))
return -EPERM;
- matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
- if (!matrix_mdev) {
- ret = -ENOMEM;
- goto err_dec_available;
- }
- vfio_init_group_dev(&matrix_mdev->vdev, &mdev->dev,
- &vfio_ap_matrix_dev_ops);
-
- matrix_mdev->mdev = mdev;
+ matrix_mdev->mdev = to_mdev_device(vdev->dev);
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->matrix);
matrix_mdev->pqap_hook = handle_pqap;
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
hash_init(matrix_mdev->qtable.queues);
+ return 0;
+}
+
+static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+ int ret;
+
+ matrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, &mdev->dev,
+ &vfio_ap_matrix_dev_ops);
+ if (IS_ERR(matrix_mdev))
+ return PTR_ERR(matrix_mdev);
+
ret = vfio_register_emulated_iommu_dev(&matrix_mdev->vdev);
if (ret)
- goto err_list;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, matrix_mdev);
mutex_lock(&matrix_dev->mdevs_lock);
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_dev->mdevs_lock);
return 0;
-err_list:
- vfio_uninit_group_dev(&matrix_mdev->vdev);
- kfree(matrix_mdev);
-err_dec_available:
- atomic_inc(&matrix_dev->available_instances);
+err_put_vdev:
+ vfio_put_device(&matrix_mdev->vdev);
return ret;
}
@@ -766,6 +768,12 @@ static void vfio_ap_mdev_unlink_fr_queues(struct ap_matrix_mdev *matrix_mdev)
}
}
+static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
+{
+ vfio_free_device(vdev);
+ atomic_inc(&matrix_dev->available_instances);
+}
+
static void vfio_ap_mdev_remove(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(&mdev->dev);
@@ -779,9 +787,7 @@ static void vfio_ap_mdev_remove(struct mdev_device *mdev)
list_del(&matrix_mdev->node);
mutex_unlock(&matrix_dev->mdevs_lock);
mutex_unlock(&matrix_dev->guests_lock);
- vfio_uninit_group_dev(&matrix_mdev->vdev);
- kfree(matrix_mdev);
- atomic_inc(&matrix_dev->available_instances);
+ vfio_put_device(&matrix_mdev->vdev);
}
static ssize_t name_show(struct mdev_type *mtype,
@@ -1794,6 +1800,8 @@ static const struct attribute_group vfio_queue_attr_group
= {
};
static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {
+ .init = vfio_ap_mdev_init_dev,
+ .release = vfio_ap_mdev_release_dev,
.open_device = vfio_ap_mdev_open_device,
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime,
Wow. That's an enormous amount of effort put into this patch.
But I'm tempted to say that this is actually overengineered quite a bit :D
Considering that there's no way to access all these calculations from user
space, and I can't imagine anybody using anything else than those standard
480i/576i (and maybe 240p/288p) modes at 13.5 MHz any time soon... I'm not
sure if we actually need all this.
But anyway, I'm not the maintainer of this subsystem, so I'm not the one to
decide.
> +enum drm_mode_analog {
> + DRM_MODE_ANALOG_NTSC,
> + DRM_MODE_ANALOG_PAL,
> +};
Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is common,
but strictly speaking a misnomer. Those are color encoding systems, and your
patchset fully supports lesser used, but standard encodings for those (e.g.
PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more neutral
naming scheme. Some ideas:
- DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh rate)
- DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
count)
- DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU System
Letter Designations)
> +#define NTSC_HFP_DURATION_TYP_NS 1500
> +#define NTSC_HFP_DURATION_MIN_NS 1270
> +#define NTSC_HFP_DURATION_MAX_NS 2220
You've defined those min/typ/max ranges, but you're not using the "typ" field
for anything other than hslen. The actual "typical" value is thus always the
midpoint, which isn't necessarily the best choice.
In particular, for the standard 720px wide modes at 13.5 MHz, hsync_start
ends up being 735 for 480i and 734 for 576i, instead of 736 and 732 requested
by BT.601. That's all obviously within tolerances, but the image ends up
noticeably off-center (at least on modern TVs), especially in the 576i case.
> + htotal = params->line_duration_ns * pixel_clock_hz / NSEC_PER_SEC;
You're multiplying an unsigned int and an unsigned long - both types are only
required to be 32 bit, so this is likely to overflow. You need to use a cast to
unsigned long long, and then call do_div() for 64-bit division.
This actually overflowed on me on my Pi running ARM32 kernel, resulting in
negative horizontal porch lengths, and drm_helper_probe_add_cmdline_mode()
taking over the mode generation (badly), and a horrible mess on screen.
> + vfp = vfp_min + (porches_rem / 2);
> + vbp = porches - vfp;
Relative position of the vertical sync within the VBI effectively moves the
image up and down. Adding that (porches_rem / 2) moves the image up off center
by that many pixels. I'd keep the VFP always at minimum to keep the image
centered.
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 01/41] drm/tests: Order Kunit tests in Makefile
Den 29.08.2022 15.11, skrev Maxime Ripard: > Since we've recently added a ton of tests, the list starts to be a bit > > of a mess and creates unneeded conflicts. > > > > Let's order it alphabetically. > > > > Signed-off-by: Maxime Ripard > > > Something has gone wrong with this patchset, there are double line endings. I looked at the patchwork version and it look all right there so I figured it might have fixed up the patches, but it failed: git apply -v --check /home/pi/tinydrm.gud-gadget/workdirs/tv_norm_gadget/53.patch Checking patch drivers/gpu/drm/tests/Makefile... error: while searching for: # SPDX-License-Identifier: GPL-2.0? ? obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o drm_damage_helper_test.o \? drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o drm_plane_helper_test.o \? drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o drm_mm_test.o? error: patch failed: drivers/gpu/drm/tests/Makefile:1 error: drivers/gpu/drm/tests/Makefile: patch does not apply ERROR: Failed check apply patch pi@build-server:~/tinydrm.gud-gadget$ file workdirs/tv_norm_gadget/53.patch workdirs/tv_norm_gadget/53.patch: unified diff output, ASCII text, with CRLF, LF line terminators Noralf. > diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile > > index 91b70f7d2769..2d9f49b62ecb 100644 > > --- a/drivers/gpu/drm/tests/Makefile > > +++ b/drivers/gpu/drm/tests/Makefile > > @@ -1,5 +1,13 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o > drm_damage_helper_test.o \ > > - drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o > drm_plane_helper_test.o \ > > - drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o > drm_mm_test.o > > +obj-$(CONFIG_DRM_KUNIT_TEST) += \ > > + drm_buddy_test.o \ > > + drm_cmdline_parser_test.o \ > > + drm_damage_helper_test.o \ > > + drm_dp_mst_helper_test.o \ > > + drm_format_helper_test.o \ > > + drm_format_test.o \ > > + drm_framebuffer_test.o \ > > + drm_mm_test.o \ > > + drm_plane_helper_test.o \ > > + drm_rect_test.o > > >
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime,
W dniu 5.09.2022 o 15:32, Maxime Ripard pisze:
> Hi,
>
> On Wed, Aug 31, 2022 at 10:14:28AM +0200, Geert Uytterhoeven wrote:
+enum drm_mode_analog {
+ DRM_MODE_ANALOG_NTSC,
+ DRM_MODE_ANALOG_PAL,
+};
>>>
>>> Using "NTSC" and "PAL" to describe the 50Hz and 60Hz analog TV modes is
>>> common,
>>> but strictly speaking a misnomer. Those are color encoding systems, and your
>>> patchset fully supports lesser used, but standard encodings for those (e.g.
>>> PAL-M for 60Hz and SECAM for 50Hz). I'd propose switching to some more
>>> neutral
>>> naming scheme. Some ideas:
>>>
>>> - DRM_MODE_ANALOG_60_HZ / DRM_MODE_ANALOG_50_HZ (after standard refresh
>>> rate)
>>> - DRM_MODE_ANALOG_525_LINES / DRM_MODE_ANALOG_625_LINES (after standard line
>>> count)
>>
>> IMHO these are bad names, as e.g. VGA640x480@60 is also analog, using
>> 60 Hz and 525 lines. Add "TV" to the name?
>>
>>> - DRM_MODE_ANALOG_JM / DRM_MODE_ANALOG_BDGHIKLN (after corresponding ITU
>>> System
>>> Letter Designations)
>>
>> Or DRM_MODE_ITU_*?
>> But given the long list of letters, this looks fragile to me.
>
> Does it matter at all? It's an internal API that isn't exposed at all.
> I'd rather have a common name that everyone can understand in this case
> rather than a *perfect* name where most will scratch their head
> wondering what it's about.
You may have a point. But in that case, maybe it'd make sense to at least add
a short comment explaining what do you mean by "NTSC" and "PAL" in this context?
Best regards,
Mateusz Kwiatkowski
[Intel-gfx] [PATCH v4 17/21] dma-buf: Move dma_buf_map_attachment() to dynamic locking specification
Move dma-buf attachment mapping functions to the dynamic locking
specification by asserting that the reservation lock is held.
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 073942bf5ae9..8e928fe6e8df 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1037,8 +1037,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
- if (dma_buf_attachment_is_dynamic(attach))
- dma_resv_assert_held(attach->dmabuf->resv);
+ dma_resv_assert_held(attach->dmabuf->resv);
if (attach->sgt) {
/*
@@ -1053,7 +1052,6 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
if (dma_buf_is_dynamic(attach->dmabuf)) {
- dma_resv_assert_held(attach->dmabuf->resv);
if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
r = attach->dmabuf->ops->pin(attach);
if (r)
@@ -1142,15 +1140,11 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
- if (dma_buf_attachment_is_dynamic(attach))
- dma_resv_assert_held(attach->dmabuf->resv);
+ dma_resv_assert_held(attach->dmabuf->resv);
if (attach->sgt == sg_table)
return;
- if (dma_buf_is_dynamic(attach->dmabuf))
- dma_resv_assert_held(attach->dmabuf->resv);
-
__unmap_dma_buf(attach, sg_table, direction);
if (dma_buf_is_dynamic(attach->dmabuf) &&
--
2.37.2
[Intel-gfx] [PATCH v4 04/21] drm/prime: Prepare to dynamic dma-buf locking specification
Prepare DRM prime core to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_prime.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index eb09e86044c6..20e109a802ae 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -940,7 +940,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct
drm_device *dev,
get_dma_buf(dma_buf);
- sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ sgt = dma_buf_map_attachment_unlocked(attach, DMA_BIDIRECTIONAL);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
goto fail_detach;
@@ -958,7 +958,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct
drm_device *dev,
return obj;
fail_unmap:
- dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sgt, DMA_BIDIRECTIONAL);
fail_detach:
dma_buf_detach(dma_buf, attach);
dma_buf_put(dma_buf);
@@ -1056,7 +1056,7 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj,
struct sg_table *sg)
attach = obj->import_attach;
if (sg)
- dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(attach, sg,
DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
/* remove the reference */
--
2.37.2
Re: [Intel-gfx] [PATCH v2 18/41] drm/connector: Add a function to lookup a TV mode by its name
Den 29.08.2022 15.11, skrev Maxime Ripard:
> As part of the command line parsing rework coming in the next patches,
>
> we'll need to lookup drm_connector_tv_mode values by their name, already
>
> defined in drm_tv_mode_enum_list.
>
>
>
> In order to avoid any code duplication, let's do a function that will
>
> perform a lookup of a TV mode name and return its value.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>
> index b1fcacd150e8..0fe01a1c20ad 100644
>
> --- a/drivers/gpu/drm/drm_connector.c
>
> +++ b/drivers/gpu/drm/drm_connector.c
>
> @@ -1003,6 +1003,30 @@ static const struct drm_prop_enum_list
> drm_tv_mode_enum_list[] = {
>
> };
>
> DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
>
>
>
> +/**
>
> + * drm_get_tv_mode_from_name - Translates a TV mode name into its enum value
>
> + * @name: TV Mode name we want to convert
>
> + * @len: Length of @name
>
> + *
>
> + * Translates @name into an enum drm_connector_tv_mode.
>
> + *
>
> + * Returns: the enum value on success, a negative errno otherwise.
>
> + */
>
> +int drm_get_tv_mode_from_name(const char *name, size_t len)
>
> +{
>
> + unsigned int i;
>
> +
>
> + for (i = 0; i < ARRAY_SIZE(drm_tv_mode_enum_list); i++) {
>
> + const struct drm_prop_enum_list *item =
> &drm_tv_mode_enum_list[i];
>
> +
>
> + if (strlen(item->name) == len && !strncmp(item->name, name,
> len))
>
> + return item->type;
>
> + }
>
> +
>
> + return -EINVAL;
>
> +}
>
> +EXPORT_SYMBOL(drm_get_tv_mode_from_name)
Missing semicolon.
Noralf.
>
> +
>
> static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
>
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
>
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>
> index bb39d2bb806e..49d261977d4e 100644
>
> --- a/include/drm/drm_connector.h
>
> +++ b/include/drm/drm_connector.h
>
> @@ -1943,6 +1943,8 @@ const char *drm_get_dp_subconnector_name(int val);
>
> const char *drm_get_content_protection_name(int val);
>
> const char *drm_get_hdcp_content_type_name(int val);
>
>
>
> +int drm_get_tv_mode_from_name(const char *name, size_t len);
>
> +
>
> int drm_mode_create_dvi_i_properties(struct drm_device *dev);
>
> void drm_connector_attach_dp_subconnector_property(struct drm_connector
> *connector);
>
>
>
>
>
Re: [Intel-gfx] [PATCH v2 19/41] drm/modes: Introduce the tv_mode property as a command-line option
Hi Maxime,
> @@ -2212,20 +2239,22 @@ struct drm_named_mode {
> unsigned int xres;
> unsigned int yres;
> unsigned int flags;
> + unsigned int tv_mode;
> };
Are _all_ named modes supposed to be about analog TV?
If so, then probably this structure should be renamed drm_named_analog_tv_mode
or something.
If not, then including tv_mode in all of them sounds almost dangrous. 0 is a
valid value for enum drm_connector_tv_mode, corresponding to
DRM_MODE_TV_MODE_NTSC_443. This is a very weird default (maybe it shouldn't be
the one that has a numeric value of 0?) and if there ever is a named mode that
is not related to analog TV, it looks that it will refer to NTSC-443.
Not sure where could that actually propagate, and maybe what I'm saying can't
happen, but I'm imagining weird scenarios where a GPU that has both a
VGA/HDMI/whatever output, and a composite output, switches to NTSC-443 on the
composite output by default because a named mode for the modern output is
selected.
Maybe something like DRM_MODE_TV_MODE_NONE = 0 would make sense?
Maybe not. This is not an actual suggestion, just "thinking out loud".
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes
Hi Maxime, W dniu 5.09.2022 o 15:37, Maxime Ripard pisze: >>> + vfp = vfp_min + (porches_rem / 2); >>> + vbp = porches - vfp; >> >> Relative position of the vertical sync within the VBI effectively moves the >> image up and down. Adding that (porches_rem / 2) moves the image up off >> center >> by that many pixels. I'd keep the VFP always at minimum to keep the image >> centered. > > And you would increase the back porch only then? Well, increasing vbp only gives a centered image with the default 480i/576i resolutions. However, only ever changing vbp will cause the image to be always at the bottom of the screen when the active line count is decreased (e.g. setting the resolution to 720x480 but for 50Hz "PAL" - like many game consoles did back in the day). I believe that the perfect solution would: - Use the canonical / standard-defined blanking line counts for the standard vertical resolutions (480/486/576) - Increase vfp and vbp from there by the same number if a smaller number of active lines is specified, so that the resulting image is centered - Likewise, decrease vfp and vbp by the same number if the active line number is larger and there is still leeway (this should allow for seamless handling of 480i vs. 486i for 60 Hz "NTSC") - If even more active lines are specified, once the limit for vfp is hit, then decrease vbp only - the resulting image will definitely be off-center, but there's no other way I hope this makes sense for you as well. Best regards, Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH v2 09/41] drm/connector: Add TV standard property
Hi Maxime,
W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
>
> Let's create a new bitmask tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports.
This is not a bitmask property anymore, you've just changed it to an enum.
The commit message is now misleading.
> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
> + { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> + { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> + { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
> + { DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
> + { DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
> + { DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
> + { DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
> + { DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
> + { DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
> + { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> + { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> + { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
> + { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
> + { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
> + { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
> + { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
> + { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
> + { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
> + { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
> +};
I did not comment on it the last time, but this list looks a little bit random.
Compared to the standards defined by V4L2, you also define SECAM-60 (a good
thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K,
SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L,
see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC).
Like I mentioned previously, I'm personally not a fan of including all those
CCIR/ITU system variants, as they don't mean any difference to the output unless
there is an RF modulator involved. But I get it that they have already been used
and regressing probably wouldn't be a very good idea. But in that case keeping
it consistent with the set of values used by V4L2 would be wise, I think.
> +/**
> + * drm_mode_create_tv_properties - create TV specific connector properties
> + * @dev: DRM device
> + * @supported_tv_modes: Bitmask of TV modes supported (See
> DRM_MODE_TV_MODE_*)
> +
> + * Called by a driver's TV initialization routine, this function creates
> + * the TV specific connector properties for a given device. Caller is
> + * responsible for allocating a list of format names and passing them to
> + * this routine.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_mode_create_tv_properties(struct drm_device *dev,
> + unsigned int supported_tv_modes)
supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*)
(or (1< + /**
> + * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to
> + * @DRM_MODE_TV_MODE_PAL_N.
> + */
> + DRM_MODE_TV_MODE_PAL_NC,
AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate
from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU
documents. See also the posting signed as Alchaemist here:
https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc
That being said, we probably want to keep it if we want to remaing compatible
with the loads of software and drivers which enumerate those as separate
systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN
etc.) are just different "spellings" referring to exactly the same system.
> + /**
> + * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the
> + * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but
> + * with different channels.
> + */
> + DRM_MODE_TV_MODE_SECAM_K,
> +
> + /**
> + * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the
> + * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and
> + * @DRM_MODE_TV_MODE_SECAM_K but with different channels.
> + */
> + DRM_MODE_TV_MODE_SECAM_K1,
Typos: you meant CCIR Systems K and K1, not System G.
Best regards,
Mateusz Kwiatkowski
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
Hello everyone,
I'm Zheng Wang. I found a potential double-free bug
in drivers/gpu/drm/i915/gvt/gtt.c. I haven't been replied for a long time.
So I decided to send it to more relavent supporters and developers to help
to solve the problem.
Best regards,
Zheng Wang.
xmzyshypnc <1002992...@qq.com> 于2022年9月4日周日 20:32写道：
> There is a double-free security bug in split_2MB_gtt_entry.
>
> Here is a calling chain :
> ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. If
> intel_gvt_dma_map_guest_page failed, it will call ppgtt_invalidate_spt,
> which will finally call ppgtt_free_spt and kfree(spt). But the caller does
> not notice that, and it will call ppgtt_free_spt again in error path.
>
> Fix this by returning the result of ppgtt_invalidate_spt to
> split_2MB_gtt_entry.
>
> Signed-off-by: Zheng Wang <1002992...@qq.com>
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c
> b/drivers/gpu/drm/i915/gvt/gtt.c
> index ce0eb03709c3..9f14fded8c0c 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu
> *vgpu,
> ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
> sub_index,
>PAGE_SIZE, &dma_addr);
> if (ret) {
> - ppgtt_invalidate_spt(spt);
> + ret = ppgtt_invalidate_spt(spt);
> return ret;
> }
> sub_se.val64 = se->val64;
> --
> 2.25.1
>
>
Re: [Intel-gfx] [PATCH v2 26/41] drm/vc4: vec: Refactor VEC TV mode setting
Den 29.08.2022 15.11, skrev Maxime Ripard:
> From: Mateusz Kwiatkowski
>
>
>
> Change the mode_set function pointer logic to declarative config0,
>
> config1 and custom_freq fields, to make TV mode setting logic more
>
> concise and uniform.
>
>
>
> Signed-off-by: Mateusz Kwiatkowski
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>
> index 72eee0cbb615..9a37c3fcc295 100644
>
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
>
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
>
> @@ -194,7 +194,9 @@ enum vc4_vec_tv_mode_id {
>
>
>
> struct vc4_vec_tv_mode {
>
> const struct drm_display_mode *mode;
>
> - void (*mode_set)(struct vc4_vec *vec);
>
> + u32 config0;
>
> + u32 config1;
>
> + u32 custom_freq;
>
> };
>
>
>
> static const struct debugfs_reg32 vec_regs[] = {
>
> @@ -224,34 +226,6 @@ static const struct debugfs_reg32 vec_regs[] = {
>
> VC4_REG32(VEC_DAC_MISC),
>
> };
>
>
>
> -static void vc4_vec_ntsc_mode_set(struct vc4_vec *vec)
>
> -{
>
> - struct drm_device *drm = vec->connector.dev;
>
> - int idx;
>
> -
>
> - if (!drm_dev_enter(drm, &idx))
>
> - return;
>
> -
>
> - VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN);
>
> - VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
>
> -
>
> - drm_dev_exit(idx);
>
> -}
>
> -
>
> -static void vc4_vec_ntsc_j_mode_set(struct vc4_vec *vec)
>
> -{
>
> - struct drm_device *drm = vec->connector.dev;
>
> - int idx;
>
> -
>
> - if (!drm_dev_enter(drm, &idx))
>
> - return;
>
> -
>
> - VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_NTSC_STD);
>
> - VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
>
> -
>
> - drm_dev_exit(idx);
>
> -}
>
> -
>
> static const struct drm_display_mode ntsc_mode = {
>
> DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
>
>720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
>
> @@ -259,37 +233,6 @@ static const struct drm_display_mode ntsc_mode = {
>
>DRM_MODE_FLAG_INTERLACE)
>
> };
>
>
>
> -static void vc4_vec_pal_mode_set(struct vc4_vec *vec)
>
> -{
>
> - struct drm_device *drm = vec->connector.dev;
>
> - int idx;
>
> -
>
> - if (!drm_dev_enter(drm, &idx))
>
> - return;
>
> -
>
> - VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_PAL_BDGHI_STD);
>
> - VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
>
> -
>
> - drm_dev_exit(idx);
>
> -}
>
> -
>
> -static void vc4_vec_pal_m_mode_set(struct vc4_vec *vec)
>
> -{
>
> - struct drm_device *drm = vec->connector.dev;
>
> - int idx;
>
> -
>
> - if (!drm_dev_enter(drm, &idx))
>
> - return;
>
> -
>
> - VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_PAL_BDGHI_STD);
>
> - VEC_WRITE(VEC_CONFIG1,
>
> - VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ);
>
> - VEC_WRITE(VEC_FREQ3_2, 0x223b);
>
> - VEC_WRITE(VEC_FREQ1_0, 0x61d1);
>
> -
>
> - drm_dev_exit(idx);
>
> -}
>
> -
>
> static const struct drm_display_mode pal_mode = {
>
> DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
>
>720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
>
> @@ -300,19 +243,24 @@ static const struct drm_display_mode pal_mode = {
>
> static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>
> [VC4_VEC_TV_MODE_NTSC] = {
>
> .mode = &ntsc_mode,
>
> - .mode_set = vc4_vec_ntsc_mode_set,
>
> + .config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
>
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_NTSC_J] = {
>
> .mode = &ntsc_mode,
>
> - .mode_set = vc4_vec_ntsc_j_mode_set,
>
> + .config0 = VEC_CONFIG0_NTSC_STD,
>
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_PAL] = {
>
> .mode = &pal_mode,
>
> - .mode_set = vc4_vec_pal_mode_set,
>
> + .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS,
>
> },
>
> [VC4_VEC_TV_MODE_PAL_M] = {
>
> .mode = &pal_mode,
>
> - .mode_set = vc4_vec_pal_m_mode_set,
>
> + .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
>
> + .custom_freq = 0x223b61d1,
>
> },
>
> };
>
>
>
> @@ -470,7 +418,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
>
> /* Mask all interrupts. */
>
> VEC_WRITE(VEC_MASK0, 0);
>
>
>
> - vec->tv_mode->mode_set(vec);
>
> + VEC_WRITE(VEC_CONFIG0, vec->tv_mode->config0);
>
> + VEC_WRITE(VEC_CONFIG1, vec->tv_mode->config1);
>
> +
>
> + if (vec->tv_mode->custom_freq != 0) {
Nit: '!= 0' is not necessary and not common either in kernel code.
[Intel-gfx] [PATCH v4 19/21] dma-buf: Document dynamic locking convention
Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 64 2 files changed, 70 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 36a76cbe9095..622b8156d212 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -119,6 +119,12 @@ DMA Buffer ioctls .. kernel-doc:: include/uapi/linux/dma-buf.h +DMA-BUF locking convention +~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: locking convention + Kernel Functions and Structures Reference ~ diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d9130486cb8f..97ce884fad76 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -794,6 +794,70 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, return sg_table; } +/** + * DOC: locking convention + * + * In order to avoid deadlock situations between dma-buf exports and importers, + * all dma-buf API users must follow the common dma-buf locking convention. + * + * Convention for importers + * + * 1. Importers must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_pin() + * - dma_buf_unpin() + * - dma_buf_map_attachment() + * - dma_buf_unmap_attachment() + * - dma_buf_vmap() + * - dma_buf_vunmap() + * + * 2. Importers must not hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_attach() + * - dma_buf_dynamic_attach() + * - dma_buf_detach() + * - dma_buf_export( + * - dma_buf_fd() + * - dma_buf_get() + * - dma_buf_put() + * - dma_buf_mmap() + * - dma_buf_begin_cpu_access() + * - dma_buf_end_cpu_access() + * - dma_buf_map_attachment_unlocked() + * - dma_buf_unmap_attachment_unlocked() + * - dma_buf_vmap_unlocked() + * - dma_buf_vunmap_unlocked() + * + * Convention for exporters + * + * 1. These &dma_buf_ops callbacks are invoked with unlocked dma-buf + *reservation and exporter can take the lock: + * + * - &dma_buf_ops.attach() + * - &dma_buf_ops.detach() + * - &dma_buf_ops.release() + * - &dma_buf_ops.begin_cpu_access() + * - &dma_buf_ops.end_cpu_access() + * + * 2. These &dma_buf_ops callbacks are invoked with locked dma-buf + *reservation and exporter can't take the lock: + * + * - &dma_buf_ops.pin() + * - &dma_buf_ops.unpin() + * - &dma_buf_ops.map_dma_buf() + * - &dma_buf_ops.unmap_dma_buf() + * - &dma_buf_ops.mmap() + * - &dma_buf_ops.vmap() + * - &dma_buf_ops.vunmap() + * + * 3. Exporters must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_move_notify() + */ + /** * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list * @dmabuf:[in]buffer to attach device to. -- 2.37.2
[Intel-gfx] [PATCH v4 03/21] drm/gem: Take reservation lock for vmap/vunmap operations
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This patch prepares DRM core and drivers to the common dynamic dma-buf
locking convention.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client.c | 4 ++--
drivers/gpu/drm/drm_gem.c| 24
drivers/gpu/drm/drm_gem_dma_helper.c | 6 ++---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++---
drivers/gpu/drm/drm_gem_ttm_helper.c | 9 +---
drivers/gpu/drm/lima/lima_sched.c| 4 ++--
drivers/gpu/drm/panfrost/panfrost_dump.c | 4 ++--
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 ++---
drivers/gpu/drm/qxl/qxl_object.c | 17 +++---
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
include/drm/drm_gem.h| 3 +++
11 files changed, 54 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 2b230b4d6942..fbcb1e995384 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -323,7 +323,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, map);
+ ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
@@ -345,7 +345,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
*buffer)
{
struct iosys_map *map = &buffer->map;
- drm_gem_vunmap(buffer->gem, map);
+ drm_gem_vunmap_unlocked(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ad068865ba20..9c55593d662d 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1156,6 +1156,8 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct
iosys_map *map)
{
int ret;
+ dma_resv_assert_held(obj->resv);
+
if (!obj->funcs->vmap)
return -EOPNOTSUPP;
@@ -1171,6 +1173,8 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
+ dma_resv_assert_held(obj->resv);
+
if (iosys_map_is_null(map))
return;
@@ -1182,6 +1186,26 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct
iosys_map *map)
}
EXPORT_SYMBOL(drm_gem_vunmap);
+int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ int ret;
+
+ dma_resv_lock(obj->resv, NULL);
+ ret = drm_gem_vmap(obj, map);
+ dma_resv_unlock(obj->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vmap_unlocked);
+
+void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ dma_resv_lock(obj->resv, NULL);
+ drm_gem_vunmap(obj, map);
+ dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
+
/**
* drm_gem_lock_reservations - Sets up the ww context and acquires
* the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index f6901ff97bbb..1e658c448366 100644
--- a/drivers/gpu/drm/drm_gem_dma_helper.c
+++ b/drivers/gpu/drm/drm_gem_dma_helper.c
@@ -230,7 +230,7 @@ void drm_gem_dma_free(struct drm_gem_dma_object *dma_obj)
if (gem_obj->import_attach) {
if (dma_obj->vaddr)
- dma_buf_vunmap(gem_obj->import_attach->dmabuf, &map);
+ dma_buf_vunmap_unlocked(gem_obj->import_attach->dmabuf,
&map);
drm_prime_gem_destroy(gem_obj, dma_obj->sgt);
} else if (dma_obj->vaddr) {
if (dma_obj->map_noncoherent)
@@ -581,7 +581,7 @@ drm_gem_dma_prime_import_sg_table_vmap(struct drm_device
*dev,
struct iosys_map map;
int ret;
- ret = dma_buf_vmap(attach->dmabuf, &map);
+ ret = dma_buf_vmap_unlocked(attach->dmabuf, &map);
if (ret) {
DRM_ERROR("Failed to vmap PRIME buffer\n");
return ERR_PTR(ret);
@@ -589,7 +589,7 @@ drm_gem_dma_prime_import_sg_table_vmap(struct drm_device
*dev,
obj = drm_gem_dma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj)) {
- dma_buf_vunmap(attach->dmabuf, &map);
+ dma_buf_vunmap_unlocked(attach->dmabuf, &map);
return obj;
}
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 880a4975507f..e35e224e6303 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -354,7
[Intel-gfx] [PATCH v4 14/21] media: tegra-vde: Prepare to dynamic dma-buf locking specification
Prepare Tegra video decoder driver to the common dynamic dma-buf
locking convention by starting to use the unlocked versions of dma-buf
API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
index 69c346148070..1c5b94989aec 100644
--- a/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
+++ b/drivers/media/platform/nvidia/tegra-vde/dmabuf-cache.c
@@ -38,7 +38,7 @@ static void tegra_vde_release_entry(struct
tegra_vde_cache_entry *entry)
if (entry->vde->domain)
tegra_vde_iommu_unmap(entry->vde, entry->iova);
- dma_buf_unmap_attachment(entry->a, entry->sgt, entry->dma_dir);
+ dma_buf_unmap_attachment_unlocked(entry->a, entry->sgt, entry->dma_dir);
dma_buf_detach(dmabuf, entry->a);
dma_buf_put(dmabuf);
@@ -102,7 +102,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
goto err_unlock;
}
- sgt = dma_buf_map_attachment(attachment, dma_dir);
+ sgt = dma_buf_map_attachment_unlocked(attachment, dma_dir);
if (IS_ERR(sgt)) {
dev_err(dev, "Failed to get dmabufs sg_table\n");
err = PTR_ERR(sgt);
@@ -152,7 +152,7 @@ int tegra_vde_dmabuf_cache_map(struct tegra_vde *vde,
err_free:
kfree(entry);
err_unmap:
- dma_buf_unmap_attachment(attachment, sgt, dma_dir);
+ dma_buf_unmap_attachment_unlocked(attachment, sgt, dma_dir);
err_detach:
dma_buf_detach(dmabuf, attachment);
err_unlock:
--
2.37.2
Re: [Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements
Den 05.09.2022 16.57, skrev Maxime Ripard: > On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote: >> >> >> Den 01.09.2022 21.35, skrev Noralf Trønnes: >>> >>> >>> I have finally found a workaround for my kernel hangs. >>> >>> Dom had a look at my kernel and found that the VideoCore was fine, and >>> he said this: >>> That suggests cause of lockup was on arm side rather than VC side. But it's hard to diagnose further. Once you've had a peripheral not respond, the AXI bus locks up and no further operations are possible. Usual causes of this are required clocks being stopped or domains disabled and then trying to access the hardware. >>> >>> So when I got this on my 64-bit build: >>> >>> [ 166.702171] SError Interrupt on CPU1, code 0xbf02 -- SError >>> [ 166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: GW >>> 5.19.0-rc6-00096-gba7973977976-dirty #1 >>> [ 166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) >>> [ 166.702206] Workqueue: events_freezable_power_ thermal_zone_device_check >>> [ 166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS >>> BTYPE=--) >>> [ 166.702242] pc : regmap_mmio_read32le+0x10/0x28 >>> [ 166.702261] lr : regmap_mmio_read+0x44/0x70 >>> ... >>> [ 166.702606] bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal] >>> >>> I wondered if that reg read was stalled due to a clock being stopped. >>> >>> Lo and behold, disabling runtime pm and keeping the vec clock running >>> all the time fixed it[1]. >>> >>> I don't know what the problem is, but at least I can now test this patchset. >>> >>> [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065 >>> >> >> It turns out I didn't have to disable runtime pm: >> https://gist.github.com/notro/0adcfcb12460b54e54458afe11dc8ea2 > > If the bcm2711_thermal IP needs that clock to be enabled, it should grab > a reference itself, but it looks like even the device tree binding > doesn't ask for one. > The first thing I tried was to unload the bcm2711_thermal module before running modeset and it still hung, so I don't think that's the problem. Noralf.
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
I rewrote the letter. Hope it works.
There is a double-free security bug in split_2MB_gtt_entry.
Here is a calling chain :
ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry.
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally call ppgtt_free_spt and
kfree(spt). But the caller does not notice that, and it will call
ppgtt_free_spt again in error path.
Fix this by returning the result of ppgtt_invalidate_spt to split_2MB_gtt_entry.
Signed-off-by: Zheng Wang
---
drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index ce0eb03709c3..9f14fded8c0c 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
PAGE_SIZE, &dma_addr);
if (ret) {
- ppgtt_invalidate_spt(spt);
+ ret = ppgtt_invalidate_spt(spt);
return ret;
}
sub_se.val64 = se->val64;
--
2.25.1
Re: [Intel-gfx] [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification
On 9/1/22 09:50, Christian König wrote: > Am 31.08.22 um 17:37 schrieb Dmitry Osipenko: >> Prepare Etnaviv driver to the common dynamic dma-buf locking convention >> by starting to use the unlocked versions of dma-buf API functions. >> >> Signed-off-by: Dmitry Osipenko > > Interesting, where is the matching vmap()? > > Anyway, this patch is Acked-by: Christian König Etnaviv maps GEM only once and then unmaps it when GEM is destroyed. The dma-buf vmapping should happen under the reservation lock, hence only the release function needs to be changed to the unlocked variant. Lucas/Christian(Gmeiner), could you please check that I haven't missed anything? >> --- >> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c >> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c >> index 3fa2da149639..7031db145a77 100644 >> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c >> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c >> @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct >> etnaviv_gem_object *etnaviv_obj) >> struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr); >> if (etnaviv_obj->vaddr) >> - dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, &map); >> + >> dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, &map); >> /* Don't drop the pages for imported dmabuf, as they are not >> * ours, just free the array we allocated: > -- Best regards, Dmitry
Re: [Intel-gfx] [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
On 31/08/2022 16:37, Dmitry Osipenko wrote:
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
LGTM,
Incase you plan to take it via another tree.
Acked-by: Srinivas Kandagatla
--srini
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
[Intel-gfx] [PATCH v4 02/21] dma-buf: Add unlocked variant of attachment-mapping functions
Add unlocked variant of dma_buf_map/unmap_attachment() that will
be used by drivers that don't take the reservation lock explicitly.
Acked-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 53 +++
include/linux/dma-buf.h | 6 +
2 files changed, 59 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5e4459bb1a6f..51fb69048853 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1099,6 +1099,34 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment, DMA_BUF);
+/**
+ * dma_buf_map_attachment_unlocked - Returns the scatterlist table of the
attachment;
+ * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
+ * dma_buf_ops.
+ * @attach:[in]attachment whose scatterlist is to be returned
+ * @direction: [in]direction of DMA transfer
+ *
+ * Unlocked variant of dma_buf_map_attachment().
+ */
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction)
+{
+ struct sg_table *sg_table;
+
+ might_sleep();
+
+ if (WARN_ON(!attach || !attach->dmabuf))
+ return ERR_PTR(-EINVAL);
+
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+ sg_table = dma_buf_map_attachment(attach, direction);
+ dma_resv_unlock(attach->dmabuf->resv);
+
+ return sg_table;
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_map_attachment_unlocked, DMA_BUF);
+
/**
* dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might
* deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
@@ -1135,6 +1163,31 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
}
EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
+/**
+ * dma_buf_unmap_attachment_unlocked - unmaps and decreases usecount of the
buffer;might
+ * deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
+ * dma_buf_ops.
+ * @attach:[in]attachment to unmap buffer from
+ * @sg_table: [in]scatterlist info of the buffer to unmap
+ * @direction: [in]direction of DMA transfer
+ *
+ * Unlocked variant of dma_buf_unmap_attachment().
+ */
+void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
+ struct sg_table *sg_table,
+ enum dma_data_direction direction)
+{
+ might_sleep();
+
+ if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
+ return;
+
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+ dma_buf_unmap_attachment(attach, sg_table, direction);
+ dma_resv_unlock(attach->dmabuf->resv);
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, DMA_BUF);
+
/**
* dma_buf_move_notify - notify attachments that DMA-buf is moving
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 8daa054dd7fe..f11b5bbc2f37 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -627,6 +627,12 @@ int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
+ enum dma_data_direction direction);
+void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
+ struct sg_table *sg_table,
+ enum dma_data_direction direction);
int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
--
2.37.2
[Intel-gfx] [PATCH v4 08/21] drm/tegra: Prepare to dynamic dma-buf locking specification
Prepare Tegra DRM driver to the common dynamic dma-buf locking convention
by starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 81991090adcc..b09b8ab40ae4 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -84,7 +84,7 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
goto free;
}
- map->sgt = dma_buf_map_attachment(map->attach, direction);
+ map->sgt = dma_buf_map_attachment_unlocked(map->attach,
direction);
if (IS_ERR(map->sgt)) {
dma_buf_detach(buf, map->attach);
err = PTR_ERR(map->sgt);
@@ -160,7 +160,8 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
static void tegra_bo_unpin(struct host1x_bo_mapping *map)
{
if (map->attach) {
- dma_buf_unmap_attachment(map->attach, map->sgt, map->direction);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->sgt,
+ map->direction);
dma_buf_detach(map->attach->dmabuf, map->attach);
} else {
dma_unmap_sgtable(map->dev, map->sgt, map->direction, 0);
@@ -181,7 +182,7 @@ static void *tegra_bo_mmap(struct host1x_bo *bo)
if (obj->vaddr) {
return obj->vaddr;
} else if (obj->gem.import_attach) {
- ret = dma_buf_vmap(obj->gem.import_attach->dmabuf, &map);
+ ret = dma_buf_vmap_unlocked(obj->gem.import_attach->dmabuf,
&map);
return ret ? NULL : map.vaddr;
} else {
return vmap(obj->pages, obj->num_pages, VM_MAP,
@@ -197,7 +198,7 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void
*addr)
if (obj->vaddr)
return;
else if (obj->gem.import_attach)
- dma_buf_vunmap(obj->gem.import_attach->dmabuf, &map);
+ dma_buf_vunmap_unlocked(obj->gem.import_attach->dmabuf, &map);
else
vunmap(addr);
}
@@ -461,7 +462,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device
*drm,
get_dma_buf(buf);
- bo->sgt = dma_buf_map_attachment(attach, DMA_TO_DEVICE);
+ bo->sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
if (IS_ERR(bo->sgt)) {
err = PTR_ERR(bo->sgt);
goto detach;
@@ -479,7 +480,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device
*drm,
detach:
if (!IS_ERR_OR_NULL(bo->sgt))
- dma_buf_unmap_attachment(attach, bo->sgt, DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(attach, bo->sgt,
DMA_TO_DEVICE);
dma_buf_detach(buf, attach);
dma_buf_put(buf);
@@ -508,8 +509,8 @@ void tegra_bo_free_object(struct drm_gem_object *gem)
tegra_bo_iommu_unmap(tegra, bo);
if (gem->import_attach) {
- dma_buf_unmap_attachment(gem->import_attach, bo->sgt,
-DMA_TO_DEVICE);
+ dma_buf_unmap_attachment_unlocked(gem->import_attach, bo->sgt,
+ DMA_TO_DEVICE);
drm_prime_gem_destroy(gem, NULL);
} else {
tegra_bo_free(gem->dev, bo);
--
2.37.2
[Intel-gfx] [PATCH v4 11/21] misc: fastrpc: Prepare to dynamic dma-buf locking specification
Prepare fastrpc to the common dynamic dma-buf locking convention by
starting to use the unlocked versions of dma-buf API functions.
Signed-off-by: Dmitry Osipenko
---
drivers/misc/fastrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 93ebd174d848..6fcfb2e9f7a7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -310,8 +310,8 @@ static void fastrpc_free_map(struct kref *ref)
return;
}
}
- dma_buf_unmap_attachment(map->attach, map->table,
-DMA_BIDIRECTIONAL);
+ dma_buf_unmap_attachment_unlocked(map->attach, map->table,
+ DMA_BIDIRECTIONAL);
dma_buf_detach(map->buf, map->attach);
dma_buf_put(map->buf);
}
@@ -726,7 +726,7 @@ static int fastrpc_map_create(struct fastrpc_user *fl, int
fd,
goto attach_err;
}
- map->table = dma_buf_map_attachment(map->attach, DMA_BIDIRECTIONAL);
+ map->table = dma_buf_map_attachment_unlocked(map->attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(map->table)) {
err = PTR_ERR(map->table);
goto map_err;
--
2.37.2
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
Resent the mail for the former letter contains html text.
Regards,
Zheng Wang
Zheng Hacker 于2022年9月5日周一 12:47写道：
> Hello everyone,
>
> I'm Zheng Wang. I found a potential double-free bug
> in drivers/gpu/drm/i915/gvt/gtt.c. I haven't been replied for a long time.
> So I decided to send it to more relavent supporters and developers to help
> to solve the problem.
>
> Best regards,
> Zheng Wang.
>
> xmzyshypnc <1002992...@qq.com> 于2022年9月4日周日 20:32写道：
>
>> There is a double-free security bug in split_2MB_gtt_entry.
>>
>> Here is a calling chain :
>> ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. If
>> intel_gvt_dma_map_guest_page failed, it will call ppgtt_invalidate_spt,
>> which will finally call ppgtt_free_spt and kfree(spt). But the caller does
>> not notice that, and it will call ppgtt_free_spt again in error path.
>>
>> Fix this by returning the result of ppgtt_invalidate_spt to
>> split_2MB_gtt_entry.
>>
>> Signed-off-by: Zheng Wang <1002992...@qq.com>
>> ---
>> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c
>> b/drivers/gpu/drm/i915/gvt/gtt.c
>> index ce0eb03709c3..9f14fded8c0c 100644
>> --- a/drivers/gpu/drm/i915/gvt/gtt.c
>> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
>> @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu
>> *vgpu,
>> ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
>> sub_index,
>>PAGE_SIZE, &dma_addr);
>> if (ret) {
>> - ppgtt_invalidate_spt(spt);
>> + ret = ppgtt_invalidate_spt(spt);
>> return ret;
>> }
>> sub_se.val64 = se->val64;
>> --
>> 2.25.1
>>
>>
Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
Hi everyone,
Now the letter is really plain-text now :)
Thanks Greg
Regards,
Zheng Wang
Zheng Hacker 于2022年9月5日周一 12:47写道：
>
> Hello everyone,
>
> I'm Zheng Wang. I found a potential double-free bug in
> drivers/gpu/drm/i915/gvt/gtt.c. I haven't been replied for a long time. So I
> decided to send it to more relavent supporters and developers to help to
> solve the problem.
>
> Best regards,
> Zheng Wang.
>
> xmzyshypnc <1002992...@qq.com> 于2022年9月4日周日 20:32写道：
>>
>> There is a double-free security bug in split_2MB_gtt_entry.
>>
>> Here is a calling chain :
>> ppgtt_populate_spt->ppgtt_populate_shadow_entry->split_2MB_gtt_entry. If
>> intel_gvt_dma_map_guest_page failed, it will call ppgtt_invalidate_spt,
>> which will finally call ppgtt_free_spt and kfree(spt). But the caller does
>> not notice that, and it will call ppgtt_free_spt again in error path.
>>
>> Fix this by returning the result of ppgtt_invalidate_spt to
>> split_2MB_gtt_entry.
>>
>> Signed-off-by: Zheng Wang <1002992...@qq.com>
>> ---
>> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
>> index ce0eb03709c3..9f14fded8c0c 100644
>> --- a/drivers/gpu/drm/i915/gvt/gtt.c
>> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
>> @@ -1215,7 +1215,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
>> ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn +
>> sub_index,
>>PAGE_SIZE, &dma_addr);
>> if (ret) {
>> - ppgtt_invalidate_spt(spt);
>> + ret = ppgtt_invalidate_spt(spt);
>> return ret;
>> }
>> sub_se.val64 = se->val64;
>> --
>> 2.25.1
>>
Re: [Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements
Den 29.08.2022 15.11, skrev Maxime Ripard: > Hi, > > > > Here's a series aiming at improving the command line named modes support, > > and more importantly how we deal with all the analog TV variants. > > > > The named modes support were initially introduced to allow to specify the > > analog TV mode to be used. > > > > However, this was causing multiple issues: > > > > * The mode name parsed on the command line was passed directly to the > > driver, which had to figure out which mode it was suppose to match; > > > > * Figuring that out wasn't really easy, since the video= argument or what > > the userspace might not even have a name in the first place, but > > instead could have passed a mode with the same timings; > > > > * The fallback to matching on the timings was mostly working as long as > > we were supporting one 525 lines (most likely NSTC) and one 625 lines > > (PAL), but couldn't differentiate between two modes with the same > > timings (NTSC vs PAL-M vs NSTC-J for example); > > > > * There was also some overlap with the tv mode property registered by > > drm_mode_create_tv_properties(), but named modes weren't interacting > > with that property at all. > > > > * Even though that property was generic, its possible values were > > specific to each drivers, which made some generic support difficult. > > > > Thus, I chose to tackle in multiple steps: > > > > * A new TV norm property was introduced, with generic values, each driver > > reporting through a bitmask what standard it supports to the userspace; > > > > * This option was added to the command line parsing code to be able to > > specify it on the kernel command line, and new atomic_check and reset > > helpers were created to integrate properly into atomic KMS; > > > > * The named mode parsing code is now creating a proper display mode for > > the given named mode, and the TV standard will thus be part of the > > connector state; > > > > * Two drivers were converted and tested for now (vc4 and sun4i), with > > some backward compatibility code to translate the old TV mode to the > > new TV mode; > > > > Unit tests were created along the way. > > > > One can switch from NTSC to PAL now using (on vc4) > > > > modetest -M vc4 -s 53:720x480i -w 53:'tv norm':0 > > > > modetest -M vc4 -s 53:720x480i -w 53:'tv norm':4 > The property name has changed, this gives me PAL: $ modetest -M vc4 -s 45:720x576i -w 45:'TV mode':4 I have finally found a workaround for my kernel hangs. Dom had a look at my kernel and found that the VideoCore was fine, and he said this: > That suggests cause of lockup was on arm side rather than VC side. > > But it's hard to diagnose further. Once you've had a peripheral not > respond, the AXI bus locks up and no further operations are possible. > Usual causes of this are required clocks being stopped or domains > disabled and then trying to access the hardware. > So when I got this on my 64-bit build: [ 166.702171] SError Interrupt on CPU1, code 0xbf02 -- SError [ 166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: GW 5.19.0-rc6-00096-gba7973977976-dirty #1 [ 166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) [ 166.702206] Workqueue: events_freezable_power_ thermal_zone_device_check [ 166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 166.702242] pc : regmap_mmio_read32le+0x10/0x28 [ 166.702261] lr : regmap_mmio_read+0x44/0x70 ... [ 166.702606] bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal] I wondered if that reg read was stalled due to a clock being stopped. Lo and behold, disabling runtime pm and keeping the vec clock running all the time fixed it[1]. I don't know what the problem is, but at least I can now test this patchset. [1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065 Noralf.
Re: [Intel-gfx] [PATCH v2 24/41] drm/vc4: vec: Remove empty mode_fixup
Den 29.08.2022 15.11, skrev Maxime Ripard: > The mode_fixup hooks are deprecated, and the behaviour we implement is the > > default one anyway. Let's remove it. > > > > Signed-off-by: Maxime Ripard > Reviewed-by: Noralf Trønnes
Re: [Intel-gfx] [PATCH v2 09/41] drm/connector: Add TV standard property
Den 29.08.2022 15.11, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
>
> current TV mode output on an analog TV connector.
>
>
>
> Despite that property name being generic, its content isn't and has been
>
> driver-specific which makes it hard to build any generic behaviour on top
>
> of it, both in kernel and user-space.
>
>
>
> Let's create a new bitmask tv norm property, that can contain any of the
>
> analog TV standards currently supported by kernel drivers. Each driver can
>
> then pass in a bitmask of the modes it supports.
>
>
>
> We'll then be able to phase out the older tv mode property.
>
>
>
> Signed-off-by: Maxime Ripard
>
>
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> +/**
>
> + * drm_mode_create_tv_properties - create TV specific connector properties
>
> + * @dev: DRM device
>
> + * @supported_tv_modes: Bitmask of TV modes supported (See
> DRM_MODE_TV_MODE_*)
>
> +
>
> + * Called by a driver's TV initialization routine, this function creates
>
> + * the TV specific connector properties for a given device. Caller is
>
> + * responsible for allocating a list of format names and passing them to
>
> + * this routine.
>
> + *
>
> + * Returns:
>
> + * 0 on success or a negative error code on failure.
>
> + */
>
> +int drm_mode_create_tv_properties(struct drm_device *dev,
>
> + unsigned int supported_tv_modes)
>
> +{
>
> + struct drm_prop_enum_list tv_mode_list[DRM_MODE_TV_MODE_MAX];
>
> + struct drm_property *tv_mode;
>
> + unsigned int i, len = 0;
>
> +
>
Can you add a check here like in the legacy version:
if (dev->mode_config.tv_mode_property)
return 0;
This way it's possible to call this multiple times. Like in drm/gud
during connector init if there are multiple TV connectors or if a device
with multiple IP blocks should show up.
Noralf.
> + for (i = 0; i < DRM_MODE_TV_MODE_MAX; i++) {
>
> + if (!(supported_tv_modes & BIT(i)))
>
> + continue;
>
> +
>
> + tv_mode_list[len].type = i;
>
> + tv_mode_list[len].name = drm_get_tv_mode_name(i);
>
> + len++;
>
> + }
>
> +
>
> + tv_mode = drm_property_create_enum(dev, 0, "TV mode",
>
> +tv_mode_list, len);
>
> + if (!tv_mode)
>
> + return -ENOMEM;
>
> +
>
> + dev->mode_config.tv_mode_property = tv_mode;
>
> +
>
> + return drm_mode_create_tv_properties_legacy(dev, 0, NULL);
>
> +}
>
> +EXPORT_SYMBOL(drm_mode_create_tv_properties);
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, Sep 06, 2022 at 03:27:17PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
> > > drm_dp_atomic_find_vcpi_slots no longer exists and needs
> > > to be used as drm_dp_atomic_find_time_slots.
> > > Also rename the function itself.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to
> > > separate function")
> >
> > The problem only exists in drm-tip. You need to revert the
> > bad merge from rerere-cache and redo it.
> >
> > And please always test build drm-tip after solving merge conflicts!
>
> I would really like to figure out how it did end like that.
>
> Here is the sequence of what I've been doing:
>
> 1) There was a series supposed to be merged which had this new
>change already in place i.e using drm_dp_atomic_find_time_slots.
> 2) Then using dim tools I started pushing according to workflow:
>a) dim update-branches
>b) dim checkout drm-intel-next
>c) wget those series mbox and run dim apply-branch drm-intel-next
> Got conflict: it was complaining about those changes around
> drm_dp_atomic_find_time_slots and after some checking I figured
> out that drm_dp_atomic_find_time_slots doesn't exist anymore.
> Here probably was my bad, as I wrongly assumed that those changes
> were probably reverted as it was also mentioned, that there was
> regression because of those.
>
> So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
> back instead of drm_dp_atomic_find_time_slots _and_ actually
> built it even.
>
>d) I run dim push-branch drm-intel-next, it did complain about merge
> conflict again with drm-intel-next which I fixed and results were
> pushed.
> I should have build at this moment as well probably.
Yes. You didn't resolve the conflict correctly, thus the build failure.
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry.
== Series Details == Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. URL : https://patchwork.freedesktop.org/series/108188/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/108188/revisions/1/mbox/ not applied Applying: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. error: patch failed: drivers/gpu/drm/i915/gvt/gtt.c:1215 error: drivers/gpu/drm/i915/gvt/gtt.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. hint: Use 'git am --show-current-patch=diff' to see the failed patch Using index info to reconstruct a base tree... Patch failed at 0001 drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.BAT: success for Move all drivers to a common dma-buf locking convention
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/108187/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12074 -> Patchwork_108187v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/index.html
Participating hosts (44 -> 41)
--
Additional (1): fi-icl-u2
Missing(4): fi-cml-u2 fi-bsw-nick fi-bdw-samus bat-dg2-8
Known issues
Here are the changes found in Patchwork_108187v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][3] -> [DMESG-FAIL][4] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4103])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2: NOTRUN -> [WARN][10] ([i915#6008])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][12] ([i915#3555])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-icl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#2403] /
[i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][15] ([i915#5134]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- {bat-rplp-1}: [INCOMPLETE][17] ([i915#6690]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/bat-rplp-1/igt@i915_selftest@l...@requests.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/bat-rplp-1/igt@i915_selftest@l...@requests.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][19] ([fdo#103375]) -> [INCOMPLETE][20]
([i915#5982])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/fi-r
Re: [Intel-gfx] [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into mmio_debug_{suspend, resume}
>-Original Message-
>From: dri-devel On Behalf Of
>Matt Roper
>Sent: Friday, September 2, 2022 7:33 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
>
>Subject: [PATCH v2 01/12] drm/i915: Move locking and unclaimed check into
>mmio_debug_{suspend, resume}
>
>Moving the locking for MMIO debug (and the final check for unclaimed
>accesses when resuming debug after a userspace-initiated forcewake) will
>make it simpler to completely skip MMIO debug handling on uncores that
>don't support it in future patches.
>
>Signed-off-by: Matt Roper
>Reviewed-by: Radhakrishna Sripada
>---
> drivers/gpu/drm/i915/intel_uncore.c | 41 +++--
> 1 file changed, 21 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>b/drivers/gpu/drm/i915/intel_uncore.c
>index 9b81b2543ce2..e717ea55484a 100644
>--- a/drivers/gpu/drm/i915/intel_uncore.c
>+++ b/drivers/gpu/drm/i915/intel_uncore.c
>@@ -50,23 +50,33 @@ intel_uncore_mmio_debug_init_early(struct
>intel_uncore_mmio_debug *mmio_debug)
> mmio_debug->unclaimed_mmio_check = 1;
> }
>
>-static void mmio_debug_suspend(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static void mmio_debug_suspend(struct intel_uncore *uncore)
/bike-shedding...
It seems like there has been a tend to name functions with the
_unlocked
postfix when the lock is being taken within the function.
Would this be a reasonable name update for these changes?
M
> {
>- lockdep_assert_held(&mmio_debug->lock);
>+ spin_lock(&uncore->debug->lock);
>
> /* Save and disable mmio debugging for the user bypass */
>- if (!mmio_debug->suspend_count++) {
>- mmio_debug->saved_mmio_check = mmio_debug-
>>unclaimed_mmio_check;
>- mmio_debug->unclaimed_mmio_check = 0;
>+ if (!uncore->debug->suspend_count++) {
>+ uncore->debug->saved_mmio_check = uncore->debug-
>>unclaimed_mmio_check;
>+ uncore->debug->unclaimed_mmio_check = 0;
> }
>+
>+ spin_unlock(&uncore->debug->lock);
> }
>
>-static void mmio_debug_resume(struct intel_uncore_mmio_debug
>*mmio_debug)
>+static bool check_for_unclaimed_mmio(struct intel_uncore *uncore);
>+
>+static void mmio_debug_resume(struct intel_uncore *uncore)
> {
>- lockdep_assert_held(&mmio_debug->lock);
>+ spin_lock(&uncore->debug->lock);
>+
>+ if (!--uncore->debug->suspend_count)
>+ uncore->debug->unclaimed_mmio_check = uncore->debug-
>>saved_mmio_check;
>
>- if (!--mmio_debug->suspend_count)
>- mmio_debug->unclaimed_mmio_check = mmio_debug-
>>saved_mmio_check;
>+ if (check_for_unclaimed_mmio(uncore))
>+ drm_info(&uncore->i915->drm,
>+ "Invalid mmio detected during user access\n");
>+
>+ spin_unlock(&uncore->debug->lock);
> }
>
> static const char * const forcewake_domain_names[] = {
>@@ -677,9 +687,7 @@ void intel_uncore_forcewake_user_get(struct
>intel_uncore *uncore)
> spin_lock_irq(&uncore->lock);
> if (!uncore->user_forcewake_count++) {
> intel_uncore_forcewake_get__locked(uncore,
>FORCEWAKE_ALL);
>- spin_lock(&uncore->debug->lock);
>- mmio_debug_suspend(uncore->debug);
>- spin_unlock(&uncore->debug->lock);
>+ mmio_debug_suspend(uncore);
> }
> spin_unlock_irq(&uncore->lock);
> }
>@@ -695,14 +703,7 @@ void intel_uncore_forcewake_user_put(struct
>intel_uncore *uncore)
> {
> spin_lock_irq(&uncore->lock);
> if (!--uncore->user_forcewake_count) {
>- spin_lock(&uncore->debug->lock);
>- mmio_debug_resume(uncore->debug);
>-
>- if (check_for_unclaimed_mmio(uncore))
>- drm_info(&uncore->i915->drm,
>- "Invalid mmio detected during user
>access\n");
>- spin_unlock(&uncore->debug->lock);
>-
>+ mmio_debug_resume(uncore);
> intel_uncore_forcewake_put__locked(uncore,
>FORCEWAKE_ALL);
> }
> spin_unlock_irq(&uncore->lock);
>--
>2.37.2
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On 06.09.2022 13:22, Ville Syrjälä wrote: On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: On 05.09.2022 19:44, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: On 05.09.2022 13:48, Ville Syrjälä wrote: On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: In case of ICL and older generations disabling plane and/or disabling async update is always performed on vblank, It should only be broken on bdw-glk (see. need_async_flip_disable_wa). On CFL it is reported every drmtip run: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html ... On APL it is less frequent, probably due to other bugs preventing run of this test, last seen at: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html Similar for SKL: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html I am not sure if I correctly read the docs but [1] says that 9th bit of PLANE_CFG (Async Address Update Enable) is "not double buffered and the changes will apply immediately" only for ICL, JSL, LKF1. It got broken in bdw and fixed again in icl. So the change is not necessary in case of icl_plane_disable_arm. [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 but if async update is enabled PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF when plane is still enabled can cause DMAR/PIPE errors. On the other side PLANE_SURF is used to arm plane registers - we need to write to it to trigger update on VBLANK, writting current value should be safe - the buffer address is valid till vblank. I think you're effectively saying that somehow the async flip disable w/a is not kicking in sometimes. I was not aware of existence of this w/a and I am little lost in figuring out how this w/a can prevent zeroing PLANE_SURF too early. When it works as designed it should: 1. turn off the async flip bit 2. wait for vblank so that gets latched 3. do the sync plane update/disable normally After debugging this terra incognita, I've figured out that plane states are not populated in intel_crtc_async_flip_disable_wa so for_each_old_intel_plane_in_state does not iterate over affected planes and w/a does not work at all. I have no idea where affected plane states should be added. Adding them to the beginning of intel_atomic_check helped, but this is just blind shot: @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device *dev, new_crtc_state->uapi.mode_changed = true; if (new_crtc_state->uapi.scaling_filter != old_crtc_state->uapi.scaling_filter) new_crtc_state->uapi.mode_changed = true; + + ret = intel_atomic_add_affected_planes(state, crtc); + if (ret) + goto fail; } intel_vrr_check_modeset(state); ret = drm_atomic_helper_check_modeset(dev, &state->base); ^ This guy should be adding them for any crtc that has been flagged for modeset ahead of time. For modesets flagged later we have to add them by hand (eg. in intel_modeset_all_pipes()). This is no-modeset scenario, drm_atomic_helper_check_modeset does not add planes in this case. Btw, tested your warns from another mail, none appeared. Regards Andrzej For normal plane updates the relevant planes are already added when the property values are updated. Let me know if there is better place/way to handle it. Regards Andrzej
Re: [Intel-gfx] [PATCH 5/5] drm/i915: split out i915_gem.c declarations to i915_gem.h
On Mon, 05 Sep 2022, Tvrtko Ursulin wrote: > On 05/09/2022 16:00, Jani Nikula wrote: >> +/* FIXME: All of the below belong somewhere else. */ > > For the series: > > Reviewed-by: Tvrtko Ursulin Thanks, pushed to drm-intel-next. > ((( > I think historically i915_gem.h started as a stash for random bits which > felt obviously wrong to put elsewhere, but it should be fine to > "upgrade" it to a more important status now that you are working on > cleaning things up, especially i915_drv.h. > > Where this "somewhere else" place could be is a bit tricky - I suspect > there isn't any great urgency to re-home them. If one day splitting > i915_gem.c into functional parts comes on the agenda so I guess then. > But it's not that huge even so don't think it's top priority. > ))) Mostly it's a bunch of debug/trace helpers that perhaps shouldn't have been called GEM_ anything to begin with. i915_debug.h? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Prepare more multi-GT initialization
On Fri, Sep 02, 2022 at 04:52:57PM -0700, Ashutosh Dixit wrote:
> From: Matt Roper
>
> We're going to introduce an additional intel_gt for MTL's media unit
> soon. Let's provide a bit more multi-GT initialization framework in
> preparation for that. The initialization will pull the list of GTs for
> a platform from the device info structure. Although necessary for the
> immediate MTL media enabling, this same framework will also be used
> farther down the road when we enable remote tiles on xehpsdv and pvc.
>
> v2:
> - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all().
>
> Cc: Aravind Iddamsetty
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c| 54 ---
> drivers/gpu/drm/i915/gt/intel_gt.h| 1 -
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_device_info.h | 16 ++
> .../gpu/drm/i915/selftests/mock_gem_device.c | 1 +
> 7 files changed, 70 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 275ad72940c1..41acc285e8bf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -736,7 +736,7 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
> u16 vdbox_mask;
> u16 vebox_mask;
>
> - info->engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> + GEM_BUG_ON(!info->engine_mask);
>
> if (GRAPHICS_VER(i915) < 11)
> return info->engine_mask;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index e4bac2431e41..5b4263c708cc 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -815,20 +815,16 @@ static void
> intel_gt_tile_cleanup(struct intel_gt *gt)
> {
> intel_uncore_cleanup_mmio(gt->uncore);
> -
> - if (!gt_is_root(gt)) {
> - kfree(gt->uncore->debug);
> - kfree(gt->uncore);
> - kfree(gt);
> - }
In this patch I see less free...
> }
>
> int intel_gt_probe_all(struct drm_i915_private *i915)
> {
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> struct intel_gt *gt = &i915->gt0;
> + const struct intel_gt_definition *gtdef;
> phys_addr_t phys_addr;
> unsigned int mmio_bar;
> + unsigned int i;
> int ret;
>
> mmio_bar = GRAPHICS_VER(i915) == 2 ? GEN2_GTTMMADR_BAR : GTTMMADR_BAR;
> @@ -839,14 +835,58 @@ int intel_gt_probe_all(struct drm_i915_private *i915)
>* and it has been already initialized early during probe
>* in i915_driver_probe()
>*/
> + gt->i915 = i915;
> + gt->name = "Primary GT";
> + gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
> +
> + drm_dbg(&i915->drm, "Setting up %s\n", gt->name);
> ret = intel_gt_tile_setup(gt, phys_addr);
> if (ret)
> return ret;
>
> i915->gt[0] = gt;
>
> - /* TODO: add more tiles */
> + if (!HAS_EXTRA_GT_LIST(i915))
> + return 0;
> +
> + for (i = 1, gtdef = &INTEL_INFO(i915)->extra_gt_list[i - 1];
> + gtdef->setup != NULL;
> + i++, gtdef = &INTEL_INFO(i915)->extra_gt_list[i - 1]) {
> + gt = drmm_kzalloc(&i915->drm, sizeof(*gt), GFP_KERNEL);
... and more allocs...
it probably deserves some smaller patches with some explanations?
or something is indeed missing here?
> + if (!gt) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + gt->i915 = i915;
> + gt->name = gtdef->name;
> + gt->type = gtdef->type;
> + gt->info.engine_mask = gtdef->engine_mask;
> + gt->info.id = i;
> +
> + drm_dbg(&i915->drm, "Setting up %s\n", gt->name);
> + if (GEM_WARN_ON(range_overflows_t(resource_size_t,
> + gtdef->mapping_base,
> + SZ_16M,
> + pci_resource_len(pdev,
> mmio_bar {
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);
> + if (ret)
> + goto err;
> +
> + i915->gt[i] = gt;
> + }
> +
> return 0;
> +
> +err:
> + i915_probe_error(i915, "Failed to initialize %s! (%d)\n", gtdef->name,
> ret);
> + intel_gt_release_all(i915);
> +
> + return ret;
> }
>
> int intel_gt_tiles_init(struct drm_i915_private *i915)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 40b06adf509a..4d8779529cc2 100644
> --- a/d
Re: [Intel-gfx] [PATCH 4/6] drm/i915/debugfs: Add perf_limit_reasons in debugfs
On Fri, Sep 02, 2022 at 04:53:00PM -0700, Ashutosh Dixit wrote:
> From: Tilak Tangudu
>
> Add perf_limit_reasons in debugfs. Unlike the lower 16 perf_limit_reasons
> status bits, the upper 16 log bits remain set until cleared, thereby
> ensuring the throttling occurrence is not missed. The clear fop clears
> the upper 16 log bits, the get fop gets all 32 log and status bits.
>
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 27 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 108b9e76c32e..5c95cba5e5df 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -655,6 +655,32 @@ static bool rps_eval(void *data)
>
> DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
>
> +static int perf_limit_reasons_get(void *data, u64 *val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + *val = intel_uncore_read(gt->uncore, GT0_PERF_LIMIT_REASONS);
> +
> + return 0;
> +}
> +
> +static int perf_limit_reasons_clear(void *data, u64 val)
> +{
> + struct intel_gt *gt = data;
> + intel_wakeref_t wakeref;
> +
> + /* Clear the upper 16 log bits, the lower 16 status bits are read-only
> */
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + intel_uncore_rmw(gt->uncore, GT0_PERF_LIMIT_REASONS,
> + GT0_PERF_LIMIT_REASONS_LOG_MASK, 0);
> +
> + return 0;
> +}
> +DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> + perf_limit_reasons_clear, "%llu\n");
> +
> void intel_gt_pm_debugfs_register(struct intel_gt *gt, struct dentry *root)
> {
> static const struct intel_gt_debugfs_file files[] = {
> @@ -664,6 +690,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> { "forcewake_user", &forcewake_user_fops, NULL},
> { "llc", &llc_fops, llc_eval },
> { "rps_boost", &rps_boost_fops, rps_eval },
> + { "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
> };
>
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5e6239864c35..10126995e1f6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1802,6 +1802,7 @@
> #define POWER_LIMIT_4_MASK REG_BIT(9)
> #define POWER_LIMIT_1_MASK REG_BIT(11)
> #define POWER_LIMIT_2_MASK REG_BIT(12)
> +#define GT0_PERF_LIMIT_REASONS_LOG_MASK REG_GENMASK(31, 16)
Is this valid for all platforms?
What does the bits are really telling us?
Could we expand the reasons? The previous bits we know exactly
what kind of limits we are dealing of, but with this combined
one without any explanation I'm afraid this will bring more
confusion than help. We will get bugged by many folks trying
to debug this out there when bit 13, for instance, is set.
"What does bit 13 mean?" will be a recurrent question with
only a tribal knowledge kind of answer.
>
> #define CHV_CLK_CTL1 _MMIO(0x101100)
> #define VLV_CLK_CTL2 _MMIO(0x101104)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > >> > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > On 05.09.2022 13:48, Ville Syrjälä wrote: > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > >> In case of ICL and older generations disabling plane and/or disabling > >> async update is always performed on vblank, > > It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > On CFL it is reported every drmtip run: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > ... > On APL it is less frequent, probably due to other bugs preventing run of > this test, last seen at: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > Similar for SKL: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > I am not sure if I correctly read the docs but [1] says that 9th bit of > PLANE_CFG (Async Address Update Enable) is "not double buffered and the > changes will apply immediately" only for ICL, JSL, LKF1. > >>> It got broken in bdw and fixed again in icl. > >>> > So the change is not necessary in case of icl_plane_disable_arm. > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > >> but if async update is enabled > >> PLANE_SURF register is updated asynchronously. Writing 0 to PLANE_SURF > >> when plane is still enabled can cause DMAR/PIPE errors. > >> On the other side PLANE_SURF is used to arm plane registers - we need > >> to > >> write to it to trigger update on VBLANK, writting current value should > >> be safe - the buffer address is valid till vblank. > > I think you're effectively saying that somehow the async > > flip disable w/a is not kicking in sometimes. > I was not aware of existence of this w/a and I am little lost in > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > >>> When it works as designed it should: > >>> 1. turn off the async flip bit > >>> 2. wait for vblank so that gets latched > >>> 3. do the sync plane update/disable normally > >> After debugging this terra incognita, I've figured out that plane states > >> are not populated in intel_crtc_async_flip_disable_wa > >> so for_each_old_intel_plane_in_state does not iterate over affected > >> planes and w/a does not work at all. > >> I have no idea where affected plane states should be added. > >> Adding them to the beginning of intel_atomic_check helped, but this is > >> just blind shot: > >> > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > >> *dev, > >> new_crtc_state->uapi.mode_changed = true; > >> > >> if (new_crtc_state->uapi.scaling_filter != > >> old_crtc_state->uapi.scaling_filter) > >> new_crtc_state->uapi.mode_changed = true; > >> + > >> + ret = intel_atomic_add_affected_planes(state, crtc); > >> + if (ret) > >> + goto fail; > >> } > >> > >> intel_vrr_check_modeset(state); > >> > >> ret = drm_atomic_helper_check_modeset(dev, &state->base); > >^ > > This guy should be adding them for any crtc that has been flagged > > for modeset ahead of time. For modesets flagged later we have to > > add them by hand (eg. in intel_modeset_all_pipes()). > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > add planes in this case. Then he mystery is how intel_crtc_async_flip_disable_wa() manages to not disable async flip for some planes... -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915: Fix intel_dp_atomic_find_vcpi_slots function
On Tue, 06 Sep 2022, "Lisovskiy, Stanislav"
wrote:
> On Tue, Sep 06, 2022 at 02:57:34PM +0300, Ville Syrjälä wrote:
>> On Tue, Sep 06, 2022 at 01:23:29PM +0300, Stanislav Lisovskiy wrote:
>> > drm_dp_atomic_find_vcpi_slots no longer exists and needs
>> > to be used as drm_dp_atomic_find_time_slots.
>> > Also rename the function itself.
>> >
>> > Signed-off-by: Stanislav Lisovskiy
>> > Fixes: 7ae5ab441402 ("Extract drm_dp_atomic_find_vcpi_slots cycle to
>> > separate function")
>>
>> The problem only exists in drm-tip. You need to revert the
>> bad merge from rerere-cache and redo it.
>>
>> And please always test build drm-tip after solving merge conflicts!
>
> I would really like to figure out how it did end like that.
>
> Here is the sequence of what I've been doing:
>
> 1) There was a series supposed to be merged which had this new
>change already in place i.e using drm_dp_atomic_find_time_slots.
> 2) Then using dim tools I started pushing according to workflow:
>a) dim update-branches
>b) dim checkout drm-intel-next
>c) wget those series mbox and run dim apply-branch drm-intel-next
> Got conflict: it was complaining about those changes around
> drm_dp_atomic_find_time_slots and after some checking I figured
> out that drm_dp_atomic_find_time_slots doesn't exist anymore.
> Here probably was my bad, as I wrongly assumed that those changes
> were probably reverted as it was also mentioned, that there was
> regression because of those.
>
> So I resolved this conflict by putting drm_dp_atomic_find_vcpi_slots
> back instead of drm_dp_atomic_find_time_slots _and_ actually
> built it even.
The rule of thumb is, don't resolve conflicts while applying
patches. Apply the patches as they were posted to the mailing list.
If your patches apply to drm-tip but not to drm-intel-next, you'll know
there's stuff in other branches that affect the lines. You'll end up
with problems both at patch apply and drm-tip rebuild if you don't get
the baseline right first.
>From the committer guidelines:
* As a general rule, do not modify the patches while applying, apart from the
commit message. If the patch conflicts, or needs to be changed due to review,
have the author rebase, update and resend. Any change at this stage is a
potential issue bypassing CI.
BR,
Jani.
>
>d) I run dim push-branch drm-intel-next, it did complain about merge
> conflict again with drm-intel-next which I fixed and results were
> pushed.
> I should have build at this moment as well probably.
>
> Then I noticed that this function drm_dp_atomic_find_vcpi_slots
> doesn't exist in drm. So basically patches should have been pushed
> as they were initially, but why the conflict appeared initially - that
> is my
> question.
>
> Stan
>
>>
>> --
>> Ville Syrjälä
>> Intel
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode
On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
With GuC mode of submission, GuC is in control of defining the context id field
that is part of the OA reports. To filter reports, UMD and KMD must know what sw
context id was chosen by GuC. There is not interface between KMD and GuC to
determine this, so read the upper-dword of EXECLIST_STATUS to filter/squash OA
reports for the specific context.
Signed-off-by: Umesh Nerlige Ramappa
I assume you checked with GuC that this doesn't change as the context is
running?
With i915/execlist submission mode, we had to ask i915 to pin the
sw_id/ctx_id.
If that's not the case then filtering is broken.
-Lionel
---
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +
drivers/gpu/drm/i915/i915_perf.c| 141
2 files changed, 124 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index a390f0813c8b..7111bae759f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -110,6 +110,8 @@ enum {
#define XEHP_SW_CTX_ID_WIDTH 16
#define XEHP_SW_COUNTER_SHIFT 58
#define XEHP_SW_COUNTER_WIDTH 6
+#define GEN12_GUC_SW_CTX_ID_SHIFT 39
+#define GEN12_GUC_SW_CTX_ID_WIDTH 16
static inline void lrc_runtime_start(struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f3c23fe9ad9c..735244a3aedd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1233,6 +1233,125 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
return stream->pinned_ctx;
}
+static int
+__store_reg_to_mem(struct i915_request *rq, i915_reg_t reg, u32 ggtt_offset)
+{
+ u32 *cs, cmd;
+
+ cmd = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ if (GRAPHICS_VER(rq->engine->i915) >= 8)
+ cmd++;
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = cmd;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = ggtt_offset;
+ *cs++ = 0;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+static int
+__read_reg(struct intel_context *ce, i915_reg_t reg, u32 ggtt_offset)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+
+ err = __store_reg_to_mem(rq, reg, ggtt_offset);
+
+ i915_request_add(rq);
+ if (!err && i915_request_wait(rq, 0, HZ / 2) < 0)
+ err = -ETIME;
+
+ i915_request_put(rq);
+
+ return err;
+}
+
+static int
+gen12_guc_sw_ctx_id(struct intel_context *ce, u32 *ctx_id)
+{
+ struct i915_vma *scratch;
+ u32 *val;
+ int err;
+
+ scratch =
__vm_create_scratch_for_read_pinned(&ce->engine->gt->ggtt->vm, 4);
+ if (IS_ERR(scratch))
+ return PTR_ERR(scratch);
+
+ err = i915_vma_sync(scratch);
+ if (err)
+ goto err_scratch;
+
+ err = __read_reg(ce, RING_EXECLIST_STATUS_HI(ce->engine->mmio_base),
+i915_ggtt_offset(scratch));
+ if (err)
+ goto err_scratch;
+
+ val = i915_gem_object_pin_map_unlocked(scratch->obj, I915_MAP_WB);
+ if (IS_ERR(val)) {
+ err = PTR_ERR(val);
+ goto err_scratch;
+ }
+
+ *ctx_id = *val;
+ i915_gem_object_unpin_map(scratch->obj);
+
+err_scratch:
+ i915_vma_unpin_and_release(&scratch, 0);
+ return err;
+}
+
+/*
+ * For execlist mode of submission, pick an unused context id
+ * 0 - (NUM_CONTEXT_TAG -1) are used by other contexts
+ * XXX_MAX_CONTEXT_HW_ID is used by idle context
+ *
+ * For GuC mode of submission read context id from the upper dword of the
+ * EXECLIST_STATUS register.
+ */
+static int gen12_get_render_context_id(struct i915_perf_stream *stream)
+{
+ u32 ctx_id, mask;
+ int ret;
+
+ if (intel_engine_uses_guc(stream->engine)) {
+ ret = gen12_guc_sw_ctx_id(stream->pinned_ctx, &ctx_id);
+ if (ret)
+ return ret;
+
+ mask = ((1U << GEN12_GUC_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN12_GUC_SW_CTX_ID_SHIFT - 32);
+ } else if (GRAPHICS_VER_FULL(stream->engine->i915) >= IP_VER(12, 50)) {
+ ctx_id = (XEHP_MAX_CONTEXT_HW_ID - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << XEHP_SW_CTX_ID_WIDTH) - 1) <<
+ (XEHP_SW_CTX_ID_SHIFT - 32);
+ } else {
+ ctx_id = (GEN12_MAX_CONTEXT_HW_ID - 1) <<
+(GEN11_SW_CTX_ID_SHIFT - 32);
+
+ mask = ((1U << GEN11_SW_CTX_ID_WIDTH) - 1) <<
+ (GEN11_SW_CTX_ID_SHIFT - 32);
+
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Mon, 05 Sep 2022, Stanislav Lisovskiy wrote: > Adding DP DSC register definitions, we might need for further > DSC implementation, supporting MST and DP branch pass-through mode. > > v2: - Fixed checkpatch comment warning > v3: - Removed function which is not yet used(Jani Nikula) > > Reviewed-by: Vinod Govindapillai > > Signed-off-by: Stanislav Lisovskiy Maarten, Maxime, Thomas - So this got pushed to drm-intel-next without your acks. Apologies. Can we live with it, or want a revert? BR, Jani. > --- > include/drm/display/drm_dp.h | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index 6c0871164771..02c4b6f20478 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -239,6 +239,9 @@ > > #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) > +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) > > #define DP_DSC_REV 0x061 > # define DP_DSC_MAJOR_MASK (0xf << 0) > @@ -277,12 +280,15 @@ > > #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) > > #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) > # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 > +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 > +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 > > #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > # define DP_DSC_RGB (1 << 0) > @@ -344,11 +350,13 @@ > # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) > > #define DP_DSC_BITS_PER_PIXEL_INC 0x06F > +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f > +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 > # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 > # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 > # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > -# define DP_DSC_BITS_PER_PIXEL_10x4 > +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 > > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote: > On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > >> > > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > > On 05.09.2022 13:48, Ville Syrjälä wrote: > > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > > >> In case of ICL and older generations disabling plane and/or disabling > > >> async update is always performed on vblank, > > > It should only be broken on bdw-glk (see. need_async_flip_disable_wa). > > On CFL it is reported every drmtip run: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > ... > > On APL it is less frequent, probably due to other bugs preventing run > > of > > this test, last seen at: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > Similar for SKL: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > > I am not sure if I correctly read the docs but [1] says that 9th bit of > > PLANE_CFG (Async Address Update Enable) is "not double buffered and the > > changes will apply immediately" only for ICL, JSL, LKF1. > > >>> It got broken in bdw and fixed again in icl. > > >>> > > So the change is not necessary in case of icl_plane_disable_arm. > > > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > > >> but if async update is enabled > > >> PLANE_SURF register is updated asynchronously. Writing 0 to > > >> PLANE_SURF > > >> when plane is still enabled can cause DMAR/PIPE errors. > > >> On the other side PLANE_SURF is used to arm plane registers - we > > >> need to > > >> write to it to trigger update on VBLANK, writting current value > > >> should > > >> be safe - the buffer address is valid till vblank. > > > I think you're effectively saying that somehow the async > > > flip disable w/a is not kicking in sometimes. > > I was not aware of existence of this w/a and I am little lost in > > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > >>> When it works as designed it should: > > >>> 1. turn off the async flip bit > > >>> 2. wait for vblank so that gets latched > > >>> 3. do the sync plane update/disable normally > > >> After debugging this terra incognita, I've figured out that plane states > > >> are not populated in intel_crtc_async_flip_disable_wa > > >> so for_each_old_intel_plane_in_state does not iterate over affected > > >> planes and w/a does not work at all. > > >> I have no idea where affected plane states should be added. > > >> Adding them to the beginning of intel_atomic_check helped, but this is > > >> just blind shot: > > >> > > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > > >> *dev, > > >> new_crtc_state->uapi.mode_changed = true; > > >> > > >> if (new_crtc_state->uapi.scaling_filter != > > >> old_crtc_state->uapi.scaling_filter) > > >> new_crtc_state->uapi.mode_changed = true; > > >> + > > >> + ret = intel_atomic_add_affected_planes(state, crtc); > > >> + if (ret) > > >> + goto fail; > > >> } > > >> > > >> intel_vrr_check_modeset(state); > > >> > > >> ret = drm_atomic_helper_check_modeset(dev, &state->base); > > >^ > > > This guy should be adding them for any crtc that has been flagged > > > for modeset ahead of time. For modesets flagged later we have to > > > add them by hand (eg. in intel_modeset_all_pipes()). > > > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > > add planes in this case. > > Then he mystery is how intel_crtc_async_flip_disable_wa() manages > to not disable async flip for some planes... After a few minutes of pondering I have a theory: 1. async flip on plane 1 crtc_state.*async_flip: false -> true 2. sync flip on plane 2, plane 1 not include in state crtc_state.*async_flip:
Re: [Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.
On Tue, 06 Sep 2022, Jani Nikula wrote: > On Mon, 05 Sep 2022, Stanislav Lisovskiy > wrote: >> Adding DP DSC register definitions, we might need for further >> DSC implementation, supporting MST and DP branch pass-through mode. >> >> v2: - Fixed checkpatch comment warning >> v3: - Removed function which is not yet used(Jani Nikula) >> >> Reviewed-by: Vinod Govindapillai >> >> Signed-off-by: Stanislav Lisovskiy > > Maarten, Maxime, Thomas - > > So this got pushed to drm-intel-next without your acks. Apologies. Can > we live with it, or want a revert? I think dim should've warned about missing acks, did it not? :( BR, Jani. > > > BR, > Jani. > > >> --- >> include/drm/display/drm_dp.h | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h >> index 6c0871164771..02c4b6f20478 100644 >> --- a/include/drm/display/drm_dp.h >> +++ b/include/drm/display/drm_dp.h >> @@ -239,6 +239,9 @@ >> >> #define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ >> # define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_PASS_THROUGH_IS_SUPPORTED (1 << 1) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_COMP_TO_COMP(1 << 2) >> +# define DP_DSC_DYNAMIC_PPS_UPDATE_SUPPORT_UNCOMP_TO_COMP (1 << 3) >> >> #define DP_DSC_REV 0x061 >> # define DP_DSC_MAJOR_MASK (0xf << 0) >> @@ -277,12 +280,15 @@ >> >> #define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 >> # define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) >> +# define DP_DSC_RGB_COLOR_CONV_BYPASS_SUPPORT (1 << 1) >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ >> >> #define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK (0x3 << 0) >> # define DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT 8 >> +# define DP_DSC_MAX_BPP_DELTA_VERSION_MASK 0x06 >> +# define DP_DSC_MAX_BPP_DELTA_AVAILABILITY 0x08 >> >> #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 >> # define DP_DSC_RGB (1 << 0) >> @@ -344,11 +350,13 @@ >> # define DP_DSC_24_PER_DP_DSC_SINK (1 << 2) >> >> #define DP_DSC_BITS_PER_PIXEL_INC 0x06F >> +# define DP_DSC_RGB_YCbCr444_MAX_BPP_DELTA_MASK 0x1f >> +# define DP_DSC_RGB_YCbCr420_MAX_BPP_DELTA_MASK 0xe0 >> # define DP_DSC_BITS_PER_PIXEL_1_16 0x0 >> # define DP_DSC_BITS_PER_PIXEL_1_8 0x1 >> # define DP_DSC_BITS_PER_PIXEL_1_4 0x2 >> # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 >> -# define DP_DSC_BITS_PER_PIXEL_10x4 >> +# define DP_DSC_BITS_PER_PIXEL_1_1 0x4 >> >> #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ >> # define DP_PSR_IS_SUPPORTED1 -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: do not reset PLANE_SURF on plane disable on older gens
On Tue, Sep 06, 2022 at 05:36:05PM +0300, Ville Syrjälä wrote: > On Tue, Sep 06, 2022 at 05:14:56PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 06, 2022 at 03:57:37PM +0200, Andrzej Hajda wrote: > > > > > > > > > On 06.09.2022 13:22, Ville Syrjälä wrote: > > > > On Tue, Sep 06, 2022 at 01:09:16PM +0200, Andrzej Hajda wrote: > > > >> > > > >> On 05.09.2022 19:44, Ville Syrjälä wrote: > > > >>> On Mon, Sep 05, 2022 at 07:02:40PM +0200, Andrzej Hajda wrote: > > > On 05.09.2022 13:48, Ville Syrjälä wrote: > > > > On Mon, Sep 05, 2022 at 10:05:00AM +0200, Andrzej Hajda wrote: > > > >> In case of ICL and older generations disabling plane and/or > > > >> disabling > > > >> async update is always performed on vblank, > > > > It should only be broken on bdw-glk (see. > > > > need_async_flip_disable_wa). > > > On CFL it is reported every drmtip run: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?testfilter=tiled-max-hw > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html#dmesg-warnings402 > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html#dmesg-warnings402 > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1209/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1208/fi-cfl-8109u/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > ... > > > On APL it is less frequent, probably due to other bugs preventing > > > run of > > > this test, last seen at: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1190/fi-apl-guc/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html > > > Similar for SKL: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1181/fi-skl-guc/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html > > > > > > I am not sure if I correctly read the docs but [1] says that 9th bit > > > of > > > PLANE_CFG (Async Address Update Enable) is "not double buffered and > > > the > > > changes will apply immediately" only for ICL, JSL, LKF1. > > > >>> It got broken in bdw and fixed again in icl. > > > >>> > > > So the change is not necessary in case of icl_plane_disable_arm. > > > > > > [1]: https://gfxspecs.intel.com/Predator/Home/Index/7656 > > > >> but if async update is enabled > > > >> PLANE_SURF register is updated asynchronously. Writing 0 to > > > >> PLANE_SURF > > > >> when plane is still enabled can cause DMAR/PIPE errors. > > > >> On the other side PLANE_SURF is used to arm plane registers - we > > > >> need to > > > >> write to it to trigger update on VBLANK, writting current value > > > >> should > > > >> be safe - the buffer address is valid till vblank. > > > > I think you're effectively saying that somehow the async > > > > flip disable w/a is not kicking in sometimes. > > > I was not aware of existence of this w/a and I am little lost in > > > figuring out how this w/a can prevent zeroing PLANE_SURF too early. > > > >>> When it works as designed it should: > > > >>> 1. turn off the async flip bit > > > >>> 2. wait for vblank so that gets latched > > > >>> 3. do the sync plane update/disable normally > > > >> After debugging this terra incognita, I've figured out that plane > > > >> states > > > >> are not populated in intel_crtc_async_flip_disable_wa > > > >> so for_each_old_intel_plane_in_state does not iterate over affected > > > >> planes and w/a does not work at all. > > > >> I have no idea where affected plane states should be added. > > > >> Adding them to the beginning of intel_atomic_check helped, but this is > > > >> just blind shot: > > > >> > > > >> @@ -6778,10 +6778,14 @@ static int intel_atomic_check(struct drm_device > > > >> *dev, > > > >> new_crtc_state->uapi.mode_changed = true; > > > >> > > > >> if (new_crtc_state->uapi.scaling_filter != > > > >> old_crtc_state->uapi.scaling_filter) > > > >> new_crtc_state->uapi.mode_changed = true; > > > >> + > > > >> + ret = intel_atomic_add_affected_planes(state, crtc); > > > >> + if (ret) > > > >> + goto fail; > > > >> } > > > >> > > > >> intel_vrr_check_modeset(state); > > > >> > > > >> ret = drm_atomic_helper_check_modeset(dev, &state->base); > > > >^ > > > > This guy should be adding them for any crtc that has been flagged > > > > for modeset ahead of time. For modesets flagged later we have to > > > > add them by hand (eg. in intel_modeset_all_pipes()). > > > > > > This is no-modeset scenario, drm_atomic_helper_check_modeset does not > > > add planes in this case. > > > > Then he myster
[Intel-gfx] ✓ Fi.CI.IGT: success for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/108187/ State : success == Summary == CI Bug Log - changes from CI_DRM_12074_full -> Patchwork_108187v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 11) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_108187v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [FAIL][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk3/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12074/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk3/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/shard-glk6/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108187v1/sh
