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 1016CC54EE9 for ; Wed, 7 Sep 2022 13:11:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229705AbiIGNL1 (ORCPT ); Wed, 7 Sep 2022 09:11:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229692AbiIGNL0 (ORCPT ); Wed, 7 Sep 2022 09:11:26 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD6DC2E688 for ; Wed, 7 Sep 2022 06:11:22 -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 5F326DD; Wed, 7 Sep 2022 15:11:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1662556280; bh=vH7ecl4u+qIuuH3YGH3VFOqhN0/7dkV3RE3coFDVbGc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wmuLdkhfggwXiRS4h2bj0R+/8RhOzRMS/kKbTtWZis02CH1r+kzc9Vpz7dfZLxYXe c5mUbxydIihEpUo1/wtUVxZdfOo/kYMOgGLFY1StgmQXwXpFn6/UjpWTmjoCfI8jbf rOCFkYHFkYBSbopSBZpvaZQtnESv9isA2m9noRD0= Date: Wed, 7 Sep 2022 16:11:05 +0300 From: Laurent Pinchart To: Dave Stevenson Cc: 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 , Hans Verkuil , Philipp Zabel , Mauro Carvalho Chehab , Benjamin MUGNIER , Jacopo Mondi Subject: Re: [Media Summit] Imaging Sensor functionality Message-ID: References: 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 Wed, Sep 07, 2022 at 01:42:16PM +0100, Dave Stevenson wrote: > On Tue, 6 Sept 2022 at 18:53, Laurent Pinchart wrote: > > On Tue, Sep 06, 2022 at 05:14:30PM +0100, 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. > > > > Could you clarify here what you mean by users and hardware designers ? > > Users can be understood as > > > > - Users of the camera sensor, i.e. OEMs designing a product > > - Users of the hardware platform , i.e. software developers writing > > applications > > - Users of the software, i.e. end-users > > Users of the software. > > Particularly on the Pi you have people using libcamera apps or Python > bindings that want to be able to choose modes of operation without > having to make kernel driver modifications. > I generally don't mind if that is through userspace or DT, but the > functionality should be exposed. > > As an example, when the strobe signals were exposed for IMX477 we had > people hooking up various high intensity strobe devices and other > weird contraptions for synchronised events [1]. Can we replicate that > sort of open-ended functionality in a standardised way within sensor > kernel drivers so that the drivers are not constraining the use cases? We have the same goal, so let's see if we can find a way to make it happen :-) > > Hardware designers could then equally mean > > > > - Sensor vendors > > - SoC vendors > > - Board vendors > > - Product vendors > > All of the above. > > For those Product Vendors designing specific products based on an SoC > and imaging sensor, if there is a defined mechanism that end users can > get to, then they can also use it to configure their specific use > case. Both cases therefore win. Hard coding their product's use case > in a mainline driver limits other use cases. > > Dave > > [1] https://forums.raspberrypi.com/viewtopic.php?t=281913 > > > > 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 > > > > Thank you, I will review that ASAP. > > > > > See you on Monday. -- Regards, Laurent Pinchart