Hi,

On 11/11/21 16:51, Dave Stevenson wrote:

Hi Hans

On Thu, 11 Nov 2021 at 15:23, Hans de Goede [off-list ref] wrote:

quoted

Hi,

On 11/11/21 12:18, Daniel Scally wrote:

<snip>

quoted

quoted

quoted

One problem I'm experiencing
is that the focus position I set isn't maintained; it holds for a couple
of seconds and then resets to the "normal" focus...this happens when the
.close() callback for the driver is called, which happens right after
the control value is applied. All the other VCM drivers in the kernel
power down on .close() so I did the same>

Right, I believe that this is fine though, we expect people to use
libcamera with this and once libcamera gets autofocus support, then
I would expect libcamera to keep the fd open the entire time while
streaming.

OK - as long as that's how it works then I agree that this is fine as is
yes.

So I've just picked up an old project of mine, called gtk-v4l which
is a nice simply v4l2 controls applet and patches it up to also
work on v4l-subdevs:

https://github.com/jwrdegoede/gtk-v4l/

So now you can run:

sudo gtk-v4l -d /dev/v4l-subdev8

And it will give you a slider to control the focus; and as
a bonus it keeps the v4l-subdev open, so no more runtime-pm
issue :)

Do the lens and sensor share a regulator / enable GPIO?

No, if they did then there would be no runtime-pm issue,
because then the VCM would not get turned off after
a v4l2-set command (for a quick test) since then the
streaming from the sensor would keep the sensor and
thus the regulator on.

I was looking at the same issue for a Sony IMX135 module with AD5398
VCM driver [1].
In my case they do share an enable GPIO, so using regulator-gpio we
can register via regulator_register_notifier for information on when
the regulator is powered up. It can then also reset to the last
position should the sensor subdev enable the regulator without the
lens driver being opened at all.

That sounds like it is relying on board-depedent behavior
(the enable GPIO and/or regulator being shared) which we don't
want in the VCM drivers as those are supposed to be board
agnostic.

This really is something which should be fixed in userspace
where the userspace consumer of the sensor should also always
open the vcm v4l-subdev.

Regards,

Hans