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

[Christopher Spinrath]

Hi Philipp,

On 11/30/2016 10:45 AM, Philipp Zabel wrote:
> Am Dienstag, den 29.11.2016, 18:37 +0100 schrieb Christopher Spinrath:
>> Hi Philipp,
>>
>> thanks for your answer!
>>
>> On 11/29/2016 05:38 PM, Philipp Zabel wrote:
>>> 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?
>>
>> I meant the workload of an ipu when driving both outputs. My setup
>> consists of two displays set to the mode 1920x1200 at 60Hz.
> 
> Thanks, that is what I meant to ask. Just to be sure that the issue
> really is the IPU throughput limitation.
> 
>>>>  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;
>>
>> Great! That works and is better than the display-subsystem workaround
>> (for the record the syntax is wrong; I had to use the node names not the
>> labels).
> 
> When I drop these lines into imx6q-nitrogen6x.dts verbatim, the
> referenced endpoint nodes are removed from the dtb as expected.

Oh, you're right. I placed these lines inside the root node / and dtc
failed with the very helpful "syntax error" error message... Sorry about
that.

>>>> 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.
>>
>> So deleting the links between HDMI encoder mux and IPU1 in the
>> devicetree is the way to go/the preferred solution?
> 
> For the ipu1_di0, yes. As you have the tfp410 connected to DI0, I'd say
> there's really no reason to ever mux HDMI to IPU1 DI0 on this board.
> 
> For IPU1 DI1 it is arguable. If the chosen resolution was low enough it
> would be possible to drive both outputs from IPU1, and depending on the
> use case it might be preferrable (to reduce power consumption, or if
> IPU2 was to be used for an LVDS display, for example).

Ok. The Utilite does not expose any kind of interface to connect LVDS,
CSI, or anything else to the IPUs except for the HDMI connectors. So the
only disadvantage I can think of is the increased power consumption.
I guess I will simply submit a patch as soon as the tfp410 bridge driver
has been merged and include the imx maintainers in the discussion.

Thanks,
Christopher

> regards
> Philipp
>