This splits the previous v7.2 patch (1) into two parts: one that replaces cec_notifier_get/put by cec_notifier_conn_(un)register, and one that sets the connector info.
That second patch moves the CEC notifier code to tda998x_bridge_detach, but Laurent is making changes in that area and prefers that this isn't implemented yet.
But the replacement of the cec_notifier_get/put functions is something that needs to be finished for v5.5.
By splitting this patch up I can merge the first half, but delay the second half. This tda driver just won't be able to report the connector information in the meantime.
Regards,
Hans
(1) https://patchwork.linuxtv.org/patch/58464/
Dariusz Marcinkiewicz (2): drm: tda998x: use cec_notifier_conn_(un)register drm: tda998x: set the connector info
drivers/gpu/drm/i2c/tda998x_drv.c | 38 ++++++++++++++++++++++--------- 1 file changed, 27 insertions(+), 11 deletions(-)
From: Dariusz Marcinkiewicz darekm@google.com
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl --- drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 84c6d4c91c65..8262b44b776e 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -82,6 +82,9 @@ struct tda998x_priv { u8 audio_port_enable[AUDIO_ROUTE_NUM]; struct tda9950_glue cec_glue; struct gpio_desc *calib; + + /* protect cec_notify */ + struct mutex cec_notify_mutex; struct cec_notifier *cec_notify; };
@@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data) tda998x_edid_delay_start(priv); } else { schedule_work(&priv->detect_work); - cec_notifier_set_phys_addr(priv->cec_notify, - CEC_PHYS_ADDR_INVALID); + + mutex_lock(&priv->cec_notify_mutex); + cec_notifier_phys_addr_invalidate( + priv->cec_notify); + mutex_unlock(&priv->cec_notify_mutex); }
handled = true; @@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify) - cec_notifier_put(priv->cec_notify); + mutex_lock(&priv->cec_notify_mutex); + cec_notifier_conn_unregister(priv->cec_notify); + priv->cec_notify = NULL; + mutex_unlock(&priv->cec_notify_mutex); }
static int tda998x_create(struct device *dev) @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev) mutex_init(&priv->mutex); /* protect the page access */ mutex_init(&priv->audio_mutex); /* protect access from audio thread */ mutex_init(&priv->edid_mutex); + mutex_init(&priv->cec_notify_mutex); INIT_LIST_HEAD(&priv->bridge.list); init_waitqueue_head(&priv->edid_delay_waitq); timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0); @@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev) cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD); }
- priv->cec_notify = cec_notifier_get(dev); + mutex_lock(&priv->cec_notify_mutex); + priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL); + mutex_unlock(&priv->cec_notify_mutex); if (!priv->cec_notify) { ret = -ENOMEM; goto fail;
On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
From: Dariusz Marcinkiewicz darekm@google.com
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl
Please explain in detail what this mutex actually achieves.
drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 84c6d4c91c65..8262b44b776e 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -82,6 +82,9 @@ struct tda998x_priv { u8 audio_port_enable[AUDIO_ROUTE_NUM]; struct tda9950_glue cec_glue; struct gpio_desc *calib;
- /* protect cec_notify */
- struct mutex cec_notify_mutex; struct cec_notifier *cec_notify;
};
@@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data) tda998x_edid_delay_start(priv); } else { schedule_work(&priv->detect_work);
cec_notifier_set_phys_addr(priv->cec_notify,CEC_PHYS_ADDR_INVALID);
mutex_lock(&priv->cec_notify_mutex);cec_notifier_phys_addr_invalidate(priv->cec_notify);mutex_unlock(&priv->cec_notify_mutex); } handled = true;@@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify)
cec_notifier_put(priv->cec_notify);
- mutex_lock(&priv->cec_notify_mutex);
- cec_notifier_conn_unregister(priv->cec_notify);
- priv->cec_notify = NULL;
- mutex_unlock(&priv->cec_notify_mutex);
By the time we get here:
1) The interrupt has been freed (which is a synchronous operation) tda998x_irq_thread() can't be called and can't be running, and therefore cec_notifier_phys_addr_invalidate() also can't be called or be running. 2) You don't touch the cec_notifier_set_phys_addr_from_edid() site; if there's any case that _might_ possibly conflict, it is that one. 3) tda998x_destroy() and tda998x_create() can't be called concurrently in any case; the driver model guarantees that ->probe and ->remove for the same device are serialised.
}
static int tda998x_create(struct device *dev) @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev) mutex_init(&priv->mutex); /* protect the page access */ mutex_init(&priv->audio_mutex); /* protect access from audio thread */ mutex_init(&priv->edid_mutex);
- mutex_init(&priv->cec_notify_mutex); INIT_LIST_HEAD(&priv->bridge.list); init_waitqueue_head(&priv->edid_delay_waitq); timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
@@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev) cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD); }
- priv->cec_notify = cec_notifier_get(dev);
- mutex_lock(&priv->cec_notify_mutex);
- priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
- mutex_unlock(&priv->cec_notify_mutex);
and:
4) priv->cec_notify will be NULL here until such time that cec_notifier_conn_register() has returned. If the mutex is trying to protect something, it's very unclear what it is.
Trying to guess what it's protecting against:
- Is it protecting against NULL priv->cec_notify? No, because it can be NULL just before we take the lock. - Is it protecting the internals of cec_notifier_conn_register() against the other calls - no, because priv->cec_notify will be NULL until the function has finished. - Is it protecting the write to priv->cec_notify? Maybe, but that doesn't need any protection - architectures are single-copy atomic, which means that a pointer is either written or it is not written. Therefore, it will either be NULL (the state before the call is made) or it will be set correctly (after the call has completed.)
So, all in all, I don't see what this lock is doing, and I think it should be removed.
If it's necessary for a future change (which may or may not be merged) then the lock should be part of that future change, because the change proposed by this patch certainly does not need it.
Thanks.
On 10/16/19 6:14 PM, Russell King - ARM Linux admin wrote:
On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
From: Dariusz Marcinkiewicz darekm@google.com
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl
Please explain in detail what this mutex actually achieves.
Dariusz, since you're the author, can you reply to Russell?
If this is going to be a delaying factor, then I'll post a new version without the mutex that just replaces the cec_notifier API.
Regards,
Hans
drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 84c6d4c91c65..8262b44b776e 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -82,6 +82,9 @@ struct tda998x_priv { u8 audio_port_enable[AUDIO_ROUTE_NUM]; struct tda9950_glue cec_glue; struct gpio_desc *calib;
- /* protect cec_notify */
- struct mutex cec_notify_mutex; struct cec_notifier *cec_notify;
};
@@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data) tda998x_edid_delay_start(priv); } else { schedule_work(&priv->detect_work);
cec_notifier_set_phys_addr(priv->cec_notify,CEC_PHYS_ADDR_INVALID);
mutex_lock(&priv->cec_notify_mutex);cec_notifier_phys_addr_invalidate(priv->cec_notify);mutex_unlock(&priv->cec_notify_mutex); } handled = true;@@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify)
cec_notifier_put(priv->cec_notify);
- mutex_lock(&priv->cec_notify_mutex);
- cec_notifier_conn_unregister(priv->cec_notify);
- priv->cec_notify = NULL;
- mutex_unlock(&priv->cec_notify_mutex);
By the time we get here:
- The interrupt has been freed (which is a synchronous operation) tda998x_irq_thread() can't be called and can't be running, and therefore cec_notifier_phys_addr_invalidate() also can't be called or be running.
- You don't touch the cec_notifier_set_phys_addr_from_edid() site; if there's any case that _might_ possibly conflict, it is that one.
- tda998x_destroy() and tda998x_create() can't be called concurrently in any case; the driver model guarantees that ->probe and ->remove for the same device are serialised.
}
static int tda998x_create(struct device *dev) @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev) mutex_init(&priv->mutex); /* protect the page access */ mutex_init(&priv->audio_mutex); /* protect access from audio thread */ mutex_init(&priv->edid_mutex);
- mutex_init(&priv->cec_notify_mutex); INIT_LIST_HEAD(&priv->bridge.list); init_waitqueue_head(&priv->edid_delay_waitq); timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
@@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev) cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD); }
- priv->cec_notify = cec_notifier_get(dev);
- mutex_lock(&priv->cec_notify_mutex);
- priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
- mutex_unlock(&priv->cec_notify_mutex);
and:
- priv->cec_notify will be NULL here until such time that cec_notifier_conn_register() has returned. If the mutex is trying to protect something, it's very unclear what it is.
Trying to guess what it's protecting against:
- Is it protecting against NULL priv->cec_notify? No, because it can be NULL just before we take the lock.
- Is it protecting the internals of cec_notifier_conn_register() against the other calls - no, because priv->cec_notify will be NULL until the function has finished.
- Is it protecting the write to priv->cec_notify? Maybe, but that doesn't need any protection - architectures are single-copy atomic, which means that a pointer is either written or it is not written. Therefore, it will either be NULL (the state before the call is made) or it will be set correctly (after the call has completed.)
So, all in all, I don't see what this lock is doing, and I think it should be removed.
If it's necessary for a future change (which may or may not be merged) then the lock should be part of that future change, because the change proposed by this patch certainly does not need it.
Thanks.
On 10/17/19 9:03 AM, Hans Verkuil wrote:
On 10/16/19 6:14 PM, Russell King - ARM Linux admin wrote:
On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
From: Dariusz Marcinkiewicz darekm@google.com
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl
Please explain in detail what this mutex actually achieves.
Dariusz, since you're the author, can you reply to Russell?
If this is going to be a delaying factor, then I'll post a new version without the mutex that just replaces the cec_notifier API.
I decided to post a v9, moving the mutex to the second patch, which should make the first patch acceptable to everyone for v5.5.
Regards,
Hans
Regards,
Hans
drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 84c6d4c91c65..8262b44b776e 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -82,6 +82,9 @@ struct tda998x_priv { u8 audio_port_enable[AUDIO_ROUTE_NUM]; struct tda9950_glue cec_glue; struct gpio_desc *calib;
- /* protect cec_notify */
- struct mutex cec_notify_mutex; struct cec_notifier *cec_notify;
};
@@ -805,8 +808,11 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data) tda998x_edid_delay_start(priv); } else { schedule_work(&priv->detect_work);
cec_notifier_set_phys_addr(priv->cec_notify,CEC_PHYS_ADDR_INVALID);
mutex_lock(&priv->cec_notify_mutex);cec_notifier_phys_addr_invalidate(priv->cec_notify);mutex_unlock(&priv->cec_notify_mutex); } handled = true;@@ -1790,8 +1796,10 @@ static void tda998x_destroy(struct device *dev)
i2c_unregister_device(priv->cec);
- if (priv->cec_notify)
cec_notifier_put(priv->cec_notify);
- mutex_lock(&priv->cec_notify_mutex);
- cec_notifier_conn_unregister(priv->cec_notify);
- priv->cec_notify = NULL;
- mutex_unlock(&priv->cec_notify_mutex);
By the time we get here:
- The interrupt has been freed (which is a synchronous operation) tda998x_irq_thread() can't be called and can't be running, and therefore cec_notifier_phys_addr_invalidate() also can't be called or be running.
- You don't touch the cec_notifier_set_phys_addr_from_edid() site; if there's any case that _might_ possibly conflict, it is that one.
- tda998x_destroy() and tda998x_create() can't be called concurrently in any case; the driver model guarantees that ->probe and ->remove for the same device are serialised.
}
static int tda998x_create(struct device *dev) @@ -1812,6 +1820,7 @@ static int tda998x_create(struct device *dev) mutex_init(&priv->mutex); /* protect the page access */ mutex_init(&priv->audio_mutex); /* protect access from audio thread */ mutex_init(&priv->edid_mutex);
- mutex_init(&priv->cec_notify_mutex); INIT_LIST_HEAD(&priv->bridge.list); init_waitqueue_head(&priv->edid_delay_waitq); timer_setup(&priv->edid_delay_timer, tda998x_edid_delay_done, 0);
@@ -1916,7 +1925,9 @@ static int tda998x_create(struct device *dev) cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD); }
- priv->cec_notify = cec_notifier_get(dev);
- mutex_lock(&priv->cec_notify_mutex);
- priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL);
- mutex_unlock(&priv->cec_notify_mutex);
and:
- priv->cec_notify will be NULL here until such time that cec_notifier_conn_register() has returned. If the mutex is trying to protect something, it's very unclear what it is.
Trying to guess what it's protecting against:
- Is it protecting against NULL priv->cec_notify? No, because it can be NULL just before we take the lock.
- Is it protecting the internals of cec_notifier_conn_register() against the other calls - no, because priv->cec_notify will be NULL until the function has finished.
- Is it protecting the write to priv->cec_notify? Maybe, but that doesn't need any protection - architectures are single-copy atomic, which means that a pointer is either written or it is not written. Therefore, it will either be NULL (the state before the call is made) or it will be set correctly (after the call has completed.)
So, all in all, I don't see what this lock is doing, and I think it should be removed.
If it's necessary for a future change (which may or may not be merged) then the lock should be part of that future change, because the change proposed by this patch certainly does not need it.
Thanks.
On Wed, Oct 16, 2019 at 6:14 PM Russell King - ARM Linux admin linux@armlinux.org.uk wrote:
On Wed, Oct 16, 2019 at 03:39:15PM +0200, Hans Verkuil wrote:
From: Dariusz Marcinkiewicz darekm@google.com
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector.
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl
Please explain in detail what this mutex actually achieves.
....
So, all in all, I don't see what this lock is doing, and I think it should be removed.
If it's necessary for a future change (which may or may not be merged) then the lock should be part of that future change, because the change proposed by this patch certainly does not need it.
Yes, with the change being split into 2 patches like that, the mutex is not needed here.
Thank you.
From: Dariusz Marcinkiewicz darekm@google.com
Fill in the cec_connector_info when calling cec_notifier_conn_register().
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Tested-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl --- drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 8262b44b776e..b0620842fa3a 100644 --- 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); + drm_connector_attach_encoder(&priv->connector, priv->bridge.encoder);
@@ -1372,6 +1385,11 @@ static void tda998x_bridge_detach(struct drm_bridge *bridge) { struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
+ mutex_lock(&priv->cec_notify_mutex); + cec_notifier_conn_unregister(priv->cec_notify); + priv->cec_notify = NULL; + mutex_unlock(&priv->cec_notify_mutex); + drm_connector_cleanup(&priv->connector); }
@@ -1795,11 +1813,6 @@ static void tda998x_destroy(struct device *dev) cancel_work_sync(&priv->detect_work);
i2c_unregister_device(priv->cec); - - mutex_lock(&priv->cec_notify_mutex); - cec_notifier_conn_unregister(priv->cec_notify); - priv->cec_notify = NULL; - mutex_unlock(&priv->cec_notify_mutex); }
static int tda998x_create(struct device *dev) @@ -1925,14 +1938,6 @@ static int tda998x_create(struct device *dev) cec_write(priv, REG_CEC_RXSHPDINTENA, CEC_RXSHPDLEV_HPD); }
- mutex_lock(&priv->cec_notify_mutex); - priv->cec_notify = cec_notifier_conn_register(dev, NULL, NULL); - mutex_unlock(&priv->cec_notify_mutex); - if (!priv->cec_notify) { - ret = -ENOMEM; - goto fail; - } - priv->cec_glue.parent = dev; priv->cec_glue.data = priv; priv->cec_glue.init = tda998x_cec_hook_init;
On Wed, Oct 16, 2019 at 03:39:16PM +0200, Hans Verkuil wrote:
From: Dariusz Marcinkiewicz darekm@google.com
Fill in the cec_connector_info when calling cec_notifier_conn_register().
Signed-off-by: Dariusz Marcinkiewicz darekm@google.com Tested-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl
drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 8262b44b776e..b0620842fa3a 100644 --- 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) { struct tda998x_priv *priv = bridge_to_tda998x_priv(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?
Thanks.
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.
Thank you!
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.
dri-devel@lists.freedesktop.org
-
Dariusz Marcinkiewicz -
Hans Verkuil -
Russell King - ARM Linux admin