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 <ch...@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
