From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id B959DE0099A; Wed, 8 Apr 2015 05:46:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail.chez-thomas.org (mail.mlbassoc.com [65.100.170.105]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 8D584E0098A for ; Wed, 8 Apr 2015 05:46:36 -0700 (PDT) Received: by mail.chez-thomas.org (Postfix, from userid 1998) id AA1A2F811E4; Wed, 8 Apr 2015 06:46:35 -0600 (MDT) Received: from [192.168.1.114] (zeus [192.168.1.114]) by mail.chez-thomas.org (Postfix) with ESMTP id 11826F811E2; Wed, 8 Apr 2015 06:46:35 -0600 (MDT) Message-ID: <5525233A.7070603@mlbassoc.com> Date: Wed, 08 Apr 2015 06:46:50 -0600 From: Gary Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nikolay Dimitrov References: <55251A2F.4040500@mlbassoc.com> <55252008.3070303@mail.bg> In-Reply-To: <55252008.3070303@mail.bg> Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm] Sabre* and HDMI X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 12:46:37 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 ------------------------------------------------------------