* ✗ Fi.CI.BUILD: failure for drm/i915/psr: Skip PSR exit for legacy cursor updates on LunarLake onwards
From: Patchwork @ 2026-06-25 6:21 UTC (permalink / raw)
To: Aaron Ma; +Cc: intel-gfx
In-Reply-To: <20260625055514.3636380-1-aaron.ma@canonical.com>
== Series Details ==
Series: drm/i915/psr: Skip PSR exit for legacy cursor updates on LunarLake onwards
URL : https://patchwork.freedesktop.org/series/169131/
State : failure
== Summary ==
Error: patch https://patchwork.freedesktop.org/api/1.0/series/169131/revisions/1/mbox/ not applied
Applying: drm/i915/psr: Skip PSR exit for legacy cursor updates on LunarLake onwards
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/display/intel_psr.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_psr.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_psr.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/psr: Skip PSR exit for legacy cursor updates on LunarLake onwards
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced
^ permalink raw reply
* [PULL] drm-intel-next-fixes
From: Joonas Lahtinen @ 2026-06-25 6:19 UTC (permalink / raw)
To: Dave Airlie, Simona Vetter
Cc: Jani Nikula, Joonas Lahtinen, Tvrtko Ursulin, Rodrigo Vivi,
Thomas Zimmermann, Maarten Lankhorst, Maxime Ripard,
Matthew Brost, Thomas Hellström, Oded Gabbay, dri-devel,
intel-gfx, intel-xe, dim-tools
Hi Dave & Sima,
Here goes drm-intel-next-fixes PR towards 7.2-rc1.
Just one display corruption fix for GLK and one Spectre
mitigation for parallel submit IOCTL.
Regards, Joonas
***
drm-intel-next-fixes-2026-06-25-1:
- Fix corrupted display output on GLK, #16209 (Ville)
- Add missing Spectre mitigation for parallel submit IOCTL (Joonas)
The following changes since commit 062499cc4813b5a3cbed5dd4fbe0177265858450:
drm/i915/mtl+: Enable PPS before PLL (2026-06-16 13:06:09 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/i915/kernel.git tags/drm-intel-next-fixes-2026-06-25-1
for you to fetch changes up to 2ee8dbd880b14fb0b5115bf2353c7900aa33b95b:
drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable (2026-06-24 13:53:32 +0300)
----------------------------------------------------------------
- Fix corrupted display output on GLK, #16209 (Ville)
- Add missing Spectre mitigation for parallel submit IOCTL (Joonas)
----------------------------------------------------------------
Joonas Lahtinen (1):
drm/i915/gem: Add missing nospec on parallel submit slot
Ville Syrjälä (1):
drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable
drivers/gpu/drm/i915/display/intel_cdclk.c | 41 ++++++++++++++++++++++++-----
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
2 files changed, 35 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH] drm/i915: Return NULL on error in active_instance
From: Joonas Lahtinen @ 2026-06-25 6:03 UTC (permalink / raw)
To: Andi Shyti
Cc: Intel graphics driver community testing & development,
Martin Hodo, Maarten Lankhorst, Thomas Hellström,
Simona Vetter, stable
In-Reply-To: <ajvTjodx7LLj_BPO@zenone.zhora.eu>
Quoting Andi Shyti (2026-06-24 15:59:30)
> Hi Joonas,
>
> On Wed, Jun 24, 2026 at 02:25:19PM +0300, Joonas Lahtinen wrote:
> > Pushed to drm-intel-gt-next, thanks for the reviews.
>
> please, next time:
>
> - Give people more time to review the patch. Only two hours
> passed between posting it and pushing it
And why exactly is that a problem? I got the review from the original
patch author and a yet another person on top while it's a very
uncontroversial and trivial patch. Two reviewers per patch is already
quite a high bar to clear if you look at git history.
> (during lunch time, BTW).
Sorry, I did not know there is a universally agreed 2 hour lunch window
in UTC timezone that I should follow. I've missed that memo.
> - There were BAT failures. They were unrelated, but so far we
> have generally held back patches until BAT was green, even for
> the most obvious changes.
Strong disagree here. That'd have caused the patch to miss -next-fixes
PR just due to random noise of CI.
If there was a reasonable doubt about the impact of the patch on the
failure, that'd of course be different, but here there was absolutely
none in this case.
As per patchwork automated mail reply:
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_169089v1, please notify your bug team
That's exactly what was done here. That's a fair ask, but asking for
maintainers not to merge any code because of false positives is simply
not.
Regards, Joonas
>
> Thanks,
> Andi
^ permalink raw reply
* [PATCH v2] drm/i915/psr: Skip PSR exit for legacy cursor updates on LunarLake onwards
From: Aaron Ma @ 2026-06-25 5:55 UTC (permalink / raw)
To: Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
David Airlie, Simona Vetter, intel-gfx, intel-xe, dri-devel,
linux-kernel
Cc: Gwan-gyeong Mun, José Roberto de Souza,
Ville Syrjälä
ORIGIN_CURSOR_UPDATE falls through to _psr_flush_handle() on
DISPLAY_VER >= 20, which calls intel_psr_exit(). Cursor plane updated
via legacy ioctl (drmModeMoveCursor) does not dirty the primary
frontbuffer, no PSR2 state change is needed. Match the existing
ORIGIN_FLIP behavior by returning early on DISPLAY_VER >= 20.
Before this, the psr2_sel_fetch_enabled guard only prevented the early
return when PSR2 selective fetch was active, sending cursor updates
through intel_psr_exit() and causing a black line artifact on some
panels during the exit/re-enable transition.
Preserve the fallthrough for pre-LNL platforms with PSR2 selective
fetch, where intel_psr_force_update() (CURSURFLIVE write) is needed
for cursor tracking.
Fixes: ef39826c12b4 ("drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled")
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
Changes in v2:
- Add DISPLAY_VER >= 20 guard to only skip PSR exit on LunarLake onwards,
preserving the intel_psr_force_update() fallthrough for pre-LNL platforms
with PSR2 selective fetch (addresses Sashiko review about cursor trailing
artifacts on pre-LNL)
v1: https://lore.kernel.org/r/20260623084137.3421894-1-aaron.ma@canonical.com
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
index e138982dc91f6..ba8c427f45463 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -3772,7 +3772,7 @@ void intel_psr_flush(struct intel_display *display,
if (origin == ORIGIN_FLIP ||
(origin == ORIGIN_CURSOR_UPDATE &&
- !intel_dp->psr.psr2_sel_fetch_enabled)) {
+ (DISPLAY_VER(display) >= 20 || !intel_dp->psr.psr2_sel_fetch_enabled))) {
tgl_dc3co_flush_locked(intel_dp, frontbuffer_bits, origin);
goto unlock;
}
--
2.43.0
^ permalink raw reply related
* RE: [PATCH] drm/i915/cmtg: Fix array-index-out-of-bounds in intel_cmtg_disable
From: Kandpal, Suraj @ 2026-06-25 4:56 UTC (permalink / raw)
To: Manna, Animesh, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org
Cc: Shankar, Uma, Dibin Moolakadan Subrahmanian, Manna, Animesh,
Nautiyal, Ankit K
In-Reply-To: <20260623085334.1297520-1-animesh.manna@intel.com>
> Subject: [PATCH] drm/i915/cmtg: Fix array-index-out-of-bounds in
> intel_cmtg_disable
>
> to_cmtg_transcoder() returns INVALID_TRANSCODER (-1) for any
> cpu_transcoder other than TRANSCODER_A/B. intel_cmtg_disable() then uses
> the resulting cmtg_transcoder to index the per-transcoder register array via
> TRANS_VRR_CTL(), but unlike the other CMTG helpers it does not check for
> INVALID_TRANSCODER first. The only guard is crtc->cmtg.enabled, which is a
> sticky flag on struct intel_crtc and can be set while the crtc_state being
> disabled has a cpu_transcoder that does not map to a CMTG transcoder (e.g.
> during a big-joiner reconfiguration that moves the eDP across pipes).
>
> This results in a negative array index (trans_offsets[-1]) and a UBSAN
> splat:
>
> UBSAN: array-index-out-of-bounds in .../display/intel_cmtg.c:187:24
> intel_cmtg_disable+0x395/0x3d0 [xe]
> intel_old_crtc_state_disables+0xfb/0x1f0 [xe]
> intel_atomic_commit_tail+0xca6/0x2040 [xe]
>
> Bail out early when cmtg_transcoder is INVALID_TRANSCODER, matching the
> guard already used by the other CMTG helpers.
>
> Fixes: 3bb44e8d421a ("drm/i915/cmtg: Modify existing hook to disable
> CMTG")
> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_cmtg.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cmtg.c
> b/drivers/gpu/drm/i915/display/intel_cmtg.c
> index 6da28c185080..dcd29ebdb432 100644
> --- a/drivers/gpu/drm/i915/display/intel_cmtg.c
> +++ b/drivers/gpu/drm/i915/display/intel_cmtg.c
> @@ -183,6 +183,9 @@ void intel_cmtg_disable(const struct intel_crtc_state
> *crtc_state)
> if (!crtc->cmtg.enabled)
> return;
>
> + if (cmtg_transcoder == INVALID_TRANSCODER)
Hmm weird that we come this far with an invalid transcoder, considering that cmtg.enabled passed.
I think we need to make this a drm_WARN_ON(cmtg_transcoder == INVALID_TRANSCODER) and return early
Also to get this splat out of the way we can either inside this function or where intel_cmtg_disable is called can be guarded by
intel_cmtg_is_allowed()
Like this:
if (crtc->cmtg.enabled && intel_cmtg_is_allowed(old_crtc_state)) {
intel_cmtg_set_clk_select(old_crtc_state);
intel_cmtg_disable(old_crtc_state);
}
if (crtc->cmtg.enabled && (intel_crtc_vrr_enabling(state, crtc)) &&
&& intel_cmtg_is_allowed(new_crtc_state))) {
intel_cmtg_set_clk_select(new_crtc_state);
intel_cmtg_disable(new_crtc_state);
}
I think this is a more full proof way of fixing this issue
Regards,
Suraj Kandpal
> + return;
> +
> crtc->cmtg.enabled = false;
> intel_de_rmw(display, TRANS_VRR_CTL(display, cmtg_transcoder),
> VRR_CTL_VRR_ENABLE | VRR_CTL_FLIP_LINE_EN, 0);
> --
> 2.29.0
^ permalink raw reply
* ✓ i915.CI.BAT: success for drm/i915: Refactor generic_handle_irq_safe() error messages (rev2)
From: Patchwork @ 2026-06-25 0:38 UTC (permalink / raw)
To: Jonathan Cavitt; +Cc: intel-gfx
In-Reply-To: <20260623202310.1023770-1-jonathan.cavitt@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
== Series Details ==
Series: drm/i915: Refactor generic_handle_irq_safe() error messages (rev2)
URL : https://patchwork.freedesktop.org/series/169051/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_18719 -> Patchwork_169051v2
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_169051v2/index.html
Participating hosts (42 -> 40)
------------------------------
Missing (2): bat-dg2-13 fi-snb-2520m
Known issues
------------
Here are the changes found in Patchwork_169051v2 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@kms_hdmi_inject@inject-audio:
- fi-kbl-7567u: [SKIP][1] -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18719/fi-kbl-7567u/igt@kms_hdmi_inject@inject-audio.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_169051v2/fi-kbl-7567u/igt@kms_hdmi_inject@inject-audio.html
Build changes
-------------
* Linux: CI_DRM_18719 -> Patchwork_169051v2
CI-20190529: 20190529
CI_DRM_18719: adbc617250e16fb2db4a4c777b89440927cb8973 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_8985: d5fe8732b8547454c38fdd220b55f6f0cc841a3b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_169051v2: adbc617250e16fb2db4a4c777b89440927cb8973 @ git://anongit.freedesktop.org/gfx-ci/linux
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_169051v2/index.html
[-- Attachment #2: Type: text/html, Size: 2146 bytes --]
^ permalink raw reply
* ✓ i915.CI.BAT: success for drm/i915/dg2: Add per-context control for Wa_22013059131 (rev8)
From: Patchwork @ 2026-06-25 0:11 UTC (permalink / raw)
To: Jia Yao; +Cc: intel-gfx
In-Reply-To: <20260623221521.1183124-1-jia.yao@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
== Series Details ==
Series: drm/i915/dg2: Add per-context control for Wa_22013059131 (rev8)
URL : https://patchwork.freedesktop.org/series/164198/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_18719 -> Patchwork_164198v8
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164198v8/index.html
Participating hosts (42 -> 40)
------------------------------
Missing (2): bat-dg2-13 fi-snb-2520m
Known issues
------------
Here are the changes found in Patchwork_164198v8 that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@kms_hdmi_inject@inject-audio:
- fi-kbl-7567u: [SKIP][1] -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18719/fi-kbl-7567u/igt@kms_hdmi_inject@inject-audio.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164198v8/fi-kbl-7567u/igt@kms_hdmi_inject@inject-audio.html
Build changes
-------------
* Linux: CI_DRM_18719 -> Patchwork_164198v8
CI-20190529: 20190529
CI_DRM_18719: adbc617250e16fb2db4a4c777b89440927cb8973 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_8985: d5fe8732b8547454c38fdd220b55f6f0cc841a3b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_164198v8: adbc617250e16fb2db4a4c777b89440927cb8973 @ git://anongit.freedesktop.org/gfx-ci/linux
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164198v8/index.html
[-- Attachment #2: Type: text/html, Size: 2143 bytes --]
^ permalink raw reply
* Re: [PATCH v5] drm/i915: Refactor generic_handle_irq_safe() error messages
From: Andi Shyti @ 2026-06-24 22:38 UTC (permalink / raw)
To: Jonathan Cavitt
Cc: intel-gfx, saurabhg.gupta, alex.zuo, michal.wajdeczko, raag.jadav,
andi.shyti, jani.nikula
In-Reply-To: <20260623202310.1023770-1-jonathan.cavitt@intel.com>
Hi Jonathan,
On Wed, Jun 24, 2026 at 04:23:10AM +0800, Jonathan Cavitt wrote:
> Refactor all error messages resulting from generic_handle_irq_safe()
> failures in I915 for clarity.
>
> v2:
> - Use drm_err_ratelimited() correctly (jcavitt)
>
> v3:
> - Use xe_err_ratelimited() instead (Jadav)
> - Split into patch series (jcavitt)
>
> v4:
> - Use suggested phrasing (Wajdeczko)
>
> v5:
> - s/PTR_ERR/ERR_PTR (jcavitt)
>
> Suggested-by: Raag Jadav <raag.jadav@intel.com>
> Suggested-by: Michal Wajdeczko <Michal.Wajdeczko@intel.com>
> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v3 0/7] don't allow changes to inactive colorops
From: Harry Wentland @ 2026-06-24 20:54 UTC (permalink / raw)
To: Melissa Wen, airlied, alexander.deucher, alex.hung,
aurabindo.pillai, christian.koenig, contact, daniels,
maarten.lankhorst, mripard, simona, siqueira, sunpeng.li,
tzimmermann
Cc: Uma Shankar, Chaitanya Kumar Borah, Xaver Hugl, Pekka Paalanen,
Louis Chauvet, Matthew Schwartz, amd-gfx, kernel-dev, Rob Clark,
Dmitry Baryshkov, Sean Paul, Marijn Suijten, linux-arm-msm,
freedreno, intel-xe, intel-gfx, dri-devel
In-Reply-To: <20260609121230.1358786-1-mwen@igalia.com>
On 2026-06-09 07:51, Melissa Wen wrote:
> This series is a follow-up of what was discussed in [1] and on #wayland
> IRC channel regarding policy and userspace expectations on changes in
> colorop properties and the current status of the color pipeline in which
> the colorop is part of. In short, we agreed that userspace can change
> properties of colorops that are currently part of an active color
> pipeline or when the pipeline is switching status in the same commit.
> However, userspace cannot change colorop properties of inactive color
> pipeline in the expactation that it will be activated at some point in
> the future.
>
> Userspace also expects persistence of color pipeline already set, even
> if it becomes inactive for a while, when activated, colorop settings
> previouly set should be preserved.
>
> In addition, I found some bugs on IGT tests when this policy is applied.
> So I sent bug fixes to kms_colorop and kms_properties to behave
> according to this contract [2]. The rest of the series in [1] was
> detached in [3] since there is no dependency between them.
>
> [v1] https://lore.kernel.org/dri-devel/20260526142940.504911-1-mwen@igalia.com/
> Changes:
> - define a macro to walk in the color pipeline (Alex H.)
> - fix checkpatch warning (Alex H.)
> [v2] https://lore.kernel.org/dri-devel/20260604180457.1110110-1-mwen@igalia.com/
> Changes:
> - [Drop] drm/atomic: duplicate state of all colorops
> If inactive colorops state are duplicated on resume, the commit will be
> rejected.
> - [New] Four new patches to make AMD driver match the policy of colorop
> updates only for colorops in active color pipelines plus individual
> colorop updates. It also tries to untangle COLOR_PIPELINE = Bypass from
> colorop BYPASS prop = true. I think patches 3-5 can be cherry-picked and
> applied if it looks correct for AMD, I just included them here for
> context (for example, Sashiko reported an issue in the previous version
> of this series).
>
> [1] https://lore.kernel.org/dri-devel/20260519211111.228303-1-mwen@igalia.com/
> [2] https://lore.kernel.org/igt-dev/20260602211259.898147-1-mwen@igalia.com
> [3] https://lore.kernel.org/igt-dev/20260526140752.503380-1-mwen@igalia.com/
>
I went through the series a week ago before being getting into the weeds
of other-important-work-tm. It looked fine to me then. Since I'll be off
for the next two weeks I wanted to make sure to at least provide my
Acked-by: Harry Wentland <harry.wentland@amd.com>
for the series. If you don't have RBs by mid-July I'll be happy to have
a more thorough review with the aim of giving my RBs.
Harry
>
> Melissa
>
> Melissa Wen (7):
> drm/atomic: only add states of active or transient active colorops
> drm/atomic: reject colorop update from inactive color pipeline
> drm/amd/display: don't check colorop status if its in an inactive
> pipeline
> drm/amd/display: truly bypass plane colorop 3x4 matrix and hdr mult
> drm/amd/display: make shaper bypass mode cleaner
> drm/amd/display: fix bnld colorop bypass mode
> drm/amd/display: allow individual colorop changes
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 31 ++-
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 178 +++++++-----------
> drivers/gpu/drm/drm_atomic.c | 125 +++++++++++-
> include/drm/drm_colorop.h | 3 +
> 4 files changed, 207 insertions(+), 130 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/3] drm/atomic: only add states of active or transient active colorops
From: John Harrison @ 2026-06-24 20:06 UTC (permalink / raw)
To: Harry Wentland, Melissa Wen, Borah, Chaitanya Kumar, Jani Nikula,
Alex Hung, airlied, maarten.lankhorst, mripard, simona,
tzimmermann
Cc: Simon Ser, Uma Shankar, Xaver Hugl, Pekka Paalanen, Louis Chauvet,
Matthew Schwartz, Rodrigo Siqueira, amd-gfx, kernel-dev,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, linux-arm-msm, freedreno, intel-xe,
intel-gfx, dri-devel
In-Reply-To: <09d1d978-0519-466b-8c81-fc045c415209@amd.com>
On 6/24/26 21:01, Harry Wentland wrote:
> On 2026-06-09 13:23, John Harrison wrote:
>> On 6/3/26 04:27, Melissa Wen wrote:
>>> On 01/06/2026 11:24, Borah, Chaitanya Kumar wrote:
>>>> On 5/29/2026 7:16 PM, Jani Nikula wrote:
>>>>> On Tue, 26 May 2026, Alex Hung <alex.hung@amd.com> wrote:
>>>>>> On 5/26/26 08:17, Melissa Wen wrote:
>>>>>>> Only consider affected colorop states those that are part of an active
>>>>>>> color pipeline or a pipeline that is about to be activated or
>>>>>>> deactivated in the same atomic commit, i.e., colorop is in the chain of
>>>>>>> old/new plane color pipeline property. To cover color_pipeline
>>>>>>> deactivation, remove the condition for plane_state->color_pipeline.
>>>>>>>
>>>>>>> Signed-off-by: Melissa Wen <mwen@igalia.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/drm_atomic.c | 67 +++++++++++++++++++++++++++++++-----
>>>>>>> 1 file changed, 58 insertions(+), 9 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>>>>>> index 170de30c28ae..4fb3a23e862a 100644
>>>>>>> --- a/drivers/gpu/drm/drm_atomic.c
>>>>>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>>>>>> @@ -812,6 +812,59 @@ static int drm_atomic_plane_check(const struct drm_plane_state *old_plane_state,
>>>>>>> return 0;
>>>>>>> }
>>>>>>> +/*
>>>>>>> + * This function walks old and new plane state color pipelines and adds all
>>>>>>> + * colorops in use by @plane to the atomic configuration @state. This is useful
>>>>>>> + * when an atomic commit needs to check all currently enabled or about to be
>>>>>>> + * enabled colorop on @plane, e.g. when changing the mode. This also avoids
>>>>>>> + * including colorop states that are not part of the atomic state.
>>>>>>> + *
>>>>>>> + * Returns:
>>>>>>> + * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
>>>>>>> + * then the w/w mutex code has detected a deadlock and the entire atomic
>>>>>>> + * sequence must be restarted. All other errors are fatal.
>>>>>>> + */
>>>>>>> +static int
>>>>>>> +drm_atomic_add_pipeline_colorops(struct drm_atomic_commit *state,
>>>>>>> + struct drm_plane *plane)
>>>>>>> +{
>>>>>>> + struct drm_colorop *colorop;
>>>>>>> + struct drm_colorop_state *colorop_state;
>>>>>>> + struct drm_plane_state *new_plane_state, *old_plane_state;
>>>>>>> +
>>>>>>> + new_plane_state = drm_atomic_get_new_plane_state(state, plane);
>>>>>>> + old_plane_state = drm_atomic_get_old_plane_state(state, plane);
>>>>>>> +
>>>>>>> + if (WARN_ON(!new_plane_state || !old_plane_state))
>>>>>>> + return -EINVAL;
>>>>>>> +
>>>>>>> + drm_dbg_atomic(plane->dev,
>>>>>>> + "Adding old+new pipeline colorops for [PLANE:%d:%s]\n",
>>>>>>> + plane->base.id, plane->name);
>>>>>>> +
>>>>>>> + for (colorop = new_plane_state->color_pipeline;
>>>>>>> + colorop;
>>>>>>> + colorop = colorop->next) {
>>>>>> This for-loop is used 5 times in this patchset. How about a macro in
>>>>>> drm_colorop.h?
>>>>>>
>>>>>> #define drm_for_each_colorop_in_pipeline(colorop, pipeline) \
>>>>>> for ((colorop) = (pipeline); (colorop); (colorop) = (colorop)->next)
>>>>> Is there a reason struct drm_colorop reinvents lists and doesn't have
>>>>> struct list_head node?
>>>>>
>>>> I believe that's because the "next" colorop is exposed as a property (of the current colorop) to userspace. Since the chain is already described by the property, a struct list_head would be redundant.
>>> Also, each color pipeline is an immutable chain of colorops where the sequence and position matter: once the chain is built, colorops are never added, removed, replaced or walked in reverse. It's a forward-only chain that ends when next == NULL, and it directly matches userspace mapping. Another point to take into account is that there is no struct drm_color_pipeline to hold a list_head yet, since each color pipeline is identified by the first colorop element in the chain. Maybe we will want a container to link a given pre-blend color pipeline to a specific post-blend color pipeline for example, but linking pre- to post-blend color pipelines is something we are still not clear about.
>>>
>>> Melissa
>>>
>> "there is no struct drm_color_pipeline to hold a list_head" <-- I think this is the real reason. It is possible to convert to use a proper list structure, but the result is slightly messy. I had a quick go at it to see how messy:
>> https://patchwork.freedesktop.org/series/168200/
>>
> Yeah, Melissa and Chaitanya pretty much described why they work the way they do. I'm not sure it makes sense to replace the mechanism with lists and any attempt to do so should make sure not to break userspace ABI. I'm not opposed to improvements either if anyone finds a solution that makes everyone's lives easier.
>
> Harry
@Harry, the patch series I linked above does the conversion. It does not
affect the user space ABI at all, only the internal kernel operation is
changed. I think it is better in some ways but maybe not in others. If
you would like to take a look, any feedback would be appreciated.
Thanks,
John.
>
>> John.
>>
>>>> Harry, others can chime in.
>>>>
>>>> ==
>>>> Chaitanya
>>>>
>>>>> BR,
>>>>> Jani.
>>>>>
>>>>>>> + colorop_state = drm_atomic_get_colorop_state(state, colorop);
>>>>>>> + if (IS_ERR(colorop_state))
>>>>>>> + return PTR_ERR(colorop_state);
>>>>>>> + }
>>>>>>> +
>>>>>>> + /* Same color pipeline as new; no point walking old. */
>>>>>>> + if (new_plane_state->color_pipeline == old_plane_state->color_pipeline)
>>>>>>> + return 0;
>>>>>>> +
>>>>>>> + for (colorop = old_plane_state->color_pipeline;
>>>>>>> + colorop;
>>>>>>> + colorop = colorop->next) {
>>>>>>> + colorop_state = drm_atomic_get_colorop_state(state, colorop);
>>>>>>> + if (IS_ERR(colorop_state))
>>>>>>> + return PTR_ERR(colorop_state);
>>>>>>> + }
>>>>>>> +
>>>>>>> + return 0;
>>>>>>> +}
>>>>>>> +
>>>>>>> static void drm_atomic_colorop_print_state(struct drm_printer *p,
>>>>>>> const struct drm_colorop_state *state)
>>>>>>> {
>>>>>>> @@ -1591,11 +1644,9 @@ drm_atomic_add_affected_planes(struct drm_atomic_commit *state,
>>>>>>> if (IS_ERR(plane_state))
>>>>>>> return PTR_ERR(plane_state);
>>>>>>> - if (plane_state->color_pipeline) {
>>>>>>> - ret = drm_atomic_add_affected_colorops(state, plane);
>>>>>>> - if (ret)
>>>>>>> - return ret;
>>>>>>> - }
>>>>>>> + ret = drm_atomic_add_pipeline_colorops(state, plane);
>>>>>>> + if (ret)
>>>>>>> + return ret;
>>>>>>> }
>>>>>>> return 0;
>>>>>>> }
>>>>>>> @@ -1607,10 +1658,8 @@ EXPORT_SYMBOL(drm_atomic_add_affected_planes);
>>>>>>> * @plane: DRM plane
>>>>>>> *
>>>>>>> * This function walks the current configuration and adds all colorops
>>>>>>> - * currently used by @plane to the atomic configuration @state. This is useful
>>>>>>> - * when an atomic commit also needs to check all currently enabled colorop on
>>>>>>> - * @plane, e.g. when changing the mode. It's also useful when re-enabling a plane
>>>>>>> - * to avoid special code to force-enable all colorops.
>>>>>>> + * currently used by @plane to the atomic configuration @state. It's useful
>>>>>>> + * when re-enabling a plane to avoid special code to force-enable all colorops.
>>>>>>> *
>>>>>>> * Since acquiring a colorop state will always also acquire the w/w mutex of the
>>>>>>> * current plane for that colorop (if there is any) adding all the colorop states for
^ permalink raw reply
* Re: [PATCH 1/3] drm/atomic: only add states of active or transient active colorops
From: Harry Wentland @ 2026-06-24 19:01 UTC (permalink / raw)
To: John Harrison, Melissa Wen, Borah, Chaitanya Kumar, Jani Nikula,
Alex Hung, airlied, maarten.lankhorst, mripard, simona,
tzimmermann
Cc: Simon Ser, Uma Shankar, Xaver Hugl, Pekka Paalanen, Louis Chauvet,
Matthew Schwartz, Rodrigo Siqueira, amd-gfx, kernel-dev,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, linux-arm-msm, freedreno, intel-xe,
intel-gfx, dri-devel
In-Reply-To: <0a0a4d13-9821-4a74-82f5-5309a1e168ca@Igalia.com>
On 2026-06-09 13:23, John Harrison wrote:
> On 6/3/26 04:27, Melissa Wen wrote:
>> On 01/06/2026 11:24, Borah, Chaitanya Kumar wrote:
>>> On 5/29/2026 7:16 PM, Jani Nikula wrote:
>>>> On Tue, 26 May 2026, Alex Hung <alex.hung@amd.com> wrote:
>>>>> On 5/26/26 08:17, Melissa Wen wrote:
>>>>>> Only consider affected colorop states those that are part of an active
>>>>>> color pipeline or a pipeline that is about to be activated or
>>>>>> deactivated in the same atomic commit, i.e., colorop is in the chain of
>>>>>> old/new plane color pipeline property. To cover color_pipeline
>>>>>> deactivation, remove the condition for plane_state->color_pipeline.
>>>>>>
>>>>>> Signed-off-by: Melissa Wen <mwen@igalia.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/drm_atomic.c | 67 +++++++++++++++++++++++++++++++-----
>>>>>> 1 file changed, 58 insertions(+), 9 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>>>>> index 170de30c28ae..4fb3a23e862a 100644
>>>>>> --- a/drivers/gpu/drm/drm_atomic.c
>>>>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>>>>> @@ -812,6 +812,59 @@ static int drm_atomic_plane_check(const struct drm_plane_state *old_plane_state,
>>>>>> return 0;
>>>>>> }
>>>>>> +/*
>>>>>> + * This function walks old and new plane state color pipelines and adds all
>>>>>> + * colorops in use by @plane to the atomic configuration @state. This is useful
>>>>>> + * when an atomic commit needs to check all currently enabled or about to be
>>>>>> + * enabled colorop on @plane, e.g. when changing the mode. This also avoids
>>>>>> + * including colorop states that are not part of the atomic state.
>>>>>> + *
>>>>>> + * Returns:
>>>>>> + * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
>>>>>> + * then the w/w mutex code has detected a deadlock and the entire atomic
>>>>>> + * sequence must be restarted. All other errors are fatal.
>>>>>> + */
>>>>>> +static int
>>>>>> +drm_atomic_add_pipeline_colorops(struct drm_atomic_commit *state,
>>>>>> + struct drm_plane *plane)
>>>>>> +{
>>>>>> + struct drm_colorop *colorop;
>>>>>> + struct drm_colorop_state *colorop_state;
>>>>>> + struct drm_plane_state *new_plane_state, *old_plane_state;
>>>>>> +
>>>>>> + new_plane_state = drm_atomic_get_new_plane_state(state, plane);
>>>>>> + old_plane_state = drm_atomic_get_old_plane_state(state, plane);
>>>>>> +
>>>>>> + if (WARN_ON(!new_plane_state || !old_plane_state))
>>>>>> + return -EINVAL;
>>>>>> +
>>>>>> + drm_dbg_atomic(plane->dev,
>>>>>> + "Adding old+new pipeline colorops for [PLANE:%d:%s]\n",
>>>>>> + plane->base.id, plane->name);
>>>>>> +
>>>>>> + for (colorop = new_plane_state->color_pipeline;
>>>>>> + colorop;
>>>>>> + colorop = colorop->next) {
>>>>>
>>>>> This for-loop is used 5 times in this patchset. How about a macro in
>>>>> drm_colorop.h?
>>>>>
>>>>> #define drm_for_each_colorop_in_pipeline(colorop, pipeline) \
>>>>> for ((colorop) = (pipeline); (colorop); (colorop) = (colorop)->next)
>>>>
>>>> Is there a reason struct drm_colorop reinvents lists and doesn't have
>>>> struct list_head node?
>>>>
>>>
>>> I believe that's because the "next" colorop is exposed as a property (of the current colorop) to userspace. Since the chain is already described by the property, a struct list_head would be redundant.
>>
>> Also, each color pipeline is an immutable chain of colorops where the sequence and position matter: once the chain is built, colorops are never added, removed, replaced or walked in reverse. It's a forward-only chain that ends when next == NULL, and it directly matches userspace mapping. Another point to take into account is that there is no struct drm_color_pipeline to hold a list_head yet, since each color pipeline is identified by the first colorop element in the chain. Maybe we will want a container to link a given pre-blend color pipeline to a specific post-blend color pipeline for example, but linking pre- to post-blend color pipelines is something we are still not clear about.
>>
>> Melissa
>>
> "there is no struct drm_color_pipeline to hold a list_head" <-- I think this is the real reason. It is possible to convert to use a proper list structure, but the result is slightly messy. I had a quick go at it to see how messy:
> https://patchwork.freedesktop.org/series/168200/
>
Yeah, Melissa and Chaitanya pretty much described why they work the way they do. I'm not sure it makes sense to replace the mechanism with lists and any attempt to do so should make sure not to break userspace ABI. I'm not opposed to improvements either if anyone finds a solution that makes everyone's lives easier.
Harry
> John.
>
>>>
>>> Harry, others can chime in.
>>>
>>> ==
>>> Chaitanya
>>>
>>>> BR,
>>>> Jani.
>>>>
>>>>>
>>>>>> + colorop_state = drm_atomic_get_colorop_state(state, colorop);
>>>>>> + if (IS_ERR(colorop_state))
>>>>>> + return PTR_ERR(colorop_state);
>>>>>> + }
>>>>>> +
>>>>>> + /* Same color pipeline as new; no point walking old. */
>>>>>> + if (new_plane_state->color_pipeline == old_plane_state->color_pipeline)
>>>>>> + return 0;
>>>>>> +
>>>>>> + for (colorop = old_plane_state->color_pipeline;
>>>>>> + colorop;
>>>>>> + colorop = colorop->next) {
>>>>>> + colorop_state = drm_atomic_get_colorop_state(state, colorop);
>>>>>> + if (IS_ERR(colorop_state))
>>>>>> + return PTR_ERR(colorop_state);
>>>>>> + }
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>>> +
>>>>>> static void drm_atomic_colorop_print_state(struct drm_printer *p,
>>>>>> const struct drm_colorop_state *state)
>>>>>> {
>>>>>> @@ -1591,11 +1644,9 @@ drm_atomic_add_affected_planes(struct drm_atomic_commit *state,
>>>>>> if (IS_ERR(plane_state))
>>>>>> return PTR_ERR(plane_state);
>>>>>> - if (plane_state->color_pipeline) {
>>>>>> - ret = drm_atomic_add_affected_colorops(state, plane);
>>>>>> - if (ret)
>>>>>> - return ret;
>>>>>> - }
>>>>>> + ret = drm_atomic_add_pipeline_colorops(state, plane);
>>>>>> + if (ret)
>>>>>> + return ret;
>>>>>> }
>>>>>> return 0;
>>>>>> }
>>>>>> @@ -1607,10 +1658,8 @@ EXPORT_SYMBOL(drm_atomic_add_affected_planes);
>>>>>> * @plane: DRM plane
>>>>>> *
>>>>>> * This function walks the current configuration and adds all colorops
>>>>>> - * currently used by @plane to the atomic configuration @state. This is useful
>>>>>> - * when an atomic commit also needs to check all currently enabled colorop on
>>>>>> - * @plane, e.g. when changing the mode. It's also useful when re-enabling a plane
>>>>>> - * to avoid special code to force-enable all colorops.
>>>>>> + * currently used by @plane to the atomic configuration @state. It's useful
>>>>>> + * when re-enabling a plane to avoid special code to force-enable all colorops.
>>>>>> *
>>>>>> * Since acquiring a colorop state will always also acquire the w/w mutex of the
>>>>>> * current plane for that colorop (if there is any) adding all the colorop states for
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* ✗ Fi.CI.BUILD: failure for Add support for a DRM backlight capability
From: Patchwork @ 2026-06-24 18:12 UTC (permalink / raw)
To: Mario Limonciello; +Cc: intel-gfx
In-Reply-To: <20260624165751.2014759-1-mario.limonciello@amd.com>
== Series Details ==
Series: Add support for a DRM backlight capability
URL : https://patchwork.freedesktop.org/series/169109/
State : failure
== Summary ==
Error: patch https://patchwork.freedesktop.org/api/1.0/series/169109/revisions/1/mbox/ not applied
Applying: Revert "backlight: Remove notifier"
Applying: backlight: add kernel-internal backlight API
Applying: drm: link connectors to backlight devices
Applying: DRM: Add support for client indicating support for luminance
error: sha1 information is lacking or useless (drivers/gpu/drm/drm_connector.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0004 DRM: Add support for client indicating support for luminance
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced
^ permalink raw reply
* [PATCH v10 27/30] drm/xe/display: Avoid using stolen memory for framebuffer when media gt exists.
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6.
Simply disable allocating stolen memory for framebuffers when media gt
is found.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/xe/display/xe_display_bo.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/xe/display/xe_display_bo.c b/drivers/gpu/drm/xe/display/xe_display_bo.c
index 7fbac223b0977..a5080f6540d46 100644
--- a/drivers/gpu/drm/xe/display/xe_display_bo.c
+++ b/drivers/gpu/drm/xe/display/xe_display_bo.c
@@ -130,6 +130,13 @@ bool xe_display_bo_fbdev_prefer_stolen(struct xe_device *xe, unsigned int size)
if (IS_DGFX(xe))
return false;
+ /*
+ * Avoid stolen memory when the media_gt exists,
+ * because a lot of latency is added when media gt is in MC6
+ */
+ if (xe_device_get_root_tile(xe)->media_gt)
+ return false;
+
if (XE_DEVICE_WA(xe, 22019338487_display))
return false;
--
2.53.0
^ permalink raw reply related
* [PATCH v10 29/30] drm/i915/pmu: Convert to raw spinlock
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
The pmu lock needs to be a raw spinlock, because cpuctx->lock from perf
is a raw spinlock too, and otherwise you get the below splat:
<3> [133.631044] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
<3> [133.631048] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0
<3> [133.631049] preempt_count: 2, expected: 0
<3> [133.631050] RCU nest depth: 0, expected: 0
<4> [133.631051] 2 locks held by swapper/0/0:
<4> [133.631053] #0: ffff88845d62e178 (&cpuctx_lock){....}-{2:2}, at: __perf_install_in_context+0x3f/0x390
<4> [133.631062] #1: ffff88813d822200 (&pmu->lock){+.+.}-{2:2}, at: i915_pmu_enable+0x48/0x390 [i915]
<4> [133.631263] irq event stamp: 8368282
<4> [133.631264] hardirqs last enabled at (8368281): [<ffffffff81527da9>] tick_nohz_idle_exit+0x99/0x170
<4> [133.631268] hardirqs last disabled at (8368282): [<ffffffff81539c93>] flush_smp_call_function_queue+0x73/0xf0
<4> [133.631273] softirqs last enabled at (347482): [<ffffffff813d13fb>] __local_bh_enable_ip+0x14b/0x190
<4> [133.631277] softirqs last disabled at (347458): [<ffffffff8154619a>] cgroup_idr_alloc.constprop.0+0x2a/0x130
<4> [133.631283] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U L 7.1.0-Patchwork_159035v16-g0984dfdee2a4+ #1 PREEMPT_{RT,(lazy)}
<4> [133.631287] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER, [L]=SOFTLOCKUP
<4> [133.631287] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021
<4> [133.631289] Call Trace:
<4> [133.631290] <TASK>
<4> [133.631291] dump_stack_lvl+0x91/0xf0
<4> [133.631297] dump_stack+0x10/0x20
<4> [133.631300] __might_resched+0x174/0x260
<4> [133.631306] rt_spin_lock+0x63/0x200
<4> [133.631309] ? i915_pmu_enable+0x48/0x390 [i915]
<4> [133.631484] i915_pmu_enable+0x48/0x390 [i915]
<4> [133.631656] i915_pmu_event_add+0x71/0x90 [i915]
<4> [133.631827] event_sched_in+0x105/0x270
<4> [133.631833] merge_sched_in+0x2db/0x4e0
<4> [133.631840] visit_groups_merge.constprop.0.isra.0+0x284/0x440
<4> [133.631845] ? lock_is_held_type+0xa3/0x130
<4> [133.631851] ctx_sched_in+0x32f/0x430
<4> [133.631860] perf_event_sched_in+0x83/0xa0
<4> [133.631866] ctx_resched+0x1c9/0x320
<4> [133.631874] __perf_install_in_context+0x266/0x390
<4> [133.631881] ? __pfx_remote_function+0x10/0x10
<4> [133.631885] remote_function+0x4f/0x70
<4> [133.631888] __flush_smp_call_function_queue+0xca/0x6e0
<4> [133.631892] ? trace_hardirqs_on+0x22/0xf0
<4> [133.631899] flush_smp_call_function_queue+0x85/0xf0
<4> [133.631904] do_idle+0x16f/0x2e0
<4> [133.631911] cpu_startup_entry+0x29/0x30
<4> [133.631914] rest_init+0x104/0x200
<4> [133.631920] start_kernel+0xa3a/0xcc0
<4> [133.631926] ? sme_unmap_bootdata+0x14/0x80
<4> [133.631933] x86_64_start_reservations+0x18/0x30
<4> [133.631936] x86_64_start_kernel+0x106/0x150
<4> [133.631938] ? soft_restart_cpu+0x14/0x14
<4> [133.631943] common_startup_64+0x13e/0x141
<4> [133.631957] </TASK>
The testcase that triggers this is perf_pmu.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/i915_pmu.c | 22 +++++++++++-----------
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c3bafda9c708..65771e54b9b51 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -232,7 +232,7 @@ static u64 get_rc6(struct intel_gt *gt)
intel_gt_pm_put_async(gt, wakeref);
}
- spin_lock_irqsave(&pmu->lock, flags);
+ raw_spin_lock_irqsave(&pmu->lock, flags);
if (wakeref) {
store_sample(pmu, gt_id, __I915_SAMPLE_RC6, val);
@@ -253,7 +253,7 @@ static u64 get_rc6(struct intel_gt *gt)
else
store_sample(pmu, gt_id, __I915_SAMPLE_RC6_LAST_REPORTED, val);
- spin_unlock_irqrestore(&pmu->lock, flags);
+ raw_spin_unlock_irqrestore(&pmu->lock, flags);
return val;
}
@@ -304,7 +304,7 @@ void i915_pmu_gt_parked(struct intel_gt *gt)
if (!pmu->registered)
return;
- spin_lock_irq(&pmu->lock);
+ raw_spin_lock_irq(&pmu->lock);
park_rc6(gt);
@@ -316,7 +316,7 @@ void i915_pmu_gt_parked(struct intel_gt *gt)
if (pmu->unparked == 0)
pmu->timer_enabled = false;
- spin_unlock_irq(&pmu->lock);
+ raw_spin_unlock_irq(&pmu->lock);
}
void i915_pmu_gt_unparked(struct intel_gt *gt)
@@ -326,7 +326,7 @@ void i915_pmu_gt_unparked(struct intel_gt *gt)
if (!pmu->registered)
return;
- spin_lock_irq(&pmu->lock);
+ raw_spin_lock_irq(&pmu->lock);
/*
* Re-enable sampling timer when GPU goes active.
@@ -336,7 +336,7 @@ void i915_pmu_gt_unparked(struct intel_gt *gt)
pmu->unparked |= BIT(gt->info.id);
- spin_unlock_irq(&pmu->lock);
+ raw_spin_unlock_irq(&pmu->lock);
}
static void
@@ -742,7 +742,7 @@ static void i915_pmu_enable(struct perf_event *event)
if (bit == -1)
goto update;
- spin_lock_irqsave(&pmu->lock, flags);
+ raw_spin_lock_irqsave(&pmu->lock, flags);
/*
* Update the bitmask of enabled events and increment
@@ -784,7 +784,7 @@ static void i915_pmu_enable(struct perf_event *event)
engine->pmu.enable_count[sample]++;
}
- spin_unlock_irqrestore(&pmu->lock, flags);
+ raw_spin_unlock_irqrestore(&pmu->lock, flags);
update:
/*
@@ -805,7 +805,7 @@ static void i915_pmu_disable(struct perf_event *event)
if (bit == -1)
return;
- spin_lock_irqsave(&pmu->lock, flags);
+ raw_spin_lock_irqsave(&pmu->lock, flags);
if (is_engine_event(event)) {
u8 sample = engine_event_sample(event);
@@ -838,7 +838,7 @@ static void i915_pmu_disable(struct perf_event *event)
pmu->timer_enabled &= pmu_needs_timer(pmu);
}
- spin_unlock_irqrestore(&pmu->lock, flags);
+ raw_spin_unlock_irqrestore(&pmu->lock, flags);
}
static void i915_pmu_event_start(struct perf_event *event, int flags)
@@ -1156,7 +1156,7 @@ void i915_pmu_register(struct drm_i915_private *i915)
};
int ret = -ENOMEM;
- spin_lock_init(&pmu->lock);
+ raw_spin_lock_init(&pmu->lock);
hrtimer_setup(&pmu->timer, i915_sample, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
init_rc6(pmu);
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index 5826cc81858c4..52d4b602310a0 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -71,7 +71,7 @@ struct i915_pmu {
/**
* @lock: Lock protecting enable mask and ref count handling.
*/
- spinlock_t lock;
+ raw_spinlock_t lock;
/**
* @unparked: GT unparked mask.
*/
--
2.53.0
^ permalink raw reply related
* [PATCH v10 30/30] drm/i915: Disable "busy" pmu event on CONFIG_PREEMPT_RT
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
The busyness implementation for guc is incompatible with PMU,
so disable it to prevent upsetting lockdep.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/i915_pmu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 65771e54b9b51..f381e6f30d987 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -554,6 +554,10 @@ engine_event_status(struct intel_engine_cs *engine,
{
switch (sample) {
case I915_SAMPLE_BUSY:
+ /* The guc submission engine->busyness() callback has issues with CONFIG_PREEMPT_RT */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && intel_uc_uses_guc_submission(&engine->gt->uc))
+ return -ENODEV;
+ break;
case I915_SAMPLE_WAIT:
break;
case I915_SAMPLE_SEMA:
--
2.53.0
^ permalink raw reply related
* [PATCH v10 28/30] drm/xe/display: Do not allocate into stolen for new framebuffers.
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
Prefer to use system memory for global framebuffers, and reserve
the space for FBC use only.
Now that multiple CRTC's can use FBC's, the simple heuristic
of using less than half of stolen is no longer sufficient.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/xe/display/xe_display_bo.c | 33 ++++------------------
1 file changed, 6 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_display_bo.c b/drivers/gpu/drm/xe/display/xe_display_bo.c
index a5080f6540d46..1bde12b509fcb 100644
--- a/drivers/gpu/drm/xe/display/xe_display_bo.c
+++ b/drivers/gpu/drm/xe/display/xe_display_bo.c
@@ -153,33 +153,12 @@ static struct drm_gem_object *xe_display_bo_fbdev_create(struct drm_device *drm,
struct xe_device *xe = to_xe_device(drm);
struct xe_bo *obj;
- obj = ERR_PTR(-ENODEV);
-
- if (xe_display_bo_fbdev_prefer_stolen(xe, size)) {
- obj = xe_bo_create_pin_map_novm(xe, xe_device_get_root_tile(xe),
- size,
- ttm_bo_type_kernel,
- XE_BO_FLAG_FORCE_WC |
- XE_BO_FLAG_STOLEN |
- XE_BO_FLAG_GGTT,
- false);
- if (!IS_ERR(obj))
- drm_info(&xe->drm, "Allocated fbdev into stolen\n");
- else
- drm_info(&xe->drm, "Allocated fbdev into stolen failed: %li\n", PTR_ERR(obj));
- } else {
- drm_info(&xe->drm, "Allocating fbdev: Stolen memory not preferred.\n");
- }
-
- if (IS_ERR(obj)) {
- obj = xe_bo_create_pin_map_novm(xe, xe_device_get_root_tile(xe), size,
- ttm_bo_type_kernel,
- XE_BO_FLAG_FORCE_WC |
- XE_BO_FLAG_VRAM_IF_DGFX(xe_device_get_root_tile(xe)) |
- XE_BO_FLAG_GGTT,
- false);
- }
-
+ obj = xe_bo_create_pin_map_novm(xe, xe_device_get_root_tile(xe), size,
+ ttm_bo_type_kernel,
+ XE_BO_FLAG_FORCE_WC |
+ XE_BO_FLAG_VRAM_IF_DGFX(xe_device_get_root_tile(xe)) |
+ XE_BO_FLAG_GGTT,
+ false);
if (IS_ERR(obj)) {
drm_err(&xe->drm, "failed to allocate framebuffer (%pe)\n", obj);
return ERR_PTR(-ENOMEM);
--
2.53.0
^ permalink raw reply related
* [PATCH v10 24/30] FOR-CI: bump MAX_STACK_TRACE_ENTRIES
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
We're hitting a bug in CI where MAX_STACK_TRACE_ENTRIES is set too low.
My guess is the repeated loading/unloading is creating multiples of the
same entries. As a hack just reset lockdep. This might only be necessary
for CI + PREEMPT_RT.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
lib/Kconfig.debug | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9b9f7c5935596..ec35b50068a73 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1625,9 +1625,8 @@ config LOCKDEP_CHAINS_BITS
config LOCKDEP_STACK_TRACE_BITS
int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)"
depends on LOCKDEP && !LOCKDEP_SMALL
- range 10 26
- default 21 if KASAN
- default 19
+ range 22 26
+ default 22
help
Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
--
2.53.0
^ permalink raw reply related
* [PATCH v10 26/30] drm/xe: Avoid using stolen memory for DPT.
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/xe/display/xe_fb_pin.c | 33 +++++++-------------------
1 file changed, 8 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
index f93c98bec5b5f..86013ef532fd7 100644
--- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
+++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
@@ -164,31 +164,14 @@ static int __xe_pin_fb_vma_dpt(struct drm_gem_object *obj,
dpt_size = ALIGN(intel_rotation_info_size(&view->rotated) * 8,
XE_PAGE_SIZE);
- if (IS_DGFX(xe))
- dpt = xe_bo_create_pin_map_at_novm(xe, tile0,
- dpt_size, ~0ull,
- ttm_bo_type_kernel,
- XE_BO_FLAG_VRAM0 |
- XE_BO_FLAG_GGTT |
- XE_BO_FLAG_PAGETABLE,
- pin_params->alignment, false);
- else
- dpt = xe_bo_create_pin_map_at_novm(xe, tile0,
- dpt_size, ~0ull,
- ttm_bo_type_kernel,
- XE_BO_FLAG_STOLEN |
- XE_BO_FLAG_GGTT |
- XE_BO_FLAG_PAGETABLE,
- pin_params->alignment, false);
- if (IS_ERR(dpt))
- dpt = xe_bo_create_pin_map_at_novm(xe, tile0,
- dpt_size, ~0ull,
- ttm_bo_type_kernel,
- XE_BO_FLAG_SYSTEM |
- XE_BO_FLAG_GGTT |
- XE_BO_FLAG_PAGETABLE |
- XE_BO_FLAG_FORCE_WC,
- pin_params->alignment, false);
+ dpt = xe_bo_create_pin_map_at_novm(xe, tile0,
+ dpt_size, ~0ull,
+ ttm_bo_type_kernel,
+ XE_BO_FLAG_VRAM_IF_DGFX(tile0) |
+ XE_BO_FLAG_GGTT |
+ XE_BO_FLAG_PAGETABLE |
+ XE_BO_FLAG_FORCE_WC,
+ pin_params->alignment, false);
if (IS_ERR(dpt))
return PTR_ERR(dpt);
--
2.53.0
^ permalink raw reply related
* [PATCH v10 22/30] Revert "drm/i915: Depend on !PREEMPT_RT."
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe
Cc: dri-devel, Sebastian Andrzej Siewior, Tvrtko Ursulin,
Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Once the known issues are addressed, it should be safe to enable the
driver.
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 5e939004b6463..40a9234e6e5dc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -3,7 +3,6 @@ config DRM_I915
tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
depends on DRM
depends on X86 && PCI
- depends on !PREEMPT_RT
select INTEL_GTT if X86
select INTERVAL_TREE
# we need shmfs for the swappable backing store, and in particular
--
2.53.0
^ permalink raw reply related
* [PATCH v10 23/30] PREEMPT_RT injection
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
kernel/Kconfig.preempt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 88c594c6d7fcd..11bec9be95405 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -90,9 +90,9 @@ config PREEMPT_LAZY
endchoice
config PREEMPT_RT
- bool "Fully Preemptible Kernel (Real-Time)"
- depends on EXPERT && ARCH_SUPPORTS_RT && !COMPILE_TEST
+ def_bool y
select PREEMPTION
+ depends on ARCH_SUPPORTS_RT
help
This option turns the kernel into a real-time kernel by replacing
various locking primitives (spinlocks, rwlocks, etc.) with
--
2.53.0
^ permalink raw reply related
* [PATCH v10 20/30] drm/i915/display: Remove uncore lock from vlv_atomic_update_fifo
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
TODO: Grab uncore lock during entire vblank evasion before disabling
interrupts, and check what breaks?
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c b/drivers/gpu/drm/i915/display/i9xx_wm.c
index 86d1c9f7f0ff0..e07303f0b3cc4 100644
--- a/drivers/gpu/drm/i915/display/i9xx_wm.c
+++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
@@ -1863,7 +1863,6 @@ static void vlv_atomic_update_fifo(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
struct intel_display *display = to_intel_display(crtc);
- struct intel_uncore *uncore = to_intel_uncore(display->drm);
const struct intel_crtc_state *crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
const struct vlv_fifo_state *fifo_state =
@@ -1892,7 +1891,6 @@ static void vlv_atomic_update_fifo(struct intel_atomic_state *state,
* intel_pipe_update_start() has already disabled interrupts
* for us, so a plain spin_lock() is sufficient here.
*/
- spin_lock(&uncore->lock);
switch (crtc->pipe) {
case PIPE_A:
@@ -1951,8 +1949,6 @@ static void vlv_atomic_update_fifo(struct intel_atomic_state *state,
}
intel_de_read_fw(display, DSPARB(display));
-
- spin_unlock(&uncore->lock);
}
#undef VLV_FIFO
--
2.53.0
^ permalink raw reply related
* [PATCH v10 19/30] drm/i915/gt: Set stop_timeout() correctly on PREEMPT-RT
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
Also check if RCU is disabled for PREEMPT-RT, which is the case when
local_bh_disable() is called.
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c0fd349a4600c..9dd9665128caa 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1607,7 +1607,7 @@ u64 intel_engine_get_last_batch_head(const struct intel_engine_cs *engine)
static unsigned long stop_timeout(const struct intel_engine_cs *engine)
{
- if (in_atomic() || irqs_disabled()) /* inside atomic preempt-reset? */
+ if (in_atomic() || irqs_disabled() || rcu_preempt_depth()) /* inside atomic preempt-reset? */
return 0;
/*
--
2.53.0
^ permalink raw reply related
* [PATCH v10 21/30] drm/i915: Use sleeping selftests for igt_atomic on PREEMPT_RT
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
This makes the i915 selftests slightly happier, especially
related to GPU reset.
I believe this may be a better approach than trying to convert
uncore->lock to raw_spinlock
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/selftests/igt_atomic.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/igt_atomic.c b/drivers/gpu/drm/i915/selftests/igt_atomic.c
index fb506b6990956..8ae39cf570b76 100644
--- a/drivers/gpu/drm/i915/selftests/igt_atomic.c
+++ b/drivers/gpu/drm/i915/selftests/igt_atomic.c
@@ -39,7 +39,14 @@ static void __hardirq_end(void)
local_irq_enable();
}
+static void __maybe_unused __nop(void)
+{}
+
const struct igt_atomic_section igt_atomic_phases[] = {
+#if IS_ENABLED(CONFIG_PREEMPT_RT)
+ { "sleeping", __nop, __nop },
+ { },
+#endif
{ "preempt", __preempt_begin, __preempt_end },
{ "softirq", __softirq_begin, __softirq_end },
{ "hardirq", __hardirq_begin, __hardirq_end },
--
2.53.0
^ permalink raw reply related
* [PATCH v10 17/30] drm/i915/guc: Consider also RCU depth in busy loop.
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe
Cc: dri-devel, Sebastian Andrzej Siewior, John B. Wyatt IV,
Rodrigo Vivi, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
intel_guc_send_busy_loop() looks at in_atomic() and irqs_disabled() to
decide if it should busy-spin while waiting or if it may sleep.
Both checks will report false on PREEMPT_RT if sleeping spinlocks are
acquired leading to RCU splats while the function sleeps.
Check also if RCU has been disabled.
Reported-by: "John B. Wyatt IV" <jwyatt@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 053780f562c1a..b25fa8f4dc4bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -362,7 +362,7 @@ static inline int intel_guc_send_busy_loop(struct intel_guc *guc,
{
int err;
unsigned int sleep_period_ms = 1;
- bool not_atomic = !in_atomic() && !irqs_disabled();
+ bool not_atomic = !in_atomic() && !irqs_disabled() && !rcu_preempt_depth();
/*
* FIXME: Have caller pass in if we are in an atomic context to avoid
--
2.53.0
^ permalink raw reply related
* [PATCH v10 18/30] drm/i915/gt: Fix selftests on PREEMPT_RT
From: Maarten Lankhorst @ 2026-06-24 18:04 UTC (permalink / raw)
To: intel-gfx, intel-xe; +Cc: dri-devel, Maarten Lankhorst
In-Reply-To: <20260624180459.1024068-1-dev@lankhorst.se>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
index 10e556a7eac45..c1eff9edd8a5e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
@@ -277,11 +277,11 @@ static int live_engine_busy_stats(void *arg)
st_engine_heartbeat_disable(engine);
ENGINE_TRACE(engine, "measuring idle time\n");
- preempt_disable();
+ migrate_disable();
de = intel_engine_get_busy_time(engine, &t[0]);
udelay(100);
de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
- preempt_enable();
+ migrate_enable();
dt = ktime_sub(t[1], t[0]);
if (de < 0 || de > 10) {
pr_err("%s: reported %lldns [%d%%] busyness while sleeping [for %lldns]\n",
@@ -316,11 +316,11 @@ static int live_engine_busy_stats(void *arg)
}
ENGINE_TRACE(engine, "measuring busy time\n");
- preempt_disable();
+ migrate_disable();
de = intel_engine_get_busy_time(engine, &t[0]);
mdelay(100);
de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
- preempt_enable();
+ migrate_enable();
dt = ktime_sub(t[1], t[0]);
if (100 * de < 95 * dt || 95 * de > 100 * dt) {
pr_err("%s: reported %lldns [%d%%] busyness while spinning [for %lldns]\n",
--
2.53.0
^ permalink raw reply related
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox