On 2024-10-04 12:07:24 [+0300], Ville Syrjälä wrote:
> > what happens if this gets delayed? Just flicker or worse?
>
> In the best best case it just gets you a corrupted frame
> of some sort, in the worst case the hardware falls over.
> Depends on what kind of update is happening, and what
> platf
On 2024-10-04 11:31:22 [+0300], Ville Syrjälä wrote:
>
> So once vblank evasion has declared things to be safe we might have
> as short a time as VBLANK_EVASION_TIME_US to write all the registers.
> If the CPU gets stolen from us at that point we can no longer guarantee
> anything. The magic value
On 2024-10-02 19:58:08 [+0300], Ville Syrjälä wrote:
> > These patches were not picked. Did I forget something or was this just
> > overseen?
>
> This looks quite poorly justified. Eg. you seem to be now
> leaving interrupts enabled (and even preemption enabled I
> guess) when we're racing against
On 2024-06-28 14:57:59 [+0200], To intel-gfx@lists.freedesktop.org wrote:
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
Reported-by: Luca Abeni
Cc: Steven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_display_trace.h | 4
drivers/gpu/drm/i915/i915_trace.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915
Once the known issues are addressed, it should be safe to enable the
driver.
Acked-by: Tvrtko Ursulin
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
x27;t 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
--
_WAIT_FOR_ATOMIC_CHECK() on PREEMPT_RT.
Reviewed-by: Tvrtko Ursulin
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfy...@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_utils.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a
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: Sebasti
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
Acked-by: Tvrtko Ursulin
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2
disabled.
Reported-by: "John B. Wyatt IV"
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sebastian Andrzej Siewior
---
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/i
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
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. Making the lock a raw_spinlock_t led to higher
l
On 2024-06-18 10:00:09 [+0100], Tvrtko Ursulin wrote:
> I did a re-test but am not 100% certain yet. CI looks frustratingly noisy at
> the moment.
>
> igt@debugfs_test@read_all_entries appears to be a fluke which is not new.
>
> But igt@gem_exec_parallel@engines@basic from the latest run seem new
On 2024-06-14 09:32:07 [+0100], Tvrtko Ursulin wrote:
> I think this could be okay-ish in principle, but the commit text is not
> entirely accurate because there is no direct coupling between the wait
> helpers and the uncore lock. They can be used from any atomic context.
>
> Okay-ish in principl
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. Making the lock a raw_spinlock_t led to higher
l
disabled.
Reported-by: "John B. Wyatt IV"
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sebastian Andrzej Siewior
---
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/i
beni
Cc: Steven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_display_trace.h | 4
drivers/gpu/drm/i915/i915_trace.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h
b/drivers
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 a
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: Sebasti
x27;t 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
--
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
x27;m
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
On 2024-06-11 18:25:07 [-0400], Rodrigo Vivi wrote:
> > 2/10 is needed for the XE driver since it shares code with i915.
>
> I believe you meant patch 1 right?
> We are trying to eliminate the
> #if I915
> for the shared display code with Xe... we probably need to think
> more deeply about that.
On 2024-06-11 14:06:00 [+0100], Tvrtko Ursulin wrote:
>
> Hi Sebastian,
Hi Tvrtko,
> Previous CI results have unfortunately expired by now. I have tried
> re-queuing it but it also does not apply any longer so I'm afraid you will
> have to respin before anyone can see the results.
No worries, I
On 2024-04-05 16:18:18 [+0200], To intel-gfx@lists.freedesktop.org wrote:
Hi,
> The following patches are from the PREEMPT_RT queue. It is mostly about
> disabling interrupts/preemption which leads to problems. Unfortunately
…
Could I please get some feedback? I didn't receive anything but
autom
On 2024-05-23 12:45:34 [+0300], Jani Nikula wrote:
>
> Thanks for testing! I suggest filing an issue at [1], attaching dmesg
> from boot with drm.debug=14 module parameter set.
>
> Cc: xe driver maintainers.
Thanks. Submitted as [0]. No idea how to Cc someone there.
[0] https://gitlab.freedeskto
Hi,
I've been testing v6.9 with the XE driver on a
| 00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris
Xe Graphics] (rev 01)
(8086:9a49) 11th Gen Intel(R) Core(TM) i7-1165G7 platform.
During boot up a few timeouts and errors showed up:
| xe :00:02.0: enabling devi
this series with
the patch below? After enabling all tracing I don't see any events in
events/i915.
Sebastian
->8--------
From: Sebastian Andrzej Siewior
Date: Thu, 6 Dec 2018 09:52:20 +0100
Subject: [PATCH] drm/i915: Disable tracing points on PRE
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
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
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: Sebasti
x27;t 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
--
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 a
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
: Steven 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
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
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. Making the lock a raw_spinlock_t led to higher
l
disabled.
Reported-by: "John B. Wyatt IV"
Signed-off-by: Sebastian Andrzej Siewior
---
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 be7
x27;m
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
patch 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/driv
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 the
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 boo
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-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 the
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-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 a
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
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 a
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
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
> > > _wai
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.
>
> > 0005-drm-i915-Don-t-check-for-atomic-context-
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:
https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-big
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
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
--- a
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 stan
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 w
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: drm/i91
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:
…
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: Sebasti
x27;m
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
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
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
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 a
: Steven 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
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 ha
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
x27;t 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
--
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&merge.
Thanks. Should I repost my queue (excluding this one) or should wait
until this one has been ta
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 -
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
--
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
x27;m
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
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: Sebasti
: Steven 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
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
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
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 a
tra (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
x27;t 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
--
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
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 bee
stead of once at
> boot-up.
Yes, it does. Thank you.
Tested-by: Sebastian Andrzej Siewior
> Cheers, Daniel
Sebastian
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
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 al
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-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-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-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)
> > {
> > - lockd
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
ark_lock().
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
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 a
x27;t 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
--
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 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: Sebasti
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
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
1 - 100 of 137 matches
Mail list logo
