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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Hans,

(CC'ing Sakari who may have more insight on ACPI properties for
Intel-based machines, or who may be able to pull the right people in
this conversation)

On Thu, Oct 01, 2026 at 05:15:05PM +0200, johannes.goede@oss.qualcomm.com wrote:
> 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.

We know that hardware manufacturers like to have multiple providers for
camera modules in the same laptop model in order to avoid supply chain
issues. Do you know if this can be confirmed from those strings, do we
have enough data to see if the identification strings are made of a
small number of clusters ?

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

I would very much like to standardize the API exposed to userspace
across different types of firmwares (ACPI and DT). Having more data
about the ACPI side could help us design DT properties that would fit
nicely with a single API.

> > ### 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.

I wouldn't expect an EEPROM, that would be quite costly for little gain.
I wonder if sensor OTP memory is typically used though. Some sensor
manufacturers specify how to store calibration data there, such as lens
shading tables for instance. I wonder if anyone puts the same data in
ACPI tables.

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

Laurent Pinchart