[PATCH] drm: tegra: Use framebuffer pitch as line stride

[Stephen Warren]

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 at nvidia.com>
>>>
>>> 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.