Re: [PATCH v2 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob,

[snip]

> > > +  data-lanes:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > > +    minItems: 1
> > > +    maxItems: 4
> > > +    items:
> > > +      # Assume up to 4 data and 1 clock lane
> > > +      maximum: 4
> > > +    description:
> > > +      An array of physical data lane indexes. Position of an entry determines
> > > +      the logical lane number, while the value of an entry indicates physical
> > > +      lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;",
> > > +      assuming the clock lane is on hardware lane 0. If the hardware does not
> > > +      support lane reordering, monotonically incremented values shall be used
> > > +      from 0 or 1 onwards, depending on whether or not there is also a clock
> > > +      lane. This property is valid for serial busses only (e.g. MIPI CSI-2).
> >
> > This won't flag [1, 3] as wrong, right ?
>
> Right. In theory you could have hardware that does this, right? You
> could pick and choose which lanes to use.

You could if your platform supports lane re-ordering (iirc there's a
single device that supports that in mainline)

My (badly worded) question is: do we expect users to define the valid
values as here below reported ? Or are we happy with 'maximum: 2' ?

If we ask users to provide the valid arrays, we get an ugly DTS and,
more problematically, this has be noticed and suggested during
reviews likely for every submission, this is all but intuitive and
most platforms don't support lane re-ordering, most if not all will
have to limit the property supported values. We get DTS validation in
exchange.

If we're fine with just having the maximum value specified, we lose
dts validation but it really gets less clunky for DTS. Run-time handling
for drivers won't change much, as devices that don't support lane
re-ordering mostly care about the number of active lanes.

It's more a policy question than a technical one...

>
> > I guess the only alternative is the ugly:
> >
> >             anyOf:
> >               - items:
> >                 - const: 1
> >               - items:
> >                 - const: 1
> >                 - const: 2
> >               - items:
> >                 - const: 1
> >                 - const: 2
> >                 - const: 3
> >               - items:
> >                 - const: 1
> >                 - const: 2
> >                 - const: 3
> >                 - const: 4
> >
> > As we express "monotonically incremented" I think it's fine, even if
> > validation won't catch it.
> >
> > Also, sakari just pointed me to the just merged
> > Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:
> >
> >           data-lanes:
> >             minItems: 1
> >             maxItems: 8
> >
> > sakari, where does 8 come from ? Afaik D-PHY supports 4 differential
> > data lanes, and C-PHY 3 'trios'
>
> Okay, let me know what values to put here.
>

I'll defer this to Sakari :)

Thanks
   j



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux