Re: [PATCH 1/1] media: dt-bindings: Add bindings for camera modules

[Kieran Bingham <kieran.bingham@ideasonboard.com>]

Hi Sakari,

Following up here because I think we already need to distinguish between
modules - presumably at the DT/overlay level.

Quoting Sakari Ailus (2025-05-19 12:56:41)
> Hi Kieran,
> 
> On Fri, May 09, 2025 at 09:44:15PM +0100, Kieran Bingham wrote:
> > Hi Sakari,
> > 
> > Quoting Sakari Ailus (2025-05-07 09:13:38)
> > > Add bindings for camera modules to allow telling especially the user space
> > > which module is found in the system. Camera modules do not have a device
> > > node so this is a property for the camera sensor device node. This allows
> > > describing modules that contain a single camera sensor.
> > > 
> > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > ---
> > > Hi all,
> > > 
> > > Here's the patch to give some advance warning for the camera module
> > > discussion. The good thing is that it's quite short.
> > > 
> > 
> > Thanks for starting this! Definitely something I would like to see a
> > solution for indeed.
> > 
> > > The intent indeed is to address the regular use case where we have a
> > > single sensor in a camera module. For cases where we have more, we'll need
> > > something else, not based on individual properties. I believe this is
> > > still the way to go, to address current issues and for a couple of
> > > additional reasons:
> > > 
> > > - Cameras with more than one sensor tend to be collections of camera
> > >   modules so this is still relevant in most cases.
> > > 
> > > - It's much simpler to have a single property than begin having new nodes
> > >   in DT. In practice such nodes would be a poor fit for DT generally as
> > >   they have (few or) no functions.
> > > 
> > > The biggest difficulty is still in module identification. These components
> > > tend to be often ignored and the best we have for a module name in that
> > > case is random-looking string if even that. Besides DT bindings, we need
> > > an additional (git?) tree to describe the modules that have no proper
> > > names but it could be also useful for those that do, for instance to
> > > include information on lens, field of view, IR filter, photos of the
> > > module etc. There is some overlap with what libcamera needs, too.
> > > 
> > 
> > One aspect that jumps to my mind here - is how do we handle variations
> > of modules?
> > 
> > For instance I have two IMX335 modules from Arducam - which are
> > otherwise identical except for different lenses with different
> > field-of-view.
> > 
> > Do we need more properties (later?) to express the different
> > configuration options of the module?
> 
> I think I'd document these as two different modules. Arducam SKU
> identifiers are probably best to be used as models here and I presume SKU
> is different between your modules?
> 
> > 
> > 
> > At some point I would love to be able to describe a 'module' as the
> > whole component including a VCM for instance - in a way that can be
> > abstracted as something that could be connected to a 'port' (see [0],
> > [1]) where it would be helpful to be able to group/abstract a movable
> > component and identify the full camera module in a way that doesn't have
> > to be duplicated in every platform configuration that it could be
> > connected.
> 
> This would likely require having a node for the module, too. It's a
> heavy-weight solution compared to just a property (or a few).
> 
> How commonly do you swap lenses outside R&D in practice?

Hard to determine that - but there are already multiple instances of
different vendor modules with the same sensor - but a different lens
configuration. I'd like to compare these to see if the common parts
could be de-duplciated.

In [2] I've posted two more tuning files for libcamera for the IMX335
and IMX415. Does specifying the vendor and SKU there match what you
would expect with this? Or should we make it a direct match on the
strings you propose below?


[2] https://lists.libcamera.org/pipermail/libcamera-devel/2025-August/052409.html

> +    $ref: /schemas/types.yaml#/definitions/string
> +    enum:
> +      - "dell,0BF122N3" # onnn,ov01a10

So I guess for the Arducam modules I've posted this would be
	"arducam,B0568"

(Do we expect these to be case sensitive? Or insensitive?)

> +  camera-module-casual:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum:
> +      - 1 # st,vs6555



> > 
> > [0] https://www.konsulko.com/wp-content/uploads/2016/09/portable-device-tree-connector.pdf
> > [1] https://lore.kernel.org/all/1464986273-12039-2-git-send-email-pantelis.antoniou@konsulko.com/
> 
> -- 
> Kind regards,
> 
> Sakari Ailus