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.
...
- 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? 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.
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.
I will add a check there,
Regards, Simon