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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

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