Philipp, All, On Wed, May 27, 2015 at 11:38 AM, Philipp Zabel <p.zabel at 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/nitrogen6x/6x_bootscript-mainline.txt >> - 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 at 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
