drm: imx: multi-display support questions

Gary Bisson gary.bisson at boundarydevices.com
Wed May 27 06:31:28 PDT 2015

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

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.


More information about the dri-devel mailing list