[Bug/RFC] drm/imx: warning: vblank wait timed out

[Philipp Zabel]

Hi Christopher,

Am Dienstag, den 29.11.2016, 16:45 +0100 schrieb Christopher Spinrath:
> Hi all,
> 
> I am trying to enable the second display pipeline of my imx6q based
> Utilite Pro. I appended a devicetree patch to this email for reference.
> 
> While it works perfectly on its own there occur kernel warnings (see
> below) if both pipelines are connected. Furthermore, the machine becomes
> almost unresponsive. Note that these warnings start to happen around the
> time getty is started. No other userspace stuff (e.g. X11) is involved.
> 
> I can make it work by adding the following hack to the devicetree:
> 
> display-subsystem {
> 	compatible = "fsl,imx-display-subsystem";
> 	ports = <&ipu1_di0>, <&ipu2_di0>, <&ipu2_di1>, <&ipu1_di1>;
> };
> 
> (i.e. reordering the ports of the display-subsystem.)
> 
> To my understanding the imx drm driver maps both outputs to ipu1 by
> default which cannot handle the load.

What is the load?

>  But using ipu1 and ipu2 for a
> single output each works. Unfortunately, I didn't find a way to model
> this restriction in the devicetree (in a sane way).

You can sever the links between HDMI encoder mux and IPU1 display
interfaces to keep it from being connected to IPU1 DI1:

/delete-node/&ipu1_di0_hdmi;
/delete-node/&hdmi_mux_0;

/delete-node/&ipu1_di1_hdmi;
/delete-node/&hdmi_mux_1;

> IMHO the driver should at least disable one of the outputs instead of
> rendering the whole system unusable. Optimally, it should figure out a
> correct mapping between outputs and ipu's itself.

It should. The problem with the IPU limitations is that they are
cross-crtc. The reference manual says that the maximum combined rate for
both display interfaces in an IPU is 240 MP/s, so we'd need to take into
account the pixel clocks of already enabled sibling crtcs when deciding
whether a mode can be set.

regards
Philipp