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

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/08/2012 03:50 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Oct 8, 2012 at 2:30 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> 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.
> 
> So reset is causing the line to go low?

I would imagine so.

> OK, there's probably nothing
> we can do here except wait for 400ms. Is there any way to detect this
> condition? Adding 400ms is quite a big jump in boot time.

I think the PMIC has a "power-on/reset reason" register. However, I
don't know exactly how long the minimum time between powering off and
immediately powering on is; it's plausible it isn't safe to skip some
waiting even in that case.