possible issue with lcd suspend/resume

[Andy Green]

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

Somebody in the thread at some point said:
| Somebody in the thread at some point said:
|
| | I am uncertain if this is possible, but I haven't reproduced a problem
| | with the lcd going permanently blank on me since this patch. Can a
| | suspend/resume get called without an appropriate pairing?
|
| WAAAAAAH I just had a BAAAAD thought that could explain mucho suspend /
| resume misery.... we don't take care about
|
| pm_message_t state
|
| argument to suspend function... anywhere really...  WAAAAH

OK it's normally alright to do that... comment from ./include/linux/pm.h


/*
~ * Several driver power state transitions are externally visible, affecting
~ * the state of pending I/O queues and (for drivers that touch hardware)
~ * interrupts, wakeups, DMA, and other hardware state.  There may also be
~ * internal transitions to various low power modes, which are transparent
~ * to the rest of the driver stack (such as a driver that's ON gating off
~ * clocks which are not in active use).
~ *
~ * One transition is triggered by resume(), after a suspend() call; the
~ * message is implicit:
~ *
~ * ON           Driver starts working again, responding to hardware events
~ *              and software requests.  The hardware may have gone through
~ *              a power-off reset, or it may have maintained state from the
~ *              previous suspend() which the driver will rely on while
~ *              resuming.  On most platforms, there are no restrictions on
~ *              availability of resources like clocks during resume().
~ *
~ * Other transitions are triggered by messages sent using suspend().  All
~ * these transitions quiesce the driver, so that I/O queues are inactive.
~ * That commonly entails turning off IRQs and DMA; there may be rules
~ * about how to quiesce that are specific to the bus or the device's type.
~ * (For example, network drivers mark the link state.)  Other details may
~ * differ according to the message:
~ *
~ * SUSPEND      Quiesce, enter a low power device state appropriate for
~ *              the upcoming system state (such as PCI_D3hot), and enable
~ *              wakeup events as appropriate.
~ *
~ * FREEZE       Quiesce operations so that a consistent image can be saved;
~ *              but do NOT otherwise enter a low power device state, and do
~ *              NOT emit system wakeup events.
~ *
~ * PRETHAW      Quiesce as if for FREEZE; additionally, prepare for
restoring
~ *              the system from a snapshot taken after an earlier FREEZE.
~ *              Some drivers will need to reset their hardware state
instead
~ *              of preserving it, to ensure that it's never mistaken
for the
~ *              state which that earlier snapshot had set up.
~ *


~    <===== important bit

~ * A minimally power-aware driver treats all messages as SUSPEND, fully
~ * reinitializes its device during resume() -- whether or not it was reset
~ * during the suspend/resume cycle -- and can't issue wakeup events.
~ *
~ * More power-aware drivers may also use low power states at runtime as
~ * well as during system sleep states like PM_SUSPEND_STANDBY.  They may
~ * be able to use wakeup events to exit from runtime low-power states,
~ * or from system low-power states such as standby or suspend-to-RAM.
~ */

#define PM_EVENT_ON 0
#define PM_EVENT_FREEZE 1
#define PM_EVENT_SUSPEND 2
#define PM_EVENT_PRETHAW 3


I checked another mainline i2c device that suspends and it too doesn't
take care about the suspend reason.  But I think you are on to the
solution of the mysteries around pcf50633 suspend and resume badness,
suspend is getting called multiple times and we are doing our stuff
multiple times when we should pick a PM_EVENT_* and only work with that
one.  It might give a little speed increase to suspend action as well.

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

iEYEARECAAYFAkhOwfcACgkQOjLpvpq7dMr8oACeIqqwxMQCdLcm0F/l3y7FjMmm
Ee0An3ucUiv6GqydhPvc7MrZJ02rPbmq
=phnV
-----END PGP SIGNATURE-----