Hi Jacopo, Rob, On Fri, Dec 04, 2020 at 10:44:08AM +0100, Jacopo Mondi wrote: > 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... The maximum value depends on the number of lanes in total in a device (which may well have several CSI-2 receivers) in case the lanes allocation to the receivers isn't static but configurable. Therefore I wouldn't put a maximum value for the array entries at all. If we want to improve the common case without indicating in DT whether lane reordering is supported (the driver already knows this as it knows its hardware), we could simply add another property to tell the number of lanes. It could be called e.g. num-data-lanes. The reason this hasn't been proposed has been that the information can already be conveyed with data-lanes property, but I think it'd be much easier to get it right. In that case clock-lanes wouldn't be used for such device either. > > > > > > 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 :) There are devices that use more lanes than the standard specifies. This is uncommon, but the common value there is 8, albeit it seems 7, 6 or 5 could also be supported. -- Kind regards, Sakari Ailus
