-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 -
drivers/gpu/drm/i915/i915_trace.h | 1 -
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
On 06/21/2013 01:08 PM, Chris Wilson wrote:
On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote:
There is a report on RT about BUG: scheduling while atomic because the
sleeping lock is taken in tracing context. This patch simply moves
locking operation out of the tracing
to remove this hack and return -1 in case of a dead
lock. Here is the patch.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 32 +++-
2 files changed, 3 insertions(+), 30
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on raw locks in the other thread.
Are there any suggestions for now? preempt_disable_nort() like Luis
suggesed?
-mario
Sebastian
___
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on raw locks in the other thread
* Christoph Mathys | 2015-12-21 14:19:10 [+0100]:
>While playing with 4.1.13-rt15 I stumbled across the following thread
>where Luis reports the same problem with i915 gpu:
>i915: sleeping function called from invalid context at
>intel_pipe_update_start/end
ut lockdep the set
name/class function vanishes.
Reported-by: kbuild test robot <fengguang...@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
---
drivers/gpu/drm/i915/i915_gem_timeline.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
---
+peterz
context: http://www.spinics.net/lists/intel-gfx/msg149011.html
On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > > On Thu, 2017-11
On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > The code has an ifdef and uses two functions to either init the bare
> > spinlock or init it and set a lock-class. It is possible to do the same
&g
FE flag because it is not required.
ping
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Sebastian Andrzej Siewior
> ---
&
: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_sw_fence.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b
. Also, it is not obvious if there is a special reason
to why the interrupts are disabled independently of the lock.
Enable/disable interrupts as part of the locking instruction.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 8 ++--
1 file changed, 2 insertions
Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Clark Williams
> Cc: Sebastian Andrzej Siewior
> ---
> Note this should need the fixes in
> 20190926105644.16703-2-bige...@linutronix.de, by itself this should be a
> test vehicle to exercise that patch!
> ---
> drivers/g
On 2019-09-26 15:57:07 [+0100], Tvrtko Ursulin wrote:
> 2. What about our tasklets - with threaded irqs we don't need them any more,
> right? So in this case they just add additional latency.
If you enqueue / schedule tasklets from your threaded handler then this
will wake up ksoftirqd and
On 2019-09-26 16:40:34 [+0100], Chris Wilson wrote:
>
> It's all edge interrupts -- although for gen2/3 my memory is hazy. But
> the GPU (circa gen6) can generate more than enough interrupts to saturate
> a CPU.
:)
> -Chris
Sebastian
___
Intel-gfx
On 2019-09-26 16:24:59 [+0100], Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index bc83f094065a..f3df7714a3f3 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -4491,8
the locks become
sleeping locks and do not really disable interrupts.
Remove lockdep_assert_irqs_disabled().
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm
Two locking related changed which popped up on PREEMPT_RT.
Sebastian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 16 +---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 -
drivers/gpu/drm/i915/gt/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
4 files changed, 7 insertions(+), 14 deletions
On 2019-09-26 16:44:33 [+0100], Chris Wilson wrote:
> > It's all edge interrupts -- although for gen2/3 my memory is hazy. But
> > the GPU (circa gen6) can generate more than enough interrupts to saturate
> > a CPU.
>
> So everything older than gen5 has MSI disabled it appears and needs
>
son confirmed that local_irq_disable() was just introduced as
an optimisation to avoid enabling/disabling interrupts during
lock/unlock combo.
Enable/disable interrupts as part of the locking instruction.
Cc: Chris Wilson
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: Rebase to v5.4-rc3
driv
son confirmed that local_irq_disable() was just introduced as
an optimisation to avoid enabling/disabling interrupts during
lock/unlock combo.
Enable/disable interrupts as part of the locking instruction.
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Sebastian Andrzej Siewior
---
v2
lso, it is not obvious if there is a special reason
to why the interrupts are disabled independently of the lock.
Enable/disable interrupts as part of the locking instruction.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c |8 ++--
1 file changed, 2 insertions(+)
On 2019-10-10 19:11:27 [+0100], Chris Wilson wrote:
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -251,15 +251,13 @@ static bool i915_request_retire(struct i
> > active->retire(active, rq);
> > }
> >
> > -
On 2019-10-10 21:30:35 [+0100], Chris Wilson wrote:
> > | spin_lock_irq(>engine->active.lock);
> > | list_del(>sched.link);
> > | spin_unlock_irq(>engine->active.lock);
> > |
> > | spin_lock_irq(>lock);
> > | i915_request_mark_complete(rq);
> > …
> > |
sing the registers. The crypto
code uses it for that purpose.
So
Reviewed-by: Sebastian Andrzej Siewior
May I ask how large the memcpy can be? I'm asking in case it is large
and an explicit rescheduling point might be needed.
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason
On 2021-01-09 01:33:52 [+0100], Thomas Bogendoerfer wrote:
> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
> > On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> > > Hi Thomas,
> > >
> > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this
tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
.../drm/i915/gt
Clark Williams reported two issues with the i915 driver running on
PREEMPT_RT. While #1 looks simple I have no idea about #2 thus the RFC.
Sebastian
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
On 2021-10-13 14:02:59 [+0200], Daniel Vetter wrote:
> On Tue, Oct 05, 2021 at 08:51:51AM +0200, Sebastian Andrzej Siewior wrote:
> > The warning poped up, it says it increase it by the number of occurrence.
> > I saw it 18 times so here it is.
> > It start
On 2021-10-13 14:57:34 [+0200], Daniel Vetter wrote:
> Hm there's a pile of commits there, and nothing immediately jumps to
> light. The thing is, 18 is likely way too much, since if e.g. we have a
> single new property on a plane and that pushes over the limit on all of
> them, you get iirc 3x4
On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote:
> On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote:
> > c7fcbf2513973 -> does not boot
> > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY
> > 6f11f37459d8f -> boot
; boot-up.
Yes, it does. Thank you.
Tested-by: Sebastian Andrzej Siewior
> Cheers, Daniel
Sebastian
On 2021-09-29 18:07:00 [+0200], Anton Lundin wrote:
> Hi.
Hi,
> While I was chasing some other bugs I tested 5.15-rc3-rt5 and noted your
> code e446c2038b58 ("drm/i915/gt: Use spin_lock_irq() instead of
> local_irq_disable() + spin_lock()") and noted that this patch created a
> lot of visual
On 2021-10-06 12:34:19 [+0300], Ville Syrjälä wrote:
> I think the correct answer is to make uncore.lock a raw_spinlock.
> Without the tracepoints deubgging any of this is stuff pretty much
> impossible. We also take that lock a lot.
Let me check if that works.
Sebastian
On 2021-10-06 12:15:21 [+0200], To Ville Syrjälä wrote:
> On 2021-10-06 12:34:19 [+0300], Ville Syrjälä wrote:
> > I think the correct answer is to make uncore.lock a raw_spinlock.
> > Without the tracepoints deubgging any of this is stuff pretty much
> > impossible. We also take that lock a lot.
On 2021-10-05 11:13:16 [+0100], Tvrtko Ursulin wrote:
> Needs this fix:
>
> commit d576b31bdece7b5034047cbe21170e948198d32f
> Author: Matthew Auld
> Date: Fri Sep 24 15:46:46 2021 +0100
>
> drm/i915: remember to call i915_sw_fence_fini
Thanks, works. Needed a tweak since it does not
The warning poped up, it says it increase it by the number of occurrence.
I saw it 18 times so here it is.
It started to up since commit
2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage
property")
Increase DRM_OBJECT_MAX_PROPERTY by 18.
Signed-off-by: Sebasti
On 2021-07-27 12:15:59 [-0700], Daniele Ceraolo Spurio wrote:
> On 7/26/2021 5:23 PM, Matthew Brost wrote:
> > This adds GuC backend support for i915_request_cancel(), which in turn
> > makes CONFIG_DRM_I915_REQUEST_TIMEOUT work.
> >
> Reviewed-by: Daniele Ceraolo Spurio
I have a few instances
Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/gpu/drm/i915/i915_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 773e7362c4442..5ff6c0a37fdfa 100644
--- a/drivers/gpu/drm/i915
ven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_trace.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 806ad688274bf..773e7362c4442 100644
--- a/drivers/gpu/drm/i915/i915_trac
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian An
Hi,
the following patches are from the PREEMPT_RT queue. It is mostly about
disabling interrupts/preemption which leads to problems.
Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because
it acquires locks from within trace points.
I tested it on a SandyBridge with built-in i915
tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
.../drm
if the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2 deletions(-)
diff --git
ock().
Cc: Peter Zijlstra
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_context.h | 6 ++-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 38 +--
drivers/gpu/drm/i915/i915_request.c
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3
On 2021-10-05 21:16:17 [+0200], Peter Zijlstra wrote:
> > -static inline void intel_context_mark_active(struct intel_context *ce)
> > +static inline void intel_context_mark_active(struct intel_context *ce,
> > +bool timeline_mutex_needed)
> > {
> > -
On 2021-09-16 11:38:55 [+0200], Maarten Lankhorst wrote:
> Patches look good.
Thank you for looking.
> For both patches:
>
> Reviewed-by: Maarten Lankhorst
>
> I've been looking at running i915 with the -rt patch series, and
> noticed i915_request_submit fails with
stance later during memory allocation.
Add a CONTEXT_IS_PARKED bit to intel_engine_cs and set_bit/clear_bit it
instead of mutex_acquire/mutex_release. Use test_bit in the two
identified spots which relied on the lockdep annotation.
Cc: Peter Zijlstra
Signed-off-by: Sebastian Andrzej Siewior
--
On 2021-11-19 08:47:56 [-], Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Don't disable interrupts and pretend a lock as been
> acquired in __timeline_mark_lock().
> URL : https://patchwork.freedesktop.org/series/97082/
> State : failure
>
> == Summary ==
>
> CI Bug Log -
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3
tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
.../drm
if the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2 deletions(-)
diff --git
jlstra (Intel)
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_context.h | 3 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 38 +--
drivers/gpu/drm/i915/i915_request.h | 3 +-
4 files ch
the following patches are from the PREEMPT_RT queue. It is mostly about
disabling interrupts/preemption which leads to problems. Patches 1-4 are
independent of PREEMPT_RT.
Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because
it acquires locks from within trace points. It has
ven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_trace.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 9795f456cccfc..0f8341ca67385 100644
--- a/drivers/gpu/drm/i915/i915_trac
Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/gpu/drm/i915/i915_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 0f8341ca67385..0aefb14c638ae 100644
--- a/drivers/gpu/drm/i915
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian An
currently unsure about changing this.
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfy...@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
mutex_acquire_nest() expects a pointer, pass the pointer.
Fixes: 12235da8c80a1 ("kernel/locking: Add context to ww_mutex_trylock()")
Signed-off-by: Sebastian Andrzej Siewior
---
Not sure why I haven't seen this earlier…
kernel/locking/ww_rt_mutex.c | 2 +-
1 file changed, 1 inser
n the lockdep annotation.
Cc: Peter Zijlstra
Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Daniel Vetter
---
v1…v2:
- Add commit 6dcb85a0ad990 as reference.
- Name the bit CONTEXT_IS_PARKING.
drivers/gpu/drm/i915/gt/intel_context.h | 3 +-
drivers/gpu/drm/i915/gt/intel_context_typ
On 2021-11-19 17:04:00 [+0100], Daniel Vetter wrote:
> Yeah if we can simplify this with reverts then I'm all for this.
>
> Acked-by: Daniel Vetter
>
> I've asked drm/i915 maintainers to check
Thanks. Should I repost my queue (excluding this one) or should wait
until this one has been taken
On 2021-12-14 09:36:52 [-0500], Steven Rostedt wrote:
> Another way around this that I can see is if the data for the tracepoints
> can fit on the stack and add wrappers around the tracepoints. For example,
> looking at the first tracepoint in i915_trace.h:
…
Nice.
> We could modify this to be:
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3
Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/gpu/drm/i915/i915_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 64c3fa7cc05df..89a4089bc4baf 100644
--- a/drivers/gpu/drm/i915
currently unsure about changing this.
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfy...@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian An
tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
.../drm
Hi,
The following patches are from the PREEMPT_RT queue. One patch was
applied, one added so here are eight again. I can post them in smaller
batches if that is preferred.
It is mostly about disabling interrupts/preemption which leads to
problems. Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
ven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_trace.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 8104981a66044..64c3fa7cc05df 100644
--- a/drivers/gpu/drm/i915/i915_trac
On 2021-12-14 15:58:45 [-], Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: PREEMPT_RT related fixups. (rev4)
> URL : https://patchwork.freedesktop.org/series/95463/
> State : failure
>
> == Summary ==
>
> Applying: drm/i915: Drop the irqs_disabled() check
> Applying:
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3
if the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Hi,
these two patches are from the RT queue. They avoid IRQ-off checks and
IRQ-off regions which are not valid/ possible on PREEMPT_RT and are not
needed on !PREEMPT_RT.
Sebastian
el. This way
> PREEMPT_RT itself can be enabled without needing to address the i915
> issues first. The RT related patches are still in RT queue and will be
> handled later.
>
> Signed-off-by: Sebastian Andrzej Siewior
A gentle ping ;)
> ---
> drivers/gpu/drm/i915/Kconfig | 1
On 2022-02-28 10:10:48 [+], Tvrtko Ursulin wrote:
> Hi,
Hi,
> Could you paste a link to the queue of i915 patches pending for a quick
> overview of how much work there is and in what areas?
Last post to the list:
On 2022-03-01 14:27:18 [+], Tvrtko Ursulin wrote:
> > you see:
> > 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
> > 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
>
> Two for the display folks.
>
> >
On 2022-03-02 11:42:35 [+], Tvrtko Ursulin wrote:
> > > > 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
> > >
> > > What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
> > > solution could be to always force the !ATOMIC path (for the whole
> > >
related patches are still in RT queue and will be
handled later.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a4c94dc2e2164..3aa719d5a0f0d 100644
On 2021-12-14 11:58:37 [-0500], Steven Rostedt wrote:
> On Tue, 14 Dec 2021 18:34:50 +0200
> Ville Syrjälä wrote:
>
> > Looks lightly tedious. Can't we have "slow" (or whatever) versions of
> > the trace macros so we could just declare these the same was as before
> > without having to manually
On 2022-01-27 00:29:37 [+0100], Mario Kleiner wrote:
> Hi, first thank you for implementing these preempt disables according to
Hi Mario,
> the markers i left long ago. And sorry for the rather late reply.
>
> I had a look at the code, as of Linux 5.16, and did also a little test run
> (of a
On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
> preempt disable section over the hardware reset callback to prepare the
> driver for being able to reset from atomic contexts.
…
This missed
On 2023-07-03 16:30:01 [+0100], Tvrtko Ursulin wrote:
> Hi,
Hi,
>
> Atomic requirement from that commit text is likely referring to removing the
> old big sleeping mutex we had in the reset path. So it looks plausible that
> preempt_disable() section is not strictly needed and perhaps motivation
On 2023-07-04 09:02:07 [+0100], Tvrtko Ursulin wrote:
> Lets make it a two patch series and then see. First patch to see if we can
> really get away without the top level preempt_disable, and then second patch
> to see if we can get away with preemptible short sleeps too.
oki.
> I guess on RT
ontexts.
>
…
This looks like what I tested previously. So
Acked-by: Sebastian Andrzej Siewior
Thank you.
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Paul Gortmaker
> Cc: Sebastian Andrzej Siewior
Sebastian
On 2023-07-10 20:51:14 [-0400], John B. Wyatt IV wrote:
> Hello everyone, I am a new kernel developer with the Red Hat real-time team.
>
> I am seeing two different call traces with 6.4-rt6 on my 12th Gen
> Intel Framework Laptop with i915 emit the same bug. Both of them
> occurred in the same
On 2023-06-22 20:57:50 [-0400], Paul Gortmaker wrote:
[ longer report about what is broken.]
Commit ade8a0f598443 ("drm/i915: Make all GPU resets atomic") introduces
a preempt_disable() section around the invocation of the reset callback.
I can't find an explanation why this is needed. There was
h description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_vblank.c | 38
1 file changed, 28 insertions(+), 10 deletions(-)
--- a/drivers/g
On 2024-04-08 13:06:50 [-0400], Steven Rostedt wrote:
> On Fri, 5 Apr 2024 16:18:23 +0200
> Sebastian Andrzej Siewior wrote:
>
> > The order of the header files is important. If this header file is
> > included after tracepoint.h was included then the NOTRACE here becomes
Once the known issues are addressed, it should be safe to enable the
driver.
Signed-off-by: Sebastian Andrzej Siewior
---
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 5932024f8f954
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian An
h includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3
Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/gpu/drm/i915/i915_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index c54653cf72c95..3c51620d011b1 100644
--- a/drivers/gpu/drm/i915
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
ven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_trace.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index ce1cbee1b39dd..c54653cf72c95 100644
--- a/drivers/gpu/drm/i915/i915_trac
1 - 100 of 106 matches
Mail list logo
