Re: [PATCH v5 1/2] dt-bindings: display: bridge: lvds-codec: Document pixel data sampling edge select

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

 



On 10/27/21 1:43 AM, Laurent Pinchart wrote:

[...]

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" ?

I'm thinking about bridges that could have multiple parallel inputs.

Can you draft an example how such a binding would look like within the
confines of this lvds-codec.yaml ?

I also have to wonder how such a hypothetical device would work, would
it serialize two parallel bussed into single LVDS one ?

Such a device would require custom bindings I think, as lvds-codec is
limited to a single input and a single output. thine,thc63lvd1024.yaml
is an example of such a device.

It seems THC63LVD1024 is LVDS->to->Parallel DPI, so pclk-sample does not seem applicable there either.

[...]



[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