Hi Boris, Thank you for the patch. On Tue, Jan 28, 2020 at 02:55:11PM +0100, Boris Brezillon wrote: > Add the bus-width property to describe the input bus format. > > v10: > * Add changelog to the commit message > * Add Rob's R-b > > v8 -> v9: > * No changes > > v7: > * Rebase on top of lvds-codec changes > * Drop the data-mapping property > > v4 -> v6: > * Not part of the series > > v3: > * New patch > > Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > --- > .../devicetree/bindings/display/bridge/lvds-codec.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > index 8f373029f5d2..7c4e42f4de61 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > @@ -55,6 +55,14 @@ properties: > description: | > For LVDS encoders, port 0 is the parallel input > For LVDS decoders, port 0 is the LVDS input > + properties: > + bus-width: > + allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > + - enum: [18, 24] > + - default: 24 > + description: > + Number of data lines used to transmit the RGB data. This is a bit unclear. First of all, depending on whether the node is an LVDS encoder or decoder, port@0 is either a parallel input or an LVDS input. The property mentiones RGB data, does it mean it apply to LVDS encoders only ? Or should it be in port@1 for LVDS decoders ? Then, I'm not sure what the property describes. Is it the number of data lanes that the chip has ? Or the number of lanes routed on the board ? Should it be specified only if the number of lanes on the board is different than the maximum number of lanes of the hardware ? A more detailed description is needed. Updating the example would also be useful. > > port@1: > type: object -- Regards, Laurent Pinchart