CHROMIUM: mfd: s5m-core: Enable low-jitter via DT.

Provide facility via device tree to activate the low-jitter
capababilities of the 32Khz clocks (BT, CP, AP).  Note the feature is
enabled for all the clocks or none per the design

BUG=chrome-os-partner:17833 chrome-os-partner:17858 chrome-os-partner:21952
TEST=manual
1. boot kernel, login as root
2. examine CTRL1 (0xa) register and see Low Jitter_EN bit (<3>) is
enabled for the spring design.
  i2cget -y -f 0 0x66 0xa
  0xf

Change-Id: Ibf9cd7527157b8ce9efeee91a3d40d0c0e13e1ff
Signed-off-by: Todd Broch <tbroch@chromium.org>
Original-Change-Id: I80750a3049806692c1c1e214982577f2f39899e1
Reviewed-on: https://gerrit.chromium.org/gerrit/66037
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: mfd: s5m: Refactor regmap usage.

Refactor sec_bulk|reg_* functions usage of regmap to facilitate
multiple regmapped devices in preparation for using s5m-rtc.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:19036 chrome-os-partner:21952
TEST=manual, compiles & kernel boots.

Change-Id: I1131503e79a1d1469f3ea9bcde43ace1ddc3bbdb
Original-Change-Id: I4ac47de476cd6d94ebd751fa0aee7800f369b1ad
Reviewed-on: https://gerrit.chromium.org/gerrit/50529
Reviewed-on: https://gerrit.chromium.org/gerrit/66038
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: rtc: s5m-rtc: Real-time clock driver for s5m8767.

Driver largely based off implementation in
  git://git.insignal.co.kr/samsung/exynos/android/kernel/samsung/exynos3.0

Although it would not backport cleanly.  Commits were:

  a781deb rtc: s5m: Modify read function for s5m8763
  e03092e rtc: Fix the minor bug for s5m8767a
  6f82705 rtc: Set initial time in s5m8767a rtc
  9e47078 mfd: Add wtsr and smpl function for s5m8767a
  49f0e86 rtc: Modify rtc_set_time for s5m rtc driver
  537c944 rtc: Modify s5m8767a EVT3 rtc driver
  4c0332b rtc: Add s5m rtc driver

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:19036 chrome-os-partner:21952
TEST=manual, compiles & kernel boots.

Change-Id: I4daa63ac4c1fc2165ea64165f6c8e03b914b5703
Original-Change-Id: I06e01e0171bd2f044977c0f4dfe34cea7641a35f
Reviewed-on: https://gerrit.chromium.org/gerrit/50530
Reviewed-on: https://gerrit.chromium.org/gerrit/66039
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: mfd: s5m: Enable RTC as wakeup source in suspend.

CL adds necessary power management functions to enable PMICs RTC wake
alarm as a wake source.

Signed-off-by: Todd Broch <tbroch@chromium.org>

BUG=chrome-os-partner:19427 chrome-os-partner:21952
TEST=manual,

rtc=`readlink /dev/rtc`
echo "+10s" > /sys/class/rtc/${rtc}/wakealarm
echo mem > /sys/power/state

Change-Id: I791adecbcd7f48521e60b98dddc1954cb1f53b47
Original-Change-Id: I155ccd6f058cdf8ed362a2c128226c5904379432
Reviewed-on: https://gerrit.chromium.org/gerrit/51338
Reviewed-on: https://gerrit.chromium.org/gerrit/66040
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: mfd: initialize EC communication earlier

The eDP bridge loaded by the DRM driver needs to be able to control the
screen regulators.
The FETs controlling the screen backlight and VDD are behind the EC, so
we need the EC MFD to be initialized in an earlier phase to allow the
(virtual) TPS65090 driver to register those FETs before the bridge init.

A similar change was done on the SPI version of the EC driver for Pit.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:21952
TEST=boot on Spring and see the traces from the virtual TPS65090
regulators earlier than the display port initialization.

Change-Id: I62223ea9fa79651a787754d45e05dd26edb7a029
Reviewed-on: https://gerrit.chromium.org/gerrit/64870
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: ASoC: samsung: enable MAX98089 support for Spring

The Spring board is using the MAX98089 audio codec.
This codec is supported by the MAX98088 driver and has the same
audio_map as the MAX98090, let's configure everything to get sound.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:21952
TEST=play audio on Spring.

Change-Id: Ieee668cb45f53cc53580cdcdfa3e39b69bbf391d
Reviewed-on: https://gerrit.chromium.org/gerrit/66115
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CHROMIUM: config: update config for Spring

Compile Spring specific drivers:
- S5M8767 PMIC driver
- virtual driver for the TPS65090 behind the EC.
- MAX98088 audio codec driver for MAX98089.
- LM90 driver in order to support G781 thermal sensor.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:21952
TEST=boot on Spring and manually check into /sys/class/regulators that
we are seeing all TPS65090 FETs and the S5M8767 bucks and LDOs, play
sound, "cat /sys/bus/i2c/devices/7-004c/temp[12]_input" and see board
temperature in milli-celsius.

Change-Id: Ide3d869d81833fd4ecb4081afde9606d36907a5a
Reviewed-on: https://gerrit.chromium.org/gerrit/64871
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
UPSTREAM: ARM: tegra: do v7_invalidate_l1 only when CPU is Cortex-A9

The v7_invalidate_l1 was used for the L1 cache that come out from reset
in a undefined state. This is no need for Cortex-A15. We do it for A9
only.

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit c04c77540a4f996ee94d0240bbae3a7512febd37)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Change-Id: Iba77702a1addc076dcdbc9150043606e2ca4f8bf
Reviewed-on: https://gerrit.chromium.org/gerrit/66330
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
UPSTREAM: ARM: tegra: add a flag for tegra_disable_clean_inv_dcache to do LoUIS or ALL

Adding a flag for tegra_disable_clean_inv_dcache to flush cache as LoUIS
or ALL. After this patch, the v7_flush_dcache_louis is used for CPU hotplug
and CPU suspend in CPU power down (e.g. CPU idle power-down mode) case. And
the v7_flush_dcache_all is used for CPU cluster power down (e.g. suspend to
LP2 mode).

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit ac2527bfc21739b77d687df1bfc4e973103fef7b)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Change-Id: Ida87d5bf9e319c51d8f6483ac40c570a90b0c166
Reviewed-on: https://gerrit.chromium.org/gerrit/66331
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
UPSTREAM: ARM: tegra: set up the correct L2 data RAM latency for Cortex-A15

When there is a cluster power down cycle in suspend, we need to set up
the correct L2 RAM data RAM latency to make L2 cache work correctly. This
is only needed for cluster 0 and needs to be done in tegra_resume before
the cache is enabled.

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit 2f5aaa3d2703256d37ae75818c495783d4ad0543)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Change-Id: Ib3b99eee2495d24d5a5b6568eb4d0546b9207636
Reviewed-on: https://gerrit.chromium.org/gerrit/66332
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
UPSTREAM: ARM: tegra: shut off the CPU rail when the last CPU in suspend

When the last CPU core in suspend, the CPU power rail can be turned off
by setting flags to flow controller. Then the flow controller will inform
PMC to turn off the CPU rail when the last CPU goes into suspend.

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit 3f1be81eef0de7193aae389663f50d38df3a3788)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Conflicts:
	arch/arm/mach-tegra/flowctrl.h
	arch/arm/mach-tegra/pmc.c

Change-Id: I066132bef2749d15961e49609db5d7cbde043c49
Reviewed-on: https://gerrit.chromium.org/gerrit/66333
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Stop warning when the EC doesn't like a command

Just turning down some debugging messages. It's not an error when the EC
doesn't like what you've told it - that's your problem, not a problem with
the kernel.

BUG=chrome-os-partner:21314
BRANCH=falco,peppy
TEST=manual

From the host, run:

  ectool tempsinfo all
  dmesg | tail

Before this change, you'd see stuff like this:

[  127.877857] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2
[  127.878206] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2
[  127.878556] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2
[  127.878905] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2
[  127.879253] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2
[  127.879603] cros_ec_lpc cros_ec_lpc.0: command 0x70 returned 2

With this change, you you don't.

Change-Id: I9be1db9496571c1a2242b75ed8cae6f82c1ea673
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66726
Reviewed-by: Randall Spangler <rspangler@chromium.org>
ARM: dts: Add non-removable property for emmc/sdio on exynos5420-peach-pit

eMMC and SDIO cards on pit are non-removable device. Lets set
non-removable property for then so that cards are not removed when
entered suspend.

BUG=chrome-os-partner:22053
TEST=build and booted on pit
TEST=run suspend_stress_test --memory_check still works

Change-Id: I5b4598e08cdd8d6bd4819a58c78566461f91fd45
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66352
ARM: dts: Add non-removable property for emmc/sdio on exynos5250-snow

eMMC and SDIO cards on snow are non-removable device. Lets set
non-removable property for then so that cards are not removed when
entered suspend.

BUG=chrome-os-partner:22053
TEST=build and booted on snow
TEST=run suspend_stress_test --memory_check

Change-Id: Ie0f36e1a14e05e1928216afccb561b3d319e7ea3
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66501
CHROMIUM: Fix REQBUFS(0) for encoder.

Handle REQBUFS(0) for CAPTURE queue as well. Also use the proper queue to call
it on for OUTPUT.

Signed-off-by: Pawel Osciak <posciak@chromium.org>

BUG=chromium:274941
TEST=veatest

Change-Id: I45a46727cc7a8bb552621f7db56fc01d3210179d
Reviewed-on: https://gerrit.chromium.org/gerrit/66624
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: kiran <kiran@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: John Sheu <sheu@chromium.org>
USTREAM: ARM: 7791/1: a.out: remove partial a.out support

a.out support on ARM requires that argc, argv and envp are passed in
r0-r2 respectively, which requires hacking load_aout_binary to
prevent argc being clobbered by the return code. Whilst mainline kernels
do set the registers up in start_thread, the aout loader has never
carried the hack in mainline.

Initialising the registers in this way actually goes against the libc
expectations for ELF binaries, where argc, argv and envp are passed on
the stack, with r0 being used to hold a pointer to an exit function for
cleaning up after the dynamic linker if required. If the pointer is
NULL, then it is ignored. When execing an ELF binary, Linux currently
zeroes r0, then sets it to argc and then finally clobbers it with the
return value of the execve syscall, so we actually end up with:

	r0 = 0
	stack[0] = argc
	r1 = stack[1] = argv
	r2 = stack[2] = envp

libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
works for user-spawned threads, but when executing an ELF binary from a
kernel thread (via call_usermodehelper), the execve is performed on the
ret_from_fork path, which restores r0 from the saved pt_regs, resulting
in argc being presented to the C library. This has horrible consequences
when the application exits, since we have an exit function registered
using argc, resulting in a jump to hyperspace.

This patch solves the problem by removing the partial a.out support from
arch/arm/ altogether.

Cc: <stable@vger.kernel.org>
Cc: Ashish Sangwan <ashishsangwan2@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit acfdd4b1f7590d02e9bae3b73bdbbc4a31b05d38)

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

BUG=chrome-os-partner:21806
TEST=recovery image works in normal mode

Change-Id: Idffa2c9f47d5a1e2cac66bdb1cc059bdbdd71de2
Reviewed-on: https://gerrit.chromium.org/gerrit/66741
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
usb-phy: samsung-usb3: Add HS Transmitter Pre-Emphasis Current Control

Some boards may require a greater amount of current sourced
to the D+ and D- lines to meet the USB compliance.
So adding a board specific property which can set the
Pre-emphasis rate of this current.

BUG=chrome-os-partner:21896
TEST=Build and boot the kernel on target, and check the value
of registers 0x1210001c and 0x1250001c is now 0x24d4e6e4 from
an earlier value of 0x24d466e4.
Further test eye diagram for USB compliance.

Change-Id: I67765ebeedb6a7ccbb0486f06bab76e19aedd5fb
Signed-off-by: Vivek Kumar Gautam <gautam.vivek@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66191
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: YeongKu Cho <ykn.cho@samsung.com>
Tested-by: YeongKu Cho <ykn.cho@samsung.com>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
dts: peach-pit: Set HS-Tx Pre-emphasis rate for usb3phy to 1X

Setting a Pre-emphasis current control of 1X, which increases
the Pre-emphasis current from current value of 0uA to 600uA.
This helps us in meeting USB compliance.

BUG=chrome-os-partner:21896
TEST=Build and boot the kernel on target, and check the value
of registers 0x1210001c and 0x1250001c is now 0x24d4e6e4 from
an earlier value of 0x24d466e4.
Further test eye diagram for USB compliance.

Change-Id: I8134d4aee4138dd0a337bbae3726b664867685d2
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66192
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: YeongKu Cho <ykn.cho@samsung.com>
Tested-by: YeongKu Cho <ykn.cho@samsung.com>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
HACK: USB: Fix USB device disconnects on resume.

The TLDR; version:

We've assumed that when a device disconnects after a resume from device
suspend, it was just a cheap, buggy device.  It turns out that the USB
core simply wasn't waiting long enough for the devices to transition
from resume to U0, and it's actually been the USB core's fault all
along...

 * * Please go test this patch with your "buggy" USB devices. * *

Background
----------

The USB 2.0 specification, section 7.1.7.7, says that upon device remote
wakeup signaling, the first active hub (which is often the roothub) must
rebroadcast the resume signaling for at least 20 ms (TDRSMDN).  After
that's done, the hub's suspend status change bit will be set, and system
software must not access the device for at least 10 ms (TRSMRCY).

It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to
Table 7-14.  That means the port can actually take longer than TRSMRCY
to resume.  Any attempt to communicate with the device, or reset the
device, will result in a USB device disconnect.

This discrepancy was found with the Intel xHCI host controller, because
they handle USB 2.0 resume a little differently than EHCI.  See the xHCI
spec, Figure 34: USB2 Root Hub Port Enabled Substate Diagram for
details.

Under EHCI, the host controller driver receives an interrupt when the
port suspend status change bit is set, and the USB core only has to time
the 10ms TRSMRCY value.

Under xHCI, the host receives an interrupt when the device remote wake
is first signaled, and the port goes into the Resume state.  The xHCI
driver kicks khubd, but doesn't allow the suspend state change to be
exposed until 20 ms (TDRSMDN) after the port status change event occurs.

Then, when the USB core calls into get port status, it transitions the
port from the Resume state to the RExit state by changing the port link
state to U0.  The xHCI driver will get a port status change event when
that transition is complete, but that port status change event is
currently ignored.

What actually happens
---------------------

By busy-waiting with xhci_handshake() after the Lynx Point LP host
initiates the transition to U0, and printing out how long it took, it
turns out that roughly 8% of the time, the host takes longer than 10 ms
to transition from RExit to U0.

Out of 227 remote wakeup events from a USB mouse and keyboard:
 - 163 transitions from RExit to U0 were immediate ( < 1 microsecond)
 - 47 transitions from RExit to U0 took under 10 ms
 - 17 transitions were over 10ms

Those 17 transitions (in microseconds) took:

10140
10305
10650
10659
10677
10695
10819
10907
10998
11030
11234
11618
11656
11724
11898
12060
12162
12757

The end result of that is that on 8% of remote wake events, the USB core
would attempt to communicate with the device before it was fully
resumed, causing USB disconnects or transfer errors on the next control
transfer to get the device status.

This bug has been reproduced under ChromeOS, which is very aggressive
about USB power management.  It enables auto-suspend for all internal
USB devices (wifi and bluetooth), and the disconnects wreck havoc on
those devices, causing the ChromeOS GUIs to repeatedly flash the USB
wifi setup screen on user login.  ChromeOS sets the autosuspend_delay_ms
to 100 milliseconds, and disables USB device persist.  I can reproduce
this bug with a vanilla 3.10.7 kernel under ChromeOS.

The USB core obviously needs to be changed to check the port status
after the TRSMRCY timeout, and continue to wait if the port is still in
the resuming state.  I will have to study the EHCI port status diagrams
in detail to figure out how the USB core can do this.  I can easily do
this without the USB core being involved, by changing the xHCI driver to
either:

1. Busy wait with xhci_handshake() in the xHCI get port status until
   the port is in U0.

2. Add a completion per xHCI port.  In xHCI get port status, initiate
   U0 entry, and wait on the port's completion for up to 20 ms.  In the
   port status change event code, complete that port's completion when
   the port is in U0 and the bus_state->resuming_ports bit is set.

In the meantime, simply increasing TRSMRCY from 10 ms to 20 ms solves
the resume issue on the Intel xHCI host.  Please test this patch under
other host controllers to see if it helps "fix" your buggy devices.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 4c7ec87025416a56d157fbed3391d102d339ebfe)
Signed-off-by: Benson Leung <bleung@chromium.org>

BUG=chrome-os-partner:21415
TEST=Follow the steps below to stress remote wakeup.
1. attach a usb mouse or keyboard to the system
2. dmesg | tail -n 20
   take note of the usb device that was just attached. In my case, the mouse showed up as 1-1
3. echo 100 > /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms
4. echo auto > /sys/bus/usb/devices/1-1/power/control
5. tail -f /var/log/messages

Check to see the mouse or keyboard does not disconnect after clicking on it repeatedly.

Change-Id: I3b6b12ad4b3df741b3ef5ddad9fa486b730aa612
Reviewed-on: https://gerrit.chromium.org/gerrit/66731
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
UPSTREAM: ARM: tegra: hook tegra_tear_down_cpu function

Hooking tegra_tear_down_cpu for Tegra114 for supporting cluster power
down when CPU cluster suspneded in LP2.

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit b573ad9f19ad56938a66c95fbc5122b77951cd5d)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Change-Id: Ia9ec09322d0edfdfea53351179b48318f6cdec46
Reviewed-on: https://gerrit.chromium.org/gerrit/66334
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>