[U-Boot] [PATCH v4 0/16] tegra: Add display driver and LCD support for Seaboard

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/08/2012 02:06 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Fri, Oct 5, 2012 at 12:51 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 10/03/2012 11:05 AM, Stephen Warren wrote:
>>> On 09/27/2012 06:44 PM, Simon Glass wrote:
>>>> This series adds support for the Tegra2x's display peripheral. This
>>>> supports the LCD display on Seaboard and we use this to enable console
>>>> output in U-Boot on the LCD.
>> ...
>>> 2) The display works fine for cold boot, or hitting the physical reset
>>> button, but when I execute "reset" at the U-Boot prompt, or "reboot"
>>> within Linux, the display is messed up; it looks like the LCD isn't able
>>> to sync to the timings sent by the display controller or something similar.
>>>
>>> Since this is slightly a corner case, it may be OK to fix it later (but
>>> not much later; reboot is very useful to me.)
>>
>> A couple more points:
>>
>> BTW, I tried the same tests on Springbank which is basically Seaboard
>> with a slightly different PCB layout, and didn't see this issue. That
>> leads me to suspect some timing issue interacting with the panel, which
>> I believe is different albeit theoretically compatible
>> resolution/scan-timing wise.
> 
> OK. I wonder the panel does not get reset properly on Seaboard?

I looked at the panel spec for the panels on the two boards. Both of
them specify that when vdd_pnl is dropped to zero, you must wait at
least 400mS before raising it again. Evidently the Seaboard panel
actually cares about this, yet the Springbank panel seems to be more
flexible than the specification. So, modifying
drivers/video/tegra.c:handle_stage() case STAGE_START to:

    if (fdt_gpio_isvalid(&config.panel_vdd)) {
        udelay(400000);
        gpio_direction_output(config.panel_vdd.gpio, 1);
    }

... appears to solve the problem; I can run "reset" in U-Boot many many
times without any issue after that change.

I guess this means that the nvidia,panel-timings DT property needs a
pre-delay entry for STAGE_START, or something like that?

Also, I wondered if we shouldn't explicitly do:

    gpio_direction_output(config.panel_vdd.gpio, 0);
    udelay(400000);
    gpio_direction_output(config.panel_vdd.gpio, 1);

... although that doesn't make a difference; the particular GPIO used on
Seaboard appears to default to 0. I'm not sure that all GPIOs are
guaranteed to though.

Slightly related, I notice that handle_stage() always executes:

timer_next = timer_get_us() + config.panel_timings[stage] * 1000;

However, that function is called for stage==0..4 (or perhaps 0..5 given
the set of case statements it supports, but not looking at the code at
the call site), yet there are only entries 0..3 in that array; there's
an overrun there.