[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210430173646.00007de1@Huawei.com>
Date: Fri, 30 Apr 2021 17:36:46 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
CC: <linuxarm@...wei.com>, <mauro.chehab@...wei.com>,
"Lad, Prabhakar" <prabhakar.csengg@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
<linux-kernel@...r.kernel.org>, <linux-media@...r.kernel.org>
Subject: Re: [PATCH v4 14/79] media: am437x: fix pm_runtime_get_sync() usage
count
On Wed, 28 Apr 2021 16:51:35 +0200
Mauro Carvalho Chehab <mchehab+huawei@...nel.org> wrote:
> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> Replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
>
> While here, ensure that the driver will check if PM runtime
> resumed at vpfe_initialize_device().
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
resume and suspend carrying regardless needs a comment I think.
(see below)
> ---
> drivers/media/platform/am437x/am437x-vpfe.c | 22 +++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c b/drivers/media/platform/am437x/am437x-vpfe.c
> index 6cdc77dda0e4..bced526f30f2 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -1021,7 +1021,9 @@ static int vpfe_initialize_device(struct vpfe_device *vpfe)
> if (ret)
> return ret;
>
> - pm_runtime_get_sync(vpfe->pdev);
> + ret = pm_runtime_resume_and_get(vpfe->pdev);
> + if (ret < 0)
> + return ret;
>
> vpfe_config_enable(&vpfe->ccdc, 1);
>
> @@ -2443,7 +2445,11 @@ static int vpfe_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
>
> /* for now just enable it here instead of waiting for the open */
> - pm_runtime_get_sync(&pdev->dev);
> + ret = pm_runtime_resume_and_get(&pdev->dev);
> + if (ret < 0) {
> + vpfe_err(vpfe, "Unable to resume device.\n");
> + goto probe_out_v4l2_unregister;
> + }
>
> vpfe_ccdc_config_defaults(ccdc);
>
> @@ -2527,10 +2533,11 @@ static int vpfe_suspend(struct device *dev)
> {
> struct vpfe_device *vpfe = dev_get_drvdata(dev);
> struct vpfe_ccdc *ccdc = &vpfe->ccdc;
> + int ret;
>
> /* only do full suspend if streaming has started */
> if (vb2_start_streaming_called(&vpfe->buffer_queue)) {
> - pm_runtime_get_sync(dev);
> + ret = pm_runtime_resume_and_get(dev);
Carrying on when you know the resume failed, seems interesting enough to
deserve a comment in the code. Not sure you can usefully do anything
but it seems likely a lot of the calls that follow will fail.
> vpfe_config_enable(ccdc, 1);
>
> /* Save VPFE context */
> @@ -2541,7 +2548,8 @@ static int vpfe_suspend(struct device *dev)
> vpfe_config_enable(ccdc, 0);
>
> /* Disable both master and slave clock */
> - pm_runtime_put_sync(dev);
> + if (ret >= 0)
> + pm_runtime_put_sync(dev);
> }
>
> /* Select sleep pin state */
> @@ -2583,18 +2591,20 @@ static int vpfe_resume(struct device *dev)
> {
> struct vpfe_device *vpfe = dev_get_drvdata(dev);
> struct vpfe_ccdc *ccdc = &vpfe->ccdc;
> + int ret;
>
> /* only do full resume if streaming has started */
> if (vb2_start_streaming_called(&vpfe->buffer_queue)) {
> /* Enable both master and slave clock */
> - pm_runtime_get_sync(dev);
> + ret = pm_runtime_resume_and_get(dev);
> vpfe_config_enable(ccdc, 1);
>
> /* Restore VPFE context */
> vpfe_restore_context(ccdc);
>
> vpfe_config_enable(ccdc, 0);
> - pm_runtime_put_sync(dev);
> + if (ret >= 0)
> + pm_runtime_put_sync(dev);
> }
>
> /* Select default pin state */
Powered by blists - more mailing lists