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: 10+ 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-vA1bhqPz9FBZXbeN9DUtxg
[not found] ` <ec9676f344eb4786a28a3c7b969f0e94-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
2016-12-30 14:27 ` Shawn Guo [this message]
2017-01-23 5:24 ` Shawn Guo
[not found] ` <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
2017-01-03 20:23 ` Christopher Spinrath
2017-01-16 20:12 ` Christopher Spinrath
2017-01-17 8:57 ` Philipp Zabel
[not found] ` <88bdfd5321484efc82af4132ac2f0d7e@rwthex-s1-b.rwth-ad.de>
[not found] ` <88bdfd5321484efc82af4132ac2f0d7e-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
2017-01-17 18:35 ` Christopher Spinrath
[not found] ` <6ed3f695104044f18e98fc9619aab16e@rwthex-s1-b.rwth-ad.de>
2017-01-18 22:20 ` Christopher Spinrath
[not found] ` <17a7f9cea35944288f97735e66859929-gtPewvpZjL8umhiu9RXYRl5UTUQ924AY@public.gmane.org>
2017-01-19 14:34 ` Philipp Zabel
[not found] ` <7b5acaa225ee4e068ae058e8aaf49a44@rwthex-w2-b.rwth-ad.de>
2017-01-22 12:51 ` Christopher Spinrath
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-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=christopher.spinrath-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=fabio.estevam-3arQi8VN3Tc@public.gmane.org \
--cc=grinberg-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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).