Hi Marek, On Tue, Oct 19, 2021 at 12:18:11AM +0200, Marek Vasut wrote: > 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@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. > > , 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. 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
