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.
[...]