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
> > | WARNI
ogram 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 f
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_reserve_no_w
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,
> >>>
&g
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
.
To 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
y 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-off-by:
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
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
nk it.
Acked-by: Sebastian Andrzej Siewior
Sebastian
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
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
> > >
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-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:
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
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 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 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:
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
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
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
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
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
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
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
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
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 inser
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
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
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
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
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
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
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
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
; 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
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)
> > {
> > -
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
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. 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
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
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
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
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
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
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
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
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
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
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
ext 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 series.
> > Thank you
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
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
' 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/amdgpu
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
' 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 workqueue
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 100644
---
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
reemptible 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/amba-clcd.c
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
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/dsi.c
index dc34bb04b865c..df90091de7
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
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 Andrz
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
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
On 2020-11-12 09:10:34 [+0100], Marek Szyprowski wrote:
> I can do more tests to help fixing this issue. Just let me know what to do.
-> https://lkml.kernel.org/r/87y2j6n8mj@nanos.tec.linutronix.de
Sebastian
___
dri-devel mailing list
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
Andrzej Siewior
---
v1…v2: Also remove the "VGA registers." in struct vmw_private as per
Emil Velikov. It it is unused since commit a278724aa23c
("drm/vmwgfx: Implement fbdev on kms v2").
On 2020-02-28 11:42:46 [+], Emil Velikov wrote:
> Hi Sebastian,
Hi Emil,
Andrzej Siewior
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 15 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 81 -
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 31 --
3 files changed, 127 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu
that this preempt_disable()ed
section is not required for correctness.
Remove the preempt_disable() section.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206591
Link:
https://lkml.kernel.org/r/0b5e1c65d89951de993deab06d1d197b40fd67aa.ca...@vmware.com
Signed-off-by: Sebastian Andrzej Siewior
1 - 100 of 131 matches
Mail list logo
