drivers/remoteproc/mtk_scp_ipi.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
Clocks are properly reference counted and do not need to be inside the
lock range.
Right now this triggers a false-positive lockdep warning on MT8192 based
Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg
sub-device, the (actual) cros-ec I2C adapter registration, I2C client
(not on cros-ec) probe doing i2c transfers and enabling clocks.
This is a false positive because the cros-ec-rpmsg under mtk-scp does
not have an I2C adapter, and also each I2C adapter and cros-ec instance
have their own mutex.
Move the clk operations outside of the send_lock range.
Fixes: ("63c13d61eafe remoteproc/mediatek: add SCP support for mt8183")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/remoteproc/mtk_scp_ipi.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/mtk_scp_ipi.c b/drivers/remoteproc/mtk_scp_ipi.c
index 00f041ebcde6..4c0d121c2f54 100644
--- a/drivers/remoteproc/mtk_scp_ipi.c
+++ b/drivers/remoteproc/mtk_scp_ipi.c
@@ -164,21 +164,21 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf, unsigned int len,
WARN_ON(len > sizeof(send_obj->share_buf)) || WARN_ON(!buf))
return -EINVAL;
- mutex_lock(&scp->send_lock);
-
ret = clk_prepare_enable(scp->clk);
if (ret) {
dev_err(scp->dev, "failed to enable clock\n");
- goto unlock_mutex;
+ return ret;
}
+ mutex_lock(&scp->send_lock);
+
/* Wait until SCP receives the last command */
timeout = jiffies + msecs_to_jiffies(2000);
do {
if (time_after(jiffies, timeout)) {
dev_err(scp->dev, "%s: IPI timeout!\n", __func__);
ret = -ETIMEDOUT;
- goto clock_disable;
+ goto unlock_mutex;
}
} while (readl(scp->reg_base + scp->data->host_to_scp_reg));
@@ -205,10 +205,9 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf, unsigned int len,
ret = 0;
}
-clock_disable:
- clk_disable_unprepare(scp->clk);
unlock_mutex:
mutex_unlock(&scp->send_lock);
+ clk_disable_unprepare(scp->clk);
return ret;
}
--
2.39.0.314.g84b9a713c41-goog
On Wed, Jan 4, 2023 at 4:31 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > Clocks are properly reference counted and do not need to be inside the > lock range. > > Right now this triggers a false-positive lockdep warning on MT8192 based > Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg > sub-device, the (actual) cros-ec I2C adapter registration, I2C client > (not on cros-ec) probe doing i2c transfers and enabling clocks. > > This is a false positive because the cros-ec-rpmsg under mtk-scp does > not have an I2C adapter, and also each I2C adapter and cros-ec instance > have their own mutex. > > Move the clk operations outside of the send_lock range. Well this managed to untangle the lockdep warning a bit, but it still appears. I'll keep looking into it.
On Wed, Jan 04, 2023 at 04:31:10PM +0800, Chen-Yu Tsai wrote: > Clocks are properly reference counted and do not need to be inside the > lock range. > > Right now this triggers a false-positive lockdep warning on MT8192 based > Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg > sub-device, the (actual) cros-ec I2C adapter registration, I2C client > (not on cros-ec) probe doing i2c transfers and enabling clocks. > > This is a false positive because the cros-ec-rpmsg under mtk-scp does > not have an I2C adapter, and also each I2C adapter and cros-ec instance > have their own mutex. > > Move the clk operations outside of the send_lock range. Thanks for providing such a clear explanation - it makes my job a lot easier. > > Fixes: ("63c13d61eafe remoteproc/mediatek: add SCP support for mt8183") This is the wrong format for a "Fixes:" tag. Please see Documentation/process/submitting-patches.rst for details. > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> I have fixed the above and applied this patch. Thanks, Mathieu > --- > drivers/remoteproc/mtk_scp_ipi.c | 11 +++++------ > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/remoteproc/mtk_scp_ipi.c b/drivers/remoteproc/mtk_scp_ipi.c > index 00f041ebcde6..4c0d121c2f54 100644 > --- a/drivers/remoteproc/mtk_scp_ipi.c > +++ b/drivers/remoteproc/mtk_scp_ipi.c > @@ -164,21 +164,21 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf, unsigned int len, > WARN_ON(len > sizeof(send_obj->share_buf)) || WARN_ON(!buf)) > return -EINVAL; > > - mutex_lock(&scp->send_lock); > - > ret = clk_prepare_enable(scp->clk); > if (ret) { > dev_err(scp->dev, "failed to enable clock\n"); > - goto unlock_mutex; > + return ret; > } > > + mutex_lock(&scp->send_lock); > + > /* Wait until SCP receives the last command */ > timeout = jiffies + msecs_to_jiffies(2000); > do { > if (time_after(jiffies, timeout)) { > dev_err(scp->dev, "%s: IPI timeout!\n", __func__); > ret = -ETIMEDOUT; > - goto clock_disable; > + goto unlock_mutex; > } > } while (readl(scp->reg_base + scp->data->host_to_scp_reg)); > > @@ -205,10 +205,9 @@ int scp_ipi_send(struct mtk_scp *scp, u32 id, void *buf, unsigned int len, > ret = 0; > } > > -clock_disable: > - clk_disable_unprepare(scp->clk); > unlock_mutex: > mutex_unlock(&scp->send_lock); > + clk_disable_unprepare(scp->clk); > > return ret; > } > -- > 2.39.0.314.g84b9a713c41-goog >
On Thu, Jan 5, 2023 at 6:22 AM Mathieu Poirier <mathieu.poirier@linaro.org> wrote: > > On Wed, Jan 04, 2023 at 04:31:10PM +0800, Chen-Yu Tsai wrote: > > Clocks are properly reference counted and do not need to be inside the > > lock range. > > > > Right now this triggers a false-positive lockdep warning on MT8192 based > > Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg > > sub-device, the (actual) cros-ec I2C adapter registration, I2C client > > (not on cros-ec) probe doing i2c transfers and enabling clocks. > > > > This is a false positive because the cros-ec-rpmsg under mtk-scp does > > not have an I2C adapter, and also each I2C adapter and cros-ec instance > > have their own mutex. > > > > Move the clk operations outside of the send_lock range. > > Thanks for providing such a clear explanation - it makes my job a lot easier. > > > > > Fixes: ("63c13d61eafe remoteproc/mediatek: add SCP support for mt8183") > > This is the wrong format for a "Fixes:" tag. Please see > Documentation/process/submitting-patches.rst for details. > > > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> > > I have fixed the above and applied this patch. Thanks, and sorry about the brain fart on my end. ChenYu
Il 04/01/23 09:31, Chen-Yu Tsai ha scritto: > Clocks are properly reference counted and do not need to be inside the > lock range. > > Right now this triggers a false-positive lockdep warning on MT8192 based > Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg > sub-device, the (actual) cros-ec I2C adapter registration, I2C client > (not on cros-ec) probe doing i2c transfers and enabling clocks. > > This is a false positive because the cros-ec-rpmsg under mtk-scp does > not have an I2C adapter, and also each I2C adapter and cros-ec instance > have their own mutex. > > Move the clk operations outside of the send_lock range. > > Fixes: ("63c13d61eafe remoteproc/mediatek: add SCP support for mt8183") > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Nice catch. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
© 2016 - 2024 Red Hat, Inc.