Re: [ANNOUNCEMENT] Camera & ISP at Linux Plumbers Conference

[johannes.goede@oss.qualcomm.com]

Hi Stefan,

Thank you for the write-up.

On 30-Sep-26 13:18, Stefan Klug wrote:

<snip>

> ## Diving into the examples
> 
> Lets look at the example I listed to see how these would be solved.
> 
> ### 1. Laptop with camera module from various manufacturers
> 
> I believe this can be solved by either integrating the detection logic
> in libcamera and/or adding rules to udev/hwdb. But we are lacking real
> examples. So if you're able to provide identification strategies for
> real, existing hardware, I'd be glad to know about it. One strategy
> might be to use the machine identifier provided by DMI. This is however
> quite coarse and can not handle cases where the manufacturer used
> different camera modules from different vendors (using the same sensor
> model). ARe there for example ACPI properties that we could query for
> additional information?
> 
> Q: Does anyone in this group have more details on which information to
> query and where to get more details from the system?
> A: ...

For the Intel IPU6/IPU7 methods there is an ACPI call which the kernel
can do on the sensor fwnode object which will return a string identifying
the modules. These strings don't really have any fixed format, typically
they contain something which look like how some laptop serials look
just a random bunch of numbers + capital letters.

Userspace cannot get to this without the kernel exporting it.

Given all the udev talk, I think a sysfs attribute would make sense
for this. We can make the kernel do the ACPI call and if it is present
add a camera_module sysfs attribute to the v4l2-subdev for the sensor,
which will only be visible when there actually is a module-name.

On laptops using devicetree we could then fill this from a devicetree
property.


> 
> ### 2. Camera modules with an embedded EEPROM
> 
> To make use of the EEPROM data from user space we need to carry two
> elements: The EEPROM data itself and some identifier telling which
> format the data in the EEPROM has. This seems relatively straightforward
> and we could model it like this in dts:
> 
> dts-snippet:
> imx283_0: sensor@1a {
> 		compatible = "sony,imx283";
>     ...
>     eeprom = <&eeprom>;
>     eeprom-format = "vendor-a-eeprom-fmt";
> };
> 
> Getting the link to the EEPROM from user space is something to
> investigate. Ideas are either sysfs or media-controller.
> The eeprom-format must be specified as well, to tell user space how to
> interpret the EEPROM data, as it is typically not self-contained.
> 
> Q: On a first discussion on that topic we were unsure if it would be
> preferred to expose the data directly in sysfs,
> or to symlink to the corresponding sysfs entry for the EEPROM. Any
> preferences?
> A: ...
> 
> Q: Any input/things to consider from ACPI side?
> A:

For IPU6/IPU7 eeprom data is not used for camera-module identification
(AFAIK), it is all done through the (custom, Intel specific) ACPI call
I mentioned above.

> Q: What happens if the EEPROM driver is not loaded yet or is just not
> available? Should it block/defer probing of the sensor?
> A:
> 
> Q: We are missing real-life examples for these cases. So input from
> vendors would be welcome.
> A:
<snip>

Regards,

Hans