On 14/07/2022 13:12, Laurent Pinchart wrote: >>>>> One option would be to support the following three compatible values: >>>>> >>>>> compatible = "melexis,mlx75026", "melexis,mlx7502x"; >>>>> compatible = "melexis,mlx75027", "melexis,mlx7502x"; >>>>> compatible = "melexis,mlx7502x"; >>>>> >>>>> The last one only would trigger autodetection. I'm still not sure how to >>>>> document that properly in bindings though. >>>> >>>> I missed that part of binding. >>>> >>>> Wildcards are not allowed in compatible, so mlx7502x has to go. >>> >>> Really ? We've had fallback generic compatible strings since the >>> beginning. >> >> Fallback generic compatibles are allowed. Wildcards not. Wildcards were >> actually never explicitly allowed, they just slipped in to many >> bindings... We have several discussions on this on mailing list, so no >> real point to repeat the arguments. >> >> There is a difference between generic fallback. If the device follows >> clear specification and version, e.g. "foo-bar-v4", you can use it for >> generic compatible. This is more common in SoC components. Requirement - >> there is a clear mapping between versions and SoCs. > > I'm not sure to see a clear difference between the two concepts. The clear difference is that you have a versioned and re-usable hardware block plus clear mapping which version goes to which SoC. Version numbers usually start with 1, not with 75025. 75025 is a model name. >>>> Anyway what does this autodetection mean? >>> >>> As far as I understand, it means that the driver will use a hardware >>> identification register to figure out if the sensor is a 75026 or 75027. >> >> Then there is no need to define 75027 compatible. DT is for cases where >> autodetection does not work... > > It's autodetection of the exact device model, those are I2C devices so > we still need DT, and we still need to know that it's one of the > MLX75026 or MLX75027. > >>> The upside is that one doesn't need to change the device tree when >>> swapping between those two sensors. The downside is that the sensor >>> needs to be powered up at probe time. Depending on the platform, one of >>> those two behaviours is preferred. Auto-detection is nice, but in >>> laptops or tablets (not a use case for this particular device, but the >>> problem applies to camera sensors in general), it would mean that the >>> privacy LED of the camera could be briefly lit at boot time due to the >>> sensor being powered on, which can worry users. >> >> OK, that's reasonable argument for dedicated compatible but I don't >> understand why you cannot perform autodetection the moment device is >> actually powered up (first time). I understand it is nice and easy to >> make everything in the probe and most devices perform it that way. But >> if you don't want to do it in the probe - DT is not a workaround for this... > > For cameras, we often deal with complex pipelines with multiple external > devices and multiple IP cores, with drivers that need to communicate > with each other to initialize the complete camera system. For instance, > each camera-related component in the system registers itself in a media > graph that can be queried from userspace and exposes information about > all devices, including their model. There's no power up of any device > when this query is being performed from userspace. It could possibly be > changed (and maybe it should, for reasons unrelated to this discussion), > but we're looking at pretty much a complete redesign of V4L2 and MC > then. Is then autodetection a real use case since you have to power up the sensor each time system boots and this violates privacy? Several I2C sensors do not care about this and they always do it on power up, so aren't we solving here something unimportant? Best regards, Krzysztof
