On 10/18/21 9:57 PM, Laurent Pinchart wrote:
Hi,
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -79,6 +79,14 @@ properties:
- port@0
- port@1
+ pclk-sample:
+ description:
+ Data sampling on rising or falling edge.
+ enum:
+ - 0 # Falling edge
+ - 1 # Rising edge
+ default: 0
+
Shouldn't this be moved to the endpoint, the same way data-mapping is
defined as an endpoint property ?
The strapping is a chip property, not port property, so no.
For this particular chip that's true. I'm still not convinced overall.
For some cases it could be a per-port property
Can you be more specific about "some cases" ?
, and moving it there for
lvds-codec too could allow implementing helpers to parse DT properties,
without much drawback for this particular use case as far as I can see.
It's hard to predict the future with certainty of course, so I won't
insist.
The DT bindings and the OS drivers are separate thing, we really
shouldn't start bending DT bindings so that they would fit nicely with a
specific OS driver model.
