public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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