Re: [Media Summit] Imaging Sensor functionality

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Sun, Sep 11, 2022 at 09:12:15AM +0200, Hans Verkuil wrote:
> On 10/09/2022 18:17, Laurent Pinchart wrote:
> > On Sat, Sep 10, 2022 at 02:50:10PM +0200, Hans Verkuil wrote:
> >> On 06/09/2022 18:14, Dave Stevenson wrote:
> >>> Hi All.
> >>>
> >>> I realise that I'm in a slightly different position from many mainline
> >>> Linux-media developers in that I see multiple use cases for the same
> >>> sensor, rather than a driver predominantly being for one
> >>> product/platform. I'm therefore wanting to look at generic solutions
> >>> and fully featured drivers. Users get to decide the use cases, not the
> >>> hardware designers.
> >>>
> >>> The issues I've raised are things that I've encountered and would
> >>> benefit from a discussion to get views as to the direction that is
> >>> perceived to be workable. I appreciate that some can not be solved
> >>> immediately, but want to avoid too much bikeshedding in the first
> >>> round of patches.
> >>> What's realistic, and what pitfalls/limitations immediately jump out at people.
> >>>
> >>> Slides are at https://drive.google.com/file/d/1vjYJjTNRL1P3j6G4Nx2ZpjFtTBTNdeFG/view?usp=sharing
> >>>
> >>> See you on Monday.
> >>>
> >>>   Dave
> >>
> >> Some comments for the meeting on Monday:
> >>
> >> - On-sensor temperature sensing:
> >>
> >> If a control is used to read this, but the value is
> >> not available yet, then -EACCES can be returned. That's already defined as a valid return
> >> code in the API, it would just need to be extended for this use-case.
> >>
> >> - Sync sensors:
> >>
> >> Should it be part of the DT? That depends, I think, on whether this is a pure sw mechanism,
> >> or whether the wiring dictates which sensor can be master and which can be slaves. I assume
> >> that at the very least there has to be a way to group sensors that are/can be connected to
> >> the same master sync signal.
> >>
> >> - Lens assemblies:
> >>
> >> For what it is worth, Cisco uses motor controlled lenses and irises. We extended the camera
> >> controls with these new controls:
> >>
> >> #define V4L2_CID_FOCUS_CURRENT                  (V4L2_CID_CAMERA_CLASS_BASE+36)
> >> #define V4L2_CID_IRIS_CURRENT                   (V4L2_CID_CAMERA_CLASS_BASE+38)
> >> #define V4L2_CID_FOCUS_MOTOR_STATUS             (V4L2_CID_CAMERA_CLASS_BASE+41)
> >> #define V4L2_CID_IRIS_MOTOR_STATUS              (V4L2_CID_CAMERA_CLASS_BASE+43)
> >> enum v4l2_motor_status {
> >>         V4L2_MOTOR_STATUS_IDLE                  = (0),
> >>         V4L2_MOTOR_STATUS_MOVING                = (1 << 0),
> >>         V4L2_MOTOR_STATUS_FAILED                = (1 << 1),
> >>         V4L2_MOTOR_STATUS_NOTCALIBRATED         = (1 << 2),
> >> };
> >> #define V4L2_CID_FOCUS_MOTOR_SPEED              (V4L2_CID_CAMERA_CLASS_BASE+46)
> >> #define V4L2_CID_IRIS_MOTOR_SPEED               (V4L2_CID_CAMERA_CLASS_BASE+48)
> >>
> >> This worked well for our use-case, but for us userspace has complete knowledge about
> >> the camera assembly properties.
> > 
> > Where does userspace get that information from ?
> > 
> 
> From the software engineers :-) We designed the cameras, so we know how to operate them.
> 
> I'm not entirely sure if that's what you meant, though.

:-)

I meant to ask if you have userspace software that can work with
different camera modules, in which case it would need to identify the
module and retrieve corresponding parameters. That leads to the question
of camera module identification (i.e. if we have modules with the same
sensor but with different lenses, how do we identify that, as typically
in DT all we have is the sensor model), parameters format (can we
standardize that, in order to have interoperability of different
userspace software with different platforms) and storage (some systems
have an NVM in the camera sensor or in the camera sensor module, can we
meaningfully use that ?).

-- 
Regards,

Laurent Pinchart