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

[Sakari Ailus <sakari.ailus@linux.intel.com>]

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?

> 
> [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