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

Marek Vasut marex at denx.de
Mon Oct 18 22:18:11 UTC 2021


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

> , 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.


More information about the dri-devel mailing list