Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tvrtko Ursulin <tursulin@ursulin.net>
Subject: Re: [PATCH v3 0/8] drm/i915: PREEMPT_RT related fixups.
Date: Fri, 4 Oct 2024 12:44:48 +0200	[thread overview]
Message-ID: <20241004104448.as7iuUly@linutronix.de> (raw)
In-Reply-To: <Zv-wTDujdFuH_wIQ@intel.com>

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
> platform we're dealing with.
> 
> We've tried to mitigate some of the worst issues by
> trying to order the register writes more carefully,
> but some of the ordering constraints (eg. scalers vs.
> DDB) are more or less in conflict with each other
> so making it 100% safe seems impossible.

So based on what you are saying, this _has_ to happen with disabled
interrupts.

> > 
> > Is this something that affects all i915 based HW or only old ones? As
> > far as I remember, there is a register lock which is only required on
> > older HW.
> 
> Currently it affects everything. There is a new double buffer
> latching inhibit bit on some of the very latest platforms that
> we could probably use to make things more safe if vblank evasion
> fails, but we've not hooked that up. But vblank evasion would still
> be necessary at least for cursor updates since those are
> done as mailbox style updates (ie. multiple updates per frame)
> and there is no way to guarantee forward progress without vblank
> evasion.

This sounds sad. Especially since the delay is at 100us.

> Register access locks aren't relevant here, and most
> register accesses in the vblank evade critical section
> are lockless anyway. The locks were too expensive and we
> determined that we an safely use lockless accesses here.

The register lock question was only an example of something that is not
required on newish hardware. Also disabling interrupts within in patch
1, 2 would require to make uncore:lock a raw_spinlock_t since it is
acquire there.

What do suggest as in how do we move forward? In terms of testing, I
have here an i7 sandy bridge with embedded GPU.

Sebastian

      reply	other threads:[~2024-10-04 10:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 12:57 [PATCH v3 0/8] drm/i915: PREEMPT_RT related fixups Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 1/8] drm/i915: Use preempt_disable/enable_rt() where recommended Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 2/8] drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 3/8] drm/i915: Don't check for atomic context on PREEMPT_RT Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 4/8] drm/i915: Disable tracing points " Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 5/8] drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock() Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 6/8] drm/i915: Drop the irqs_disabled() check Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 7/8] drm/i915/guc: Consider also RCU depth in busy loop Sebastian Andrzej Siewior
2024-06-28 12:58 ` [PATCH v3 8/8] Revert "drm/i915: Depend on !PREEMPT_RT." Sebastian Andrzej Siewior
2024-06-28 13:35 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: PREEMPT_RT related fixups. (rev12) Patchwork
2024-06-28 13:35 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-06-28 13:43 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-06-28 14:03   ` Saarinen, Jani
2024-10-02 16:25 ` [PATCH v3 0/8] drm/i915: PREEMPT_RT related fixups Sebastian Andrzej Siewior
2024-10-02 16:58   ` Ville Syrjälä
2024-10-04  6:49     ` Sebastian Andrzej Siewior
2024-10-04  8:31       ` Ville Syrjälä
2024-10-04  8:45         ` Sebastian Andrzej Siewior
2024-10-04  9:07           ` Ville Syrjälä
2024-10-04 10:44             ` Sebastian Andrzej Siewior [this message]

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=20241004104448.as7iuUly@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tursulin@ursulin.net \
    --cc=ville.syrjala@linux.intel.com \
    /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