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