possible issue with lcd suspend/resume

[Sean McNeil]

I think the patch where I essentially did a printk if I hit it a second 
time crashes. So I'm pretty sure suspend is getting suspended twice as I 
did indeed crash :)

Andy Green wrote:
> 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