Re: [PATCH v2] media: ov5640: Use runtime PM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sakari,

On Sun, Mar 13, 2022 at 03:38:34PM +0200, Sakari Ailus wrote:
> On Sun, Mar 13, 2022 at 03:01:52PM +0200, Laurent Pinchart wrote:
> > On Fri, Mar 11, 2022 at 03:32:26PM +0200, Sakari Ailus wrote:
> > > On Fri, Mar 11, 2022 at 03:20:55PM +0200, Laurent Pinchart wrote:
> > > > On Fri, Mar 11, 2022 at 03:15:54PM +0200, Sakari Ailus wrote:
> > > > > On Fri, Mar 11, 2022 at 02:30:09PM +0200, Laurent Pinchart wrote:
> > > > > > On Fri, Mar 11, 2022 at 02:23:53PM +0200, Sakari Ailus wrote:
> > > > > > > On Fri, Mar 11, 2022 at 08:12:59PM +0900, Paul Elder wrote:
> > > > > > > > Switch to using runtime PM for power management.
> > > > > > > > 
> > > > > > > > Signed-off-by: Paul Elder <paul.elder@xxxxxxxxxxxxxxxx>
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > Changes in v2:
> > > > > > > > - replace manual tracking of power status with pm_runtime_get_if_in_use
> > > > > > > > - power on the sensor before reading the checking the chip id
> > > > > > > > - add dependency on PM to Kconfig
> > > > > > > > ---
> > > > > > > >  drivers/media/i2c/Kconfig  |   1 +
> > > > > > > >  drivers/media/i2c/ov5640.c | 112 ++++++++++++++++++++++---------------
> > > > > > > >  2 files changed, 67 insertions(+), 46 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > > > > > > > index e7194c1be4d2..97c3611d9304 100644
> > > > > > > > --- a/drivers/media/i2c/Kconfig
> > > > > > > > +++ b/drivers/media/i2c/Kconfig
> > > > > > > > @@ -1025,6 +1025,7 @@ config VIDEO_OV5640
> > > > > > > >  	tristate "OmniVision OV5640 sensor support"
> > > > > > > >  	depends on OF
> > > > > > > >  	depends on GPIOLIB && VIDEO_V4L2 && I2C
> > > > > > > > +	depends on PM
> > > > > > > 
> > > > > > > I think this is not needed as the sensor is powered on explicitly in probe.
> > > > > > > 
> > > > > > > You should similarly power it off explicitly in remove, set the runtime PM
> > > > > > > status suspended and disable runtime PM. See e.g. imx319 driver for an
> > > > > > > example. It doesn't have resume callback but that doesn't really matter ---
> > > > > > > it's just ACPI-only.
> > > > > > 
> > > > > > Do we want to continue supporting !PM ? Does it have any real use case
> > > > > > when dealing with camera sensors ?
> > > > > 
> > > > > Probably not much.
> > > > > 
> > > > > The changes I proposed are not eve related on runtime PM. Hence the
> > > > > question here is whether there should be a dependency to CONFIG_PM or not,
> > > > > and as there's no technical reason to have it, it should be omitted.
> > > > 
> > > > But if there's no real use case for !PM, wouldn't we be better off
> > > > depending on PM and simplifying the probe functions instead ?
> > > 
> > > What would change in the probe function if runtime PM was required by the
> > > driver?
> > 
> > We wouldn't need the complicated dance of calling
> > 
> > 	ret = ov5640_set_power(sensor, true);
> > 	if (ret)
> > 		goto free_ctrls;
> > 
> > 	pm_runtime_set_active(dev);
> > 	pm_runtime_enable(dev);
> > 	pm_runtime_get(dev);
> 
> pm_runtime_get() is redundant here.
> 
> > 
> > but could write it as
> > 
> > 	pm_runtime_enable(dev);
> > 	pm_runtime_resume_and_get(dev);
> 
> You'll need put here, too.

Yes, after reading the version register (or doing any other harware
access). Actually the full code would be


 	pm_runtime_enable(dev);
 	pm_runtime_resume_and_get(dev);

	/* Hardware access */

	pm_runtime_set_autosuspend_delay(dev, 1000);
	pm_runtime_use_autosuspend(dev);
	pm_runtime_put_autosuspend(dev);

(plus error handling).

If the probe function doesn't need to access the hardware, then
the above becomes

	pm_runtime_enable(dev);
	pm_runtime_set_autosuspend_delay(dev, 1000);
	pm_runtime_use_autosuspend(dev);

instead of having to power up the device just in case !PM.

> Also the latter only works on DT-based systems so it's not an option for
> most of the drivers.

How so, what's wrong with the above for ACPI-based system ?

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux