On 11/27/2012 11:17 AM, Stephen Warren wrote: > On 11/26/2012 08:16 PM, Mark Zhang wrote: >> On 11/27/2012 06:37 AM, Stephen Warren wrote: >>> On 11/22/2012 12:37 PM, Thierry Reding wrote: >>>> Instead of using the stride derived from the display mode, use the pitch >>>> associated with the currently active framebuffer. This fixes a bug where >>>> the LCD display content would be skewed when enabling HDMI with a video >>>> mode different from that of the LCD. >>> >>> This patch certainly doesn't cause any additional issues for me, so: >>> >>> Tested-by: Stephen Warren <swarren@xxxxxxxxxx> >>> >>> Howwever, it still doesn't allow both Cardhu's LCD panel and external >>> HDMI port (1080p) to be active at once. If I boot with both enabled, or >>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads >>> are active, then some kind of display corruption starts; it looks like a >>> clocking issue or perhaps memory underflow. >> >> I haven't observed this issue. What kind of display corruption you mean? >> Did it recover after some seconds or the display in LVDS panel was >> always corrupted? >> >> During my testing, I connected HDMI while booting cardhu and I can see >> the LVDS and HDMI working with no corruptions. > > For your viewing pleasure (and playing with my new phone) :-) > http://www.youtube.com/watch?v=ZJxJnONz7DA > > The external monitor is 1920x1200 I believe. Jon Mayo says the corruption in the video is display (memory fetch) underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu programs the memory controller at a slow rate, and the bootloader and/or kernel is supposed to bump up the rate to the max, but that's not implemented anywhere yet upstream. If you're testing with "fastboot" instead of U-Boot, that might be re-programming the memory frequencies, and hence avoiding this. I guess we have a fun time ahead of us with mode validation and memory controller programming. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
