[Intel-gfx] [PATCH v3 06/10] drm/fb-helper: Support deferred setup

[Daniel Vetter]

On Wed, Mar 22, 2017 at 10:06 PM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
>> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
> [...]
>> > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> [...]
>> > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>> >  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
>> >  {
>> >     struct drm_device *dev = fb_helper->dev;
>> > +   unsigned int width, height;
>> >     int err = 0;
>> >
>> >     if (!drm_fbdev_emulation)
>> >             return 0;
>> >
>> > +   if (fb_helper->deferred_setup)
>> > +           return drm_fb_helper_initial_config(fb_helper,
>> > +                                               fb_helper->preferred_bpp);
>>
>> I think this must be moved under the protection of ->lock, you might race
>> otherwise (e.g. hpd vs. userspace forcing a re-probe, both noticing the
>> change).
>
> I think I had originally put this under the lock only to see that result
> in a deadlock. I can't quite remember why that was, but testing shows
> that this still happens. It's getting rather late, so I'll have to defer
> tracking this down to tomorrow.

initial_config also grabs your new lock, which means you'd need more
static _unlocked variants to make it work. I didn't see any other
obvious problem this would cause.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch