dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: devicetree@vger.kernel.org,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	dri-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	Jacopo Mondi <jacopo+renesas@jmondi.org>
Subject: Re: [PATCH/RFC 05/15] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
Date: Sat, 9 Mar 2019 13:51:28 +0200	[thread overview]
Message-ID: <20190309115128.GC4924@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190309112308.rbuqwvvvxgihmj7d@uno.localdomain>

Hi Jacopo,

On Sat, Mar 09, 2019 at 12:23:08PM +0100, Jacopo Mondi wrote:
> On Fri, Mar 08, 2019 at 07:57:39PM +0200, Laurent Pinchart wrote:
> > On Fri, Mar 08, 2019 at 05:49:25PM +0100, Jacopo Mondi wrote:
> >> On Thu, Mar 07, 2019 at 01:23:35AM +0200, Laurent Pinchart wrote:
> >>> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> >>> dual-link. In dual-link mode both input ports are used to carry even-
> >>> and odd-numbered pixels separately. Document this in the DT bindings,
> >>> along with the related rules governing port and usage.
> >>>
> >>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >>> ---
> >>>  .../bindings/display/bridge/thine,thc63lvd1024.txt         | 7 +++++++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> index 37f0c04d5a28..4ff6eb9bbc19 100644
> >>> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -28,6 +28,13 @@ Optional video port nodes:
> >>>  - port@1: Second LVDS input port
> >>>  - port@3: Second digital CMOS/TTL parallel output
> >>>
> >>> +The device can operate in single-link mode or dual-link mode. In single-link
> >>> +mode, all pixels are received on port@0, and port@1 shall not contain any
> >>> +endpoint. In dual-link mode, even-numbered pixels are received on port@0 and
> >>> +odd-numbered pixels on port@1, and both port@0 and port@1 shall contain
> >>> +endpoints.
> >>
> >> You know, I'm not sure this is helpful, as if we have to go and
> >> describe what the chip supports, a paragraph for dual ouput mode would
> >> be required as well. The bindings already document that the chip
> >> supports single/dual input/output modes, maybe you can just add rules
> >> that prescribes how to populate the endpoints, for both input and
> >> output modes?
> >
> > That's what I was trying to do :-) How else would you like to see it
> > described ?
> 
> I wonder if it won't be enough to expand the Optional endpoint
> properties description as in:
> 
>  - port@1: Second LVDS input port, to be used for dual-input mode
>  - port@3: Second digital CMOS/TTL parallel output, to be used for
>    dual-output mode.

I think it's useful to explain the constraints regarding presence (or
absence) of endpoints for ports 0 and 1 depending on which mode the
device operates under, not just what the ports are used for.

> If you prefer providing more context, it's fine what you had, just
> keep in mind there's also dual-output mode and not just the dual-input
> one.

Absolutely. The reason why I haven't expanded the bindings to document
dual-output mode is that I have no way to test it, and I don't think
untested bindings (meaning without a testable end-to-end implementation)
are a good idea.

> Up to you, feel free to add my
> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> if relevant.
> 
> >>> +
> >>> +
> >>
> >> You can drop this empty line.
> >>
> >>>  Example:
> >>>  --------
> >>>

-- 
Regards,

Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-03-09 11:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 23:23 [PATCH/RFC 00/15] R-Car DU: LVDS dual-link mode support Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 01/15] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham
2019-03-06 23:23 ` [PATCH/RFC 02/15] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham
2019-05-11 20:44     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 03/15] drm/bridge: use bus flags in bridge timings Laurent Pinchart
2019-04-24  8:13   ` Kieran Bingham
2019-03-06 23:23 ` [PATCH/RFC 04/15] drm: bridge: Add dual_link field to the drm_bridge_timings structure Laurent Pinchart
2019-04-24  8:12   ` Kieran Bingham
2019-05-11 20:36     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 05/15] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
2019-03-08 16:49   ` Jacopo Mondi
2019-03-08 17:57     ` Laurent Pinchart
2019-03-09 11:23       ` Jacopo Mondi
2019-03-09 11:51         ` Laurent Pinchart [this message]
2019-03-06 23:23 ` [PATCH/RFC 06/15] drm: bridge: thc63: Report input bus mode through bridge timings Laurent Pinchart
2019-03-08 17:32   ` Jacopo Mondi
2019-03-08 18:00     ` Laurent Pinchart
2019-03-09 11:24       ` Jacopo Mondi
2019-03-09 11:45         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
2019-03-18 10:21   ` [PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas,companion property Geert Uytterhoeven
2019-03-18 14:22     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 08/15] drm: rcar-du: lvds: Remove LVDS double-enable checks Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 09/15] drm: rcar-du: lvds: Adjust operating frequency for D3 and E3 Laurent Pinchart
2019-03-08 16:28   ` Jacopo Mondi
2019-03-06 23:23 ` [PATCH/RFC 10/15] drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3 Laurent Pinchart
2019-03-08 16:25   ` Jacopo Mondi
2019-03-08 18:07     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 11/15] drm: rcar-du: lvds: Add support for dual-link mode Laurent Pinchart
2019-03-08 17:20   ` Jacopo Mondi
2019-03-08 18:12     ` Laurent Pinchart
2019-03-09 11:11       ` Jacopo Mondi
2019-03-09 11:25         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 12/15] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 13/15] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1 Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 14/15] [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 15/15] [HACK] arm64: dts: renesas: ebisu: " Laurent Pinchart

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=20190309115128.GC4924@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacopo+renesas@jmondi.org \
    --cc=jacopo@jmondi.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).