linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: linuxarm@huawei.com, mauro.chehab@huawei.com,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
Date: Wed, 28 Apr 2021 09:13:02 +0200	[thread overview]
Message-ID: <20210428091302.64af1e5d@coco.lan> (raw)
In-Reply-To: <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>

Em Tue, 27 Apr 2021 13:50:44 +0200
Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:

> On 27.04.2021 11:42, Mauro Carvalho Chehab wrote:
> > Em Tue, 27 Apr 2021 11:30:55 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> >   
> >> Em Tue, 27 Apr 2021 10:18:12 +0200
> >> Sylwester Nawrocki <s.nawrocki@samsung.com> escreveu:
> >>  
> >>> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:    
> >>>> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> >>>> added pm_runtime_resume_and_get() in order to automatically handle
> >>>> dev->power.usage_count decrement on errors.
> >>>>
> >>>> Use the new API, in order to cleanup the error check logic.
> >>>>
> >>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >>>> ---
> >>>>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
> >>>>  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
> >>>>  2 files changed, 2 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> index 9f41c2e7097a..9d5841194f6b 100644
> >>>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
> >>>>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
> >>>>  	int i;
> >>>>  
> >>>> -	pm_runtime_get_sync(&pdev->dev);
> >>>> +	pm_runtime_resume_and_get(&pdev->dev);
> >>>>  
> >>>>  	gsc_unregister_m2m_device(gsc);
> >>>>  	v4l2_device_unregister(&gsc->v4l2_dev);
> >>>> @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
> >>>>  	for (i = 0; i < gsc->num_clocks; i++)
> >>>>  		clk_disable_unprepare(gsc->clock[i]);
> >>>>  
> >>>> -	pm_runtime_put_noidle(&pdev->dev);      
> >>>
> >>> If we do this then the device usage count will not get decremented
> >>> after the pm_runtime_resume_and_get() call above and after driver
> >>> unload/load cycle it will not be possible to suspend the device.
> >>> I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
> >>> works better in that case.    
> >>
> >> Good point.
> >>
> >> Actually, I don't see any reason why to call a PM resume
> >> function - either being pm_runtime_get_sync() or
> >> pm_runtime_resume_and_get().
> >>
> >> The code there could simply be:
> >>
> >>     static int gsc_remove(struct platform_device *pdev)
> >>     {
> >>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
> >>         int i;
> >>
> >>         gsc_unregister_m2m_device(gsc);
> >>         v4l2_device_unregister(&gsc->v4l2_dev);
> >>
> >>         vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> >>         for (i = 0; i < gsc->num_clocks; i++)
> >>                 clk_disable_unprepare(gsc->clock[i]);
> >>
> >>         pm_runtime_disable(&pdev->dev);
> >>
> >>         dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
> >>         return 0;
> >>     }
> >>
> >> Eventually also adding:
> >> 	pm_runtime_suspended(&pdev->dev);  
> > 
> > In time: I actually meant:
> > 
> > 	pm_runtime_set_suspended(&pdev->dev);
> > 
> > but after double-checking the PM runtime code, it sounds to me that
> > just calling pm_runtime_disable() would be enough. Not 100% sure
> > here. Btw, some media drivers call it after pm_runtime_disable(),
> > while others don't do.  
> 
> I think if the device is brought into suspended state (e.g. by
> disabling clocks as above) the pm_runtime_set_suspended() call
> should be there. IOW a following sequence: 
> 
> 	pm_runtime_disable(dev);
> 	if (!pm_runtime_status_suspended(dev))
> 		/* put device into suspended state (disable clocks, 
> 		  voltage regulators, assert GPIOs, etc. */
> 	pm_runtime_set_suspended(dev);

Not sure if this would work, as the clock framework would try
to do things like calling clk_pm_runtime_put().

Perhaps an alternative would be to just return an error if it
can't resume PM runtime, e. g.:

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..d47d02c75484 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1208,9 +1208,11 @@ static int gsc_probe(struct platform_device *pdev)
 static int gsc_remove(struct platform_device *pdev)
 {
        struct gsc_dev *gsc = platform_get_drvdata(pdev);
-       int i;
+       int ret, i;
 
-       pm_runtime_get_sync(&pdev->dev);
+       ret = pm_runtime_resume_and_get(&pdev->dev);
+       if (ret < 0)
+               return ret;
 
        gsc_unregister_m2m_device(gsc);
        v4l2_device_unregister(&gsc->v4l2_dev);


Thanks,
Mauro

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-28  7:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1619191723.git.mchehab+huawei@kernel.org>
2021-04-24  6:44 ` [PATCH 01/78] media: atmel: properly get pm_runtime Mauro Carvalho Chehab
2021-04-24  9:36   ` kernel test robot
2021-04-24  6:44 ` [PATCH 03/78] media: mdk-mdp: fix pm_runtime_get_sync() usage count Mauro Carvalho Chehab
2021-04-24  6:44 ` [PATCH 05/78] " Mauro Carvalho Chehab
2021-04-24 18:23   ` Ezequiel Garcia
2021-04-24  6:44 ` [PATCH 14/78] staging: media: imx7-mipi-csis: use pm_runtime_resume_and_get() Mauro Carvalho Chehab
2021-04-26 10:11   ` Rui Miguel Silva
2021-04-24  6:44 ` [PATCH 16/78] staging: media: cedrus_video: " Mauro Carvalho Chehab
2021-04-24  6:44 ` [PATCH 20/78] media: mtk-vcodec: fix pm_runtime_get_sync() usage count Mauro Carvalho Chehab
2021-04-24  6:44 ` [PATCH 21/78] media: s5p-jpeg: " Mauro Carvalho Chehab
2021-04-27  9:14   ` Sylwester Nawrocki
2021-04-24  6:44 ` [PATCH 23/78] media: sun8i_rotate: " Mauro Carvalho Chehab
2021-04-24  6:45 ` [PATCH 57/78] media: exynos4-is: use pm_runtime_resume_and_get() Mauro Carvalho Chehab
2021-04-25 20:57   ` Sylwester Nawrocki
2021-04-26 13:12     ` Mauro Carvalho Chehab
2021-04-27  8:06       ` Sylwester Nawrocki
2021-04-24  6:45 ` [PATCH 58/78] media: exynos-gsc: " Mauro Carvalho Chehab
2021-04-27  8:18   ` Sylwester Nawrocki
2021-04-27  9:30     ` Mauro Carvalho Chehab
2021-04-27  9:42       ` Mauro Carvalho Chehab
2021-04-27 11:50         ` Sylwester Nawrocki
2021-04-28  7:13           ` Mauro Carvalho Chehab [this message]
2021-04-28  7:17             ` Mauro Carvalho Chehab
2021-04-28  8:27               ` Sylwester Nawrocki
2021-04-24  6:45 ` [PATCH 59/78] media: mtk-jpeg: " Mauro Carvalho Chehab
2021-04-24  6:45 ` [PATCH 70/78] media: rga-buf: " Mauro Carvalho Chehab
2021-04-28 17:09   ` Ezequiel Garcia
2021-04-24  6:45 ` [PATCH 71/78] media: rkisp1-capture: " Mauro Carvalho Chehab
2021-04-24  6:45 ` [PATCH 73/78] media: s5p-mfc: " Mauro Carvalho Chehab
2021-04-27  9:36   ` Sylwester Nawrocki
2021-04-24  6:45 ` [PATCH 75/78] media: stm32: " Mauro Carvalho Chehab
2021-04-24  6:45 ` [PATCH 76/78] media: sun4i_v4l2: " Mauro Carvalho Chehab
2021-04-24 10:21   ` kernel test robot

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=20210428091302.64af1e5d@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mauro.chehab@huawei.com \
    --cc=mchehab@kernel.org \
    --cc=s.nawrocki@samsung.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).