Hi, On 11/11/21 16:51, Dave Stevenson wrote: > Hi Hans > > On Thu, 11 Nov 2021 at 15:23, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> Hi, >> >> On 11/11/21 12:18, Daniel Scally wrote: >> >> <snip> >> >>>>> 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
