Re: Compatible vs onnn,model at ap1302 binding

[Rob Herring <robh@kernel.org>]

On Mon, Jun 30, 2025 at 09:30:41PM +0300, Laurent Pinchart wrote:
> Hi Frank,
> 
> On Mon, Jun 30, 2025 at 02:04:21PM -0400, Frank Li wrote:
> > Hi Rob:
> > 
> > There are long discussion about AP1302 support.
> > 
> > https://lore.kernel.org/imx/20250623-ap1302-v3-0-c9ca5b791494@nxp.com/T/#m9ecad9fcbfd1ac1c59b3aa5737e3860a64db2eb4
> > previous thread
> > https://lore.kernel.org/linux-media/1631091372-16191-1-git-send-email-anil.mamidala@xilinx.com/
> > 
> > Let me summary the key points.
> 
> Thanks for the summary.
> 
> > AP1302 is I2C ISP processor, which can connect to some RAW sensors. such as
> > AR0144. AR0144 can work alone, a RFC upstreaming at
> > https://lore.kernel.org/linux-devicetree/20240630141802.15830-2-laurent.pinchart@ideasonboard.com/
> > 
> > When AR0144 connect to AP1302, it is not 100% transparents for software,
> > It needs power supplies for it.
> > 
> > The basically there are two methods now.
> > 
> > Method 1 ( Laurent Pinchart purposed ):
> > 
> > use a vendor's specific property like model
> > 
> > camera@3c {
> >         compatible = "onnn,ap1302";
> >         ...
> >         sensors {
> >                 onnn,model = "onnn,ar0144";
> >                 ^^^^

Why is this outside the sensor node?

> >                 sensor@0 {
> >                         reg = <0>;
> >                         vdd-supply = <&mt6358_vcamd_reg>;
> >                         vaa-supply = <&mt6358_vcama1_reg>;
> >                         vddio-supply = <&reg_1p8v_ext>;
> >         ....
> > 
> > 
> > Method 2 ( suggested by Rob at 2021 ):
> > 
> > use compatible string:
> > 
> > camera@3c {
> >         compatible = "onnn,ap1302";
> >         ...
> >         ports {
> >                 port@0 {
> >                         compatible = "onnn,ar0144";
> >                         ^^^^
> >                         reg = <0>;
> >                         vaa-supply = <&vaa_regulator>;

Please don't hijack the graph binding (ports and port nodes). 

> > 
> >         ...
> > 
> > 
> >                Method 2                              Mathod 1
> > The same hardware should use the         There are not driver to match onnn,ar0144.
> > same binding regardless connect to       AR0144 is not visilable from host point.
> > which bus/devices
> > 
> >                                          compatible means software comaptible, but
> >                                          there are not driver for it at this case.
> > 
> > reg in difference spi/i2c also have      reg is i2c's address, but here is port or
> > difference means.                        sensor index.
> > 
> > Similar case for spi and i2c devices.    There are difference set of mandatory properties
> >                                          when connect to ISP or SoC.
> > 
> > 
> > Rob and Laurent Pinchart:
> > 
> >         Need a direction to move forwards!
> 
> There are two things to consider here. One is the DT property we want to
> use to identify the sensor model. It can be argued that the "compatible"
> property is widely used for this purpose. This is true, but the
> "compatible" property is meant to indicate compatibility from an
> operating system software point of view (regardless of which operating
> system is used). As a result, it serves as the central piece around
> which drivers are bound to devices, and therefore is also used to match
> DT schemas for the device.
> 
> What we need here is to identify the sensor model, first and foremost to
> load the corresponding AP1302 firmware, and to know which power supplies
> the AP1302 driver needs to control for the sensor. Note that it would be
> entirely feasible for the sensor power supplies to be connected to GPIOs
> of the AP1302 and entirely controlled by the AP1302 firmware, but on
> some designs those power supplies are connected to GPIOs of the main
> SoC, and therefore need to be controlled by the AP1302 driver.
> 
> While I think a custom property is better, I could live with
> "compatible" *iif* it does not imply at the corresponding DT schema for
> the sensor is pulled in. The DT binding for the sensor when controlled
> from the main SoC describe the properties of the sensor that are
> required for that use case, and those only overlap slightly with the
> properties of the sensor needed by the AP1302. Using "compatible" in
> such a case would in my opinion be misleading as it would imply
> compatibility with the sensor DT binding.

Why not a new compatible (e.g. onnn,ar0144-isp)? Seems to me there would 
be at least some overlap. If there are supplies, then the names should 
be the same, right?

If you really want onnn,model, then that's fine. Probably there's not 
enough different sensors for me to really care...

Rob