From: liuxinliang <z.liuxinliang@hisilicon.com>
To: John Stultz <john.stultz@linaro.org>,
lkml <linux-kernel@vger.kernel.org>
Cc: Rongrong Zou <zourongrong@gmail.com>,
Xinwei Kong <kong.kongxinwei@hisilicon.com>,
Chen Feng <puck.chen@hisilicon.com>,
David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Sean Paul <seanpaul@chromium.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC][PATCH] drm: kirin: Add a mutex to avoid fb initialization race
Date: Fri, 24 Feb 2017 09:55:47 +0800 [thread overview]
Message-ID: <58AF92A3.2040200@hisilicon.com> (raw)
In-Reply-To: <1487811383-6915-1-git-send-email-john.stultz@linaro.org>
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
>
WARNING: multiple messages have this Message-ID (diff)
From: liuxinliang <z.liuxinliang@hisilicon.com>
To: John Stultz <john.stultz@linaro.org>,
lkml <linux-kernel@vger.kernel.org>
Cc: Rongrong Zou <zourongrong@gmail.com>,
Xinwei Kong <kong.kongxinwei@hisilicon.com>,
Chen Feng <puck.chen@hisilicon.com>,
"David Airlie" <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Sean Paul <seanpaul@chromium.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [RFC][PATCH] drm: kirin: Add a mutex to avoid fb initialization race
Date: Fri, 24 Feb 2017 09:55:47 +0800 [thread overview]
Message-ID: <58AF92A3.2040200@hisilicon.com> (raw)
In-Reply-To: <1487811383-6915-1-git-send-email-john.stultz@linaro.org>
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
>
next prev parent reply other threads:[~2017-02-24 1:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 0:56 [RFC][PATCH] drm: kirin: Add a mutex to avoid fb initialization race John Stultz
2017-02-23 0:56 ` John Stultz
2017-02-24 1:55 ` liuxinliang [this message]
2017-02-24 1:55 ` liuxinliang
2017-02-24 21:33 ` John Stultz
2017-02-24 21:33 ` John Stultz
2017-02-25 1:22 ` liuxinliang
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=58AF92A3.2040200@hisilicon.com \
--to=z.liuxinliang@hisilicon.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=john.stultz@linaro.org \
--cc=kong.kongxinwei@hisilicon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=puck.chen@hisilicon.com \
--cc=seanpaul@chromium.org \
--cc=zourongrong@gmail.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 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.