From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 06382E0099A; Wed, 8 Apr 2015 05:33:20 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id AA172E0098A for ; Wed, 8 Apr 2015 05:33:14 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id 0A7236002B0F; Wed, 8 Apr 2015 15:33:12 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1428496393; bh=6sMdMkWuw/F3dAlyWsSZjMimmex7URNrLb9tbRodrx0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=3JUqgbJwSAdXM21wv59sTTGV+kiUQ9ehVJMP3LhX6UWutTrlN3FQBdx/IsS8DeqnM sPMM9RKu38E49GnkHXTREOnJzPvEOJvwJ9zxnm8ifwKCr1scO1KWWQ/Ulasbwsytzq TFT10mZ2WY33P//fcRdRfWKA69NIvFQkxl4myh3I= Message-ID: <55252008.3070303@mail.bg> Date: Wed, 08 Apr 2015 15:33:12 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Gary Thomas References: <55251A2F.4040500@mlbassoc.com> In-Reply-To: <55251A2F.4040500@mlbassoc.com> 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:33:20 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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