From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE5F5C6FA83 for ; Sun, 11 Sep 2022 09:14:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229920AbiIKJOC (ORCPT ); Sun, 11 Sep 2022 05:14:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229566AbiIKJOB (ORCPT ); Sun, 11 Sep 2022 05:14:01 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 948A63C156 for ; Sun, 11 Sep 2022 02:13:58 -0700 (PDT) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 93CC0415; Sun, 11 Sep 2022 11:13:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1662887635; bh=lKaj3eVvOL2TM1AGESx/h1C60OAYo2sgV4xyxPzw+ng=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OtoLKQ0SpdX/29qhCQzXz3BddOk3cBYP301GJXYEY1IulCJ9Kj6G6vfqcr5jMKc6e HYSAThwmo0ZronJw4czjWpfIzvCdHh5moHmqAXBh6DyfTHi3dGKyGs8Vtoqo22PDHs RDq6GTnLBw15rvcXhmkxgBOtOGUwvydt3YXmtlmc= Date: Sun, 11 Sep 2022 12:13:39 +0300 From: Laurent Pinchart To: Hans Verkuil Cc: Dave Stevenson , Linux Media Mailing List , Sakari Ailus , Kieran Bingham , Nicolas Dufresne , Benjamin Gaignard , Hidenori Kobayashi , Paul Kocialkowski , Michael Olbrich , Ricardo Ribalda , Maxime Ripard , Daniel Scally , Jernej =?utf-8?Q?=C5=A0krabec?= , Niklas =?utf-8?Q?S=C3=B6derlund?= , Michael Tretter , Philipp Zabel , Mauro Carvalho Chehab , Benjamin MUGNIER , Jacopo Mondi Subject: Re: [Media Summit] Imaging Sensor functionality Message-ID: References: <29b69b01-15c9-28dc-4e21-7e54be171059@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org 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