| Message ID | 1487811383-6915-1-git-send-email-john.stultz@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi John, On 2017/2/23 8:56, John Stultz wrote: > In some cases I've been seeing a race where two framebuffers > would be initialized, as kirin_fbdev_output_poll_changed() > might get called quickly in succession, resulting in the fb > initialization happening twice. This could cause the system I might understand this race. This because two places call drm_helper_hpd_irq_event might cause the race: One place is here static int kirin_drm_kms_init(struct drm_device *dev) { ... /* force detection after connectors init */ (void)drm_helper_hpd_irq_event(dev); ... } another is the adv7533 interrupt thread handler static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd) { ... if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder) drm_helper_hpd_irq_event(adv7511->connector.dev); ... } right? I don't get a better way to fix this yet , I like to put fb_lock into kirin_drm_private. And it seems hard to fix this in the core drm_helper_hpd_irq_event. -xinliang > to boot up with a blank screen. > > This patch adds a simple mutex to serialize it and seems to > avoid the race. > > Obviously I suspect this patch isn't the best solution, but > I wanted to send it out as something concrete to discuss the > bug. > > Suggestions or feedback for a better solution would be greatly > appreciated. > > Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> > Cc: Rongrong Zou <zourongrong@gmail.com> > Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> > Cc: Chen Feng <puck.chen@hisilicon.com> > Cc: David Airlie <airlied@linux.ie> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: Sean Paul <seanpaul@chromium.org> > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: John Stultz <john.stultz@linaro.org> > --- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > index ebd5f4f..80c607f 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c > @@ -50,11 +50,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev) > return 0; > } > > +static DEFINE_MUTEX(fb_lock); > #ifdef CONFIG_DRM_FBDEV_EMULATION > static void kirin_fbdev_output_poll_changed(struct drm_device *dev) > { > struct kirin_drm_private *priv = dev->dev_private; > > + mutex_lock(&fb_lock); > if (priv->fbdev) { > drm_fbdev_cma_hotplug_event(priv->fbdev); > } else { > @@ -64,6 +66,7 @@ static void kirin_fbdev_output_poll_changed(struct drm_device *dev) > if (IS_ERR(priv->fbdev)) > priv->fbdev = NULL; > } > + mutex_unlock(&fb_lock); > } > #endif >
On Thu, Feb 23, 2017 at 5:55 PM, liuxinliang <z.liuxinliang@hisilicon.com> wrote: > Hi John, > > On 2017/2/23 8:56, John Stultz wrote: >> >> In some cases I've been seeing a race where two framebuffers >> would be initialized, as kirin_fbdev_output_poll_changed() >> might get called quickly in succession, resulting in the fb >> initialization happening twice. This could cause the system > > > I might understand this race. This because two places call > drm_helper_hpd_irq_event might cause the race: > One place is here > static int kirin_drm_kms_init(struct drm_device *dev) > { > ... > /* force detection after connectors init */ > (void)drm_helper_hpd_irq_event(dev); > ... > } > > another is the adv7533 interrupt thread handler > static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd) > { > ... > if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder) > drm_helper_hpd_irq_event(adv7511->connector.dev); > ... > } > > right? > > I don't get a better way to fix this yet , I like to put fb_lock into > kirin_drm_private. Ok. I've moved the mutex to the kirin_drm_private structure. Anything else you'd like to see before I resend? thanks -john
On 2017/2/25 5:33, John Stultz wrote: > On Thu, Feb 23, 2017 at 5:55 PM, liuxinliang > <z.liuxinliang@hisilicon.com> wrote: >> Hi John, >> >> On 2017/2/23 8:56, John Stultz wrote: >>> In some cases I've been seeing a race where two framebuffers >>> would be initialized, as kirin_fbdev_output_poll_changed() >>> might get called quickly in succession, resulting in the fb >>> initialization happening twice. This could cause the system >> >> I might understand this race. This because two places call >> drm_helper_hpd_irq_event might cause the race: >> One place is here >> static int kirin_drm_kms_init(struct drm_device *dev) >> { >> ... >> /* force detection after connectors init */ >> (void)drm_helper_hpd_irq_event(dev); >> ... >> } >> >> another is the adv7533 interrupt thread handler >> static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd) >> { >> ... >> if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder) >> drm_helper_hpd_irq_event(adv7511->connector.dev); >> ... >> } >> >> right? >> >> I don't get a better way to fix this yet , I like to put fb_lock into >> kirin_drm_private. > Ok. I've moved the mutex to the kirin_drm_private structure. > > Anything else you'd like to see before I resend? Thanks, no more then. Best, -xinliang > > thanks > -john > > . >
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index ebd5f4f..80c607f 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -50,11 +50,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev) return 0; } +static DEFINE_MUTEX(fb_lock); #ifdef CONFIG_DRM_FBDEV_EMULATION static void kirin_fbdev_output_poll_changed(struct drm_device *dev) { struct kirin_drm_private *priv = dev->dev_private; + mutex_lock(&fb_lock); if (priv->fbdev) { drm_fbdev_cma_hotplug_event(priv->fbdev); } else { @@ -64,6 +66,7 @@ static void kirin_fbdev_output_poll_changed(struct drm_device *dev) if (IS_ERR(priv->fbdev)) priv->fbdev = NULL; } + mutex_unlock(&fb_lock); } #endif
In some cases I've been seeing a race where two framebuffers would be initialized, as kirin_fbdev_output_poll_changed() might get called quickly in succession, resulting in the fb initialization happening twice. This could cause the system to boot up with a blank screen. This patch adds a simple mutex to serialize it and seems to avoid the race. Obviously I suspect this patch isn't the best solution, but I wanted to send it out as something concrete to discuss the bug. Suggestions or feedback for a better solution would be greatly appreciated. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz <john.stultz@linaro.org> --- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +++ 1 file changed, 3 insertions(+)