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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Oct 19, 2021 at 04:39:05PM +0200, Marek Vasut wrote:
> 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@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.

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

With a chip that has a single input, that's always the case :-)

Anyway, I don't mind a chip-level property for this binding as we're
limited to a single port. If other devices need to specify this at the
port level, I'm sure we'll be able to cope with the lack of uniformity.

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

-- 
Regards,

Laurent Pinchart