[meta-fsl-arm] Sabre* and HDMI

[meta-fsl-arm] Sabre* and HDMI

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

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

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

[-- Attachment #2: HDMI-BAD.png --]
[-- Type: image/png, Size: 13235 bytes --]

[-- Attachment #3: HDMI-OK.png --]
[-- Type: image/png, Size: 15485 bytes --]

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

[Nikolay Dimitrov]

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).

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.

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.

Hope this helps for now. Regards,
Nikolay

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

[Gary Thomas]

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
------------------------------------------------------------

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

[Gary Thomas]

On 2015-04-08 06:46, Gary Thomas wrote:
> 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?
>

I found an old recipe in meta-oe that should have done this, but sadly
it did not handle read-edid.  I've managed to update it so read-edid
works - look for an updated recipe to meta-oe soon (from me).

That said, I've run the above on my various systems and they all come
out with reasonable EDID data.  Sadly, the overscan occurs whether the
EDID is properly read or not, so this does not seem to be the root of
my problems.

For completeness, here's the EDID from my monitor:

Section "Monitor"
         Identifier "SAMSUNG"
         ModelName "SAMSUNG"
         VendorName "SAM"
         # Monitor Manufactured week 15 of 2007
         # EDID version 1.3
         # Digital Display
         DisplaySize 160 90
         Gamma 2.20
         Option "DPMS" "false"
         Horizsync 27-68
         VertRefresh 49-61
         # Maximum pixel clock is 150MHz

         #Extension block found. Parsing...
         Modeline        "Mode 10" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync
         Modeline        "Mode 0" 74.25 1920 2008 2052 2200 540 542 547 562 +hsync +vsync interlace
         Modeline        "Mode 1" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
         Modeline        "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace
         Modeline        "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync
         Modeline        "Mode 4" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
         Modeline        "Mode 5" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace
         Modeline        "Mode 6" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
         Modeline        "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync
         Modeline        "Mode 8" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
         Modeline        "Mode 9" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
         Modeline        "Mode 11" 74.25 1920 2448 2492 2640 540 542 547 562 +hsync +vsync interlace
         Modeline        "Mode 12" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
         Modeline        "Mode 13" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync
         Option "PreferredMode" "Mode 10"
EndSection

>>
>> 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
------------------------------------------------------------