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

[Stephen Warren]

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.