From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock
Date: Fri, 19 Oct 2018 09:32:35 +0100 [thread overview]
Message-ID: <153993795528.19935.11751515814714096059@skylake-alporthouse-com> (raw)
In-Reply-To: <20181019082354.GU31561@phenom.ffwll.local>
Quoting Daniel Vetter (2018-10-19 09:23:54)
> On Mon, Oct 15, 2018 at 12:17:39PM +0100, Chris Wilson wrote:
> > We try to avoid a deadlock of synchronizing the async fbdev task by
> > skipping the synchronisation from the async worker, but that prevents us
> > from using an async worker for the device probe. As we have our own
> > barrier and do not rely on the global async flush, we can simply replace
> > the async task with an explicit worker.
> >
> > References: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Does this now mean that fbdev setup lags behind module load? Afaiui that
> will annoy userspace, which assumes that once the kms driver is loaded,
> fbdev works. Or at least I have vague memories of pains in this area.
I have no idea what pain you remember, I just ask wtf is fbdev.
Since we register the driver before module load completes, there's a
race window for third parties who can make that same assumption, so
what's the difference: fbdev is available as soon as it is registered
and not before.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2018-10-19 8:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 11:17 [PATCH 1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock Chris Wilson
2018-10-15 11:17 ` [PATCH 2/4] drm/i915/fbdev: Use i915/drm_i915_private consistently Chris Wilson
2018-10-15 11:17 ` [PATCH 3/4] drm/i915: Disable displays at the user's request Chris Wilson
2018-10-19 8:22 ` Daniel Vetter
2018-10-19 8:39 ` Chris Wilson
2018-11-06 17:48 ` Ville Syrjälä
2018-10-15 11:17 ` [PATCH 4/4] HAX: force i915.disable_display=1 Chris Wilson
2018-10-15 11:39 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/fbdev: Use an ordinary worker to avoid async deadlock Patchwork
2018-10-15 11:41 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-15 11:52 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-10-17 9:18 ` Patchwork
2018-10-19 8:23 ` [PATCH 1/4] " Daniel Vetter
2018-10-19 8:32 ` Chris Wilson [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=153993795528.19935.11751515814714096059@skylake-alporthouse-com \
--to=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.