From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org,
Thomas Gleixner <tglx@linutronix.de>,
dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
Date: Tue, 1 Mar 2022 14:27:18 +0000 [thread overview]
Message-ID: <42282635-50a8-505f-0bd5-5aef9945e3d3@linux.intel.com> (raw)
In-Reply-To: <YhylgaoHtSKi7+el@linutronix.de>
On 28/02/2022 10:35, Sebastian Andrzej Siewior wrote:
> On 2022-02-28 10:10:48 [+0000], 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-bigeasy@linutronix.de/
>
> or if you look at the DRM section in
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=v5.17-rc6-rt10-patches#n156
Thanks!
> 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-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
_wait_for_atomic macro) on PREEMPT_RT.
> 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
If the issue is only with certain trace points why disable all?
> 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
Didn't quite fully understand, why is this not fixable? Especially
thinking if the option of not blanket disabling all tracepoints in the
previous patch.
> 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
Not sure about why cond_resched was put between irq_work_queue and
irq_work_sync - would it not be like-for-like change to have the two
together? Commit message makes me think _queue already starts the
handler on x86 at least.
> 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
I think this is okay. The part after the unlock is serialized by the
tasklet already.
Slight doubt due the comment:
local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
Makes me want to think about it harder but not now.
Another thing to check is if execlists_context_status_change still needs
the atomic notifier chain with this change.
> 0010-drm-i915-Drop-the-irqs_disabled-check.patch
LGTM.
> Revert-drm-i915-Depend-on-PREEMPT_RT.patch
Okay.
And finally for this very patch (the thread I am replying to):
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
>
> and you could view them from
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches?h=v5.17-rc6-rt10-patches
>
>> Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any arch,
>> that something more is not yet ready?
>
> Correct. Looking at what I have queued for the next merge window I have
> less than 20 patches (excluding i915 and printk) before ARCH_SUPPORTS_RT
> can be enabled for x86-64.
>
>> Regards,
>>
>> Tvrtko
>
> Sebastian
next prev parent reply other threads:[~2022-03-01 14:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 18:59 [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT Sebastian Andrzej Siewior
2022-02-16 3:16 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-02-16 7:16 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-02-25 23:03 ` [Intel-gfx] [PATCH] " Sebastian Andrzej Siewior
2022-02-28 10:10 ` Tvrtko Ursulin
2022-02-28 10:35 ` Sebastian Andrzej Siewior
2022-03-01 14:27 ` Tvrtko Ursulin [this message]
2022-03-01 15:13 ` Sebastian Andrzej Siewior
2022-03-02 11:42 ` Tvrtko Ursulin
2022-03-02 12:32 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42282635-50a8-505f-0bd5-5aef9945e3d3@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=airlied@linux.ie \
--cc=bigeasy@linutronix.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox