Hi all,
After a few days of experimentation on multi-display support on i.MX6, I have some questions regarding the status of the imx-drm driver.
Here is description of my testing setup: - Nitrogen6x (a SabreLite would work the same) - Mainline kernel 4.1-rc2 + a few patches for display support (some are pending, other are scheduled for 4.2) https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=132811 https://patchwork.kernel.org/patch/6439221/ https://patchwork.kernel.org/patch/6439231/ https://patchwork.kernel.org/patch/6212451/ - Available displays: - 1 LVDS 10" Hannstar HSD100PXN1 display - 1 LCD 7" Okaya display - 1 HDMI 1080p TV - U-boot script used to boot the mainline kernel properly: https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/n... - Basic Buildroot filesystem with libdrm and its test binaries
First of all, using the standard imx_v6_v7_defconfig, everything runs fine with a single-display setup, no matter if it is using LVDS, RGB or HDMI interface.
But in multi-display setup, the first observation is that CONFIG_DRM_IMX_FB_HELPER seems to be problematic. When this option is set, only one display can be used either using the /dev/fb0 or 'modetest -s' from libdrm test binaries. As soon as the option is removed, every display can be used properly with the following commands: # modetest -M imx-drm -s 32:800x480 # modetest -M imx-drm -s 34:1920x1080 # modetest -M imx-drm -s 36:1024x768
Is this option only meant for single-display setup? Has it been tested in multi-display? It seems limited to fb0 creation, would it be possible to make the driver create as many fbs as the number of monitors?
Also, when trying to display different patterns on each and every display at once, I have been using the example provided by David Herrmann: https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c This shows a clocking issue when using both DRM_IMX_PARALLEL_DISPLAY and DRM_IMX_LDB at the same time. Although the driver is smart enough to connect ipu1_di0 to the RGB interface and ipu1_di1 to the LVDS interface, the clock set by the LDB driver (65MHz) is overwritten when the parallel interface is enabled as they both share pll5_video.
Has anyone successfully tried using both drivers, LVDS and parallel, at the same time?
Then I've run into Steve's series that seems to address some clocking issues. http://lists.freedesktop.org/archives/dri-devel/2014-October/070996.html
Is there the equivalent series for the driver since it has moved from staging?
Hope the above description is sufficient, if needed I can provide modeprint/modetest/clk_summary outputs.
Regards, Gary
Hi Gary,
Am Dienstag, den 26.05.2015, 16:47 +0200 schrieb Gary Bisson:
Hi all,
After a few days of experimentation on multi-display support on i.MX6, I have some questions regarding the status of the imx-drm driver.
Here is description of my testing setup:
- Nitrogen6x (a SabreLite would work the same)
- Mainline kernel 4.1-rc2 + a few patches for display support (some are pending, other are scheduled for 4.2)
https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=132811 https://patchwork.kernel.org/patch/6439221/ https://patchwork.kernel.org/patch/6439231/ https://patchwork.kernel.org/patch/6212451/
- Available displays:
- 1 LVDS 10" Hannstar HSD100PXN1 display
- 1 LCD 7" Okaya display
- 1 HDMI 1080p TV
- U-boot script used to boot the mainline kernel properly:
https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/n...
- Basic Buildroot filesystem with libdrm and its test binaries
First of all, using the standard imx_v6_v7_defconfig, everything runs fine with a single-display setup, no matter if it is using LVDS, RGB or HDMI interface.
But in multi-display setup, the first observation is that CONFIG_DRM_IMX_FB_HELPER seems to be problematic. When this option is set, only one display can be used either using the /dev/fb0 or 'modetest -s' from libdrm test binaries. As soon as the option is removed, every display can be used properly with the following commands: # modetest -M imx-drm -s 32:800x480 # modetest -M imx-drm -s 34:1920x1080 # modetest -M imx-drm -s 36:1024x768
Is this option only meant for single-display setup? Has it been tested in multi-display?
It seems limited to fb0 creation, would it be possible to make the driver create as many fbs as the number of monitors?
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Also, when trying to display different patterns on each and every display at once, I have been using the example provided by David Herrmann: https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c This shows a clocking issue when using both DRM_IMX_PARALLEL_DISPLAY and DRM_IMX_LDB at the same time. Although the driver is smart enough to connect ipu1_di0 to the RGB interface and ipu1_di1 to the LVDS interface, the clock set by the LDB driver (65MHz) is overwritten when the parallel interface is enabled as they both share pll5_video.
Has anyone successfully tried using both drivers, LVDS and parallel, at the same time?
For parallel and LVDS we'd either need to force the parallel panel to be clocked by the IPU internal clock, or move one or the other external clock source off of pll5_video. I have used a LVDS panel which could be driven from the mmdc_ch1_axi clock, but there are some issues when switching the LDB_DI clock parents: http://marc.info/?l=linux-arm-kernel&m=142055950831840&w=2
Then I've run into Steve's series that seems to address some clocking issues. http://lists.freedesktop.org/archives/dri-devel/2014-October/070996.html
Is there the equivalent series for the driver since it has moved from staging?
A few of the patches have been reposted and some of them applied. I'm not aware of a rebased version of the DI clock parent patch.
regards Philipp
Philipp, All,
On Wed, May 27, 2015 at 11:38 AM, Philipp Zabel p.zabel@pengutronix.de wrote:
Hi Gary,
Am Dienstag, den 26.05.2015, 16:47 +0200 schrieb Gary Bisson:
Hi all,
After a few days of experimentation on multi-display support on i.MX6, I have some questions regarding the status of the imx-drm driver.
Here is description of my testing setup:
- Nitrogen6x (a SabreLite would work the same)
- Mainline kernel 4.1-rc2 + a few patches for display support (some are pending, other are scheduled for 4.2)
https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=132811 https://patchwork.kernel.org/patch/6439221/ https://patchwork.kernel.org/patch/6439231/ https://patchwork.kernel.org/patch/6212451/
- Available displays:
- 1 LVDS 10" Hannstar HSD100PXN1 display
- 1 LCD 7" Okaya display
- 1 HDMI 1080p TV
- U-boot script used to boot the mainline kernel properly:
https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/n...
- Basic Buildroot filesystem with libdrm and its test binaries
First of all, using the standard imx_v6_v7_defconfig, everything runs fine with a single-display setup, no matter if it is using LVDS, RGB or HDMI interface.
But in multi-display setup, the first observation is that CONFIG_DRM_IMX_FB_HELPER seems to be problematic. When this option is set, only one display can be used either using the /dev/fb0 or 'modetest -s' from libdrm test binaries. As soon as the option is removed, every display can be used properly with the following commands: # modetest -M imx-drm -s 32:800x480 # modetest -M imx-drm -s 34:1920x1080 # modetest -M imx-drm -s 36:1024x768
Is this option only meant for single-display setup? Has it been tested in multi-display?
It seems limited to fb0 creation, would it be possible to make the driver create as many fbs as the number of monitors?
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal). The CRTC settings show that both have the same origin (0,0) so I expected the LVDS to display a part of what the HDMI *should* display.
I get the following traces when trying to display something on HDMI: # modetest -M imx-drm -s 34:1920x1080 setting mode 1920x1080-50Hz@XR24 on connectors 34, crtc 18 [ 350.915681] imx-ipuv3 2400000.ipu: DC stop timeout after 50 ms
Then trying to display something through the fbdev results in the LVDS being updated but still no signal on HDMI. # cat /dev/urandom > /dev/fb0
Once again, as soon as I remove the IMX_FB_HELPER configuration everything runs fine.
Also, when trying to display different patterns on each and every display at once, I have been using the example provided by David Herrmann: https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c This shows a clocking issue when using both DRM_IMX_PARALLEL_DISPLAY and DRM_IMX_LDB at the same time. Although the driver is smart enough to connect ipu1_di0 to the RGB interface and ipu1_di1 to the LVDS interface, the clock set by the LDB driver (65MHz) is overwritten when the parallel interface is enabled as they both share pll5_video.
Has anyone successfully tried using both drivers, LVDS and parallel, at the same time?
For parallel and LVDS we'd either need to force the parallel panel to be clocked by the IPU internal clock, or move one or the other external clock source off of pll5_video.
Do you have a preference for one solution over the other?
I have used a LVDS panel which could be driven from the mmdc_ch1_axi clock, but there are some issues when switching the LDB_DI clock parents: http://marc.info/?l=linux-arm-kernel&m=142055950831840&w=2
I will look into this approach.
Then I've run into Steve's series that seems to address some clocking issues. http://lists.freedesktop.org/archives/dri-devel/2014-October/070996.html
Is there the equivalent series for the driver since it has moved from staging?
A few of the patches have been reposted and some of them applied. I'm not aware of a rebased version of the DI clock parent patch.
Ok, thanks, I'll check and see what I need to get all the displays to work together.
Regards, Gary
Hi Gary,
Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson:
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal). The CRTC settings show that both have the same origin (0,0) so I expected the LVDS to display a part of what the HDMI *should* display.
No, but it does require the HDMI and LVDS display to use different clock sources (unless LVDS serializer clock happens to be the same as the HDMI pixel clock). I wonder what we should do about this for devices that have both LVDS and HDMI output and can only use PLL5 for both. Register a clock notifier that vetoes changes?
[...]
For parallel and LVDS we'd either need to force the parallel panel to be clocked by the IPU internal clock, or move one or the other external clock source off of pll5_video.
Do you have a preference for one solution over the other?
That depends on the board. Is there an LVDS display that can be driven by a PLL other than PLL5? Since there is no sane way to change the LDB_DI parent in a running system, that should be configured in the device tree.
regards Philipp
Hi Philipp,
On 05/28/2015 03:58 AM, Philipp Zabel wrote:
Hi Gary,
Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson:
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal). The CRTC settings show that both have the same origin (0,0) so I expected the LVDS to display a part of what the HDMI *should* display.
No, but it does require the HDMI and LVDS display to use different clock sources (unless LVDS serializer clock happens to be the same as the HDMI pixel clock).
I wonder what we should do about this for devices that have both LVDS and HDMI output and can only use PLL5 for both. Register a clock notifier that vetoes changes?
The LDB can be clocked from PLL2.
Here's a snippet of the clock tree from our 3.10.53 (Android) kernel running both HDMI at 720P and the Hannstar hsd070pww1 panel:
pll2_pfd0_352m 1 1 500210526 ldb_di1_div_7 0 0 71458646 ldb_di1_div_sel 0 0 71458646 ldb_di1 0 0 71458646 ldb_di1_div_3_5 0 0 142917293 ldb_di0_div_7 1 1 71458646 ldb_di0_div_sel 1 1 71458646 ldb_di0 1 1 71458646 ipu1_di1_sel 1 1 71458646 ipu1_di1 1 1 71458646 ipu1_pclk1_sel 1 1 71458646 ipu1_pclk1_div 1 1 71458646 ipu1_pclk_1 1 1 71458646
I believe that the Freescale kernels always clock the LVDS display bridge from PLL2 but perhaps not.
I'll test a dual-channel (1080P) display and trace the code in this branch of our kernel tree: https://github.com/boundarydevices/linux-imx6/tree/boundary-imx-kk4.4.3_2.0....
[...]
For parallel and LVDS we'd either need to force the parallel panel to be clocked by the IPU internal clock, or move one or the other external clock source off of pll5_video.
Do you have a preference for one solution over the other?
That depends on the board. Is there an LVDS display that can be driven by a PLL other than PLL5? Since there is no sane way to change the LDB_DI parent in a running system, that should be configured in the device tree.
That would certainly be best (to allow the use of the more accurate PLL5 in the normal case), but the PLL2 clock parent works well in the most common cases.
Regards,
Eric
Hi Eric,
Am Donnerstag, den 28.05.2015, 12:30 -0700 schrieb Eric Nelson:
Hi Philipp,
On 05/28/2015 03:58 AM, Philipp Zabel wrote:
Hi Gary,
Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson:
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal). The CRTC settings show that both have the same origin (0,0) so I expected the LVDS to display a part of what the HDMI *should* display.
No, but it does require the HDMI and LVDS display to use different clock sources (unless LVDS serializer clock happens to be the same as the HDMI pixel clock).
I wonder what we should do about this for devices that have both LVDS and HDMI output and can only use PLL5 for both. Register a clock notifier that vetoes changes?
The LDB can be clocked from PLL2.
Here's a snippet of the clock tree from our 3.10.53 (Android) kernel running both HDMI at 720P and the Hannstar hsd070pww1 panel:
pll2_pfd0_352m 1 1 500210526
What is the parent of gpu2d_core_sel? This looks like it would severely overclock the vivante 2d core.
regards Philipp
Hi Philipp,
On 05/29/2015 02:30 AM, Philipp Zabel wrote:
Hi Eric,
Am Donnerstag, den 28.05.2015, 12:30 -0700 schrieb Eric Nelson:
Hi Philipp,
On 05/28/2015 03:58 AM, Philipp Zabel wrote:
Hi Gary,
Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson:
According to the kerneldoc comment for drm_fb_helper_initial_config (which is used by imx-drm via drm_fbdev_cma_init), it should set up a single /dev/fb cloned over all connectors. This works here with LVDS and HDMI.
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal). The CRTC settings show that both have the same origin (0,0) so I expected the LVDS to display a part of what the HDMI *should* display.
No, but it does require the HDMI and LVDS display to use different clock sources (unless LVDS serializer clock happens to be the same as the HDMI pixel clock).
I wonder what we should do about this for devices that have both LVDS and HDMI output and can only use PLL5 for both. Register a clock notifier that vetoes changes?
The LDB can be clocked from PLL2.
Here's a snippet of the clock tree from our 3.10.53 (Android) kernel running both HDMI at 720P and the Hannstar hsd070pww1 panel:
pll2_pfd0_352m 1 1 500210526What is the parent of gpu2d_core_sel? This looks like it would severely overclock the vivante 2d core.
PLL3.
Here's a full clock tree for a Nitrogen6x configured for 1280x800 LVDS and 720P HDMI.
The GPU 2d core is running at 480MHz and the 3d core at 528MHz, so they're both under the limits of 532 and 540.
Looking at the clock tree for 4.1, it appears that the gpu3d_core is being over-clocked at 594 MHz.
Regards,
Eric
Hi Gary,
On Wed, May 27, 2015 at 10:31 AM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Does it require the two displays to have the exact same resolution? I'm wondering what is wrong with my setup but with a 1024x768 LVDS and a 1920x1080 HDMI display no image is shown on the HDMI (no signal).
I have seen this error sometime ago.
Do you get HDMI image if you unplug/plug the HDMI cable?
This was also fixed by Steve Longerbeam series and we still need to fix it in mainline.
Regards,
Fabio Estevam
Hi Gary,
On Wed, May 27, 2015 at 10:31 AM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Ok, thanks, I'll check and see what I need to get all the displays to work together.
With this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352189.html
I am able to get HDMI and LVDS working on a mx6q-sabresd.
Regards,
Fabio Estevam
On Tue, Jun 23, 2015 at 2:49 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Gary,
On Wed, May 27, 2015 at 10:31 AM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Ok, thanks, I'll check and see what I need to get all the displays to work together.
With this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352189.html
I am able to get HDMI and LVDS working on a mx6q-sabresd.
Sorry, the correct URL is: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352179.html
Hi Fabio,
On Tue, Jun 23, 2015 at 7:50 PM, Fabio Estevam festevam@gmail.com wrote:
On Tue, Jun 23, 2015 at 2:49 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Gary,
On Wed, May 27, 2015 at 10:31 AM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Ok, thanks, I'll check and see what I need to get all the displays to work together.
With this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352189.html
I am able to get HDMI and LVDS working on a mx6q-sabresd.
Sorry, the correct URL is: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352179.html
Thank you for your e-mail and sorry for the delay in my response. I confirm this patch, ported over to my dtsi file, makes the HDMI and LVDS work together.
I'll check with Eric but we will most likely use the same configuration for our platforms.
Regards, Gary
Hi Gary,
On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Thank you for your e-mail and sorry for the delay in my response. I confirm this patch, ported over to my dtsi file, makes the HDMI and LVDS work together.
I'll check with Eric but we will most likely use the same configuration for our platforms.
What do you mean by "use the same configuration for our platforms"?
I was planning to send the two attached patches.
Are you and Eric OK with them?
Regards,
Fabio Estevam
Hi Fabio,
On Mon, Jun 29, 2015 at 6:08 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Gary,
On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Thank you for your e-mail and sorry for the delay in my response. I confirm this patch, ported over to my dtsi file, makes the HDMI and LVDS work together.
I'll check with Eric but we will most likely use the same configuration for our platforms.
What do you mean by "use the same configuration for our platforms"?
I meant the clock tree configuration, having LDB under the PLL3.
I was planning to send the two attached patches.
I am ok with it but I'd like Eric to ack it too as he might have some remarks.
Regards, Gary
On Mon, Jun 29, 2015 at 1:12 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
I am ok with it but I'd like Eric to ack it too as he might have some remarks.
Ok, I will submit it to the linux-arm mailing list with you and Eric on Cc.
Regards,
Fabio Estevam
Thanks Fabio,
On 06/29/2015 09:08 AM, Fabio Estevam wrote:
Hi Gary,
On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Thank you for your e-mail and sorry for the delay in my response. I confirm this patch, ported over to my dtsi file, makes the HDMI and LVDS work together.
I'll check with Eric but we will most likely use the same configuration for our platforms.
What do you mean by "use the same configuration for our platforms"?
I was planning to send the two attached patches.
Are you and Eric OK with them?
These look good to me.
Gary, did you test one of these against either of our 1280x800 panels?
Fabio, Eric,
On Mon, Jun 29, 2015 at 6:22 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Thanks Fabio,
On 06/29/2015 09:08 AM, Fabio Estevam wrote:
Hi Gary,
On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson gary.bisson@boundarydevices.com wrote:
Thank you for your e-mail and sorry for the delay in my response. I confirm this patch, ported over to my dtsi file, makes the HDMI and LVDS work together.
I'll check with Eric but we will most likely use the same configuration for our platforms.
What do you mean by "use the same configuration for our platforms"?
I was planning to send the two attached patches.
Are you and Eric OK with them?
These look good to me.
Gary, did you test one of these against either of our 1280x800 panels?
Yes I've tested with both Hannstar 10" 1024x768 and 7" 1280x800. I will answer to the patches sent for Sabrelite and Nitrogen6x.
Regards, Gary
dri-devel@lists.freedesktop.org
-
Eric Nelson -
Fabio Estevam -
Gary Bisson -
Philipp Zabel