Re: [meta-fsl-arm] Sabre* and HDMI

[Gary Thomas <gary@mlbassoc.com>]

On 2015-04-08 06:33, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 04/08/2015 03:08 PM, Gary Thomas wrote:
>> Disclaimer - this question is not 100% BSP, but I'm hoping someone
>> reading it might have some insights.
>>
>> I have multiple i.MX6 boards which I support using Poky/Yocto plus
>> meta-fsl-arm*.  The problem I'm looking at is on some of them, HDMI
>> works correctly where on others the screen is clipped (overscan).
>>
>> On the SabreLite, using linux-boundary_3.10.53, HDMI works correctly
>> (on all the monitors I have tried).  An image of the upper left of
>> the screen is in HDMI-OK.png
>>
>> On SabreSD, using linux-imx_3.10.53, HDMI on a 720p monitor, the
>> image is clipped with upwards of 5% of the pixels missing. This is
>> shown in HDMI-BAD.png
>>
>> I've not yet tried the linux-boundary kernel on the SabreSD, but I
>> expect the same result as I have seen this problem on other boards
>> (internal) that use the linux-boundary kernel.
>>
>> Any insights on what might cause this?  About the only thing we can
>> think of is the SabreSD sends its HDMI signals through a
>> level-shifting ESD device whereas the SabreLite manages these signals
>> more directly using FETs and discrete circuitry.
>>
>> Thanks for any ideas
>
> The actual HDMI video signal is not level-shifted by the ESD chip, it's
> only clamped when subjected to voltages outside SOAR. The ESD chip
> doesn't even buffer the video signal. So technically speaking, the video
> signal is 1:1 the same on both boards, both as signal levels, protocols,
> everything (except for the ability to protect against ESD damage, of
> course).

Thanks for the explanation (the previous words were my hardware guy's,
sorry to have mispoken)

>
> There could be a difference in the way how well the I2C (DDC)
> level-shifting works, in some cases this could allow or prevent the
> display to properly communicate settings with the board, and the kernel
> could or couldn't fetch EDID data. You can check with read-edid tool
> whether the monitor gives any/meaningful information:
>
> # read-edid | parse-edid
>
> ...just to be sure it works.

I've looked at the EDID when the kernel parses it and it looks OK.

I'd like to try your example, but I don't find 'read-edid' anywhere.
The only package I can find, which contains only parse-edid, is in
meta-openembedded/meta-oe/recipes-support/read-edid/read-edid_2.0.0.bb

Ideas where to get read-edid?

>
> The different boards can use different timings on the same monitor,
> depending on what they "see" attached. Which is also a reminder for you
> to make sure that both boards's kernels have the same video bootargs, so
> you can make a meaningful comparison.
>
> I hope that you're comparing kernels built from the same source tree, so the display timing definitions are exactly the same.

Yes, as I said, I've tried two different platforms both built
using linux-boundary_3.10.53 - one works, the other not.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------