Re: [PATCH] drm/i915: Add flex arrays to struct i915_syncmap
On Thu, Feb 08, 2024 at 07:13:18PM +0100, Erick Archer wrote:
> The "struct i915_syncmap" uses a dynamically sized set of trailing
> elements. It can use an "u32" array or a "struct i915_syncmap *"
> array.
>
> So, use the preferred way in the kernel declaring flexible arrays [1].
> Because there are two possibilities for the trailing arrays, it is
> necessary to declare a union and use the DECLARE_FLEX_ARRAY macro.
>
> The comment can be removed as the union is now clear enough.
>
> Also, avoid the open-coded arithmetic in the memory allocator functions
> [2] using the "struct_size" macro.
>
> Moreover, refactor the "__sync_seqno" and "__sync_child" functions due
> to now it is possible to use the union members added to the structure.
> This way, it is also possible to avoid the open-coded arithmetic in
> pointers.
>
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays
> [1]
> Link:
> https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> [2]
> Signed-off-by: Erick Archer
> ---
> drivers/gpu/drm/i915/i915_syncmap.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_syncmap.c
> b/drivers/gpu/drm/i915/i915_syncmap.c
> index 60404dbb2e9f..df6437c37373 100644
> --- a/drivers/gpu/drm/i915/i915_syncmap.c
> +++ b/drivers/gpu/drm/i915/i915_syncmap.c
> @@ -75,13 +75,10 @@ struct i915_syncmap {
> unsigned int height;
> unsigned int bitmap;
> struct i915_syncmap *parent;
> - /*
> - * Following this header is an array of either seqno or child pointers:
> - * union {
> - * u32 seqno[KSYNCMAP];
> - * struct i915_syncmap *child[KSYNCMAP];
> - * };
> - */
> + union {
> + DECLARE_FLEX_ARRAY(u32, seqno);
> + DECLARE_FLEX_ARRAY(struct i915_syncmap *, child);
> + };
This is a new code pattern for me! Trailing arrays of different element
sizes but with a fixed element count. :)
I hope when __counted_by is expanded to take expressions we can add a
literal. :)
Reviewed-by: Kees Cook
--
Kees Cook
✓ Fi.CI.BAT: success for drm/i915/cdclk: More hardcoded cd2x divider nukage (rev3)
== Series Details ==
Series: drm/i915/cdclk: More hardcoded cd2x divider nukage (rev3)
URL : https://patchwork.freedesktop.org/series/129611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129611v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129611v3/index.html
Participating hosts (36 -> 33)
--
Missing(3): bat-kbl-2 bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129611v3 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][1] ([i915#10194]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129611v3/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][3] ([i915#10010]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129611v3/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129611v3/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129611v3
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129611v3: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
15f88c1d8271 drm/i915/cdclk: Document CDCLK update methods
41ca6eafc3ca drm/i915/cdclk: Remove the hardcoded divider from
cdclk_compute_crawl_and_squash_midpoint()
3217dc251617 drm/i915/cdclk: Squash waveform is 16 bits
b9521daca6e2 drm/i915/cdclk: Extract cdclk_divider()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129611v3/index.html
✓ Fi.CI.BAT: success for drm/i915: PLL state check stuff
== Series Details ==
Series: drm/i915: PLL state check stuff
URL : https://patchwork.freedesktop.org/series/129735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129735v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/index.html
Participating hosts (36 -> 30)
--
Missing(6): fi-cfl-guc fi-snb-2520m fi-pnv-d510 bat-jsl-3 fi-bsw-nick
bat-jsl-1
Known issues
Here are the changes found in Patchwork_129735v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/fi-cfl-8109u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/fi-cfl-8109u/boot.html
### IGT changes ###
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][3] ([i915#10194]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][5] ([i915#10010]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129735v1
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129735v1: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
34108726aa48 drm/i915: Enable fastboot across the board
706b21a209a9 drm/i915: Add PLL .compare_hw_state() vfunc
0210379630ac drm/i915: Reuse ibx_dump_hw_state() for gmch platforms
a848f9038a4e drm/i915: Include the CRTC name in the ELD buffer mismatch
10c843a1f82f drm/i915: Fix PLL state check for gmch platforms
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129735v1/index.html
✗ Fi.CI.SPARSE: warning for drm/i915: PLL state check stuff
== Series Details == Series: drm/i915: PLL state check stuff URL : https://patchwork.freedesktop.org/series/129735/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
✗ Fi.CI.CHECKPATCH: warning for drm/i915: PLL state check stuff
== Series Details ==
Series: drm/i915: PLL state check stuff
URL : https://patchwork.freedesktop.org/series/129735/
State : warning
== Summary ==
Error: dim checkpatch failed
40b158c2ea84 drm/i915: Fix PLL state check for gmch platforms
c9b044f993a8 drm/i915: Include the CRTC name in the ELD buffer mismatch
61f1c4fa93b0 drm/i915: Reuse ibx_dump_hw_state() for gmch platforms
a6768a7eee59 drm/i915: Add PLL .compare_hw_state() vfunc
-:62: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#62: FILE: drivers/gpu/drm/i915/display/intel_display.c:5050:
+#define PIPE_CONF_CHECK_PLL(name) do { \
+ if (!intel_dpll_compare_hw_state(dev_priv, _config->name, \
+_config->name)) { \
+ pipe_config_pll_mismatch(fastset, crtc, __stringify(name), \
+_config->name, \
+_config->name); \
+ ret = false; \
+ } \
+} while (0)
-:62: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#62: FILE: drivers/gpu/drm/i915/display/intel_display.c:5050:
+#define PIPE_CONF_CHECK_PLL(name) do { \
+ if (!intel_dpll_compare_hw_state(dev_priv, _config->name, \
+_config->name)) { \
+ pipe_config_pll_mismatch(fastset, crtc, __stringify(name), \
+_config->name, \
+_config->name); \
+ ret = false; \
+ } \
+} while (0)
-:72: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:5060:
+#define PIPE_CONF_CHECK_TIMINGS(name) do { \
PIPE_CONF_CHECK_I(name.crtc_hdisplay); \
PIPE_CONF_CHECK_I(name.crtc_htotal); \
PIPE_CONF_CHECK_I(name.crtc_hblank_start); \
-:333: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#333: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4552:
+ return i915->display.dpll.mgr->compare_hw_state(a, b);
+ } else {
total: 0 errors, 1 warnings, 3 checks, 308 lines checked
8444ed41ce37 drm/i915: Enable fastboot across the board
Re: [PATCH] drm/buddy: Fix alloc_range() error handling code
On Sat, Feb 10, 2024 at 12:06:58AM +0530, Arunpravin Paneer Selvam wrote:
> Hi Daniel,
>
> On 2/9/2024 11:34 PM, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> > > Few users have observed display corruption when they boot
> > > the machine to KDE Plasma or playing games. We have root
> > > caused the problem that whenever alloc_range() couldn't
> > > find the required memory blocks the function was returning
> > > SUCCESS in some of the corner cases.
> > >
> > > The right approach would be if the total allocated size
> > > is less than the required size, the function should
> > > return -ENOSPC.
> > >
> > > Cc: # 6.7+
> > > Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
> > > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
> > > Tested-by: Mario Limonciello
> > > Link:
> > > https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
> > > Acked-by: Christian König
> > > Reviewed-by: Matthew Auld
> > > Signed-off-by: Arunpravin Paneer Selvam
> > New unit test for this would be most excellent - these kind of missed edge
> > cases is exactly what kunit is for. Can you please follow up with, since
> > we don't want to hold up the bugfix for longer?
> Matthew Auld has added a new unit test for this case. Please let us know if
> this will suffice.
> https://patchwork.freedesktop.org/patch/577497/?series=129671=1
Ah yeah, might be best to submit them both together as one series (you
just need to add your own signed-off-by if you resend other people's
patches). That way bots can pick it up together, since new testcase and
bugfix only make sense together.
-Sima
>
> Thanks,
> Arun.
> > -Sima
> >
> > > ---
> > > drivers/gpu/drm/drm_buddy.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> > > index f57e6d74fb0e..c1a99bf4dffd 100644
> > > --- a/drivers/gpu/drm/drm_buddy.c
> > > +++ b/drivers/gpu/drm/drm_buddy.c
> > > @@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
> > > } while (1);
> > > list_splice_tail(, blocks);
> > > +
> > > + if (total_allocated < size) {
> > > + err = -ENOSPC;
> > > + goto err_free;
> > > + }
> > > +
> > > return 0;
> > > err_undo:
> > > --
> > > 2.25.1
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 5/5] drm/i915: Enable fastboot across the board
From: Ville Syrjälä
There's nothing magical about vlv+ platforms vs. fastboot.
If it works somewhere it should work everywhere, assuming
we've not missed any crucial state checks. That seems unlikely
on older platforms with less state to check anyway.
Just enable fastboot across the board, and the remove the
remnants of the optional stuff (we already removed the
modparam for fastboot anyway).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 22
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 66ee6749fdae..00ac65a14029 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4937,20 +4937,6 @@ pipe_config_pll_mismatch(bool fastset,
}
}
-static bool fastboot_enabled(struct drm_i915_private *dev_priv)
-{
- /* Enable fastboot by default on Skylake and newer */
- if (DISPLAY_VER(dev_priv) >= 9)
- return true;
-
- /* Enable fastboot by default on VLV and CHV */
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- return true;
-
- /* Disabled by default on all others */
- return false;
-}
-
bool
intel_pipe_config_compare(const struct intel_crtc_state *current_config,
const struct intel_crtc_state *pipe_config,
@@ -4959,14 +4945,6 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
struct drm_i915_private *dev_priv =
to_i915(current_config->uapi.crtc->dev);
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
bool ret = true;
- bool fixup_inherited = fastset &&
- current_config->inherited && !pipe_config->inherited;
-
- if (fixup_inherited && !fastboot_enabled(dev_priv)) {
- drm_dbg_kms(_priv->drm,
- "initial modeset and fastboot not set\n");
- ret = false;
- }
#define PIPE_CONF_CHECK_X(name) do { \
if (current_config->name != pipe_config->name) { \
--
2.43.0
[PATCH 4/5] drm/i915: Add PLL .compare_hw_state() vfunc
From: Ville Syrjälä
Chunk up the humenguous dpll_hw_state comparison check into per-platform
variants, implemented in the dpll_mgr. This is step one in allowing
each platform (or perhaps even PLL) type to have a custom hw state
structure instead of having to smash it all into one.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 78 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 95 +++
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 +
3 files changed, 141 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1d381fa96c84..66ee6749fdae 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4907,6 +4907,36 @@ pipe_config_mismatch(bool fastset, const struct
intel_crtc *crtc,
va_end(args);
}
+static void
+pipe_config_pll_mismatch(bool fastset,
+const struct intel_crtc *crtc,
+const char *name,
+const struct intel_dpll_hw_state *a,
+const struct intel_dpll_hw_state *b)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+
+ if (fastset) {
+ if (!drm_debug_enabled(DRM_UT_KMS))
+ return;
+
+ drm_dbg_kms(>drm,
+ "[CRTC:%d:%s] fastset requirement not met in %s\n",
+ crtc->base.base.id, crtc->base.name, name);
+ drm_dbg_kms(>drm, "expected:\n");
+ intel_dpll_dump_hw_state(i915, a);
+ drm_dbg_kms(>drm, "found:\n");
+ intel_dpll_dump_hw_state(i915, b);
+ } else {
+ drm_err(>drm, "[CRTC:%d:%s] mismatch in %s buffer\n",
+ crtc->base.base.id, crtc->base.name, name);
+ drm_err(>drm, "expected:\n");
+ intel_dpll_dump_hw_state(i915, a);
+ drm_err(>drm, "found:\n");
+ intel_dpll_dump_hw_state(i915, b);
+ }
+}
+
static bool fastboot_enabled(struct drm_i915_private *dev_priv)
{
/* Enable fastboot by default on Skylake and newer */
@@ -5016,7 +5046,17 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
} \
} while (0)
-#define PIPE_CONF_CHECK_TIMINGS(name) do { \
+#define PIPE_CONF_CHECK_PLL(name) do { \
+ if (!intel_dpll_compare_hw_state(dev_priv, _config->name, \
+_config->name)) { \
+ pipe_config_pll_mismatch(fastset, crtc, __stringify(name), \
+_config->name, \
+_config->name); \
+ ret = false; \
+ } \
+} while (0)
+
+#define PIPE_CONF_CHECK_TIMINGS(name) do { \
PIPE_CONF_CHECK_I(name.crtc_hdisplay); \
PIPE_CONF_CHECK_I(name.crtc_htotal); \
PIPE_CONF_CHECK_I(name.crtc_hblank_start); \
@@ -5223,40 +5263,8 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_P(shared_dpll);
/* FIXME convert everything over the dpll_mgr */
- if (dev_priv->display.dpll.mgr || HAS_GMCH(dev_priv)) {
- PIPE_CONF_CHECK_X(dpll_hw_state.dpll);
- PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md);
- PIPE_CONF_CHECK_X(dpll_hw_state.fp0);
- PIPE_CONF_CHECK_X(dpll_hw_state.fp1);
- PIPE_CONF_CHECK_X(dpll_hw_state.wrpll);
- PIPE_CONF_CHECK_X(dpll_hw_state.spll);
- PIPE_CONF_CHECK_X(dpll_hw_state.ctrl1);
- PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
- PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
- PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr0);
- PIPE_CONF_CHECK_X(dpll_hw_state.div0);
- PIPE_CONF_CHECK_X(dpll_hw_state.ebb0);
- PIPE_CONF_CHECK_X(dpll_hw_state.ebb4);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll0);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll1);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll2);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll3);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll6);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll8);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll9);
- PIPE_CONF_CHECK_X(dpll_hw_state.pll10);
- PIPE_CONF_CHECK_X(dpll_hw_state.pcsdw12);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_refclkin_ctl);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_clktop2_coreclkctl1);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_clktop2_hsclkctl);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_pll_div0);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_pll_div1);
- PIPE_CONF_CHECK_X(dpll_hw_state.mg_pll_lf);
-
[PATCH 3/5] drm/i915: Reuse ibx_dump_hw_state() for gmch platforms
From: Ville Syrjälä GMCH platform DPLLs are similar to the IBX+ PCH DPLLs so we can just use the same state dump function for both. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c index e7e0a4cf9f93..c6cc7465b92c 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c @@ -4458,13 +4458,7 @@ void intel_dpll_dump_hw_state(struct drm_i915_private *i915, /* fallback for platforms that don't use the shared dpll * infrastructure */ - drm_dbg_kms(>drm, - "dpll_hw_state: dpll: 0x%x, dpll_md: 0x%x, " - "fp0: 0x%x, fp1: 0x%x\n", - hw_state->dpll, - hw_state->dpll_md, - hw_state->fp0, - hw_state->fp1); + ibx_dump_hw_state(i915, hw_state); } } -- 2.43.0
[PATCH 2/5] drm/i915: Include the CRTC name in the ELD buffer mismatch
From: Ville Syrjälä
Most crtc state mismatches include the CRTC id+name in the
prints. Also include it in the ELD buffer mismatch
prints.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f20728b7f67b..1d381fa96c84 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4851,10 +4851,12 @@ memcmp_diff_len(const u8 *a, const u8 *b, size_t len)
}
static void
-pipe_config_buffer_mismatch(struct drm_i915_private *dev_priv,
- bool fastset, const char *name,
+pipe_config_buffer_mismatch(bool fastset, const struct intel_crtc *crtc,
+ const char *name,
const u8 *a, const u8 *b, size_t len)
{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
if (fastset) {
if (!drm_debug_enabled(DRM_UT_KMS))
return;
@@ -4863,7 +4865,8 @@ pipe_config_buffer_mismatch(struct drm_i915_private
*dev_priv,
len = memcmp_diff_len(a, b, len);
drm_dbg_kms(_priv->drm,
- "fastset requirement not met in %s buffer\n", name);
+ "[CRTC:%d:%s] fastset requirement not met in %s
buffer\n",
+ crtc->base.base.id, crtc->base.name, name);
print_hex_dump(KERN_DEBUG, "expected: ", DUMP_PREFIX_NONE,
16, 0, a, len, false);
print_hex_dump(KERN_DEBUG, "found: ", DUMP_PREFIX_NONE,
@@ -4872,7 +4875,8 @@ pipe_config_buffer_mismatch(struct drm_i915_private
*dev_priv,
/* only dump up to the last difference */
len = memcmp_diff_len(a, b, len);
- drm_err(_priv->drm, "mismatch in %s buffer\n", name);
+ drm_err(_priv->drm, "[CRTC:%d:%s] mismatch in %s buffer\n",
+ crtc->base.base.id, crtc->base.name, name);
print_hex_dump(KERN_ERR, "expected: ", DUMP_PREFIX_NONE,
16, 0, a, len, false);
print_hex_dump(KERN_ERR, "found: ", DUMP_PREFIX_NONE,
@@ -5071,7 +5075,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
BUILD_BUG_ON(sizeof(current_config->name) != (len)); \
BUILD_BUG_ON(sizeof(pipe_config->name) != (len)); \
if (!intel_compare_buffer(current_config->name, pipe_config->name,
(len))) { \
- pipe_config_buffer_mismatch(dev_priv, fastset,
__stringify(name), \
+ pipe_config_buffer_mismatch(fastset, crtc, __stringify(name), \
current_config->name, \
pipe_config->name, \
(len)); \
--
2.43.0
[PATCH 1/5] drm/i915: Fix PLL state check for gmch platforms
From: Ville Syrjälä
GMCH DPLL state check was mistakenly removed in
commit 87fc875a2b85 ("drm/i915/dg2: Skip shared DPLL handling").
Bring it back.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7db0655d8c9e..f20728b7f67b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5215,9 +5215,11 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_BOOL(double_wide);
- if (dev_priv->display.dpll.mgr) {
+ if (dev_priv->display.dpll.mgr)
PIPE_CONF_CHECK_P(shared_dpll);
+ /* FIXME convert everything over the dpll_mgr */
+ if (dev_priv->display.dpll.mgr || HAS_GMCH(dev_priv)) {
PIPE_CONF_CHECK_X(dpll_hw_state.dpll);
PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md);
PIPE_CONF_CHECK_X(dpll_hw_state.fp0);
--
2.43.0
[PATCH 0/5] drm/i915: PLL state check stuff
From: Ville Syrjälä Start chunking up the dpll_hw_state momnster into per-platform pieces. Also restore PLL state check on gmch platforms, and flip on fastboot across the board. Ville Syrjälä (5): drm/i915: Fix PLL state check for gmch platforms drm/i915: Include the CRTC name in the ELD buffer mismatch drm/i915: Reuse ibx_dump_hw_state() for gmch platforms drm/i915: Add PLL .compare_hw_state() vfunc drm/i915: Enable fastboot across the board drivers/gpu/drm/i915/display/intel_display.c | 106 -- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 103 +++-- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 + 3 files changed, 148 insertions(+), 64 deletions(-) -- 2.43.0
Re: [PATCH] drm/buddy: Fix alloc_range() error handling code
Hi Daniel,
On 2/9/2024 11:34 PM, Daniel Vetter wrote:
On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
New unit test for this would be most excellent - these kind of missed edge
cases is exactly what kunit is for. Can you please follow up with, since
we don't want to hold up the bugfix for longer?
Matthew Auld has added a new unit test for this case. Please let us know
if this will suffice.
https://patchwork.freedesktop.org/patch/577497/?series=129671=1
Thanks,
Arun.
-Sima
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
--
2.25.1
✓ Fi.CI.BAT: success for drm/i915/gvt: remove redundant assignment to pointer map
== Series Details ==
Series: drm/i915/gvt: remove redundant assignment to pointer map
URL : https://patchwork.freedesktop.org/series/129731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129731v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): fi-apl-guc
Missing(2): bat-kbl-2 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_129731v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_fence@basic-busy@bcs0:
- {bat-arls-1}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-arls-1/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_exec_parallel@engines@userptr:
- {bat-arls-2}: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-2/igt@gem_exec_parallel@engi...@userptr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-arls-2/igt@gem_exec_parallel@engi...@userptr.html
* igt@i915_selftest@live@execlists:
- {bat-arls-1}: [DMESG-WARN][5] ([i915#10194]) -> [DMESG-FAIL][6] +5
other tests dmesg-fail
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-arls-1/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@guc_multi_lrc:
- {bat-arls-1}: NOTRUN -> [DMESG-FAIL][7] +6 other tests dmesg-fail
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-arls-1/igt@i915_selftest@live@guc_multi_lrc.html
Known issues
Here are the changes found in Patchwork_129731v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][8] -> [FAIL][9] ([i915#8293])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/fi-cfl-8109u/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3
other tests skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][11] ([fdo#109271]) +13 other tests
skip
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][12] ([i915#10194]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][14] ([i915#10010]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129731v1/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129731v1
CI-20190529: 20190529
Re: [PATCH] drm/buddy: Fix alloc_range() error handling code
On Fri, Feb 09, 2024 at 08:56:24PM +0530, Arunpravin Paneer Selvam wrote:
> Few users have observed display corruption when they boot
> the machine to KDE Plasma or playing games. We have root
> caused the problem that whenever alloc_range() couldn't
> find the required memory blocks the function was returning
> SUCCESS in some of the corner cases.
>
> The right approach would be if the total allocated size
> is less than the required size, the function should
> return -ENOSPC.
>
> Cc: # 6.7+
> Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
> Tested-by: Mario Limonciello
> Link:
> https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
> Acked-by: Christian König
> Reviewed-by: Matthew Auld
> Signed-off-by: Arunpravin Paneer Selvam
New unit test for this would be most excellent - these kind of missed edge
cases is exactly what kunit is for. Can you please follow up with, since
we don't want to hold up the bugfix for longer?
-Sima
> ---
> drivers/gpu/drm/drm_buddy.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index f57e6d74fb0e..c1a99bf4dffd 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
> } while (1);
>
> list_splice_tail(, blocks);
> +
> + if (total_allocated < size) {
> + err = -ENOSPC;
> + goto err_free;
> + }
> +
> return 0;
>
> err_undo:
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 4/5] drm/xe/hdcp: Enable HDCP for XE
Hi Suraj,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-intel/for-linux-next-fixes
linus/master v6.8-rc3 next-20240209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Suraj-Kandpal/drm-i915-hdcp-Move-intel_hdcp_gsc_message-def-away-from-header-file/20240209-181915
base: https://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next
patch link:
https://lore.kernel.org/r/20240209101412.1326176-5-suraj.kandpal%40intel.com
patch subject: [PATCH 4/5] drm/xe/hdcp: Enable HDCP for XE
config: loongarch-allmodconfig
(https://download.01.org/0day-ci/archive/20240210/202402100132.xip3zz5i-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240210/202402100132.xip3zz5i-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202402100132.xip3zz5i-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/xe/xe_gsc_submit.c:50: warning: expecting prototype for
>> xe_gsc_get_host_session_id(). Prototype was for
>> xe_gsc_create_host_session_id() instead
vim +50 drivers/gpu/drm/xe/xe_gsc_submit.c
42
43 /**
44 * xe_gsc_get_host_session_id - Creates a random 64 bit host_session id
with
45 * bits 56-63 masked.
46 *
47 * Returns: random host_session_id which can be used to send messages
to gsc cs
48 */
49 u64 xe_gsc_create_host_session_id(void)
> 50 {
51 u64 host_session_id;
52
53 get_random_bytes(_session_id, sizeof(u64));
54 host_session_id &= ~HOST_SESSION_CLIENT_MASK;
55 return host_session_id;
56 }
57
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: ✗ Fi.CI.BUILD: failure for series starting with [v3,1/2] drm/i915: Prevent HW access during init from SDVO TV get_modes hook
On Fri, Feb 09, 2024 at 05:23:08PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v3,1/2] drm/i915: Prevent HW access during init > from SDVO TV get_modes hook > URL : https://patchwork.freedesktop.org/series/129727/ > State : failure > > == Summary == > > Error: make failed > CALLscripts/checksyscalls.sh > DESCEND objtool > INSTALL libsubcmd_headers > CC [M] drivers/gpu/drm/i915/display/intel_sdvo.o > drivers/gpu/drm/i915/display/intel_sdvo.c: In function > ‘intel_sdvo_get_tv_modes’: > drivers/gpu/drm/i915/display/intel_sdvo.c:2305:41: error: ‘i915’ undeclared > (first use in this function); did you mean ‘I915’? > 2305 | if (!intel_display_driver_check_access(i915)) > | ^~~~ > | I915 > drivers/gpu/drm/i915/display/intel_sdvo.c:2305:41: note: each undeclared > identifier is reported only once for each function it appears in > make[6]: *** [scripts/Makefile.build:243: > drivers/gpu/drm/i915/display/intel_sdvo.o] Error 1 > make[5]: *** [scripts/Makefile.build:481: drivers/gpu/drm/i915] Error 2 > make[4]: *** [scripts/Makefile.build:481: drivers/gpu/drm] Error 2 > make[3]: *** [scripts/Makefile.build:481: drivers/gpu] Error 2 > make[2]: *** [scripts/Makefile.build:481: drivers] Error 2 > make[1]: *** [/home/kbuild2/kernel/Makefile:1921: .] Error 2 > make: *** [Makefile:240: __sub-make] Error 2 > Build failed, no error log produced Not sure why this fails, on latest drm-tip I get a different result, see below. Looks like an old tree is used as the base, could someone from the CI team check this? $ git fetch drm-tip $ git reset --hard drm-tip/drm-tip HEAD is now at 2aceb3c0b9c8c drm-tip: 2024y-02m-09d-12h-48m-25s UTC integration manifest $ git am ~/imre.mbox Applying: drm/i915: Prevent HW access during init from SDVO TV get_modes hook Applying: drm/i915: Prevent HW access during init from connector get_modes hooks $ make CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/gpu/drm/i915/display/intel_crt.o CC [M] drivers/gpu/drm/i915/display/intel_dp_mst.o CC [M] drivers/gpu/drm/i915/display/intel_dvo.o CC [M] drivers/gpu/drm/i915/display/intel_sdvo.o LD [M] drivers/gpu/drm/i915/i915.o CC [M] drivers/gpu/drm/xe/i915-display/intel_dp_mst.o LD [M] drivers/gpu/drm/xe/xe.o MODPOST Module.symvers Kernel: arch/x86/boot/bzImage is ready (#1476) LD [M] drivers/gpu/drm/i915/i915.ko LD [M] drivers/gpu/drm/xe/xe.ko
✓ Fi.CI.BAT: success for drm/i915/panelreplay: Panel replay workaround with VRR (rev2)
== Series Details ==
Series: drm/i915/panelreplay: Panel replay workaround with VRR (rev2)
URL : https://patchwork.freedesktop.org/series/129632/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129632v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/index.html
Participating hosts (36 -> 35)
--
Additional (1): fi-apl-guc
Missing(2): bat-mtlp-8 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_129632v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@dmabuf:
- {bat-arls-2}: [DMESG-WARN][1] ([i915#10194]) -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-2/igt@i915_selftest@l...@dmabuf.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/bat-arls-2/igt@i915_selftest@l...@dmabuf.html
Known issues
Here are the changes found in Patchwork_129632v2 that come from known issues:
### CI changes ###
Issues hit
* boot:
- bat-jsl-1: [PASS][3] -> [FAIL][4] ([i915#8293])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-jsl-1/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/bat-jsl-1/boot.html
- fi-apl-guc: NOTRUN -> [FAIL][5] ([i915#8293])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/fi-apl-guc/boot.html
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][6] ([i915#9197]) +1 other test skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][7] ([i915#10194]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][9] ([i915#10010]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/bat-adln-1/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#9197]: https://gitlab.freedesktop.org/drm/intel/issues/9197
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129632v2
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129632v2: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
d5644dd32bc8 drm/i915/panelreplay: Panel replay workaround with VRR
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129632v2/index.html
✗ Fi.CI.BUILD: failure for series starting with [v3,1/2] drm/i915: Prevent HW access during init from SDVO TV get_modes hook
== Series Details == Series: series starting with [v3,1/2] drm/i915: Prevent HW access during init from SDVO TV get_modes hook URL : https://patchwork.freedesktop.org/series/129727/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/gpu/drm/i915/display/intel_sdvo.o drivers/gpu/drm/i915/display/intel_sdvo.c: In function ‘intel_sdvo_get_tv_modes’: drivers/gpu/drm/i915/display/intel_sdvo.c:2305:41: error: ‘i915’ undeclared (first use in this function); did you mean ‘I915’? 2305 | if (!intel_display_driver_check_access(i915)) | ^~~~ | I915 drivers/gpu/drm/i915/display/intel_sdvo.c:2305:41: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [scripts/Makefile.build:243: drivers/gpu/drm/i915/display/intel_sdvo.o] Error 1 make[5]: *** [scripts/Makefile.build:481: drivers/gpu/drm/i915] Error 2 make[4]: *** [scripts/Makefile.build:481: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:481: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:481: drivers] Error 2 make[1]: *** [/home/kbuild2/kernel/Makefile:1921: .] Error 2 make: *** [Makefile:240: __sub-make] Error 2 Build failed, no error log produced
✓ Fi.CI.BAT: success for drm/buddy: Fix alloc_range() error handling code (rev3)
== Series Details ==
Series: drm/buddy: Fix alloc_range() error handling code (rev3)
URL : https://patchwork.freedesktop.org/series/129637/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129637v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/index.html
Participating hosts (36 -> 35)
--
Additional (1): fi-apl-guc
Missing(2): bat-adlm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129637v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
other tests skip
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_hangman@error-state-basic:
- bat-mtlp-6: [PASS][2] -> [ABORT][3] ([i915#9414])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-6/igt@i915_hang...@error-state-basic.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/bat-mtlp-6/igt@i915_hang...@error-state-basic.html
* igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][4] ([fdo#109271]) +13 other tests
skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][5] ([i915#10194]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][7] ([i915#10010]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#9414]: https://gitlab.freedesktop.org/drm/intel/issues/9414
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129637v3
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129637v3: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8ab024a3578c drm/buddy: Fix alloc_range() error handling code
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129637v3/index.html
✗ Fi.CI.CHECKPATCH: warning for drm/buddy: Fix alloc_range() error handling code (rev3)
== Series Details == Series: drm/buddy: Fix alloc_range() error handling code (rev3) URL : https://patchwork.freedesktop.org/series/129637/ State : warning == Summary == Error: dim checkpatch failed 49edf7cf2985 drm/buddy: Fix alloc_range() error handling code -:19: WARNING:BAD_SIGN_OFF: Use a single space after Cc: #19: Cc: # 6.7+ total: 0 errors, 1 warnings, 0 checks, 12 lines checked
[PULL] drm-misc-next
Hi Dave and Sima, here's the PR for drm-misc-next for this week. There's nothing that stands out: plenty of fixes, the usual round of newly supported panel and bridge devices, and some changes to the internal interfaces. Best regards Thomas drm-misc-next-2024-02-08: drm-misc-next for v6.9: UAPI Changes: Cross-subsystem Changes: dma-buf: - clean up docs media: - tc358743: fix v4l device registration video: - move all kernel parameters for video behind CONFIG_VIDEO sound: - remove include from header Core Changes: ci: - add tests for msm managed: - add drmm_release_action() with tests ttm: - fix errno codes - simply busy-placement handling - fix page decryption docs: - add new external references - clean up Driver Changes: amdgpu: - clean up bridge: - imx: add i.MX8MP HDMI PVI plus DT bindings, add i.MX8MP HDMI TX plus DT bindings - samsung-dsim: add bsh-smm-s2/pro boards - sii902x: fix probing and unregistration - tc358767: limit pixel PLL input range - switch to new drm_bridge_read_edid() interface - clean up imx: - use devm_ functions during init - clean up lima: - fix memory leak loongson: - fail if no VRAM present meson: - switch to new drm_bridge_read_edid() interface nouveau: - clean up panel: - add BOE TH101MB31IG002-28A plus DT bindings - add EDT ETML1010G3DRA plus DT bindings - add Novatek NT36672E LCD DSI plus DT bindings - nt36523: support 120Hz timings, fix includes - simple: fix display timings on RK32FN48H - visionox-vtdr6130: fix initialization panel-orientation-quirks: - GPD Win Mini vmwgfx: - list command SVGA_3D_CMD_DEFINE_GB_SURFACE_V4 as invalid - fix null-pointer deref in execbuf - refactor display-mode probing - fix fencing for creating cursor MOBs - fix cursor-memory lifetime - clean up xlnx: - fix live video input for ZynqMP DPSUB The following changes since commit f8e4806e0dfa8796b3d7076a7fe054455a59c38b: Merge tag 'drm-misc-next-2024-01-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2024-02-05 13:50:15 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2024-02-08 for you to fetch changes up to 3ce7384048fa1793db0eae013fa377d89256b76f: drm/bridge: remove drm_bridge_get_edid() in favour of drm_bridge_edid_read() (2024-02-08 17:12:33 +0200) drm-misc-next for v6.9: UAPI Changes: Cross-subsystem Changes: dma-buf: - clean up docs media: - tc358743: fix v4l device registration video: - move all kernel parameters for video behind CONFIG_VIDEO sound: - remove include from header Core Changes: ci: - add tests for msm managed: - add drmm_release_action() with tests ttm: - fix errno codes - simply busy-placement handling - fix page decryption docs: - add new external references - clean up Driver Changes: amdgpu: - clean up bridge: - imx: add i.MX8MP HDMI PVI plus DT bindings, add i.MX8MP HDMI TX plus DT bindings - samsung-dsim: add bsh-smm-s2/pro boards - sii902x: fix probing and unregistration - tc358767: limit pixel PLL input range - switch to new drm_bridge_read_edid() interface - clean up imx: - use devm_ functions during init - clean up lima: - fix memory leak loongson: - fail if no VRAM present meson: - switch to new drm_bridge_read_edid() interface nouveau: - clean up panel: - add BOE TH101MB31IG002-28A plus DT bindings - add EDT ETML1010G3DRA plus DT bindings - add Novatek NT36672E LCD DSI plus DT bindings - nt36523: support 120Hz timings, fix includes - simple: fix display timings on RK32FN48H - visionox-vtdr6130: fix initialization panel-orientation-quirks: - GPD Win Mini vmwgfx: - list command SVGA_3D_CMD_DEFINE_GB_SURFACE_V4 as invalid - fix null-pointer deref in execbuf - refactor display-mode probing - fix fencing for creating cursor MOBs - fix cursor-memory lifetime - clean up xlnx: - fix live video input for ZynqMP DPSUB Adam Ford (1): drm/bridge: imx8mp-hdmi-pvi: Fix build warnings Alex Bee (1): drm/rockchip: inno_hdmi: Explicitly include drm_atomic.h Alexander Stein (2): drm: panel: simple: convert LG LB070WV8 fixed mode into display timings media: tc358743: register v4l2 async device only after successful setup Alexander Warnecke (1): drm/panel: Add driver for BOE TH101MB31IG002-28A panel Anatoliy Klymenko (4): drm: xlnx: zynqmp_dpsub: Make drm bridge discoverable drm: xlnx: zynqmp_dpsub: Fix timing for live mode drm: xlnx: zynqmp_dpsub: Clear status register ASAP drm: xlnx: zynqmp_dpsub: Filter interrupts against mask Chen Haonan (1): drm/panel: Simplify with dev_err_probe() Christian König (2): drm/vmwgfx: remove vmw_vram_gmr_placement drm/ttm: return ENOSPC from ttm_bo_mem_space v3 Dario Binacchi (2): drm: bridge: samsung-dsim: enter display mode in the enable() callback drm: bridge: samsung-dsim: complete the
✓ Fi.CI.BAT: success for drm/i915/selftests: Increasing the sleep time for live_rc6_manual (rev3)
== Series Details ==
Series: drm/i915/selftests: Increasing the sleep time for live_rc6_manual (rev3)
URL : https://patchwork.freedesktop.org/series/129664/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129664v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/index.html
Participating hosts (36 -> 37)
--
Additional (2): fi-glk-j4005 fi-apl-guc
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_129664v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_setmode@basic-clone-single-crtc:
- {bat-arls-2}: [SKIP][1] ([i915#10208] / [i915#8809]) -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-2/igt@kms_setm...@basic-clone-single-crtc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/bat-arls-2/igt@kms_setm...@basic-clone-single-crtc.html
Known issues
Here are the changes found in Patchwork_129664v3 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-cfl-8109u: [PASS][3] -> [FAIL][4] ([i915#8293])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/fi-cfl-8109u/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-cfl-8109u/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-glk-j4005: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
other tests skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
- fi-glk-j4005: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_lrc:
- bat-adlp-6: [PASS][8] -> [INCOMPLETE][9] ([i915#9413])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005: NOTRUN -> [SKIP][10] ([fdo#109271]) +6 other tests
skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][11] ([fdo#109271]) +13 other tests
skip
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][12] ([i915#10194]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][14] ([i915#10010]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129664v3/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10208]: https://gitlab.freedesktop.org/drm/intel/issues/10208
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[PATCH][next] drm/i915/gvt: remove redundant assignment to pointer map
The pointer map is being initialized with a value that is never
read, it is being re-assigned later on in a for-loop. The
initialization is redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/i915/gvt/interrupt.c:346:28: warning: Value stored to
'map' during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
b/drivers/gpu/drm/i915/gvt/interrupt.c
index c8e7dfc9f791..8c8e37f50a45 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -343,7 +343,7 @@ static void update_upstream_irq(struct intel_vgpu *vgpu,
{
struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
struct intel_gvt_irq *irq = >gvt->irq;
- struct intel_gvt_irq_map *map = irq->irq_map;
+ struct intel_gvt_irq_map *map;
struct intel_gvt_irq_info *up_irq_info = NULL;
u32 set_bits = 0;
u32 clear_bits = 0;
--
2.39.2
Re: [PATCH v2] drm/i915/panelreplay: Panel replay workaround with VRR
On Fri, Feb 09, 2024 at 09:13:00PM +0530, Animesh Manna wrote:
> Panel Replay VSC SDP not getting sent when VRR is enabled
> and W1 and W2 are 0. So Program Set Context Latency in
> TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
>
> HSD: 14015406119
>
> v1: Initial version.
> v2: Update timings stored in adjusted_mode struct. [Ville]
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_vblank.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
> b/drivers/gpu/drm/i915/display/intel_vblank.c
> index baf7354cb6e2..2e11629e4e9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_vblank.c
> +++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> @@ -552,6 +552,19 @@ void intel_crtc_update_active_timings(const struct
> intel_crtc_state *crtc_state,
> adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
> adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
> adjusted_mode.crtc_vblank_start =
> intel_vrr_vmin_vblank_start(crtc_state);
> +
> + /*
> + * WA: HSD-14015406119
> + * Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY
> register
> + * to at least a value of 1 when Panel Replay is enabled with
> VRR.
> + * Value for TRANS_SET_CONTEXT_LATENCY is calculated by
> substracting
> + * crtc_vdisplay from crtc_vblank_start, so incrementing
> crtc_vblank_start
> + * by 1 if both are equal.
> + */
> + if (DISPLAY_VER(i915) >= 13 && crtc_state->has_panel_replay &&
> + adjusted_mode.crtc_vblank_start ==
> adjusted_mode.crtc_vdisplay)
> + adjusted_mode.crtc_vblank_start += 1;
Wrong place. It needs to done during compute_config/etc.
> +
> vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
> } else {
> mode_flags &= ~I915_MODE_FLAG_VRR;
> --
> 2.29.0
--
Ville Syrjälä
Intel
[PATCH v3 2/2] drm/i915: Prevent HW access during init from connector get_modes hooks
Prevent accessing the HW from the get_modes hooks of connectors deriving
the mode list from the display's EDID. drm_edid_connector_add_modes()
will return the mode list based on the EDID which was cached during a
previous detection/get_modes call.
This also fixes the NULL deref problem (10085) which was
introduced/revealed by
commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during
driver init/shutdown")
After the above change MST connectors will not change state during
driver init/shutdown; thus some of these connectors with no I2C/DDC
adapter registered for them (since the given MST port has no sink
connected) may stay then in the 'unknown' connector status. The
get_modes() hook should not try to use the I2C/DDC adapter in this state
(which would lead to the above NULL deref) which this patch ensures.
v2:
- Remove the redundant check from intel_crt_ddc_get_modes().
- Rebase on latest drm-tip.
- Add Fixes: line / related commit notes.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085
Fixes: bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during
driver init/shutdown")
Signed-off-by: Imre Deak
Reviewed-by: Jouni Högander
Link:
https://patchwork.freedesktop.org/patch/msgid/20240206153910.1758057-3-imre.d...@intel.com
---
drivers/gpu/drm/i915/display/intel_crt.c| 3 +++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
drivers/gpu/drm/i915/display/intel_dvo.c| 5 +
drivers/gpu/drm/i915/display/intel_sdvo.c | 4
4 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index b9733a73e21d4..93479db0f89f6 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -933,6 +933,9 @@ static int intel_crt_get_modes(struct drm_connector
*connector)
struct i2c_adapter *ddc;
int ret;
+ if (!intel_display_driver_check_access(dev_priv))
+ return drm_edid_connector_add_modes(connector);
+
wakeref = intel_display_power_get(dev_priv,
intel_encoder->power_domain);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 5fa25a5a36b55..5307ddd4edcf5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1197,6 +1197,7 @@ static bool intel_dp_mst_initial_fastset_check(struct
intel_encoder *encoder,
static int intel_dp_mst_get_ddc_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct drm_i915_private *i915 = to_i915(intel_connector->base.dev);
struct intel_dp *intel_dp = intel_connector->mst_port;
const struct drm_edid *drm_edid;
int ret;
@@ -1204,6 +1205,9 @@ static int intel_dp_mst_get_ddc_modes(struct
drm_connector *connector)
if (drm_connector_is_unregistered(connector))
return intel_connector_update_modes(connector, NULL);
+ if (!intel_display_driver_check_access(i915))
+ return drm_edid_connector_add_modes(connector);
+
drm_edid = drm_dp_mst_edid_read(connector, _dp->mst_mgr,
intel_connector->port);
ret = intel_connector_update_modes(connector, drm_edid);
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
b/drivers/gpu/drm/i915/display/intel_dvo.c
index 8ca9ae4798a89..c076da75b066e 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++ b/drivers/gpu/drm/i915/display/intel_dvo.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "i915_reg.h"
@@ -338,8 +339,12 @@ intel_dvo_detect(struct drm_connector *_connector, bool
force)
static int intel_dvo_get_modes(struct drm_connector *_connector)
{
struct intel_connector *connector = to_intel_connector(_connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
int num_modes;
+ if (!intel_display_driver_check_access(i915))
+ return drm_edid_connector_add_modes(>base);
+
/*
* We should probably have an i2c driver get_modes function for those
* devices which will have a fixed set of modes determined by the chip
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
b/drivers/gpu/drm/i915/display/intel_sdvo.c
index c67605059aa3e..825638702ac1b 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
@@ -2202,12 +2202,16 @@ intel_sdvo_detect(struct drm_connector *connector, bool
force)
static int intel_sdvo_get_ddc_modes(struct drm_connector *connector)
{
+ struct drm_i915_private *i915 = to_i915(connector->dev);
int num_modes = 0;
const struct drm_edid *drm_edid;
drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
+ if
[PATCH v3 1/2] drm/i915: Prevent HW access during init from SDVO TV get_modes hook
Prevent accessing the HW from the SDVO/TV get_modes connector hook. Returning 0 from the hook will make the caller - drm_helper_probe_single_connector_modes() - return a default/EDID override mode list to users. This matches the case where intel_sdvo_get_tv_modes() fails to retrieve the current mode list due to a HW access failure. v2: Clarify the commit message wrt. which modes get_modes() returns. (Jouni) Signed-off-by: Imre Deak Reviewed-by: Jouni Högander Link: https://patchwork.freedesktop.org/patch/msgid/20240208111838.1950411-1-imre.d...@intel.com --- drivers/gpu/drm/i915/display/intel_sdvo.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c b/drivers/gpu/drm/i915/display/intel_sdvo.c index 412c15d32f07e..c67605059aa3e 100644 --- a/drivers/gpu/drm/i915/display/intel_sdvo.c +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c @@ -2312,6 +2312,9 @@ static int intel_sdvo_get_tv_modes(struct drm_connector *connector) drm_dbg_kms(>drm, "[CONNECTOR:%d:%s]\n", connector->base.id, connector->name); + if (!intel_display_driver_check_access(i915)) + return 0; + /* * Read the list of supported input resolutions for the selected TV * format. -- 2.39.2
[PATCH v2] drm/i915/panelreplay: Panel replay workaround with VRR
Panel Replay VSC SDP not getting sent when VRR is enabled
and W1 and W2 are 0. So Program Set Context Latency in
TRANS_SET_CONTEXT_LATENCY register to at least a value of 1.
HSD: 14015406119
v1: Initial version.
v2: Update timings stored in adjusted_mode struct. [Ville]
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_vblank.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
b/drivers/gpu/drm/i915/display/intel_vblank.c
index baf7354cb6e2..2e11629e4e9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -552,6 +552,19 @@ void intel_crtc_update_active_timings(const struct
intel_crtc_state *crtc_state,
adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
adjusted_mode.crtc_vblank_start =
intel_vrr_vmin_vblank_start(crtc_state);
+
+ /*
+* WA: HSD-14015406119
+* Program Set Context Latency in TRANS_SET_CONTEXT_LATENCY
register
+* to at least a value of 1 when Panel Replay is enabled with
VRR.
+* Value for TRANS_SET_CONTEXT_LATENCY is calculated by
substracting
+* crtc_vdisplay from crtc_vblank_start, so incrementing
crtc_vblank_start
+* by 1 if both are equal.
+*/
+ if (DISPLAY_VER(i915) >= 13 && crtc_state->has_panel_replay &&
+ adjusted_mode.crtc_vblank_start ==
adjusted_mode.crtc_vdisplay)
+ adjusted_mode.crtc_vblank_start += 1;
+
vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
} else {
mode_flags &= ~I915_MODE_FLAG_VRR;
--
2.29.0
✓ Fi.CI.BAT: success for drm/i915/gt: Prevent possible NULL dereference in __caps_show()
== Series Details ==
Series: drm/i915/gt: Prevent possible NULL dereference in __caps_show()
URL : https://patchwork.freedesktop.org/series/129707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129707v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): fi-apl-guc
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129707v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
other tests skip
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][2] -> [ABORT][3] ([i915#9662])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][4] ([fdo#109271]) +13 other tests
skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][5] ([i915#10194]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][7] ([i915#10010]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/bat-adln-1/igt@i915_selftest@live@gt_pm.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#9662]: https://gitlab.freedesktop.org/drm/intel/issues/9662
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129707v1
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129707v1: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
393b3dcc7cea drm/i915/gt: Prevent possible NULL dereference in __caps_show()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129707v1/index.html
[PATCH] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Acked-by: Christian König
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
--
2.25.1
[PATCH] drm/buddy: Fix alloc_range() error handling code
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Cc: # 6.7+
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Tested-by: Mario Limonciello
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20240207174456.341121-1-arunpravin.paneersel...@amd.com/
Reviewed-by: Matthew Auld
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
--
2.25.1
Re: [PATCH v3 1/3] bits: introduce fixed-type genmasks
On Thu, Feb 08, 2024 at 08:48:59PM +0100, Andi Shyti wrote: > On Wed, Feb 07, 2024 at 11:45:19PM -0800, Lucas De Marchi wrote: ... > > Signed-off-by: Yury Norov > > Signed-off-by: Lucas De Marchi > > Acked-by: Jani Nikula > > Lucas' SoB should be at the bottom here. In any case, nice patch: And it's at the bottom (among SoB lines), there is no violation with Submitting Patches. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2] drm/i915/selftests: Increasing the sleep time for live_rc6_manual
Hi Anirban
On 2/9/2024 5:41 PM, Sk Anirban wrote:
From: Anirban Sk
Sometimes gt_pm live_rc6_manual selftest fails due to no power being
measured for the rc6 disabled period. Therefore increasing the rc6 disable
period from 250ms to 1000ms to rule out such sporadic failure.
Signed-off-by: Anirban Sk
Reviewed-by: Anshuman Gupta
Change log:
Remove the above line. move the version info above signed-off.
v2: add Reviewed-by: Anshuman Gupta
don't have to add this
More descriptive and improved commit message.
add the name of the person in brackets
"v2 : More descriptive and improved commit message (Anshuman)"
Thanks
Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_rc6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index a7189c2d660c..1aa1446c8fb0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -62,12 +62,12 @@ int live_rc6_manual(void *arg)
dt = ktime_get();
rc0_power = librapl_energy_uJ();
- msleep(250);
+ msleep(1000);
rc0_power = librapl_energy_uJ() - rc0_power;
dt = ktime_sub(ktime_get(), dt);
res[1] = rc6_residency(rc6);
if ((res[1] - res[0]) >> 10) {
- pr_err("RC6 residency increased by %lldus while disabled for
250ms!\n",
+ pr_err("RC6 residency increased by %lldus while disabled for
1000ms!\n",
(res[1] - res[0]) >> 10);
err = -EINVAL;
goto out_unlock;
Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
On Fri, Feb 09, 2024 at 01:17:27PM +, Kahola, Mika wrote: > > -Original Message- > > From: Ville Syrjälä > > Sent: Friday, February 9, 2024 2:49 PM > > To: Kahola, Mika > > Cc: Jani Nikula ; > > intel-gfx@lists.freedesktop.org > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP > > > > On Fri, Feb 09, 2024 at 12:33:20PM +, Kahola, Mika wrote: > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Friday, February 9, 2024 2:19 PM > > > > To: Kahola, Mika > > > > Cc: Jani Nikula ; > > > > intel-gfx@lists.freedesktop.org > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for > > > > eDP > > > > > > > > On Fri, Feb 09, 2024 at 12:13:02PM +, Kahola, Mika wrote: > > > > > > -Original Message- > > > > > > From: Ville Syrjälä > > > > > > Sent: Friday, February 9, 2024 2:07 PM > > > > > > To: Kahola, Mika > > > > > > Cc: Jani Nikula ; > > > > > > intel-gfx@lists.freedesktop.org > > > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset > > > > > > for eDP > > > > > > > > > > > > On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote: > > > > > > > > -Original Message- > > > > > > > > From: Jani Nikula > > > > > > > > Sent: Friday, February 9, 2024 11:06 AM > > > > > > > > To: Kahola, Mika ; > > > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > > Cc: Kahola, Mika > > > > > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full > > > > > > > > modeset for eDP > > > > > > > > > > > > > > > > On Tue, 06 Feb 2024, Mika Kahola wrote: > > > > > > > > > Force full modeset for eDP when booting up. GOP programs > > > > > > > > > PLL parameters and hence, we would be able to use fastset for > > > > > > > > > eDP. > > > > > > > > > However, with fastset we are not setting PLL values from > > > > > > > > > the driver and rely that GOP and driver PLL values match. > > > > > > > > > We have discovered that with some of the panels this is > > > > > > > > > not true and hence we would need to program PLL values by > > > > > > > > > the driver. The patch suggests a workaround as enabling > > > > > > > > > full modeset when booting up. This way we force the driver to > > > > > > > > > write the PLL values to the hw. > > > > > > > > > > > > > > > > No. We want to avoid full modesets if possible, both in general > > > > > > > > and at probe. > > > > > > > > > > > > > > > > And when we do end up with modesets, the decision needs to > > > > > > > > be based on changes in the state that we can't write to the > > > > > > > > hardware without a modeset. > > > > > > > > > > > > > > > > We can't unconditionally force a modeset on eDP panels at probe. > > > > > > > > > > > > > > Thanks! Just wondering what the options here might be? With > > > > > > > fastest we end up having a mismatch with one PLL value with a > > > > > > few panels. > > > > > > > > > > > > You seem to be stuck in some infinite loop. If your PLL > > > > > > parameters are mismatching that should prevent the fastset, but > > > > > > then I guess you added some hack to allow the fastset despite > > > > > > the mismatch, and now you're trying to undo that hack by blindly > > > > > > forcing a > > > > full modeset? > > > > > > > > > > That's right, I found myself to be between a rock and a hard place. I > > > > > did discard the fastest but found out that we cannot do > > that. > > > > > > > > If you discarded it then why are you not already getting the full > > > > modeset you want? > > > > > > > Poor choice of words, I guess. What I meant that I discarded the state > > > verification in case of fastest. This way the mismatch is > > hidden under the carpet. > > > > Right. So just add the state verification back and it'll just work (tm). > > I wish it would be that simple. With fastest it seems that we are not > programming PLL values but instead rely the ones GOP programs. When reading > out these values from HW there is this one value that differs from the SW > state defined by our driver. I was thinking about that we should read the > state from HW and update our SW state based on that but then we would end up > comparing HW state to HW state, which to me is not what state verification is > all about. The actual problem would appear to be that someone forgot to handle these snps/cx0 PLLs in pipe_config_compare(). Implementing these PLLs outside the dpll_mgr framework was another big mistake. And the ridonculous size of dpll_hw_state is another problem. We need to do some major refactoring to clean up this mess once and for all. Some kind of plan: 1. move all PLLs over to the dpll_mgr framework, starting with snps/cx0 2. move all PLL hw state verification into the dpll_mgr so it can be customized per-PLL type 3. Perhaps make dpll_hw_state opaque and split it up into per-PLL type variants. Need to think about memory allocation issues with this one... I think I'll see if I can quickly type up a start for
RE: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> -Original Message- > From: Ville Syrjälä > Sent: Friday, February 9, 2024 2:49 PM > To: Kahola, Mika > Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP > > On Fri, Feb 09, 2024 at 12:33:20PM +, Kahola, Mika wrote: > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Friday, February 9, 2024 2:19 PM > > > To: Kahola, Mika > > > Cc: Jani Nikula ; > > > intel-gfx@lists.freedesktop.org > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for > > > eDP > > > > > > On Fri, Feb 09, 2024 at 12:13:02PM +, Kahola, Mika wrote: > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: Friday, February 9, 2024 2:07 PM > > > > > To: Kahola, Mika > > > > > Cc: Jani Nikula ; > > > > > intel-gfx@lists.freedesktop.org > > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset > > > > > for eDP > > > > > > > > > > On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote: > > > > > > > -Original Message- > > > > > > > From: Jani Nikula > > > > > > > Sent: Friday, February 9, 2024 11:06 AM > > > > > > > To: Kahola, Mika ; > > > > > > > intel-gfx@lists.freedesktop.org > > > > > > > Cc: Kahola, Mika > > > > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full > > > > > > > modeset for eDP > > > > > > > > > > > > > > On Tue, 06 Feb 2024, Mika Kahola wrote: > > > > > > > > Force full modeset for eDP when booting up. GOP programs > > > > > > > > PLL parameters and hence, we would be able to use fastset for > > > > > > > > eDP. > > > > > > > > However, with fastset we are not setting PLL values from > > > > > > > > the driver and rely that GOP and driver PLL values match. > > > > > > > > We have discovered that with some of the panels this is > > > > > > > > not true and hence we would need to program PLL values by > > > > > > > > the driver. The patch suggests a workaround as enabling > > > > > > > > full modeset when booting up. This way we force the driver to > > > > > > > > write the PLL values to the hw. > > > > > > > > > > > > > > No. We want to avoid full modesets if possible, both in general > > > > > > > and at probe. > > > > > > > > > > > > > > And when we do end up with modesets, the decision needs to > > > > > > > be based on changes in the state that we can't write to the > > > > > > > hardware without a modeset. > > > > > > > > > > > > > > We can't unconditionally force a modeset on eDP panels at probe. > > > > > > > > > > > > Thanks! Just wondering what the options here might be? With > > > > > > fastest we end up having a mismatch with one PLL value with a > > > > > few panels. > > > > > > > > > > You seem to be stuck in some infinite loop. If your PLL > > > > > parameters are mismatching that should prevent the fastset, but > > > > > then I guess you added some hack to allow the fastset despite > > > > > the mismatch, and now you're trying to undo that hack by blindly > > > > > forcing a > > > full modeset? > > > > > > > > That's right, I found myself to be between a rock and a hard place. I > > > > did discard the fastest but found out that we cannot do > that. > > > > > > If you discarded it then why are you not already getting the full modeset > > > you want? > > > > > Poor choice of words, I guess. What I meant that I discarded the state > > verification in case of fastest. This way the mismatch is > hidden under the carpet. > > Right. So just add the state verification back and it'll just work (tm). I wish it would be that simple. With fastest it seems that we are not programming PLL values but instead rely the ones GOP programs. When reading out these values from HW there is this one value that differs from the SW state defined by our driver. I was thinking about that we should read the state from HW and update our SW state based on that but then we would end up comparing HW state to HW state, which to me is not what state verification is all about. > > > > > > > > > Here, another hack is introduced to force the full modeset to > > > > ensure that the driver programs these PLL values. As Jani already > > > mentioned, this is a no go option as well. > > > > > > > > > > > > > > > > > > > > > Should we try identify the panels and setup some sort of > > > > > > quirks for these problematic panels or what would be the best > > > solution? > > > > > > > > > > > > -Mika- > > > > > > > > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > Jani. > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Mika Kahola > > > > > > > > --- > > > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 13 > > > > > > > > + > > > > > > > > 1 file changed, 13 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > > > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c > > > > > > > > index ab415f41924d..9699ded1eb5f 100644 > > > > > > > > ---
Re: [PATCH] drm/buddy: Fix alloc_range() error handling code
On 2/8/2024 7:47 PM, Matthew Auld wrote:
On 08/02/2024 13:47, Arunpravin Paneer Selvam wrote:
Hi Matthew,
On 2/8/2024 7:00 PM, Matthew Auld wrote:
On 07/02/2024 17:44, Arunpravin Paneer Selvam wrote:
Few users have observed display corruption when they boot
the machine to KDE Plasma or playing games. We have root
caused the problem that whenever alloc_range() couldn't
find the required memory blocks the function was returning
SUCCESS in some of the corner cases.
Can you please give an example here?
In the try hard contiguous allocation, for example the requested
memory is 1024 pages,
it might go and pick the highest and last block (of size 512 pages)
in the freelist where
there are no more space exist in the total address range. In this
kind of corner case,
alloc_range was returning success though the allocated size is less
than the requested size.
Hence in try_hard_contiguous_allocation, we will not proceed to the
LHS allocation and
we return only with the RHS allocation having only the 512 pages of
allocation. This
leads to display corruption in many use cases (I think mainly when
requested for contiguous huge buffer)
mainly on APU platforms.
Ok, I guess other thing is doing:
lhs_offset = drm_buddy_block_offset(block) - lhs_size;
I presume it's possible for block_offset < lhs_size here, which might
be funny?
yes, seems it is possible, I will modify the lhs_offset calculation and
send the patch for review.
Thanks,
Arun.
Thanks,
Arun.
The right approach would be if the total allocated size
is less than the required size, the function should
return -ENOSPC.
Gitlab ticket link -
https://gitlab.freedesktop.org/drm/amd/-/issues/3097
Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory
allocation")
Signed-off-by: Arunpravin Paneer Selvam
Tested-by: Mario Limonciello
---
drivers/gpu/drm/drm_buddy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..c1a99bf4dffd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -539,6 +539,12 @@ static int __alloc_range(struct drm_buddy *mm,
} while (1);
list_splice_tail(, blocks);
+
+ if (total_allocated < size) {
+ err = -ENOSPC;
+ goto err_free;
+ }
+
return 0;
err_undo:
Re: [PATCH 00/13] drm/i915: drm_dbg_kms() conversions and cleanups
On Thu, Feb 08, 2024 at 05:52:38PM +0200, Jani Nikula wrote: > On Thu, 08 Feb 2024, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Convert a bunch of lingering DRM_DEBUG_KMS() & co. to the > > per-device drm_dbg_kms() variants. The stuff remining after this > > are DVO encoder drivers, DMI match functions, and ACPI/DSM stuff. > > > > And also include a bit of other house cleaning I spotted. > > > > Ville Syrjälä (13): > > drm/i915: Correct for_each_old_global_obj_in_state() arguments > > drm/i915/sdvo: Convert to per-device debugs > > drm/i915/sdvo: Fix up code alignment > > drm/i915/color: Use per-device debugs > > drm/i915/fb: Use per-device debugs > > drm/i915/bios: Switch to kms debugs > > drm/i915/bios: Use per-device debugs for VBT related stuff > > drm/i915/hdcp: Use per-device debugs > > drm/i915/wm: Pass the whole i916 to intel_get_cxsr_latency() > > Off by one in the subject there. ;) Doh. I did spot that myself but then forgot to fix it anyway. > > Other than that, the series is > > Reviewed-by: Jani Nikula Thanks. Pushed the lot. > > > > drm/i915/wm: Use per-device debugs in pre-ilk wm code > > drm/i915/wm: Use per-device debugs ilk wm code > > drm/i915/dvo/ns2501: Nuke pointless casts > > drm/i915/dvo: Use sizeof(*variable) instead of sizeof(type) > > > > drivers/gpu/drm/i915/display/dvo_ch7017.c | 2 +- > > drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 2 +- > > drivers/gpu/drm/i915/display/dvo_ivch.c | 2 +- > > drivers/gpu/drm/i915/display/dvo_ns2501.c | 6 +- > > drivers/gpu/drm/i915/display/dvo_sil164.c | 2 +- > > drivers/gpu/drm/i915/display/dvo_tfp410.c | 2 +- > > drivers/gpu/drm/i915/display/i9xx_wm.c| 81 +++ > > drivers/gpu/drm/i915/display/intel_bios.c | 73 +++--- > > drivers/gpu/drm/i915/display/intel_bios.h | 3 +- > > drivers/gpu/drm/i915/display/intel_color.c| 11 +- > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12 +- > > drivers/gpu/drm/i915/display/intel_fb.c | 7 +- > > .../gpu/drm/i915/display/intel_global_state.h | 4 +- > > drivers/gpu/drm/i915/display/intel_opregion.c | 6 +- > > drivers/gpu/drm/i915/display/intel_sdvo.c | 217 ++ > > 15 files changed, 233 insertions(+), 197 deletions(-) > > -- > Jani Nikula, Intel -- Ville Syrjälä Intel
Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
On Fri, Feb 09, 2024 at 12:33:20PM +, Kahola, Mika wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Friday, February 9, 2024 2:19 PM
> > To: Kahola, Mika
> > Cc: Jani Nikula ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> >
> > On Fri, Feb 09, 2024 at 12:13:02PM +, Kahola, Mika wrote:
> > > > -Original Message-
> > > > From: Ville Syrjälä
> > > > Sent: Friday, February 9, 2024 2:07 PM
> > > > To: Kahola, Mika
> > > > Cc: Jani Nikula ;
> > > > intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for
> > > > eDP
> > > >
> > > > On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote:
> > > > > > -Original Message-
> > > > > > From: Jani Nikula
> > > > > > Sent: Friday, February 9, 2024 11:06 AM
> > > > > > To: Kahola, Mika ;
> > > > > > intel-gfx@lists.freedesktop.org
> > > > > > Cc: Kahola, Mika
> > > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset
> > > > > > for eDP
> > > > > >
> > > > > > On Tue, 06 Feb 2024, Mika Kahola wrote:
> > > > > > > Force full modeset for eDP when booting up. GOP programs PLL
> > > > > > > parameters and hence, we would be able to use fastset for eDP.
> > > > > > > However, with fastset we are not setting PLL values from the
> > > > > > > driver and rely that GOP and driver PLL values match.
> > > > > > > We have discovered that with some of the panels this is not
> > > > > > > true and hence we would need to program PLL values by the
> > > > > > > driver. The patch suggests a workaround as enabling full
> > > > > > > modeset when booting up. This way we force the driver to write
> > > > > > > the PLL values to the hw.
> > > > > >
> > > > > > No. We want to avoid full modesets if possible, both in general and
> > > > > > at probe.
> > > > > >
> > > > > > And when we do end up with modesets, the decision needs to be
> > > > > > based on changes in the state that we can't write to the hardware
> > > > > > without a modeset.
> > > > > >
> > > > > > We can't unconditionally force a modeset on eDP panels at probe.
> > > > >
> > > > > Thanks! Just wondering what the options here might be? With
> > > > > fastest we end up having a mismatch with one PLL value with a
> > > > few panels.
> > > >
> > > > You seem to be stuck in some infinite loop. If your PLL parameters
> > > > are mismatching that should prevent the fastset, but then I guess
> > > > you added some hack to allow the fastset despite the mismatch, and now
> > > > you're trying to undo that hack by blindly forcing a
> > full modeset?
> > >
> > > That's right, I found myself to be between a rock and a hard place. I did
> > > discard the fastest but found out that we cannot do that.
> >
> > If you discarded it then why are you not already getting the full modeset
> > you want?
> >
> Poor choice of words, I guess. What I meant that I discarded the state
> verification in case of fastest. This way the mismatch is hidden under the
> carpet.
Right. So just add the state verification back and it'll just work (tm).
>
>
> > > Here, another hack is introduced to force the full modeset to ensure that
> > > the driver programs these PLL values. As Jani already
> > mentioned, this is a no go option as well.
> > >
> > > >
> > > > >
> > > > > Should we try identify the panels and setup some sort of quirks for
> > > > > these problematic panels or what would be the best
> > solution?
> > > > >
> > > > > -Mika-
> > > > >
> > > > > >
> > > > > >
> > > > > > BR,
> > > > > > Jani.
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Mika Kahola
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > > > > > > 1 file changed, 13 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > index ab415f41924d..9699ded1eb5f 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > > > > > > intel_encoder *encoder,
> > > > > > >* of crtc_state->dsc, we have no way to ensure reliable
> > > > > > > fastset.
> > > > > > >* Remove once we have readout for DSC.
> > > > > > >*/
> > > > > > > +
> > > > > > > if (crtc_state->dsc.compression_enable) {
> > > > > > > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full
> > > > > > > modeset due to DSC being enabled\n",
> > > > > > > encoder->base.base.id, encoder->base.name);
> > > > > > > @@ -3326,6
> > > > > > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct
> > > > > > > +intel_encoder *encoder,
> > > > > > > fastset = false;
> > > > > > > }
> > > > > > >
> > > > > > > + /*
> > > > > > > + * FIXME hack to force full modeset for eDP as not
✓ Fi.CI.BAT: success for drm/i915: Add flex arrays to struct i915_syncmap
== Series Details ==
Series: drm/i915: Add flex arrays to struct i915_syncmap
URL : https://patchwork.freedesktop.org/series/129706/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129706v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/index.html
Participating hosts (36 -> 35)
--
Additional (1): fi-apl-guc
Missing(2): bat-mtlp-8 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129706v1 that come from known issues:
### CI changes ###
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
other tests skip
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@kms_hdmi_inject@inject-audio:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271]) +13 other tests
skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/fi-apl-guc/igt@kms_hdmi_inj...@inject-audio.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][3] ([i915#10194]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][5] ([i915#10010]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/bat-adln-1/igt@i915_selftest@live@gt_pm.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#10197]: https://gitlab.freedesktop.org/drm/intel/issues/10197
[i915#10206]: https://gitlab.freedesktop.org/drm/intel/issues/10206
[i915#10211]: https://gitlab.freedesktop.org/drm/intel/issues/10211
[i915#10234]: https://gitlab.freedesktop.org/drm/intel/issues/10234
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129706v1
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129706v1: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
bc318fe64b90 drm/i915: Add flex arrays to struct i915_syncmap
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129706v1/index.html
RE: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, February 9, 2024 2:19 PM
> To: Kahola, Mika
> Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
>
> On Fri, Feb 09, 2024 at 12:13:02PM +, Kahola, Mika wrote:
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: Friday, February 9, 2024 2:07 PM
> > > To: Kahola, Mika
> > > Cc: Jani Nikula ;
> > > intel-gfx@lists.freedesktop.org
> > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for
> > > eDP
> > >
> > > On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote:
> > > > > -Original Message-
> > > > > From: Jani Nikula
> > > > > Sent: Friday, February 9, 2024 11:06 AM
> > > > > To: Kahola, Mika ;
> > > > > intel-gfx@lists.freedesktop.org
> > > > > Cc: Kahola, Mika
> > > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset
> > > > > for eDP
> > > > >
> > > > > On Tue, 06 Feb 2024, Mika Kahola wrote:
> > > > > > Force full modeset for eDP when booting up. GOP programs PLL
> > > > > > parameters and hence, we would be able to use fastset for eDP.
> > > > > > However, with fastset we are not setting PLL values from the
> > > > > > driver and rely that GOP and driver PLL values match.
> > > > > > We have discovered that with some of the panels this is not
> > > > > > true and hence we would need to program PLL values by the
> > > > > > driver. The patch suggests a workaround as enabling full
> > > > > > modeset when booting up. This way we force the driver to write the
> > > > > > PLL values to the hw.
> > > > >
> > > > > No. We want to avoid full modesets if possible, both in general and
> > > > > at probe.
> > > > >
> > > > > And when we do end up with modesets, the decision needs to be
> > > > > based on changes in the state that we can't write to the hardware
> > > > > without a modeset.
> > > > >
> > > > > We can't unconditionally force a modeset on eDP panels at probe.
> > > >
> > > > Thanks! Just wondering what the options here might be? With
> > > > fastest we end up having a mismatch with one PLL value with a
> > > few panels.
> > >
> > > You seem to be stuck in some infinite loop. If your PLL parameters
> > > are mismatching that should prevent the fastset, but then I guess
> > > you added some hack to allow the fastset despite the mismatch, and now
> > > you're trying to undo that hack by blindly forcing a
> full modeset?
> >
> > That's right, I found myself to be between a rock and a hard place. I did
> > discard the fastest but found out that we cannot do that.
>
> If you discarded it then why are you not already getting the full modeset you
> want?
>
Poor choice of words, I guess. What I meant that I discarded the state
verification in case of fastest. This way the mismatch is hidden under the
carpet.
> > Here, another hack is introduced to force the full modeset to ensure that
> > the driver programs these PLL values. As Jani already
> mentioned, this is a no go option as well.
> >
> > >
> > > >
> > > > Should we try identify the panels and setup some sort of quirks for
> > > > these problematic panels or what would be the best
> solution?
> > > >
> > > > -Mika-
> > > >
> > > > >
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > > >
> > > > > > Signed-off-by: Mika Kahola
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > > > > > 1 file changed, 13 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > index ab415f41924d..9699ded1eb5f 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > > > > > intel_encoder *encoder,
> > > > > > * of crtc_state->dsc, we have no way to ensure reliable
> > > > > > fastset.
> > > > > > * Remove once we have readout for DSC.
> > > > > > */
> > > > > > +
> > > > > > if (crtc_state->dsc.compression_enable) {
> > > > > > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full
> > > > > > modeset due to DSC being enabled\n",
> > > > > > encoder->base.base.id, encoder->base.name);
> > > > > > @@ -3326,6
> > > > > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct
> > > > > > +intel_encoder *encoder,
> > > > > > fastset = false;
> > > > > > }
> > > > > >
> > > > > > + /*
> > > > > > +* FIXME hack to force full modeset for eDP as not always BIOS
> > > > > > written PLL
> > > > > > +* values does not match with the ones defined in the driver
> > > > > > code
> > > > > > +*/
> > > > > > + if (!crtc_state->uapi.mode_changed &&
> > > > > > + intel_dp_is_edp(intel_dp)) {
> > > > > > + drm_dbg_kms(>drm, "Forcing full modeset for
> > > > > > eDP\n");
> > > >
Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
On Fri, Feb 09, 2024 at 12:13:02PM +, Kahola, Mika wrote:
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Friday, February 9, 2024 2:07 PM
> > To: Kahola, Mika
> > Cc: Jani Nikula ;
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> >
> > On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote:
> > > > -Original Message-
> > > > From: Jani Nikula
> > > > Sent: Friday, February 9, 2024 11:06 AM
> > > > To: Kahola, Mika ;
> > > > intel-gfx@lists.freedesktop.org
> > > > Cc: Kahola, Mika
> > > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for
> > > > eDP
> > > >
> > > > On Tue, 06 Feb 2024, Mika Kahola wrote:
> > > > > Force full modeset for eDP when booting up. GOP programs PLL
> > > > > parameters and hence, we would be able to use fastset for eDP.
> > > > > However, with fastset we are not setting PLL values from the
> > > > > driver and rely that GOP and driver PLL values match.
> > > > > We have discovered that with some of the panels this is not true
> > > > > and hence we would need to program PLL values by the driver. The
> > > > > patch suggests a workaround as enabling full modeset when booting
> > > > > up. This way we force the driver to write the PLL values to the hw.
> > > >
> > > > No. We want to avoid full modesets if possible, both in general and at
> > > > probe.
> > > >
> > > > And when we do end up with modesets, the decision needs to be based
> > > > on changes in the state that we can't write to the hardware without a
> > > > modeset.
> > > >
> > > > We can't unconditionally force a modeset on eDP panels at probe.
> > >
> > > Thanks! Just wondering what the options here might be? With fastest we
> > > end up having a mismatch with one PLL value with a
> > few panels.
> >
> > You seem to be stuck in some infinite loop. If your PLL parameters are
> > mismatching that should prevent the fastset, but then I
> > guess you added some hack to allow the fastset despite the mismatch, and
> > now you're trying to undo that hack by blindly forcing a
> > full modeset?
>
> That's right, I found myself to be between a rock and a hard place. I did
> discard the fastest but found out that we cannot do that.
If you discarded it then why are you not already getting the full
modeset you want?
> Here, another hack is introduced to force the full modeset to ensure that the
> driver programs these PLL values. As Jani already mentioned, this is a no go
> option as well.
>
> >
> > >
> > > Should we try identify the panels and setup some sort of quirks for these
> > > problematic panels or what would be the best solution?
> > >
> > > -Mika-
> > >
> > > >
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Mika Kahola
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > > > > 1 file changed, 13 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > index ab415f41924d..9699ded1eb5f 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > > > > intel_encoder *encoder,
> > > > >* of crtc_state->dsc, we have no way to ensure reliable
> > > > > fastset.
> > > > >* Remove once we have readout for DSC.
> > > > >*/
> > > > > +
> > > > > if (crtc_state->dsc.compression_enable) {
> > > > > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full
> > > > > modeset due to DSC being enabled\n",
> > > > > encoder->base.base.id, encoder->base.name);
> > > > > @@ -3326,6
> > > > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct
> > > > > +intel_encoder *encoder,
> > > > > fastset = false;
> > > > > }
> > > > >
> > > > > + /*
> > > > > + * FIXME hack to force full modeset for eDP as not always BIOS
> > > > > written PLL
> > > > > + * values does not match with the ones defined in the driver
> > > > > code
> > > > > + */
> > > > > + if (!crtc_state->uapi.mode_changed &&
> > > > > + intel_dp_is_edp(intel_dp)) {
> > > > > + drm_dbg_kms(>drm, "Forcing full modeset for
> > > > > eDP\n");
> > > > > + crtc_state->uapi.mode_changed = true;
> > > > > + fastset = false;
> > > > > + }
> > > > > +
> > > > > +
> > > > > return fastset;
> > > > > }
> > > >
> > > > --
> > > > Jani Nikula, Intel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
RE: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, February 9, 2024 2:07 PM
> To: Kahola, Mika
> Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
>
> On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote:
> > > -Original Message-
> > > From: Jani Nikula
> > > Sent: Friday, February 9, 2024 11:06 AM
> > > To: Kahola, Mika ;
> > > intel-gfx@lists.freedesktop.org
> > > Cc: Kahola, Mika
> > > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for
> > > eDP
> > >
> > > On Tue, 06 Feb 2024, Mika Kahola wrote:
> > > > Force full modeset for eDP when booting up. GOP programs PLL
> > > > parameters and hence, we would be able to use fastset for eDP.
> > > > However, with fastset we are not setting PLL values from the
> > > > driver and rely that GOP and driver PLL values match.
> > > > We have discovered that with some of the panels this is not true
> > > > and hence we would need to program PLL values by the driver. The
> > > > patch suggests a workaround as enabling full modeset when booting
> > > > up. This way we force the driver to write the PLL values to the hw.
> > >
> > > No. We want to avoid full modesets if possible, both in general and at
> > > probe.
> > >
> > > And when we do end up with modesets, the decision needs to be based
> > > on changes in the state that we can't write to the hardware without a
> > > modeset.
> > >
> > > We can't unconditionally force a modeset on eDP panels at probe.
> >
> > Thanks! Just wondering what the options here might be? With fastest we end
> > up having a mismatch with one PLL value with a
> few panels.
>
> You seem to be stuck in some infinite loop. If your PLL parameters are
> mismatching that should prevent the fastset, but then I
> guess you added some hack to allow the fastset despite the mismatch, and now
> you're trying to undo that hack by blindly forcing a
> full modeset?
That's right, I found myself to be between a rock and a hard place. I did
discard the fastest but found out that we cannot do that. Here, another hack is
introduced to force the full modeset to ensure that the driver programs these
PLL values. As Jani already mentioned, this is a no go option as well.
>
> >
> > Should we try identify the panels and setup some sort of quirks for these
> > problematic panels or what would be the best solution?
> >
> > -Mika-
> >
> > >
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Mika Kahola
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index ab415f41924d..9699ded1eb5f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > > > intel_encoder *encoder,
> > > > * of crtc_state->dsc, we have no way to ensure reliable
> > > > fastset.
> > > > * Remove once we have readout for DSC.
> > > > */
> > > > +
> > > > if (crtc_state->dsc.compression_enable) {
> > > > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full
> > > > modeset due to DSC being enabled\n",
> > > > encoder->base.base.id, encoder->base.name);
> > > > @@ -3326,6
> > > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct
> > > > +intel_encoder *encoder,
> > > > fastset = false;
> > > > }
> > > >
> > > > + /*
> > > > +* FIXME hack to force full modeset for eDP as not always BIOS
> > > > written PLL
> > > > +* values does not match with the ones defined in the driver
> > > > code
> > > > +*/
> > > > + if (!crtc_state->uapi.mode_changed &&
> > > > + intel_dp_is_edp(intel_dp)) {
> > > > + drm_dbg_kms(>drm, "Forcing full modeset for
> > > > eDP\n");
> > > > + crtc_state->uapi.mode_changed = true;
> > > > + fastset = false;
> > > > + }
> > > > +
> > > > +
> > > > return fastset;
> > > > }
> > >
> > > --
> > > Jani Nikula, Intel
>
> --
> Ville Syrjälä
> Intel
Re: Re: [PATCH 09/10] drm/xe: switch from drm_debug_printer() to device specific drm_dbg_printer()
On Thu, 01 Feb 2024, Lucas De Marchi wrote: > Do you plan to also merge the last patch where you remove > drm_debug_printer()? Any conflict to be solved in the merge commit? > > This is just a question to know what's the plan, not preferring > something else. I looked into it, didn't see any conflicts, and merged away. Hopefully none pop up until the branches merge again. > Acked-by: Lucas De Marchi Thanks, Jani. -- Jani Nikula, Intel
Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
On Fri, Feb 09, 2024 at 11:55:58AM +, Kahola, Mika wrote:
> > -Original Message-
> > From: Jani Nikula
> > Sent: Friday, February 9, 2024 11:06 AM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Cc: Kahola, Mika
> > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> >
> > On Tue, 06 Feb 2024, Mika Kahola wrote:
> > > Force full modeset for eDP when booting up. GOP programs PLL
> > > parameters and hence, we would be able to use fastset for eDP.
> > > However, with fastset we are not setting PLL values from the driver
> > > and rely that GOP and driver PLL values match.
> > > We have discovered that with some of the panels this is not true and
> > > hence we would need to program PLL values by the driver. The patch
> > > suggests a workaround as enabling full modeset when booting up. This
> > > way we force the driver to write the PLL values to the hw.
> >
> > No. We want to avoid full modesets if possible, both in general and at
> > probe.
> >
> > And when we do end up with modesets, the decision needs to be based on
> > changes in the state that we can't write to the
> > hardware without a modeset.
> >
> > We can't unconditionally force a modeset on eDP panels at probe.
>
> Thanks! Just wondering what the options here might be? With fastest we end up
> having a mismatch with one PLL value with a few panels.
You seem to be stuck in some infinite loop. If your PLL parameters
are mismatching that should prevent the fastset, but then I guess
you added some hack to allow the fastset despite the mismatch, and
now you're trying to undo that hack by blindly forcing a full
modeset?
>
> Should we try identify the panels and setup some sort of quirks for these
> problematic panels or what would be the best solution?
>
> -Mika-
>
> >
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Mika Kahola
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index ab415f41924d..9699ded1eb5f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > > intel_encoder *encoder,
> > >* of crtc_state->dsc, we have no way to ensure reliable fastset.
> > >* Remove once we have readout for DSC.
> > >*/
> > > +
> > > if (crtc_state->dsc.compression_enable) {
> > > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset
> > > due to DSC being enabled\n",
> > > encoder->base.base.id, encoder->base.name); @@
> > > -3326,6
> > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct intel_encoder
> > > *encoder,
> > > fastset = false;
> > > }
> > >
> > > + /*
> > > + * FIXME hack to force full modeset for eDP as not always BIOS written
> > > PLL
> > > + * values does not match with the ones defined in the driver code
> > > + */
> > > + if (!crtc_state->uapi.mode_changed &&
> > > + intel_dp_is_edp(intel_dp)) {
> > > + drm_dbg_kms(>drm, "Forcing full modeset for eDP\n");
> > > + crtc_state->uapi.mode_changed = true;
> > > + fastset = false;
> > > + }
> > > +
> > > +
> > > return fastset;
> > > }
> >
> > --
> > Jani Nikula, Intel
--
Ville Syrjälä
Intel
✓ Fi.CI.BAT: success for XE HDCP Enablement (rev4)
== Series Details ==
Series: XE HDCP Enablement (rev4)
URL : https://patchwork.freedesktop.org/series/129456/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14248 -> Patchwork_129456v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/index.html
Participating hosts (36 -> 36)
--
Additional (1): fi-glk-j4005
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_129456v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-glk-j4005: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-glk-j4005: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
other tests skip
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-glk-j4005: NOTRUN -> [SKIP][3] ([fdo#109271]) +6 other tests skip
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/fi-glk-j4005/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_fence@basic-busy@ccs0:
- {bat-arls-1}: [DMESG-WARN][4] ([i915#10194]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html
* igt@i915_selftest@live@gt_pm:
- bat-adln-1: [DMESG-FAIL][6] ([i915#10010]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-mtlp-8: [DMESG-WARN][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14248/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/bat-mtlp-8/igt@i915_selftest@l...@hangcheck.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#10010]: https://gitlab.freedesktop.org/drm/intel/issues/10010
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
Build changes
-
* Linux: CI_DRM_14248 -> Patchwork_129456v4
CI-20190529: 20190529
CI_DRM_14248: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7708: c2ecf4ba307d3342682745de6f608d307a06782c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_129456v4: c7d234dd2d329f223f56699636248a609dbe2267 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
c02e0771fa2f drm/xe/hdcp: Add intel_hdcp_gsc_message to Makefile
d7d3ef697d6b drm/xe/hdcp: Enable HDCP for XE
bee167eca708 drm/xe: Use gsc_proxy_init_done to check proxy status
fb34e562f57c drm/xe/hdcp: Use xe_device struct
6d46d98765c7 drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header
file
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129456v4/index.html
[PATCH v2] drm/i915/selftests: Increasing the sleep time for live_rc6_manual
From: Anirban Sk
Sometimes gt_pm live_rc6_manual selftest fails due to no power being
measured for the rc6 disabled period. Therefore increasing the rc6 disable
period from 250ms to 1000ms to rule out such sporadic failure.
Signed-off-by: Anirban Sk
Reviewed-by: Anshuman Gupta
Change log:
v2: add Reviewed-by: Anshuman Gupta
More descriptive and improved commit message.
---
drivers/gpu/drm/i915/gt/selftest_rc6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index a7189c2d660c..1aa1446c8fb0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -62,12 +62,12 @@ int live_rc6_manual(void *arg)
dt = ktime_get();
rc0_power = librapl_energy_uJ();
- msleep(250);
+ msleep(1000);
rc0_power = librapl_energy_uJ() - rc0_power;
dt = ktime_sub(ktime_get(), dt);
res[1] = rc6_residency(rc6);
if ((res[1] - res[0]) >> 10) {
- pr_err("RC6 residency increased by %lldus while disabled for
250ms!\n",
+ pr_err("RC6 residency increased by %lldus while disabled for
1000ms!\n",
(res[1] - res[0]) >> 10);
err = -EINVAL;
goto out_unlock;
--
2.25.1
✗ Fi.CI.SPARSE: warning for XE HDCP Enablement (rev4)
== Series Details == Series: XE HDCP Enablement (rev4) URL : https://patchwork.freedesktop.org/series/129456/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old'
RE: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> -Original Message-
> From: Jani Nikula
> Sent: Friday, February 9, 2024 11:06 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika
> Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
>
> On Tue, 06 Feb 2024, Mika Kahola wrote:
> > Force full modeset for eDP when booting up. GOP programs PLL
> > parameters and hence, we would be able to use fastset for eDP.
> > However, with fastset we are not setting PLL values from the driver
> > and rely that GOP and driver PLL values match.
> > We have discovered that with some of the panels this is not true and
> > hence we would need to program PLL values by the driver. The patch
> > suggests a workaround as enabling full modeset when booting up. This
> > way we force the driver to write the PLL values to the hw.
>
> No. We want to avoid full modesets if possible, both in general and at probe.
>
> And when we do end up with modesets, the decision needs to be based on
> changes in the state that we can't write to the
> hardware without a modeset.
>
> We can't unconditionally force a modeset on eDP panels at probe.
Thanks! Just wondering what the options here might be? With fastest we end up
having a mismatch with one PLL value with a few panels.
Should we try identify the panels and setup some sort of quirks for these
problematic panels or what would be the best solution?
-Mika-
>
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index ab415f41924d..9699ded1eb5f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> > intel_encoder *encoder,
> > * of crtc_state->dsc, we have no way to ensure reliable fastset.
> > * Remove once we have readout for DSC.
> > */
> > +
> > if (crtc_state->dsc.compression_enable) {
> > drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset
> > due to DSC being enabled\n",
> > encoder->base.base.id, encoder->base.name); @@
> > -3326,6
> > +3327,18 @@ bool intel_dp_initial_fastset_check(struct intel_encoder
> > *encoder,
> > fastset = false;
> > }
> >
> > + /*
> > +* FIXME hack to force full modeset for eDP as not always BIOS written
> > PLL
> > +* values does not match with the ones defined in the driver code
> > +*/
> > + if (!crtc_state->uapi.mode_changed &&
> > + intel_dp_is_edp(intel_dp)) {
> > + drm_dbg_kms(>drm, "Forcing full modeset for eDP\n");
> > + crtc_state->uapi.mode_changed = true;
> > + fastset = false;
> > + }
> > +
> > +
> > return fastset;
> > }
>
> --
> Jani Nikula, Intel
Re: Re: [PATCH 00/10] drm: drm debug and error logging improvements
On Thu, 01 Feb 2024, Maxime Ripard wrote: > On Thu, Feb 01, 2024 at 02:51:13PM +0200, Jani Nikula wrote: >> On Tue, 16 Jan 2024, Jani Nikula wrote: >> > This is resend and more patches on top of [1]. I don't think I've >> > changed anything since then. >> >> Hi drm-misc maintainers - >> >> I've got R-b from Luca, but given there's no comments outside of Intel, >> are you okay with me merging this to drm-misc? > > Acked-by: Maxime Ripard Thanks for the reviews and acks, pushed to drm-misc-next. BR, Jani. -- Jani Nikula, Intel
2024 X.Org Foundation Membership deadline for voting in the election
The 2024 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 26 February 2024 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Christopher Michael, on behalf of the X.Org elections committee
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Michael,
On Tue, Feb 6, 2024 at 12:29 PM Michael Walle wrote:
>
> Hi Stephen and all,
>
> >> Today's linux-next merge of the drm-misc tree got a conflict in:
> >>
> >> drivers/gpu/drm/bridge/samsung-dsim.c
> >>
> >> between commit:
> >>
> >> ff3d5d04db07 ("drm: bridge: samsung-dsim: Don't use
> >> FORCE_STOP_STATE")
> >>
> >> from Linus' tree and commit:
> >>
> >> b2fe2292624a ("drm: bridge: samsung-dsim: enter display mode in the
> >> enable() callback")
> >>
> >> from the drm-misc tree.
> >>
> >> I fixed it up (see below, please check) and can carry the fix as
> >> necessary. This is now fixed as far as linux-next is concerned, but
> >> any
> >> non trivial conflicts should be mentioned to your upstream maintainer
> >> when your tree is submitted for merging. You may also want to
> >> consider
> >> cooperating with the maintainer of the conflicting tree to minimise
> >> any
> >> particularly complex conflicts.
> >
> > I changed my mind and just used the latter version of this file.
>
> Bug wise, this is the wrong solution. Because it will reintroduce the
> faulty FORCE_STOP_STATE. Also keep in mind, my fixes commit is/was
> already
> backported to the stable series.
>
> See also the discussion at [1]. Unfortunately, there was no conculusion
> yet.
> I think [2] is the proper resolution, at least for the commit
> b2fe2292624a
> ("drm: bridge: samsung-dsim: enter display mode in the enable()
> callback")
> I'm not sure in what state the drm-misc tree is.
>
> -michael
>
> [1]
> https://lore.kernel.org/dri-devel/CAPM=9tytMB9frxNeD08hu1qsusY=wee3bjofmuga1rspabw...@mail.gmail.com/
> [2]
> https://lore.kernel.org/dri-devel/31e1a38a1d012a32d6f7bc8372b63...@kernel.org/
Unfortunately, in this recent period, I have been very busy and have
not been able to run tests on this matter.
As soon as I am able to do so, I will.
Thanks and regards,
Dario
--
Dario Binacchi
Senior Embedded Linux Developer
dario.binac...@amarulasolutions.com
__
Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH] drm/i915/gt: Prevent possible NULL dereference in __caps_show()
Hello,
On 2/7/24 01:16, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 06/02/2024 16:45, Nikita Zhandarovich wrote:
>> After falling through the switch statement to default case 'repr' is
>> initialized with NULL, which will lead to incorrect dereference of
>> '!repr[n]' in the following loop.
>>
>> Fix it with the help of an additional check for NULL.
>>
>> Found by Linux Verification Center (linuxtesting.org) with static
>> analysis tool SVACE.
>>
>> Fixes: 4ec76dbeb62b ("drm/i915/gt: Expose engine properties via sysfs")
>> Signed-off-by: Nikita Zhandarovich
>> ---
>> P.S. The NULL-deref problem might be dealt with this way but I am
>> not certain that the rest of the __caps_show() behaviour remains
>> correct if we end up in default case. For instance, as far as I
>> can tell, buf might turn out to be w/o '\0'. I could use some
>> direction if this has to be addressed as well.
>>
>> drivers/gpu/drm/i915/gt/sysfs_engines.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c
>> b/drivers/gpu/drm/i915/gt/sysfs_engines.c
>> index 021f51d9b456..6b130b732867 100644
>> --- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
>> +++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
>> @@ -105,7 +105,7 @@ __caps_show(struct intel_engine_cs *engine,
>> len = 0;
>> for_each_set_bit(n, , show_unknown ? BITS_PER_LONG : count) {
>> - if (n >= count || !repr[n]) {
>> + if (n >= count || !repr || !repr[n]) {
>
> There are two input combinations to this function when repr is NULL.
>
> First is show_unknown=true and caps=0, which means the for_each_set_bit
> will not execute its body. (No bits set.)
>
> Second is show_unknown=false and caps=~0, which means count is zero so
> for_each_set_bit will again not run. (Bitfield size input param is zero.)
>
> So unless I am missing something I do not see the null pointer dereference.
>
> What could theoretically happen is that a third input combination
> appears, where caps is not zero in the show_unknown=true case, either
> via a fully un-handled engine->class (switch), or a new capability bit
> not added to the static array a bit above.
>
> That would assert during driver development here:
>
> if (GEM_WARN_ON(show_unknown))
>
> Granted that could be after the dereference in "if (n >= count ||
> !repr[n])", but would be caught in debug builds (CI) and therefore not
> be able to "ship" (get merge to the repo).
>
> Your second question is about empty buffer returned i.e. len=0 at the
> end of the function? (Which is when the buffer will not be null
> terminated - or you see another option?)
>
> That I think is safe too since it just results in a zero length read in
> sysfs.
>
> Regards,
>
> Tvrtko
>
>> if (GEM_WARN_ON(show_unknown))
>> len += sysfs_emit_at(buf, len, "[%x] ", n);
>> } else {
Thank you for such a full response.
I think you are right. I was under the impression that either currently
or in the future there might be an input combination, as you mentioned,
that may trigger the NULL dereference. If you feel it will be caught
beforehand, I am satisfied as well. Same goes for the empty buffer stuff.
I think dropping the patch is the best option then. Apologies for any
inconvenience.
Nikita
Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()
vhost and VIRTIO-related parts:
Reviewed-by: Stefan Hajnoczi
On Wed, 22 Nov 2023 at 07:50, Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional argument.
>
> Signed-off-by: Christian Brauner
> ---
> arch/x86/kvm/hyperv.c | 2 +-
> arch/x86/kvm/xen.c| 2 +-
> drivers/accel/habanalabs/common/device.c | 2 +-
> drivers/fpga/dfl.c| 2 +-
> drivers/gpu/drm/drm_syncobj.c | 6 +++---
> drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
> drivers/infiniband/hw/mlx5/devx.c | 2 +-
> drivers/misc/ocxl/file.c | 2 +-
> drivers/s390/cio/vfio_ccw_chp.c | 2 +-
> drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
> drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 2 +-
> drivers/usb/gadget/function/f_fs.c| 4 ++--
> drivers/vdpa/vdpa_user/vduse_dev.c| 6 +++---
> drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 2 +-
> drivers/vfio/pci/vfio_pci_core.c | 6 +++---
> drivers/vfio/pci/vfio_pci_intrs.c | 12 ++--
> drivers/vfio/platform/vfio_platform_irq.c | 4 ++--
> drivers/vhost/vdpa.c | 4 ++--
> drivers/vhost/vhost.c | 10 +-
> drivers/vhost/vhost.h | 2 +-
> drivers/virt/acrn/ioeventfd.c | 2 +-
> drivers/xen/privcmd.c | 2 +-
> fs/aio.c | 2 +-
> fs/eventfd.c | 9 +++--
> include/linux/eventfd.h | 4 ++--
> mm/memcontrol.c | 10 +-
> mm/vmpressure.c | 2 +-
> samples/vfio-mdev/mtty.c | 4 ++--
> virt/kvm/eventfd.c| 4 ++--
> 30 files changed, 60 insertions(+), 63 deletions(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 238afd7335e4..4943f6b2bbee 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2388,7 +2388,7 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu
> *vcpu, struct kvm_hv_hcall *h
> if (!eventfd)
> return HV_STATUS_INVALID_PORT_ID;
>
> - eventfd_signal(eventfd, 1);
> + eventfd_signal(eventfd);
> return HV_STATUS_SUCCESS;
> }
>
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index e53fad915a62..523bb6df5ac9 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -2088,7 +2088,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu
> *vcpu, u64 param, u64 *r)
> if (ret < 0 && ret != -ENOTCONN)
> return false;
> } else {
> - eventfd_signal(evtchnfd->deliver.eventfd.ctx, 1);
> + eventfd_signal(evtchnfd->deliver.eventfd.ctx);
> }
>
> *r = 0;
> diff --git a/drivers/accel/habanalabs/common/device.c
> b/drivers/accel/habanalabs/common/device.c
> index 9711e8fc979d..3a89644f087c 100644
> --- a/drivers/accel/habanalabs/common/device.c
> +++ b/drivers/accel/habanalabs/common/device.c
> @@ -2044,7 +2044,7 @@ static void hl_notifier_event_send(struct
> hl_notifier_event *notifier_event, u64
> notifier_event->events_mask |= event_mask;
>
> if (notifier_event->eventfd)
> - eventfd_signal(notifier_event->eventfd, 1);
> + eventfd_signal(notifier_event->eventfd);
>
> mutex_unlock(_event->lock);
> }
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index dd7a783d53b5..e73f88050f08 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -1872,7 +1872,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
> {
> struct eventfd_ctx *trigger = arg;
>
> - eventfd_signal(trigger, 1);
> + eventfd_signal(trigger);
> return IRQ_HANDLED;
> }
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 01da6789d044..b9cc62982196 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -1365,7 +1365,7 @@ static void syncobj_eventfd_entry_fence_func(struct
> dma_fence *fence,
> struct syncobj_eventfd_entry *entry =
> container_of(cb, struct syncobj_eventfd_entry, fence_cb);
>
> - eventfd_signal(entry->ev_fd_ctx, 1);
> + eventfd_signal(entry->ev_fd_ctx);
> syncobj_eventfd_entry_free(entry);
> }
>
> @@ -1388,13 +1388,13 @@ syncobj_eventfd_entry_func(struct drm_syncobj
> *syncobj,
> entry->fence = fence;
>
> if (entry->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE) {
> - eventfd_signal(entry->ev_fd_ctx, 1);
> + eventfd_signal(entry->ev_fd_ctx);
>
[PATCH] drm/i915/gt: Prevent possible NULL dereference in __caps_show()
After falling through the switch statement to default case 'repr' is
initialized with NULL, which will lead to incorrect dereference of
'!repr[n]' in the following loop.
Fix it with the help of an additional check for NULL.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 4ec76dbeb62b ("drm/i915/gt: Expose engine properties via sysfs")
Signed-off-by: Nikita Zhandarovich
---
P.S. The NULL-deref problem might be dealt with this way but I am
not certain that the rest of the __caps_show() behaviour remains
correct if we end up in default case. For instance, as far as I
can tell, buf might turn out to be w/o '\0'. I could use some
direction if this has to be addressed as well.
drivers/gpu/drm/i915/gt/sysfs_engines.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c
b/drivers/gpu/drm/i915/gt/sysfs_engines.c
index 021f51d9b456..6b130b732867 100644
--- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
@@ -105,7 +105,7 @@ __caps_show(struct intel_engine_cs *engine,
len = 0;
for_each_set_bit(n, , show_unknown ? BITS_PER_LONG : count) {
- if (n >= count || !repr[n]) {
+ if (n >= count || !repr || !repr[n]) {
if (GEM_WARN_ON(show_unknown))
len += sysfs_emit_at(buf, len, "[%x] ", n);
} else {
--
2.25.1
Re: linux-next: manual merge of the drm-misc tree with Linus' tree
Hi Stephen and all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/bridge/samsung-dsim.c
between commit:
ff3d5d04db07 ("drm: bridge: samsung-dsim: Don't use
FORCE_STOP_STATE")
from Linus' tree and commit:
b2fe2292624a ("drm: bridge: samsung-dsim: enter display mode in the
enable() callback")
from the drm-misc tree.
I fixed it up (see below, please check) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but
any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to
consider
cooperating with the maintainer of the conflicting tree to minimise
any
particularly complex conflicts.
I changed my mind and just used the latter version of this file.
Bug wise, this is the wrong solution. Because it will reintroduce the
faulty FORCE_STOP_STATE. Also keep in mind, my fixes commit is/was
already
backported to the stable series.
See also the discussion at [1]. Unfortunately, there was no conculusion
yet.
I think [2] is the proper resolution, at least for the commit
b2fe2292624a
("drm: bridge: samsung-dsim: enter display mode in the enable()
callback")
I'm not sure in what state the drm-misc tree is.
-michael
[1]
https://lore.kernel.org/dri-devel/CAPM=9tytMB9frxNeD08hu1qsusY=wee3bjofmuga1rspabw...@mail.gmail.com/
[2]
https://lore.kernel.org/dri-devel/31e1a38a1d012a32d6f7bc8372b63...@kernel.org/
[PATCH] drm/i915: Add flex arrays to struct i915_syncmap
The "struct i915_syncmap" uses a dynamically sized set of trailing
elements. It can use an "u32" array or a "struct i915_syncmap *"
array.
So, use the preferred way in the kernel declaring flexible arrays [1].
Because there are two possibilities for the trailing arrays, it is
necessary to declare a union and use the DECLARE_FLEX_ARRAY macro.
The comment can be removed as the union is now clear enough.
Also, avoid the open-coded arithmetic in the memory allocator functions
[2] using the "struct_size" macro.
Moreover, refactor the "__sync_seqno" and "__sync_child" functions due
to now it is possible to use the union members added to the structure.
This way, it is also possible to avoid the open-coded arithmetic in
pointers.
Link:
https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and-one-element-arrays
[1]
Link:
https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
[2]
Signed-off-by: Erick Archer
---
drivers/gpu/drm/i915/i915_syncmap.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_syncmap.c
b/drivers/gpu/drm/i915/i915_syncmap.c
index 60404dbb2e9f..df6437c37373 100644
--- a/drivers/gpu/drm/i915/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/i915_syncmap.c
@@ -75,13 +75,10 @@ struct i915_syncmap {
unsigned int height;
unsigned int bitmap;
struct i915_syncmap *parent;
- /*
-* Following this header is an array of either seqno or child pointers:
-* union {
-* u32 seqno[KSYNCMAP];
-* struct i915_syncmap *child[KSYNCMAP];
-* };
-*/
+ union {
+ DECLARE_FLEX_ARRAY(u32, seqno);
+ DECLARE_FLEX_ARRAY(struct i915_syncmap *, child);
+ };
};
/**
@@ -99,13 +96,13 @@ void i915_syncmap_init(struct i915_syncmap **root)
static inline u32 *__sync_seqno(struct i915_syncmap *p)
{
GEM_BUG_ON(p->height);
- return (u32 *)(p + 1);
+ return p->seqno;
}
static inline struct i915_syncmap **__sync_child(struct i915_syncmap *p)
{
GEM_BUG_ON(!p->height);
- return (struct i915_syncmap **)(p + 1);
+ return p->child;
}
static inline unsigned int
@@ -200,7 +197,7 @@ __sync_alloc_leaf(struct i915_syncmap *parent, u64 id)
{
struct i915_syncmap *p;
- p = kmalloc(sizeof(*p) + KSYNCMAP * sizeof(u32), GFP_KERNEL);
+ p = kmalloc(struct_size(p, seqno, KSYNCMAP), GFP_KERNEL);
if (unlikely(!p))
return NULL;
@@ -282,7 +279,7 @@ static noinline int __sync_set(struct i915_syncmap **root,
u64 id, u32 seqno)
unsigned int above;
/* Insert a join above the current layer */
- next = kzalloc(sizeof(*next) + KSYNCMAP * sizeof(next),
+ next = kzalloc(struct_size(next, child, KSYNCMAP),
GFP_KERNEL);
if (unlikely(!next))
return -ENOMEM;
--
2.25.1
[PATCH 4/5] drm/xe/hdcp: Enable HDCP for XE
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
--v2
-add kfree at appropriate place [Daniele]
-remove useless define [Daniele]
-move host session logic to xe_gsc_submit.c [Daniele]
-call xe_gsc_check_and_update_pending directly in an if condition
[Daniele]
-use xe_device instead of drm_i915_private [Daniele]
--v3
-use xe prefix for newly exposed function [Daniele]
-remove client specific defines from intel_gsc_mtl_header [Daniele]
-add missing kfree() [Daniele]
-have NULL check for hdcp_message in finish function [Daniele]
-dont have too many variable declarations in the same line [Daniele]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 180 ++-
drivers/gpu/drm/xe/xe_gsc_submit.c | 15 ++
drivers/gpu/drm/xe/xe_gsc_submit.h | 1 +
3 files changed, 193 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 425db3532ce5..aa8c13916bb6 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -4,12 +4,27 @@
*/
#include
+#include
+#include "abi/gsc_command_header_abi.h"
#include "intel_hdcp_gsc.h"
#include "xe_device_types.h"
#include "xe_gt.h"
#include "xe_gsc_proxy.h"
#include "xe_pm.h"
+#include "xe_bo.h"
+#include "xe_map.h"
+#include "xe_gsc_submit.h"
+
+#define HECI_MEADDRESS_HDCP 18
+
+struct intel_hdcp_gsc_message {
+ struct xe_bo *hdcp_bo;
+ u64 hdcp_cmd_in;
+ u64 hdcp_cmd_out;
+};
+
+#define HDCP_GSC_HEADER_SIZE sizeof(struct intel_gsc_mtl_header)
bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
@@ -40,19 +55,178 @@ bool intel_hdcp_gsc_check_status(struct xe_device *xe)
return ret;
}
+/*This function helps allocate memory for the command that we will send to gsc
cs */
+static int intel_hdcp_gsc_initialize_message(struct xe_device *xe,
+struct intel_hdcp_gsc_message
*hdcp_message)
+{
+ struct xe_bo *bo = NULL;
+ u64 cmd_in, cmd_out;
+ int ret = 0;
+
+ /* allocate object of two page for HDCP command memory and store it */
+ xe_device_mem_access_get(xe);
+ bo = xe_bo_create_pin_map(xe, xe_device_get_root_tile(xe), NULL,
PAGE_SIZE * 2,
+ ttm_bo_type_kernel,
+ XE_BO_CREATE_SYSTEM_BIT |
+ XE_BO_CREATE_GGTT_BIT);
+
+ if (IS_ERR(bo)) {
+ drm_err(>drm, "Failed to allocate bo for HDCP streaming
command!\n");
+ ret = PTR_ERR(bo);
+ goto out;
+ }
+
+ cmd_in = xe_bo_ggtt_addr(bo);
+ cmd_out = cmd_in + PAGE_SIZE;
+ xe_map_memset(xe, >vmap, 0, 0, bo->size);
+
+ hdcp_message->hdcp_bo = bo;
+ hdcp_message->hdcp_cmd_in = cmd_in;
+ hdcp_message->hdcp_cmd_out = cmd_out;
+out:
+ xe_device_mem_access_put(xe);
+ return ret;
+}
+
+static int intel_hdcp_gsc_hdcp2_init(struct xe_device *xe)
+{
+ struct intel_hdcp_gsc_message *hdcp_message;
+ int ret;
+
+ hdcp_message = kzalloc(sizeof(*hdcp_message), GFP_KERNEL);
+
+ if (!hdcp_message)
+ return -ENOMEM;
+
+ /*
+* NOTE: No need to lock the comp mutex here as it is already
+* going to be taken before this function called
+*/
+ ret = intel_hdcp_gsc_initialize_message(xe, hdcp_message);
+ xe->display.hdcp.hdcp_message = hdcp_message;
+
+ if (ret) {
+ drm_err(>drm, "Could not initialize hdcp_message\n");
+ kfree(hdcp_message);
+ }
+
+ return ret;
+}
+
int intel_hdcp_gsc_init(struct xe_device *xe)
{
- drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
- return -ENODEV;
+ struct i915_hdcp_arbiter *data;
+ int ret;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ mutex_lock(>display.hdcp.hdcp_mutex);
+ xe->display.hdcp.arbiter = data;
+ xe->display.hdcp.arbiter->hdcp_dev = xe->drm.dev;
+ xe->display.hdcp.arbiter->ops = _hdcp_ops;
+ ret = intel_hdcp_gsc_hdcp2_init(xe);
+ if (ret)
+ kfree(data);
+
+ mutex_unlock(>display.hdcp.hdcp_mutex);
+
+ return ret;
}
void intel_hdcp_gsc_fini(struct xe_device *xe)
{
+ struct intel_hdcp_gsc_message *hdcp_message =
+ xe->display.hdcp.hdcp_message;
+
+ if (!hdcp_message)
+ return;
+
+ xe_bo_unpin_map_no_vm(hdcp_message->hdcp_bo);
+ kfree(hdcp_message);
+}
+
+static int xe_gsc_send_sync(struct xe_device *xe,
+ struct intel_hdcp_gsc_message *hdcp_message,
+ u32 msg_size_in, u32 msg_size_out,
+ u32 addr_out_off)
+{
+ struct
[PATCH 5/5] drm/xe/hdcp: Add intel_hdcp_gsc_message to Makefile
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index c531210695db..2b654c908ff3 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -254,6 +254,7 @@ xe-$(CONFIG_DRM_XE_DISPLAY) += \
i915-display/intel_global_state.o \
i915-display/intel_gmbus.o \
i915-display/intel_hdcp.o \
+ i915-display/intel_hdcp_gsc_message.o \
i915-display/intel_hdmi.o \
i915-display/intel_hotplug.o \
i915-display/intel_hotplug_irq.o \
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index aa8c13916bb6..f185465d5682 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -5,9 +5,11 @@
#include
#include
+#include
#include "abi/gsc_command_header_abi.h"
#include "intel_hdcp_gsc.h"
+#include "intel_hdcp_gsc_message.h"
#include "xe_device_types.h"
#include "xe_gt.h"
#include "xe_gsc_proxy.h"
@@ -113,6 +115,22 @@ static int intel_hdcp_gsc_hdcp2_init(struct xe_device *xe)
return ret;
}
+static const struct i915_hdcp_ops gsc_hdcp_ops = {
+ .initiate_hdcp2_session = intel_hdcp_gsc_initiate_session,
+ .verify_receiver_cert_prepare_km =
+ intel_hdcp_gsc_verify_receiver_cert_prepare_km,
+ .verify_hprime = intel_hdcp_gsc_verify_hprime,
+ .store_pairing_info = intel_hdcp_gsc_store_pairing_info,
+ .initiate_locality_check = intel_hdcp_gsc_initiate_locality_check,
+ .verify_lprime = intel_hdcp_gsc_verify_lprime,
+ .get_session_key = intel_hdcp_gsc_get_session_key,
+ .repeater_check_flow_prepare_ack =
+ intel_hdcp_gsc_repeater_check_flow_prepare_ack,
+ .verify_mprime = intel_hdcp_gsc_verify_mprime,
+ .enable_hdcp_authentication = intel_hdcp_gsc_enable_authentication,
+ .close_hdcp_session = intel_hdcp_gsc_close_session,
+};
+
int intel_hdcp_gsc_init(struct xe_device *xe)
{
struct i915_hdcp_arbiter *data;
--
2.25.1
[PATCH 1/5] drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file
Move intel_hdcp_gsc_message definition into intel_hdcp_gsc_message.c
so that intel_hdcp_gsc_message can be redefined for xe as needed.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 6 ++
drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 7 +--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index 18117b789b16..e44f60f00e8b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -13,6 +13,12 @@
#include "intel_hdcp_gsc.h"
#include "intel_hdcp_gsc_message.h"
+struct intel_hdcp_gsc_message {
+ struct i915_vma *vma;
+ void *hdcp_cmd_in;
+ void *hdcp_cmd_out;
+};
+
bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 14;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
index eba2057c5a9e..5f610df61cc9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
@@ -10,12 +10,7 @@
#include
struct drm_i915_private;
-
-struct intel_hdcp_gsc_message {
- struct i915_vma *vma;
- void *hdcp_cmd_in;
- void *hdcp_cmd_out;
-};
+struct intel_hdcp_gsc_message;
bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915);
ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
--
2.25.1
[PATCH 3/5] drm/xe: Use gsc_proxy_init_done to check proxy status
Expose gsc_proxy_init_done so that we can check if gsc proxy has
been initialized or not.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 25 +++-
drivers/gpu/drm/xe/xe_gsc_proxy.c| 4 ++--
drivers/gpu/drm/xe/xe_gsc_proxy.h| 1 +
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 5d1d0054b578..425db3532ce5 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -4,8 +4,12 @@
*/
#include
+
#include "intel_hdcp_gsc.h"
#include "xe_device_types.h"
+#include "xe_gt.h"
+#include "xe_gsc_proxy.h"
+#include "xe_pm.h"
bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
@@ -14,7 +18,26 @@ bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
bool intel_hdcp_gsc_check_status(struct xe_device *xe)
{
- return false;
+ struct xe_tile *tile = xe_device_get_root_tile(xe);
+ struct xe_gt *gt = tile->media_gt;
+ bool ret = true;
+
+ xe_pm_runtime_get(xe);
+ ret = xe_force_wake_get(gt_to_fw(gt), XE_FW_GSC);
+ if (ret) {
+ drm_dbg_kms(>drm,
+ "failed to get forcewake to check proxy status\n");
+ ret = false;
+ goto out;
+ }
+
+ if (!xe_gsc_proxy_init_done(>uc.gsc))
+ ret = false;
+
+ xe_force_wake_put(gt_to_fw(gt), XE_FW_GSC);
+out:
+ xe_pm_runtime_put(xe);
+ return ret;
}
int intel_hdcp_gsc_init(struct xe_device *xe)
diff --git a/drivers/gpu/drm/xe/xe_gsc_proxy.c
b/drivers/gpu/drm/xe/xe_gsc_proxy.c
index 309ef80e3b95..1ced6b4d4946 100644
--- a/drivers/gpu/drm/xe/xe_gsc_proxy.c
+++ b/drivers/gpu/drm/xe/xe_gsc_proxy.c
@@ -66,7 +66,7 @@ static inline struct xe_device *kdev_to_xe(struct device
*kdev)
return dev_get_drvdata(kdev);
}
-static bool gsc_proxy_init_done(struct xe_gsc *gsc)
+bool xe_gsc_proxy_init_done(struct xe_gsc *gsc)
{
struct xe_gt *gt = gsc_to_gt(gsc);
u32 fwsts1 = xe_mmio_read32(gt, HECI_FWSTS1(MTL_GSC_HECI1_BASE));
@@ -528,7 +528,7 @@ int xe_gsc_proxy_start(struct xe_gsc *gsc)
if (err)
return err;
- if (!gsc_proxy_init_done(gsc)) {
+ if (!xe_gsc_proxy_init_done(gsc)) {
xe_gt_err(gsc_to_gt(gsc), "GSC FW reports proxy init not
completed\n");
return -EIO;
}
diff --git a/drivers/gpu/drm/xe/xe_gsc_proxy.h
b/drivers/gpu/drm/xe/xe_gsc_proxy.h
index 908f9441f093..c511ade6b863 100644
--- a/drivers/gpu/drm/xe/xe_gsc_proxy.h
+++ b/drivers/gpu/drm/xe/xe_gsc_proxy.h
@@ -11,6 +11,7 @@
struct xe_gsc;
int xe_gsc_proxy_init(struct xe_gsc *gsc);
+bool xe_gsc_proxy_init_done(struct xe_gsc *gsc);
void xe_gsc_proxy_remove(struct xe_gsc *gsc);
int xe_gsc_proxy_start(struct xe_gsc *gsc);
--
2.25.1
[PATCH 0/5] XE HDCP Enablement
This patch series enables HDCP on XE. Mainly includes rewriting functions that were responsible for sending hdcp messages via gsc cs. Signed-off-by: Suraj Kandpal Suraj Kandpal (5): drm/i915/hdcp: Move intel_hdcp_gsc_message def away from header file drm/xe/hdcp: Use xe_device struct drm/xe: Use gsc_proxy_init_done to check proxy status drm/xe/hdcp: Enable HDCP for XE drm/xe/hdcp: Add intel_hdcp_gsc_message to Makefile drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 6 + drivers/gpu/drm/i915/display/intel_hdcp_gsc.h | 7 +- drivers/gpu/drm/xe/Makefile | 1 + drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 236 +- drivers/gpu/drm/xe/xe_gsc_proxy.c | 4 +- drivers/gpu/drm/xe/xe_gsc_proxy.h | 1 + drivers/gpu/drm/xe/xe_gsc_submit.c| 15 ++ drivers/gpu/drm/xe/xe_gsc_submit.h| 1 + 8 files changed, 253 insertions(+), 18 deletions(-) -- 2.25.1
[PATCH 2/5] drm/xe/hdcp: Use xe_device struct
Use xe_device struct instead of drm_i915_private so as to not
cause confusion and comply with Xe standards even though xe_device
gets translated to drm_i915_private.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
index 0f11a39333e2..5d1d0054b578 100644
--- a/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
+++ b/drivers/gpu/drm/xe/display/xe_hdcp_gsc.c
@@ -3,30 +3,31 @@
* Copyright 2023, Intel Corporation.
*/
-#include "i915_drv.h"
+#include
#include "intel_hdcp_gsc.h"
+#include "xe_device_types.h"
-bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
+bool intel_hdcp_gsc_cs_required(struct xe_device *xe)
{
return true;
}
-bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915)
+bool intel_hdcp_gsc_check_status(struct xe_device *xe)
{
return false;
}
-int intel_hdcp_gsc_init(struct drm_i915_private *i915)
+int intel_hdcp_gsc_init(struct xe_device *xe)
{
- drm_info(>drm, "HDCP support not yet implemented\n");
+ drm_dbg_kms(>drm, "HDCP support not yet implemented\n");
return -ENODEV;
}
-void intel_hdcp_gsc_fini(struct drm_i915_private *i915)
+void intel_hdcp_gsc_fini(struct xe_device *xe)
{
}
-ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
+ssize_t intel_hdcp_gsc_msg_send(struct xe_device *xe, u8 *msg_in,
size_t msg_in_len, u8 *msg_out,
size_t msg_out_len)
{
--
2.25.1
Re: [PATCH 05/11] drm/i915/hdcp: Add new remote capability check shim function
On Sun, 04 Feb 2024, Suraj Kandpal wrote:
> Create a remote HDCP capability shim function which can read the
> remote monitor HDCP capability when in MST configuration.
>
> --v2
> -Add an assertion to make sure only mst encoder call this remote_cap
> function [Ankit]
>
> Signed-off-by: Suraj Kandpal
> ---
> .../drm/i915/display/intel_display_types.h| 4 +++
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 26 +++
> drivers/gpu/drm/i915/display/intel_hdcp.c | 16
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 +++
> 4 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index ae2e8cff9d69..7e7a370a3b30 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -532,6 +532,10 @@ struct intel_hdcp_shim {
> /* HDCP2.2 Link Integrity Check */
> int (*check_2_2_link)(struct intel_digital_port *dig_port,
> struct intel_connector *connector);
> +
> + /* HDCP remote sink cap */
> + int (*remote_hdcp_cap)(struct intel_connector *connector,
> +bool *hdcp_capable, bool *hdcp2_capable);
> };
>
> struct intel_hdcp {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index ef1a4c90c225..ccd274200f92 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -668,6 +668,31 @@ int intel_dp_hdcp2_capable(struct intel_connector
> *connector,
> return _intel_dp_hdcp2_capable(aux, capable);
> }
>
> +static
> +int intel_dp_hdcp_remote_cap(struct intel_connector *connector,
> + bool *hdcp_capable, bool *hdcp2_capable)
> +{
> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
> + struct drm_dp_aux *aux = >port->aux;
> + u8 bcaps;
> + int ret;
> +
> + if (!intel_encoder_is_mst(connector->encoder))
> + return -EINVAL;
> +
> + ret = _intel_dp_hdcp2_capable(aux, hdcp2_capable);
> + if (ret)
> + return ret;
> +
> + ret = intel_dp_hdcp_read_bcaps(aux, i915, );
> + if (ret)
> + return ret;
> +
> + *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
> +
> + return 0;
> +}
> +
> static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> .read_bksv = intel_dp_hdcp_read_bksv,
> @@ -685,6 +710,7 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> .config_stream_type = intel_dp_hdcp2_config_stream_type,
> .check_2_2_link = intel_dp_hdcp2_check_link,
> .hdcp_2_2_capable = intel_dp_hdcp2_capable,
> + .remote_hdcp_cap = intel_dp_hdcp_remote_cap,
Please either call these _cap or _capable, don't mix.
Arguably a function called "capable" sounds like a predicate function
that should return the value. In code,
if (capable(foo))
is misleading if that's checking the status of the capability read, not
the actual capability.
So maybe these should be called "get capability" or something.
BR,
Jani.
> .protocol = HDCP_PROTOCOL_DP,
> };
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 4593ac10e2fa..2b739249b60c 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -205,6 +205,22 @@ bool intel_hdcp2_capable(struct intel_connector
> *connector)
> return capable;
> }
>
> +void intel_hdcp_remote_cap(struct intel_connector *connector,
> +bool *hdcp_capable,
> +bool *hdcp2_capable)
> +{
> + struct intel_hdcp *hdcp = >hdcp;
> +
> + /* Remote Sink's capability for HDCP */
> + if (!hdcp->shim->remote_hdcp_cap)
> + return;
> +
> + hdcp->shim->remote_hdcp_cap(connector, hdcp_capable, hdcp2_capable);
> +
> + if (intel_hdcp2_prerequisite(connector))
> + *hdcp2_capable = false;
> +}
> +
> static bool intel_hdcp_in_use(struct drm_i915_private *i915,
> enum transcoder cpu_transcoder, enum port port)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index a9c784fd9ba5..213d286ca3fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -40,6 +40,9 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
> *state,
> bool is_hdcp_supported(struct drm_i915_private *i915, enum port port);
> bool intel_hdcp_capable(struct intel_connector *connector);
> bool intel_hdcp2_capable(struct intel_connector *connector);
> +void intel_hdcp_remote_cap(struct intel_connector *connector,
> +bool *hdcp_capable,
> +bool
Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
On Tue, 06 Feb 2024, Mika Kahola wrote:
> Force full modeset for eDP when booting up. GOP programs
> PLL parameters and hence, we would be able to use fastset
> for eDP. However, with fastset we are not setting PLL values
> from the driver and rely that GOP and driver PLL values match.
> We have discovered that with some of the panels this is not
> true and hence we would need to program PLL values by the
> driver. The patch suggests a workaround as enabling full
> modeset when booting up. This way we force the driver to
> write the PLL values to the hw.
No. We want to avoid full modesets if possible, both in general and at
probe.
And when we do end up with modesets, the decision needs to be based on
changes in the state that we can't write to the hardware without a
modeset.
We can't unconditionally force a modeset on eDP panels at probe.
BR,
Jani.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ab415f41924d..9699ded1eb5f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct
> intel_encoder *encoder,
>* of crtc_state->dsc, we have no way to ensure reliable fastset.
>* Remove once we have readout for DSC.
>*/
> +
> if (crtc_state->dsc.compression_enable) {
> drm_dbg_kms(>drm, "[ENCODER:%d:%s] Forcing full modeset
> due to DSC being enabled\n",
> encoder->base.base.id, encoder->base.name);
> @@ -3326,6 +3327,18 @@ bool intel_dp_initial_fastset_check(struct
> intel_encoder *encoder,
> fastset = false;
> }
>
> + /*
> + * FIXME hack to force full modeset for eDP as not always BIOS written
> PLL
> + * values does not match with the ones defined in the driver code
> + */
> + if (!crtc_state->uapi.mode_changed &&
> + intel_dp_is_edp(intel_dp)) {
> + drm_dbg_kms(>drm, "Forcing full modeset for eDP\n");
> + crtc_state->uapi.mode_changed = true;
> + fastset = false;
> + }
> +
> +
> return fastset;
> }
--
Jani Nikula, Intel
Re: [PATCH v2] drm/i915: Add GuC submission interface version query
On 08/02/2024 17:55, Souza, Jose wrote:
On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
On 08/02/2024 14:30, Souza, Jose wrote:
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute command streamers
simultaneously can cause GPU hangs due issues in firmware scheduling.
Based on patches from Vivaik and Joonas.
Compile tested only.
v2:
* Added branch version.
Reviewed-by: José Roberto de Souza
Tested-by: José Roberto de Souza
UMD: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25233
Thanks, but please we also need to close down on the branch number
situation. I.e. be sure what is the failure mode in shipping Mesa with
the change as it stands in the MR linked. What platforms could start
failing and when, depending on GuC FW release eventualities.
yes, I have asked John Harrison for a documentation link about the firmware
versioning.
Got the documentation link, MR updated.
Will ask for reviews in Mesa side.
Is it then understood and accepted that should GuC ever update the
branch number on any given platform, that platform, for all deployed
Mesa's in the field, will automatically revert to no async queues and so
cause a silent performance regression?
Regards,
Tvrtko
Regards,
Tvrtko
Signed-off-by: Tvrtko Ursulin
Cc: Kenneth Graunke
Cc: Jose Souza
Cc: Sagar Ghuge
Cc: Paulo Zanoni
Cc: John Harrison
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Tvrtko Ursulin
Cc: Vivaik Balasubrawmanian
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_query.c | 33 +++
include/uapi/drm/i915_drm.h | 12 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 00871ef99792..d4dba1240b40 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -551,6 +551,38 @@ static int query_hwconfig_blob(struct drm_i915_private
*i915,
return hwconfig->size;
}
+static int
+query_guc_submission_version(struct drm_i915_private *i915,
+struct drm_i915_query_item *query)
+{
+ struct drm_i915_query_guc_submission_version __user *query_ptr =
+ u64_to_user_ptr(query->data_ptr);
+ struct drm_i915_query_guc_submission_version ver;
+ struct intel_guc *guc = _gt(i915)->uc.guc;
+ const size_t size = sizeof(ver);
+ int ret;
+
+ if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+ return -ENODEV;
+
+ ret = copy_query_item(, size, size, query);
+ if (ret != 0)
+ return ret;
+
+ if (ver.branch || ver.major || ver.minor || ver.patch)
+ return -EINVAL;
+
+ ver.branch = 0;
+ ver.major = guc->submission_version.major;
+ ver.minor = guc->submission_version.minor;
+ ver.patch = guc->submission_version.patch;
+
+ if (copy_to_user(query_ptr, , size))
+ return -EFAULT;
+
+ return 0;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
@@ -559,6 +591,7 @@ static int (* const i915_query_funcs[])(struct
drm_i915_private *dev_priv,
query_memregion_info,
query_hwconfig_blob,
query_geometry_subslices,
+ query_guc_submission_version,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 550c496ce76d..84fb7f7ea834 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3038,6 +3038,7 @@ struct drm_i915_query_item {
* - %DRM_I915_QUERY_MEMORY_REGIONS (see struct
drm_i915_query_memory_regions)
* - %DRM_I915_QUERY_HWCONFIG_BLOB (see `GuC HWCONFIG blob uAPI`)
* - %DRM_I915_QUERY_GEOMETRY_SUBSLICES (see struct
drm_i915_query_topology_info)
+* - %DRM_I915_QUERY_GUC_SUBMISSION_VERSION (see struct
drm_i915_query_guc_submission_version)
*/
__u64 query_id;
#define DRM_I915_QUERY_TOPOLOGY_INFO 1
@@ -3046,6 +3047,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_MEMORY_REGIONS4
#define DRM_I915_QUERY_HWCONFIG_BLOB 5
#define DRM_I915_QUERY_GEOMETRY_SUBSLICES6
+#define DRM_I915_QUERY_GUC_SUBMISSION_VERSION 7
/* Must be kept compact -- no holes and well documented */
/**
@@ -3591,6 +3593,16 @@ struct drm_i915_query_memory_regions {
struct drm_i915_memory_region_info regions[];
};
+/**
+* struct drm_i915_query_guc_submission_version -
Re: Re: [PATCH v3 2/3] bits: Introduce fixed-type BIT
On Thu, 08 Feb 2024, Lucas De Marchi wrote: > On Thu, Feb 08, 2024 at 09:04:45PM +0100, Andi Shyti wrote: >>Hi Lucas, >> >>looks good, just one idea... >> >>... >> >>> +#define BIT_U8(b) ((u8)(BIT_INPUT_CHECK(u8, b) + BIT(b))) >>> +#define BIT_U16(b) ((u16)(BIT_INPUT_CHECK(u16, b) + BIT(b))) >>> +#define BIT_U32(b) ((u32)(BIT_INPUT_CHECK(u32, b) + BIT(b))) >>> +#define BIT_U64(b) ((u64)(BIT_INPUT_CHECK(u64, b) + BIT(b))) >> >>considering that BIT defines are always referred to unsigned >>types, I would just call them >> >>#define BIT8 >>#define BIT16 >>#define BIT32 >>#define BIT64 >> >>what do you think? > > it will clash with defines from other headers and not match the ones for > GENMASK so I prefer it the other way. Agreed. -- Jani Nikula, Intel
