ASoC: OMAP4: HDMI: add mixer control to get LPCM channels

Also fix a potential race condition where the state
could have changed during the sleep.

Change-Id: I189d0cd17ea56f5e0c2315061ab18acfcff2c91c
Signed-off-by: Simon Wilson <simonwilson@google.com>
ASoC: ABE: Use DMA at 16-bits specifically for 16-bits mono

Use sDMA configured at 16-bits specifically for 16-bits mono.
Otherwise, use 32-bits as 16-bits stereo can be packed into
a 32-bits container.

Since the DMA data size is not fixed, it doesn't make sense
to keep it as part of the static DMA parameters anymore.

Change-Id: Ib38a0d77fc8dc0935fdf3e61e291a500b32865d2
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>

Conflicts:
	sound/soc/omap/omap-abe.c
Revert "omap: l3 error: disable WARN dump"

This reverts commit 0fba1e7baaa5b00a645cb41e11b64a0c7ce4c7c1.
Revert "omap_l3_noc: added missing include"

This reverts commit 27e701a5f38a615c9fd82002cd09d88e88b650c2.
Revert "vm: convert snd_pcm_lib_mmap_iomem() to vm_iomap_memory() helper"

This reverts commit 88c4967e09540ba0c6bb1a8dd43e4b58aaa3027e.
omap: lpddr2 samsung data: tune timings
omap: lpddr2 samsung: fix include
Backport binder from omapzoom android - 3.8y branch.

Conflicts:
	drivers/staging/android/binder.c
cpufreq: Fix broken uevents for cpufreq governor and cpu devices

cyanogens uevent commit when the governor changes was rendered
non-working since kitkat (or so) as the uevent filter function
caused events to be dropped. Now hook into cpufreq_core_init()
and cpufreq_add_dev_interface() to create our basic ksets for
cpufreq and cpu devices. Also, we don't need to set environmental
data, so clean it up a bit.

This commit requires a change in ueventd.rc that add rules for
several files of interest.

Inspired by http://review.cyanogenmod.org/#/c/61579/
front_defconfig: disable DPLL_CASCADING
timer: optimize apply_slack()

__fls(mask) is equivalent to find_last_bit(&mask, BITS_PER_LONG), but cheaper.
find_last_bit was showing up high on the list when I was profiling for stalls
on icache misses on a system with very small cache size (MIPS).

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: edoko <r_data@naver.com>

Change-Id: I8a5021a2fb2936c00ffd456663a76cb1b23e3100
cpufreq: Fix sysfs deadlock with concurrent hotplug/frequency switch

Running one program that continuously hotplugs and replugs a cpu
concurrently with another program that continuously writes to the
scaling_setspeed node eventually deadlocks with:

=============================================
[ INFO: possible recursive locking detected ]
3.4.0 #37 Tainted: G        W
---------------------------------------------
filemonkey/122 is trying to acquire lock:
 (s_active#13){++++.+}, at: [<c01a3d28>] sysfs_remove_dir+0x9c/0xb4

but task is already holding lock:
 (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(s_active#13);
  lock(s_active#13);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by filemonkey/122:
 #0:  (&buffer->mutex){+.+.+.}, at: [<c01a2230>] sysfs_write_file+0x28/0x140
 #1:  (s_active#13){++++.+}, at: [<c01a22f0>] sysfs_write_file+0xe8/0x140

stack backtrace:
[<c0014fcc>] (unwind_backtrace+0x0/0x120) from [<c00ca600>] (validate_chain+0x6f8/0x1054)
[<c00ca600>] (validate_chain+0x6f8/0x1054) from [<c00cb778>] (__lock_acquire+0x81c/0x8d8)
[<c00cb778>] (__lock_acquire+0x81c/0x8d8) from [<c00cb9c0>] (lock_acquire+0x18c/0x1e8)
[<c00cb9c0>] (lock_acquire+0x18c/0x1e8) from [<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180)
[<c01a3ba8>] (sysfs_addrm_finish+0xd0/0x180) from [<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4)
[<c01a3d28>] (sysfs_remove_dir+0x9c/0xb4) from [<c02d0e5c>] (kobject_del+0x10/0x38)
[<c02d0e5c>] (kobject_del+0x10/0x38) from [<c02d0f74>] (kobject_release+0xf0/0x194)
[<c02d0f74>] (kobject_release+0xf0/0x194) from [<c0565a98>] (cpufreq_cpu_put+0xc/0x24)
[<c0565a98>] (cpufreq_cpu_put+0xc/0x24) from [<c05683f0>] (store+0x6c/0x74)
[<c05683f0>] (store+0x6c/0x74) from [<c01a2314>] (sysfs_write_file+0x10c/0x140)
[<c01a2314>] (sysfs_write_file+0x10c/0x140) from [<c014af44>] (vfs_write+0xb0/0x128)
[<c014af44>] (vfs_write+0xb0/0x128) from [<c014b06c>] (sys_write+0x3c/0x68)
[<c014b06c>] (sys_write+0x3c/0x68) from [<c000e0e0>] (ret_fast_syscall+0x0/0x3c)

This is because store() in cpufreq.c indirectly calls
kobject_get() via cpufreq_cpu_get() and is the last one to call
kobject_put() via cpufreq_cpu_put(). Sysfs code should not call
kobject_get() or kobject_put() directly (see the comment around
sysfs_schedule_callback() for more information).

Fix this deadlock by introducing two new functions:

	struct cpufreq_policy *cpufreq_cpu_get_sysfs(unsigned int cpu)
	void cpufreq_cpu_put_sysfs(struct cpufreq_policy *data)

which do the same thing as cpufreq_cpu_{get,put}() but don't call
kobject functions.

To easily trigger this deadlock you can insert an msleep() with a
reasonably large value right after the fail label at the bottom
of the store() function in cpufreq.c and then write
scaling_setspeed in one task and offline the cpu in another. The
first task will hang and be detected by the hung task detector.

Change-Id: I7db3608f43ef97d7eb1214598bc39946c82734ee
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS

commit 8404663f81d212918ff85f493649a7991209fa04 upstream.

The {get,put}_user macros don't perform range checking on the provided
__user address when !CPU_HAS_DOMAINS.

This patch reworks the out-of-line assembly accessors to check the user
address against a specified limit, returning -EFAULT if is is out of
range.

[will: changed get_user register allocation to match put_user]
[rmk: fixed building on older ARM architectures]

Change-Id: I3e3ddeaa51e47798bcf27181afd3785ccc015317
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
	arch/arm/lib/getuser.S
	arch/arm/lib/putuser.S
kswapd: reduce time spent in congestion_wait

By reducing the amount of time kswapd spends in
congestion_wait kswapd is able to free up more
memory in the background and therefore  reduce
the amount  of time spent in direct reclaim.

Change-Id: I46ebe577f8954d8ce9907430958fa0e53090979c
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Greg Grisco <ggrisco@codeaurora.org>
Signed-off-by: Quallenauge <Hamsi2k@freenet.de>
mm: vmscan: Move pages that fail swapout to LRU active list

Move pages that fail swapout to the LRU active list to reduce
pressure on swap device when swapping out is already failing.
This helps when using a pseudo swap device such as zram which
starts failing when memory is low.

Change-Id: Ib136cd0a744378aa93d837a24b9143ee818c80b3
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Quallenauge <Hamsi2k@freenet.de>
gpio_input: convert from wakelocks to wakeup sources

And add device names to wakeup source names

Change-Id: Ia5f2723319a2e749f00d6ec7d846edff6af6d5c2
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Quallenauge <Hamsi2k@freenet.de>
omap4-common: only disable interrupt when port is suspending

Previously the interrupt got disabled and then the suspend
could be aborted due to data in the rx fifo. When this happened
the interrupt was never enabled again.

Change-Id: I3d145b48b56f5ef69aa062e36e4dff3ed5bdff42

Conflicts:
	drivers/tty/serial/omap-serial.c
OMAP: USB Host: Wake up L3_init clockdomain ASAP on USB remote wakeup event

OMAP: USB Host: Wake up L3_init clockdomain ASAP on USB remote wakeup event

[backported from p-android-omap-3.4]

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, currently we enable different clocks
to the Host too late and its internal state
machine may enter in some bad state.

This patch ensures that clocks to the host are
enabled as soon as possible so its internal
state logic can start to handle remote wakeup
without latencies introduced by PM runtime
framework.

Change-Id: Id9658f69696d7040cc563681a1bb0c4527e81fdb
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>

Conflicts:
	arch/arm/mach-omap2/usb-host.c

Conflicts:
	arch/arm/mach-omap2/usb-host.c
omap: usb host: mux: force PHY STP line to low state in idle/off mode

omap: usb host: mux: force PHY STP line to low state in idle/off mode

[backported from p-android-omap-3.4]

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, we enable different clocks to the Host quite late
and its internal state machine may enter in some bad state.
Next patch http://review.omapzoom.org/32086 (OMAP: USB Host: Wake
up L3_init clockdomain ASAP on USB remote wakeup event)(1) fixed
this issue for OMAP4470 but it is not enough for 4430/4460
where restoring from OFF mode takes more time.

In this case next behavior has been observed on ULPI lines
for 4430/4460 (say initial OMAP's state is OFF mode):      (2)
 - a device connected to PHY issues remote wakeup
 - the PHY directly represents this state on D0:D1 lines
 - OMAP sees line state change and starts its 'resume from OFF'
   procedure
 - after ~100 uS after D0:D1 change, OMAP asserts STP line
 - PHY starts is internal resume procedure, deasserts DIR and
   starts to generate clocks to OMAP
 - after ~8ms OMAP deasserts STP line and puts the PHY to the
   low-power state immediately (sends 0x84-0x4A 0x84-0x4A 0x84-0x05
   sequence)
 - the OMAP restoring sequence is still in progress and is only on
   its start phase.

After above sequence the ULPI interface is not functional
anymore for OMAP - no matter PORTSC.FPR nor direct access
through INSNREG05_ULPI register you use.
The root cause seems to be related to i693 errata (USB HOST EHCI - Port
Resume Fails On Second Resume Iteration) that says we have to
switch ULPI_CLK to internal clocksource for short time after *each* PHY
suspend, otherwise internal EHCI counter will not reach
18 and second resume iteration will fail.
The reason of why it affects only 4430/4460 but not 4470 is because
after applying patch [1] 4470 restores from OFF mode fast enough
and so internal EHCI logic does not have a chance to
put the PHY in low power mode. Whereas for 4430/4460
the restore-from-OFF sequence is a little bit longer,
and we have PHY-resume and PHY-suspend [2], and after that
after end of restore-from-OFF we try to wakeup the PHY
again and meet the i693 condition.

The workaround here consists in keeping the STP line
in low state until the EHCI is ready to work with PHY.

For this, the patch uses some MUX magic, forcing the
STP to 'safe mode' and pulldown for idle or OFF state
and muxing it back to STP mode for active state.

This prevents wake-up-the-PHY in the middle of restoring from
off sequence and works fine on all OMAP4 SoCs.

Change-Id: I95d7bf707f76519ee7d81f4437d8564f03b5d602
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
mfd: Move omap-usb-host usbhs init before allocing child dev

mfd: Move omap-usb-host usbhs init before allocing child dev

[backported from p-android-omap-3.4]

There could be possible race condition where the host dev's
are alloced and added to platform dev just before usbhs_init.
Just move usbhs_init before adding child dev.

Change-Id: I3c54db97f39c7714427e738560fba8076283e66d
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>