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

[Marek Vasut]

On 10/19/21 8:49 AM, Laurent Pinchart wrote:
> Hi Marek,

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

>>> , 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.
> 
> DT bindings are not holy beings that live in a mythical heaven way above
> the mere mortal drivers, they would be useless without implementations.
> It's not about bending them, which I regularly push against during
> review, but about structuring them in a way that facilitates
> implementations when all other things are equal.

Note that the pclk-sample isn't a property of the input, but of the 
chip, I don't think it is a good idea to say they are equal and conflate 
them like so.

> As I said, despite wondering whether or not it would be better to move
> the property to the endpoint (and that was a genuine open question), I
> won't insist in this case.

[...]