drm: imx: multi-display support questions

[Gary Bisson]

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