From: shawnguo@kernel.org (Shawn Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
Date: Fri, 30 Dec 2016 22:27:11 +0800 [thread overview]
Message-ID: <20161230142708.GU6177@dragon> (raw)
In-Reply-To: <ec9676f344eb4786a28a3c7b969f0e94@rwthex-s1-b.rwth-ad.de>
On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath at rwth-aachen.de wrote:
> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> Apart from the already enabled Designware HDMI port, the Utilite Pro
> has a second display pipeline which has the following shape:
>
> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
> --> HDMI connector.
> Enable support for it.
>
> In addition, since this pipeline is hardwired to IPU1, sever the link
> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
> possible to drive both displays at high resolution due to the bandwidth
> limitations of a single IPU.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
@Philipp, can you help review the changes?
> ---
>
> Hi all,
>
> the removal of the link between IPU1 and the Designware HDMI encoder is the
> result of a discussion I had with Philipp Zabel:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>
> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
> approach has at least one disadvantage: if the resolution is low enough such
> that a single IPU can handle both displays then muxing both displays to IPU1
> would reduce the power consumption.
>
> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
> solution since I'm not aware of any OS/driver that is capable of switching IPUs
> or can handle the bandwidth limitation in a sane way. In particular, Linux is
> unusable when both displays are supposed to be driven at high resolution and
> both muxing options for the DW HDMI are available (this is not a userspace
> issue; the system becomes almost unresponsive as soon as the kernel sets the
> initial resolution).
>
> Cheers,
> Christopher
>
> P.S.: this patch depends on the tfp410 bridge driver which has recently been
> merged into drm-next.
v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 2200994..69bdd82 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -59,6 +59,33 @@
> rtc1 = &snvs_rtc;
> };
>
> + encoder {
> + compatible = "ti,tfp410";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint {
> + remote-endpoint = <¶llel_display_out>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> @@ -72,6 +99,19 @@
> };
> };
>
> + hdmi-connector {
> + compatible = "hdmi-connector";
> +
The newline is unnecessary.
> + type = "a";
> + ddc-i2c-bus = <&i2c_dvi_ddc>;
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> + };
> +
> i2cmux {
> compatible = "i2c-mux-gpio";
> pinctrl-names = "default";
> @@ -105,8 +145,46 @@
> #size-cells = <0>;
> };
> };
> +
> + parallel-display {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1>;
> +
Ditto
I can fix them up if I get a Reviewed-by tag from Philipp on this
version.
Shawn
> + interface-pix-fmt = "rgb24";
> +
> + port at 0 {
> + reg = <0>;
> +
> + parallel_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> +
> + parallel_display_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + };
> + };
> + };
> };
>
> +/*
> + * A single IPU is not able to drive both display interfaces available on the
> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
> + * IPU2 instead of IPU1.
> + */
> +/delete-node/&ipu1_di0_hdmi;
> +/delete-node/&hdmi_mux_0;
> +/delete-node/&ipu1_di1_hdmi;
> +/delete-node/&hdmi_mux_1;
> +
> &hdmi {
> ddc-i2c-bus = <&i2c2>;
> status = "okay";
> @@ -151,6 +229,39 @@
> >;
> };
>
> + pinctrl_ipu1: ipu1grp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
> + >;
> + };
> +
> pinctrl_uart2: uart2grp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
> @@ -194,6 +305,10 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <¶llel_display_in>;
> +};
> +
> &pcie {
> pcie at 0,0 {
> reg = <0x000000 0 0 0 0>;
> --
> 2.10.2
>
WARNING: multiple messages have this Message-ID (diff)
From: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
grinberg-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org,
fabio.estevam-3arQi8VN3Tc@public.gmane.org
Subject: Re: [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
Date: Fri, 30 Dec 2016 22:27:11 +0800 [thread overview]
Message-ID: <20161230142708.GU6177@dragon> (raw)
In-Reply-To: <ec9676f344eb4786a28a3c7b969f0e94-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org wrote:
> From: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
>
> Apart from the already enabled Designware HDMI port, the Utilite Pro
> has a second display pipeline which has the following shape:
>
> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
> --> HDMI connector.
> Enable support for it.
>
> In addition, since this pipeline is hardwired to IPU1, sever the link
> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
> possible to drive both displays at high resolution due to the bandwidth
> limitations of a single IPU.
>
> Signed-off-by: Christopher Spinrath <christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>
@Philipp, can you help review the changes?
> ---
>
> Hi all,
>
> the removal of the link between IPU1 and the Designware HDMI encoder is the
> result of a discussion I had with Philipp Zabel:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>
> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
> approach has at least one disadvantage: if the resolution is low enough such
> that a single IPU can handle both displays then muxing both displays to IPU1
> would reduce the power consumption.
>
> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
> solution since I'm not aware of any OS/driver that is capable of switching IPUs
> or can handle the bandwidth limitation in a sane way. In particular, Linux is
> unusable when both displays are supposed to be driven at high resolution and
> both muxing options for the DW HDMI are available (this is not a userspace
> issue; the system becomes almost unresponsive as soon as the kernel sets the
> initial resolution).
>
> Cheers,
> Christopher
>
> P.S.: this patch depends on the tfp410 bridge driver which has recently been
> merged into drm-next.
v4.10-rc1 has the driver, so the dependency is gone now, I guess.
>
> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 2200994..69bdd82 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -59,6 +59,33 @@
> rtc1 = &snvs_rtc;
> };
>
> + encoder {
> + compatible = "ti,tfp410";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint {
> + remote-endpoint = <¶llel_display_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
> pinctrl-names = "default";
> @@ -72,6 +99,19 @@
> };
> };
>
> + hdmi-connector {
> + compatible = "hdmi-connector";
> +
The newline is unnecessary.
> + type = "a";
> + ddc-i2c-bus = <&i2c_dvi_ddc>;
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> + };
> +
> i2cmux {
> compatible = "i2c-mux-gpio";
> pinctrl-names = "default";
> @@ -105,8 +145,46 @@
> #size-cells = <0>;
> };
> };
> +
> + parallel-display {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ipu1>;
> +
Ditto
I can fix them up if I get a Reviewed-by tag from Philipp on this
version.
Shawn
> + interface-pix-fmt = "rgb24";
> +
> + port@0 {
> + reg = <0>;
> +
> + parallel_display_in: endpoint {
> + remote-endpoint = <&ipu1_di0_disp0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + parallel_display_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + };
> + };
> + };
> };
>
> +/*
> + * A single IPU is not able to drive both display interfaces available on the
> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
> + * IPU2 instead of IPU1.
> + */
> +/delete-node/&ipu1_di0_hdmi;
> +/delete-node/&hdmi_mux_0;
> +/delete-node/&ipu1_di1_hdmi;
> +/delete-node/&hdmi_mux_1;
> +
> &hdmi {
> ddc-i2c-bus = <&i2c2>;
> status = "okay";
> @@ -151,6 +229,39 @@
> >;
> };
>
> + pinctrl_ipu1: ipu1grp {
> + fsl,pins = <
> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
> + >;
> + };
> +
> pinctrl_uart2: uart2grp {
> fsl,pins = <
> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
> @@ -194,6 +305,10 @@
> };
> };
>
> +&ipu1_di0_disp0 {
> + remote-endpoint = <¶llel_display_in>;
> +};
> +
> &pcie {
> pcie@0,0 {
> reg = <0x000000 0 0 0 0>;
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-12-30 14:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-02 14:37 [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline christopher.spinrath at rwth-aachen.de
2016-12-02 14:37 ` christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg
2016-12-30 14:27 ` Shawn Guo [this message]
2016-12-30 14:27 ` Shawn Guo
[not found] ` <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
2017-01-03 20:23 ` Christopher Spinrath
2017-01-03 20:23 ` Christopher Spinrath
2017-01-16 20:12 ` Christopher Spinrath
2017-01-16 20:12 ` Christopher Spinrath
2017-01-17 8:57 ` Philipp Zabel
2017-01-17 8:57 ` Philipp Zabel
[not found] ` <88bdfd5321484efc82af4132ac2f0d7e@rwthex-s1-b.rwth-ad.de>
2017-01-17 18:35 ` Christopher Spinrath
2017-01-17 18:35 ` Christopher Spinrath
[not found] ` <6ed3f695104044f18e98fc9619aab16e@rwthex-s1-b.rwth-ad.de>
2017-01-18 22:20 ` Christopher Spinrath
2017-01-18 22:20 ` Christopher Spinrath
2017-01-19 14:34 ` Philipp Zabel
2017-01-19 14:34 ` Philipp Zabel
[not found] ` <7b5acaa225ee4e068ae058e8aaf49a44@rwthex-w2-b.rwth-ad.de>
2017-01-22 12:51 ` Christopher Spinrath
2017-01-22 12:51 ` Christopher Spinrath
2017-01-23 5:24 ` Shawn Guo
2017-01-23 5:24 ` Shawn Guo
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=20161230142708.GU6177@dragon \
--to=shawnguo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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 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.