And another thing:
On Tue, May 18, 2021 at 02:02:24AM +0300, Laurent Pinchart wrote:
On Sat, May 15, 2021 at 10:46:55PM +0200, Marek Vasut wrote:
Decoder input LVDS format is a property of the decoder chip or even its strapping. Add DT property data-mapping the same way lvds-panel does, to define the LVDS data mapping.
The information could also be derived by the driver from the compatible string in the case when this is an intrinsic property of the device (or when it's configurable by software), but the fact that it can also be controlled by strapping makes a DT property needed. We may want to limit the usage of the DT property to the strapping case though, but I don't have a real preference here, so I'm fine with this approach.
Signed-off-by: Marek Vasut marex@denx.de Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Rob Herring robh+dt@kernel.org Cc: Sam Ravnborg sam@ravnborg.org Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org
.../bindings/display/bridge/lvds-codec.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index f4dd16bd69d2..f0abb94f8f2e 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -64,6 +64,15 @@ properties: - port@0 - port@1
- data-mapping:
- enum:
- jeida-18- jeida-24- vesa-24- description: |
The color signals mapping order. See details inDocumentation/devicetree/bindings/display/panel/lvds.yaml- pclk-sample: description: Data sampling on rising or falling edge.
@@ -79,6 +88,16 @@ properties:
power-supply: true
+if:
- not:
- properties:
compatible:contains:const: lvds-decoder+then:
- properties:
- data-mapping: false
Should we make the property required for lvds-decoder ? We need to support backward compatibility in the driver, but from a DT bindings point of view, should all new DTs require the property ?
if: not: properties:
Unless I'm mistaken, you can't have identically named properties at the same level (multiple 'if' at the root level). You can group them in a 'allOf' property.