Measurements: Massive Display-related power savings

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| The real problem is in glamofb_blank() code (which I have written
| as part of the patchset regarding the measurements in this thread).
|
| All that we do in glamofb_blank() is to disable DCLK of the display
| controller.  If I uncomment this code, the device properly comes back
after
| the blanking.

Thanks for looking into it further.  Currently on stable-tracking we
have what seems to be quite stable suspend/resume now but always it
resumes with a WSOD, I found yesterday I was also looking in the wrong
place about jbt6k74 init because with a 'scope I saw no video data is
coming from Glamo and it's the DCLK issue you found too.  However, I
differentially dumped the glamo registers before and after then to try
to identify the bad boy and I didn't see any relevant difference :-(

- -0040:  05db 51f2 0aba b000 0003 0000 0000 0000
- -0050:  000f 111e c443 111e 000f 0001 050f 020f
+0040:  05db 518d 0aba aedf 0003 0000 0000 0000
+0050:  000f 111e ccc3 111e 000f 0001 050f 020f
- -1180:  8023 0000 0000 0000 0000 0000 0000 0000
+1180:  81ce 0025 2b00 0003 0000 0000 0000 0000

This compared all the regs covered in

cat /sys/class/i2c-adapter/i2c-0/0-0073/glamo3362.0/regs

(note changed path on stable-tracking since Glamo is a child of PMU now).

Also, MMC is up and working fine so there is no memory- or pll- level
issue in Glamo when it is in this mode.

| It really puzzles me what could be the cause of this.  Only few GTA02
devices
| seem to show this behaviour.  Mickey's device exhibiting this problem is
| a MP GTA02v6, just like other devices not exhibiting the problem.  It
is always
| reliable on a given device.  Either it does always come back with a
white screen,
| or it does always work.  So it's unlikely timing related.
|
| There would be two questions for Smedia (who's the contact inside
Openmoko to
| talk to them?):
|
| 1) Is there a certain condition when we can disable DCLK?  Maybe stopping
|    this clock is only valid in a certain state e.g. during vertical blank?
|    What we want to do is to stop the glamo from producing any video output
|    signal.
|
| 2) Did Openmoko ever use different silicon revisions of the Glamo 3362 for
|    different production runs?

I think we probably solve it ourselves before S-Media will solve it.

One thing to bear in mind, framebuffer notifcation callback action on
jbt6k74 driver is asynchronous to resume on that driver, if I understood
the situation.  It would be one of a very shrunken number of races left
on stable-tracking.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkGbQkACgkQOjLpvpq7dMoWZACfcVgFDNmLLpY4maEr0bL169M+
3q4AoIHb9CQ4FVCCaGSpMIEcjiCoJfL9
=QRT5
-----END PGP SIGNATURE-----