| Message ID | 20230104083110.736377-1-wenst@chromium.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | remoteproc/mtk_scp: Move clk ops outside send_lock | expand |
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>
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
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.
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; }
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(-)