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
