| Message ID | a19c5b2ddac542dc92e3827fbf1eaba1@rwthex-s1-b.rwth-ad.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Philipp, thanks for your answer! On 11/29/2016 05:38 PM, Philipp Zabel wrote: > Hi Christopher, > > Am Dienstag, den 29.11.2016, 16:45 +0100 schrieb Christopher Spinrath: >> Hi all, >> >> I am trying to enable the second display pipeline of my imx6q based >> Utilite Pro. I appended a devicetree patch to this email for reference. >> >> While it works perfectly on its own there occur kernel warnings (see >> below) if both pipelines are connected. Furthermore, the machine becomes >> almost unresponsive. Note that these warnings start to happen around the >> time getty is started. No other userspace stuff (e.g. X11) is involved. >> >> I can make it work by adding the following hack to the devicetree: >> >> display-subsystem { >> compatible = "fsl,imx-display-subsystem"; >> ports = <&ipu1_di0>, <&ipu2_di0>, <&ipu2_di1>, <&ipu1_di1>; >> }; >> >> (i.e. reordering the ports of the display-subsystem.) >> >> To my understanding the imx drm driver maps both outputs to ipu1 by >> default which cannot handle the load. > > What is the load? I meant the workload of an ipu when driving both outputs. My setup consists of two displays set to the mode 1920x1200@60Hz. >> But using ipu1 and ipu2 for a >> single output each works. Unfortunately, I didn't find a way to model >> this restriction in the devicetree (in a sane way). > > You can sever the links between HDMI encoder mux and IPU1 display > interfaces to keep it from being connected to IPU1 DI1: > > /delete-node/&ipu1_di0_hdmi; > /delete-node/&hdmi_mux_0; > > /delete-node/&ipu1_di1_hdmi; > /delete-node/&hdmi_mux_1; Great! That works and is better than the display-subsystem workaround (for the record the syntax is wrong; I had to use the node names not the labels). >> IMHO the driver should at least disable one of the outputs instead of >> rendering the whole system unusable. Optimally, it should figure out a >> correct mapping between outputs and ipu's itself. > > It should. The problem with the IPU limitations is that they are > cross-crtc. The reference manual says that the maximum combined rate for > both display interfaces in an IPU is 240 MP/s, so we'd need to take into > account the pixel clocks of already enabled sibling crtcs when deciding > whether a mode can be set. So deleting the links between HDMI encoder mux and IPU1 in the devicetree is the way to go/the preferred solution? Cheers, Christopher > regards > Philipp >
Am Dienstag, den 29.11.2016, 18:37 +0100 schrieb Christopher Spinrath: > Hi Philipp, > > thanks for your answer! > > On 11/29/2016 05:38 PM, Philipp Zabel wrote: > > Hi Christopher, > > > > Am Dienstag, den 29.11.2016, 16:45 +0100 schrieb Christopher Spinrath: > >> Hi all, > >> > >> I am trying to enable the second display pipeline of my imx6q based > >> Utilite Pro. I appended a devicetree patch to this email for reference. > >> > >> While it works perfectly on its own there occur kernel warnings (see > >> below) if both pipelines are connected. Furthermore, the machine becomes > >> almost unresponsive. Note that these warnings start to happen around the > >> time getty is started. No other userspace stuff (e.g. X11) is involved. > >> > >> I can make it work by adding the following hack to the devicetree: > >> > >> display-subsystem { > >> compatible = "fsl,imx-display-subsystem"; > >> ports = <&ipu1_di0>, <&ipu2_di0>, <&ipu2_di1>, <&ipu1_di1>; > >> }; > >> > >> (i.e. reordering the ports of the display-subsystem.) > >> > >> To my understanding the imx drm driver maps both outputs to ipu1 by > >> default which cannot handle the load. > > > > What is the load? > > I meant the workload of an ipu when driving both outputs. My setup > consists of two displays set to the mode 1920x1200@60Hz. Thanks, that is what I meant to ask. Just to be sure that the issue really is the IPU throughput limitation. > >> But using ipu1 and ipu2 for a > >> single output each works. Unfortunately, I didn't find a way to model > >> this restriction in the devicetree (in a sane way). > > > > You can sever the links between HDMI encoder mux and IPU1 display > > interfaces to keep it from being connected to IPU1 DI1: > > > > /delete-node/&ipu1_di0_hdmi; > > /delete-node/&hdmi_mux_0; > > > > /delete-node/&ipu1_di1_hdmi; > > /delete-node/&hdmi_mux_1; > > Great! That works and is better than the display-subsystem workaround > (for the record the syntax is wrong; I had to use the node names not the > labels). When I drop these lines into imx6q-nitrogen6x.dts verbatim, the referenced endpoint nodes are removed from the dtb as expected. > >> IMHO the driver should at least disable one of the outputs instead of > >> rendering the whole system unusable. Optimally, it should figure out a > >> correct mapping between outputs and ipu's itself. > > > > It should. The problem with the IPU limitations is that they are > > cross-crtc. The reference manual says that the maximum combined rate for > > both display interfaces in an IPU is 240 MP/s, so we'd need to take into > > account the pixel clocks of already enabled sibling crtcs when deciding > > whether a mode can be set. > > So deleting the links between HDMI encoder mux and IPU1 in the > devicetree is the way to go/the preferred solution? For the ipu1_di0, yes. As you have the tfp410 connected to DI0, I'd say there's really no reason to ever mux HDMI to IPU1 DI0 on this board. For IPU1 DI1 it is arguable. If the chosen resolution was low enough it would be possible to drive both outputs from IPU1, and depending on the use case it might be preferrable (to reduce power consumption, or if IPU2 was to be used for an LVDS display, for example). regards Philipp
Hi Philipp, On 11/30/2016 10:45 AM, Philipp Zabel wrote: > Am Dienstag, den 29.11.2016, 18:37 +0100 schrieb Christopher Spinrath: >> Hi Philipp, >> >> thanks for your answer! >> >> On 11/29/2016 05:38 PM, Philipp Zabel wrote: >>> Hi Christopher, >>> >>> Am Dienstag, den 29.11.2016, 16:45 +0100 schrieb Christopher Spinrath: >>>> Hi all, >>>> >>>> I am trying to enable the second display pipeline of my imx6q based >>>> Utilite Pro. I appended a devicetree patch to this email for reference. >>>> >>>> While it works perfectly on its own there occur kernel warnings (see >>>> below) if both pipelines are connected. Furthermore, the machine becomes >>>> almost unresponsive. Note that these warnings start to happen around the >>>> time getty is started. No other userspace stuff (e.g. X11) is involved. >>>> >>>> I can make it work by adding the following hack to the devicetree: >>>> >>>> display-subsystem { >>>> compatible = "fsl,imx-display-subsystem"; >>>> ports = <&ipu1_di0>, <&ipu2_di0>, <&ipu2_di1>, <&ipu1_di1>; >>>> }; >>>> >>>> (i.e. reordering the ports of the display-subsystem.) >>>> >>>> To my understanding the imx drm driver maps both outputs to ipu1 by >>>> default which cannot handle the load. >>> >>> What is the load? >> >> I meant the workload of an ipu when driving both outputs. My setup >> consists of two displays set to the mode 1920x1200@60Hz. > > Thanks, that is what I meant to ask. Just to be sure that the issue > really is the IPU throughput limitation. > >>>> But using ipu1 and ipu2 for a >>>> single output each works. Unfortunately, I didn't find a way to model >>>> this restriction in the devicetree (in a sane way). >>> >>> You can sever the links between HDMI encoder mux and IPU1 display >>> interfaces to keep it from being connected to IPU1 DI1: >>> >>> /delete-node/&ipu1_di0_hdmi; >>> /delete-node/&hdmi_mux_0; >>> >>> /delete-node/&ipu1_di1_hdmi; >>> /delete-node/&hdmi_mux_1; >> >> Great! That works and is better than the display-subsystem workaround >> (for the record the syntax is wrong; I had to use the node names not the >> labels). > > When I drop these lines into imx6q-nitrogen6x.dts verbatim, the > referenced endpoint nodes are removed from the dtb as expected. Oh, you're right. I placed these lines inside the root node / and dtc failed with the very helpful "syntax error" error message... Sorry about that. >>>> IMHO the driver should at least disable one of the outputs instead of >>>> rendering the whole system unusable. Optimally, it should figure out a >>>> correct mapping between outputs and ipu's itself. >>> >>> It should. The problem with the IPU limitations is that they are >>> cross-crtc. The reference manual says that the maximum combined rate for >>> both display interfaces in an IPU is 240 MP/s, so we'd need to take into >>> account the pixel clocks of already enabled sibling crtcs when deciding >>> whether a mode can be set. >> >> So deleting the links between HDMI encoder mux and IPU1 in the >> devicetree is the way to go/the preferred solution? > > For the ipu1_di0, yes. As you have the tfp410 connected to DI0, I'd say > there's really no reason to ever mux HDMI to IPU1 DI0 on this board. > > For IPU1 DI1 it is arguable. If the chosen resolution was low enough it > would be possible to drive both outputs from IPU1, and depending on the > use case it might be preferrable (to reduce power consumption, or if > IPU2 was to be used for an LVDS display, for example). Ok. The Utilite does not expose any kind of interface to connect LVDS, CSI, or anything else to the IPUs except for the HDMI connectors. So the only disadvantage I can think of is the increased power consumption. I guess I will simply submit a patch as soon as the tfp410 bridge driver has been merged and include the imx maintainers in the discussion. Thanks, Christopher > regards > Philipp >
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts index 2200994..0bd068b 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"; + + 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,6 +145,32 @@ #size-cells = <0>; }; }; + + parallel-display { + compatible = "fsl,imx-parallel-display"; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ipu1_1>; + + 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>; + }; + }; + }; }; &hdmi { @@ -151,6 +217,39 @@ >; }; + pinctrl_ipu1_1: ipu1grp-1 { + 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 +293,10 @@ }; }; +&ipu1_di0_disp0 { + remote-endpoint = <¶llel_display_in>; +}; + &pcie { pcie@0,0 { reg = <0x000000 0 0 0 0>;
Hi all, I am trying to enable the second display pipeline of my imx6q based Utilite Pro. I appended a devicetree patch to this email for reference. While it works perfectly on its own there occur kernel warnings (see below) if both pipelines are connected. Furthermore, the machine becomes almost unresponsive. Note that these warnings start to happen around the time getty is started. No other userspace stuff (e.g. X11) is involved. I can make it work by adding the following hack to the devicetree: display-subsystem { compatible = "fsl,imx-display-subsystem"; ports = <&ipu1_di0>, <&ipu2_di0>, <&ipu2_di1>, <&ipu1_di1>; }; (i.e. reordering the ports of the display-subsystem.) To my understanding the imx drm driver maps both outputs to ipu1 by default which cannot handle the load. But using ipu1 and ipu2 for a single output each works. Unfortunately, I didn't find a way to model this restriction in the devicetree (in a sane way). IMHO the driver should at least disable one of the outputs instead of rendering the whole system unusable. Optimally, it should figure out a correct mapping between outputs and ipu's itself. Any help would be much appreciated. Cheers, Christopher The warning occurring is the following (I used a clean v4.9-rc5 branch but copied the config of ArchlinuxARM which is why -ARCH+ got appended): [ 6.546989] WARNING: CPU: 0 PID: 185 at drivers/gpu/drm/drm_atomic_helper.c:1140 drm_atomic_helper_wait_for_vblanks+0x274/0x278 [ 6.547005] [CRTC:24] vblank wait timed out [ 6.547118] Modules linked in: dw_hdmi_ahb_audio imx_ipuv3_crtc(+) caam_jr mwifiex_sdio(+) mwifiex cfg80211 btmrvl_sdio(+) btmrvl snd_soc_imx_spdif bluetooth imx_ipu_v3 rfkill ofpart caam snd_soc_fsl_spdif snd_soc_fsl_asrc imx_pcm_dma snd_soc_core snd_pcm_dmaengine snd_pcm spi_imx coda snd_timer videobuf2_dma_contig igb v4l2_mem2mem videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core imx2_wdt dw_hdmi_imx dw_hdmi etnaviv parallel_display uio_pdrv_genirq ti_tfp410 uio imxdrm evdev joydev mousedev sch_fq_codel ip_tables x_tables [ 6.547128] CPU: 0 PID: 185 Comm: systemd-udevd Not tainted 4.9.0-rc5-ARCH+ #3 [ 6.547131] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 6.547154] [<c0110524>] (unwind_backtrace) from [<c010b8dc>] (show_stack+0x10/0x14) [ 6.547167] [<c010b8dc>] (show_stack) from [<c03bf6a0>] (dump_stack+0x88/0x9c) [ 6.547181] [<c03bf6a0>] (dump_stack) from [<c013c1b0>] (__warn+0xe8/0x100) [ 6.547191] [<c013c1b0>] (__warn) from [<c013c210>] (warn_slowpath_fmt+0x48/0x6c) [ 6.547204] [<c013c210>] (warn_slowpath_fmt) from [<c04d3b78>] (drm_atomic_helper_wait_for_vblanks+0x274/0x278) [ 6.547228] [<c04d3b78>] (drm_atomic_helper_wait_for_vblanks) from [<bf02d2ec>] (imx_drm_atomic_commit_tail+0x48/0x58 [imxdrm]) [ 6.547247] [<bf02d2ec>] (imx_drm_atomic_commit_tail [imxdrm]) from [<c04d6410>] (commit_tail+0x40/0x5c) [ 6.547256] [<c04d6410>] (commit_tail) from [<c04d64c8>] (drm_atomic_helper_commit+0x94/0xc8) [ 6.547267] [<c04d64c8>] (drm_atomic_helper_commit) from [<c04d9448>] (restore_fbdev_mode+0x148/0x298) [ 6.547275] [<c04d9448>] (restore_fbdev_mode) from [<c04da468>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x30/0x74) [ 6.547283] [<c04da468>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c04da4dc>] (drm_fb_helper_set_par+0x30/0x60) [ 6.547294] [<c04da4dc>] (drm_fb_helper_set_par) from [<c042e2ec>] (fbcon_init+0x4f8/0x544) [ 6.547305] [<c042e2ec>] (fbcon_init) from [<c049f1fc>] (visual_init+0xc0/0x108) [ 6.547316] [<c049f1fc>] (visual_init) from [<c04a0718>] (do_bind_con_driver+0x1b0/0x37c) [ 6.547323] [<c04a0718>] (do_bind_con_driver) from [<c04a0cac>] (do_take_over_console+0x144/0x1b0) [ 6.547331] [<c04a0cac>] (do_take_over_console) from [<c042e3a8>] (do_fbcon_takeover+0x70/0xcc) [ 6.547346] [<c042e3a8>] (do_fbcon_takeover) from [<c015bf74>] (notifier_call_chain+0x44/0x84) [ 6.547355] [<c015bf74>] (notifier_call_chain) from [<c015c2d8>] (__blocking_notifier_call_chain+0x48/0x60) [ 6.547364] [<c015c2d8>] (__blocking_notifier_call_chain) from [<c015c308>] (blocking_notifier_call_chain+0x18/0x20) [ 6.547373] [<c015c308>] (blocking_notifier_call_chain) from [<c0439a4c>] (register_framebuffer+0x1bc/0x2cc) [ 6.547381] [<c0439a4c>] (register_framebuffer) from [<c04da7c0>] (drm_fb_helper_initial_config+0x2b4/0x480) [ 6.547389] [<c04da7c0>] (drm_fb_helper_initial_config) from [<c04db098>] (drm_fbdev_cma_init_with_funcs+0x7c/0xf4) [ 6.547397] [<c04db098>] (drm_fbdev_cma_init_with_funcs) from [<c04db128>] (drm_fbdev_cma_init+0x18/0x20) [ 6.547409] [<c04db128>] (drm_fbdev_cma_init) from [<bf02d530>] (imx_drm_bind+0xf4/0x184 [imxdrm]) [ 6.547423] [<bf02d530>] (imx_drm_bind [imxdrm]) from [<c050167c>] (try_to_bring_up_master+0x148/0x184) [ 6.547431] [<c050167c>] (try_to_bring_up_master) from [<c050174c>] (component_add+0x94/0x140) [ 6.547439] [<c050174c>] (component_add) from [<c050801c>] (platform_drv_probe+0x50/0xb0) [ 6.547449] [<c050801c>] (platform_drv_probe) from [<c0506638>] (driver_probe_device+0x204/0x2b0) [ 6.547457] [<c0506638>] (driver_probe_device) from [<c050679c>] (__driver_attach+0xb8/0xbc) [ 6.547465] [<c050679c>] (__driver_attach) from [<c05048a8>] (bus_for_each_dev+0x7c/0xc0) [ 6.547473] [<c05048a8>] (bus_for_each_dev) from [<c0505a44>] (bus_add_driver+0x108/0x214) [ 6.547482] [<c0505a44>] (bus_add_driver) from [<c0506f0c>] (driver_register+0x78/0xf4) [ 6.547491] [<c0506f0c>] (driver_register) from [<c01018d0>] (do_one_initcall+0x54/0x190) [ 6.547501] [<c01018d0>] (do_one_initcall) from [<c020ee78>] (do_init_module+0x60/0x1c8) [ 6.547512] [<c020ee78>] (do_init_module) from [<c01c621c>] (load_module+0x1b74/0x2150) [ 6.547521] [<c01c621c>] (load_module) from [<c01c6974>] (SyS_init_module+0x17c/0x194) [ 6.547530] [<c01c6974>] (SyS_init_module) from [<c01079e0>] (ret_fast_syscall+0x0/0x3c) [ 6.547546] ---[ end trace 1b051bae4f1eecd2 ]--- WIP devicetree patch: