linux-toradex.git/drivers/base, branch imx-android-r13.2

ENGR00175844 irq: enable IRQF_EARLY_RESUME irq when dpm_suspend_noirq failed

2012-03-16T01:54:46+00:00

The dpm_suspend_noirq routing calls suspend_device_irqs()
first to disable all the irq no matter what flags it has.
Then it enumerates the device driver on dpm_suspend_list to
call their suspend_noirq pm callback. If any dev suspend
failed, it will call dpm_resume_noirq to re-enable all
the irq without IRQF_EARLY_RESUME, and return failed.

If dpm_suspend_noirq() return failed, then no syscore_resume()
can be called, that means the irq with flag IRQF_EARLY_RESUME,
can not be re-enabled on this case.

	error = dpm_suspend_noirq(PMSG_SUSPEND);
	if (error) {
		..
		goto Platform_finish;
	}
	....
	error = syscore_suspend();
	if (!error) {
		...
		syscore_resume();
	}
	...
	dpm_resume_noirq(PMSG_RESUME);

 Platform_finish:
	if (suspend_ops->finish)
		suspend_ops->finish();

So we must enable all the irqs no matter it's IRQF_EARLY_RESUME
or not.
Otherwise the GPIO power key who's irq has flag of IRQF_EARLY_RESUME
will be disabled forever when some device failed to suspend.

Signed-off-by: Xinyu Chen

Merge branch 'android-3.0' into imx_3.0.15_android

2012-02-02T08:58:05+00:00

Conflicts:
	drivers/misc/Kconfig
	drivers/misc/Makefile
	drivers/net/wireless/Makefile
	kernel/power/main.c
	sound/soc/soc-core.c

ENGR00133978 PM: add time sensitive debug function to suspend & resume

2012-01-09T11:53:47+00:00

There was some driver is slow on suspend/resume,
but some embeded system like eReader,Cellphone
are time sensitive,this commit will report the slow
driver on suspend/resume, the default value is 500us(0.5ms)

Also, the threshold can be change by modify
'/sys/power/device_suspend_time_threshold' to change the threshold,
it is in microsecond.

The output is like:

PM: device platform:soc-audio.2 suspend too slow, takes          606.696 msecs
PM: device platform:mxc_sdc_fb.1 suspend too slow, takes         7.708 msecs

the default state of suspend driver is default off,
if you want to debug the suspend time, echo time in
microsecond(u Second) to /sys/powe/device_suspend_time_threshold

eg: I want to know which driver suspend & resume takes
more that 0.5 ms (500 us), you can just :

ehco 500 > /sys/power/device_suspend_time_threshold

Signed-off-by: Zhang Jiejing

drivers/base/node.c: fix compilation error with older versions of gcc

2011-11-26T17:09:59+00:00

commit 91a13c281d7d4648c0b32dede11a0144c4e7984c upstream.

Patch to fix the error message "directives may not be used inside a macro
argument" which appears when the kernel is compiled for the cris architecture.

Signed-off-by: Claudio Scordino 
Acked-by: David Rientjes 
Signed-off-by: Greg Kroah-Hartman

PM / driver core: disable device's runtime PM during shutdown

2011-11-26T17:09:56+00:00

commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 upstream.

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 
Acked-by: Ming Lei 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / Runtime: Automatically retry failed autosuspends

2011-11-11T17:36:57+00:00

commit 886486b792e4f6f96d4fbe8ec5bf20811cab7d6a upstream.

Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed.  The idle callback routine could
then schedule a delayed suspend for some time later.

However this behavior was changed by commit
f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle
notification after failing suspend).  No notifications were sent, and
there was no clear mechanism to retry failed suspends.

This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down.  Therefore
this patch (as1492) adds a mechanism for retrying failed
autosuspends.  If the callback routine updates the last_busy field so
that the next autosuspend expiration time is in the future, the
autosuspend will automatically be rescheduled.

Signed-off-by: Alan Stern 
Tested-by: Henrik Rydberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Merge commit 'v3.0.8' into android-3.0

2011-10-27T22:01:19+00:00

firmware loader: allow builtin firmware load even if usermodehelper is disabled

2011-10-03T18:41:07+00:00

commit caca9510ff4e5d842c0589110243d60927836222 upstream.

In commit a144c6a6c924 ("PM: Print a warning if firmware is requested
when tasks are frozen") we not only printed a warning if somebody tried
to load the firmware when tasks are frozen - we also failed the load.

But that check was done before the check for built-in firmware, and then
when we disallowed usermode helpers during bootup (commit 288d5abec831:
"Boot up with usermodehelper disabled"), that actually means that
built-in modules can no longer load their firmware even if the firmware
is built in too.  Which used to work, and some people depended on it for
the R100 driver.

So move the test for usermodehelper_is_disabled() down, to after
checking the built-in firmware.

This should fix:

	https://bugzilla.kernel.org/show_bug.cgi?id=40952

Reported-by: James Cloos 
Bisected-by: Elimar Riesebieter 
Cc: Michel Dänzer 
Cc: Rafael Wysocki 
Cc: Greg Kroah-Hartman 
Cc: Valdis Kletnieks 
Signed-off-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Lucas Villa Real 
Signed-off-by: Greg Kroah-Hartman

PM: runtime: add might_sleep to PM runtime functions

2011-09-24T03:08:51+00:00

The list of functions that can be called in atomic context is
non-intuitive (pm_runtime_put_sync can not, but
pm_runtime_put_sync_suspend can, if pm_runtime_irq_safe has
been called?).  The code is actively misleading - the entry
points all start with spin_lock_irqsave, suggesting they
are safe to call in atomic context, but may later
enable interrupts.

Add might_sleep_if to all the __pm_runtime_* entry points
to enforce correct usage.

Also add pm_runtime_put_sync_autosuspend to the list of
functions that can be called in atomic context.

Change-Id: Icac17a10d77c64d44bd2761a91a588dfd1d0c6f0
Signed-off-by: Colin Cross

Merge commit 'v3.0' into android-3.0

2011-08-11T01:04:30+00:00