On Thu, Oct 31, 2013 at 4:48 PM, Matt Sealey <neko@xxxxxxxxxxxxx> wrote: > On Thu, Oct 31, 2013 at 4:08 PM, Fabio Estevam <festevam@xxxxxxxxx> wrote: >> On Thu, Oct 31, 2013 at 7:00 PM, Russell King - ARM Linux >> <linux@xxxxxxxxxxxxxxxx> wrote: >> >>>> Interesting. With the monitor I have tested I am not able to see this >>>> magenta line. >>> >>> Monitor or TV? Beware of overscans which will hide this effect. >> >> I used a PC monitor on my tests. >> >> I sent v5 using 4 as the number of loops according to Troy's results. > > Stop, stop, stop! > > Has nobody noticed this register isn't described in the reference manual? > > What does it even do? How can we quantify Troy's results by just > throwing numbers at it and then saying "no magenta line here"? Okay a little worry here is that the last time I kicked an HDMI transmitter around a huge magenta line was basically a side effect of doing the following things that weren't necessary to spec; either enabling audio infoframes when in DVI mode (the transmitter doesn't care if you're in DVI mode, it will shove audio out there anyway) or some really weird timing effects, almost a race condition, if you're generating infoframes at the wrong points (such as SPD or suchlike) - sometimes the monitor will figure it out. Sometimes not. The easiest case is enable "HDMI transmitter mode" on a monitor that does not actually have an HDMI-spec-capable decoder on it. If you have an HDMI to DVI cable, you have this. If you have an older or cheaper monitor with no speakers, this can also be entirely possible. You almost never see this on TVs, but you DO see it on maybe the "3rd" HDMI port on some TVs (where audio mysteriously doesn't work, but it works fine on the other two ports). I wrote a little treatise on this about those Radeon HDMI->DVI dongles to the DRM list, it's the same deal. Essentially there's not a lot of point enabling HDMI mode if your monitor doesn't support audio, and if you do enable it, you HAVE to make sure your AVI InfoFrames are being sent (but, obviously, don't send AVI InfoFrames in DVI mode or all you'll see is a magenta line if it extends the blanking timings, and the monitor doesn't handle it). I notice the register enums have DVI mode in there, also I saw a weird case where the CEA modes in the kernel that got introduced with DRM had a couple backwards polarities, and one or two of them on some monitors that specified them would give the magenta line (and on others that had the same VIC in their CEA list) would work fine.. I guess they had more resilient logic to detect things like the wrong HSYNC polarity. What modes are being set here (are they derived from VIC codes or actual detail timings?) that cause the magenta line? The actual fix may be to go through the HDMI spec and fix the CEA mode definitions that correspond to each VIC and be sure they're accurate. Hammering the register 4 times probably just resolves it by approaching what seems like a more correct waveform by constantly re-starting the transmission path. That might explain why some values work for some and some don't for others. I'm concerned that the real problem isn't addressed (and I did see a patch that fiddled a polarity value earlier..) and the actual effects of these bits is not actually documented in the manuals. 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 important register if the definition in the source code is to be believed (do we believe it?) if working HDMI output is to be achieved. Thanks, Matt Sealey <neko@xxxxxxxxxxxxx> _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
