[PATCH] media: v4l2-async: link ancillary device runtime PM to the sensor's

[PATCH] media: v4l2-async: link ancillary device runtime PM to the sensor's

[Cédric Bellegarde]

When a sensor's fwnode references an ancillary lens or flash device
(e.g. via the "lens-focus" or "flash-leds" properties),
v4l2_async_create_ancillary_links() already creates a media controller
link between the two entities, but their runtime PM states remain
independent.

This is a problem for devices such as VCM lens actuators, which are
typically spring-loaded: holding a position away from the spring's
rest point requires continuous power, and the position is not retained
once power is cut. If such an actuator is allowed to runtime-suspend
independently of the sensor, the lens can drift back to its rest
position during an otherwise active capture session.

Add V4L2_SUBDEV_FL_PM_LINK to allow an ancillary subdevice to request
that its runtime PM state be linked to the associated sensor.

Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org>
---
Link runtime PM of ancillary devices such as lens actuators to their associated sensor,
while allowing actuators to autosuspend when idle.

Example usage:
https://gitlab.com/gnumdk/linux/-/commit/82b2d71415a1d95b2170e19ce025afc8bbdcf145
---
 drivers/media/v4l2-core/v4l2-async.c | 18 ++++++++++++++----
 include/media/v4l2-subdev.h          |  7 +++++++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index 460bf3dbbb88..22df627153b8 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -318,6 +318,7 @@ static int v4l2_async_create_ancillary_links(struct v4l2_async_notifier *n,
 {
 #if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
 	struct media_link *link;
+	struct device_link *devlink;
 
 	if (sd->entity.function != MEDIA_ENT_F_LENS &&
 	    sd->entity.function != MEDIA_ENT_F_FLASH)
@@ -331,11 +332,20 @@ static int v4l2_async_create_ancillary_links(struct v4l2_async_notifier *n,
 	}
 
 	link = media_create_ancillary_link(&n->sd->entity, &sd->entity);
-
-	return IS_ERR(link) ? PTR_ERR(link) : 0;
-#else
-	return 0;
+	if (IS_ERR(link))
+		return PTR_ERR(link);
+
+	if (sd->flags & V4L2_SUBDEV_FL_PM_LINK) {
+		devlink = device_link_add(n->sd->dev, sd->dev,
+					  DL_FLAG_PM_RUNTIME |
+					  DL_FLAG_AUTOREMOVE_CONSUMER);
+		if (!devlink)
+			dev_warn(notifier_dev(n),
+				 "failed to link power management of %s to %s\n",
+				 dev_name(sd->dev), dev_name(n->sd->dev));
+	}
 #endif
+	return 0;
 }
 
 static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index d256b7ec8f84..9f64b10afd10 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -972,6 +972,13 @@ struct v4l2_subdev_internal_ops {
  * - Multiple streams per pad are supported
  */
 #define V4L2_SUBDEV_FL_STREAMS			(1U << 4)
+/*
+ * Set this flag to keep the subdevice active while its associated sensor is active.
+ *
+ * This is intended for ancillary devices, such as lens actuators, whose
+ * hardware state or physical position cannot be retained while powered off.
+ */
+#define V4L2_SUBDEV_FL_PM_LINK          (1U << 5)
 
 struct regulator_bulk_data;
 

---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260911-sensors_pm-787eac01aa18

Best regards,
-- 
Cédric Bellegarde <cedric.bellegarde@adishatz.org>

Re: [PATCH] media: v4l2-async: link ancillary device runtime PM to the sensor's

[Sakari Ailus]

Hi Cédric,

On Tue, Sep 22, 2026 at 09:39:12PM +0200, Cédric Bellegarde wrote:
> When a sensor's fwnode references an ancillary lens or flash device
> (e.g. via the "lens-focus" or "flash-leds" properties),
> v4l2_async_create_ancillary_links() already creates a media controller
> link between the two entities, but their runtime PM states remain
> independent.
> 
> This is a problem for devices such as VCM lens actuators, which are
> typically spring-loaded: holding a position away from the spring's
> rest point requires continuous power, and the position is not retained
> once power is cut. If such an actuator is allowed to runtime-suspend
> independently of the sensor, the lens can drift back to its rest
> position during an otherwise active capture session.
> 
> Add V4L2_SUBDEV_FL_PM_LINK to allow an ancillary subdevice to request
> that its runtime PM state be linked to the associated sensor.

Interesting idea.

The IPU bridge has created such a device link between the VCM and the
sensor as on some ACPI systems the VCM is in fact relying on the power
resources of the sensor. But to do this everywhere?

VCMs traditionally have been powered through opening their sub-device node
and that hasn't been exactly neat API-wise. It has been practical still,
AFAIK, as in order to control the VCM, you have to have a sub-device node
open.

This change also does mean that if the sensor is powered, even for
always-on use cases that generally consume very little power, the VCM is
powered on as well. VCMs still typically consume very little power if the
current is configured to zero. Maybe this won't be an issue? Backtracking
from such a change wouldn't be simple, and might not be possible at all.

There wouldn't be a need for a sub-device flag and this would be done for
all VCMs based on the ancillary link.

I wonder what others think.

Cc Laurent and Hans as well.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH] media: v4l2-async: link ancillary device runtime PM to the sensor's

[Kieran Bingham]

Quoting Sakari Ailus (2026-09-23 07:34:54)
> Hi C�dric,
> 
> On Tue, Sep 22, 2026 at 09:39:12PM +0200, C�dric Bellegarde wrote:
> > When a sensor's fwnode references an ancillary lens or flash device
> > (e.g. via the "lens-focus" or "flash-leds" properties),
> > v4l2_async_create_ancillary_links() already creates a media controller
> > link between the two entities, but their runtime PM states remain
> > independent.
> > 
> > This is a problem for devices such as VCM lens actuators, which are
> > typically spring-loaded: holding a position away from the spring's
> > rest point requires continuous power, and the position is not retained
> > once power is cut. If such an actuator is allowed to runtime-suspend
> > independently of the sensor, the lens can drift back to its rest
> > position during an otherwise active capture session.
> > 
> > Add V4L2_SUBDEV_FL_PM_LINK to allow an ancillary subdevice to request
> > that its runtime PM state be linked to the associated sensor.
> 
> Interesting idea.
> 
> The IPU bridge has created such a device link between the VCM and the
> sensor as on some ACPI systems the VCM is in fact relying on the power
> resources of the sensor. But to do this everywhere?

Same on any Raspberry Pi camera module. The VCM is powered by the same
enable lines as the Sensor there I think which has made things
interesting in handling VCMs for those devices.


> VCMs traditionally have been powered through opening their sub-device node
> and that hasn't been exactly neat API-wise. It has been practical still,
> AFAIK, as in order to control the VCM, you have to have a sub-device node
> open.

This is an issue though, as libcamera opens the device nodes and holds
the file descriptor when it has a camera. This means that even if the
camera isn't streaming, the VCM is powered on and causes power
consumption on mobile devices which people then attribute to pipewire.

 
> This change also does mean that if the sensor is powered, even for
> always-on use cases that generally consume very little power, the VCM is
> powered on as well. VCMs still typically consume very little power if the

Do you foresee use cases where a linked VCM shouldn't be  powered while
a camera is streaming? That effectively means the lens position seen by
the camera is 'arbitrary' / undefined ?

> current is configured to zero. Maybe this won't be an issue? Backtracking
> from such a change wouldn't be simple, and might not be possible at all.
> 
> There wouldn't be a need for a sub-device flag and this would be done for
> all VCMs based on the ancillary link.
> 
> I wonder what others think.
> 
> Cc Laurent and Hans as well.

Cc Dave too as he's looked at similar things in the past.

--
Kieran

> 
> -- 
> Kind regards,
> 
> Sakari Ailus

Re: [PATCH] media: v4l2-async: link ancillary device runtime PM to the sensor's

[Sakari Ailus]

Hi Kieran,

On Wed, Sep 23, 2026 at 07:58:21AM +0100, Kieran Bingham wrote:
> Quoting Sakari Ailus (2026-09-23 07:34:54)
> > Hi C�dric,
> > 
> > On Tue, Sep 22, 2026 at 09:39:12PM +0200, C�dric Bellegarde wrote:
> > > When a sensor's fwnode references an ancillary lens or flash device
> > > (e.g. via the "lens-focus" or "flash-leds" properties),
> > > v4l2_async_create_ancillary_links() already creates a media controller
> > > link between the two entities, but their runtime PM states remain
> > > independent.
> > > 
> > > This is a problem for devices such as VCM lens actuators, which are
> > > typically spring-loaded: holding a position away from the spring's
> > > rest point requires continuous power, and the position is not retained
> > > once power is cut. If such an actuator is allowed to runtime-suspend
> > > independently of the sensor, the lens can drift back to its rest
> > > position during an otherwise active capture session.
> > > 
> > > Add V4L2_SUBDEV_FL_PM_LINK to allow an ancillary subdevice to request
> > > that its runtime PM state be linked to the associated sensor.
> > 
> > Interesting idea.
> > 
> > The IPU bridge has created such a device link between the VCM and the
> > sensor as on some ACPI systems the VCM is in fact relying on the power
> > resources of the sensor. But to do this everywhere?
> 
> Same on any Raspberry Pi camera module. The VCM is powered by the same
> enable lines as the Sensor there I think which has made things
> interesting in handling VCMs for those devices.

Yes, this has been an issue in DT for a long time. :-( I'm not sure if this
approach could extend into a solution for that though.

> 
> 
> > VCMs traditionally have been powered through opening their sub-device node
> > and that hasn't been exactly neat API-wise. It has been practical still,
> > AFAIK, as in order to control the VCM, you have to have a sub-device node
> > open.
> 
> This is an issue though, as libcamera opens the device nodes and holds
> the file descriptor when it has a camera. This means that even if the
> camera isn't streaming, the VCM is powered on and causes power
> consumption on mobile devices which people then attribute to pipewire.

A practical fix for that could be to set the current to 0 when streaming is
off.

> 
>  
> > This change also does mean that if the sensor is powered, even for
> > always-on use cases that generally consume very little power, the VCM is
> > powered on as well. VCMs still typically consume very little power if the
> 
> Do you foresee use cases where a linked VCM shouldn't be  powered while
> a camera is streaming? That effectively means the lens position seen by
> the camera is 'arbitrary' / undefined ?

It's neither, in that case the lens will be just in the resting position
which is typically close to infinite.

> 
> > current is configured to zero. Maybe this won't be an issue? Backtracking
> > from such a change wouldn't be simple, and might not be possible at all.
> > 
> > There wouldn't be a need for a sub-device flag and this would be done for
> > all VCMs based on the ancillary link.
> > 
> > I wonder what others think.
> > 
> > Cc Laurent and Hans as well.
> 
> Cc Dave too as he's looked at similar things in the past.

-- 
Regards,

Sakari Ailus