From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Dariusz Marcinkiewicz <darekm@google.com>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCHv8 2/2] drm: tda998x: set the connector info
Date: Thu, 17 Oct 2019 10:44:13 +0100 [thread overview]
Message-ID: <20191017094413.GB25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <CALFZZQEL_YFEJWw557p-uV14APthSoTn61tY59yXZEPioxPSfw@mail.gmail.com>
On Thu, Oct 17, 2019 at 11:26:38AM +0200, Dariusz Marcinkiewicz wrote:
> Hi Russel.
>
> On Wed, Oct 16, 2019 at 6:22 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> ...
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1337,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
> > > struct drm_device *drm)
> > > {
> > > struct drm_connector *connector = &priv->connector;
> > > + struct cec_connector_info conn_info;
> > > + struct cec_notifier *notifier;
> > > int ret;
> > >
> > > connector->interlace_allowed = 1;
> > > @@ -1353,6 +1355,17 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
> > > if (ret)
> > > return ret;
> > >
> > > + cec_fill_conn_info_from_drm(&conn_info, connector);
> > > +
> > > + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> > > + NULL, &conn_info);
> > > + if (!notifier)
> > > + return -ENOMEM;
> > > +
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + priv->cec_notify = notifier;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > As per my previous comments, this is a single-copy atomic operation.
> > Either priv->cec_notify is set or it isn't; there is no intermediate
> > value. It can't be set to a value until cec_notifier_conn_register()
> > has completed. So the lock doesn't help.
> >
> ....
> > > +
> > > drm_connector_attach_encoder(&priv->connector,
> > > priv->bridge.encoder);
> > >
> > > @@ -1372,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge *bridge)
> ...
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + cec_notifier_conn_unregister(priv->cec_notify);
> > > + priv->cec_notify = NULL;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > This is the only case where the lock makes sense - to ensure that any
> > of the cec_notifier_set_phys_addr*() functions aren't called
> > concurrently with it. However, there's no locking around the instance
> > in tda998x_connector_get_modes(), so have you ensured that that
> > function can't be called concurrently?
> >
> I assumed that tda998x_connector_get_modes does not need to be
> synchronized as it belongs to the connector that gets cleaned up here.
> But, on a closer look, I don't think that this assumption necessarily
> holds.
>
> If this patch is to be merged, I can send an update that:
> - strips locking from tda998x_connector_init,
> - in tda998x_connector_get_modes calls cec_notifier* with the lock held.
Okay, I'd suggest a comment in the code describing precisely what the
lock is doing would be a good idea, as it may not be obvious in the
future.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Dariusz Marcinkiewicz <darekm@google.com>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel@ffwll.ch>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCHv8 2/2] drm: tda998x: set the connector info
Date: Thu, 17 Oct 2019 10:44:13 +0100 [thread overview]
Message-ID: <20191017094413.GB25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <CALFZZQEL_YFEJWw557p-uV14APthSoTn61tY59yXZEPioxPSfw@mail.gmail.com>
On Thu, Oct 17, 2019 at 11:26:38AM +0200, Dariusz Marcinkiewicz wrote:
> Hi Russel.
>
> On Wed, Oct 16, 2019 at 6:22 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> ...
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1337,6 +1337,8 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
> > > struct drm_device *drm)
> > > {
> > > struct drm_connector *connector = &priv->connector;
> > > + struct cec_connector_info conn_info;
> > > + struct cec_notifier *notifier;
> > > int ret;
> > >
> > > connector->interlace_allowed = 1;
> > > @@ -1353,6 +1355,17 @@ static int tda998x_connector_init(struct tda998x_priv *priv,
> > > if (ret)
> > > return ret;
> > >
> > > + cec_fill_conn_info_from_drm(&conn_info, connector);
> > > +
> > > + notifier = cec_notifier_conn_register(priv->cec_glue.parent,
> > > + NULL, &conn_info);
> > > + if (!notifier)
> > > + return -ENOMEM;
> > > +
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + priv->cec_notify = notifier;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > As per my previous comments, this is a single-copy atomic operation.
> > Either priv->cec_notify is set or it isn't; there is no intermediate
> > value. It can't be set to a value until cec_notifier_conn_register()
> > has completed. So the lock doesn't help.
> >
> ....
> > > +
> > > drm_connector_attach_encoder(&priv->connector,
> > > priv->bridge.encoder);
> > >
> > > @@ -1372,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge *bridge)
> ...
> > > + mutex_lock(&priv->cec_notify_mutex);
> > > + cec_notifier_conn_unregister(priv->cec_notify);
> > > + priv->cec_notify = NULL;
> > > + mutex_unlock(&priv->cec_notify_mutex);
> >
> > This is the only case where the lock makes sense - to ensure that any
> > of the cec_notifier_set_phys_addr*() functions aren't called
> > concurrently with it. However, there's no locking around the instance
> > in tda998x_connector_get_modes(), so have you ensured that that
> > function can't be called concurrently?
> >
> I assumed that tda998x_connector_get_modes does not need to be
> synchronized as it belongs to the connector that gets cleaned up here.
> But, on a closer look, I don't think that this assumption necessarily
> holds.
>
> If this patch is to be merged, I can send an update that:
> - strips locking from tda998x_connector_init,
> - in tda998x_connector_get_modes calls cec_notifier* with the lock held.
Okay, I'd suggest a comment in the code describing precisely what the
lock is doing would be a good idea, as it may not be obvious in the
future.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2019-10-17 9:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 13:39 [PATCHv8 0/2] drm: tda998x: use cec_notifier_conn_(un)register Hans Verkuil
2019-10-16 13:39 ` Hans Verkuil
2019-10-16 13:39 ` [PATCHv8 1/2] " Hans Verkuil
2019-10-16 13:39 ` Hans Verkuil
2019-10-16 16:14 ` Russell King - ARM Linux admin
2019-10-16 16:14 ` Russell King - ARM Linux admin
2019-10-17 7:03 ` Hans Verkuil
2019-10-17 7:03 ` Hans Verkuil
2019-10-17 7:29 ` Hans Verkuil
2019-10-17 7:29 ` Hans Verkuil
2019-10-17 9:27 ` Dariusz Marcinkiewicz
2019-10-17 9:27 ` Dariusz Marcinkiewicz
2019-10-16 13:39 ` [PATCHv8 2/2] drm: tda998x: set the connector info Hans Verkuil
2019-10-16 13:39 ` Hans Verkuil
2019-10-16 16:22 ` Russell King - ARM Linux admin
2019-10-16 16:22 ` Russell King - ARM Linux admin
2019-10-17 9:26 ` Dariusz Marcinkiewicz
2019-10-17 9:26 ` Dariusz Marcinkiewicz
2019-10-17 9:44 ` Russell King - ARM Linux admin [this message]
2019-10-17 9:44 ` Russell King - ARM Linux admin
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=20191017094413.GB25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=darekm@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.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.