== Series Details ==
Series: series starting with [v2,1/1] drm/i915/gt: Increase a time to retry
RING_HEAD reset
URL : https://patchwork.freedesktop.org/series/142218/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15800 -> Patchwork_142218v1
==
> On Thu, Dec 05, 2024 at 04:29:55PM +, Murthy, Arun R wrote:
> > > > > -Original Message-
> > > > > From: Dmitry Baryshkov
> > > > > Sent: Wednesday, December 4, 2024 5:17 PM
> > > > > To: Murthy, Arun R
> > > > > Cc: intel...@lists.freedesktop.org;
> > > > > intel-gfx@lists.freedesk
== Series Details ==
Series: drm/connector: add eld_mutex to protect connector->eld (rev2)
URL : https://patchwork.freedesktop.org/series/141958/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/connector: add eld_mutex to protect connector->eld (rev2)
URL : https://patchwork.freedesktop.org/series/141958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800 -> Patchwork_141958v2
Sum
== Series Details ==
Series: drm/connector: add eld_mutex to protect connector->eld (rev2)
URL : https://patchwork.freedesktop.org/series/141958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800_full -> Patchwork_141958v2_full
===
== Series Details ==
Series: series starting with [v2,1/1] drm/i915/gt: Increase a time to retry
RING_HEAD reset (rev3)
URL : https://patchwork.freedesktop.org/series/142218/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800 -> Patchwork_142218v3
===
== Series Details ==
Series: i915/gt: Reapply workarounds in case the previous attempt failed. (rev2)
URL : https://patchwork.freedesktop.org/series/142188/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800 -> Patchwork_142188v2
==
== Series Details ==
Series: i915/gt: Reapply workarounds in case the previous attempt failed. (rev2)
URL : https://patchwork.freedesktop.org/series/142188/
State : warning
== Summary ==
Error: dim checkpatch failed
70c3e0476ce2 i915/gt: Reapply workarounds in case the previous attempt failed.
Issue seen again where engine resets fails because the engine resumes from
an incorrect RING_HEAD. HEAD is still not 0 even after writing into it.
This seems to be timing issue and we experimented different values from 5ms
to 50ms and found out that 50ms works best based on testing.
So, if write do
From: David Laight
> Sent: 06 December 2024 02:26
(now it is no longer 2am...)
Linus suggested this a while back:
> in
> https://lore.kernel.org/all/CAHk-=wiq=gunwjwwh1craychw73umoaskacovlatfdkevez...@mail.gmail.com/
>
>/*
> * iff 'x' is a non-zero constant integer expression,
> *
Am Donnerstag, dem 05.12.2024 um 22:14 -0800 schrieb Linus Torvalds:
> On Thu, 5 Dec 2024 at 18:26, David Laight wrote:
> >
> > From: Vincent Mailhol
> > > ACK. Would adding a suggested--by Linus tag solve your concern?
>
> I'm genberally the one person who doesn't need any more credit ;)
>
> >
== Series Details ==
Series: series starting with [v2,1/1] drm/i915/gt: Increase a time to retry
RING_HEAD reset (rev2)
URL : https://patchwork.freedesktop.org/series/142218/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15800 -> Patchwork_142218v2
===
Dear Jani,
Thank you for the patch.
Am 05.12.24 um 13:37 schrieb Jani Nikula:
The debugfs contains all the other timings except panel power cycle
delay. Add it for completeness.
For the record, here is the output from the Dell XPS 13 9360, and in
case you want to add it to the commit messag
On Fri. 6 Dec. 2024 at 15:40, Martin Uecker wrote:
> Am Freitag, dem 06.12.2024 um 02:25 + schrieb David Laight:
> > From: Vincent Mailhol
> > > Sent: 05 December 2024 15:31
> > >
> > > -CC: Martin Uecker
> > > +CC: Martin Uecker
> > > (seems that Martin changed his address)
>
> My current o
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++--
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Acked-by: Raphael Gallais-Pou
Signed-off-by: Dmitry Baryshkov
---
drivers/gp
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/analogix/anx7625.c
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access. Individual drivers are not updated (to reduce possible issues
while applying the
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ite-it66121.c | 2
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/display/amdgpu_dm/amd
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Reviewed-by: Jani Nikula
Acked-by: Jani Nikula
Signed-off-by: Dmitry Baryshko
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access.
The individual drivers were just compile tested. I propose to merge the
drm_con
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Acked-by: Abhinav Kumar
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Bary
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/radeon/radeon_audio.c | 2
== Series Details ==
Series: series starting with [v2,1/1] drm/i915/gt: Increase a time to retry
RING_HEAD reset (rev3)
URL : https://patchwork.freedesktop.org/series/142218/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800_full -> Patchwork_142218v3_full
=
On Thu. 5 Dec 2024 at 03:48, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:33
> >
> > __builtin_constant_p() is known for not always being able to produce
> > constant expression [1] which led to the introduction of
> > __is_constexpr() [2]. Because of its dependency on
-CC: Martin Uecker
+CC: Martin Uecker
(seems that Martin changed his address)
On Thu. 5 Dec. 2024 at 03:39, David Laight wrote:
> > Sent: 02 December 2024 17:33
> >
> > From: Vincent Mailhol
> >
> > __is_constexpr(), while being one of the most glorious one liner hack
> > ever witnessed by man
== Series Details ==
Series: i915/gt: Reapply workarounds in case the previous attempt failed. (rev2)
URL : https://patchwork.freedesktop.org/series/142188/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_15800_full -> Patchwork_142188v2_full
...
> > > #define const_NULL(x) _Generic(0 ? (x) : (char *)0, char *: 1, void *: 0)
> > > #define const_true(x) const_NULL((x) ? NULL : (void *)1L))
> > > #define const_expr(x) const_NULL((x) ? NULL : NULL))
> > > I send this morning.
> > > Needs 's/char/struct kjkjkjkjui/' applied.
> >
> > Oh Chri
On Mon, Dec 02, 2024 at 10:07:23PM +0200, Imre Deak wrote:
> On Mon, Dec 02, 2024 at 05:35:34PM +0100, Simona Vetter wrote:
> > On Tue, Nov 26, 2024 at 06:18:56PM +0200, Imre Deak wrote:
> > > Atm when the connector is added to the drm_mode_config::connector_list,
> > > the connector may not be ful
On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol wrote:
>
> > causes issues when 'x' is not an integer expression (think
> > "is_const(NULL)" or "is_const(1 == 2)".
>
> But 1 == 2 already has an integer type as proven by:
Yeah, I was confused about exactly what triggers that odd
'-Wint-in-bool-contex
On Fri, 6 Dec 2024 at 10:52, Linus Torvalds
wrote:
>
> This may be a case of "we just need to disable that incorrect compiler
> warning". Or does anybody see a workaround?
Hmm. The "== 0" thing does work, but as mentioned, that causes (more
valid, imho) warnings with pointers.
And it's not neces
On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
>
> I'm missing the compiler version and options to generate the error.
Just -Wall with most recent gcc versions seems to do it. At least I
can repro it with gcc-14.2.1 and something silly like this:
$ cat t.c
int fn(int a) { return (a<<2)?1:2
Instead of 3 different calls, it should be safe to unify to a single
call now. This makes the init sequence cleaner, and display less
tangled.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/display/xe_display.c | 71 +++--
drivers/gpu/drm/x
We're changing the driver to have no interrupts during early init for
Xe, so we poll the PIPE_FRMSTMSMP counter instead.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
.../drm/i915/display/intel_plane_initial.c| 7 ++-
.../drm/i915/displa
I have rebased the previous series and took out the GuC parts. This makes it a
lot easier to review missing parts,
and not be dependent on GuC loading changes for merging.
Maarten Lankhorst (5):
drm/xe/display: Add intel_plane_initial_vblank_wait
drm/xe: Remove double pageflip
drm/xe: Move
No allocations should be done before we have had a chance to preserve
the display fb.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_device.c | 6 ++
drivers/gpu/drm/xe/xe_tile.c | 12
drivers/gpu/drm/xe/xe_tile.h | 1 +
3 files chang
Technically, I believe this means that xe_display_init_noirq and
xe_display_init_noaccel can be merged together now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/xe_device.c | 12
drivers/gpu/drm/xe/xe_tile.c | 7 +++
2 files changed, 11 insertions(+), 8 deletions(
From: Linus Torvalds
> Sent: 06 December 2024 18:53
>
> On Fri, 6 Dec 2024 at 10:31, Vincent Mailhol
> wrote:
> >
> > > causes issues when 'x' is not an integer expression (think
> > > "is_const(NULL)" or "is_const(1 == 2)".
> >
> > But 1 == 2 already has an integer type as proven by:
>
> Yeah,
== Series Details ==
Series: drm/xe/display: Re-use display vmas when possible (rev3)
URL : https://patchwork.freedesktop.org/series/136034/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15803 -> Patchwork_136034v3
Summary
== Series Details ==
Series: drm/xe/display: Re-use display vmas when possible (rev3)
URL : https://patchwork.freedesktop.org/series/136034/
State : warning
== Summary ==
Error: dim checkpatch failed
7efb6bc72ad1 drm/xe/display: Re-use display vmas when possible
-:175: ERROR:CODE_INDENT: code
This is already handled below by fixup_initial_plane_config.
Fixes: a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of
ggtt")
Cc: Ville Syrjälä
Reviewed-by: Vinod Govindapillai
Reviewed-by: Lucas De Marchi
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/xe/display/xe_p
== Series Details ==
Series: drm/xe/display: Rework display init for reducing flickering.
URL : https://patchwork.freedesktop.org/series/142242/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/in
== Series Details ==
Series: drm/xe/display: Rework display init for reducing flickering.
URL : https://patchwork.freedesktop.org/series/142242/
State : warning
== Summary ==
Error: dim checkpatch failed
f70c71cbab36 drm/xe/display: Add intel_plane_initial_vblank_wait
-:110: WARNING:LONG_LINE:
From: Willy Tarreau
> Sent: 06 December 2024 19:39
> On Fri, Dec 06, 2024 at 11:15:20AM -0800, Linus Torvalds wrote:
> > On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> > >
> > > I'm missing the compiler version and options to generate the error.
> >
> > Just -Wall with most recent gcc versions
From: Linus Torvalds
> Sent: 06 December 2024 19:15
> On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> >
> > I'm missing the compiler version and options to generate the error.
>
> Just -Wall with most recent gcc versions seems to do it. At least I
> can repro it with gcc-14.2.1 and something s
On Fri, Dec 06, 2024 at 11:15:20AM -0800, Linus Torvalds wrote:
> On Fri, 6 Dec 2024 at 11:07, David Laight wrote:
> >
> > I'm missing the compiler version and options to generate the error.
>
> Just -Wall with most recent gcc versions seems to do it. At least I
> can repro it with gcc-14.2.1 and
On Thu. 5 Dec 2024 at 03:30, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:33
> >
> > From: Vincent Mailhol
> >
> > For completion, add statically_false() which is the equivalent of
> > statically_true() except that it will return true only if the input is
> > known to
On Thu, Dec 05, 2024 at 03:47:35PM +, Sebastian Brzezinka wrote:
> `wa_verify`sporadically detects lost workaround on application; this
> is unusual behavior since wa are applied at `intel_gt_init_hw` and
> verified right away by `intel_gt_verify_workarounds`, and `wa_verify`
> doesn't fail on
On Thu, Dec 05, 2024 at 01:44:13PM +0530, Raag Jadav wrote:
> Log throttle reasons on selftest failure which will be useful for
> debugging.
>
> Signed-off-by: Raag Jadav
> ---
> drivers/gpu/drm/i915/gt/selftest_rps.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git
i915 has this really nice, infrastructure where everything becomes
complicated, GGTT needs eviction, etc..
Lets not do that, and make the dumbest possible interface instead.
Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel
fb.
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
Grrr, I just realized that my emails are bouncing… Didn't happen
before, I guess this is because my smtp server is unhappy with the
many people in CC.
Resending using another address (and, while at it, redacted two
messages to combine them in one and added more details).
My deep apologies for tha
== Series Details ==
Series: drm/xe/display: Rework display init for reducing flickering.
URL : https://patchwork.freedesktop.org/series/142242/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_15803 -> Patchwork_142242v1
Summ
On Fri. 6 Dec. 2024 at 15:14, Linus Torvalds
wrote:
> On Thu, 5 Dec 2024 at 18:26, David Laight wrote:
> >
> > From: Vincent Mailhol
> > > ACK. Would adding a suggested--by Linus tag solve your concern?
>
> I'm genberally the one person who doesn't need any more credit ;)
>
> > I actually suspect
On Thu. 5 Dec 2024 at 04:00, David Laight wrote:
> From: Vincent Mailhol
> > Sent: 02 December 2024 17:34
> >
> > Most of the use of __is_const_expr() in i915_reg_defs.h are just to
> > test whether an expression is known to be true. Because those checks
> > are all done in a BUILD_BUG_ON_ZERO(),
Cc: Chris
On Fri, Dec 06, 2024 at 10:45:18AM -0500, Rodrigo Vivi wrote:
> On Thu, Dec 05, 2024 at 01:44:13PM +0530, Raag Jadav wrote:
> > Log throttle reasons on selftest failure which will be useful for
> > debugging.
> >
> > Signed-off-by: Raag Jadav
> > ---
> > drivers/gpu/drm/i915/gt/selfte
On Thu, Dec 05, 2024 at 12:07:53PM +0530, Anirban, Sk wrote:
> On 03-12-2024 16:16, Jani Nikula wrote:
> > On Tue, 03 Dec 2024, Sk Anirban wrote:
> > > Add delays to allow frequency stabilization before power measurement
> > > to fix sporadic power conservation issues in live_rps_power test.
> > L
On Sat. 7 Dec. 2024 at 05:24, David Laight wrote:
> > > > #define const_NULL(x) _Generic(0 ? (x) : (char *)0, char *: 1, void *:
> > > > 0)
> > > > #define const_true(x) const_NULL((x) ? NULL : (void *)1L))
> > > > #define const_expr(x) const_NULL((x) ? NULL : NULL))
> > > > I send this morning.
59 matches
Mail list logo
