Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
(I missed this review you did before I had sent a v2.1, I will incorporate
what is missing in the next version)
On Mon, Jan 23, 2023 at 12:38:28PM +0200, Jani Nikula wrote:
On Fri, 20 Jan 2023, Lucas De Marchi wrote:
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
1) It increases the code size since the array is declared
in each call site
Would be interesting to see what this does, and whether the compiler has
the smarts to combine these within each file:
-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+#define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])
if the compiler is smart, it would be at least 1 per compilation unit.
gcc doesn't seem smart enough to even compile it though:
../drivers/gpu/drm/i915/i915_reg_defs.h:155:52: error: expected ‘)’ before ‘{’ token
155 | #define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])
| ~ ^
What I'm thinking for the remaining uses of _PICK() is to be explicit
and statically define them in a good .c depending on the use.
Then use that in the macro.
2) Developers need to be careful not to incur an
out-of-bounds array access
3) Developers need to be careful that the indexes match the
table. For that it may be that the table needs to contain
holes, making (1) even worse.
Add a variant of _PICK_EVEN() that works with 2 ranges and selects which
one to use depending on the index value.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg_defs.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
b/drivers/gpu/drm/i915/i915_reg_defs.h
index be43580a6979..b7ec87464d69 100644
--- a/drivers/gpu/drm/i915/i915_reg_defs.h
+++ b/drivers/gpu/drm/i915/i915_reg_defs.h
@@ -119,6 +119,34 @@
*/
#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
+/*
+ * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
+ * The first range is used for indexes below @__c_index, and the second
+ * range is used for anything above it. Example::
I'd like this to be clear about which range is used for index ==
__c_index, instead of saying "below" and "above".
No need for the double colon :: because this isn't a kernel-doc comment.
ok, what about this?
* Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
* @__c_index corresponds to the index in which the second range starts
* to be used. Using math interval notation, the first range is used
* for indexes [ 0, @__c_index), while the second range is used for
* [ @__c_index, ... ). Example:
+ *
+ * #define _FOO_A 0xf000
+ * #define _FOO_B 0xf004
+ * #define _FOO_C 0xf008
+ * #define _SUPER_FOO_A0xa000
+ * #define _SUPER_FOO_B0xa100
+ * #define FOO(x) _MMIO(_PICK_EVEN_RANGES(x, 3,
\
The example uses a different name for the macro.
yeah, that was the previous name I was using... good catch, will fix.
+ * _FOO_A, _FOO_B,
\
+ * _SUPER_FOO_A, _SUPER_FOO_B))
+ *
+ * This expands to:
+ * 0: 0xf000,
+ * 1: 0xf004,
+ * 2: 0xf008,
+ * 3: 0xa100,
With the above definitions, this would be 3: 0xa000.
fixed
thanks
Lucas De Marchi
+ * 4: 0xa200,
+ * 5: 0xa300,
+ * ...
+ */
+#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d)
\
+ (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) +
\
+((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : \
+ _PICK_EVEN((__index) - (__c_index), __c,
__d)))
+
/*
* Given the arbitrary numbers in varargs, pick the 0-based __index'th number.
*
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Implement workaround for CDCLK PLL disable/enable
On Mon, Jan 23, 2023 at 02:52:37PM -0500, Rodrigo Vivi wrote:
> On Mon, Jan 23, 2023 at 03:16:11PM +0200, Stanislav Lisovskiy wrote:
> > It was reported that we might get a hung and loss of register access in
> > some cases when CDCLK PLL is disabled and then enabled, while squashing
> > is enabled.
> > As a workaround it was proposed by HW team that SW should disable squashing
> > when CDCLK PLL is being reenabled.
>
> What's the WA lineage for this WA?
Not sure, what you mean but HSD is: 14017300873
Stan
>
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 0c107a38f9d0..e338f288c9ac 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1801,6 +1801,13 @@ static bool
> > cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
> > return true;
> > }
> >
> > +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
> > +{
> > + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> > + && dev_priv->display.cdclk.hw.vco > 0
> > + && HAS_CDCLK_SQUASH(dev_priv));
> > +}
> > +
> > static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> >const struct intel_cdclk_config *cdclk_config,
> >enum pipe pipe)
> > @@ -1815,9 +1822,12 @@ static void _bxt_set_cdclk(struct drm_i915_private
> > *dev_priv,
> > !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
> > if (dev_priv->display.cdclk.hw.vco != vco)
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > - } else if (DISPLAY_VER(dev_priv) >= 11)
> > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > + if (pll_enable_wa_needed(dev_priv))
> > + dg2_cdclk_squash_program(dev_priv, 0);
> > +
> > icl_cdclk_pll_update(dev_priv, vco);
> > - else
> > + } else
> > bxt_cdclk_pll_update(dev_priv, vco);
> >
> > waveform = cdclk_squash_waveform(dev_priv, cdclk);
> > --
> > 2.37.3
> >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
== Series Details ==
Series: drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
URL : https://patchwork.freedesktop.org/series/113251/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12625_full -> Patchwork_113251v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/index.html
Participating hosts (12 -> 11)
--
Additional (1): shard-rkl0
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113251v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@ctrl-surf-copy:
- {shard-rkl}:[SKIP][1] ([i915#3555] / [i915#5325]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-3/igt@gem_...@ctrl-surf-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_...@ctrl-surf-copy.html
* igt@gem_ccs@suspend-resume:
- {shard-rkl}:[SKIP][3] ([i915#5325]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-2/igt@gem_...@suspend-resume.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_...@suspend-resume.html
Known issues
Here are the changes found in Patchwork_113251v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][9] ([i915#5784]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-dg1-16/igt@gem_...@reset-stress.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-dg1-15/igt@gem_...@reset-stress.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][11] ([i915#7052]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-3/igt@gem_...@suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][13] ([i915#2846]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-glk8/igt@gem_exec_f...@basic-deadline.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-4/igt@gem_exec_fair@basic-none-...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_exec_fair@basic-none-...@rcs0.html
- shard-glk: [FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-glk6/igt@gem_exec_fair@basic-none-...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +12 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-2/igt@gem_exec_re...@basic-wc-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_set_tiling_vs_pwrite:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +3 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-3/igt@gem_set_tiling_vs_pwrite.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/shard-rkl-5/igt@gem_set_tiling_vs_pwrite.html
* igt@gen9_exec_parse@valid-registers:
- {shard-rkl}:[SKIP][23] ([i915#2527]) -> [PASS][24] +4 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/shard-rkl-4/igt@gen9_exec_pa...@valid-registers.html
[24]:
https://intel-gfx-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
== Series Details ==
Series: drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
URL : https://patchwork.freedesktop.org/series/113251/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12625 -> Patchwork_113251v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/index.html
Participating hosts (39 -> 39)
--
Additional (1): fi-tgl-dsi
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113251v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-dsi}: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/fi-tgl-dsi/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_113251v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([i915#7828])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/fi-rkl-guc/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][3] -> [FAIL][4] ([i915#6298])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [INCOMPLETE][5] ([i915#4983]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-2}: [DMESG-FAIL][7] ([i915#7059]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/bat-rpls-2/igt@i915_selftest@live@gt_mocs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/bat-rpls-2/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][9] -> [PASS][10] +4 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@requests:
- {bat-rplp-1}: [INCOMPLETE][11] ([i915#7609]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12625/bat-rplp-1/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113251v1/bat-rplp-1/igt@i915_selftest@l...@requests.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7059]: https://gitlab.freedesktop.org/drm/intel/issues/7059
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7
[Intel-gfx] [PATCH v6 5/6] drm/i915/pxp: Trigger the global teardown for before suspending
A driver bug was recently discovered where the security firmware was
receiving internal HW signals indicating that session key expirations
had occurred. Architecturally, the firmware was expecting a response
from the GuC to acknowledge the event with the firmware side.
However the OS was in a suspended state and GuC had been reset.
Internal specifications actually required the driver to ensure
that all active sessions be properly cleaned up in such cases where
the system is suspended and the GuC potentially unable to respond.
This patch adds the global teardown code in i915's suspend_prepare
code path.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 65 +---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++
5 files changed, 66 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index cfc9af8b3d21..9d4c7724e98e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -270,6 +270,60 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
return bound;
}
+static int __pxp_global_teardown_final(struct intel_pxp *pxp)
+{
+ if (!pxp->arb_is_valid)
+ return 0;
+ /*
+* To ensure synchronous and coherent session teardown completion
+* in response to suspend or shutdown triggers, don't use a worker.
+*/
+ intel_pxp_mark_termination_in_progress(pxp);
+ intel_pxp_terminate(pxp, false);
+
+ if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(250)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
+{
+ if (pxp->arb_is_valid)
+ return 0;
+ /*
+* The arb-session is currently inactive and we are doing a reset and
restart
+* due to a runtime event. Use the worker that was designed for this.
+*/
+ pxp_queue_termination(pxp);
+
+ if (!wait_for_completion_timeout(&pxp->termination,
msecs_to_jiffies(250)))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+void intel_pxp_end(struct intel_pxp *pxp)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ intel_wakeref_t wakeref;
+
+ if (!intel_pxp_is_enabled(pxp))
+ return;
+
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ mutex_lock(&pxp->arb_mutex);
+
+ if (__pxp_global_teardown_final(pxp))
+ drm_dbg(&i915->drm, "PXP end timed out\n");
+
+ mutex_unlock(&pxp->arb_mutex);
+
+ intel_pxp_fini_hw(pxp);
+ intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+}
+
/*
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
@@ -286,16 +340,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
mutex_lock(&pxp->arb_mutex);
- if (pxp->arb_is_valid)
- goto unlock;
-
- pxp_queue_termination(pxp);
-
- if (!wait_for_completion_timeout(&pxp->termination,
- msecs_to_jiffies(250))) {
- ret = -ETIMEDOUT;
+ ret = __pxp_global_teardown_restart(pxp);
+ if (ret)
goto unlock;
- }
/* make sure the compiler doesn't optimize the double access */
barrier();
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 9658d3005222..3ded0890cd27 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -27,6 +27,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
+void intel_pxp_end(struct intel_pxp *pxp);
int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..e427464aa131 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -16,7 +16,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return;
- pxp->arb_is_valid = false;
+ intel_pxp_end(pxp);
intel_pxp_invalidate(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 74ed7e16e481..448cacb0465d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -115,11 +115,11 @@ static int pxp_terminate_arb_session_and_global(struct
intel_pxp *pxp)
return
[Intel-gfx] [PATCH v6 3/6] mei: clean pending read with vtag on bus
From: Alexander Usyskin
Client on bus have only one vtag map slot and should disregard the vtag
value when cleaning pending read flag.
Fixes read flow control message unexpectedly generated when
clent on bus send messages with different vtags.
Signed-off-by: Alexander Usyskin
Reviewed-by: Tomas Winkler
---
drivers/misc/mei/client.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9ddb854b8155..5c19097266fe 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1343,7 +1343,9 @@ static void mei_cl_reset_read_by_vtag(const struct mei_cl
*cl, u8 vtag)
struct mei_cl_vtag *vtag_l;
list_for_each_entry(vtag_l, &cl->vtag_map, list) {
- if (vtag_l->vtag == vtag) {
+ /* The client on bus has one fixed vtag map */
+ if ((cl->cldev && mei_cldev_enabled(cl->cldev)) ||
+ vtag_l->vtag == vtag) {
vtag_l->pending_read = false;
break;
}
--
2.39.0
[Intel-gfx] [PATCH v6 6/6] drm/i915/pxp: Pxp hw init should be in resume_complete
During suspend flow, i915 currently achors' on the pm_suspend_prepare
callback as the location where we quiesce the entire GPU and perform
all necessary cleanup in order to go into suspend. PXP is also called
during this time to perform the arbitration session teardown (with
the assurance no additional GEM IOCTLs will come after that could
restart the session).
However, if other devices or drivers fail their suspend_prepare, the
system will not go into suspend and i915 will be expected to resume
operation. In this case, we need to re-initialize the PXP hardware
and this really should be done within the pm_resume_complete callback
which is the correct opposing function in the resume sequence to
match pm_suspend_prepare of the suspend sequence.
Because this callback is the last thing at the end of resuming
we expect little to no impact to the rest of the i915 resume sequence
with this change.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
Acked-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +++---
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 6469c7c1e154..122736b48938 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1167,6 +1167,13 @@ static bool suspend_to_idle(struct drm_i915_private
*dev_priv)
return false;
}
+static void i915_drm_complete(struct drm_device *dev)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+
+ intel_pxp_resume_complete(i915->pxp);
+}
+
static int i915_drm_prepare(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
@@ -1367,8 +1374,6 @@ static int i915_drm_resume(struct drm_device *dev)
i915_gem_resume(dev_priv);
- intel_pxp_resume(dev_priv->pxp);
-
intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
intel_hpd_init(dev_priv);
@@ -1560,6 +1565,16 @@ static int i915_pm_resume(struct device *kdev)
return i915_drm_resume(&i915->drm);
}
+static void i915_pm_complete(struct device *kdev)
+{
+ struct drm_i915_private *i915 = kdev_to_i915(kdev);
+
+ if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF)
+ return;
+
+ i915_drm_complete(&i915->drm);
+}
+
/* freeze: before creating the hibernation_image */
static int i915_pm_freeze(struct device *kdev)
{
@@ -1780,6 +1795,7 @@ const struct dev_pm_ops i915_pm_ops = {
.suspend_late = i915_pm_suspend_late,
.resume_early = i915_pm_resume_early,
.resume = i915_pm_resume,
+ .complete = i915_pm_complete,
/*
* S4 event handlers
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index e427464aa131..4f836b317424 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -34,7 +34,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
}
}
-void intel_pxp_resume(struct intel_pxp *pxp)
+void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
if (!intel_pxp_is_enabled(pxp))
return;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
index 586be769104f..06b46f535b42 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
@@ -11,7 +11,7 @@ struct intel_pxp;
#ifdef CONFIG_DRM_I915_PXP
void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
void intel_pxp_suspend(struct intel_pxp *pxp);
-void intel_pxp_resume(struct intel_pxp *pxp);
+void intel_pxp_resume_complete(struct intel_pxp *pxp);
void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
#else
static inline void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
@@ -22,7 +22,7 @@ static inline void intel_pxp_suspend(struct intel_pxp *pxp)
{
}
-static inline void intel_pxp_resume(struct intel_pxp *pxp)
+static inline void intel_pxp_resume_complete(struct intel_pxp *pxp)
{
}
@@ -32,6 +32,6 @@ static inline void intel_pxp_runtime_suspend(struct intel_pxp
*pxp)
#endif
static inline void intel_pxp_runtime_resume(struct intel_pxp *pxp)
{
- intel_pxp_resume(pxp);
+ intel_pxp_resume_complete(pxp);
}
#endif /* __INTEL_PXP_PM_H__ */
--
2.39.0
[Intel-gfx] [PATCH v6 1/6] mei: mei-me: resume device in prepare
From: Alexander Usyskin
Asynchronous runtime resume is not possible while the system
is suspending.
The power management subsystem resumes the device only in the
suspend phase, not in the prepare phase.
Force resume device in prepare to allow drivers on mei bus
to communicate in their prepare callbacks.
Signed-off-by: Alexander Usyskin
Reviewed-by: Tomas Winkler
---
drivers/misc/mei/pci-me.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 5bf0d50d55a0..676d566f38dd 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -342,6 +342,12 @@ static void mei_me_remove(struct pci_dev *pdev)
}
#ifdef CONFIG_PM_SLEEP
+static int mei_me_pci_prepare(struct device *device)
+{
+ pm_runtime_resume(device);
+ return 0;
+}
+
static int mei_me_pci_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
@@ -398,7 +404,17 @@ static int mei_me_pci_resume(struct device *device)
return 0;
}
-#endif /* CONFIG_PM_SLEEP */
+
+static void mei_me_pci_complete(struct device *device)
+{
+ pm_runtime_suspend(device);
+}
+#else /* CONFIG_PM_SLEEP */
+
+#define mei_me_pci_prepare NULL
+#define mei_me_pci_complete NULL
+
+#endif /* !CONFIG_PM_SLEEP */
#ifdef CONFIG_PM
static int mei_me_pm_runtime_idle(struct device *device)
@@ -501,6 +517,8 @@ static inline void mei_me_unset_pm_domain(struct mei_device
*dev)
}
static const struct dev_pm_ops mei_me_pm_ops = {
+ .prepare = mei_me_pci_prepare,
+ .complete = mei_me_pci_complete,
SET_SYSTEM_SLEEP_PM_OPS(mei_me_pci_suspend,
mei_me_pci_resume)
SET_RUNTIME_PM_OPS(
--
2.39.0
[Intel-gfx] [PATCH v6 4/6] drm/i915/pxp: Invalidate all PXP fw sessions during teardown
A gap was recently discovered where if an application did not
invalidate all of the stream keys (intentionally or not), and the
driver did a full PXP global teardown on the GT subsystem, we
find that future session creation would fail on the security
firmware's side of the equation. i915 is the entity that needs
ensure the sessions' state across both iGT and security firmware
are at a known clean point when performing a full global teardown.
Architecturally speaking, i915 should inspect all active sessions
and submit the invalidate-stream-key PXP command to the security
firmware for each of them. However, for the upstream i915 driver
we only support the arbitration session that can be created
so that will be the only session we will cleanup.
Signed-off-by: Alan Previn
Reviewed-by: Juston Li
Acked-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 1 +
.../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15
.../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 35 +++
5 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..9658d3005222 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -24,6 +24,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32
arb_session_id);
int intel_pxp_start(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
index 739f9072fa5f..26f7d9f01bf3 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_42.h
@@ -12,6 +12,9 @@
/* PXP-Opcode for Init Session */
#define PXP42_CMDID_INIT_SESSION 0x1e
+/* PXP-Opcode for Invalidate Stream Key */
+#define PXP42_CMDID_INVALIDATE_STREAM_KEY 0x0007
+
/* PXP-Input-Packet: Init Session (Arb-Session) */
struct pxp42_create_arb_in {
struct pxp_cmd_header header;
@@ -25,4 +28,16 @@ struct pxp42_create_arb_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_in {
+ struct pxp_cmd_header header;
+ u32 rsvd[3];
+} __packed;
+
+/* PXP-Output-Packet: Invalidate Stream Key */
+struct pxp42_inv_stream_key_out {
+ struct pxp_cmd_header header;
+ u32 rsvd;
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_42_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
index aaa8187a0afb..ae9b151b7cb7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_cmn.h
@@ -28,6 +28,9 @@ struct pxp_cmd_header {
union {
u32 status; /* out */
u32 stream_id; /* in */
+#define PXP_CMDHDR_EXTDATA_SESSION_VALID GENMASK(0, 0)
+#define PXP_CMDHDR_EXTDATA_APP_TYPE GENMASK(1, 1)
+#define PXP_CMDHDR_EXTDATA_SESSION_ID GENMASK(17, 2)
};
/* Length of the message (excluding the header) */
u32 buffer_len;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index ae413580b81a..74ed7e16e481 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -110,6 +110,8 @@ static int pxp_terminate_arb_session_and_global(struct
intel_pxp *pxp)
intel_uncore_write(gt->uncore, PXP_GLOBAL_TERMINATE, 1);
+ intel_pxp_tee_end_arb_fw_session(pxp, ARB_SESSION);
+
return ret;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index cd5b86216506..aa0ad46e524b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -319,3 +319,38 @@ int intel_pxp_tee_cmd_create_arb_session(struct intel_pxp
*pxp,
return ret;
}
+
+void intel_pxp_tee_end_arb_fw_session(struct intel_pxp *pxp, u32 session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct pxp42_inv_stream_key_in msg_in = {0};
+ struct pxp42_inv_stream_key_out msg_out = {0};
+ int ret, trials = 0;
+
+try_again:
+ memset(&msg_in, 0, sizeof(msg_in));
+ memset(&msg_out, 0, sizeof(msg_out));
+ msg_in.header.api_version = PXP_APIVER(4, 2);
+ msg_in.header.command_id = PXP42_CMDID_INVALIDATE_STREAM_KEY;
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+
+ msg_in.header.stream_id = FIELD_PREP(PXP_CMDHDR_EXTDATA_SESSION_VALID,
1);
+ msg_in.header.stream_id |= FIELD_PREP(PXP_CMDHDR_
[Intel-gfx] [PATCH v6 0/6] drm/i915/pxp: Add missing cleanup steps for PXP global-teardown
A customer issue was recently discovered and in the process a gap in i915's PXP interaction with HW+FW architecure was also realized. This series adds those missing pieces. This fix includes changes where i915 calls into the mei component interface in order to submit requests to the security firmware during the i915's suspend_prepare flow. This change did expose a blocking issue in the mei component side that was discovered while testing in rev1. The issue being the mei-pxp component driver not being able to runtime-resume while being within the suspend_prepare callstack. Thus, we have now included the mei patches (from Alexander) that fixes that issue by adding a device-link based on the interface type to ensure mei side runtime resume during the i915's suspend_prepare call. That said, as per request from Alexander, we seek Greg's and Tomas' review for the mei patches (Patch 1, 2 and 3). Patch 2, although is a change in the i915 code, is the mei component device link change. The individual patches explain more details. Patch 7 can be ignored as it won't be merged and is only meant to ensure the CI run's the PXP subtests with PXP support enabled in KConfig. Changes from prior revs: v1: - Dont need to teardown non-arbitration sessions (Juston). - Fix builds when PXP is enabled in config (Alan/CI-build). - Fix the broken pm-suspend-resume symmetry when we do this pxp-session-teardown during i915s pm_suspend_prepare by ensuring the init is done during i915s pm_resume_complete. v2: - Rebase on latest drm-tip after PXP subsytem was promoted to global. - Remove "INTEL_PXP_MAX_HWDRM_SESSIONS" unneeded (Juston Li). - Added mei patches that are dependencies for this series to successfully pass testing when PXP config is enabled. v3: - Added fix for mei patch when CONFIG_PM_SLEEP is off (reported by kernel test robot ). v4: - Added "DRM_SWITCH_POWER_OFF" check and removed bail-out if '!i915' that wont happen in i915_pm_complete (Daniele). - move i915_pm_complete to appear in i915_pm_resume. - One more fix for mei patch when CONFIG_PM_SLEEP is off (reported by kernel test robot ). v5: - Reworked Patch#2 on device link establishment. Don't hide triggering device-link behind drm_WARN, return -ENODEV if it fails and stash the returned device_link struct. Alan Previn (3): drm/i915/pxp: Invalidate all PXP fw sessions during teardown drm/i915/pxp: Trigger the global teardown for before suspending drm/i915/pxp: Pxp hw init should be in resume_complete Alexander Usyskin (3): mei: mei-me: resume device in prepare drm/i915/pxp: add device link between i915 and mei_pxp mei: clean pending read with vtag on bus drivers/gpu/drm/i915/i915_driver.c| 20 +- drivers/gpu/drm/i915/pxp/intel_pxp.c | 65 --- drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 + .../drm/i915/pxp/intel_pxp_cmd_interface_42.h | 15 + .../i915/pxp/intel_pxp_cmd_interface_cmn.h| 3 + drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 6 +- drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 8 ++- drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 5 ++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 46 + drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 ++ drivers/misc/mei/client.c | 4 +- drivers/misc/mei/pci-me.c | 20 +- 13 files changed, 183 insertions(+), 21 deletions(-) base-commit: 6a023df4443d313724dc96d1fff15193bb7ec5b8 -- 2.39.0
[Intel-gfx] [PATCH v6 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
From: Alexander Usyskin
Add device link with i915 as consumer and mei_pxp as supplier
to ensure proper ordering of power flows.
V2: condition on absence of heci_pxp to filter out DG
Signed-off-by: Alexander Usyskin
---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 11 +++
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index 73aa8015f828..cd5b86216506 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -127,6 +127,12 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
intel_wakeref_t wakeref;
int ret = 0;
+ if (!HAS_HECI_PXP(i915)) {
+ pxp->component_dev_link = device_link_add(i915_kdev, tee_kdev,
DL_FLAG_STATELESS);
+ if (drm_WARN_ON(&i915->drm, !pxp->component_dev_link))
+ return -ENODEV;
+ }
+
mutex_lock(&pxp->tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
@@ -169,6 +175,11 @@ static void i915_pxp_tee_component_unbind(struct device
*i915_kdev,
mutex_lock(&pxp->tee_mutex);
pxp->pxp_component = NULL;
mutex_unlock(&pxp->tee_mutex);
+
+ if (pxp->component_dev_link) {
+ device_link_remove(i915_kdev, tee_kdev);
+ pxp->component_dev_link = NULL;
+ }
}
static const struct component_ops i915_pxp_tee_component_ops = {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
index 7dc5f08d1583..efd2f3915abe 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_types.h
@@ -32,6 +32,12 @@ struct intel_pxp {
* which are protected by &tee_mutex.
*/
struct i915_pxp_component *pxp_component;
+
+ /**
+* @component_dev_link: device link of the pxp-component enforcing i915
as the
+* consumer. This is needed for legacy platform (TGL/ADL) full-feature
usage.
+*/
+ struct device_link *component_dev_link;
/**
* @pxp_component_added: track if the pxp component has been added.
* Set and cleared in tee init and fini functions respectively.
--
2.39.0
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use uabi engines for the default engine map (rev4)
== Series Details ==
Series: drm/i915: Use uabi engines for the default engine map (rev4)
URL : https://patchwork.freedesktop.org/series/68395/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624_full -> Patchwork_68395v4_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_68395v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@block-copy-inplace:
- {shard-rkl}:[SKIP][1] ([i915#3555] / [i915#5325]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@gem_...@block-copy-inplace.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-5/igt@gem_...@block-copy-inplace.html
* igt@gem_ccs@suspend-resume:
- {shard-rkl}:[SKIP][3] ([i915#5325]) -> [SKIP][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-4/igt@gem_...@suspend-resume.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-5/igt@gem_...@suspend-resume.html
Known issues
Here are the changes found in Patchwork_68395v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#79])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2122])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a2.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][11] ([i915#3281]) -> [PASS][12] +8 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@api_intel...@object-reloc-keep-cache.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html
* igt@fbdev@write:
- {shard-rkl}:[SKIP][13] ([i915#2582]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-4/igt@fb...@write.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-6/igt@fb...@write.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- {shard-rkl}:[SKIP][17] ([i915#6252]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-1/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@gem_exec_fair@basic-none-r...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk8/igt@gem_exec_fair@basic-none-...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/shard-glk5/igt@gem_exec_fair@basic-no
[Intel-gfx] ✓ Fi.CI.IGT: success for Use unversioned blob path for ADLP DMC
== Series Details ==
Series: Use unversioned blob path for ADLP DMC
URL : https://patchwork.freedesktop.org/series/113238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624_full -> Patchwork_113238v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/index.html
Participating hosts (12 -> 11)
--
Additional (1): shard-rkl0
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113238v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@block-copy-uncompressed:
- {shard-rkl}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-rkl-5/igt@gem_...@block-copy-uncompressed.html
* igt@gem_ccs@block-multicopy-compressed:
- {shard-rkl}:[SKIP][2] ([i915#5325]) -> [SKIP][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@gem_...@block-multicopy-compressed.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-rkl-5/igt@gem_...@block-multicopy-compressed.html
Known issues
Here are the changes found in Patchwork_113238v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#5566] /
[i915#716])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2346])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2122])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
* igt@runner@aborted:
- shard-glk: NOTRUN -> [FAIL][14] ([i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-glk8/igt@run...@aborted.html
Possible fixes
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][15] ([i915#658]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-3/igt@feature_discov...@psr2.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- {shard-rkl}:[SKIP][17] ([i915#6252]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-rkl-4/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-2/igt@gem_exec_fair@basic-none-r...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][21] ([i915#3281]) -> [PASS][22] +7 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-1/igt@gem_exec_re...@basic-gtt-read-noreloc.html
[22]:
https://in
[Intel-gfx] ✓ Fi.CI.IGT: success for Add _PICK_EVEN_2RANGES (rev2)
== Series Details ==
Series: Add _PICK_EVEN_2RANGES (rev2)
URL : https://patchwork.freedesktop.org/series/113177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624_full -> Patchwork_113177v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113177v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@ctrl-surf-copy:
- {shard-rkl}:[SKIP][1] ([i915#3555] / [i915#5325]) -> [SKIP][2] +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-6/igt@gem_...@ctrl-surf-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-5/igt@gem_...@ctrl-surf-copy.html
* igt@gem_ccs@suspend-resume:
- {shard-rkl}:[SKIP][3] ([i915#5325]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-4/igt@gem_...@suspend-resume.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-5/igt@gem_...@suspend-resume.html
* igt@gem_eio@suspend:
- {shard-rkl}:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-6/igt@gem_...@suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-5/igt@gem_...@suspend.html
Known issues
Here are the changes found in Patchwork_113177v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#5334])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-glk4/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-glk1/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@info:
- {shard-rkl}:[SKIP][15] ([i915#2582]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-1/igt@fb...@info.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-6/igt@fb...@info.html
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- {shard-rkl}:[SKIP][17] ([i915#6252]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-2/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][21] ([i915#3281]) -> [PASS][22] +9 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-4/igt@gem_exec_re...@basic-wc-read-noreloc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_set_tiling_vs_pwrite:
- {shard-rkl}:[SKIP][23] ([i915#3282]) -> [PASS][24] +5 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/shard-rkl-6/igt@gem_set_tiling_vs_pwrite.html
[24]:
https://intel-gfx-ci.01.org/tree
Re: [Intel-gfx] [PATCH v7 4/6] drm/i915/hdcp: Refactor HDCP API structures
LGTM.
Reviewed-by: Ankit Nautiyal
On 1/10/2023 4:27 PM, Suraj Kandpal wrote:
It requires to move intel specific HDCP API structures to
i915_cp_fw_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h
so that any content protection fw interfaces can use these
structures.
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
---
drivers/misc/mei/hdcp/mei_hdcp.c | 44 ++--
drivers/misc/mei/hdcp/mei_hdcp.h | 354 -
include/drm/i915_hdcp_interface.h | 355 ++
3 files changed, 377 insertions(+), 376 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 0ff0bd07e385..d4faecbbbe76 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -52,7 +52,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
session_init_in.header.api_version = HDCP_API_VERSION;
session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
- session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
session_init_in.header.buffer_len =
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
@@ -75,7 +75,7 @@ mei_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
return byte;
}
- if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_INITIATE_HDCP2_SESSION,
session_init_out.header.status);
@@ -122,7 +122,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.header.api_version = HDCP_API_VERSION;
verify_rxcert_in.header.command_id = WIRED_VERIFY_RECEIVER_CERT;
- verify_rxcert_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ verify_rxcert_in.header.status = FW_HDCP_STATUS_SUCCESS;
verify_rxcert_in.header.buffer_len =
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
@@ -148,7 +148,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
return byte;
}
- if (verify_rxcert_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (verify_rxcert_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_VERIFY_RECEIVER_CERT,
verify_rxcert_out.header.status);
@@ -194,7 +194,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.api_version = HDCP_API_VERSION;
send_hprime_in.header.command_id = WIRED_AKE_SEND_HPRIME;
- send_hprime_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ send_hprime_in.header.status = FW_HDCP_STATUS_SUCCESS;
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
@@ -218,7 +218,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
return byte;
}
- if (send_hprime_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (send_hprime_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
WIRED_AKE_SEND_HPRIME, send_hprime_out.header.status);
return -EIO;
@@ -251,7 +251,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
pairing_info_in.header.api_version = HDCP_API_VERSION;
pairing_info_in.header.command_id = WIRED_AKE_SEND_PAIRING_INFO;
- pairing_info_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ pairing_info_in.header.status = FW_HDCP_STATUS_SUCCESS;
pairing_info_in.header.buffer_len =
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
@@ -276,7 +276,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct hdcp_port_data *data,
return byte;
}
- if (pairing_info_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ if (pairing_info_out.header.status != FW_HDCP_STATUS_SUCCESS) {
dev_dbg(dev, "ME cmd 0x%08X failed. Status: 0x%X\n",
WIRED_AKE_SEND_PAIRING_INFO,
pairing_info_out.header.status);
@@ -311,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.api_version = HDCP_API_VERSION;
lc_init_in.header.command_id = WIRED_INIT_LOCALITY_CHECK;
- lc_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ lc_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
Re: [Intel-gfx] [PATCH v7 3/6] i915/hdcp: HDCP2.x Refactoring to agnostic hdcp
LGTM.
Reviewed-by: Ankit Nautiyal
On 1/10/2023 4:27 PM, Suraj Kandpal wrote:
As now we have more then one type of content protection
secrity firmware. Let change the i915_cp_fw_hdcp_interface.h
header naming convention to suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev
As interface to CP FW can be either a non i915 component or
i915 intergral component, change structure name Accordingly.
%s/i915_hdcp_comp_master/i915_hdcp_master
%s/i915_hdcp_component_ops/i915_hdcp_ops
--v3
-Changing names to drop cp_fw to make naming more agnostic[Jani]
Cc: Tomas Winkler
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Ankit Nautiyal
Signed-off-by: Anshuman Gupta
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_core.h | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index de71ff6ad80a..132e9134ba05 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -15,6 +15,7 @@
#include
#include
+#include
#include "intel_cdclk.h"
#include "intel_display.h"
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 262c76f21801..0d6aed1eb171 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1409,7 +1409,7 @@ static int hdcp2_authenticate_port(struct intel_connector
*connector)
return ret;
}
-static int hdcp2_close_mei_session(struct intel_connector *connector)
+static int hdcp2_close_session(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1433,7 +1433,7 @@ static int hdcp2_close_mei_session(struct intel_connector
*connector)
static int hdcp2_deauthenticate_port(struct intel_connector *connector)
{
- return hdcp2_close_mei_session(connector);
+ return hdcp2_close_session(connector);
}
/* Authentication flow starts from here */
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: implement async_flip mode per plane tracking (rev3)
== Series Details ==
Series: drm/i915: implement async_flip mode per plane tracking (rev3)
URL : https://patchwork.freedesktop.org/series/108371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12622_full -> Patchwork_108371v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108371v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-d-ts-continuation-suspend:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-dg1-15/igt@kms_vbl...@pipe-d-ts-continuation-suspend.html
Known issues
Here are the changes found in Patchwork_108371v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][4] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_suspend@basic-s3-devices@smem:
- shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk6/igt@gem_exec_suspend@basic-s3-devi...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk8/igt@gem_exec_suspend@basic-s3-devi...@smem.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#5566] /
[i915#716])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk2/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk7/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#79]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +32 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk7/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@sysfs_clients@pidname:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2994])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-glk7/igt@sysfs_clie...@pidname.html
Possible fixes
* igt@fbdev@read:
- {shard-rkl}:[SKIP][14] ([i915#2582]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-1/igt@fb...@read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-rkl-6/igt@fb...@read.html
- {shard-tglu}: [SKIP][16] ([i915#2582]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-tglu-6/igt@fb...@read.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-tglu-1/igt@fb...@read.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][18] ([i915#6268]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- {shard-rkl}:[FAIL][20] ([i915#2842]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-6/igt@gem_exec_fair@basic-none-...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-t
Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
On Mon, 2023-01-23 at 09:31 -0500, Vivi, Rodrigo wrote:
> On Sun, Jan 22, 2023 at 06:57:24AM +, Usyskin, Alexander wrote:
> > > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > > index d50354bfb993..bef6d7f8ac55 100644
> > > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > > @@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct
> > >
alan:snip.
Thanks Jani, Rodrigo and Alex. I'll re-rev with all of Rodrigo's recommendation:
- will break down the initial code so we dont hide device-link behind
drm_WARN_ON
- since i didnt hear any hard objection - I will stick with Rodrigo's
recommendation to stash the device-link.
- dont need DL_FLAG_PM_RUNTIME
- use -ENODEV
probably like this:
if (!HAS_HECI_PXP(i915)) {
pxp->component_dev_link = device_link_add(i915_kdev, tee_kdev,
DL_FLAG_STATELESS);
if (drm_WARN_ON(&i915->drm, !pxp->component_dev_link))
return -ENODEV;
}
alan:snip.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/fb-helper: Various cleanups
== Series Details ==
Series: drm/fb-helper: Various cleanups
URL : https://patchwork.freedesktop.org/series/113220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12622_full -> Patchwork_113220v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/index.html
Participating hosts (12 -> 10)
--
Missing(2): pig-skl-6260u pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113220v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ccs@block-copy-inplace:
- {shard-rkl}:[SKIP][1] ([i915#3555] / [i915#5325]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-1/igt@gem_...@block-copy-inplace.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-rkl-5/igt@gem_...@block-copy-inplace.html
Known issues
Here are the changes found in Patchwork_113220v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk8/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: NOTRUN -> [FAIL][5] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk9/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#79]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk7/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +32 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk9/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@sysfs_clients@pidname:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2994])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk9/igt@sysfs_clie...@pidname.html
Possible fixes
* igt@drm_read@short-buffer-nonblock:
- {shard-rkl}:[SKIP][11] ([i915#4098]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-1/igt@drm_r...@short-buffer-nonblock.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-rkl-6/igt@drm_r...@short-buffer-nonblock.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][13] ([i915#658]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-1/igt@feature_discov...@psr1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18] +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-4/igt@gem_exec_fair@basic-p...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-wc-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +8 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/shard-rkl-1/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
* igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Convert PSS_MODE2 to multicast register (rev2)
On Sat, Jan 21, 2023 at 08:34:52PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gt: Convert PSS_MODE2 to multicast register (rev2)
> URL : https://patchwork.freedesktop.org/series/113159/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12618_full -> Patchwork_113159v2_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/index.html
>
> Participating hosts (12 -> 9)
> --
>
> Missing(3): shard-rkl0 pig-kbl-iris pig-skl-6260u
>
> Known issues
>
>
> Here are the changes found in Patchwork_113159v2_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@heavy-verify-multi:
> - shard-glk: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613])
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@gem_lmem_swapp...@heavy-verify-multi.html
>
> * igt@gem_userptr_blits@vma-merge:
> - shard-glk: NOTRUN -> [FAIL][2] ([i915#3318])
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@gem_userptr_bl...@vma-merge.html
>
> * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
> - shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3886]) +1
> similar issue
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
>
> * igt@kms_cdclk@mode-transition:
> - shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +46 similar
> issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@kms_cd...@mode-transition.html
>
> * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
> - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
>
> * igt@kms_dsc@dsc-with-bpc-formats:
> - shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#7205])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@kms_...@dsc-with-bpc-formats.html
>
> * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
> - shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#658])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html
>
> * igt@sysfs_clients@sema-50:
> - shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2994])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-glk7/igt@sysfs_clie...@sema-50.html
>
>
> Possible fixes
>
> * igt@drm_fdinfo@virtual-idle:
> - {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11] +1 similar
> issue
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-rkl-6/igt@drm_fdi...@virtual-idle.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
>
> * igt@drm_read@empty-block:
> - {shard-rkl}:[SKIP][12] ([i915#4098]) -> [PASS][13] +1 similar
> issue
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-rkl-3/igt@drm_r...@empty-block.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-rkl-6/igt@drm_r...@empty-block.html
>
> * igt@fbdev@info:
> - {shard-rkl}:[SKIP][14] ([i915#2582]) -> [PASS][15]
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-rkl-3/igt@fb...@info.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-rkl-6/igt@fb...@info.html
>
> * igt@gem_exec_fair@basic-pace@rcs0:
> - {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17] +2 similar
> issues
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
>
> * igt@gem_exec_reloc@basic-write-read-active:
> - {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +5 similar
> issues
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12618/shard-rkl-1/igt@gem_exec_re...@basic-write-read-active.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113159v2/shard-rkl-5/igt@gem_exec_re...@basic-write-read-active.html
>
> * igt@gem_exec_schedule@semapho
Re: [Intel-gfx] [PATCH v2 8/9] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
Thanks - will go with your suggestion - ditch all the abstraction / consolidation .. add only the two additional calls with the explicit runtime-takes - that minimizes the changes. And won't forget to the fix the '&' -> '&&' ...alan On Wed, 2023-01-18 at 18:17 -0800, Ceraolo Spurio, Daniele wrote: > > > On 1/11/2023 1:42 PM, Alan Previn wrote: > > On legacy platforms, KCR HW enabling is done at the time the mei > > component interface is bound. It's also disabled during unbind. > > However, for MTL onwards, we don't depend on the tee-component > > operation before we can start sending GSC-CS firmware messages. > > > > Thus, immediately enable KCR HW on PXP's init, fini and resume. alan:snip..
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Add GuC oriented print macros
On 1/20/2023 08:40, Michal Wajdeczko wrote: While we do have GT oriented print macros, add few more GuC specific to have common look and feel across all messages related to the GuC and to avoid chasing the gt pointer. We will use these macros shortly in upcoming patches. Signed-off-by: Michal Wajdeczko Cc: Tvrtko Ursulin Cc: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 48 1 file changed, 48 insertions(+) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_print.h diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h new file mode 100644 index ..e75989d4ba06 --- /dev/null +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h @@ -0,0 +1,48 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2023 Intel Corporation + */ + +#ifndef __INTEL_GUC_PRINT__ +#define __INTEL_GUC_PRINT__ + +#include "gt/intel_gt.h" This necessary only for the guc_to_gt() accessor? Hmm. Maybe it is worth moving that to intel_guc.h? I know Jani for one would like to see all of that cleaned up. But maybe that's a follow up patch. John. +#include "gt/intel_gt_print.h" + +#define guc_printk(_guc, _level, _fmt, ...) \ + gt_##_level(guc_to_gt(_guc), "GUC: " _fmt, ##__VA_ARGS__) + +#define guc_err(_guc, _fmt, ...) \ + guc_printk((_guc), err, _fmt, ##__VA_ARGS__) + +#define guc_warn(_guc, _fmt, ...) \ + guc_printk((_guc), warn, _fmt, ##__VA_ARGS__) + +#define guc_notice(_guc, _fmt, ...) \ + guc_printk((_guc), notice, _fmt, ##__VA_ARGS__) + +#define guc_info(_guc, _fmt, ...) \ + guc_printk((_guc), info, _fmt, ##__VA_ARGS__) + +#define guc_dbg(_guc, _fmt, ...) \ + guc_printk((_guc), dbg, _fmt, ##__VA_ARGS__) + +#define guc_err_ratelimited(_guc, _fmt, ...) \ + guc_printk((_guc), err_ratelimited, _fmt, ##__VA_ARGS__) + +#define guc_probe_error(_guc, _fmt, ...) \ + guc_printk((_guc), probe_error, _fmt, ##__VA_ARGS__) + +#define guc_WARN(_guc, _cond, _fmt, ...) \ + gt_WARN(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__) + +#define guc_WARN_ONCE(_guc, _cond, _fmt, ...) \ + gt_WARN_ONCE(guc_to_gt(_guc), _cond, "GUC: " _fmt, ##__VA_ARGS__) + +#define guc_WARN_ON(_guc, _cond) \ + gt_WARN(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON", __stringify(_cond)) + +#define guc_WARN_ON_ONCE(_guc, _cond) \ + gt_WARN_ONCE(guc_to_gt(_guc), _cond, "%s(%s)", "guc_WARN_ON_ONCE", __stringify(_cond)) + +#endif /* __INTEL_GUC_PRINT__ */
Re: [Intel-gfx] [PATCH 8/8] drm/i915/guc: Update GT/GuC messages in intel_uc.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 74 +--
1 file changed, 36 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 9a8a1abf71d7..e94f0d7119c4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -6,11 +6,13 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "gt/intel_reset.h"
#include "intel_gsc_fw.h"
#include "intel_gsc_uc.h"
#include "intel_guc.h"
#include "intel_guc_ads.h"
+#include "intel_guc_print.h"
#include "intel_guc_submission.h"
#include "gt/intel_rps.h"
#include "intel_uc.h"
@@ -67,14 +69,14 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
ret = intel_reset_guc(gt);
if (ret) {
- DRM_ERROR("Failed to reset GuC, ret = %d\n", ret);
+ gt_err(gt, "Failed to reset GuC, ret = %d\n", ret);
return ret;
}
guc_status = intel_uncore_read(gt->uncore, GUC_STATUS);
- WARN(!(guc_status & GS_MIA_IN_RESET),
-"GuC status: 0x%x, MIA core expected to be in reset\n",
-guc_status);
+ gt_WARN(gt, !(guc_status & GS_MIA_IN_RESET),
+ "GuC status: 0x%x, MIA core expected to be in reset\n",
+ guc_status);
return ret;
}
@@ -252,15 +254,13 @@ static int guc_enable_communication(struct intel_guc *guc)
intel_guc_ct_event_handler(&guc->ct);
spin_unlock_irq(gt->irq_lock);
- drm_dbg(&i915->drm, "GuC communication enabled\n");
+ guc_dbg(guc, "communication enabled\n");
return 0;
}
static void guc_disable_communication(struct intel_guc *guc)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
-
/*
* Events generated during or after CT disable are logged by guc in
* via mmio. Make sure the register is clear before disabling CT since
@@ -280,11 +280,12 @@ static void guc_disable_communication(struct intel_guc
*guc)
*/
guc_get_mmio_msg(guc);
- drm_dbg(&i915->drm, "GuC communication disabled\n");
+ guc_dbg(guc, "communication disabled\n");
}
static void __uc_fetch_firmwares(struct intel_uc *uc)
{
+ struct intel_gt *gt = uc_to_gt(uc);
int err;
GEM_BUG_ON(!intel_uc_wants_guc(uc));
@@ -293,15 +294,13 @@ static void __uc_fetch_firmwares(struct intel_uc *uc)
if (err) {
/* Make sure we transition out of transient "SELECTED" state */
if (intel_uc_wants_huc(uc)) {
- drm_dbg(&uc_to_gt(uc)->i915->drm,
- "Failed to fetch GuC: %d disabling HuC\n", err);
+ gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling
HuC\n", ERR_PTR(err));
intel_uc_fw_change_status(&uc->huc.fw,
INTEL_UC_FIRMWARE_ERROR);
}
if (intel_uc_wants_gsc_uc(uc)) {
- drm_dbg(&uc_to_gt(uc)->i915->drm,
- "Failed to fetch GuC: %d disabling GSC\n", err);
+ gt_dbg(gt, "Failed to fetch GuC fw (%pe) disabling
GSC\n", ERR_PTR(err));
intel_uc_fw_change_status(&uc->gsc.fw,
INTEL_UC_FIRMWARE_ERROR);
}
@@ -382,7 +381,7 @@ static int uc_init_wopcm(struct intel_uc *uc)
int err;
if (unlikely(!base || !size)) {
- i915_probe_error(gt->i915, "Unsuccessful WOPCM partitioning\n");
+ gt_probe_error(gt, "Unsuccessful WOPCM partitioning\n");
return -E2BIG;
}
@@ -413,13 +412,13 @@ static int uc_init_wopcm(struct intel_uc *uc)
return 0;
err_out:
- i915_probe_error(gt->i915, "Failed to init uC WOPCM registers!\n");
- i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
-i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
-intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
- i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
-i915_mmio_reg_offset(GUC_WOPCM_SIZE),
-intel_uncore_read(uncore, GUC_WOPCM_SIZE));
+ gt_probe_error(gt, "Failed to init uC WOPCM registers!\n");
+ gt_probe_error(gt, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
+ i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
+ intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+ gt_probe_error(gt, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
+ i915_mmio_reg_offset(GUC_WOPCM_SIZE),
+ intel_uncore_read(uncore, GUC_WOPCM_SIZE));
return err;
Re: [Intel-gfx] [PATCH 7/8] drm/i915/guc: Update GuC messages in intel_guc_submission.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 60 ---
1 file changed, 26 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b436dd7f12e4..bb98206304ee 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -27,6 +27,7 @@
#include "intel_guc_ads.h"
#include "intel_guc_capture.h"
+#include "intel_guc_print.h"
#include "intel_guc_submission.h"
#include "i915_drv.h"
@@ -1443,8 +1444,7 @@ static void guc_init_engine_stats(struct intel_guc *guc)
int ret = guc_action_enable_usage_stats(guc);
if (ret)
- drm_err(>->i915->drm,
- "Failed to enable usage stats: %d!\n", ret);
+ guc_err(guc, "Failed to enable usage stats: %pe\n",
ERR_PTR(ret));
}
}
@@ -3585,8 +3585,7 @@ static int guc_request_alloc(struct i915_request *rq)
intel_context_sched_disable_unpin(ce);
else if (intel_context_is_closed(ce))
if (wait_for(context_close_done(ce), 1500))
- drm_warn(&guc_to_gt(guc)->i915->drm,
-"timed out waiting on context sched close before
realloc\n");
+ guc_warn(guc, "timed out waiting on context sched close
before realloc\n");
/*
* Call pin_guc_id here rather than in the pinning step as with
* dma_resv, contexts can be repeatedly pinned / unpinned trashing the
@@ -4349,11 +4348,14 @@ static int __guc_action_set_scheduling_policies(struct
intel_guc *guc,
ret = intel_guc_send(guc, (u32 *)&policy->h2g,
__guc_scheduling_policy_action_size(policy));
- if (ret < 0)
+ if (ret < 0) {
+ guc_probe_error(guc, "Failed to configure global scheduling
policies: %pe!\n",
+ ERR_PTR(ret));
return ret;
+ }
if (ret != policy->count) {
- drm_warn(&guc_to_gt(guc)->i915->drm, "GuC global scheduler policy
processed %d of %d KLVs!",
+ guc_warn(guc, "global scheduler policy processed %d of %d
KLVs!",
ret, policy->count);
if (ret > policy->count)
return -EPROTO;
@@ -4367,7 +4369,7 @@ static int guc_init_global_schedule_policy(struct
intel_guc *guc)
struct scheduling_policy policy;
struct intel_gt *gt = guc_to_gt(guc);
intel_wakeref_t wakeref;
- int ret = 0;
+ int ret;
if (GUC_SUBMIT_VER(guc) < MAKE_GUC_VER(1, 1, 0))
return 0;
@@ -4385,10 +4387,6 @@ static int guc_init_global_schedule_policy(struct
intel_guc *guc)
yield, ARRAY_SIZE(yield));
ret = __guc_action_set_scheduling_policies(guc, &policy);
- if (ret)
- i915_probe_error(gt->i915,
-"Failed to configure global scheduling
policies: %pe!\n",
-ERR_PTR(ret));
}
return ret;
@@ -4487,21 +4485,18 @@ g2h_context_lookup(struct intel_guc *guc, u32 ctx_id)
struct intel_context *ce;
if (unlikely(ctx_id >= GUC_MAX_CONTEXT_ID)) {
- drm_err(&guc_to_gt(guc)->i915->drm,
- "Invalid ctx_id %u\n", ctx_id);
+ guc_err(guc, "Invalid ctx_id %u\n", ctx_id);
return NULL;
}
ce = __get_context(guc, ctx_id);
if (unlikely(!ce)) {
- drm_err(&guc_to_gt(guc)->i915->drm,
- "Context is NULL, ctx_id %u\n", ctx_id);
+ guc_err(guc, "Context is NULL, ctx_id %u\n", ctx_id);
return NULL;
}
if (unlikely(intel_context_is_child(ce))) {
- drm_err(&guc_to_gt(guc)->i915->drm,
- "Context is child, ctx_id %u\n", ctx_id);
+ guc_err(guc, "Context is child, ctx_id %u\n", ctx_id);
return NULL;
}
@@ -4516,7 +4511,7 @@ int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
u32 ctx_id;
if (unlikely(len < 1)) {
- drm_err(&guc_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+ guc_err(guc, "Invalid length %u\n", len);
return -EPROTO;
}
ctx_id = msg[0];
@@ -4568,7 +4563,7 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
u32 ctx_id;
if (unlikely(len < 2)) {
- drm_err(&guc_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
+ guc_err(guc, "Invalid length %u\n", len);
retu
Re: [Intel-gfx] [PATCH 6/8] drm/i915/guc: Update GuC messages in intel_guc_log.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 35 +++---
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 68331c538b0a..1d76497b783c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -12,6 +12,7 @@
#include "i915_memcpy.h"
#include "intel_guc_capture.h"
#include "intel_guc_log.h"
+#include "intel_guc_print.h"
#if defined(CONFIG_DRM_I915_DEBUG_GUC)
#define GUC_LOG_DEFAULT_CRASH_BUFFER_SIZE SZ_2M
@@ -39,7 +40,6 @@ struct guc_log_section {
static void _guc_log_init_sizes(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
static const struct guc_log_section sections[GUC_LOG_SECTIONS_LIMIT] = {
{
GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT,
@@ -82,12 +82,12 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
}
if (!IS_ALIGNED(log->sizes[i].bytes, log->sizes[i].units))
- drm_err(&i915->drm, "Mis-aligned GuC log %s size: 0x%X vs
0x%X!",
+ guc_err(guc, "Mis-aligned log %s size: 0x%X vs 0x%X!",
sections[i].name, log->sizes[i].bytes,
log->sizes[i].units);
log->sizes[i].count = log->sizes[i].bytes / log->sizes[i].units;
if (!log->sizes[i].count) {
- drm_err(&i915->drm, "Zero GuC log %s size!",
sections[i].name);
+ guc_err(guc, "Zero log %s size!", sections[i].name);
} else {
/* Size is +1 unit */
log->sizes[i].count--;
@@ -95,14 +95,14 @@ static void _guc_log_init_sizes(struct intel_guc_log *log)
/* Clip to field size */
if (log->sizes[i].count > sections[i].max) {
- drm_err(&i915->drm, "GuC log %s size too large: %d vs
%d!",
+ guc_err(guc, "log %s size too large: %d vs %d!",
sections[i].name, log->sizes[i].count + 1,
sections[i].max + 1);
log->sizes[i].count = sections[i].max;
}
}
if (log->sizes[GUC_LOG_SECTIONS_CRASH].units != log->sizes[GUC_LOG_SECTIONS_DEBUG].units) {
- drm_err(&i915->drm, "Unit mis-match for GuC log crash and debug
sections: %d vs %d!",
+ guc_err(guc, "Unit mis-match for GuC log crash and debug sections:
%d vs %d!",
-> "for log, crash and debug sections"
log->sizes[GUC_LOG_SECTIONS_CRASH].units,
log->sizes[GUC_LOG_SECTIONS_DEBUG].units);
log->sizes[GUC_LOG_SECTIONS_CRASH].units =
log->sizes[GUC_LOG_SECTIONS_DEBUG].units;
@@ -374,6 +374,7 @@ size_t intel_guc_get_log_buffer_offset(struct intel_guc_log
*log,
static void _guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log)
{
+ struct intel_guc *guc = log_to_guc(log);
unsigned int buffer_size, read_offset, write_offset, bytes_to_copy,
full_cnt;
struct guc_log_buffer_state *log_buf_state, *log_buf_snapshot_state;
struct guc_log_buffer_state log_buf_state_local;
@@ -383,7 +384,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
mutex_lock(&log->relay.lock);
- if (WARN_ON(!intel_guc_log_relay_created(log)))
+ if (guc_WARN_ON(guc, !intel_guc_log_relay_created(log)))
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
@@ -398,7 +399,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
* Used rate limited to avoid deluge of messages, logs might be
* getting consumed by User at a slow rate.
*/
- DRM_ERROR_RATELIMITED("no sub-buffer to copy general logs\n");
+ guc_err_ratelimited(guc, "no sub-buffer to copy general
logs\n");
log->relay.full_count++;
goto out_unlock;
@@ -451,7 +452,7 @@ static void _guc_log_copy_debuglogs_for_relay(struct
intel_guc_log *log)
write_offset = buffer_size;
} else if (unlikely((read_offset > buffer_size) ||
(write_offset > buffer_size))) {
- DRM_ERROR("invalid log buffer state\n");
+ guc_err(guc, "invalid log buffer state\n");
/* copy whole buffer as offsets are unreliable */
read_offset = 0;
write_offset = buffer_size;
@@ -547,7 +548,7 @@ static int guc_log_relay_create(struct intel_guc_log *log)
Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Update GuC messages in intel_guc_fw.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 5b86b2e286e0..3d2249bda368 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -13,6 +13,7 @@
#include "gt/intel_gt_mcr.h"
#include "gt/intel_gt_regs.h"
#include "intel_guc_fw.h"
+#include "intel_guc_print.h"
#include "i915_drv.h"
static void guc_prepare_xfer(struct intel_gt *gt)
@@ -103,8 +104,10 @@ static inline bool guc_ready(struct intel_uncore *uncore,
u32 *status)
return uk_val == INTEL_GUC_LOAD_STATUS_READY;
}
-static int guc_wait_ucode(struct intel_uncore *uncore)
+static int guc_wait_ucode(struct intel_guc *guc)
{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct intel_uncore *uncore = gt->uncore;
u32 status;
int ret;
@@ -127,10 +130,8 @@ static int guc_wait_ucode(struct intel_uncore *uncore)
*/
ret = wait_for(guc_ready(uncore, &status), 200);
if (ret) {
- struct drm_device *drm = &uncore->i915->drm;
-
- drm_info(drm, "GuC load failed: status = 0x%08X\n", status);
- drm_info(drm, "GuC load failed: status: Reset = %d, "
+ guc_info(guc, "load failed: status = 0x%08X\n", status);
+ guc_info(guc, "load failed: status: Reset = %d, "
"BootROM = 0x%02X, UKernel = 0x%02X, "
"MIA = 0x%02X, Auth = 0x%02X\n",
REG_FIELD_GET(GS_MIA_IN_RESET, status),
@@ -140,12 +141,12 @@ static int guc_wait_ucode(struct intel_uncore *uncore)
REG_FIELD_GET(GS_AUTH_STATUS_MASK, status));
if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
- drm_info(drm, "GuC firmware signature verification
failed\n");
+ guc_info(guc, "firmware signature verification
failed\n");
ret = -ENOEXEC;
}
if (REG_FIELD_GET(GS_UKERNEL_MASK, status) == INTEL_GUC_LOAD_STATUS_EXCEPTION) {
- drm_info(drm, "GuC firmware exception. EIP: %#x\n",
+ guc_info(guc, "firmware exception. EIP: %#x\n",
intel_uncore_read(uncore, SOFT_SCRATCH(13)));
ret = -ENXIO;
}
@@ -194,7 +195,7 @@ int intel_guc_fw_upload(struct intel_guc *guc)
if (ret)
goto out;
- ret = guc_wait_ucode(uncore);
+ ret = guc_wait_ucode(guc);
if (ret)
goto out;
Re: [Intel-gfx] [PATCH 4/8] drm/i915/guc: Update GuC messages in intel_guc_ct.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 2b22065e87bf..89adfc4193d2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -11,6 +11,7 @@
#include "i915_drv.h"
#include "intel_guc_ct.h"
+#include "intel_guc_print.h"
#include "gt/intel_gt.h"
static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
@@ -28,21 +29,16 @@ static inline struct drm_i915_private *ct_to_i915(struct
intel_guc_ct *ct)
return ct_to_gt(ct)->i915;
}
-static inline struct drm_device *ct_to_drm(struct intel_guc_ct *ct)
-{
- return &ct_to_i915(ct)->drm;
-}
-
#define CT_ERROR(_ct, _fmt, ...) \
- drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ guc_err(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
#ifdef CONFIG_DRM_I915_DEBUG_GUC
#define CT_DEBUG(_ct, _fmt, ...) \
- drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ guc_dbg(ct_to_guc(_ct), "CT: " _fmt, ##__VA_ARGS__)
#else
#define CT_DEBUG(...) do { } while (0)
#endif
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
- i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+ guc_probe_error(ct_to_guc(ct), "CT: " _fmt, ##__VA_ARGS__)
ct_to_i915 is also now redundant and can be removed?
John.
/**
* DOC: CTB Blob
Re: [Intel-gfx] [PATCH 3/8] drm/i915/guc: Update GuC messages in intel_guc_ads.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index a7f737c4792e..69ce06faf8cd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -15,6 +15,7 @@
#include "intel_guc_ads.h"
#include "intel_guc_capture.h"
#include "intel_guc_fwif.h"
+#include "intel_guc_print.h"
#include "intel_uc.h"
#include "i915_drv.h"
@@ -427,7 +428,7 @@ static long guc_mmio_reg_state_create(struct intel_guc *guc)
guc->ads_regset = temp_set.storage;
- drm_dbg(&guc_to_gt(guc)->i915->drm, "Used %zu KB for temporary ADS regset\n",
+ guc_dbg(guc, "Used %zu KB for temporary ADS regset\n",
(temp_set.storage_max * sizeof(struct guc_mmio_reg)) >> 10);
return total * sizeof(struct guc_mmio_reg);
@@ -621,7 +622,7 @@ static void guc_init_golden_context(struct intel_guc *guc)
engine = find_engine_state(gt, engine_class);
if (!engine) {
- drm_err(>->i915->drm, "No engine state recorded for class
%d!\n",
+ guc_err(guc, "No engine state recorded for class %d!\n",
engine_class);
ads_blob_write(guc, ads.eng_state_size[guc_class], 0);
ads_blob_write(guc, ads.golden_context_lrca[guc_class],
0);
@@ -646,7 +647,6 @@ static int
guc_capture_prep_lists(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
u32 ads_ggtt, capture_offset, null_ggtt, total_size = 0;
struct guc_gt_system_info local_info;
struct iosys_map info_map;
@@ -751,7 +751,7 @@ guc_capture_prep_lists(struct intel_guc *guc)
}
if (guc->ads_capture_size && guc->ads_capture_size != PAGE_ALIGN(total_size))
- drm_warn(&i915->drm, "GuC->ADS->Capture alloc size changed from %d
to %d\n",
+ guc_warn(guc, "ADS capture alloc size changed from %d to %d\n",
guc->ads_capture_size, PAGE_ALIGN(total_size));
return PAGE_ALIGN(total_size);
Re: [Intel-gfx] [PATCH 2/8] drm/i915/guc: Update GuC messages in intel_guc.c
On 1/20/2023 08:40, Michal Wajdeczko wrote:
Use new macros to have common prefix that also include GT#.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 31 +-
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 1bccc175f9e6..be39e519b5fd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -11,6 +11,7 @@
#include "intel_guc.h"
#include "intel_guc_ads.h"
#include "intel_guc_capture.h"
+#include "intel_guc_print.h"
#include "intel_guc_slpc.h"
#include "intel_guc_submission.h"
#include "i915_drv.h"
@@ -94,8 +95,8 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
assert_rpm_wakelock_held(>->i915->runtime_pm);
spin_lock_irq(gt->irq_lock);
- WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
-gt->pm_guc_events);
+ guc_WARN_ON_ONCE(guc, intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
+gt->pm_guc_events);
gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
spin_unlock_irq(gt->irq_lock);
@@ -342,7 +343,7 @@ static void guc_init_params(struct intel_guc *guc)
params[GUC_CTL_DEVID] = guc_ctl_devid(guc);
for (i = 0; i < GUC_CTL_MAX_DWORDS; i++)
- DRM_DEBUG_DRIVER("param[%2d] = %#x\n", i, params[i]);
+ guc_dbg(guc, "param[%2d] = %#x\n", i, params[i]);
}
/*
@@ -389,7 +390,6 @@ void intel_guc_dump_time_info(struct intel_guc *guc, struct
drm_printer *p)
int intel_guc_init(struct intel_guc *guc)
{
- struct intel_gt *gt = guc_to_gt(guc);
int ret;
ret = intel_uc_fw_init(&guc->fw);
@@ -451,7 +451,7 @@ int intel_guc_init(struct intel_guc *guc)
intel_uc_fw_fini(&guc->fw);
out:
intel_uc_fw_change_status(&guc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
- i915_probe_error(gt->i915, "failed with %d\n", ret);
+ guc_probe_error(guc, "failed with %pe\n", ERR_PTR(ret));
return ret;
}
@@ -480,7 +480,6 @@ void intel_guc_fini(struct intel_guc *guc)
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
{
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
u32 header;
int i;
@@ -515,7 +514,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*request, u32 len,
10, 10, &header);
if (unlikely(ret)) {
timeout:
- drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
+ guc_err(guc, "mmio request %#x: no reply %x\n",
request[0], header);
goto out;
}
@@ -537,7 +536,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*request, u32 len,
if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
- drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
+ guc_dbg(guc, "mmio request %#x: retrying, reason %u\n",
request[0], reason);
goto retry;
}
@@ -546,7 +545,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*request, u32 len,
u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
- drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
+ guc_err(guc, "mmio request %#x: failure %x/%u\n",
request[0], error, hint);
ret = -ENXIO;
goto out;
@@ -554,7 +553,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32
*request, u32 len,
if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
proto:
- drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
+ guc_err(guc, "mmio request %#x: unexpected reply %#x\n",
request[0], header);
ret = -EPROTO;
goto out;
@@ -597,9 +596,9 @@ int intel_guc_to_host_process_recv_msg(struct intel_guc
*guc,
msg = payload[0] & guc->msg_enabled_mask;
if (msg & INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)
- drm_err(&guc_to_gt(guc)->i915->drm, "Received early GuC crash dump
notification!\n");
+ guc_err(guc, "Received early GuC crash dump notification!\n");
if (msg & INTEL_GUC_RECV_MSG_EXCEPTION)
- drm_err(&guc_to_gt(guc)->i915->drm, "Received early GuC exception
notification!\n");
+ guc_err(guc, "Received early GuC exception notification!\n");
These two should drop the 'GUC' string from the message g
Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
On Wed, 2023-01-18 at 18:01 -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 1/11/2023 1:42 PM, Alan Previn wrote:
> > Despite KCR subsystem being in the media-tile (close to the
> > GSC-CS), the IRQ controls for it are on GT-0 with other global
> > IRQ controls. Thus, add a helper for KCR hw interrupt
> > enable/disable functions to get the correct gt structure (for
> > uncore) for MTL.
> >
> > In the helper, we get GT-0's handle for uncore when touching
> > IRQ registers despite the pxp->ctrl_gt being the media-tile.
> > No difference for legacy of course.
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
> > drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +---
> > drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
> > 3 files changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > index 4b8e70caa3ad..9f6e300486b4 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > @@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
> > static int pxp_terminate_set(void *data, u64 val)
> > {
> > struct intel_pxp *pxp = data;
> > - struct intel_gt *gt = pxp->ctrl_gt;
> > + struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
>
> This doesn't seem to be required here. The only use of gt in this
> function is an assert below and both the root and media gt point to the
> same irq_lock, so it doesn't matter which one we're using. Should we
> keep it anyway just for safety in case things change in the future? or
> just add a comment instead?
>
I rather we keep this helper for consistency: everything else in front-end
pxp code is using pxp->ctrl_gt, but if we use pxp->[root_gt] here, it would
just read like a bug without understanding the hw details.
As you have pointed out farther down, the helper could just return root gt
always (since they both point to the same IRQ register). I will go ahead and
follow your recommendation for the helper internals (with the comments
explaining in detail) but have the callers continue to use that helper.
> >
> > if (!intel_pxp_is_active(pxp))
> > return -ENODEV;
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > index 91e9622c07d0..2eef0c19e91a 100644
> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > @@ -8,6 +8,7 @@
> > #include "gt/intel_gt_regs.h"
> > #include "gt/intel_gt_types.h"
> >
> > +#include "i915_drv.h"
> > #include "i915_irq.h"
> > #include "i915_reg.h"
> >
> > @@ -17,6 +18,22 @@
> > #include "intel_pxp_types.h"
> > #include "intel_runtime_pm.h"
> >
> > +/**
> > + * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
> > + * @pxp: pointer to pxp struct
> > + *
> > + * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
> > + * but for MTL+ that has a media-tile, although the KCR engine is in the
> > + * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
> > + */
> > +struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
> > +{
> > + if (pxp->uses_gsccs)
> > + return to_gt(pxp->ctrl_gt->i915);
> > +
> > + return pxp->ctrl_gt;
>
> AFAICT here we can skip the if and always return the root gt, because
> that's what happens in both cases. If you want to make sure we don't get
> issues in the future maybe instead add a:
>
> GEM_BUG_ON(!i915->media_gt && !gt_is_root(pxp->ctrl_gt))
will do.
>
> > +}
> > +
> > /**
> > * intel_pxp_irq_handler - Handles PXP interrupts.
> > * @pxp: pointer to pxp struct
> > @@ -29,7 +46,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
> > if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
> > return;
> >
> > - gt = pxp->ctrl_gt;
> > + gt = intel_pxp_get_irq_gt(pxp);
>
> Here also we only have the assert below
i will follow the above recommendation.
>
> Daniele
>
> >
> > lockdep_assert_held(gt->irq_lock);
> >
> > @@ -68,7 +85,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
> >
> > void intel_pxp_irq_enable(struct intel_pxp *pxp)
> > {
> > - struct intel_gt *gt = pxp->ctrl_gt;
> > + struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
> >
> > spin_lock_irq(gt->irq_lock);
> >
> > @@ -83,7 +100,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
> >
> > void intel_pxp_irq_disable(struct intel_pxp *pxp)
> > {
> > - struct intel_gt *gt = pxp->ctrl_gt;
> > + struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
> >
> > /*
> > * We always need to submit a global termination when we re-enable
> > the
> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
> > b
Re: [Intel-gfx] [PATCH 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'
Hi Thomas,
a quick drive-by comment.
On Mon, Jan 23, 2023 at 11:05:59AM +0100, Thomas Zimmermann wrote:
> The generic fbdev emulation names variables of type struct fb_info
> both 'fbi' and 'info'. The latter seems to be more common in fbdev
> code, so name fbi accordingly.
>
> Also replace the duplicate variable in drm_fbdev_fb_destroy().
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fbdev_generic.c | 49 ++---
> 1 file changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
> b/drivers/gpu/drm/drm_fbdev_generic.c
> index 49a0bba86ce7..7633da5c13c3 100644
> --- a/drivers/gpu/drm/drm_fbdev_generic.c
> +++ b/drivers/gpu/drm/drm_fbdev_generic.c
> @@ -46,17 +46,16 @@ static int drm_fbdev_fb_release(struct fb_info *info, int
> user)
> static void drm_fbdev_fb_destroy(struct fb_info *info)
> {
> struct drm_fb_helper *fb_helper = info->par;
> - struct fb_info *fbi = fb_helper->info;
> void *shadow = NULL;
>
> if (!fb_helper->dev)
> return;
>
> - if (fbi) {
> - if (fbi->fbdefio)
> - fb_deferred_io_cleanup(fbi);
> + if (info) {
As info is already used above to find fb_helper, this check is
redundant.
Sam
> + if (info->fbdefio)
> + fb_deferred_io_cleanup(info);
> if (drm_fbdev_use_shadow_fb(fb_helper))
> - shadow = fbi->screen_buffer;
> + shadow = info->screen_buffer;
> }
>
> drm_fb_helper_fini(fb_helper);
> @@ -173,7 +172,7 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
> *fb_helper,
> struct drm_device *dev = fb_helper->dev;
> struct drm_client_buffer *buffer;
> struct drm_framebuffer *fb;
> - struct fb_info *fbi;
> + struct fb_info *info;
> u32 format;
> struct iosys_map map;
> int ret;
> @@ -192,35 +191,35 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
> *fb_helper,
> fb_helper->fb = buffer->fb;
> fb = buffer->fb;
>
> - fbi = drm_fb_helper_alloc_info(fb_helper);
> - if (IS_ERR(fbi))
> - return PTR_ERR(fbi);
> + info = drm_fb_helper_alloc_info(fb_helper);
> + if (IS_ERR(info))
> + return PTR_ERR(info);
>
> - fbi->fbops = &drm_fbdev_fb_ops;
> - fbi->screen_size = sizes->surface_height * fb->pitches[0];
> - fbi->fix.smem_len = fbi->screen_size;
> - fbi->flags = FBINFO_DEFAULT;
> + info->fbops = &drm_fbdev_fb_ops;
> + info->screen_size = sizes->surface_height * fb->pitches[0];
> + info->fix.smem_len = info->screen_size;
> + info->flags = FBINFO_DEFAULT;
>
> - drm_fb_helper_fill_info(fbi, fb_helper, sizes);
> + drm_fb_helper_fill_info(info, fb_helper, sizes);
>
> if (drm_fbdev_use_shadow_fb(fb_helper)) {
> - fbi->screen_buffer = vzalloc(fbi->screen_size);
> - if (!fbi->screen_buffer)
> + info->screen_buffer = vzalloc(info->screen_size);
> + if (!info->screen_buffer)
> return -ENOMEM;
> - fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
> + info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
>
> - fbi->fbdefio = &drm_fbdev_defio;
> - fb_deferred_io_init(fbi);
> + info->fbdefio = &drm_fbdev_defio;
> + fb_deferred_io_init(info);
> } else {
> /* buffer is mapped for HW framebuffer */
> ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
> if (ret)
> return ret;
> if (map.is_iomem) {
> - fbi->screen_base = map.vaddr_iomem;
> + info->screen_base = map.vaddr_iomem;
> } else {
> - fbi->screen_buffer = map.vaddr;
> - fbi->flags |= FBINFO_VIRTFB;
> + info->screen_buffer = map.vaddr;
> + info->flags |= FBINFO_VIRTFB;
> }
>
> /*
> @@ -229,10 +228,10 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
> *fb_helper,
>* case.
>*/
> #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
> - if (fb_helper->hint_leak_smem_start && fbi->fix.smem_start == 0
> &&
> + if (fb_helper->hint_leak_smem_start && info->fix.smem_start ==
> 0 &&
> !drm_WARN_ON_ONCE(dev, map.is_iomem))
> - fbi->fix.smem_start =
> - page_to_phys(virt_to_page(fbi->screen_buffer));
> + info->fix.smem_start =
> + page_to_phys(virt_to_page(info->screen_buffer));
> #endif
> }
>
> --
> 2.39.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use uabi engines for the default engine map (rev4)
== Series Details ==
Series: drm/i915: Use uabi engines for the default engine map (rev4)
URL : https://patchwork.freedesktop.org/series/68395/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624 -> Patchwork_68395v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/index.html
Participating hosts (38 -> 39)
--
Additional (2): fi-kbl-soraka fi-pnv-d510
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_68395v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#1886])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@late_gt_pm:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][4] ([i915#7640])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +15 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +44 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-1}: [DMESG-FAIL][7] ([i915#7059]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][9] ([i915#6257]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-2/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/bat-rpls-2/igt@i915_selftest@l...@requests.html
- {bat-rpls-1}: [INCOMPLETE][11] ([i915#4983]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][13] ([i915#6298]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-1:
- {bat-adlp-9}: [FAIL][15] ([i915#4137]) -> [PASS][16] +3 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-adlp-9/igt@kms_pipe_crc_basic@read-...@pipe-c-dp-1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v4/bat-adlp-9/igt@kms_pipe_crc_basic@read-...@pipe-c-dp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4137]: https://gitlab.freedesktop.org/drm/intel/issues/4137
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7059]: https://gitlab.freedesktop.org/drm/intel/issues/7059
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Implement Wa_14014971492
On Wed, Jan 18, 2023 at 10:51:59AM +0200, Jouni Högander wrote: > Implement Wa_14014971492 and apply it for affected platforms. > > Bspec: 52890, 54369, 55378, 66624 > > Cc: Mika Kahola > Cc: José Roberto de Souza > Signed-off-by: Jouni Högander > --- > drivers/gpu/drm/i915/display/intel_psr.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 7d4a15a283a0..24900a790508 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -1842,6 +1842,11 @@ int intel_psr2_sel_fetch_update(struct > intel_atomic_state *state, > if (full_update) > goto skip_sel_fetch_set_loop; > > + /* Wa_14014971492 */ > + if ((IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) || > + IS_DISPLAY_VER(dev_priv, 12, 13)) This is not true. This lineage number shows as not needed for most of platforms with the display version 12. you should only have TGL and ADL-P here, besides the MTL one... Which, btw, why we have a MTL_DISPLAY macro instead of using the display version :'( && crtc_state->splitter.enable) > + pipe_clip.y1 = 0; > + > ret = drm_atomic_add_affected_planes(&state->base, &crtc->base); > if (ret) > return ret; > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmc: Use unversioned path for ADLP
On Mon, Jan 23, 2023 at 03:20:21PM -0300, Gustavo Sousa wrote:
> The new DMC release for ADLP (v2.18) in linux-firmware adopted the new
> convention of using unversioned filenames, so update the driver code for
> that new release. Keep the latest versioned path as fallback so we do
> not cause regressions.
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 2464796c769d..257aa2b7cf20 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -63,8 +63,10 @@
> #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
> MODULE_FIRMWARE(DG2_DMC_PATH);
>
> -#define ADLP_DMC_PATHDMC_LEGACY_PATH(adlp, 2, 16)
> +#define ADLP_DMC_PATHDMC_PATH(adlp)
> +#define ADLP_DMC_FALLBACK_PATH DMC_LEGACY_PATH(adlp, 2, 16)
> MODULE_FIRMWARE(ADLP_DMC_PATH);
> +MODULE_FIRMWARE(ADLP_DMC_FALLBACK_PATH);
I'm glad this works without warning on the intrd/intramfs generators.
Reviewed-by: Rodrigo Vivi
>
> #define ADLS_DMC_PATHDMC_LEGACY_PATH(adls, 2, 01)
> MODULE_FIRMWARE(ADLS_DMC_PATH);
> @@ -855,7 +857,9 @@ static void intel_dmc_runtime_pm_put(struct
> drm_i915_private *dev_priv)
>
> static const char *dmc_fallback_path(struct drm_i915_private *i915)
> {
> - /* No fallback paths for now. */
> + if (IS_ALDERLAKE_P(i915))
> + return ADLP_DMC_FALLBACK_PATH;
> +
> return NULL;
> }
>
> --
> 2.39.0
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmc: Prepare to use unversioned paths
On Mon, Jan 23, 2023 at 03:20:20PM -0300, Gustavo Sousa wrote:
> New DMC releases in linux-firmware will stop using version number in
> blob filenames. This new convention provides the following benefits:
>
> 1. It simplifies code maintenance, as new DMC releases for a platform
> using the new convention will always use the same filename for the
> blob.
>
> 2. It allows DMC to be loaded even if the target system does not have
> the most recent firmware installed.
>
> Prepare the driver by:
>
> - Using the new convention for DMC_PATH() and renaming the currently
> used one to make it clear it is for the legacy scheme.
>
> - Implementing a fallback mechanism for future transitions from
> versioned to unversioned paths so that we do not cause a regression
> for systems not having the most up-to-date linux-firmware files.
>
> v2:
> - Keep using request_firmware() instead of firmware_request_nowarn().
> (Jani)
> v3:
> - Keep current DMC paths instead of directly using unversioned ones,
> so that we do not disturb initrd generation.
> (Lucas, Rodrigo)
>
> Signed-off-by: Gustavo Sousa
> Cc: Jani Nikula
> Cc: Lucas De Marchi
> Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 62 ++--
> 1 file changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 370c91d323fc..2464796c769d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -42,51 +42,59 @@
> #define DMC_VERSION_MAJOR(version) ((version) >> 16)
> #define DMC_VERSION_MINOR(version) ((version) & 0x)
>
> -#define DMC_PATH(platform, major, minor) \
> - "i915/" \
> - __stringify(platform) "_dmc_ver" \
> - __stringify(major) "_" \
> +#define DMC_PATH(platform) \
> + "i915/" __stringify(platform) "_dmc.bin"
> +
> +/*
> + * New DMC additions should not use this. This is used solely to remain
> + * compatible with systems that have not yet updated DMC blobs to use
> + * unversioned file names.
> + */
> +#define DMC_LEGACY_PATH(platform, major, minor) \
> + "i915/" \
> + __stringify(platform) "_dmc_ver"\
> + __stringify(major) "_" \
> __stringify(minor) ".bin"
>
> #define DISPLAY_VER13_DMC_MAX_FW_SIZE0x2
>
> #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>
> -#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08)
> +#define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
> MODULE_FIRMWARE(DG2_DMC_PATH);
>
> -#define ADLP_DMC_PATHDMC_PATH(adlp, 2, 16)
> +#define ADLP_DMC_PATHDMC_LEGACY_PATH(adlp, 2, 16)
> MODULE_FIRMWARE(ADLP_DMC_PATH);
>
> -#define ADLS_DMC_PATHDMC_PATH(adls, 2, 01)
> +#define ADLS_DMC_PATHDMC_LEGACY_PATH(adls, 2, 01)
> MODULE_FIRMWARE(ADLS_DMC_PATH);
>
> -#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02)
> +#define DG1_DMC_PATH DMC_LEGACY_PATH(dg1, 2, 02)
> MODULE_FIRMWARE(DG1_DMC_PATH);
>
> -#define RKL_DMC_PATH DMC_PATH(rkl, 2, 03)
> +#define RKL_DMC_PATH DMC_LEGACY_PATH(rkl, 2, 03)
> MODULE_FIRMWARE(RKL_DMC_PATH);
>
> -#define TGL_DMC_PATH DMC_PATH(tgl, 2, 12)
> +#define TGL_DMC_PATH DMC_LEGACY_PATH(tgl, 2, 12)
> MODULE_FIRMWARE(TGL_DMC_PATH);
>
> -#define ICL_DMC_PATH DMC_PATH(icl, 1, 09)
> +#define ICL_DMC_PATH DMC_LEGACY_PATH(icl, 1, 09)
> #define ICL_DMC_MAX_FW_SIZE 0x6000
> MODULE_FIRMWARE(ICL_DMC_PATH);
>
> -#define GLK_DMC_PATH DMC_PATH(glk, 1, 04)
> +#define GLK_DMC_PATH DMC_LEGACY_PATH(glk, 1, 04)
> #define GLK_DMC_MAX_FW_SIZE 0x4000
> MODULE_FIRMWARE(GLK_DMC_PATH);
>
> -#define KBL_DMC_PATH DMC_PATH(kbl, 1, 04)
> +#define KBL_DMC_PATH DMC_LEGACY_PATH(kbl, 1, 04)
> #define KBL_DMC_MAX_FW_SIZE BXT_DMC_MAX_FW_SIZE
> MODULE_FIRMWARE(KBL_DMC_PATH);
>
> -#define SKL_DMC_PATH DMC_PATH(skl, 1, 27)
> +#define SKL_DMC_PATH DMC_LEGACY_PATH(skl, 1, 27)
> #define SKL_DMC_MAX_FW_SIZE BXT_DMC_MAX_FW_SIZE
> MODULE_FIRMWARE(SKL_DMC_PATH);
>
> -#define BXT_DMC_PATH DMC_PATH(bxt, 1, 07)
> +#define BXT_DMC_PATH DMC_LEGACY_PATH(bxt, 1, 07)
> #define BXT_DMC_MAX_FW_SIZE 0x3000
> MODULE_FIRMWARE(BXT_DMC_PATH);
>
> @@ -845,16 +853,38 @@ static void intel_dmc_runtime_pm_put(struct
> drm_i915_private *dev_priv)
> intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
> }
>
> +static const char *dmc_fallback_path(struct drm_i915_private *i915)
> +{
> + /* No fa
Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Fix request locking during error capture & debugfs dump
On 1/23/2023 09:51, Tvrtko Ursulin wrote:
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
In addition, intel_guc_find_hung_context() was not acquiring the
correct spinlock before searching the request list. So fix that up
too. While at it, add some extra whitespace padding for readability.
Is this part splittable into a separate patch?
I guess it could but it seems closely related to all the other locking
fix ups in this patch.
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
v3: Add a _get suffix to intel_context_find_active_request now that it
grabs a reference (Daniele).
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full
GPU reset with GuC")
Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context
reset")
Cc: Matthew Brost
Cc: John Harrison
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Andrzej Hajda
Cc: Matthew Auld
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Tejas Upadhyay
Cc: Andy Shevchenko
Cc: Aravind Iddamsetty
Cc: Alan Previn
Cc: Bruce Chang
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 3 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++---
5 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e94365b08f1ef..4285c1c71fa12 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,7 +528,7 @@ struct i915_request
*intel_context_create_request(struct intel_context *ce)
return rq;
}
-struct i915_request *intel_context_find_active_request(struct
intel_context *ce)
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce)
TBH I don't "dig" this name, it's a bit on the long side and feels out
of character. I won't insist it be changed, but if get really has to
be included in the name I would be happy with
intel_context_get_active_request().
Personally, I see the 'find' component as meaning it is a search not
just a dereference of an existing pointer and therefore being a useful
part of the name. I don't think there is a simple name that encapsulates
everything that is going on here. But I don't feel too strongly about it
if you really think the shorter version is better.
One could add some kerneldoc... but it would be almost the only function
in the whole of intel_context.h with such. Not sure if that is
intentional because "obviously it should be obvious what a function is
doing by reading the code and documentation is a waste of space that
gets out of date and inaccurate" and we aren't meant to kerneldoc
internal behaviour or if it's just the general lack of documentation for
any driver code.
{
struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
@@ -552,6 +552,8 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
active = rq;
}
+ if (active)
+ active = i915_request_get_rcu(active);
spin_unlock_irqrestore(&parent->guc_state.lock, flags);
return active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index fb62b7b8cbcda..ccc80c6607ca8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -268,8 +268,7 @@
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use uabi engines for the default engine map (rev4)
== Series Details == Series: drm/i915: Use uabi engines for the default engine map (rev4) URL : https://patchwork.freedesktop.org/series/68395/ State : warning == Summary == Error: dim checkpatch failed 0d0b8f01c267 drm/i915: Use uabi engines for the default engine map -:11: WARNING:BAD_SIGN_OFF: Non-standard signature: 'Reveiwed-by:' - perhaps 'Reviewed-by:'? #11: Reveiwed-by: Jonathan Cavitt -:42: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #42: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1115: + GEM_BUG_ON(engine->legacy_idx >= max); total: 0 errors, 2 warnings, 0 checks, 27 lines checked
Re: [Intel-gfx] [PATCH] drm/i915: Use uabi engines for the default engine map
-Original Message-
From: Cavitt, Jonathan
Sent: Monday, January 23, 2023 7:25 AM
To: intel-gfx@lists.freedesktop.org
Cc: Cavitt, Jonathan ; Dutt, Sudeep
Subject: [PATCH] drm/i915: Use uabi engines for the default engine map
>
> From: Tvrtko Ursulin
>
> Default engine map is exactly about uabi engines so no excuse not to use
> the appropriate iterator to populate it.
>
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Jonathan Cavitt
Reviewed-by: Jonathan Cavitt
-Jonathan Cavitt
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 454e73a433c8..42a39e103d7c 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1096,16 +1096,15 @@ static struct i915_gem_engines
> *alloc_engines(unsigned int count)
> static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
> struct intel_sseu rcs_sseu)
> {
> - const struct intel_gt *gt = to_gt(ctx->i915);
> + const unsigned int max = I915_NUM_ENGINES;
> struct intel_engine_cs *engine;
> struct i915_gem_engines *e, *err;
> - enum intel_engine_id id;
>
> - e = alloc_engines(I915_NUM_ENGINES);
> + e = alloc_engines(max);
> if (!e)
> return ERR_PTR(-ENOMEM);
>
> - for_each_engine(engine, gt, id) {
> + for_each_uabi_engine(engine, ctx->i915) {
> struct intel_context *ce;
> struct intel_sseu sseu = {};
> int ret;
> @@ -1113,7 +1112,7 @@ static struct i915_gem_engines *default_engines(struct
> i915_gem_context *ctx,
> if (engine->legacy_idx == INVALID_ENGINE)
> continue;
>
> - GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
> + GEM_BUG_ON(engine->legacy_idx >= max);
> GEM_BUG_ON(e->engines[engine->legacy_idx]);
>
> ce = intel_context_create(engine);
> --
> 2.25.1
>
>
[Intel-gfx] ✓ Fi.CI.BAT: success for Use unversioned blob path for ADLP DMC
== Series Details ==
Series: Use unversioned blob path for ADLP DMC
URL : https://patchwork.freedesktop.org/series/113238/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624 -> Patchwork_113238v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/index.html
Participating hosts (38 -> 38)
--
Additional (2): fi-kbl-soraka fi-pnv-d510
Missing(2): fi-rkl-11600 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113238v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#1886])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@guc_multi_lrc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][4] ([i915#7640])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-kbl-soraka/igt@i915_selftest@live@guc_multi_lrc.html
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#4983])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +15 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][8] ([fdo#109271]) +44 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-1}: [DMESG-FAIL][9] ([i915#7059]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][11] ([i915#6257]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-2/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/bat-rpls-2/igt@i915_selftest@l...@requests.html
- {bat-rpls-1}: [INCOMPLETE][13] ([i915#4983]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][15] ([i915#6298]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113238v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7059]: https://gitlab.freedesktop.org/drm/intel/issues/7059
[i915#7640]: https://gitlab.freedesktop.org/drm/intel/issues/7640
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux:
Re: [Intel-gfx] [PATCH] drm/i915: Implement workaround for CDCLK PLL disable/enable
On Mon, Jan 23, 2023 at 03:16:11PM +0200, Stanislav Lisovskiy wrote:
> It was reported that we might get a hung and loss of register access in
> some cases when CDCLK PLL is disabled and then enabled, while squashing
> is enabled.
> As a workaround it was proposed by HW team that SW should disable squashing
> when CDCLK PLL is being reenabled.
What's the WA lineage for this WA?
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 0c107a38f9d0..e338f288c9ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1801,6 +1801,13 @@ static bool
> cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
> return true;
> }
>
> +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
> +{
> + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> + && dev_priv->display.cdclk.hw.vco > 0
> + && HAS_CDCLK_SQUASH(dev_priv));
> +}
> +
> static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> @@ -1815,9 +1822,12 @@ static void _bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
> if (dev_priv->display.cdclk.hw.vco != vco)
> adlp_cdclk_pll_crawl(dev_priv, vco);
> - } else if (DISPLAY_VER(dev_priv) >= 11)
> + } else if (DISPLAY_VER(dev_priv) >= 11) {
> + if (pll_enable_wa_needed(dev_priv))
> + dg2_cdclk_squash_program(dev_priv, 0);
> +
> icl_cdclk_pll_update(dev_priv, vco);
> - else
> + } else
> bxt_cdclk_pll_update(dev_priv, vco);
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
> --
> 2.37.3
>
[Intel-gfx] ✓ Fi.CI.BAT: success for Add _PICK_EVEN_2RANGES (rev2)
== Series Details ==
Series: Add _PICK_EVEN_2RANGES (rev2)
URL : https://patchwork.freedesktop.org/series/113177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624 -> Patchwork_113177v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-pnv-d510
Missing(2): fi-rkl-11600 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113177v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2] ([i915#6972] /
[i915#7911])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [PASS][3] -> [TIMEOUT][4] ([i915#6794])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-rkl-guc/igt@i915_selftest@l...@mman.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][5] -> [FAIL][6] ([i915#6298])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-lvds-1:
- fi-ctg-p8600: [PASS][7] -> [FAIL][8] ([fdo#103375])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-ctg-p8600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-lvds-1.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +44 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-1}: [DMESG-FAIL][11] ([i915#7059]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][13] ([i915#6257]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-2/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/bat-rpls-2/igt@i915_selftest@l...@requests.html
- {bat-rpls-1}: [INCOMPLETE][15] ([i915#4983]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][17] ([i915#6298]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113177v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#6972]: https://gitlab.freedeskt
Re: [Intel-gfx] misc mdev tidyups
On Tue, 10 Jan 2023 10:10:05 +0100 Christoph Hellwig wrote: > Hi all, > > this series tidies up the mdev Kconfig interaction and documentation a bit. > > Diffstat: > Documentation/driver-api/vfio-mediated-device.rst | 108 > -- > Documentation/s390/vfio-ap.rst|1 > arch/s390/Kconfig |6 - > arch/s390/configs/debug_defconfig |1 > arch/s390/configs/defconfig |1 > drivers/gpu/drm/i915/Kconfig |2 > drivers/vfio/mdev/Kconfig |8 - > samples/Kconfig | 16 +-- > samples/vfio-mdev/README.rst | 100 > 9 files changed, 115 insertions(+), 128 deletions(-) > Applied to vfio next branch for v6.3. Thanks, Alex
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add _PICK_EVEN_2RANGES (rev2)
== Series Details == Series: Add _PICK_EVEN_2RANGES (rev2) URL : https://patchwork.freedesktop.org/series/113177/ State : warning == Summary == Error: dim checkpatch failed 7b9046444db2 drm/i915: Add _PICK_EVEN_2RANGES() -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__index' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:145: +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) \ + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + \ +((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : \ + _PICK_EVEN((__index) - (__c_index), __c, __d))) -:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__c_index' - possible side-effects? #58: FILE: drivers/gpu/drm/i915/i915_reg_defs.h:145: +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) \ + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + \ +((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : \ + _PICK_EVEN((__index) - (__c_index), __c, __d))) total: 0 errors, 0 warnings, 2 checks, 34 lines checked ceebaa623fa3 drm/i915: Fix coding style on DPLL*_ENABLE defines 3cd72fb54cf9 drm/i915: Convert pll macros to _PICK_EVEN_2RANGES -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: 4027456 1857036984 4220143 4064ef build64/drivers/gpu/drm/i915/i915.o.old total: 0 errors, 1 warnings, 0 checks, 106 lines checked ee6f334b5960 drm/i915: Replace _MMIO_PHY3() with _PICK_EVEN_2RANGES() -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: 4026997 1857036984 4219684 406324 build64/drivers/gpu/drm/i915/i915.o.old total: 0 errors, 1 warnings, 0 checks, 42 lines checked 032484a878c9 drm/i915: Convert PIPE3/PORT3 to _PICK_EVEN_2RANGES() -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: 4026288 1857036984 4218975 40605f build64/drivers/gpu/drm/i915/i915.o.old -:36: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'a' - possible side-effects? #36: FILE: drivers/gpu/drm/i915/display/intel_display_reg_defs.h:32: +#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK_EVEN_2RANGES(pipe, 1, a, a, b, c)) -:37: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'a' - possible side-effects? #37: FILE: drivers/gpu/drm/i915/display/intel_display_reg_defs.h:33: +#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK_EVEN_2RANGES(pipe, 1, a, a, b, c)) total: 0 errors, 1 warnings, 2 checks, 18 lines checked 63cd3e50d93a drm/i915: Convert _FIA() to _PICK_EVEN_2RANGES() 377d7638eb55 drm/i915: Convert MBUS_ABOX_CTL() to _PICK_EVEN_2RANGES() 9a055281abe7 drm/i915: Convert PALETTE() to _PICK_EVEN_2RANGES()
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use uabi engines for the default engine map (rev3)
== Series Details ==
Series: drm/i915: Use uabi engines for the default engine map (rev3)
URL : https://patchwork.freedesktop.org/series/68395/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12624 -> Patchwork_68395v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/index.html
Participating hosts (38 -> 38)
--
Additional (2): fi-kbl-soraka fi-pnv-d510
Missing(2): fi-ilk-650 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_68395v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:NOTRUN -> [FAIL][1] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@guc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][7] ([i915#7913])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +15 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +44 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-1}: [DMESG-FAIL][10] ([i915#7059]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][12] ([i915#6257]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-2/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/bat-rpls-2/igt@i915_selftest@l...@requests.html
- {bat-rpls-1}: [INCOMPLETE][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@l...@requests.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][16] ([i915#6298]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_68395v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org
Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Convert pll macros to _PICK_EVEN_2RANGES
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 3/8] drm/i915: Convert pll macros to
> _PICK_EVEN_2RANGES
>
> Avoid the array lookup, converting the PLL macros after ICL to
> _PICK_EVEN_RANGES. This provides the following reduction in code size:
>
> $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
> textdata bss dec hex filename
> 4027456 1857036984 4220143 4064ef
> build64/drivers/gpu/drm/i915/i915.o.old
> 4026997 1857036984 4219684 406324
> build64/drivers/gpu/drm/i915/i915.o.new
>
> At the same time it's safer, avoiding out-of-bounds array access. This
> allows to
> remove _MMIO_PLL3() that is now unused.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
> ---
> .../drm/i915/display/intel_display_reg_defs.h | 1 -
> drivers/gpu/drm/i915/i915_reg.h | 59 +--
> 2 files changed, 29 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> index 02605418ff08..a4ed1c530799 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> @@ -34,7 +34,6 @@
> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
> -#define _MMIO_PLL3(pll, ...) _MMIO(_PICK(pll, __VA_ARGS__))
>
> /*
> * Device info offset array based helpers for groups of registers with
> unevenly
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8da3546d82fb..dd1eb8b10e0e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7232,13 +7232,15 @@ enum skl_power_gate {
> #define PLL_LOCK REG_BIT(30)
> #define PLL_POWER_ENABLE REG_BIT(27)
> #define PLL_POWER_STATEREG_BIT(26)
> -#define ICL_DPLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_ADLS_DPLL2_ENABLE,
> _ADLS_DPLL3_ENABLE)
> +#define ICL_DPLL_ENABLE(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 3,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> +
> _ADLS_DPLL3_ENABLE, _ADLS_DPLL3_ENABLE))
>
> #define _DG2_PLL3_ENABLE 0x4601C
>
> -#define DG2_PLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_ADLS_DPLL2_ENABLE,
> _DG2_PLL3_ENABLE)
> +#define DG2_PLL_ENABLE(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 3,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> + _DG2_PLL3_ENABLE,
> _DG2_PLL3_ENABLE))
>
> #define TBT_PLL_ENABLE _MMIO(0x46020)
>
> @@ -7251,8 +7253,9 @@ enum skl_power_gate {
> _MG_PLL2_ENABLE)
>
> /* DG1 PLL */
> -#define DG1_DPLL_ENABLE(pll)_MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_MG_PLL1_ENABLE,
> _MG_PLL2_ENABLE)
> +#define DG1_DPLL_ENABLE(pll)_MMIO(_PICK_EVEN_2RANGES(pll, 2,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> + _MG_PLL1_ENABLE,
> _MG_PLL2_ENABLE))
>
> /* ADL-P Type C PLL */
> #define PORTTC1_PLL_ENABLE 0x46038
> @@ -7312,9 +7315,9 @@ enum skl_power_gate {
> #define _TGL_DPLL0_CFGCR00x164284
> #define _TGL_DPLL1_CFGCR00x16428C
> #define _TGL_TBTPLL_CFGCR0 0x16429C
> -#define TGL_DPLL_CFGCR0(pll) _MMIO_PLL3(pll,
> _TGL_DPLL0_CFGCR0, \
> - _TGL_DPLL1_CFGCR0, \
> - _TGL_TBTPLL_CFGCR0)
> +#define TGL_DPLL_CFGCR0(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 2,
> \
> + _TGL_DPLL0_CFGCR0,
> _TGL_DPLL1_CFGCR0,\
> + _TGL_TBTPLL_CFGCR0,
> _TGL_TBTPLL_CFGCR0))
> #define RKL_DPLL_CFGCR0(pll) _MMIO_PLL(pll, _TGL_DPLL0_CFGCR0,
> \
> _TGL_DPLL1_CFGCR0)
>
> @@ -7327,40 +7330,36 @@ enum skl_power_gate {
> #define _TGL_DPLL0_CFGCR10x164288
> #define _TGL_DPLL1_CFGCR10x164290
> #define _TGL_TBTPLL_CFGCR1 0x1642A0
> -#define TGL_DPLL_CFGCR1(pll) _MMIO_PLL3(pll,
> _TGL_DPLL0_CFGCR1, \
> -_TGL_DPLL1_CFGCR1, \
> -
[Intel-gfx] [PATCH] drm/i915: Use uabi engines for the default engine map
From: Tvrtko Ursulin
Default engine map is exactly about uabi engines so no excuse not to use
the appropriate iterator to populate it.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Jonathan Cavitt
Reveiwed-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 454e73a433c8..42a39e103d7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1096,16 +1096,15 @@ static struct i915_gem_engines *alloc_engines(unsigned
int count)
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
struct intel_sseu rcs_sseu)
{
- const struct intel_gt *gt = to_gt(ctx->i915);
+ const unsigned int max = I915_NUM_ENGINES;
struct intel_engine_cs *engine;
struct i915_gem_engines *e, *err;
- enum intel_engine_id id;
- e = alloc_engines(I915_NUM_ENGINES);
+ e = alloc_engines(max);
if (!e)
return ERR_PTR(-ENOMEM);
- for_each_engine(engine, gt, id) {
+ for_each_uabi_engine(engine, ctx->i915) {
struct intel_context *ce;
struct intel_sseu sseu = {};
int ret;
@@ -1113,7 +1112,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx,
if (engine->legacy_idx == INVALID_ENGINE)
continue;
- GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
+ GEM_BUG_ON(engine->legacy_idx >= max);
GEM_BUG_ON(e->engines[engine->legacy_idx]);
ce = intel_context_create(engine);
--
2.25.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement workaround for CDCLK PLL disable/enable
== Series Details ==
Series: drm/i915: Implement workaround for CDCLK PLL disable/enable
URL : https://patchwork.freedesktop.org/series/113226/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12624 -> Patchwork_113226v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113226v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113226v1, 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_113226v1/index.html
Participating hosts (38 -> 38)
--
Additional (1): fi-pnv-d510
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113226v1:
### IGT changes ###
Possible regressions
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- fi-skl-6700k2: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-skl-6700k2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-skl-6700k2/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_113226v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][3] -> [INCOMPLETE][4] ([i915#6972] /
[i915#7911])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#7911])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][7] -> [INCOMPLETE][8] ([i915#4983])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +44 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-bsw-n3050/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@fbdev@write:
- fi-blb-e6850: [SKIP][12] ([fdo#109271]) -> [PASS][13] +4 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-blb-e6850/igt@fb...@write.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-blb-e6850/igt@fb...@write.html
* igt@i915_selftest@live@gt_mocs:
- {bat-rpls-1}: [DMESG-FAIL][14] ([i915#7059]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/bat-rpls-1/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][16] ([i915#6257]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-2/igt@i915_selftest@l...@requests.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/bat-rpls-2/igt@i915_selftest@l...@requests.html
- {bat-rpls-1}: [INCOMPLETE][18] ([i915#4983]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/bat-rpls-1/igt@i915_selftest@l...@requests.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][20] ([i915#6298]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12624/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113226v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element i
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Implement workaround for CDCLK PLL disable/enable
== Series Details == Series: drm/i915: Implement workaround for CDCLK PLL disable/enable URL : https://patchwork.freedesktop.org/series/113226/ State : warning == Summary == Error: dim checkpatch failed 2bf60cdfb1d8 drm/i915: Implement workaround for CDCLK PLL disable/enable -:25: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line #25: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1807: + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv)) + && dev_priv->display.cdclk.hw.vco > 0 -:26: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line #26: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1808: + && dev_priv->display.cdclk.hw.vco > 0 + && HAS_CDCLK_SQUASH(dev_priv)); -:43: CHECK:BRACES: Unbalanced braces around else statement #43: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1830: + } else total: 0 errors, 0 warnings, 3 checks, 27 lines checked
Re: [Intel-gfx] [PATCH v8 5/8] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
On Mon, Jan 23, 2023 at 12:15:04PM +0200, Jani Nikula wrote:
> On Fri, 20 Jan 2023, Ville Syrjälä wrote:
> > On Thu, Jan 19, 2023 at 06:18:58PM +0200, Jani Nikula wrote:
> >> diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
> >> b/drivers/gpu/drm/i915/display/intel_lvds.c
> >> index aecec992cd0d..6a98787edf48 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_lvds.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_lvds.c
> >> @@ -479,8 +479,11 @@ static int intel_lvds_get_modes(struct drm_connector
> >> *connector)
> >>struct intel_connector *intel_connector = to_intel_connector(connector);
> >>
> >>/* use cached edid if we have one */
> >> - if (!IS_ERR_OR_NULL(intel_connector->edid))
> >> - return drm_add_edid_modes(connector, intel_connector->edid);
> >> + if (!IS_ERR_OR_NULL(intel_connector->edid)) {
> >> + drm_edid_connector_update(connector, intel_connector->edid);
> >
> > Isn't this update redundant?
>
> Maybe far fetched, but if the user does connector force disable via
> debugfs, drm_helper_probe_single_connector_modes() will clear the EDID
> property and display info. And after that, nobody's going to do the
> connector update again unless we do it here.
Right, DP/HDMI take care of that in .force(), we have no
.force() for LVDS atm. And I take the encoder types not handled
in this patch will keep using some older get_edid() thingy that
will do the update for them also from .get_modes()? Hmm, apart
from the encoders using intel_panel_get_modes() which I suppose
must already be busted...
I guess we should think about unifying the behaviour for all
the encoder types, including using detect_edid for everything...
Anyways, that's something for the future. For the time being
Reviewed-by: Ville Syrjälä
>
> BR,
> Jani.
>
>
>
> >
> >> +
> >> + return drm_edid_connector_add_modes(connector);
> >> + }
> >>
> >>return intel_panel_get_modes(intel_connector);
> >> }
> >> @@ -834,7 +837,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
> >>struct intel_connector *intel_connector;
> >>struct drm_connector *connector;
> >>struct drm_encoder *encoder;
> >> - struct edid *edid;
> >> + const struct drm_edid *drm_edid;
> >>i915_reg_t lvds_reg;
> >>u32 lvds;
> >>u8 pin;
> >> @@ -945,27 +948,36 @@ void intel_lvds_init(struct drm_i915_private
> >> *dev_priv)
> >> * preferred mode is the right one.
> >> */
> >>mutex_lock(&dev_priv->drm.mode_config.mutex);
> >> - if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC)
> >> + if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC) {
> >> + const struct edid *edid;
> >> +
> >> + /* FIXME: Make drm_get_edid_switcheroo() return drm_edid */
> >>edid = drm_get_edid_switcheroo(connector,
> >> - intel_gmbus_get_adapter(dev_priv, pin));
> >> - else
> >> - edid = drm_get_edid(connector,
> >> - intel_gmbus_get_adapter(dev_priv, pin));
> >> - if (edid) {
> >> - if (drm_add_edid_modes(connector, edid)) {
> >> - drm_connector_update_edid_property(connector,
> >> - edid);
> >> - } else {
> >> +
> >> intel_gmbus_get_adapter(dev_priv, pin));
> >> + if (edid) {
> >> + drm_edid = drm_edid_alloc(edid, (edid->extensions + 1)
> >> * EDID_LENGTH);
> >>kfree(edid);
> >> - edid = ERR_PTR(-EINVAL);
> >> + } else {
> >> + drm_edid = NULL;
> >> + }
> >> + } else {
> >> + drm_edid = drm_edid_read_ddc(connector,
> >> + intel_gmbus_get_adapter(dev_priv,
> >> pin));
> >> + }
> >> + if (drm_edid) {
> >> + if (drm_edid_connector_update(connector, drm_edid) ||
> >> + !drm_edid_connector_add_modes(connector)) {
> >> + drm_edid_connector_update(connector, NULL);
> >> + drm_edid_free(drm_edid);
> >> + drm_edid = ERR_PTR(-EINVAL);
> >>}
> >>} else {
> >> - edid = ERR_PTR(-ENOENT);
> >> + drm_edid = ERR_PTR(-ENOENT);
> >>}
> >> - intel_connector->edid = edid;
> >> + intel_connector->edid = drm_edid;
> >>
> >>intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
> >> - IS_ERR(edid) ? NULL : edid);
> >> + IS_ERR_OR_NULL(drm_edid) ? NULL :
> >> drm_edid_raw(drm_edid));
> >>
> >>/* Try EDID first */
> >>intel_panel_add_edid_fixed_modes(intel_connector, true);
> >> --
> >> 2.34.1
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Use unversioned path for ADLP
The new DMC release for ADLP (v2.18) in linux-firmware adopted the new
convention of using unversioned filenames, so update the driver code for
that new release. Keep the latest versioned path as fallback so we do
not cause regressions.
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 2464796c769d..257aa2b7cf20 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -63,8 +63,10 @@
#define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
MODULE_FIRMWARE(DG2_DMC_PATH);
-#define ADLP_DMC_PATH DMC_LEGACY_PATH(adlp, 2, 16)
+#define ADLP_DMC_PATH DMC_PATH(adlp)
+#define ADLP_DMC_FALLBACK_PATH DMC_LEGACY_PATH(adlp, 2, 16)
MODULE_FIRMWARE(ADLP_DMC_PATH);
+MODULE_FIRMWARE(ADLP_DMC_FALLBACK_PATH);
#define ADLS_DMC_PATH DMC_LEGACY_PATH(adls, 2, 01)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -855,7 +857,9 @@ static void intel_dmc_runtime_pm_put(struct
drm_i915_private *dev_priv)
static const char *dmc_fallback_path(struct drm_i915_private *i915)
{
- /* No fallback paths for now. */
+ if (IS_ALDERLAKE_P(i915))
+ return ADLP_DMC_FALLBACK_PATH;
+
return NULL;
}
--
2.39.0
[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Prepare to use unversioned paths
New DMC releases in linux-firmware will stop using version number in
blob filenames. This new convention provides the following benefits:
1. It simplifies code maintenance, as new DMC releases for a platform
using the new convention will always use the same filename for the
blob.
2. It allows DMC to be loaded even if the target system does not have
the most recent firmware installed.
Prepare the driver by:
- Using the new convention for DMC_PATH() and renaming the currently
used one to make it clear it is for the legacy scheme.
- Implementing a fallback mechanism for future transitions from
versioned to unversioned paths so that we do not cause a regression
for systems not having the most up-to-date linux-firmware files.
v2:
- Keep using request_firmware() instead of firmware_request_nowarn().
(Jani)
v3:
- Keep current DMC paths instead of directly using unversioned ones,
so that we do not disturb initrd generation.
(Lucas, Rodrigo)
Signed-off-by: Gustavo Sousa
Cc: Jani Nikula
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_dmc.c | 62 ++--
1 file changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 370c91d323fc..2464796c769d 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -42,51 +42,59 @@
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
-#define DMC_PATH(platform, major, minor) \
- "i915/" \
- __stringify(platform) "_dmc_ver" \
- __stringify(major) "_" \
+#define DMC_PATH(platform) \
+ "i915/" __stringify(platform) "_dmc.bin"
+
+/*
+ * New DMC additions should not use this. This is used solely to remain
+ * compatible with systems that have not yet updated DMC blobs to use
+ * unversioned file names.
+ */
+#define DMC_LEGACY_PATH(platform, major, minor) \
+ "i915/" \
+ __stringify(platform) "_dmc_ver"\
+ __stringify(major) "_" \
__stringify(minor) ".bin"
#define DISPLAY_VER13_DMC_MAX_FW_SIZE 0x2
#define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
-#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08)
+#define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
MODULE_FIRMWARE(DG2_DMC_PATH);
-#define ADLP_DMC_PATH DMC_PATH(adlp, 2, 16)
+#define ADLP_DMC_PATH DMC_LEGACY_PATH(adlp, 2, 16)
MODULE_FIRMWARE(ADLP_DMC_PATH);
-#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
+#define ADLS_DMC_PATH DMC_LEGACY_PATH(adls, 2, 01)
MODULE_FIRMWARE(ADLS_DMC_PATH);
-#define DG1_DMC_PATH DMC_PATH(dg1, 2, 02)
+#define DG1_DMC_PATH DMC_LEGACY_PATH(dg1, 2, 02)
MODULE_FIRMWARE(DG1_DMC_PATH);
-#define RKL_DMC_PATH DMC_PATH(rkl, 2, 03)
+#define RKL_DMC_PATH DMC_LEGACY_PATH(rkl, 2, 03)
MODULE_FIRMWARE(RKL_DMC_PATH);
-#define TGL_DMC_PATH DMC_PATH(tgl, 2, 12)
+#define TGL_DMC_PATH DMC_LEGACY_PATH(tgl, 2, 12)
MODULE_FIRMWARE(TGL_DMC_PATH);
-#define ICL_DMC_PATH DMC_PATH(icl, 1, 09)
+#define ICL_DMC_PATH DMC_LEGACY_PATH(icl, 1, 09)
#define ICL_DMC_MAX_FW_SIZE0x6000
MODULE_FIRMWARE(ICL_DMC_PATH);
-#define GLK_DMC_PATH DMC_PATH(glk, 1, 04)
+#define GLK_DMC_PATH DMC_LEGACY_PATH(glk, 1, 04)
#define GLK_DMC_MAX_FW_SIZE0x4000
MODULE_FIRMWARE(GLK_DMC_PATH);
-#define KBL_DMC_PATH DMC_PATH(kbl, 1, 04)
+#define KBL_DMC_PATH DMC_LEGACY_PATH(kbl, 1, 04)
#define KBL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
MODULE_FIRMWARE(KBL_DMC_PATH);
-#define SKL_DMC_PATH DMC_PATH(skl, 1, 27)
+#define SKL_DMC_PATH DMC_LEGACY_PATH(skl, 1, 27)
#define SKL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
MODULE_FIRMWARE(SKL_DMC_PATH);
-#define BXT_DMC_PATH DMC_PATH(bxt, 1, 07)
+#define BXT_DMC_PATH DMC_LEGACY_PATH(bxt, 1, 07)
#define BXT_DMC_MAX_FW_SIZE0x3000
MODULE_FIRMWARE(BXT_DMC_PATH);
@@ -845,16 +853,38 @@ static void intel_dmc_runtime_pm_put(struct
drm_i915_private *dev_priv)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
}
+static const char *dmc_fallback_path(struct drm_i915_private *i915)
+{
+ /* No fallback paths for now. */
+ return NULL;
+}
+
static void dmc_load_work_fn(struct work_struct *work)
{
struct drm_i915_private *dev_priv;
struct intel_dmc *dmc;
const struct firmware *fw = NULL;
+ const char *fallback_path;
+ int err;
dev_priv = conta
[Intel-gfx] [PATCH 0/2] Use unversioned blob path for ADLP DMC
This series introduces the use of unversioned blob path for ADLP DMC, which begins using the new convention as of v2.18. In order not to cause regressions with systems not having linux-firmware up to date, we recall a patch from [1] that adds a fallback mechanism to load from the latest versioned path in case the unversioned one is not found. IMPORTANT: Prior to applying this, we need to wait for a PR to linux-firmware with the proper update to be applied. I will create such PR after this series is accepted and CI results are good. [1]: "drm/i915/dmc: Make firmware loading backwards-compatible" https://patchwork.freedesktop.org/series/112116/ Signed-off-by: Gustavo Sousa Gustavo Sousa (2): drm/i915/dmc: Prepare to use unversioned paths drm/i915/dmc: Use unversioned path for ADLP drivers/gpu/drm/i915/display/intel_dmc.c | 66 ++-- 1 file changed, 50 insertions(+), 16 deletions(-) -- 2.39.0
Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Fix request locking during error capture & debugfs dump
On 20/01/2023 23:28, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
In addition, intel_guc_find_hung_context() was not acquiring the
correct spinlock before searching the request list. So fix that up
too. While at it, add some extra whitespace padding for readability.
Is this part splittable into a separate patch?
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
v3: Add a _get suffix to intel_context_find_active_request now that it
grabs a reference (Daniele).
Fixes: dc0dad365c5e ("drm/i915/guc: Fix for error capture after full GPU reset with
GuC")
Fixes: 573ba126aef3 ("drm/i915/guc: Capture error state on context reset")
Cc: Matthew Brost
Cc: John Harrison
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Andrzej Hajda
Cc: Matthew Auld
Cc: Matt Roper
Cc: Umesh Nerlige Ramappa
Cc: Michael Cheng
Cc: Lucas De Marchi
Cc: Tejas Upadhyay
Cc: Andy Shevchenko
Cc: Aravind Iddamsetty
Cc: Alan Previn
Cc: Bruce Chang
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 3 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++---
5 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e94365b08f1ef..4285c1c71fa12 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,7 +528,7 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
-struct i915_request *intel_context_find_active_request(struct intel_context *ce)
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce)
TBH I don't "dig" this name, it's a bit on the long side and feels out of
character. I won't insist it be changed, but if get really has to be included in the name
I would be happy with intel_context_get_active_request().
{
struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
@@ -552,6 +552,8 @@ struct i915_request
*intel_context_find_active_request(struct intel_context *ce)
active = rq;
}
+ if (active)
+ active = i915_request_get_rcu(active);
spin_unlock_irqrestore(&parent->guc_state.lock, flags);
return active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index fb62b7b8cbcda..ccc80c6607ca8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -268,8 +268,7 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce);
-struct i915_request *
-intel_context_find_active_request(struct intel_context *ce);
+struct i915_request *intel_context_find_active_request_get(struct
intel_context *ce);
static inline bool intel_context_is_barrier(const struct intel_context *ce)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 922f1bb22dc68..fbc0a81617e89 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2237,9 +2237,11 @@ static void engine_dump_active_requests(struct
intel_engine_cs *engine, struct d
if (guc) {
ce = intel_engine_get_hung_context(engine);
if (ce)
- hung_rq = intel_context_find_acti
Re: [Intel-gfx] [PATCH v2.1] drm/i915: Add _PICK_EVEN_2RANGES()
> -Original Message- > From: De Marchi, Lucas > Sent: Monday, January 23, 2023 9:16 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Srivatsa, Anusha ; Jani Nikula > ; De Marchi, Lucas > Subject: [PATCH v2.1] drm/i915: Add _PICK_EVEN_2RANGES() > > It's a constant pattern in the driver to need to use 2 ranges of MMIOs based > on > port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() > needs to be used. Using _PICK() is discouraged due to some reasons like: > > 1) It increases the code size since the array is declared >in each call site > 2) Developers need to be careful not to incur an >out-of-bounds array access > 3) Developers need to be careful that the indexes match the >table. For that it may be that the table needs to contain >holes, making (1) even worse. > > Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one > to use depending on the index value. > > v2: Fix the address expansion in the example (Anusha) > > Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/i915_reg_defs.h | 28 > 1 file changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h > b/drivers/gpu/drm/i915/i915_reg_defs.h > index be43580a6979..bab6a9ec2ddd 100644 > --- a/drivers/gpu/drm/i915/i915_reg_defs.h > +++ b/drivers/gpu/drm/i915/i915_reg_defs.h > @@ -119,6 +119,34 @@ > */ > #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) > > +/* > + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. > + * The first range is used for indexes below @__c_index, and the second > + * range is used for anything above it. Example:: > + * > + * #define _FOO_A0xf000 > + * #define _FOO_B0xf004 > + * #define _FOO_C0xf008 > + * #define _SUPER_FOO_A 0xa000 > + * #define _SUPER_FOO_B 0xa100 > + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3, > \ > + * _FOO_A, _FOO_B, > \ > + * _SUPER_FOO_A, _SUPER_FOO_B)) > + * > + * This expands to: > + * 0: 0xf000, > + * 1: 0xf004, > + * 2: 0xf008, > + * 3: 0xa000, > + * 4: 0xa100, > + * 5: 0xa200, > + * ... > + */ > +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) > \ > + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + > \ > + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : > \ > +_PICK_EVEN((__index) - (__c_index), __c, > __d))) > + > /* > * Given the arbitrary numbers in varargs, pick the 0-based __index'th > number. > * > -- > 2.39.0
[Intel-gfx] [PATCH v2.1] drm/i915: Add _PICK_EVEN_2RANGES()
It's a constant pattern in the driver to need to use 2 ranges of MMIOs based on port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged due to some reasons like: 1) It increases the code size since the array is declared in each call site 2) Developers need to be careful not to incur an out-of-bounds array access 3) Developers need to be careful that the indexes match the table. For that it may be that the table needs to contain holes, making (1) even worse. Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one to use depending on the index value. v2: Fix the address expansion in the example (Anusha) Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_reg_defs.h | 28 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h b/drivers/gpu/drm/i915/i915_reg_defs.h index be43580a6979..bab6a9ec2ddd 100644 --- a/drivers/gpu/drm/i915/i915_reg_defs.h +++ b/drivers/gpu/drm/i915/i915_reg_defs.h @@ -119,6 +119,34 @@ */ #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) +/* + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. + * The first range is used for indexes below @__c_index, and the second + * range is used for anything above it. Example:: + * + * #define _FOO_A 0xf000 + * #define _FOO_B 0xf004 + * #define _FOO_C 0xf008 + * #define _SUPER_FOO_A0xa000 + * #define _SUPER_FOO_B0xa100 + * #define FOO(x) _MMIO(_PICK_EVEN_RANGES(x, 3, \ + * _FOO_A, _FOO_B, \ + * _SUPER_FOO_A, _SUPER_FOO_B)) + * + * This expands to: + * 0: 0xf000, + * 1: 0xf004, + * 2: 0xf008, + * 3: 0xa000, + * 4: 0xa100, + * 5: 0xa200, + * ... + */ +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) \ + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + \ +((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : \ + _PICK_EVEN((__index) - (__c_index), __c, __d))) + /* * Given the arbitrary numbers in varargs, pick the 0-based __index'th number. * -- 2.39.0
Re: [Intel-gfx] [PATCH] drm/i915: Avoid potential vm use-after-free
+ some more people based on e1a7ab4fca0c
On 19/01/2023 17:32, Rob Clark wrote:
From: Rob Clark
Adding the vm to the vm_xa table makes it visible to userspace, which
could try to race with us to close the vm. So we need to take our extra
reference before putting it in the table.
Signed-off-by: Rob Clark
---
Note, you could list commit e1a7ab4fca0c ("drm/i915: Remove the vm open
count") as the "fixed" commit, but really the issue seems to go back
much further (with the fix needing some backporting in the process).
It would probably be rather essential to identify the correct Fixes: tag.
Since Thomas, Matt and Niranjana you were directly involved in the patch
which changed significantly how this works, perhaps there is something
still somewhat easily retrievable from your memory lanes to help with this?
Regards,
Tvrtko
drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 6250de9b9196..e4b78ab4773b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private
*file_priv,
vm = ctx->vm;
GEM_BUG_ON(!vm);
+ /*
+* Get a reference for the allocated handle. Once the handle is
+* visible in the vm_xa table, userspace could try to close it
+* from under our feet, so we need to hold the extra reference
+* first.
+*/
+ i915_vm_get(vm);
+
err = xa_alloc(&file_priv->vm_xa, &id, vm, xa_limit_32b, GFP_KERNEL);
- if (err)
+ if (err) {
+ i915_vm_put(vm);
return err;
-
- i915_vm_get(vm);
+ }
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->value = id;
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev4)
== Series Details ==
Series: drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev4)
URL : https://patchwork.freedesktop.org/series/111433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12619_full -> Patchwork_111433v4_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/index.html
Participating hosts (11 -> 10)
--
Additional (1): shard-tglu-9
Missing(2): pig-skl-6260u pig-kbl-iris
New tests
-
New tests have been introduced between CI_DRM_12619_full and
Patchwork_111433v4_full:
### New IGT tests (6) ###
* igt@gem_exec_schedule@noreorder-priority@vcs1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@gem_spin_batch@engines@vcs1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@gem_spin_batch@resubmit-new@vcs1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@i915_hangman@detector@vcs1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@i915_hangman@engine-engine-hang@vcs1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s
* igt@i915_hangman@engine-error-state-capture@vcs1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_111433v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][1] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-glk: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3886]) +4
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +41 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2122])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/shard-glk6/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ac-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk7/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ac-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a1:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a1.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#658])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@kms_psr2...@overlay-plane-update-sf-dmg-area.html
* igt@kms_vblank@pipe-b-accuracy-idle:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#43])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/shard-glk1/igt@kms_vbl...@pipe-b-accuracy-idle.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk9/igt@kms_vbl...@pipe-b-accuracy-idle.html
* igt@kms_writeback@writeback-fb-id:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2437])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@kms_writeb...@writeback-fb-id.html
* igt@sysfs_clients@fair-0:
- shard-glk: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2994])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/shard-glk5/igt@sysfs_clie...@fair-0.html
Possible fixes
* igt@fbdev@info:
- {shard-rkl}:[SKIP][16] ([i915#2582
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
On Mon, Jan 23, 2023 at 08:15:16AM -0800, Anusha Srivatsa wrote: -Original Message- From: Jani Nikula Sent: Monday, January 23, 2023 3:01 AM To: De Marchi, Lucas ; Srivatsa, Anusha Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() On Sat, 21 Jan 2023, Lucas De Marchi wrote: > On Fri, Jan 20, 2023 at 10:14:19PM -0800, Anusha Srivatsa wrote: >> >> >>> -Original Message- >>> From: Intel-gfx On Behalf >>> Of Lucas De Marchi >>> Sent: Friday, January 20, 2023 11:35 AM >>> To: intel-gfx@lists.freedesktop.org >>> Cc: De Marchi, Lucas ; dri- >>> de...@lists.freedesktop.org >>> Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add >>> _PICK_EVEN_2RANGES() >>> >>> It's a constant pattern in the driver to need to use 2 ranges of >>> MMIOs based on port, phy, pll, etc. When that happens, instead of >>> using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged due to some reasons like: >>> >>> 1) It increases the code size since the array is declared >>>in each call site >>> 2) Developers need to be careful not to incur an >>>out-of-bounds array access >>> 3) Developers need to be careful that the indexes match the >>>table. For that it may be that the table needs to contain >>>holes, making (1) even worse. >>> >>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects >>> which one to use depending on the index value. >>> >>> Signed-off-by: Lucas De Marchi >>> --- >>> drivers/gpu/drm/i915/i915_reg_defs.h | 28 >>> >>> 1 file changed, 28 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h >>> b/drivers/gpu/drm/i915/i915_reg_defs.h >>> index be43580a6979..b7ec87464d69 100644 >>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h >>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h >>> @@ -119,6 +119,34 @@ >>> */ >>> #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - >>> (__a))) >>> >>> +/* >>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. >>> + * The first range is used for indexes below @__c_index, and the >>> +second >>> + * range is used for anything above it. Example:: >>> + * >>> + * #define _FOO_A 0xf000 >>> + * #define _FOO_B 0xf004 >>> + * #define _FOO_C 0xf008 >>> + * #define _SUPER_FOO_A 0xa000 >>> + * #define _SUPER_FOO_B 0xa100 >>> + * #define FOO(x) _MMIO(_PICK_EVEN_RANGES(x, 3, >>>\ >>> + * _FOO_A, _FOO_B, >>>\ >>> + * _SUPER_FOO_A, _SUPER_FOO_B)) >>> + * >>> + * This expands to: >>> + *0: 0xf000, >>> + *1: 0xf004, >>> + *2: 0xf008, >>> + *3: 0xa100, >>You mean 3:0xa000 > > doesn't really matter. This is an example of register addresses. They > don't need to start from 0, it's whatever the hw gives us. I think the point is that the example is inconsistent between _SUPER_FOO_A and "3: 0xa100". Yes. It's the inconsistency with _SUPER_FOO_A that I was pointing out. ah, ok. I will send a fixup to this patch. thanks Lucas De Marchi
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
> -Original Message- > From: Jani Nikula > Sent: Monday, January 23, 2023 3:01 AM > To: De Marchi, Lucas ; Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() > > On Sat, 21 Jan 2023, Lucas De Marchi wrote: > > On Fri, Jan 20, 2023 at 10:14:19PM -0800, Anusha Srivatsa wrote: > >> > >> > >>> -Original Message- > >>> From: Intel-gfx On Behalf > >>> Of Lucas De Marchi > >>> Sent: Friday, January 20, 2023 11:35 AM > >>> To: intel-gfx@lists.freedesktop.org > >>> Cc: De Marchi, Lucas ; dri- > >>> de...@lists.freedesktop.org > >>> Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add > >>> _PICK_EVEN_2RANGES() > >>> > >>> It's a constant pattern in the driver to need to use 2 ranges of > >>> MMIOs based on port, phy, pll, etc. When that happens, instead of > >>> using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is > >>> discouraged > due to some reasons like: > >>> > >>> 1) It increases the code size since the array is declared > >>>in each call site > >>> 2) Developers need to be careful not to incur an > >>>out-of-bounds array access > >>> 3) Developers need to be careful that the indexes match the > >>>table. For that it may be that the table needs to contain > >>>holes, making (1) even worse. > >>> > >>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects > >>> which one to use depending on the index value. > >>> > >>> Signed-off-by: Lucas De Marchi > >>> --- > >>> drivers/gpu/drm/i915/i915_reg_defs.h | 28 > >>> > >>> 1 file changed, 28 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h > >>> b/drivers/gpu/drm/i915/i915_reg_defs.h > >>> index be43580a6979..b7ec87464d69 100644 > >>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h > >>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h > >>> @@ -119,6 +119,34 @@ > >>> */ > >>> #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - > >>> (__a))) > >>> > >>> +/* > >>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address > offsets. > >>> + * The first range is used for indexes below @__c_index, and the > >>> +second > >>> + * range is used for anything above it. Example:: > >>> + * > >>> + * #define _FOO_A0xf000 > >>> + * #define _FOO_B0xf004 > >>> + * #define _FOO_C0xf008 > >>> + * #define _SUPER_FOO_A 0xa000 > >>> + * #define _SUPER_FOO_B 0xa100 > >>> + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3, > >>> \ > >>> + * _FOO_A, _FOO_B, > >>> \ > >>> + * _SUPER_FOO_A, > >>> _SUPER_FOO_B)) > >>> + * > >>> + * This expands to: > >>> + * 0: 0xf000, > >>> + * 1: 0xf004, > >>> + * 2: 0xf008, > >>> + * 3: 0xa100, > >>You mean 3:0xa000 > > > > doesn't really matter. This is an example of register addresses. They > > don't need to start from 0, it's whatever the hw gives us. > > I think the point is that the example is inconsistent between _SUPER_FOO_A and > "3: 0xa100". Yes. It's the inconsistency with _SUPER_FOO_A that I was pointing out. Anusha > BR, > Jani. > > > > > Lucas De Marchi > > > >> > >>> + * 4: 0xa200, > >>4:0xa100 > >> > >>> + * 5: 0xa300, > >>5:0xa200 > >> > >>Anusha > >>> + * ... > >>> + */ > >>> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) > >>> \ > >>> + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + > >>> \ > >>> + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : > >>> \ > >>> +_PICK_EVEN((__index) - (__c_index), __c, > >>> __d))) > >>> + > >>> /* > >>> * Given the arbitrary numbers in varargs, pick the 0-based __index'th > number. > >>> * > >>> -- > >>> 2.39.0 > >> > > -- > Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: implement async_flip mode per plane tracking (rev3)
== Series Details ==
Series: drm/i915: implement async_flip mode per plane tracking (rev3)
URL : https://patchwork.freedesktop.org/series/108371/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12622 -> Patchwork_108371v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/index.html
Participating hosts (39 -> 38)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_108371v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7828])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/fi-rkl-11600/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_module_load@load:
- fi-ctg-p8600: [DMESG-WARN][2] ([i915#6020]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/fi-ctg-p8600/igt@i915_module_l...@load.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/fi-ctg-p8600/igt@i915_module_l...@load.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][4] ([i915#7699]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [TIMEOUT][6] ([i915#6794]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/fi-rkl-guc/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][8] ([i915#6257]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-rpls-2/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/bat-rpls-2/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][10] ([i915#6367]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][12] ([i915#4817]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-5: [FAIL][14] ([fdo#103375]) -> [PASS][15] +3 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#6020]: https://gitlab.freedesktop.org/drm/intel/issues/6020
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12622 -> Patchwork_108371v3
CI-20190529: 20190529
CI_DRM_12622: 93e8ce8fb03496d8d0ccf15e7363563af90a4f8f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7131: 13b07163b012f6a195463bc14c06b84ecbd9f094 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108371v3: 93e8ce8fb03496d8d0ccf15e7363563af90a4f8f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8341acf98e17 drm/i915: implement async_flip mode per plane tracking
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108371v3/index.html
Re: [Intel-gfx] [PULL] drm-misc-next
Hi Am 23.01.23 um 16:23 schrieb John Paul Adrian Glaubitz: Hi Thomas! On 1/23/23 16:13, Thomas Zimmermann wrote: Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via Is the Rage 128 GPU still supported via the generic modesetting driver? I'm asking because, we're still supporting PowerMacs in Debian Ports of which some of those are sporting a Rage 128 GPU. Similar question applies to the i810 GPU used in some old ThinkPads, for example. Yes, all of those chips are still supported by the generic modesetting drivers and even the old userspace Xorg drivers. OK, good to know. The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Correct me if I'm wrong, but I thought that's what Mesa Classic was forked off for? AFAIK Mesa classic is for old radeon, i915 and old nouveau code. The so-called amber branch: https://docs.mesa3d.org/amber.html But the removed code is for even older hardware. https://docs.mesa3d.org/systems.html#deprecated-systems-and-drivers Best regards Thomas Thanks, Adrian -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[Intel-gfx] [PATCH] drm/i915: Use uabi engines for the default engine map
From: Tvrtko Ursulin
Default engine map is exactly about uabi engines so no excuse not to use
the appropriate iterator to populate it.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 454e73a433c8..42a39e103d7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1096,16 +1096,15 @@ static struct i915_gem_engines *alloc_engines(unsigned
int count)
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
struct intel_sseu rcs_sseu)
{
- const struct intel_gt *gt = to_gt(ctx->i915);
+ const unsigned int max = I915_NUM_ENGINES;
struct intel_engine_cs *engine;
struct i915_gem_engines *e, *err;
- enum intel_engine_id id;
- e = alloc_engines(I915_NUM_ENGINES);
+ e = alloc_engines(max);
if (!e)
return ERR_PTR(-ENOMEM);
- for_each_engine(engine, gt, id) {
+ for_each_uabi_engine(engine, ctx->i915) {
struct intel_context *ce;
struct intel_sseu sseu = {};
int ret;
@@ -1113,7 +1112,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx,
if (engine->legacy_idx == INVALID_ENGINE)
continue;
- GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
+ GEM_BUG_ON(engine->legacy_idx >= max);
GEM_BUG_ON(e->engines[engine->legacy_idx]);
ce = intel_context_create(engine);
--
2.25.1
Re: [Intel-gfx] [PULL] drm-misc-next
Hi Am 23.01.23 um 16:00 schrieb John Paul Adrian Glaubitz: Hi Thomas! Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via Is the Rage 128 GPU still supported via the generic modesetting driver? I'm asking because, we're still supporting PowerMacs in Debian Ports of which some of those are sporting a Rage 128 GPU. Similar question applies to the i810 GPU used in some old ThinkPads, for example. Yes, all of those chips are still supported by the generic modesetting drivers and even the old userspace Xorg drivers. The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Best regards Thomas Thanks, Adrian -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: implement async_flip mode per plane tracking (rev3)
== Series Details == Series: drm/i915: implement async_flip mode per plane tracking (rev3) URL : https://patchwork.freedesktop.org/series/108371/ State : warning == Summary == Error: dim checkpatch failed 4169010b7b5e drm/i915: implement async_flip mode per plane tracking -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set total: 0 errors, 1 warnings, 0 checks, 52 lines checked
Re: [Intel-gfx] [PATCH v4] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
On Mon, 2023-01-23 at 14:29 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 23.01.23 um 13:20 schrieb Hogander, Jouni:
> > On Mon, 2023-01-23 at 12:38 +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 23.01.23 um 08:44 schrieb Jouni Högander:
> > > > After disconnecting damage worker from update logic it's left
> > > > to
> > > > fbdev
> > > > emulation implementation to have fb_dirty function. Currently
> > > > intel
> > > > fbdev doesn't have it. This is causing problems to features
> > > > (PSR,
> > > > FBC,
> > > > DRRS) relying on dirty callback.
> > > >
> > > > Implement simple fb_dirty callback to deliver notifications
> > > > about
> > > > updates
> > > > in fb console.
> > > >
> > > > v4: Add proper Fixes tag and modify commit message
> > > > v3: Check damage clip
> > > > v2: Improved commit message and added Fixes tag
> > > >
> > > > Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker
> > > > from
> > > > update logic")
> > > > Cc: Ville Syrjälä
> > > > Cc: Thomas Zimmermann
> > > > Cc: Jani Nikula
> > > > Signed-off-by: Jouni Högander
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_fbdev.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > > b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > > index 19f3b5d92a55..d39db8050c69 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > > @@ -321,8 +321,20 @@ static int intelfb_create(struct
> > > > drm_fb_helper
> > > > *helper,
> > > > return ret;
> > > > }
> > > >
> > > > +static int intelfb_dirty(struct drm_fb_helper *helper, struct
> > > > drm_clip_rect *clip)
> > > > +{
> > > > + if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
> > > > + return 0;
> > > > +
> > > > + if (helper->fb->funcs->dirty)
> > > > + return helper->fb->funcs->dirty(helper->fb,
> > > > NULL,
> > > > 0, 0, clip, 1);
> > >
> > > Didn't I nack this approach already? You shouldn't set fb_dirty.
> > > The
> > > better solution was to implement i915-specific helpers for write,
> > > fillarea, copyarea and blit. Those should call intelfb_dirty()
> > > directly
> > > after performing the output. And IIRC you already implemented
> > > this.
> >
> > I have implemented such thing. I didn't took it as a nack back
> > then.
> > Last comment from you was:
> >
> > "if you go with fb_dirty, please implement the clipping
> > test in your callback."
> >
> > and v3 was prepared to address that comment. My thinking was that
> > this
> > is only for fb console, but Ville Syrjälä commented that there is
> > more
> > than console so I sticked in this approach.
> >
> > So you think I should just drop idea of setting dirty callback and
> > implement those i915-specific helpers?
>
> Ah OK, so I remembered incorrectly.
>
> A few things have changed since my original comment and I worked on
> fbdev helper a bit. The thing is that fb_dirty will likely go away
> at
> some point (together with the rest of drm_fb_helper_funcs). IOW at
> some
> point, you'll need those i915 functions anyways. Not using fb_dirty
> now
> will safe that work later on.
Ok, I will modify the patch accordingly.
>
> Best regards
> Thomas
>
> >
> > >
> > > Best regards
> > > Thomas
> > >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static const struct drm_fb_helper_funcs
> > > > intel_fb_helper_funcs = {
> > > > .fb_probe = intelfb_create,
> > > > + .fb_dirty = intelfb_dirty,
> > > > };
> > > >
> > > > static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
> > >
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > (HRB 36809, AG Nürnberg)
> > > Geschäftsführer: Ivo Totev
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
On Sun, Jan 22, 2023 at 06:57:24AM +, Usyskin, Alexander wrote:
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > index d50354bfb993..bef6d7f8ac55 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
> > > @@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct
> > device *i915_kdev,
> > > intel_wakeref_t wakeref;
> > > int ret = 0;
> > >
> > > + if (!HAS_HECI_PXP(i915) &&
> > > + drm_WARN_ON(&i915->drm, !device_link_add(i915_kdev,
> > tee_kdev,
> >
> > I don't like the action here hidden behind the drm_WARN_ON.
> > Please notice that almost every use of this and other helpers like
> > this expect the param as a failure. Not an actual action. So,
> > most of lazy readers like me might ignore that the main function
> > is actually a param inside this warn condition.
> >
> Honestly, copy-pasted from drivers/gpu/drm/i915/display/intel_audio.c +1266
> I don't have deep knowledge of drm macros, so thought this should be ok.
> Can make it any other form that acceptable in drm tree...
something like I suggested in my previous reply please.
>
> > We should probably stash the link as well...
> >
> > pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
> >
> > so in the end below, instead of checking the HAS_HECI_PXP again
> > and use the remove version you check the dev_link and use the del
> > function.
> >
> > something like:
> >
> > if (pxp->dev_link)
> >device_link_del(pxp->dev_link);
> >
> Not sure that this simplification warrants additional clutter in struct.
>
> > Also, do you really need the WARN to see the stack when this happens
> > or you already know the callers?
> > Why not a simple drm_error msg?
> >
> > if (!HAS_HECI_PXP(i915) {
> > pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
> > if (!pxp->dev_link) {
> >drm_error();
> >return -ESOMETHING;
> >
> > > DL_FLAG_STATELESS)))
> >
> > do we need the RPM in sync as well?
> > I mean:
> >
> > DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME)))
> >
> > ?
>
> No, the mei device should not be active all the time when i915 is active,
> only when pxp requires it.
okay then
>
> >
> > > + return -ENOMEM;
> >
> > why ENOMEM?
> Copy-paste from i915 audio.
It doesn't make sense to me.
Looking to other derivers -ENODEV or -EINVAL seems to be
the most used choices...
looking to the error codes probably ECHILD would make sense
but no one is using it... so let's stay with ENODEV?!
>
> >
> > > +
> > > mutex_lock(&pxp->tee_mutex);
> > > pxp->pxp_component = data;
> > > pxp->pxp_component->tee_dev = tee_kdev;
> > > @@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct
> > device *i915_kdev,
> > > mutex_lock(&pxp->tee_mutex);
> > > pxp->pxp_component = NULL;
> > > mutex_unlock(&pxp->tee_mutex);
> > > +
> > > + if (!HAS_HECI_PXP(i915))
> > > + device_link_remove(i915_kdev, tee_kdev);
> > > }
> > >
> > > static const struct component_ops i915_pxp_tee_component_ops = {
> > > --
> > > 2.39.0
> > >
Re: [Intel-gfx] [PATCH v4] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
Hi
Am 23.01.23 um 13:20 schrieb Hogander, Jouni:
On Mon, 2023-01-23 at 12:38 +0100, Thomas Zimmermann wrote:
Hi
Am 23.01.23 um 08:44 schrieb Jouni Högander:
After disconnecting damage worker from update logic it's left to
fbdev
emulation implementation to have fb_dirty function. Currently intel
fbdev doesn't have it. This is causing problems to features (PSR,
FBC,
DRRS) relying on dirty callback.
Implement simple fb_dirty callback to deliver notifications about
updates
in fb console.
v4: Add proper Fixes tag and modify commit message
v3: Check damage clip
v2: Improved commit message and added Fixes tag
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from
update logic")
Cc: Ville Syrjälä
Cc: Thomas Zimmermann
Cc: Jani Nikula
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 19f3b5d92a55..d39db8050c69 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -321,8 +321,20 @@ static int intelfb_create(struct drm_fb_helper
*helper,
return ret;
}
+static int intelfb_dirty(struct drm_fb_helper *helper, struct
drm_clip_rect *clip)
+{
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty)
+ return helper->fb->funcs->dirty(helper->fb, NULL,
0, 0, clip, 1);
Didn't I nack this approach already? You shouldn't set fb_dirty. The
better solution was to implement i915-specific helpers for write,
fillarea, copyarea and blit. Those should call intelfb_dirty()
directly
after performing the output. And IIRC you already implemented this.
I have implemented such thing. I didn't took it as a nack back then.
Last comment from you was:
"if you go with fb_dirty, please implement the clipping
test in your callback."
and v3 was prepared to address that comment. My thinking was that this
is only for fb console, but Ville Syrjälä commented that there is more
than console so I sticked in this approach.
So you think I should just drop idea of setting dirty callback and
implement those i915-specific helpers?
Ah OK, so I remembered incorrectly.
A few things have changed since my original comment and I worked on
fbdev helper a bit. The thing is that fb_dirty will likely go away at
some point (together with the rest of drm_fb_helper_funcs). IOW at some
point, you'll need those i915 functions anyways. Not using fb_dirty now
will safe that work later on.
Best regards
Thomas
Best regards
Thomas
+
+ return 0;
+}
+
static const struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.fb_probe = intelfb_create,
+ .fb_dirty = intelfb_dirty,
};
static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] [PATCH] drm/i915: Implement workaround for CDCLK PLL disable/enable
It was reported that we might get a hung and loss of register access in
some cases when CDCLK PLL is disabled and then enabled, while squashing
is enabled.
As a workaround it was proposed by HW team that SW should disable squashing
when CDCLK PLL is being reenabled.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 0c107a38f9d0..e338f288c9ac 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1801,6 +1801,13 @@ static bool
cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
return true;
}
+static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
+{
+ return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
+ && dev_priv->display.cdclk.hw.vco > 0
+ && HAS_CDCLK_SQUASH(dev_priv));
+}
+
static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
@@ -1815,9 +1822,12 @@ static void _bxt_set_cdclk(struct drm_i915_private
*dev_priv,
!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
- } else if (DISPLAY_VER(dev_priv) >= 11)
+ } else if (DISPLAY_VER(dev_priv) >= 11) {
+ if (pll_enable_wa_needed(dev_priv))
+ dg2_cdclk_squash_program(dev_priv, 0);
+
icl_cdclk_pll_update(dev_priv, vco);
- else
+ } else
bxt_cdclk_pll_update(dev_priv, vco);
waveform = cdclk_squash_waveform(dev_priv, cdclk);
--
2.37.3
Re: [Intel-gfx] [PATCH 6/7] drm/i915: move I915_COLOR_UNEVICTABLE to i915_gem_gtt.h
On Fri, 20 Jan 2023, Rodrigo Vivi wrote: > On Wed, Jan 18, 2023 at 03:15:37PM +0200, Jani Nikula wrote: >> Declutter i915_drv.h. >> >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/i915_drv.h | 2 -- >> drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ >> 2 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h >> b/drivers/gpu/drm/i915/i915_drv.h >> index eed552e507dc..d12c7932677a 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.h >> +++ b/drivers/gpu/drm/i915/i915_drv.h >> @@ -68,8 +68,6 @@ struct drm_i915_clock_gating_funcs; >> struct vlv_s0ix_state; >> struct intel_pxp; >> >> -#define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space >> */ >> - >> #define GEM_QUIRK_PIN_SWIZZLED_PAGESBIT(0) >> >> /* Data Stolen Memory (DSM) aka "i915 stolen memory" */ >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h >> b/drivers/gpu/drm/i915/i915_gem_gtt.h > > same question here... used in gem_evict which does not directly include this I'd already pushed these by the time you commented. :( Am I being rude if I say I kind of expect some header cleanup and #include mess untangling from the gem folks too, and won't follow-up on this myself? BR, Jani. > >> index 243419783052..3d77679bf211 100644 >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h >> @@ -18,6 +18,8 @@ struct drm_i915_gem_object; >> struct i915_address_space; >> struct i915_gem_ww_ctx; >> >> +#define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space >> */ >> + >> int __must_check i915_gem_gtt_prepare_pages(struct drm_i915_gem_object *obj, >> struct sg_table *pages); >> void i915_gem_gtt_finish_pages(struct drm_i915_gem_object *obj, >> -- >> 2.34.1 >> -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v4] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
On Mon, 2023-01-23 at 14:20 +0200, Jouni Högander wrote:
> On Mon, 2023-01-23 at 12:38 +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 23.01.23 um 08:44 schrieb Jouni Högander:
> > > After disconnecting damage worker from update logic it's left to
> > > fbdev
> > > emulation implementation to have fb_dirty function. Currently
> > > intel
> > > fbdev doesn't have it. This is causing problems to features (PSR,
> > > FBC,
> > > DRRS) relying on dirty callback.
> > >
> > > Implement simple fb_dirty callback to deliver notifications about
> > > updates
> > > in fb console.
> > >
> > > v4: Add proper Fixes tag and modify commit message
> > > v3: Check damage clip
> > > v2: Improved commit message and added Fixes tag
> > >
> > > Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker
> > > from
> > > update logic")
> > > Cc: Ville Syrjälä
> > > Cc: Thomas Zimmermann
> > > Cc: Jani Nikula
> > > Signed-off-by: Jouni Högander
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fbdev.c | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > index 19f3b5d92a55..d39db8050c69 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > > @@ -321,8 +321,20 @@ static int intelfb_create(struct
> > > drm_fb_helper
> > > *helper,
> > > return ret;
> > > }
> > >
> > > +static int intelfb_dirty(struct drm_fb_helper *helper, struct
> > > drm_clip_rect *clip)
> > > +{
> > > + if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
> > > + return 0;
> > > +
> > > + if (helper->fb->funcs->dirty)
> > > + return helper->fb->funcs->dirty(helper->fb, NULL,
> > > 0, 0, clip, 1);
> >
> > Didn't I nack this approach already? You shouldn't set fb_dirty.
> > The
> > better solution was to implement i915-specific helpers for write,
> > fillarea, copyarea and blit. Those should call intelfb_dirty()
> > directly
> > after performing the output. And IIRC you already implemented
> > this.
>
> I have implemented such thing. I didn't took it as a nack back then.
Meant to say "I haven't implemented such thing". Sorry for the typo.
> Last comment from you was:
>
> "if you go with fb_dirty, please implement the clipping
> test in your callback."
>
> and v3 was prepared to address that comment. My thinking was that
> this
> is only for fb console, but Ville Syrjälä commented that there is
> more
> than console so I sticked in this approach.
>
> So you think I should just drop idea of setting dirty callback and
> implement those i915-specific helpers?
>
> >
> > Best regards
> > Thomas
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static const struct drm_fb_helper_funcs intel_fb_helper_funcs =
> > > {
> > > .fb_probe = intelfb_create,
> > > + .fb_dirty = intelfb_dirty,
> > > };
> > >
> > > static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Ivo Totev
>
Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp
On Sun, 22 Jan 2023, "Usyskin, Alexander" wrote:
>> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > index d50354bfb993..bef6d7f8ac55 100644
>> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > @@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct
>> device *i915_kdev,
>> >intel_wakeref_t wakeref;
>> >int ret = 0;
>> >
>> > + if (!HAS_HECI_PXP(i915) &&
>> > + drm_WARN_ON(&i915->drm, !device_link_add(i915_kdev,
>> tee_kdev,
>>
>> I don't like the action here hidden behind the drm_WARN_ON.
>> Please notice that almost every use of this and other helpers like
>> this expect the param as a failure. Not an actual action. So,
>> most of lazy readers like me might ignore that the main function
>> is actually a param inside this warn condition.
>>
> Honestly, copy-pasted from drivers/gpu/drm/i915/display/intel_audio.c +1266
> I don't have deep knowledge of drm macros, so thought this should be ok.
> Can make it any other form that acceptable in drm tree...
Unfortunately, some pattern being present in the driver does not mean
it's a good example to be emulated. If we copy a bad pattern, it seems
more acceptable, and even more people will copy it.
BR,
Jani.
>
>> We should probably stash the link as well...
>>
>> pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
>>
>> so in the end below, instead of checking the HAS_HECI_PXP again
>> and use the remove version you check the dev_link and use the del
>> function.
>>
>> something like:
>>
>> if (pxp->dev_link)
>>device_link_del(pxp->dev_link);
>>
> Not sure that this simplification warrants additional clutter in struct.
>
>> Also, do you really need the WARN to see the stack when this happens
>> or you already know the callers?
>> Why not a simple drm_error msg?
>>
>> if (!HAS_HECI_PXP(i915) {
>> pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
>> if (!pxp->dev_link) {
>> drm_error();
>> return -ESOMETHING;
>>
>> > DL_FLAG_STATELESS)))
>>
>> do we need the RPM in sync as well?
>> I mean:
>>
>> DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME)))
>>
>> ?
>
> No, the mei device should not be active all the time when i915 is active,
> only when pxp requires it.
>
>>
>> > + return -ENOMEM;
>>
>> why ENOMEM?
> Copy-paste from i915 audio.
>
>>
>> > +
>> >mutex_lock(&pxp->tee_mutex);
>> >pxp->pxp_component = data;
>> >pxp->pxp_component->tee_dev = tee_kdev;
>> > @@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct
>> device *i915_kdev,
>> >mutex_lock(&pxp->tee_mutex);
>> >pxp->pxp_component = NULL;
>> >mutex_unlock(&pxp->tee_mutex);
>> > +
>> > + if (!HAS_HECI_PXP(i915))
>> > + device_link_remove(i915_kdev, tee_kdev);
>> > }
>> >
>> > static const struct component_ops i915_pxp_tee_component_ops = {
>> > --
>> > 2.39.0
>> >
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC 1/2] drm/connector: add connector list iteration with filtering
On Thu, 15 Dec 2022, Daniel Vetter wrote:
> On Wed, Oct 05, 2022 at 01:51:43PM +0300, Jani Nikula wrote:
>> Add new function drm_connector_list_iter_filter_begin() to initialize
>> connector list iterator with a filter function. Subsequent iteration on
>> the list will only return connectors on which the filter function
>> returns true.
>>
>> Cc: Arun R Murthy
>> Cc: Suraj Kandpal
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_connector.c | 57 ++---
>> include/drm/drm_connector.h | 9 ++
>> 2 files changed, 54 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index e3142c8142b3..d54b4b54cecb 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -762,6 +762,29 @@ static struct lockdep_map connector_list_iter_dep_map =
>> {
>> };
>> #endif
>>
>> +/**
>> + * drm_connector_list_iter_filter_begin - initialize a connector_list
>> iterator with filter
>> + * @dev: DRM device
>> + * @iter: connector_list iterator
>> + * @filter: connector filter function
>> + * @filter_context: context to be passed to the filter function
>> + *
>> + * Same as drm_connector_list_iter_begin(), but sets up the iterator to only
>> + * return connectors where filter(connector) returns true.
>> + */
>> +void drm_connector_list_iter_filter_begin(struct drm_device *dev,
>> + struct drm_connector_list_iter *iter,
>> + drm_connector_list_iter_filter_fn
>> filter,
>> + void *filter_context)
>> +{
>> +iter->dev = dev;
>> +iter->conn = NULL;
>> +iter->filter = filter;
>> +iter->filter_context = filter_context;
>> +lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL,
>> _RET_IP_);
>> +}
>> +EXPORT_SYMBOL(drm_connector_list_iter_filter_begin);
>
> So maybe I'm missing the obvious, but can't we just put a for_each_fi
> right after the for_each_connector_iter?
>
> And then maybe provide a default filter to kick out connectors and maybe a
> macro that does the filtered iteration? The iter_begin/next/end is already
> fairly tricky pattern compared to plain for_each macro, I think we should
> try hard to not complicate it further with lots of variants if that's not
> absolutely necessary.
Sorry, dropped the ball here, and lost sight of it.
You mean not have any of this in drm core, and just add the
for_each_if() in local wrappers everywhere?
BR,
Jani.
> -Daniel
>
>
>> +
>> /**
>> * drm_connector_list_iter_begin - initialize a connector_list iterator
>> * @dev: DRM device
>> @@ -775,9 +798,7 @@ static struct lockdep_map connector_list_iter_dep_map = {
>> void drm_connector_list_iter_begin(struct drm_device *dev,
>> struct drm_connector_list_iter *iter)
>> {
>> -iter->dev = dev;
>> -iter->conn = NULL;
>> -lock_acquire_shared_recursive(&connector_list_iter_dep_map, 0, 1, NULL,
>> _RET_IP_);
>> +drm_connector_list_iter_filter_begin(dev, iter, NULL, NULL);
>> }
>> EXPORT_SYMBOL(drm_connector_list_iter_begin);
>>
>> @@ -800,15 +821,8 @@ __drm_connector_put_safe(struct drm_connector *conn)
>> schedule_work(&config->connector_free_work);
>> }
>>
>> -/**
>> - * drm_connector_list_iter_next - return next connector
>> - * @iter: connector_list iterator
>> - *
>> - * Returns: the next connector for @iter, or NULL when the list walk has
>> - * completed.
>> - */
>> -struct drm_connector *
>> -drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
>> +static struct drm_connector *
>> +__drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
>> {
>> struct drm_connector *old_conn = iter->conn;
>> struct drm_mode_config *config = &iter->dev->mode_config;
>> @@ -836,6 +850,25 @@ drm_connector_list_iter_next(struct
>> drm_connector_list_iter *iter)
>>
>> return iter->conn;
>> }
>> +
>> +/**
>> + * drm_connector_list_iter_next - return next connector
>> + * @iter: connector_list iterator
>> + *
>> + * Returns: the next connector for @iter, or NULL when the list walk has
>> + * completed.
>> + */
>> +struct drm_connector *
>> +drm_connector_list_iter_next(struct drm_connector_list_iter *iter)
>> +{
>> +struct drm_connector *connector;
>> +
>> +while ((connector = __drm_connector_list_iter_next(iter)) &&
>> + iter->filter && !iter->filter(connector, iter->filter_context))
>> +;
>> +
>> +return connector;
>> +}
>> EXPORT_SYMBOL(drm_connector_list_iter_next);
>>
>> /**
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 56aee949c6fa..497b98197d3a 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -1868,6 +1868,9 @@ struct drm_tile_group *drm_mode_get_tile_group(struct
>> drm_device *dev,
>> void drm_mode_put
Re: [Intel-gfx] [PATCH v4] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
On Mon, 2023-01-23 at 12:38 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 23.01.23 um 08:44 schrieb Jouni Högander:
> > After disconnecting damage worker from update logic it's left to
> > fbdev
> > emulation implementation to have fb_dirty function. Currently intel
> > fbdev doesn't have it. This is causing problems to features (PSR,
> > FBC,
> > DRRS) relying on dirty callback.
> >
> > Implement simple fb_dirty callback to deliver notifications about
> > updates
> > in fb console.
> >
> > v4: Add proper Fixes tag and modify commit message
> > v3: Check damage clip
> > v2: Improved commit message and added Fixes tag
> >
> > Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from
> > update logic")
> > Cc: Ville Syrjälä
> > Cc: Thomas Zimmermann
> > Cc: Jani Nikula
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_fbdev.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > index 19f3b5d92a55..d39db8050c69 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > @@ -321,8 +321,20 @@ static int intelfb_create(struct drm_fb_helper
> > *helper,
> > return ret;
> > }
> >
> > +static int intelfb_dirty(struct drm_fb_helper *helper, struct
> > drm_clip_rect *clip)
> > +{
> > + if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
> > + return 0;
> > +
> > + if (helper->fb->funcs->dirty)
> > + return helper->fb->funcs->dirty(helper->fb, NULL,
> > 0, 0, clip, 1);
>
> Didn't I nack this approach already? You shouldn't set fb_dirty. The
> better solution was to implement i915-specific helpers for write,
> fillarea, copyarea and blit. Those should call intelfb_dirty()
> directly
> after performing the output. And IIRC you already implemented this.
I have implemented such thing. I didn't took it as a nack back then.
Last comment from you was:
"if you go with fb_dirty, please implement the clipping
test in your callback."
and v3 was prepared to address that comment. My thinking was that this
is only for fb console, but Ville Syrjälä commented that there is more
than console so I sticked in this approach.
So you think I should just drop idea of setting dirty callback and
implement those i915-specific helpers?
>
> Best regards
> Thomas
>
> > +
> > + return 0;
> > +}
> > +
> > static const struct drm_fb_helper_funcs intel_fb_helper_funcs = {
> > .fb_probe = intelfb_create,
> > + .fb_dirty = intelfb_dirty,
> > };
> >
> > static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH] drm/i915: Use uabi engines for the default engine map
On 20/01/2023 19:19, Jonathan Cavitt wrote:
From: Tvrtko Ursulin
Default engine map is exactly about uabi engines so no excuse not to use
the appropriate iterator to populate it.
Okay I guess this was something I did as part of multi-tile enabling
refactor some years ago, so even if it looks a bit head scratching on
it's own it still has a purpose so IMO if someone r-b's it is okay to merge.
Jonathan even you could r-b, but you need to add your s-o-b in any case
and re-send.
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 454e73a433c8..42a39e103d7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1096,16 +1096,15 @@ static struct i915_gem_engines *alloc_engines(unsigned
int count)
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx,
struct intel_sseu rcs_sseu)
{
- const struct intel_gt *gt = to_gt(ctx->i915);
+ const unsigned int max = I915_NUM_ENGINES;
struct intel_engine_cs *engine;
struct i915_gem_engines *e, *err;
- enum intel_engine_id id;
- e = alloc_engines(I915_NUM_ENGINES);
+ e = alloc_engines(max);
if (!e)
return ERR_PTR(-ENOMEM);
- for_each_engine(engine, gt, id) {
+ for_each_uabi_engine(engine, ctx->i915) {
struct intel_context *ce;
struct intel_sseu sseu = {};
int ret;
@@ -1113,7 +1112,7 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx,
if (engine->legacy_idx == INVALID_ENGINE)
continue;
- GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
+ GEM_BUG_ON(engine->legacy_idx >= max);
GEM_BUG_ON(e->engines[engine->legacy_idx]);
ce = intel_context_create(engine);
Re: [Intel-gfx] [PATCH v4] drm/i915/fbdev: Implement fb_dirty for intel custom fb helper
Hi
Am 23.01.23 um 08:44 schrieb Jouni Högander:
After disconnecting damage worker from update logic it's left to fbdev
emulation implementation to have fb_dirty function. Currently intel
fbdev doesn't have it. This is causing problems to features (PSR, FBC,
DRRS) relying on dirty callback.
Implement simple fb_dirty callback to deliver notifications about updates
in fb console.
v4: Add proper Fixes tag and modify commit message
v3: Check damage clip
v2: Improved commit message and added Fixes tag
Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update
logic")
Cc: Ville Syrjälä
Cc: Thomas Zimmermann
Cc: Jani Nikula
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 19f3b5d92a55..d39db8050c69 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -321,8 +321,20 @@ static int intelfb_create(struct drm_fb_helper *helper,
return ret;
}
+static int intelfb_dirty(struct drm_fb_helper *helper, struct drm_clip_rect *clip)
+{
+ if (!(clip->x1 < clip->x2 && clip->y1 < clip->y2))
+ return 0;
+
+ if (helper->fb->funcs->dirty)
+ return helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, clip,
1);
Didn't I nack this approach already? You shouldn't set fb_dirty. The
better solution was to implement i915-specific helpers for write,
fillarea, copyarea and blit. Those should call intelfb_dirty() directly
after performing the output. And IIRC you already implemented this.
Best regards
Thomas
+
+ return 0;
+}
+
static const struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.fb_probe = intelfb_create,
+ .fb_dirty = intelfb_dirty,
};
static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] [PATCH i-g-t v2] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
From: Tvrtko Ursulin
Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.
Also fix a memory leak on the same failure path just so Valgrind runs are
quite.
v2:
* Fix a memory leak in the same failure mode too.
Signed-off-by: Tvrtko Ursulin
Acked-by: Nirmoy Das # v1
---
tools/intel_gpu_top.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..0a1de41b3374 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -340,7 +340,7 @@ static struct engines *discover_engines(char *device)
d = opendir(sysfs_root);
if (!d)
- return NULL;
+ goto err;
while ((dent = readdir(d)) != NULL) {
const char *endswith = "-busy";
@@ -423,10 +423,8 @@ static struct engines *discover_engines(char *device)
}
if (ret) {
- free(engines);
errno = ret;
-
- return NULL;
+ goto err;
}
qsort(engine_ptr(engines, 0), engines->num_engines,
@@ -435,6 +433,11 @@ static struct engines *discover_engines(char *device)
engines->root = d;
return engines;
+
+err:
+ free(engines);
+
+ return NULL;
}
static void free_engines(struct engines *engines)
@@ -448,6 +451,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
+ if (!engines)
+ return;
+
for (pmu = &free_list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2574,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or newer
is required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
- goto err;
+ goto err_engines;
}
ret = pmu_init(engines);
@@ -2585,7 +2591,7 @@ int main(int argc, char **argv)
"More information can be found at 'Perf events and tool security' document:\n"
"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
- goto err;
+ goto err_pmu;
}
ret = EXIT_SUCCESS;
@@ -2699,8 +2705,9 @@ int main(int argc, char **argv)
free_clients(clients);
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
exit:
igt_devices_free();
--
2.34.1
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
On 1/23/2023 12:09 PM, Das, Nirmoy wrote:
Hi Tvrtko,
On 1/23/2023 11:24 AM, Tvrtko Ursulin wrote:
On 20/01/2023 14:29, Das, Nirmoy wrote:
Hi Tvrtko,
On 1/19/2023 4:54 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..517dc2995d26 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -448,6 +448,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
+ if (!engines)
+ return;
+
This check should happen before the struct pmu_counter free_list
generation.
I could, but it doesn't have to, not sure what reasons for should you
have in mind?
In my tree, I see:
"
static void free_engines(struct engines *engines)
{
struct pmu_counter **pmu, *free_list[] = {
&engines->r_gpu,
&engines->r_pkg,
&engines->imc_reads,
&engines->imc_writes,
NULL
};
unsigned int i;
"
Maybe I am missing something here, wouldn't those dereferences of
"engines" segfault if the engines is NULL.
Ah never mind it shouldn't matter.
Regards,
Nirmoy
Regards,
Tvrtko
Regards,
Nirmoy
for (pmu = &free_list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2571,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or
newer is required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
- goto err;
+ goto err_engines;
}
ret = pmu_init(engines);
@@ -2585,7 +2588,7 @@ int main(int argc, char **argv)
"More information can be found at 'Perf events and tool security'
document:\n"
"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
- goto err;
+ goto err_pmu;
}
ret = EXIT_SUCCESS;
@@ -2699,8 +2702,9 @@ int main(int argc, char **argv)
free_clients(clients);
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
exit:
igt_devices_free();
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
On 1/19/2023 4:54 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.
Signed-off-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
tools/intel_gpu_top.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..517dc2995d26 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -448,6 +448,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
+ if (!engines)
+ return;
+
for (pmu = &free_list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2571,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or newer is
required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
- goto err;
+ goto err_engines;
}
ret = pmu_init(engines);
@@ -2585,7 +2588,7 @@ int main(int argc, char **argv)
"More information can be found at 'Perf events and tool security' document:\n"
"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
- goto err;
+ goto err_pmu;
}
ret = EXIT_SUCCESS;
@@ -2699,8 +2702,9 @@ int main(int argc, char **argv)
free_clients(clients);
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
exit:
igt_devices_free();
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Various cleanups
== Series Details ==
Series: drm/fb-helper: Various cleanups
URL : https://patchwork.freedesktop.org/series/113220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12622 -> Patchwork_113220v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/index.html
Participating hosts (39 -> 38)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-bsw-kefka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113220v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7156])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +15 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
Possible fixes
* igt@i915_module_load@load:
- fi-ctg-p8600: [DMESG-WARN][6] ([i915#6020]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/fi-ctg-p8600/igt@i915_module_l...@load.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-ctg-p8600/igt@i915_module_l...@load.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][8] ([i915#7699]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [TIMEOUT][10] ([i915#6794]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [INCOMPLETE][12] ([i915#6257]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-rpls-2/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/bat-rpls-2/igt@i915_selftest@l...@requests.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-5: [FAIL][14] ([fdo#103375]) -> [PASS][15] +3 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12622/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113220v1/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6020]: https://gitlab.freedesktop.org/drm/intel/issues/6020
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
Build changes
-
* Linux: CI_DRM_12622 -> Patchwork_113220v1
CI-20190529: 20190529
CI_DRM_12622: 93e8ce8fb03496d8d0ccf15e7363563af90a4f8f @
git://anongit.freedesktop.org/
Re: [Intel-gfx] [PATCH dii-client 3/9] drm/i915/mtl: Fix Wa_14015855405 implementation
On 11.01.2023 15:55, Radhakrishna Sripada wrote:
> The patch "2357f2b271ad drm/i915/mtl: Initial display workarounds"
> extended the workaround Wa_16015201720 to MTL. However the registers
> that the original WA implamented moved for MTL.
>
> Implement the workaround with the correct register.
>
> Fixes: 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
> Cc: Matt Atwood
> Cc: Lucas De Marchi
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 35
> drivers/gpu/drm/i915/i915_reg.h | 10 +--
> 2 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 4124b3d37110..216915256eb6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -372,15 +372,12 @@ static void disable_all_event_handlers(struct
> drm_i915_private *i915)
> }
> }
>
> -static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> +static void adlp_pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> {
> enum pipe pipe;
>
> - if (DISPLAY_VER(i915) < 13)
> - return;
> -
> /*
> - * Wa_16015201720:adl-p,dg2, mtl
> + * Wa_16015201720:adl-p,dg2
>* The WA requires clock gating to be disabled all the time
>* for pipe A and B.
>* For pipe C and D clock gating needs to be disabled only
> @@ -396,6 +393,34 @@ static void pipedmc_clock_gating_wa(struct
> drm_i915_private *i915, bool enable)
>PIPEDMC_GATING_DIS, 0);
> }
>
> +static void mtl_pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> +{
> + /*
> + * Wa_14015855405
> + * The WA requires clock gating to be disabled all the time
> + * for pipe A and B.
> + * For pipe C and D clock gating needs to be disabled only
> + * during initializing the firmware.
> + * TODO/FIXME: WA deviates wrt. enable/disable for Pipes C, D. Needs
> recheck.
> + * For now carry-forward the implementation for dg2.
typo "s/for dg2/from dg2/"
Reviewed-by: Balasubramani Vivekanandan
Regards,
Bala
> + */
> + if (enable)
> + intel_de_rmw(i915, GEN9_CLKGATE_DIS_0, 0,
> + MTL_PIPEDMC_GATING_DIS_A |
> MTL_PIPEDMC_GATING_DIS_B |
> + MTL_PIPEDMC_GATING_DIS_C |
> MTL_PIPEDMC_GATING_DIS_D);
> + else
> + intel_de_rmw(i915, GEN9_CLKGATE_DIS_0,
> + MTL_PIPEDMC_GATING_DIS_C |
> MTL_PIPEDMC_GATING_DIS_D, 0);
> +}
> +
> +static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> +{
> + if (DISPLAY_VER(i915) >= 14)
> + return mtl_pipedmc_clock_gating_wa(i915, enable);
> + else if (DISPLAY_VER(i915) == 13)
> + return adlp_pipedmc_clock_gating_wa(i915, enable);
> +}
> +
> /**
> * intel_dmc_load_program() - write the firmware from memory to register.
> * @dev_priv: i915 drm device.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8b2cf980f323..d43f0f8e061c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1786,9 +1786,13 @@
> * GEN9 clock gating regs
> */
> #define GEN9_CLKGATE_DIS_0 _MMIO(0x46530)
> -#define DARBF_GATING_DIS (1 << 27)
> -#define PWM2_GATING_DIS(1 << 14)
> -#define PWM1_GATING_DIS(1 << 13)
> +#define DARBF_GATING_DIS REG_BIT(27)
> +#define MTL_PIPEDMC_GATING_DIS_A REG_BIT(15)
> +#define MTL_PIPEDMC_GATING_DIS_B REG_BIT(14)
> +#define PWM2_GATING_DISREG_BIT(14)
> +#define MTL_PIPEDMC_GATING_DIS_C REG_BIT(13)
> +#define PWM1_GATING_DISREG_BIT(13)
> +#define MTL_PIPEDMC_GATING_DIS_D REG_BIT(12)
>
> #define GEN9_CLKGATE_DIS_3 _MMIO(0x46538)
> #define TGL_VRH_GATING_DIS REG_BIT(31)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
Hi Tvrtko,
On 1/23/2023 11:24 AM, Tvrtko Ursulin wrote:
On 20/01/2023 14:29, Das, Nirmoy wrote:
Hi Tvrtko,
On 1/19/2023 4:54 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..517dc2995d26 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -448,6 +448,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
+ if (!engines)
+ return;
+
This check should happen before the struct pmu_counter free_list
generation.
I could, but it doesn't have to, not sure what reasons for should you
have in mind?
In my tree, I see:
"
static void free_engines(struct engines *engines)
{
struct pmu_counter **pmu, *free_list[] = {
&engines->r_gpu,
&engines->r_pkg,
&engines->imc_reads,
&engines->imc_writes,
NULL
};
unsigned int i;
"
Maybe I am missing something here, wouldn't those dereferences of
"engines" segfault if the engines is NULL.
Regards,
Nirmoy
Regards,
Tvrtko
Regards,
Nirmoy
for (pmu = &free_list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2571,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or newer
is required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
- goto err;
+ goto err_engines;
}
ret = pmu_init(engines);
@@ -2585,7 +2588,7 @@ int main(int argc, char **argv)
"More information can be found at 'Perf events and tool security'
document:\n"
"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
- goto err;
+ goto err_pmu;
}
ret = EXIT_SUCCESS;
@@ -2699,8 +2702,9 @@ int main(int argc, char **argv)
free_clients(clients);
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
exit:
igt_devices_free();
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/fb-helper: Various cleanups
== Series Details == Series: drm/fb-helper: Various cleanups URL : https://patchwork.freedesktop.org/series/113220/ State : warning == Summary == Error: dim checkpatch failed 5ab0ea975cf6 drm/client: Test for connectors before sending hotplug event 375ab6efdb6e drm/client: Add hotplug_failed flag cd08e72eef2b drm/fb-helper: Introduce drm_fb_helper_unprepare() -:59: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #59: FILE: include/drm/drm_fb_helper.h:299: } +void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper) total: 0 errors, 0 warnings, 1 checks, 42 lines checked 15f07c8dbc87 drm/fbdev-generic: Initialize fb-helper structure in generic setup 62b277b14ac0 drm/fb-helper: Remove preferred_bpp parameter from fbdev internals a60df8b21d68 drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function 001d97408c83 drm/fbdev-generic: Minimize hotplug error handling e30390bb2278 drm/fbdev-generic: Minimize client unregistering 6fd2dcb41557 drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy() 27813d7a17b0 drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
On Sat, 21 Jan 2023, Lucas De Marchi wrote: > On Fri, Jan 20, 2023 at 10:14:19PM -0800, Anusha Srivatsa wrote: >> >> >>> -Original Message- >>> From: Intel-gfx On Behalf Of Lucas >>> De Marchi >>> Sent: Friday, January 20, 2023 11:35 AM >>> To: intel-gfx@lists.freedesktop.org >>> Cc: De Marchi, Lucas ; dri- >>> de...@lists.freedesktop.org >>> Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() >>> >>> It's a constant pattern in the driver to need to use 2 ranges of MMIOs >>> based on >>> port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), >>> _PICK() >>> needs to be used. Using _PICK() is discouraged due to some reasons like: >>> >>> 1) It increases the code size since the array is declared >>>in each call site >>> 2) Developers need to be careful not to incur an >>>out-of-bounds array access >>> 3) Developers need to be careful that the indexes match the >>>table. For that it may be that the table needs to contain >>>holes, making (1) even worse. >>> >>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one >>> to use depending on the index value. >>> >>> Signed-off-by: Lucas De Marchi >>> --- >>> drivers/gpu/drm/i915/i915_reg_defs.h | 28 >>> 1 file changed, 28 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h >>> b/drivers/gpu/drm/i915/i915_reg_defs.h >>> index be43580a6979..b7ec87464d69 100644 >>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h >>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h >>> @@ -119,6 +119,34 @@ >>> */ >>> #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) >>> >>> +/* >>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address >>> offsets. >>> + * The first range is used for indexes below @__c_index, and the second >>> + * range is used for anything above it. Example:: >>> + * >>> + * #define _FOO_A 0xf000 >>> + * #define _FOO_B 0xf004 >>> + * #define _FOO_C 0xf008 >>> + * #define _SUPER_FOO_A0xa000 >>> + * #define _SUPER_FOO_B0xa100 >>> + * #define FOO(x) _MMIO(_PICK_EVEN_RANGES(x, 3, >>> \ >>> + * _FOO_A, _FOO_B, >>> \ >>> + * _SUPER_FOO_A, _SUPER_FOO_B)) >>> + * >>> + * This expands to: >>> + * 0: 0xf000, >>> + * 1: 0xf004, >>> + * 2: 0xf008, >>> + * 3: 0xa100, >>You mean 3:0xa000 > > doesn't really matter. This is an example of register addresses. They > don't need to start from 0, it's whatever the hw gives us. I think the point is that the example is inconsistent between _SUPER_FOO_A and "3: 0xa100". BR, Jani. > > Lucas De Marchi > >> >>> + * 4: 0xa200, >>4:0xa100 >> >>> + * 5: 0xa300, >>5:0xa200 >> >>Anusha >>> + * ... >>> + */ >>> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) >>> \ >>> + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + >>> \ >>> +((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : >>> \ >>> + _PICK_EVEN((__index) - (__c_index), __c, >>> __d))) >>> + >>> /* >>> * Given the arbitrary numbers in varargs, pick the 0-based __index'th >>> number. >>> * >>> -- >>> 2.39.0 >> -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 01/10] drm/client: Test for connectors before sending hotplug event
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 262ec64d4397..09ac191c202d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
+ if (!dev->mode_config.num_connector) {
+ drm_dbg_kms(dev, "No connectors found, will not send hotplug
events!\n");
+ return;
+ }
+
mutex_lock(&dev->clientlist_mutex);
list_for_each_entry(client, &dev->clientlist, list) {
if (!client->funcs || !client->funcs->hotplug)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 0a4c160e0e58..3d455a2e3fb5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- if (!dev->mode_config.num_connector) {
- drm_dbg_kms(dev, "No connectors found, will not create
framebuffer!\n");
- return 0;
- }
-
drm_fb_helper_prepare(dev, fb_helper, &drm_fb_helper_generic_funcs);
ret = drm_fb_helper_init(dev, fb_helper);
--
2.39.0
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
On Fri, 20 Jan 2023, Lucas De Marchi wrote:
> It's a constant pattern in the driver to need to use 2 ranges of MMIOs
> based on port, phy, pll, etc. When that happens, instead of using
> _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
> due to some reasons like:
>
> 1) It increases the code size since the array is declared
>in each call site
Would be interesting to see what this does, and whether the compiler has
the smarts to combine these within each file:
-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+#define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])
> 2) Developers need to be careful not to incur an
>out-of-bounds array access
> 3) Developers need to be careful that the indexes match the
>table. For that it may be that the table needs to contain
>holes, making (1) even worse.
>
> Add a variant of _PICK_EVEN() that works with 2 ranges and selects which
> one to use depending on the index value.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_reg_defs.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
> b/drivers/gpu/drm/i915/i915_reg_defs.h
> index be43580a6979..b7ec87464d69 100644
> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
> @@ -119,6 +119,34 @@
> */
> #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
>
> +/*
> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
> + * The first range is used for indexes below @__c_index, and the second
> + * range is used for anything above it. Example::
I'd like this to be clear about which range is used for index ==
__c_index, instead of saying "below" and "above".
No need for the double colon :: because this isn't a kernel-doc comment.
> + *
> + * #define _FOO_A0xf000
> + * #define _FOO_B0xf004
> + * #define _FOO_C0xf008
> + * #define _SUPER_FOO_A 0xa000
> + * #define _SUPER_FOO_B 0xa100
> + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3,
> \
The example uses a different name for the macro.
> + * _FOO_A, _FOO_B,
> \
> + * _SUPER_FOO_A, _SUPER_FOO_B))
> + *
> + * This expands to:
> + * 0: 0xf000,
> + * 1: 0xf004,
> + * 2: 0xf008,
> + * 3: 0xa100,
With the above definitions, this would be 3: 0xa000.
> + * 4: 0xa200,
> + * 5: 0xa300,
> + * ...
> + */
> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d)
> \
> + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) +
> \
> + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) :
> \
> +_PICK_EVEN((__index) - (__c_index), __c,
> __d)))
> +
> /*
> * Given the arbitrary numbers in varargs, pick the 0-based __index'th
> number.
> *
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 0/8] Add _PICK_EVEN_2RANGES
On Fri, 20 Jan 2023, Lucas De Marchi wrote: > Add a new macro, _PICK_EVEN_2RANGES, that supports using 2 address > ranges. This can be considered a v2 of > https://patchwork.freedesktop.org/series/109606/ > > I think I converted all the _PICK() uses that could be easily done > without making it much harder to read. We do have some cases of 3 > ranges: I left those alone. > > As commented in the original series and like Jani I think we may need > something else to cover all the use cases in future. Right now I don't > think we have a good alternative though. This new macro both improves > the current code and can be used for cases the ranges change in new > platforms, so I think it's good enough. In future I think just saving > the reg during initialization and using different functions if the > bitfields change may be an alternative. Did not review, but on the approach, Acked-by: Jani Nikula > > This was lightly tested on ADL-S and DG2. > > Lucas De Marchi (8): > drm/i915: Add _PICK_EVEN_2RANGES() > drm/i915: Fix coding style on DPLL*_ENABLE defines > drm/i915: Convert pll macros to _PICK_EVEN_2RANGES > drm/i915: Replace _MMIO_PHY3() with _PICK_EVEN_2RANGES() > drm/i915: Convert PIPE3/PORT3 to _PICK_EVEN_2RANGES() > drm/i915: Convert _FIA() to _PICK_EVEN_2RANGES() > drm/i915: Convert MBUS_ABOX_CTL() to _PICK_EVEN_2RANGES() > drm/i915: Convert PALETTE() to _PICK_EVEN_2RANGES() > > .../drm/i915/display/intel_display_reg_defs.h | 10 +- > .../gpu/drm/i915/display/intel_mg_phy_regs.h | 4 +- > drivers/gpu/drm/i915/i915_reg.h | 106 +- > drivers/gpu/drm/i915/i915_reg_defs.h | 28 + > 4 files changed, 89 insertions(+), 59 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fbdev_generic.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 135d58b8007b..63f66325a8a5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- drm_fb_helper_prepare(dev, fb_helper, &drm_fb_helper_generic_funcs);
-
ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;
@@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper)
return;
+ drm_fb_helper_prepare(dev, fb_helper, &drm_fb_helper_generic_funcs);
ret = drm_client_init(dev, &fb_helper->client, "fbdev",
&drm_fbdev_client_funcs);
if (ret) {
- kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
- return;
+ goto err_drm_client_init;
}
/*
@@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
drm_client_register(&fb_helper->client);
+
+ return;
+
+err_drm_client_init:
+ drm_fb_helper_unprepare(fb_helper);
+ kfree(fb_helper);
+ return;
}
EXPORT_SYMBOL(drm_fbdev_generic_setup);
--
2.39.0
Re: [Intel-gfx] [PATCH i-g-t] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU
On 20/01/2023 14:29, Das, Nirmoy wrote:
Hi Tvrtko,
On 1/19/2023 4:54 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Avoid trying to dereference null engines on exit when there are either
none which are supported, or kernel does not have i915 PMU support.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 7aa233570463..517dc2995d26 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -448,6 +448,9 @@ static void free_engines(struct engines *engines)
};
unsigned int i;
+ if (!engines)
+ return;
+
This check should happen before the struct pmu_counter free_list
generation.
I could, but it doesn't have to, not sure what reasons for should you
have in mind?
Regards,
Tvrtko
Regards,
Nirmoy
for (pmu = &free_list[0]; *pmu; pmu++) {
if ((*pmu)->present)
free((char *)(*pmu)->units);
@@ -2568,7 +2571,7 @@ int main(int argc, char **argv)
"Failed to detect engines! (%s)\n(Kernel 4.16 or newer
is required for i915 PMU support.)\n",
strerror(errno));
ret = EXIT_FAILURE;
- goto err;
+ goto err_engines;
}
ret = pmu_init(engines);
@@ -2585,7 +2588,7 @@ int main(int argc, char **argv)
"More information can be found at 'Perf events and tool security'
document:\n"
"https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html\n";);
ret = EXIT_FAILURE;
- goto err;
+ goto err_pmu;
}
ret = EXIT_SUCCESS;
@@ -2699,8 +2702,9 @@ int main(int argc, char **argv)
free_clients(clients);
free(codename);
-err:
+err_pmu:
free_engines(engines);
+err_engines:
free(pmu_device);
exit:
igt_devices_free();
[Intel-gfx] [PATCH 05/10] drm/fb-helper: Remove preferred_bpp parameter from fbdev internals
Store the console's preferred BPP value in struct drm_fb_helper
and remove the respective function parameters from the internal
fbdev code.
The BPP value is only required as a fallback and will now always
be available in the fb-helper instance.
No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 4379bcd7718b..258103d317ac 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1786,7 +1786,7 @@ static uint32_t
drm_fb_helper_find_color_mode_format(struct drm_fb_helper *fb_he
return drm_fb_helper_find_format(fb_helper, formats, format_count, bpp,
depth);
}
-static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
+static int __drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = &fb_helper->client;
@@ -1831,7 +1831,7 @@ static int __drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int prefe
surface_format = drm_fb_helper_find_color_mode_format(fb_helper,
plane->format_types,
plane->format_count,
-
preferred_bpp);
+
fb_helper->preferred_bpp);
if (surface_format != DRM_FORMAT_INVALID)
break; /* found supported format */
}
@@ -1903,7 +1903,7 @@ static int __drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int prefe
return 0;
}
-static int drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper, int
preferred_bpp,
+static int drm_fb_helper_find_sizes(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
struct drm_client_dev *client = &fb_helper->client;
@@ -1912,7 +1912,7 @@ static int drm_fb_helper_find_sizes(struct drm_fb_helper
*fb_helper, int preferr
int ret;
mutex_lock(&client->modeset_mutex);
- ret = __drm_fb_helper_find_sizes(fb_helper, preferred_bpp, sizes);
+ ret = __drm_fb_helper_find_sizes(fb_helper, sizes);
mutex_unlock(&client->modeset_mutex);
if (ret)
@@ -1934,15 +1934,14 @@ static int drm_fb_helper_find_sizes(struct
drm_fb_helper *fb_helper, int preferr
* Allocates the backing storage and sets up the fbdev info structure through
* the ->fb_probe callback.
*/
-static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
-int preferred_bpp)
+static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper)
{
struct drm_client_dev *client = &fb_helper->client;
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_surface_size sizes;
int ret;
- ret = drm_fb_helper_find_sizes(fb_helper, preferred_bpp, &sizes);
+ ret = drm_fb_helper_find_sizes(fb_helper, &sizes);
if (ret) {
/* First time: disable all crtc's.. */
if (!fb_helper->deferred_setup)
@@ -2125,8 +2124,7 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper
*fb_helper)
/* Note: Drops fb_helper->lock before returning. */
static int
-__drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper,
- int bpp_sel)
+__drm_fb_helper_initial_config_and_unlock(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
struct fb_info *info;
@@ -2137,10 +2135,9 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper,
height = dev->mode_config.max_height;
drm_client_modeset_probe(&fb_helper->client, width, height);
- ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+ ret = drm_fb_helper_single_fb_probe(fb_helper);
if (ret < 0) {
if (ret == -EAGAIN) {
- fb_helper->preferred_bpp = bpp_sel;
fb_helper->deferred_setup = true;
ret = 0;
}
@@ -2231,8 +2228,10 @@ int drm_fb_helper_initial_config(struct drm_fb_helper
*fb_helper, int bpp_sel)
if (!drm_fbdev_emulation)
return 0;
+ fb_helper->preferred_bpp = bpp_sel;
+
mutex_lock(&fb_helper->lock);
- ret = __drm_fb_helper_initial_config_and_unlock(fb_helper, bpp_sel);
+ ret = __drm_fb_helper_initial_config_and_unlock(fb_helper);
return ret;
}
@@ -2268,8 +2267,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
mutex
[Intel-gfx] [PATCH 09/10] drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy()
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fbdev_generic.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index bd5b59551c06..49a0bba86ce7 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -43,8 +43,9 @@ static int drm_fbdev_fb_release(struct fb_info *info, int
user)
return 0;
}
-static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
+static void drm_fbdev_fb_destroy(struct fb_info *info)
{
+ struct drm_fb_helper *fb_helper = info->par;
struct fb_info *fbi = fb_helper->info;
void *shadow = NULL;
@@ -66,24 +67,10 @@ static void drm_fbdev_cleanup(struct drm_fb_helper
*fb_helper)
drm_client_buffer_vunmap(fb_helper->buffer);
drm_client_framebuffer_delete(fb_helper->buffer);
-}
-
-static void drm_fbdev_release(struct drm_fb_helper *fb_helper)
-{
- drm_fbdev_cleanup(fb_helper);
drm_client_release(&fb_helper->client);
kfree(fb_helper);
}
-/*
- * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
- * unregister_framebuffer() or fb_release().
- */
-static void drm_fbdev_fb_destroy(struct fb_info *info)
-{
- drm_fbdev_release(info->par);
-}
-
static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct drm_fb_helper *fb_helper = info->par;
--
2.39.0
Re: [Intel-gfx] [PATCH v8 5/8] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
On Fri, 20 Jan 2023, Ville Syrjälä wrote:
> On Thu, Jan 19, 2023 at 06:18:58PM +0200, Jani Nikula wrote:
>> diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
>> b/drivers/gpu/drm/i915/display/intel_lvds.c
>> index aecec992cd0d..6a98787edf48 100644
>> --- a/drivers/gpu/drm/i915/display/intel_lvds.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lvds.c
>> @@ -479,8 +479,11 @@ static int intel_lvds_get_modes(struct drm_connector
>> *connector)
>> struct intel_connector *intel_connector = to_intel_connector(connector);
>>
>> /* use cached edid if we have one */
>> -if (!IS_ERR_OR_NULL(intel_connector->edid))
>> -return drm_add_edid_modes(connector, intel_connector->edid);
>> +if (!IS_ERR_OR_NULL(intel_connector->edid)) {
>> +drm_edid_connector_update(connector, intel_connector->edid);
>
> Isn't this update redundant?
Maybe far fetched, but if the user does connector force disable via
debugfs, drm_helper_probe_single_connector_modes() will clear the EDID
property and display info. And after that, nobody's going to do the
connector update again unless we do it here.
BR,
Jani.
>
>> +
>> +return drm_edid_connector_add_modes(connector);
>> +}
>>
>> return intel_panel_get_modes(intel_connector);
>> }
>> @@ -834,7 +837,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
>> struct intel_connector *intel_connector;
>> struct drm_connector *connector;
>> struct drm_encoder *encoder;
>> -struct edid *edid;
>> +const struct drm_edid *drm_edid;
>> i915_reg_t lvds_reg;
>> u32 lvds;
>> u8 pin;
>> @@ -945,27 +948,36 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
>> * preferred mode is the right one.
>> */
>> mutex_lock(&dev_priv->drm.mode_config.mutex);
>> -if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC)
>> +if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC) {
>> +const struct edid *edid;
>> +
>> +/* FIXME: Make drm_get_edid_switcheroo() return drm_edid */
>> edid = drm_get_edid_switcheroo(connector,
>> -intel_gmbus_get_adapter(dev_priv, pin));
>> -else
>> -edid = drm_get_edid(connector,
>> -intel_gmbus_get_adapter(dev_priv, pin));
>> -if (edid) {
>> -if (drm_add_edid_modes(connector, edid)) {
>> -drm_connector_update_edid_property(connector,
>> -edid);
>> -} else {
>> +
>> intel_gmbus_get_adapter(dev_priv, pin));
>> +if (edid) {
>> +drm_edid = drm_edid_alloc(edid, (edid->extensions + 1)
>> * EDID_LENGTH);
>> kfree(edid);
>> -edid = ERR_PTR(-EINVAL);
>> +} else {
>> +drm_edid = NULL;
>> +}
>> +} else {
>> +drm_edid = drm_edid_read_ddc(connector,
>> + intel_gmbus_get_adapter(dev_priv,
>> pin));
>> +}
>> +if (drm_edid) {
>> +if (drm_edid_connector_update(connector, drm_edid) ||
>> +!drm_edid_connector_add_modes(connector)) {
>> +drm_edid_connector_update(connector, NULL);
>> +drm_edid_free(drm_edid);
>> +drm_edid = ERR_PTR(-EINVAL);
>> }
>> } else {
>> -edid = ERR_PTR(-ENOENT);
>> +drm_edid = ERR_PTR(-ENOENT);
>> }
>> -intel_connector->edid = edid;
>> +intel_connector->edid = drm_edid;
>>
>> intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
>> - IS_ERR(edid) ? NULL : edid);
>> + IS_ERR_OR_NULL(drm_edid) ? NULL :
>> drm_edid_raw(drm_edid));
>>
>> /* Try EDID first */
>> intel_panel_add_edid_fixed_modes(intel_connector, true);
>> --
>> 2.34.1
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 03/10] drm/fb-helper: Introduce drm_fb_helper_unprepare()
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 14 +-
include/drm/drm_fb_helper.h | 4
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c5c13e192b64..4379bcd7718b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -435,6 +435,18 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
}
EXPORT_SYMBOL(drm_fb_helper_prepare);
+/**
+ * drm_fb_helper_unprepare - clean up a drm_fb_helper structure
+ * @fb_helper: driver-allocated fbdev helper structure to set up
+ *
+ * Cleans up the framebuffer helper. Inverse of drm_fb_helper_prepare().
+ */
+void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
+{
+ mutex_destroy(&fb_helper->lock);
+}
+EXPORT_SYMBOL(drm_fb_helper_unprepare);
+
/**
* drm_fb_helper_init - initialize a &struct drm_fb_helper
* @dev: drm device
@@ -561,7 +573,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
mutex_unlock(&kernel_fb_helper_lock);
- mutex_destroy(&fb_helper->lock);
+ drm_fb_helper_unprepare(fb_helper);
if (!fb_helper->client.funcs)
drm_client_release(&fb_helper->client);
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index f443e1f11654..123f2ef035c5 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,6 +230,7 @@ drm_fb_helper_from_client(struct drm_client_dev *client)
#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
+void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper);
int drm_fb_helper_init(struct drm_device *dev, struct drm_fb_helper *helper);
void drm_fb_helper_fini(struct drm_fb_helper *helper);
int drm_fb_helper_blank(int blank, struct fb_info *info);
@@ -295,6 +296,9 @@ static inline void drm_fb_helper_prepare(struct drm_device
*dev,
const struct drm_fb_helper_funcs *funcs)
{
}
+void drm_fb_helper_unprepare(struct drm_fb_helper *fb_helper)
+{
+}
static inline int drm_fb_helper_init(struct drm_device *dev,
struct drm_fb_helper *helper)
--
2.39.0
[Intel-gfx] [PATCH 07/10] drm/fbdev-generic: Minimize hotplug error handling
Call drm_fb_helper_init() in the generic-fbdev hotplug helper to revert the effects of drm_fb_helper_init(). No full cleanup is required. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_fbdev_generic.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_fbdev_generic.c b/drivers/gpu/drm/drm_fbdev_generic.c index 6ae014040df3..dd8be5e0f271 100644 --- a/drivers/gpu/drm/drm_fbdev_generic.c +++ b/drivers/gpu/drm/drm_fbdev_generic.c @@ -387,25 +387,21 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev *client) ret = drm_fb_helper_init(dev, fb_helper); if (ret) - goto err; + goto err_drm_err; if (!drm_drv_uses_atomic_modeset(dev)) drm_helper_disable_unused_functions(dev); ret = drm_fb_helper_initial_config(fb_helper); if (ret) - goto err_cleanup; + goto err_drm_fb_helper_fini; return 0; -err_cleanup: - drm_fbdev_cleanup(fb_helper); -err: - fb_helper->dev = NULL; - fb_helper->info = NULL; - +err_drm_fb_helper_fini: + drm_fb_helper_fini(fb_helper); +err_drm_err: drm_err(dev, "fbdev: Failed to setup generic emulation (ret=%d)\n", ret); - return ret; } -- 2.39.0
[Intel-gfx] [PATCH 06/10] drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/armada/armada_fbdev.c | 4 ++--
drivers/gpu/drm/drm_fb_helper.c| 22 ++
drivers/gpu/drm/drm_fbdev_generic.c| 19 ++-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
drivers/gpu/drm/i915/display/intel_fbdev.c | 11 ++-
drivers/gpu/drm/msm/msm_fbdev.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 ++--
drivers/gpu/drm/radeon/radeon_fb.c | 4 ++--
drivers/gpu/drm/tegra/fb.c | 7 +++
include/drm/drm_fb_helper.h| 3 ++-
11 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index 584cee123bd8..07e410c62b7a 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -129,7 +129,7 @@ int armada_fbdev_init(struct drm_device *dev)
priv->fbdev = fbh;
- drm_fb_helper_prepare(dev, fbh, &armada_fb_helper_funcs);
+ drm_fb_helper_prepare(dev, fbh, 32, &armada_fb_helper_funcs);
ret = drm_fb_helper_init(dev, fbh);
if (ret) {
@@ -137,7 +137,7 @@ int armada_fbdev_init(struct drm_device *dev)
goto err_fb_helper;
}
- ret = drm_fb_helper_initial_config(fbh, 32);
+ ret = drm_fb_helper_initial_config(fbh);
if (ret) {
DRM_ERROR("failed to set initial config\n");
goto err_fb_setup;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 258103d317ac..28c428e9c530 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -416,14 +416,30 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
* drm_fb_helper_prepare - setup a drm_fb_helper structure
* @dev: DRM device
* @helper: driver-allocated fbdev helper structure to set up
+ * @preferred_bpp: Preferred bits per pixel for the device.
* @funcs: pointer to structure of functions associate with this helper
*
* Sets up the bare minimum to make the framebuffer helper usable. This is
* useful to implement race-free initialization of the polling helpers.
*/
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
+ unsigned int preferred_bpp,
const struct drm_fb_helper_funcs *funcs)
{
+ /*
+* Pick a preferred bpp of 32 if no value has been given. This
+* will select XRGB for the framebuffer formats. All drivers
+* have to support XRGB for backwards compatibility with legacy
+* userspace, so it's the safe choice here.
+*
+* TODO: Replace struct drm_mode_config.preferred_depth and this
+* bpp value with a preferred format that is given as struct
+* drm_format_info. Then derive all other values from the
+* format.
+*/
+ if (!preferred_bpp)
+ preferred_bpp = 32;
+
INIT_LIST_HEAD(&helper->kernel_fb_list);
spin_lock_init(&helper->damage_lock);
INIT_WORK(&helper->resume_work, drm_fb_helper_resume_worker);
@@ -432,6 +448,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
mutex_init(&helper->lock);
helper->funcs = funcs;
helper->dev = dev;
+ helper->preferred_bpp = preferred_bpp;
}
EXPORT_SYMBOL(drm_fb_helper_prepare);
@@ -2183,7 +2200,6 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper)
/**
* drm_fb_helper_initial_config - setup a sane initial connector configuration
* @fb_helper: fb_helper device struct
- * @bpp_sel: bpp value to use for the framebuffer configuration
*
* Scans the CRTCs and connectors and tries to put together an initial setup.
* At the moment, this is a cloned configuration across all heads with
@@ -2221,15 +2237,13 @@ __drm_fb_helper_initial_config_and_unlock(struct
drm_fb_helper *fb_helper)
* RETURNS:
* Zero if everything went ok, nonzero otherwise.
*/
-int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel)
+int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper)
{
int ret;
if (!drm_fbdev_emulation)
return 0;
- fb_helper->preferred_bpp = bpp_sel;
-
mutex_lock(&fb_helper->lock);
ret = __drm_fb_helper_initial_config_and_unlock(fb_helper);
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 63f66325a8a5..6ae014040df3 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++
[Intel-gfx] [PATCH 08/10] drm/fbdev-generic: Minimize client unregistering
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where the client never creates
the framebuffer, only the client state needs to be released. We
can detect which case it is, full or client-only cleanup, be
looking at the presence of fb_helper's info field.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fbdev_generic.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index dd8be5e0f271..bd5b59551c06 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -362,11 +362,13 @@ static void drm_fbdev_client_unregister(struct
drm_client_dev *client)
{
struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
- if (fb_helper->info)
- /* drm_fbdev_fb_destroy() takes care of cleanup */
+ if (fb_helper->info) {
drm_fb_helper_unregister_info(fb_helper);
- else
- drm_fbdev_release(fb_helper);
+ } else {
+ drm_fb_helper_unprepare(fb_helper);
+ drm_client_release(&fb_helper->client);
+ kfree(fb_helper);
+ }
}
static int drm_fbdev_client_restore(struct drm_client_dev *client)
--
2.39.0
[Intel-gfx] [PATCH 02/10] drm/client: Add hotplug_failed flag
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper, which prevents us from initializing these pointers
early after allocation.
The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 4
include/drm/drm_client.h| 8
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 09ac191c202d..009e7b10455c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!client->funcs || !client->funcs->hotplug)
continue;
+ if (client->hotplug_failed)
+ continue;
+
ret = client->funcs->hotplug(client);
drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
+ if (ret)
+ client->hotplug_failed = true;
}
mutex_unlock(&dev->clientlist_mutex);
}
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 3d455a2e3fb5..135d58b8007b 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
struct drm_device *dev = client->dev;
int ret;
- /* Setup is not retried if it has failed */
- if (!fb_helper->dev && fb_helper->funcs)
- return 0;
-
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 4fc8018eddda..39482527a775 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -106,6 +106,14 @@ struct drm_client_dev {
* @modesets: CRTC configurations
*/
struct drm_mode_set *modesets;
+
+ /**
+* @hotplug failed:
+*
+* Set by client hotplug helpers if the hotplugging failed
+* before. It is usually not tried again.
+*/
+ bool hotplug_failed;
};
int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,
--
2.39.0
[Intel-gfx] [PATCH 10/10] drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info'
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fbdev_generic.c | 49 ++---
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 49a0bba86ce7..7633da5c13c3 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -46,17 +46,16 @@ static int drm_fbdev_fb_release(struct fb_info *info, int
user)
static void drm_fbdev_fb_destroy(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
- struct fb_info *fbi = fb_helper->info;
void *shadow = NULL;
if (!fb_helper->dev)
return;
- if (fbi) {
- if (fbi->fbdefio)
- fb_deferred_io_cleanup(fbi);
+ if (info) {
+ if (info->fbdefio)
+ fb_deferred_io_cleanup(info);
if (drm_fbdev_use_shadow_fb(fb_helper))
- shadow = fbi->screen_buffer;
+ shadow = info->screen_buffer;
}
drm_fb_helper_fini(fb_helper);
@@ -173,7 +172,7 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
struct drm_device *dev = fb_helper->dev;
struct drm_client_buffer *buffer;
struct drm_framebuffer *fb;
- struct fb_info *fbi;
+ struct fb_info *info;
u32 format;
struct iosys_map map;
int ret;
@@ -192,35 +191,35 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
fb_helper->fb = buffer->fb;
fb = buffer->fb;
- fbi = drm_fb_helper_alloc_info(fb_helper);
- if (IS_ERR(fbi))
- return PTR_ERR(fbi);
+ info = drm_fb_helper_alloc_info(fb_helper);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
- fbi->fbops = &drm_fbdev_fb_ops;
- fbi->screen_size = sizes->surface_height * fb->pitches[0];
- fbi->fix.smem_len = fbi->screen_size;
- fbi->flags = FBINFO_DEFAULT;
+ info->fbops = &drm_fbdev_fb_ops;
+ info->screen_size = sizes->surface_height * fb->pitches[0];
+ info->fix.smem_len = info->screen_size;
+ info->flags = FBINFO_DEFAULT;
- drm_fb_helper_fill_info(fbi, fb_helper, sizes);
+ drm_fb_helper_fill_info(info, fb_helper, sizes);
if (drm_fbdev_use_shadow_fb(fb_helper)) {
- fbi->screen_buffer = vzalloc(fbi->screen_size);
- if (!fbi->screen_buffer)
+ info->screen_buffer = vzalloc(info->screen_size);
+ if (!info->screen_buffer)
return -ENOMEM;
- fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
+ info->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
- fbi->fbdefio = &drm_fbdev_defio;
- fb_deferred_io_init(fbi);
+ info->fbdefio = &drm_fbdev_defio;
+ fb_deferred_io_init(info);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
if (map.is_iomem) {
- fbi->screen_base = map.vaddr_iomem;
+ info->screen_base = map.vaddr_iomem;
} else {
- fbi->screen_buffer = map.vaddr;
- fbi->flags |= FBINFO_VIRTFB;
+ info->screen_buffer = map.vaddr;
+ info->flags |= FBINFO_VIRTFB;
}
/*
@@ -229,10 +228,10 @@ static int drm_fbdev_fb_probe(struct drm_fb_helper
*fb_helper,
* case.
*/
#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
- if (fb_helper->hint_leak_smem_start && fbi->fix.smem_start == 0
&&
+ if (fb_helper->hint_leak_smem_start && info->fix.smem_start ==
0 &&
!drm_WARN_ON_ONCE(dev, map.is_iomem))
- fbi->fix.smem_start =
- page_to_phys(virt_to_page(fbi->screen_buffer));
+ info->fix.smem_start =
+ page_to_phys(virt_to_page(info->screen_buffer));
#endif
}
--
2.39.0
[Intel-gfx] [PATCH 00/10] drm/fb-helper: Various cleanups
Add various cleanups and changes to DRM's fbdev helpers and the generic fbdev emulation. There's no clear theme here, just lots of small things that need to be updated. In the end, the code will better reflect which parts are in the DRM client, which is fbdev emulation, and which are shared fbdev helpers. Thomas Zimmermann (10): drm/client: Test for connectors before sending hotplug event drm/client: Add hotplug_failed flag drm/fb-helper: Introduce drm_fb_helper_unprepare() drm/fbdev-generic: Initialize fb-helper structure in generic setup drm/fb-helper: Remove preferred_bpp parameter from fbdev internals drm/fb-helper: Initialize fb-helper's preferred BPP in prepare function drm/fbdev-generic: Minimize hotplug error handling drm/fbdev-generic: Minimize client unregistering drm/fbdev-generic: Inline clean-up helpers into drm_fbdev_fb_destroy() drm/fbdev-generic: Rename struct fb_info 'fbi' to 'info' drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/drm_client.c | 10 ++ drivers/gpu/drm/drm_fb_helper.c| 58 ++--- drivers/gpu/drm/drm_fbdev_generic.c| 129 - drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/gma500/framebuffer.c | 4 +- drivers/gpu/drm/i915/display/intel_fbdev.c | 11 +- drivers/gpu/drm/msm/msm_fbdev.c| 4 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 +- drivers/gpu/drm/radeon/radeon_fb.c | 4 +- drivers/gpu/drm/tegra/fb.c | 7 +- include/drm/drm_client.h | 8 ++ include/drm/drm_fb_helper.h| 7 +- 13 files changed, 133 insertions(+), 121 deletions(-) base-commit: 7d3e7f64a42d66ba8da6e7b66a8d85457ef84570 prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6 -- 2.39.0
Re: [Intel-gfx] [PATCH v8 4/8] drm/edid: remove redundant _drm_connector_update_edid_property()
On Thu, 19 Jan 2023, Jani Nikula wrote:
> Realize that drm_edid_connector_update() and
> _drm_connector_update_edid_property() are now the same thing. Drop the
> latter.
>
> Cc: Ville Syrjälä
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Thanks for the reviews, pushed 1-4 to drm-misc-next.
BR,
Jani.
> ---
> drivers/gpu/drm/drm_edid.c | 21 +
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d0c21d27b978..3d0a4da661bc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6784,24 +6784,6 @@ int drm_edid_connector_add_modes(struct drm_connector
> *connector)
> }
> EXPORT_SYMBOL(drm_edid_connector_add_modes);
>
> -static int _drm_connector_update_edid_property(struct drm_connector
> *connector,
> -const struct drm_edid *drm_edid)
> -{
> - /*
> - * Set the display info, using edid if available, otherwise resetting
> - * the values to defaults. This duplicates the work done in
> - * drm_add_edid_modes, but that function is not consistently called
> - * before this one in all drivers and the computation is cheap enough
> - * that it seems better to duplicate it rather than attempt to ensure
> - * some arbitrary ordering of calls.
> - */
> - update_display_info(connector, drm_edid);
> -
> - _drm_update_tile_info(connector, drm_edid);
> -
> - return _drm_edid_connector_property_update(connector, drm_edid);
> -}
> -
> /**
> * drm_connector_update_edid_property - update the edid property of a
> connector
> * @connector: drm connector
> @@ -6823,8 +6805,7 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
> {
> struct drm_edid drm_edid;
>
> - return _drm_connector_update_edid_property(connector,
> -
> drm_edid_legacy_init(&drm_edid, edid));
> + return drm_edid_connector_update(connector,
> drm_edid_legacy_init(&drm_edid, edid));
> }
> EXPORT_SYMBOL(drm_connector_update_edid_property);
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev4)
== Series Details ==
Series: drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev4)
URL : https://patchwork.freedesktop.org/series/111433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12619 -> Patchwork_111433v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/index.html
Participating hosts (37 -> 35)
--
Additional (1): fi-bsw-kefka
Missing(3): fi-kbl-soraka fi-rkl-11600 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_111433v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_mocs:
- fi-rkl-guc: NOTRUN -> [INCOMPLETE][1] ([i915#4983])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/fi-rkl-guc/igt@i915_selftest@live@gt_mocs.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][2] -> [FAIL][3] ([i915#6298])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka: NOTRUN -> [SKIP][4] ([fdo#109271]) +26 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][5] ([i915#4312])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {bat-adls-5}: [FAIL][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/bat-adls-5/igt@i915_pm_...@module-reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/bat-adls-5/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][8] ([i915#7699]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [DMESG-FAIL][10] ([i915#4983]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/bat-rpls-2/igt@i915_selftest@l...@reset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/bat-rpls-2/igt@i915_selftest@l...@reset.html
- {bat-rpls-1}: [DMESG-FAIL][12] ([i915#4983]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/bat-rpls-1/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [INCOMPLETE][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-3:
- {bat-dg2-11}: [INCOMPLETE][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12619/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-3.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v4/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12619 -> Patchwork_111433v4
CI-20190529: 20190529
CI_DRM_12619: 7d3e7f64a42d66ba8da6e7b66a8d85457ef84570 @
git://anongit.freedesktop.org/gfx-ci/linux
