On Mon, Mar 21, 2022 at 01:24:19PM +0200, Laurent Pinchart wrote: > On Mon, Mar 21, 2022 at 12:58:25PM +0200, Sakari Ailus wrote: > > Hi Laurent, > > > > On Sat, Mar 19, 2022 at 12:28:22AM +0200, Laurent Pinchart wrote: > > > > @@ -3288,6 +3256,9 @@ static int ov5640_g_volatile_ctrl(struct v4l2_ctrl *ctrl) > > > > > > > > /* v4l2_ctrl_lock() locks our own mutex */ > > > > > > > > + if (!pm_runtime_get_if_in_use(&sensor->i2c_client->dev)) > > > > + return 0; > > > > > > I'm afraid this won't work as intended :-S This function is called by > > > v4l2_ctrl_handler_setup(), itself called from ov5640_sensor_resume(). At > > > that point, runtime PM isn't flagged as in use yet, we're still in the > > > process of resuming. > > > > > > There are a few ways around this. The simplest one may be to move the > > > v4l2_ctrl_handler_setup() call from ov5640_sensor_resume() to > > > ov5640_s_stream(). Sakari, any opinion ? > > > > That's one way to do it, yes. > > > > The problem is that when the s_ctrl callback is run, there's no information > > on whether it's being called from the runtime PM resume handler (which > > powers on the device) or via another path. > > > > Changing that would require changing the callback arguments, or adding a > > new callback with that information included. > > We can also add a flag in the driver-specific structure to tell if the > device is powered or not. Delaying v4l2_ctrl_handler_setup() until > .s_stream() seems easier though, but then maybe we should return early > from .s_ctrl() until streaming is started, even if the device is powered > on ? (Finally fixed Jacopo's e-mail.) The device is likely powered off if streaming is disabled. But it might not be if the controls are being accessed right after stopping streaming. You could use a driver-local information to keep the knowledge of this, but it'd be better if drivers wouldn't have to manage such information. -- Sakari Ailus
