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

[Marek Vasut]

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 at 0
>>>>>>>>            - port at 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.

[...]