From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Vasut <marex@denx.de>
Cc: dri-devel@lists.freedesktop.org, Rob Herring <robh+dt@kernel.org>,
Sam Ravnborg <sam@ravnborg.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v5 1/2] dt-bindings: display: bridge: lvds-codec: Document pixel data sampling edge select
Date: Tue, 19 Oct 2021 09:49:57 +0300 [thread overview]
Message-ID: <YW5qlXPyy6ZOHS6N@pendragon.ideasonboard.com> (raw)
In-Reply-To: <4f235f45-5c03-eaeb-69ac-3d801a1dd58c@denx.de>
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
next prev parent reply other threads:[~2021-10-19 6:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-17 0:12 [PATCH v5 1/2] dt-bindings: display: bridge: lvds-codec: Document pixel data sampling edge select Marek Vasut
2021-10-17 0:12 ` [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for " Marek Vasut
2021-10-17 16:49 ` Sam Ravnborg
2021-10-17 17:29 ` Marek Vasut
2021-10-17 17:40 ` Sam Ravnborg
2021-10-17 20:05 ` Marek Vasut
2021-10-23 23:04 ` Marek Vasut
2021-11-24 3:02 ` Marek Vasut
2021-12-07 17:30 ` Marek Vasut
2021-10-18 17:54 ` [PATCH v5 1/2] dt-bindings: display: bridge: lvds-codec: Document " Rob Herring
2021-10-18 18:08 ` Laurent Pinchart
2021-10-18 19:47 ` Marek Vasut
2021-10-18 19:57 ` Laurent Pinchart
2021-10-18 22:18 ` Marek Vasut
2021-10-19 6:49 ` Laurent Pinchart [this message]
2021-10-19 14:39 ` Marek Vasut
2021-10-26 23:43 ` Laurent Pinchart
2021-10-27 12:29 ` Marek Vasut
-- strict thread matches above, loose matches on Subject: below --
2021-06-02 20:36 [PATCH V5 " Marek Vasut
2021-06-10 16:09 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YW5qlXPyy6ZOHS6N@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=marex@denx.de \
--cc=robh+dt@kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox