f[intf_id].irq < 0)
> return;
>
> - ret = generic_handle_irq(gt->gsc.intf[intf_id].irq);
> + ret = generic_handle_irq_safe(gt->gsc.intf[intf_id].irq);
> +
that extra line looks odd, other than that
Acked-by: Sebastian Andrzej Siewior
> if (ret)
>
1e3dc1d8622b ("drm/i915/gsc: add gsc as a mei auxiliary device")
> Tested-by: Furong Zhou
> Suggested-by: Sebastian Andrzej Siewior
> Signed-off-by: Junxiao Chang
> ---
> drivers/gpu/drm/i915/gt/intel_gsc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
&g
On 2025-04-24 10:53:31 [+], Chang, Junxiao wrote:
> >> This should have a Fixes when generic_handle_irq() was introduced.
>
> If PREEMPT_RT is disabled, original driver works fine. I prefer to not
> add "Fixes:"?
PREEMPT_RT is mainline. It deserves the same fixes as other parts of the
kernel.
On 2025-04-24 14:56:08 [+0800], Junxiao Chang wrote:
> MEI GSC interrupt comes from i915. It has top half and bottom half.
> Top half is called from i915 interrupt handler. It should be in
> irq disabled context.
>
> With RT kernel, by default i915 IRQ handler is in threaded IRQ. MEI GSC
> top hal
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
I posted this path
https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
Then
On 2024-06-13 14:33:51 [+0200], Christian König wrote:
> > Provide ww_mutex_base_lock() which points to the correct function for
> > PREEMPT_RT and non-PREEMPT_RT builds.
>
> In general good that somebody is looking into this, but I can't even judge
> why ww_mutex would use rt_mutex in the first p
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
Repost of https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
drivers/gpu/drm/ttm/tests/
function for
> > PREEMPT_RT and non-PREEMPT_RT builds.
> >
> > Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
> > Signed-off-by: Sebastian Andrzej Siewior
> > ---
> >
> > For the record, testing led to
> > | WARN
he test program since
> their usefulness is limited outside of well known selftests.
>
> Provide ww_mutex_base_lock() which points to the correct function for
> PREEMPT_RT and non-PREEMPT_RT builds.
>
> Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions&q
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
For the record, testing led to
| WARNING: CPU: 5 PID: 2089 at include/drm/ttm/ttm_bo.h:247
ttm_bo_re
On 2023-10-04 08:44:58 [-0400], Harry Wentland wrote:
> CI passed.
>
> Series is
> Acked-by: Harry Wentland
Thank you.
> Harry
Sebastian
On 2023-10-04 08:10:35 [-0400], Hamza Mahfooz wrote:
> I did some digging, and it seems like the intention of that patch was to
> fix the following splat:
>
> WARNING: CPU: 5 PID: 1062 at
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/dc_fpu.c:71
> dc_assert_fp_enabled+0x1a/0x30 [amdgpu]
> [...
On 2023-10-03 15:53:41 [-0400], Harry Wentland wrote:
> On 2023-09-21 10:15, Sebastian Andrzej Siewior wrote:
> > This is a revert of the commit mentioned below while it is not wrong, as
> > in the kernel will explode, having migrate_disable() here it is
> > comple
On 2023-10-03 15:54:58 [-0400], Harry Wentland wrote:
> On 2023-10-02 06:58, Sebastian Andrzej Siewior wrote:
> > On 2023-09-22 07:33:26 [+0200], Christian König wrote:
> >> Am 21.09.23 um 16:15 schrieb Sebastian Andrzej Siewior:
> >>> Hi,
> >>>
>
On 2023-09-22 07:33:26 [+0200], Christian König wrote:
> Am 21.09.23 um 16:15 schrieb Sebastian Andrzej Siewior:
> > Hi,
> >
> > I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
> > is #4 + #5 and the rest was made while looking at th
preserve previous "clean" state of "pipes" add a memset() before the
second invocation of dcn20_validate_bandwidth_internal() where the
variable is used.
Signed-off-by: Sebastian Andrzej Siewior
---
.../drm/amd/display/dc/dcn20/dcn20_resource.c| 10 +-
.../gpu/dr
.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217928
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 10 +-
drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 7 ++-
drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.h | 5
Add a warning if the FPU is used from any context other than task
context. This is only precaution since the code is not able to be used
from softirq while the API allows it on x86 for instance.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 1 +
1
Hi,
I stumbled uppon the amdgpu driver via a bugzilla report. The actual fix
is #4 + #5 and the rest was made while looking at the code.
Sebastian
that can occur if the
variable is additionally accessed from an interrupt.
Remove migrate_disable/enable() from dc_fpu_begin/end().
Cc: Tianci Yin
Cc: Aurabindo Pillai
Fixes: 0c316556d1249 ("drm/amd/display: Disable migration to ensure consistency
of per-CPU variable")
Signed-of
functions which are now not
needed.
Signed-off-by: Sebastian Andrzej Siewior
---
.../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c| 50 ---
1 file changed, 20 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
b/drivers/gpu/drm/amd/display
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
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
o need to
unblank it.
Acked-by: Sebastian Andrzej Siewior
Sebastian
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
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
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 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:
…
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
: 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
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
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
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
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
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
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
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: Sebasti
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
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
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
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
: 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
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 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
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
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
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
: 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 806ad688274bf..773e7362c4442 100644
--- a/drivers/gpu/drm/i915/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: Sebasti
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 apply
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 o
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-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 GEM_BUG_ON(!irqs_disabled());
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
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
---
.../d
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
on't see it
in the next tree as of today. Is there anything for me to do?
> Regards,
> Christian.
>
> Am 09.02.21 um 17:53 schrieb Sebastian Andrzej Siewior:
> > On 2021-02-09 13:50:31 [+0100], Christian König wrote:
> > > Reviewed-by: Christian König for the se
On 2021-02-08 23:38:07 [+0100], To linux-fb...@vger.kernel.org wrote:
> Folks,
>
> in the discussion about preempt count consistency across kernel
> configurations:
>
> https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
>
> it was concluded that the usage of in_interrupt() and re
On 2021-02-09 13:50:31 [+0100], Christian König wrote:
> Reviewed-by: Christian König for the series.
Thank you.
Any chance you could give me a hand with the remaining three users
within the amdgpu driver? I don't know if the in_interrupt() check can
be limited to certain callers.
What I noticed
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
In the long run, usage of
false.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index ca7e7264926e6..72c319b860a33 100644
--- a/drivers/gpu/drm
7; to gfx_v8_0_parse_sq_irq() which is true if
invoked from the worker.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/a
lready done to check if the ih pointer is from
ih_soft.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_
false.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index ca7e7264926e6..72c319b860a33 100644
--- a/drivers/gpu/drm
7; to gfx_v8_0_parse_sq_irq() which is true if
invoked from the worker.
Signed-off-by: Sebastian Andrzej Siewior
---
Side note: work_pending() will return false _before_ the callback
function (gfx_v8_0_sq_irq_work_func() in case) is invoked. That means if
the interrupt can fire again before the work
lready done to check if the ih pointer is from
ih_soft.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_
.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/gma500/intel_gmbus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/intel_gmbus.c
b/drivers/gpu/drm/gma500/intel_gmbus.c
index 370bd6451bd9b..eb0924473a218 100644
--- a/drivers/gpu/drm
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
In the long run, usage of
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/video/fbdev/omap/hwa742.c | 42 ---
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap/hwa742.c
b/drivers/video/fbdev/omap/hwa742.c
index cfe63932f8255..b191bef22d984 10064
Folks,
in the discussion about preempt count consistency across kernel
configurations:
https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/
it was concluded that the usage of in_interrupt() and related context
checks should be removed from non-core code.
In the long run, usage of
used in preemptible context.
Replace clcdfb_sleep() with msleep().
Cc: Peter Collingbourne
Cc: Russell King
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/video/fbdev/amba-clcd.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/a
c: linux-o...@vger.kernel.org
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/d
ned-off-by: Ahmed S. Darwish
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index dc34bb04b865c..df90091de75f8 10
The mba-clcd driver uses in_interrupt() in clcdfb_sleep():
| /*
| * Unfortunately, the enable/disable functions may be called either from
| * process or IRQ context, and we _need_ to delay. This is _not_ good.
| */
| static inline void clcdfb_sleep(unsigned int ms)
| {
| if (in_atomic()
reemptible user will block on the semphore waiting for a
request to become available in case there are no requests available.
Replace in_interrupt() with a `can_sleep' argument to indicate if it is
safe to block on the sempahore.
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Sebastian
1 - 100 of 138 matches
Mail list logo
