This bug has been identified as one that may not be required for MPQ since it now seems clear that MPQ and MP firmwares will be different.  Please comment if you disagree with this assessment.  Thanks!

I don't see a flash before "free your music" any more, but there is one before the logi logo.

Fixed in baby-mp r6706. This moves the backlight init after the framebuffer init. I also found it was necessary to add a 200ms delay after the spi configuration of the framebuffer. Caleb, why's that?

The init isn't happening in threads, is it?   I could imagine 200 me to unit the device but 200 me after unit seems pretty long for the display to start going.

There is a charge pump in the display itself.  Maybe it takes that long to stabilize. 

Maybe Maurice knows the answer.

The LCD probably requires a running VSYNC, HSYNC and LSCLK running in order to properly sequence the various charge pumps.

Here are the steps i would do for power on:
- turn off backlight if not already done
- initialize imx25 LCD i/f
- initialize LCD
- wait a few VSYNC period (to be determined)
- turn on backlight

I think that's basically what's happening. If the display is initialized before the mx25 interface it does not seem to work. But a 200ms delay seems long?

200ms doesn't seem unreasonable.

I found in Fig 6.3.1, page 153 of https://svn.slimdevices.com/repos/player/trunk/hardware/babyboom/docs/datasheets/display/Novatech%20NT39116%20V0.8.pdf : "wait for more than 120ms after power control command".

Reset priority before triage.

Richard asks why there even needs to be a 200ms delay, Maurice?

After power on reset, the LCD is in sleep-in mode. The doc mentions an internal self test procedure that lasts 120ms when transitioning from sleep-in mode to sleep-out mode; see chapter 5.14.2.
In short, after issuing the sleep-out command, the imx25 should wait 120ms before sending any other command. Ideally, the imx25 should check if bit 6 of RDDSDR has been inverted by the self test after the 120ms period.

It should be noted that a non initialized matrix apprears white and this is probably the flash we are seeing.

Richard, can you verify that we are not communicating with LCD for 120ms after sending sleep-out command?

Hi Richard,

I don't consider this issue as P1 and I am assigning the bug back to you. Feel free to close it or return it to me if you consider something is not right.

We are waiting 120ms after taking the display out of sleep mode before sending any other commands, see baby_lcd_spi_sequence in mx25_baby_gpio.c. An addition 200ms delay is needed after the DISPON to remove the white flash.

it looks like the initialization sequence from wintek is not appropriate. Instead of this:
- SLPOUT (start the various charge pumps)
- wait 120ms (wait for the charge pumps to reach their target voltage)
- set all the registers (change the target volatge of the charge pumps!!!)
- wait extra 200ms (wait again for the charge pumps to reach their new target)
- turn on backlight


we should have that:
- set all the registers (set the target voltages once for all)
- SLPOUT (turn on the charge pumps)
- wait 120ms (or whatever value is apropriate to make sure the various charge pumps have reached their value; we need at least a 30% safety margin to accomodate the tolerance of the capacitors used inside the panel)
- turn on the backlight

Caleb and i did some experiment and with 120ms we can still see something flashy on the screen. The flashiness is completely gone at 200ms.

Caleb is checking in the fix.

Fixed in r6854.  Moved SLPOUT and DISPON to the end of the init sequence.