Messages in this thread | | | Date | Mon, 5 Dec 2011 08:56:32 +1100 | From | NeilBrown <> | Subject | Re: [PATCH 1/1] driver core: disable device's runtime pm during shutdown |
| |
On Wed, 16 Nov 2011 00:16:08 +0100 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Tuesday, November 15, 2011, Greg KH wrote: > > On Mon, Nov 14, 2011 at 11:27:37PM +0100, Rafael J. Wysocki wrote: > > > On Monday, November 14, 2011, Peter Chen wrote: > > > > There may be an issue when the user issue "reboot/shutdown" command, then > > > > the device has shut down its hardware, after that, this runtime-pm featured > > > > device's driver will probably be scheduled to do its suspend routine, > > > > and at its suspend routine, it may access hardware, but the device has > > > > already shutdown physically, then the system hang may be occurred. > > > > > > > > I ran out this issue using an auto-suspend supported USB devices, like > > > > 3G modem, keyboard. The usb runtime suspend routine may be scheduled > > > > after the usb controller has been shut down, and the usb runtime suspend > > > > routine will try to suspend its roothub(controller), it will access > > > > register, then the system hang occurs as the controller is shutdown. > > > > Signed-off-by: Peter Chen <peter.chen@freescale.com> > > > > > > Greg, do you want me to take this one? > > > > Please do: > > Acked-by: Greg Kroah-Hartman <gregkh@suse.de> > > Done, thanks! >
Hi, this patches causes a problem for me.
Specifically it makes it impossible to power-down a device which uses twl4030 for power control on an omap3 processor.
To perform the shutdown we need to send a command over the i2c bus. The relevant bus is called omap_i2c.1 and this is normally in suspend mode. When a request is sent, omap_i2c_xfer uses pm_runtime_get_sync to wake it up, performs the transfer, then calls pm_runtime_put to let it go back to sleep.
So it is asleep when the new pm_runtime_disable() call is made, so it stays asleep, omap_i2c_xfer cannot wake it, the transfer doesn't happen and the system doesn't get powered off.
So here is a device that should *not* have pm disabled at shutdown.
So I feel this fix is a little too heavy-handed. I don't fully understand the problem scenario described above but it seems to me that if the auto-suspend timer can fire after the hardware has been shut down, then maybe the hardware-shutdown should be disabling that timer. Maybe?
Suggestions?
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |