DCONLOAD goes high at S3 entry and exit

[wmb@…]

DCONLOAD needs to stay low during suspend so that the DCON can keep the screen contents frozen. But that is not possible with the current wiring. It is connected to 5536 GPIO 11, which is also SLP_CLK_EN#.

When you enter S3 state, the 5536 drives that line high for several milliseconds, then releases it. I measured it drifting down to 0.5 V (probably due to R188 which connects to +3.3V, which is not powered during suspend).

When you exit S3 (wakeup), DCONLOAD again goes high, staying there until the CPU has had time to reconfigure its GPIO pins.

During these times when DCONLOAD is high, the DCON loses the display data.

I'm not sure what the correct solution is. It might be possible to pull DCONLOAD down to GND instead of up to +3.3V, but there is still the problem of the 5536 driving it as SLP_CLK_EN# .

[wmb@…]

Additional experiments suggest that the "SLP_CLK_EN#" function is not involved. The current hypothesis is that the 5536 tri-states the GPIO11 line when it turns off (a reasonable behavior) and when it is coming back up, so the pull-up resistor drives the signal high until the voltage on the rail collapses. If that is correct, then replacing the pull-up with a pull-down is likely to be effective.

[wmb@…]

I have confirmed the tri-state hypothesis and the effectiveness of a pull-down in preventing DCONLOAD glitches.

a) First test: connected 2K2 resistor from DCONLOAD to ground, thus forming a voltage divider with the existing pull-up resistor. In this configuration, with DCONLOAD set to low via the GPIO, the signal glitched to 0.6V at S3 entry and exit. 0.6V is the expected value for 10K up / 2K2 down voltage divider driven from 3.3V. So the tri-state hypothesis is confirmed.

b) Second test: removed the 10K pullup (R188), leaving the 2K2 pulldown connected. In this configuration, with DCONLOAD set to low via the GPIO, the signal remained low throughout the S3 cycle.

In configuration (b), the LCD screen retains the correct display image while suspended (with the unmodified board, entry to S3 caused the display to fade out).

However, there is still a remaining problem: when waking up from S3 (initiated by briefly pressing the power button), the LCD screen usually immediately goes blank (actually almost blank - it has closely-spaced dim vertical lines). I saw one time where this didn't happen - the screen stayed intact upon wakeup - but most of the time the screen blanks. This is not caused by DCONLOAD glitches; I have verified that DCONLOAD remains solidly low while this is happening.

[wad]

I will accept the ticket to get it into the Quanta EC list for B3, but Mitch gets the credit for debugging.

The remaining problem sounds power related, but the DRAM buffer should retain at least a portion of the data through several hundred milliseconds. I interpret your report to imply that it remains blank until rebooted ?

[wmb@…]

Yes, it remains blank until rebooted. Although I strongly suspect that I could reinitialize the display subsystem and redraw the screen to get the data back - which is about the same as rebooting from the DCON point of view.

It could be power related, or perhaps it might have something to do with other control signals to the DCON - e.g. DCONBLNK or the SMBUS link.

[wmb@…]

Hmmm, it appears that DCONBLNK really goes from the DCON to the 5536 - the off-page reference symbol on page 11 of the schematic is wrong. That removes DCONBLNK from the list of likely culprits...

[wmb@…]

I reworked a B2 system to pull DCONLOAD to GND through a 10K resistor, removing the 10K pullup resistor R188.

The system retains the screen data across a suspend/resume cycle. So the "remaining problem" mentioned above does not seem to happen on B2.

For B3, I recommend changing R188 from a pull-up to a pull-down.

[wmb@…]

I have one unmodified B2 and one with DCONLOAD pulled down instead of up.

The unmodified one is very flaky with my firmware S3 test - the screen glitches on some wakeups, and the system hangs randomly on resume (about 1 in 10 resumes, on average).

The modified one is solid; I have done something like 50 suspend/resume cycles in a row with no glitches or other problems.

[wad]

Mitch's solution is accepted, and this will be fixed in the B3 build.

In the meantime, B2 units may be modified to fix this problem using the direction at: http://wiki.laptop.org/go/B2_Suspend_ECR#DCONLOAD_pulldown