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

[Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 11/28/2012 02:37 PM, Mark Zhang wrote:
> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>> 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>
>>>>> 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.
>>
> 
> All right, I just test the framebuffer console and "xinit", I didn't
> install the whole ubuntu.
> 
> I'll install the ubuntu in my cardhu and see whether I have this kind of
> issues.

Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
you described. The display worked with no corruptions. I can show you
the video if you want.

What I used for testing is a cardhu board with our downstream U-Boot.

But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So
sounds like the clock setting has some problems... I'll have a look at this.

Mark
> 
> Mark
>> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>