Re: [PATCH v4 1/2] dt-bindings: media: i2c: Add Mira016 image sensor

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

Hi Jacopo,

On Wed, Sep 09, 2026 at 09:35:52AM +0200, Jacopo Mondi wrote:
> Sakari,
> 
> On Tue, Sep 08, 2026 at 02:48:54PM +0300, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Sep 08, 2026 at 01:46:11PM +0200, Jacopo Mondi wrote:
> > > Hi Sakari
> > >
> > > On Tue, Sep 08, 2026 at 11:16:26AM +0300, Sakari Ailus wrote:
> > > > Hi Jacopo,
> > > >
> > > > On Tue, Sep 08, 2026 at 09:57:23AM +0200, Jacopo Mondi wrote:
> > > > > Add bindings for the ams OSRAM Mira016 image sensor.
> > > > >
> > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> > > > > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > > > > ---
> > > > >  .../devicetree/bindings/media/i2c/ams,mira016.yaml | 97 ++++++++++++++++++++++
> > > > >  MAINTAINERS                                        |  7 ++
> > > > >  2 files changed, 104 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml b/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..49a606fca6cb
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/i2c/ams,mira016.yaml
> > > > > @@ -0,0 +1,97 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/media/i2c/ams,mira016.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: AMS 0.16 MP NIR enhanced global shutter image sensor
> > > > > +
> > > > > +maintainers:
> > > > > +  - Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> > > > > +  - Philippe Baetens <philippebaetens@gmail.com>
> > > > > +
> > > > > +description:
> > > > > +  Mira016 is a 0.16 MP NIR enhanced global shutter image sensor designed for 2D
> > > > > +  and 3D consumer and industrial machine vision applications. The sensor is
> > > > > +  compliant to the MIPI CSI-2 v1.3 protocol interface and the D-PHY v1.2
> > > > > +  physical layer specifications to transmit the image data to the host
> > > > > +  processor. It uses one data lane and one clock lane operating up to 1.5 Gbps.
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: /schemas/media/video-interface-devices.yaml#
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: ams,mira016
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  clocks:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  vdd28-supply:
> > > > > +    description:
> > > > > +      I/O voltage supply, 2.8 volts
> > > > > +
> > > > > +  vdd11-supply:
> > > > > +    description:
> > > > > +      I/O voltage supply, 1.1 volts
> > > > > +
> > > > > +  reset-gpios:
> > > > > +    description: Sensor reset (RST_N) GPIO
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  port:
> > > > > +    $ref: /schemas/graph.yaml#/$defs/port-base
> > > > > +    additionalProperties: false
> > > > > +    description:
> > > > > +      Video output port
> > > > > +
> > > > > +    properties:
> > > > > +      endpoint:
> > > > > +        $ref: /schemas/media/video-interfaces.yaml#
> > > > > +        unevaluatedProperties: false
> > > > > +
> > > > > +        properties:
> > > > > +          data-lanes:
> > > > > +            items:
> > > > > +              - const: 1
> > > >
> > > > The device obviously supports non-continuous clock mode (and that's what
> > > > the driver also only does right now) but as the continous clock mode is
> > > > required by CSI-2, I presume the device can do both.
> > > >
> > > > So I think you should have
> > > >
> > > >              clock-noncontinuous: true
> > > >
> > > > here.
> > > >
> > >
> > > Maybe I'm confused (again, after 10 or so years of doing this) by the
> > > usage of unevaluatedProperties/additionalProperties, but if I read
> > > Documentation/devicetree/bindings/writing-schema.rst right
> > >
> > >   * unevaluatedProperties: false
> > >       Used when this binding references other schema whose all properties
> > >       should be allowed.
> > >
> > > Means all properties from video-interfaces.yaml are accepted (which is
> > > imho very wrong, but it's a battle with dt maintainers I don't want to
> > > start again).
> >
> > I guess you should have
> >
> > 		additionalProperties: false
> >
> > too?
> >
> 
> Where exactly do you mean ?
> 
> I don't think I can have additionalProperties: and
> unevaluatedProperties: in the same node, do I ?

Yes, these are mutually exclusive.

> 
> It's been a long time ago when we discussed with dt-maintainers what
> the policy should have been for endpoints that reference
> video-interfaces.yaml.
> 
> To me, the most sensible thing was to use "additionalProperties: false"
> and explicitly allow the supported properties, instead of allowing all
> of them. However dt maintainers had a different opinion (for reasons I
> honestly can't remember) and I think we have stabilized on the
> following pattern
> 
>         port:
>           $ref: /schemas/graph.yaml#/$defs/port-base
>           additionalProperties: false
> 
>           properties:
>             endpoint:
>               $ref: /schemas/media/video-interfaces.yaml#
>               unevaluatedProperties: false
> 
>               properties:
>                 ...
> 
> All the most recently merged bindings in media/i2c have this pattern
> 
> 42f83a32259a ("dt-bindings: media: i2c: Add Sony IMX678")
> 097d2be74ad0 ("dt-bindings: media: i2c: document Omnivision OV08D10 CMOS image sensor")
> 631dd79305ab ("dt-bindings: media: i2c: Add ov2732 image sensor")
> 
> I feel like I'm missing something obvious, otherwise I don't see why
> this binding should be different ?

Good question. Perhaps there was no specific thought given on
non-contiguous clock support? I guess most of the above should probably
specify it, even if the driver doesn't support it.

There's a good example of doing this in
Documentation/devicetree/bindings/media/i2c/ovti,ov5670.yaml, you're listed
as the maintainer there. :-)

-- 
Regards,

Sakari Ailus