devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support
@ 2019-05-28 14:12 Laurent Pinchart
  2019-05-28 14:12 ` [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Laurent Pinchart @ 2019-05-28 14:12 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, devicetree, Jacopo Mondi, Kieran Bingham

Hello everybody,

This patch series implements support for LVDS dual-link mode in the
R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
LVDS decoder driver.

LVDS dual-link is a mode of operation where two individual LVDS links
are operated together to carry even- and odd-numbered pixels separately.
This doubles the possible bandwidth of the video transmission. Both the
transmitter and the receiver need to support this mode of operation.

The R-Car D3 and E3 SoCs include two independent LVDS encoders that can
be grouped together to operate in dual-link mode. When used separately,
the LVDS encoders are connected to two different CRTCs and transmit
independent video streams. When used in dual-link mode, the first LVDS
encoder is connected to the first CRTC, and split even- and odd-numbered
pixels. It transmits half of the pixels on its LVDS output, and sends
the other half to the second LVDS encoder for transmittion over the
second LVDS link. The second LVDS encoder thus operates under control of
the first one, and isn't connected directly to a CRTC.

On the receiving side, the THC63LVD1024 LVDS-to-parallel bridge has two
LVDS inputs and two parallel outputs. It can operate in four different
modes:

- Single-in, single-out: The first LVDS input receives the video stream,
  and the bridge outputs it on the first parallel output. The second
  LVDS input and the second parallel output are not used.

- Single-in, dual-out: The first LVDS input receives the video stream,
  and the bridge splits even- and odd-numbered pixels and outputs them
  on the first and second parallel outputs. The second LVDS input is not
  used.

- Dual-in, single-out: The two LVDS inputs are used in dual-link mode,
  and the bridge combines the even- and odd-numbered pixels and outputs
  them on the first parallel output. The second parallel output is not
  used.

- Dual-in, dual-out: The two LVDS inputs are used in dual-link mode,
  and the bridge outputs the even- and odd-numbered pixels on the first
  parallel output.

The operating mode is selected by two input pins of the bridge, which
are connected to DIP switches on the development boards I use. The mode
is thus fixed from a Linux point of view.

Patch 01/10 adds a new dual_link boolen field to the drm_bridge_timings
structure to let bridges report their LVDS mode of operation. Patch
02/10 clarifies the THC63LVD1024 DT bindings to document dual-link
operation, and patch 03/10 implements dual-link support in the
thc64lvd1024 bridge driver by setting the drm_bridge_timings dual_link
field according to the mode selected through DT.

Patch 04/10 extends the R-Car LVDS DT bindings to specify the companion
LVDS encoder for dual-link operation. Patches 05/10 then performs a
small cleanup in the LVDS encoder driver. Patch 06/10 implements
dual-link support in the LVDS encoder driver, which involves retrieving
the operation mode from the LVDS receiver, locating the companion LVDS
encoder, and configuring both encoders when dual-link operation is
desired. The API towards the DU driver is also extended to report the
mode of operation.

Patch 07/10 implements dual-link mode support in the DU driver. There is
no specific configuration to be performed there, as dual-link is fully
implemented in the LVDS encoder driver, but the DU driver has to skip
creation of the DRM encoder and connector related to the second LVDS
encoder when dual-link is used, as the second LVDS encoder operates as a
slave of the first one, transparently from a CRTC (and thus userspace)
perspective.

Patch 08/10 specifies the companion LVDS encoder in the D3 and E3 DT
bindings. This by itself doesn't enable dual-link mode, the LVDS0
encoder is still connected to the HDMI output through LVDS receiver, and
the LVDS1 encoder is not used. Patches 09/10 and 10/10, not intended to
be merged, enable dual-link operation for the D3 and E3 boards for
testing and require flipping DIP switches on the boards.

The patches are based on top of my drm/du/next branch, and are available
for convenience at

        git://linuxtv.org/pinchartl/media.git drm/du/lvds/dual-link

They have been tested successfully on the D3 Draak board. I expect them
to work on E3 as well, but I don't have access to an Ebisu board to test
this.

Laurent Pinchart (10):
  drm: bridge: Add dual_link field to the drm_bridge_timings structure
  dt-bindings: display: bridge: thc63lvd1024: Document dual-link
    operation
  drm: bridge: thc63: Report input bus mode through bridge timings
  dt-bindings: display: renesas: lvds: Add renesas,companion property
  drm: rcar-du: lvds: Remove LVDS double-enable checks
  drm: rcar-du: lvds: Add support for dual-link mode
  drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
  arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1
  [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation
  [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation

 .../bindings/display/bridge/renesas,lvds.txt  |   7 +
 .../display/bridge/thine,thc63lvd1024.txt     |   6 +
 .../arm64/boot/dts/renesas/r8a77990-ebisu.dts |  24 +++-
 arch/arm64/boot/dts/renesas/r8a77990.dtsi     |   2 +
 .../arm64/boot/dts/renesas/r8a77995-draak.dts |  24 +++-
 arch/arm64/boot/dts/renesas/r8a77995.dtsi     |   2 +
 drivers/gpu/drm/bridge/thc63lvd1024.c         |  54 ++++++--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c     |  12 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c         |   2 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c           | 126 +++++++++++++-----
 drivers/gpu/drm/rcar-du/rcar_lvds.h           |   5 +
 include/drm/drm_bridge.h                      |   8 ++
 12 files changed, 214 insertions(+), 58 deletions(-)

-- 
Regards,

Laurent Pinchart

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
  2019-05-28 14:12 [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart
@ 2019-05-28 14:12 ` Laurent Pinchart
  2019-06-07 22:15   ` Kieran Bingham
  2019-05-28 14:12 ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 15+ messages in thread
From: Laurent Pinchart @ 2019-05-28 14:12 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, devicetree, Jacopo Mondi, Kieran Bingham

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>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
index 37f0c04d5a28..d17d1e5820d7 100644
--- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -28,6 +28,12 @@ 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.
+
 Example:
 --------
 
-- 
Regards,

Laurent Pinchart

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

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-05-28 14:12 [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart
  2019-05-28 14:12 ` [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
@ 2019-05-28 14:12 ` Laurent Pinchart
  2019-05-28 16:37   ` Sam Ravnborg
  2019-06-07 22:33   ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas,companion property Kieran Bingham
  2019-05-28 16:46 ` [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Sam Ravnborg
  2019-06-07 22:16 ` Kieran Bingham
  3 siblings, 2 replies; 15+ messages in thread
From: Laurent Pinchart @ 2019-05-28 14:12 UTC (permalink / raw)
  To: dri-devel
  Cc: linux-renesas-soc, devicetree, Jacopo Mondi, Jacopo Mondi,
	Kieran Bingham

Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.

The new property doesn't control the mode of operation, it only
describes the relationship between the master and companion LVDS
encoders.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Changes since v2:

- Clarify when the companion property is required or not allowed

Changes since v1:

- Fixed typo
---
 .../devicetree/bindings/display/bridge/renesas,lvds.txt    | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
index 900a884ad9f5..2d24bd8cbec5 100644
--- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -45,6 +45,13 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
 
 Each port shall have a single endpoint.
 
+Optional properties:
+
+- renesas,companion : phandle to the companion LVDS encoder. This property is
+  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
+  the second encoder to be used as a companion in dual-link mode. It shall not
+  be set for any other LVDS encoder.
+
 
 Example:
 
-- 
Regards,

Laurent Pinchart

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

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-05-28 14:12 ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
@ 2019-05-28 16:37   ` Sam Ravnborg
  2019-05-28 16:49     ` Laurent Pinchart
  2019-06-07 22:33   ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas,companion property Kieran Bingham
  1 sibling, 1 reply; 15+ messages in thread
From: Sam Ravnborg @ 2019-05-28 16:37 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: devicetree, Jacopo Mondi, Kieran Bingham, dri-devel,
	linux-renesas-soc, Jacopo Mondi

Hi Laurent.

Reading through this nice series.

On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> Add a new optional renesas,companion property to point to the companion
> LVDS encoder. This is used to support dual-link operation where the main
> LVDS encoder splits even-numbered and odd-numbered pixels between the
> two LVDS encoders.
> 
> The new property doesn't control the mode of operation, it only
> describes the relationship between the master and companion LVDS
> encoders.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Changes since v2:
> 
> - Clarify when the companion property is required or not allowed
> 
> Changes since v1:
> 
> - Fixed typo
> ---
>  .../devicetree/bindings/display/bridge/renesas,lvds.txt    | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> index 900a884ad9f5..2d24bd8cbec5 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -45,6 +45,13 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>  
>  Each port shall have a single endpoint.
>  
> +Optional properties:
> +
> +- renesas,companion : phandle to the companion LVDS encoder. This property is
> +  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> +  the second encoder to be used as a companion in dual-link mode. It shall not
> +  be set for any other LVDS encoder.

If the D3 and E3 socs do not mandate the use of dual-link, then what to
do in the DT? Because according to the above this property must be
specified for D3 and E3 SOC's.

> +
>  
>  Example:

Always good with examples, maybe it comes later.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support
  2019-05-28 14:12 [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart
  2019-05-28 14:12 ` [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
  2019-05-28 14:12 ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
@ 2019-05-28 16:46 ` Sam Ravnborg
  2019-06-07 22:16 ` Kieran Bingham
  3 siblings, 0 replies; 15+ messages in thread
From: Sam Ravnborg @ 2019-05-28 16:46 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: linux-renesas-soc, devicetree, Jacopo Mondi, Kieran Bingham,
	dri-devel

Hi Laurent.

Nice series with small and well described patches.

> On Tue, May 28, 2019 at 05:12:24PM +0300, Laurent Pinchart wrote:
>> Hello everybody,
>> 
>> This patch series implements support for LVDS dual-link mode in the
>> R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
>> LVDS decoder driver.

Patches looks good.
With my few comments addressed:
Acked-by: Sam Ravnborg <sam@ravnborg.org>

(Do not feel too confident in all the stuff, r-b seems to give me too
much credit for spending less than half an hour reading the patches).

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-05-28 16:37   ` Sam Ravnborg
@ 2019-05-28 16:49     ` Laurent Pinchart
  2019-05-28 16:59       ` Sam Ravnborg
  0 siblings, 1 reply; 15+ messages in thread
From: Laurent Pinchart @ 2019-05-28 16:49 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: devicetree, Jacopo Mondi, Laurent Pinchart, Kieran Bingham,
	dri-devel, linux-renesas-soc, Jacopo Mondi

Hi Sam,

On Tue, May 28, 2019 at 06:37:30PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation where the main
> > LVDS encoder splits even-numbered and odd-numbered pixels between the
> > two LVDS encoders.
> > 
> > The new property doesn't control the mode of operation, it only
> > describes the relationship between the master and companion LVDS
> > encoders.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > Changes since v2:
> > 
> > - Clarify when the companion property is required or not allowed
> > 
> > Changes since v1:
> > 
> > - Fixed typo
> > ---
> >  .../devicetree/bindings/display/bridge/renesas,lvds.txt    | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > index 900a884ad9f5..2d24bd8cbec5 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > @@ -45,6 +45,13 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> >  
> >  Each port shall have a single endpoint.
> >  
> > +Optional properties:
> > +
> > +- renesas,companion : phandle to the companion LVDS encoder. This property is
> > +  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> > +  the second encoder to be used as a companion in dual-link mode. It shall not
> > +  be set for any other LVDS encoder.
> 
> If the D3 and E3 socs do not mandate the use of dual-link, then what to
> do in the DT? Because according to the above this property must be
> specified for D3 and E3 SOC's.

This property doesn't enable dual-link mode, it only specifies the
companion LVDS encoder used for dual-link mode, when enabled (through
communication between the LVDS encoder and the LVDS receiver at
runtime).

Jacopo had a similar comment so I suppose this isn't clear. How would
you word it to make it clear ?

> > +
> >  
> >  Example:
> 
> Always good with examples, maybe it comes later.

Good point, I'll fix that.

-- 
Regards,

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-05-28 16:49     ` Laurent Pinchart
@ 2019-05-28 16:59       ` Sam Ravnborg
  2019-06-06  7:54         ` Laurent Pinchart
  0 siblings, 1 reply; 15+ messages in thread
From: Sam Ravnborg @ 2019-05-28 16:59 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: devicetree, Jacopo Mondi, Laurent Pinchart, Kieran Bingham,
	dri-devel, linux-renesas-soc, Jacopo Mondi

Hi Laurent.

> > >  
> > > +Optional properties:
> > > +
> > > +- renesas,companion : phandle to the companion LVDS encoder. This property is
> > > +  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> > > +  the second encoder to be used as a companion in dual-link mode. It shall not
> > > +  be set for any other LVDS encoder.
> > 
> > If the D3 and E3 socs do not mandate the use of dual-link, then what to
> > do in the DT? Because according to the above this property must be
> > specified for D3 and E3 SOC's.
> 
> This property doesn't enable dual-link mode, it only specifies the
> companion LVDS encoder used for dual-link mode, when enabled (through
> communication between the LVDS encoder and the LVDS receiver at
> runtime).
> 
> Jacopo had a similar comment so I suppose this isn't clear. How would
> you word it to make it clear ?
Let me try:


- renesas,companion : phandle to the companion LVDS encoder. This property is
  mandatory for the first LVDS encoder on D3 and E3 SoCs when dual-link mode
  is supported.
  The property shall pont to the phandle of the second encoder to be used as a
  companion in dual-link mode. It shall not be set for any other LVDS encoder.

The main difference is "when dual-link mode is supported".
As per my understanding this property is only relevant when the actual
HW supports / uses dual-link mode.
So for a board that do not even wire up dual-link, then setting the
property would be confusing.

I hope this better describes my understanding.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-05-28 16:59       ` Sam Ravnborg
@ 2019-06-06  7:54         ` Laurent Pinchart
  2019-06-06  9:27           ` Sam Ravnborg
  0 siblings, 1 reply; 15+ messages in thread
From: Laurent Pinchart @ 2019-06-06  7:54 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: devicetree, Jacopo Mondi, Laurent Pinchart, Kieran Bingham,
	dri-devel, linux-renesas-soc, Jacopo Mondi

Hi Sam,

On Tue, May 28, 2019 at 06:59:00PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
> 
> > > >  
> > > > +Optional properties:
> > > > +
> > > > +- renesas,companion : phandle to the companion LVDS encoder. This property is
> > > > +  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> > > > +  the second encoder to be used as a companion in dual-link mode. It shall not
> > > > +  be set for any other LVDS encoder.
> > > 
> > > If the D3 and E3 socs do not mandate the use of dual-link, then what to
> > > do in the DT? Because according to the above this property must be
> > > specified for D3 and E3 SOC's.
> > 
> > This property doesn't enable dual-link mode, it only specifies the
> > companion LVDS encoder used for dual-link mode, when enabled (through
> > communication between the LVDS encoder and the LVDS receiver at
> > runtime).
> > 
> > Jacopo had a similar comment so I suppose this isn't clear. How would
> > you word it to make it clear ?
> 
> Let me try:
> 
> - renesas,companion : phandle to the companion LVDS encoder. This property is
>   mandatory for the first LVDS encoder on D3 and E3 SoCs when dual-link mode
>   is supported.
>   The property shall pont to the phandle of the second encoder to be used as a
>   companion in dual-link mode. It shall not be set for any other LVDS encoder.
> 
> The main difference is "when dual-link mode is supported".
> As per my understanding this property is only relevant when the actual
> HW supports / uses dual-link mode.
> So for a board that do not even wire up dual-link, then setting the
> property would be confusing.

That's not quite correct. The property shall be specified when the SoC
supports dual-link mode (which is the case for the D3 and E3 SoCs only),
regardless of whether the board is wired up in single-link or dual-link
mode. Selection of the mode is performed at runtime by looking at the
requirements of the LVDS sink, not based on the companion property in
DT. The renesas,companion property is thus SoC-specific, but not
board-specific.

> I hope this better describes my understanding.

-- 
Regards,

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property
  2019-06-06  7:54         ` Laurent Pinchart
@ 2019-06-06  9:27           ` Sam Ravnborg
  0 siblings, 0 replies; 15+ messages in thread
From: Sam Ravnborg @ 2019-06-06  9:27 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: devicetree, Jacopo Mondi, Laurent Pinchart, Kieran Bingham,
	dri-devel, linux-renesas-soc, Jacopo Mondi

Hi Laurent.

> > 
> > The main difference is "when dual-link mode is supported".
> > As per my understanding this property is only relevant when the actual
> > HW supports / uses dual-link mode.
> > So for a board that do not even wire up dual-link, then setting the
> > property would be confusing.
> 
> That's not quite correct. The property shall be specified when the SoC
> supports dual-link mode (which is the case for the D3 and E3 SoCs only),
> regardless of whether the board is wired up in single-link or dual-link
> mode. Selection of the mode is performed at runtime by looking at the
> requirements of the LVDS sink, not based on the companion property in
> DT. The renesas,companion property is thus SoC-specific, but not
> board-specific.
Thanks for taking your time to clarify this.

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
  2019-05-28 14:12 ` [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
@ 2019-06-07 22:15   ` Kieran Bingham
  2019-06-07 22:30     ` Laurent Pinchart
  0 siblings, 1 reply; 15+ messages in thread
From: Kieran Bingham @ 2019-06-07 22:15 UTC (permalink / raw)
  To: Laurent Pinchart, dri-devel; +Cc: linux-renesas-soc, devicetree, Jacopo Mondi

Hi Laurent,

On 28/05/2019 15:12, 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>
> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> index 37f0c04d5a28..d17d1e5820d7 100644
> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -28,6 +28,12 @@ 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.
> +

Your cover letter details 4 different modes of operation for this part.

Do you anticipate the other combinations {Single-in, dual-out; dual-in,
dual-out} being supported? Perhaps that would be defined by the relevant
endpoints being connected or not ?


You state that in dual-link mode, both port@0, and port@1 shall contain
endpoints, so that implies that you only expect to support dual-in with
the 'dual-link' property. If that is correct, should it be stated
explicitly?


Otherwise,

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>


>  Example:
>  --------
>  
> 

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support
  2019-05-28 14:12 [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart
                   ` (2 preceding siblings ...)
  2019-05-28 16:46 ` [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Sam Ravnborg
@ 2019-06-07 22:16 ` Kieran Bingham
  2019-06-07 22:21   ` Laurent Pinchart
  3 siblings, 1 reply; 15+ messages in thread
From: Kieran Bingham @ 2019-06-07 22:16 UTC (permalink / raw)
  To: Laurent Pinchart, dri-devel; +Cc: linux-renesas-soc, devicetree, Jacopo Mondi

Hi Laurent,

On 28/05/2019 15:12, Laurent Pinchart wrote:
> Hello everybody,
> 
> This patch series implements support for LVDS dual-link mode in the
> R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
> LVDS decoder driver.
> 
> LVDS dual-link is a mode of operation where two individual LVDS links
> are operated together to carry even- and odd-numbered pixels separately.
> This doubles the possible bandwidth of the video transmission. Both the
> transmitter and the receiver need to support this mode of operation.
> 
> The R-Car D3 and E3 SoCs include two independent LVDS encoders that can
> be grouped together to operate in dual-link mode. When used separately,
> the LVDS encoders are connected to two different CRTCs and transmit
> independent video streams. When used in dual-link mode, the first LVDS
> encoder is connected to the first CRTC, and split even- and odd-numbered
> pixels. It transmits half of the pixels on its LVDS output, and sends
> the other half to the second LVDS encoder for transmittion over the
> second LVDS link. The second LVDS encoder thus operates under control of
> the first one, and isn't connected directly to a CRTC.
> 
> On the receiving side, the THC63LVD1024 LVDS-to-parallel bridge has two
> LVDS inputs and two parallel outputs. It can operate in four different
> modes:
> 
> - Single-in, single-out: The first LVDS input receives the video stream,
>   and the bridge outputs it on the first parallel output. The second
>   LVDS input and the second parallel output are not used.
> 
> - Single-in, dual-out: The first LVDS input receives the video stream,
>   and the bridge splits even- and odd-numbered pixels and outputs them
>   on the first and second parallel outputs. The second LVDS input is not
>   used.
> 
> - Dual-in, single-out: The two LVDS inputs are used in dual-link mode,
>   and the bridge combines the even- and odd-numbered pixels and outputs
>   them on the first parallel output. The second parallel output is not
>   used.
> 
> - Dual-in, dual-out: The two LVDS inputs are used in dual-link mode,
>   and the bridge outputs the even- and odd-numbered pixels on the first
>   parallel output.


Clarifying this, having checked with you, Dual-in, dual-out means 'even
pixels are received on the first input, and provided on the first
output, and odd pixels are received on the second input, and provided on
the second output'.


> The operating mode is selected by two input pins of the bridge, which
> are connected to DIP switches on the development boards I use. The mode
> is thus fixed from a Linux point of view.

Would there ever by a scenario where these could be connected to GPIO's
and changed dynamically? I guess that might not make much sense - as the
configuration is more use case dependant.


> Patch 01/10 adds a new dual_link boolen field to the drm_bridge_timings
> structure to let bridges report their LVDS mode of operation. Patch
> 02/10 clarifies the THC63LVD1024 DT bindings to document dual-link
> operation, and patch 03/10 implements dual-link support in the
> thc64lvd1024 bridge driver by setting the drm_bridge_timings dual_link
> field according to the mode selected through DT.
> 
> Patch 04/10 extends the R-Car LVDS DT bindings to specify the companion
> LVDS encoder for dual-link operation. Patches 05/10 then performs a
> small cleanup in the LVDS encoder driver. Patch 06/10 implements
> dual-link support in the LVDS encoder driver, which involves retrieving
> the operation mode from the LVDS receiver, locating the companion LVDS
> encoder, and configuring both encoders when dual-link operation is
> desired. The API towards the DU driver is also extended to report the
> mode of operation.
> 
> Patch 07/10 implements dual-link mode support in the DU driver. There is
> no specific configuration to be performed there, as dual-link is fully
> implemented in the LVDS encoder driver, but the DU driver has to skip
> creation of the DRM encoder and connector related to the second LVDS
> encoder when dual-link is used, as the second LVDS encoder operates as a
> slave of the first one, transparently from a CRTC (and thus userspace)
> perspective.
> 
> Patch 08/10 specifies the companion LVDS encoder in the D3 and E3 DT
> bindings. This by itself doesn't enable dual-link mode, the LVDS0
> encoder is still connected to the HDMI output through LVDS receiver, and
> the LVDS1 encoder is not used. Patches 09/10 and 10/10, not intended to
> be merged, enable dual-link operation for the D3 and E3 boards for
> testing and require flipping DIP switches on the boards.
> 
> The patches are based on top of my drm/du/next branch, and are available
> for convenience at
> 
>         git://linuxtv.org/pinchartl/media.git drm/du/lvds/dual-link
> 
> They have been tested successfully on the D3 Draak board. I expect them
> to work on E3 as well, but I don't have access to an Ebisu board to test
> this.
> 
> Laurent Pinchart (10):
>   drm: bridge: Add dual_link field to the drm_bridge_timings structure
>   dt-bindings: display: bridge: thc63lvd1024: Document dual-link
>     operation
>   drm: bridge: thc63: Report input bus mode through bridge timings
>   dt-bindings: display: renesas: lvds: Add renesas,companion property
>   drm: rcar-du: lvds: Remove LVDS double-enable checks
>   drm: rcar-du: lvds: Add support for dual-link mode
>   drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
>   arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1
>   [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation
>   [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> 
>  .../bindings/display/bridge/renesas,lvds.txt  |   7 +
>  .../display/bridge/thine,thc63lvd1024.txt     |   6 +
>  .../arm64/boot/dts/renesas/r8a77990-ebisu.dts |  24 +++-
>  arch/arm64/boot/dts/renesas/r8a77990.dtsi     |   2 +
>  .../arm64/boot/dts/renesas/r8a77995-draak.dts |  24 +++-
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi     |   2 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c         |  54 ++++++--
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c     |  12 ++
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c         |   2 +-
>  drivers/gpu/drm/rcar-du/rcar_lvds.c           | 126 +++++++++++++-----
>  drivers/gpu/drm/rcar-du/rcar_lvds.h           |   5 +
>  include/drm/drm_bridge.h                      |   8 ++
>  12 files changed, 214 insertions(+), 58 deletions(-)
> 

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support
  2019-06-07 22:16 ` Kieran Bingham
@ 2019-06-07 22:21   ` Laurent Pinchart
  0 siblings, 0 replies; 15+ messages in thread
From: Laurent Pinchart @ 2019-06-07 22:21 UTC (permalink / raw)
  To: Kieran Bingham
  Cc: devicetree, Laurent Pinchart, dri-devel, linux-renesas-soc,
	Jacopo Mondi

Hi Kieran,

On Fri, Jun 07, 2019 at 11:16:37PM +0100, Kieran Bingham wrote:
> On 28/05/2019 15:12, Laurent Pinchart wrote:
> > Hello everybody,
> > 
> > This patch series implements support for LVDS dual-link mode in the
> > R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
> > LVDS decoder driver.
> > 
> > LVDS dual-link is a mode of operation where two individual LVDS links
> > are operated together to carry even- and odd-numbered pixels separately.
> > This doubles the possible bandwidth of the video transmission. Both the
> > transmitter and the receiver need to support this mode of operation.
> > 
> > The R-Car D3 and E3 SoCs include two independent LVDS encoders that can
> > be grouped together to operate in dual-link mode. When used separately,
> > the LVDS encoders are connected to two different CRTCs and transmit
> > independent video streams. When used in dual-link mode, the first LVDS
> > encoder is connected to the first CRTC, and split even- and odd-numbered
> > pixels. It transmits half of the pixels on its LVDS output, and sends
> > the other half to the second LVDS encoder for transmittion over the
> > second LVDS link. The second LVDS encoder thus operates under control of
> > the first one, and isn't connected directly to a CRTC.
> > 
> > On the receiving side, the THC63LVD1024 LVDS-to-parallel bridge has two
> > LVDS inputs and two parallel outputs. It can operate in four different
> > modes:
> > 
> > - Single-in, single-out: The first LVDS input receives the video stream,
> >   and the bridge outputs it on the first parallel output. The second
> >   LVDS input and the second parallel output are not used.
> > 
> > - Single-in, dual-out: The first LVDS input receives the video stream,
> >   and the bridge splits even- and odd-numbered pixels and outputs them
> >   on the first and second parallel outputs. The second LVDS input is not
> >   used.
> > 
> > - Dual-in, single-out: The two LVDS inputs are used in dual-link mode,
> >   and the bridge combines the even- and odd-numbered pixels and outputs
> >   them on the first parallel output. The second parallel output is not
> >   used.
> > 
> > - Dual-in, dual-out: The two LVDS inputs are used in dual-link mode,
> >   and the bridge outputs the even- and odd-numbered pixels on the first
> >   parallel output.
> 
> Clarifying this, having checked with you, Dual-in, dual-out means 'even
> pixels are received on the first input, and provided on the first
> output, and odd pixels are received on the second input, and provided on
> the second output'.

Yes, my bad, this is wrong in the cover letter.

> > The operating mode is selected by two input pins of the bridge, which
> > are connected to DIP switches on the development boards I use. The mode
> > is thus fixed from a Linux point of view.
> 
> Would there ever by a scenario where these could be connected to GPIO's
> and changed dynamically? I guess that might not make much sense - as the
> configuration is more use case dependant.

This can't be ruled out, but the use cases would indeed be limited. If
the need ever arises, we can just extend the DT bindings to specify
those GPIOs, and add a new in-kernel API at the drm_bridge level to
configure the mode dynamically.

> > Patch 01/10 adds a new dual_link boolen field to the drm_bridge_timings
> > structure to let bridges report their LVDS mode of operation. Patch
> > 02/10 clarifies the THC63LVD1024 DT bindings to document dual-link
> > operation, and patch 03/10 implements dual-link support in the
> > thc64lvd1024 bridge driver by setting the drm_bridge_timings dual_link
> > field according to the mode selected through DT.
> > 
> > Patch 04/10 extends the R-Car LVDS DT bindings to specify the companion
> > LVDS encoder for dual-link operation. Patches 05/10 then performs a
> > small cleanup in the LVDS encoder driver. Patch 06/10 implements
> > dual-link support in the LVDS encoder driver, which involves retrieving
> > the operation mode from the LVDS receiver, locating the companion LVDS
> > encoder, and configuring both encoders when dual-link operation is
> > desired. The API towards the DU driver is also extended to report the
> > mode of operation.
> > 
> > Patch 07/10 implements dual-link mode support in the DU driver. There is
> > no specific configuration to be performed there, as dual-link is fully
> > implemented in the LVDS encoder driver, but the DU driver has to skip
> > creation of the DRM encoder and connector related to the second LVDS
> > encoder when dual-link is used, as the second LVDS encoder operates as a
> > slave of the first one, transparently from a CRTC (and thus userspace)
> > perspective.
> > 
> > Patch 08/10 specifies the companion LVDS encoder in the D3 and E3 DT
> > bindings. This by itself doesn't enable dual-link mode, the LVDS0
> > encoder is still connected to the HDMI output through LVDS receiver, and
> > the LVDS1 encoder is not used. Patches 09/10 and 10/10, not intended to
> > be merged, enable dual-link operation for the D3 and E3 boards for
> > testing and require flipping DIP switches on the boards.
> > 
> > The patches are based on top of my drm/du/next branch, and are available
> > for convenience at
> > 
> >         git://linuxtv.org/pinchartl/media.git drm/du/lvds/dual-link
> > 
> > They have been tested successfully on the D3 Draak board. I expect them
> > to work on E3 as well, but I don't have access to an Ebisu board to test
> > this.
> > 
> > Laurent Pinchart (10):
> >   drm: bridge: Add dual_link field to the drm_bridge_timings structure
> >   dt-bindings: display: bridge: thc63lvd1024: Document dual-link
> >     operation
> >   drm: bridge: thc63: Report input bus mode through bridge timings
> >   dt-bindings: display: renesas: lvds: Add renesas,companion property
> >   drm: rcar-du: lvds: Remove LVDS double-enable checks
> >   drm: rcar-du: lvds: Add support for dual-link mode
> >   drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode
> >   arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1
> >   [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation
> >   [HACK] arm64: dts: renesas: ebisu: Enable LVDS dual-link operation
> > 
> >  .../bindings/display/bridge/renesas,lvds.txt  |   7 +
> >  .../display/bridge/thine,thc63lvd1024.txt     |   6 +
> >  .../arm64/boot/dts/renesas/r8a77990-ebisu.dts |  24 +++-
> >  arch/arm64/boot/dts/renesas/r8a77990.dtsi     |   2 +
> >  .../arm64/boot/dts/renesas/r8a77995-draak.dts |  24 +++-
> >  arch/arm64/boot/dts/renesas/r8a77995.dtsi     |   2 +
> >  drivers/gpu/drm/bridge/thc63lvd1024.c         |  54 ++++++--
> >  drivers/gpu/drm/rcar-du/rcar_du_encoder.c     |  12 ++
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c         |   2 +-
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c           | 126 +++++++++++++-----
> >  drivers/gpu/drm/rcar-du/rcar_lvds.h           |   5 +
> >  include/drm/drm_bridge.h                      |   8 ++
> >  12 files changed, 214 insertions(+), 58 deletions(-)

-- 
Regards,

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
  2019-06-07 22:15   ` Kieran Bingham
@ 2019-06-07 22:30     ` Laurent Pinchart
  2019-06-07 22:36       ` Kieran Bingham
  0 siblings, 1 reply; 15+ messages in thread
From: Laurent Pinchart @ 2019-06-07 22:30 UTC (permalink / raw)
  To: Kieran Bingham
  Cc: devicetree, Laurent Pinchart, dri-devel, linux-renesas-soc,
	Jacopo Mondi

Hi Kieran,

On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
> On 28/05/2019 15:12, 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>
> > Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > index 37f0c04d5a28..d17d1e5820d7 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -28,6 +28,12 @@ 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.
> > +
> 
> Your cover letter details 4 different modes of operation for this part.
> 
> Do you anticipate the other combinations {Single-in, dual-out; dual-in,
> dual-out} being supported? Perhaps that would be defined by the relevant
> endpoints being connected or not ?

I expect that someone might need those modes at some point, but I
haven't specified them on purpose, as I don't like writing DT bindings
that can't be tested. I however expoect that those additional modes can
be derived from the connected endpoints.

> You state that in dual-link mode, both port@0, and port@1 shall contain
> endpoints, so that implies that you only expect to support dual-in with
> the 'dual-link' property. If that is correct, should it be stated
> explicitly?

What do you mean by the 'dual-link' property ? The patch series defines
no such property.

> Otherwise,
> 
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> 
> >  Example:
> >  --------
> >  

-- 
Regards,

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas,companion property
  2019-05-28 14:12 ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
  2019-05-28 16:37   ` Sam Ravnborg
@ 2019-06-07 22:33   ` Kieran Bingham
  1 sibling, 0 replies; 15+ messages in thread
From: Kieran Bingham @ 2019-06-07 22:33 UTC (permalink / raw)
  To: Laurent Pinchart, dri-devel
  Cc: linux-renesas-soc, devicetree, Jacopo Mondi, Jacopo Mondi

Hi Laurent,

On 28/05/2019 15:12, Laurent Pinchart wrote:
> Add a new optional renesas,companion property to point to the companion
> LVDS encoder. This is used to support dual-link operation where the main
> LVDS encoder splits even-numbered and odd-numbered pixels between the
> two LVDS encoders.
> 
> The new property doesn't control the mode of operation, it only
> describes the relationship between the master and companion LVDS
> encoders.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Changes since v2:
> 
> - Clarify when the companion property is required or not allowed
> 
> Changes since v1:
> 
> - Fixed typo
> ---
>  .../devicetree/bindings/display/bridge/renesas,lvds.txt    | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> index 900a884ad9f5..2d24bd8cbec5 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> @@ -45,6 +45,13 @@ OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>  
>  Each port shall have a single endpoint.
>  
> +Optional properties:
> +> +- renesas,companion : phandle to the companion LVDS encoder. This
property is
> +  mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
> +  the second encoder to be used as a companion in dual-link mode. It shall not
> +  be set for any other LVDS encoder.
> +

I see Sam has already asked for an updated example, so with that:

I'm fine with the text above.

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

>  
>  Example:
>  
> 

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation
  2019-06-07 22:30     ` Laurent Pinchart
@ 2019-06-07 22:36       ` Kieran Bingham
  0 siblings, 0 replies; 15+ messages in thread
From: Kieran Bingham @ 2019-06-07 22:36 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: devicetree, Laurent Pinchart, dri-devel, linux-renesas-soc,
	Jacopo Mondi

Hi Laurent,

On 07/06/2019 23:30, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
>> On 28/05/2019 15:12, 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>
>>> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> ---
>>>  .../bindings/display/bridge/thine,thc63lvd1024.txt          | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> index 37f0c04d5a28..d17d1e5820d7 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>> @@ -28,6 +28,12 @@ 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.
>>> +
>>
>> Your cover letter details 4 different modes of operation for this part.
>>
>> Do you anticipate the other combinations {Single-in, dual-out; dual-in,
>> dual-out} being supported? Perhaps that would be defined by the relevant
>> endpoints being connected or not ?
> 
> I expect that someone might need those modes at some point, but I
> haven't specified them on purpose, as I don't like writing DT bindings
> that can't be tested. I however expoect that those additional modes can
> be derived from the connected endpoints.
> 
>> You state that in dual-link mode, both port@0, and port@1 shall contain
>> endpoints, so that implies that you only expect to support dual-in with
>> the 'dual-link' property. If that is correct, should it be stated
>> explicitly?
> 
> What do you mean by the 'dual-link' property ? The patch series defines
> no such property.

Aha, my imagination is creating something from all the references to the
word 'dual-link' :-D

Ok - so it is just the existence of the endpoints which will
enable//configure the various modes of operation.

I guess that will become more clear when I get down to the driver patches :)



> 
>> Otherwise,
>>
>> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>>
>>>  Example:
>>>  --------
>>>  
> 

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2019-06-07 22:36 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-28 14:12 [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart
2019-05-28 14:12 ` [PATCH v3 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
2019-06-07 22:15   ` Kieran Bingham
2019-06-07 22:30     ` Laurent Pinchart
2019-06-07 22:36       ` Kieran Bingham
2019-05-28 14:12 ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart
2019-05-28 16:37   ` Sam Ravnborg
2019-05-28 16:49     ` Laurent Pinchart
2019-05-28 16:59       ` Sam Ravnborg
2019-06-06  7:54         ` Laurent Pinchart
2019-06-06  9:27           ` Sam Ravnborg
2019-06-07 22:33   ` [PATCH v3 04/10] dt-bindings: display: renesas: lvds: Add renesas,companion property Kieran Bingham
2019-05-28 16:46 ` [PATCH v3 00/10] R-Car DU: LVDS dual-link mode support Sam Ravnborg
2019-06-07 22:16 ` Kieran Bingham
2019-06-07 22:21   ` Laurent Pinchart

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