possible issue with lcd suspend/resume
sean at mcneil.com
Wed Jun 11 20:38:28 CEST 2008
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,
> ~ * 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
> ~ * and software requests. The hardware may have gone
> ~ * 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
> ~ * (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
> ~ * 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
> ~ * the system from a snapshot taken after an earlier FREEZE.
> ~ * Some drivers will need to reset their hardware state
> ~ * 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
> ~ * 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.
More information about the openmoko-kernel