[PATCH v4] imx-drm: Add mx6 hdmi transmitter support

[Matt Sealey]

On Mon, Nov 4, 2013 at 7:13 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Mon, Nov 4, 2013 at 9:20 PM, Matt Sealey <neko at bakuhatsu.net> wrote:
>
>> Fabio, Shawn, could you go so far as to bring this up with the i.MX
>> guys responsible for documentation or find the original transmitter IP
>> specs, or find the two pages missing from the manual? This is a really
>
> The multiple writes comes from the following erratum:
> ERR005173 HDMI: Clarification on HDMI programming procedure to avoid
> FIFO overflow

I know about that one. BTW this isn't in the MX6SDL errata
documentation, but it is in the MX6QD errata. If this actually affects
the Solo etc. as Russell dictates, isn't the errata document missing
some info here?

Also the patch doesn't ACTUALLY do what the erratum states you should
do - nobody is checking audio FIFO status here before retrying.

What I am more curious about is the net effect of every bit in this 8
bit undocumented register which seems to have a major errata around
it.

I noticed a couple which have very abstract definitions which could
mean a couple things regarding packetizing information. What does
R_V_BLANK_IN_OSC mean? It's being set when the VIC selected is 39,
which makes sense in that there is a magic interlace timing for this
VIC if it also exists in the EDID DTDs. However, no check for this is
made, it just sets it outright. In fact, it doesn't even make sense
since in theory it would not be being told to set the VIC timing, it
would be passed the DTD timing, which need to match a very specific
set of values, and if they match you need to, instead, fix up the
timing used based on the fact that VIC 39 was also listed in the CEA
extension block...

If you don't follow the CEA-861-E specs or HDMI 1.3a specs *at least*
when configuring a mode, and packetizing your infoframes, and the
content of those infoframes, then you're going to end up with magenta
lines regardless of esoteric audio FIFO underflows.

What I don't understand here is how a FIFO underflow in the audio
packetizer is causing this magenta line. What you should get is a pop
or crackle in the audio (or silence..) or just zero effect on the
display if the packetizer can't put valid data in there. There aren't
any reasons why a FIFO underflow would somehow change mode timings to
cause a magenta line.

That said, I got the same thing accidentally enabling audio on a DVI
monitor, although this was an SPDIF connection to an external
transmitter (not an internal IP block) - even if you didn't enable
audio and it was in DVI mode, it caused enough "drag" on the logic to
sample audio and be getting nothing over the audio link to put a huge
pink line down the side of at least 2 monitors. There doesn't seem to
be any audio setup going on in the driver, so I would suggest trying
to just force DVI mode and see if the line goes away or gets worse
with those different values for retrying, and then forcing HDMI mode..
same test.


Matt Sealey <neko at bakuhatsu.net>