logger: modify the sysfs for the enable toggle

 * You can disable logging by echo-ing 0 in /sys/module/logger/parameters/enabled
 * By default the logging is enabled.

Signed-off-by: Dan Trifan <jimsth@gmail.com>
power: make sync on suspend optional

On embedded devices with built-in batteries, it is not so
important to sync the file systems before suspend.  The chance
of losing power during suspend are no greater than they are
when the system is awake.  The sync operations can greatly
increase suspend latency when the system has accrued many dirty
pages and/or the target storage devices are not particularly
fast.

This commit adds a kernel config option to allow file system
sync in the suspend and earlysuspend paths to be disabled.  It is
enabled by default.  It also exposes two command line options to
control this feature: suspendsync and earlysuspendsync.

Change-Id: I97ff1b9d0431c9b6aee4dbd00e40d559d3ee1ec8
Signed-off-by: Russ Knize <Russ.Knize@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/614512
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Igor Kovalenko <igork@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
[ljc: Bring-up on to newer HEAD]
Signed-off-by: Luis Cruz <ljc2491@gmail.com>

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: do not sync filesystems before suspend

Signed-off-by: Dan Trifan <jimsth@gmail.com>
power: quickwakeup: initial driver

This driver allows clients to register code to be called upon wakeup
so that clients can perform specific checks and vote to drop the system
back into suspend without fully resuming if the wake reason was a special
quick wakeup event.

Propagation of (CR)

Change-Id: I791ff02f34b616e6da2b68efc2d4eb4449e5bbe7
Signed-off-by: James Wylder <jwylder1@motorola.com>
Signed-off-by: Jared Suttles <jsuttles@motorola.com>
Signed-off-by: Joe Swantek <w98568@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/611835
SLTApproved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Joseph Swantek <jswantek@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
omap4: pm44xx: add suspend_again handler

Call quickwakeup clients to enable us to perform very small amounts of processing and then to drop quickly back into suspend.

Picked from here: https://github.com/SyNtheticNightmar3/kernel_asus_flo/commit/b4f468d93955ce36539450fc3eab8fcd1c0e2714

Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: enable quick wakeup

Signed-off-by: Dan Trifan <jimsth@gmail.com>
CHROMIUM: clocksource: allow clocksources to be selected earlier during boot

Global and per-CPU timers ought to be initialized once SMP initialization
is complete.  Although the clocksources associated with these timers may
not be registered until later in the boot process, they should be ready
to go once registered.  We'd like to stop using the super low-resolution
boot clocksource (jiffies) as soon as possible since devices may rely on
accurate timekeeping while being brought up during boot, so move
clocksource_done_booting() to arch_initcall time so that we can switch
to a higher-resolution clocksrouce earlier in the boot process.

BUG=chrome-os-partner:20458
TEST=Pit and Lumpy both still boot reliably.  Boot time on Pit improves
considerably:
Before: [    3.032967] VFS: Mounted root ...
After:  [    1.855936] VFS: Mounted root ...
Lumpy boot time improves very slightly:
Before: [    1.786347] VFS: Mounted root ...
After:  [    1.754297] VFS: Mounted root ...

Change-Id: I951fee2e7e4697ccfe7f845a2c1c6bd80669a8d5
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170102
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
lib: Proportions with flexible period

Implement code computing proportions of events of different type (like code in
lib/proportions.c) but allowing periods to have different lengths. This allows
us to have aging periods of fixed wallclock time which gives better proportion
estimates given the hugely varying throughput of different devices - previous
measuring of aging period by number of events has the problem that a reasonable
period length for a system with low-end USB stick is not a reasonable period
length for a system with high-end storage array resulting either in too slow
proportion updates or too fluctuating proportion updates.

Change-Id: I63575f8ce47f6a05757dcfa8dae8f8617c12a4bf
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
lib: Fix possible deadlock in flexible proportion code

When percpu counter function in fprop_new_period() is interrupted by an
interrupt while holding counter lock, it can cause deadlock when the
interrupt wants to take the lock as well. Fix the problem by disabling
interrupts when calling percpu counter functions.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
lib/flex_proportions.c: fix corruption of denominator in flexible proportions

When racing with CPU hotplug, percpu_counter_sum() can return negative
values for the number of observed events.

This confuses fprop_new_period(), which uses unsigned type and as a
result number of events is set to big *positive* number.  From that
moment on, things go pear shaped and can result e.g.  in division by
zero as denominator is later truncated to 32-bits.

This bug causes a divide-by-zero oops in bdi_dirty_limit() in Borislav's
3.6.0-rc6 based kernel.

Fix the issue by using a signed type in fprop_new_period().  That makes
us bail out from the function without doing anything (mistakenly)
thinking there are no events to age.  That makes aging somewhat
inaccurate but getting accurate data would be rather hard.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: Borislav Petkov <bp@amd64.org>
Reported-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: bring in minmax governor

 * CREDITS to @Erasmux
 * I loved this one on my TF101, revive it.
 * Rewritten for new cpufreq API

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: Allow minmax to be set as default

While the Kconfig option CPU_FREQ_DEFAULT_GOV_MINMAX implies that
'minmax' will be selected as the default gov, compiling with it
enabled will cause errors unless defined in cpufreq.h

Fixes: 'error: 'CPUFREQ_DEFAULT_GOVERNOR' undeclared'
with CONFIG_CPU_FREQ_DEFAULT_GOV_MINMAX=y

Signed-off-by: Dan Trifan <jimsth@gmail.com>