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

[Mark Zhang]

On 12/04/2012 11:50 AM, Stephen Warren wrote:
> On 12/03/2012 08:00 PM, Mark Zhang wrote:
>> 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 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.
>>>>
>>>
>>> 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 at 60HZ". So
>> sounds like the clock setting has some problems... I'll have a look at this.
> 
> Oh, I thought I'd followed up on this - Jon Mayo said it was display
> underflow due to lack of memory bandwidth. IIRC, this may be due to the
> BCT programming the memory controller for conservative settings that
> don't require non-default voltages from the PMIC, with the expectation
> that the bootloader or kernel will reprogram everything for correct
> performance.
> 

OK, I see. But my HDMI doesn't work so I will spend some time digging it.

Mark