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