From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> To: dri-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org, Jacopo Mondi <jacopo+renesas@jmondi.org>, Kieran Bingham <kieran.bingham@ideasonboard.com>, devicetree@vger.kernel.org Subject: [PATCH v2 00/10] R-Car DU: LVDS dual-link mode support Date: Sun, 12 May 2019 00:06:52 +0300 [thread overview] Message-ID: <20190511210702.18394-1-laurent.pinchart+renesas@ideasonboard.com> (raw) 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 | 6 + .../display/bridge/thine,thc63lvd1024.txt | 6 + .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 ++- arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 + .../arm64/boot/dts/renesas/r8a77995-draak.dts | 21 ++- 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 | 123 +++++++++++++----- drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 + include/drm/drm_bridge.h | 8 ++ 12 files changed, 214 insertions(+), 48 deletions(-) -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> To: dri-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org, Kieran Bingham <kieran.bingham@ideasonboard.com>, Andrzej Hajda <a.hajda@samsung.com>, devicetree@vger.kernel.org, Jacopo Mondi <jacopo+renesas@jmondi.org> Subject: [PATCH v2 00/10] R-Car DU: LVDS dual-link mode support Date: Sun, 12 May 2019 00:06:52 +0300 [thread overview] Message-ID: <20190511210702.18394-1-laurent.pinchart+renesas@ideasonboard.com> (raw) 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 | 6 + .../display/bridge/thine,thc63lvd1024.txt | 6 + .../arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 ++- arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 + .../arm64/boot/dts/renesas/r8a77995-draak.dts | 21 ++- 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 | 123 +++++++++++++----- drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 + include/drm/drm_bridge.h | 8 ++ 12 files changed, 214 insertions(+), 48 deletions(-) -- Regards, Laurent Pinchart
next reply other threads:[~2019-05-11 21:06 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-11 21:06 Laurent Pinchart [this message] 2019-05-11 21:06 ` [PATCH v2 00/10] R-Car DU: LVDS dual-link mode support Laurent Pinchart 2019-05-11 21:06 ` [PATCH v2 01/10] drm: bridge: Add dual_link field to the drm_bridge_timings structure Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-11 21:06 ` [PATCH v2 02/10] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-12 8:58 ` Geert Uytterhoeven 2019-05-12 8:58 ` Geert Uytterhoeven 2019-05-12 10:22 ` Laurent Pinchart 2019-05-12 10:22 ` Laurent Pinchart 2019-05-14 20:17 ` Rob Herring 2019-05-14 20:17 ` Rob Herring 2019-05-11 21:06 ` [PATCH v2 03/10] drm: bridge: thc63: Report input bus mode through bridge timings Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-28 9:05 ` Jacopo Mondi 2019-05-28 9:05 ` Jacopo Mondi 2019-05-11 21:06 ` [PATCH v2 04/10] dt-bindings: display: renesas: lvds: Add renesas, companion property Laurent Pinchart 2019-05-11 21:06 ` [PATCH v2 04/10] dt-bindings: display: renesas: lvds: Add renesas,companion property Laurent Pinchart 2019-05-28 9:28 ` Jacopo Mondi 2019-05-28 9:28 ` Jacopo Mondi 2019-05-28 12:30 ` Laurent Pinchart 2019-05-28 12:30 ` Laurent Pinchart 2019-05-11 21:06 ` [PATCH v2 05/10] drm: rcar-du: lvds: Remove LVDS double-enable checks Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-28 9:40 ` Jacopo Mondi 2019-05-28 9:40 ` Jacopo Mondi 2019-05-11 21:06 ` [PATCH v2 06/10] drm: rcar-du: lvds: Add support for dual-link mode Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-28 9:35 ` Jacopo Mondi 2019-05-28 9:35 ` Jacopo Mondi 2019-05-28 12:46 ` Laurent Pinchart 2019-05-28 12:46 ` Laurent Pinchart 2019-05-11 21:06 ` [PATCH v2 07/10] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode Laurent Pinchart 2019-05-11 21:06 ` Laurent Pinchart 2019-05-28 9:38 ` Jacopo Mondi 2019-05-28 9:38 ` Jacopo Mondi 2019-05-11 21:07 ` [PATCH v2 08/10] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1 Laurent Pinchart 2019-05-11 21:07 ` Laurent Pinchart 2019-05-28 9:39 ` Jacopo Mondi 2019-05-28 9:39 ` Jacopo Mondi 2019-05-11 21:07 ` [PATCH v2 09/10] [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation Laurent Pinchart 2019-05-11 21:07 ` Laurent Pinchart 2019-05-11 21:07 ` [PATCH v2 10/10] [HACK] arm64: dts: renesas: ebisu: " Laurent Pinchart 2019-05-11 21:07 ` Laurent Pinchart 2019-05-12 8:55 ` [PATCH v2 00/10] R-Car DU: LVDS dual-link mode support Geert Uytterhoeven 2019-05-12 8:55 ` Geert Uytterhoeven 2019-05-12 10:15 ` Laurent Pinchart 2019-05-12 10:15 ` Laurent Pinchart 2019-05-28 10:20 ` Jacopo Mondi 2019-05-28 10:20 ` Jacopo Mondi
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=20190511210702.18394-1-laurent.pinchart+renesas@ideasonboard.com \ --to=laurent.pinchart+renesas@ideasonboard.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=jacopo+renesas@jmondi.org \ --cc=kieran.bingham@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.