CHROMIUM: video: tegra: Bump up the emc clock if it's too low

tegra_emc_bw_to_freq_req() appears to underestimate the required
DRAM rate for low bandwidth requests.  If it estimates a low DRAM
rate (<= 20.4Mhz), then bump up it up to the next available rate.

BUG=none
TEST=After updates to 0x19 version of emc table (CL:186868 and
CL:186869), the norrin panel no longer shows corruption.

Change-Id: I4f62feaf8bd4613f8f8c81169321fbbe69111f49
Signed-off-by: David Ung <davidu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186938
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: memory: tegra124: support revision 0x19 EMC tables

The revision 0x19 table adds the setting of the MC_EMEM_ARB_MISC1
register.

BUG=none
TEST=Built kernel and boot. EMC scaling works on nyan-rev1.

Change-Id: I474ca7ab04cd45c4d19779163b2469f53533a9bc
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186868
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: dts: nyan: update revision 0x19 EMC tables

The patch updates EMC tables to revision 0x19.

BUG=none
TEST=Built kernel and boot. EMC scaling works on nyan-rev1.

Change-Id: I2d3db8b9e75e7aa59852c78d72700fb85095abc3
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186869
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: clk: tegra: add clock aliases for use by DVFS

Add aliases for a few more clocks on Tegra124 so that they can be
used by Tegra-DVFS.

BUG=None
TEST=Build and boot on Nyan

Change-Id: I0680bc6bf190e5adc666c27602e5ee8ab628f73d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187110
CHROMIUM: ARM: tegra124: dvfs: update Core DVFS table

Update memory related entries as per characterization results and add
some more clocks into the Core DVFS table so we won't under voltage when
operating those clocks.

BUG=None
TEST=boot and read sysfs under /sys/kernel/debug/tegra_dvfs/dvfs.

Change-Id: I9ee73ca22105139a86dcb7dae8205857fba01bda
Signed-off-by: Bill Huang <bilhuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186952
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: backing_dev: Fix hung task on sync

bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can happen since mod_delayed_work can now steal work from a work_queue.
This fixes the problem by using queue_delayed_work instead. This is a
regression from the move to the bdi workqueue design.

The reason that this causes a problem is that laptop-mode will change the
delay, dirty_writeback_centisecs, to 60000 (10 minutes) by default. In the case
that bdi_wakeup_thread_delayed races with sync_inodes_sb, sync will be stopped
for 10 minutes and trigger a hung task. Even if dirty_writeback_centisecs is
not long enough to cause a hung task, we still don't want to delay sync for
that long.

For the same reason, this also changes bdi_writeback_workfn to immediately
queue the work again in the case that the work_list is not empty. The same
problem can happen if the sync work is run on the rescue worker.

BUG=chrome-os-partner:25356
TEST=suspend_stress_test for about 500 iterations on rambi

Change-Id: I5353401d6e960b8f4ac4e48fa185584ca2a66260
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186655
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
UPSTREAM: writeback: fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

BUG=chrome-os-partner:25356
TEST=suspend_stress_test for about 500 iterations

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 146d7009b45cdb45ec3be8ad73177dae58f4bc91)
Signed-off-by: Derek Basehore <dbasehore@chromium.org>

Change-Id: I3c051492f7f1e67e1cdb4e71c3645cd6cc95f154
Reviewed-on: https://chromium-review.googlesource.com/186666
Tested-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Sonny Rao <sonnyrao@chromium.org>
CHROMIUM: mfd: Add DT include file for AS3722 PMIC

The version of the AS3722 MFD driver which landed in the ChromeOS
tree did not include the DT binding include file, but the one that
landed upstream did.  Pull it in from commit d460a6f ["mfd: Add
support for ams AS3722 PMIC"] upstream.

Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Florian Lobmaier <florian.lobmaier@ams.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

BUG=chrome-os-partner:25096
TEST=Build and boot on Nyan.

Change-Id: I48934bea1ae191a3130334a4e5a1039ac9b1dcba
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187155
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
CHROMIUM: pinctrl: as3722: add suspend sequencing support

Add support for setting the suspend sequence and configuration for
GPIOs on the AS3722 PMIC.  Suspend configuration is supplied in
the "low-power-enable" device-tree property.

BUG=chrome-os-partner:25096
TEST=Build and boot on Nyan.

Change-Id: I19a2306ed8ab190c99a04af108826650f726274c
Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186965
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: ARM: dts: nyan: add AS3722 GPIO standby configuration

Configure AS3722 GPIO1 (REGEN3) to output low and be 5th (slot 4)
in the standby sequence

BUG=chrome-os-partner:25096
TEST=Build and boot on Nyan. GPIO1 is low during suspend.

Change-Id: Id49a93965bcc5aed2385bb0c218ea01c4ab7c525
Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186086
Reviewed-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: input: cros_ec_keyb: clear buffer only when not a wake device

According to the comment there, we should clear the EC's key scan buffer
only when it's *not* a wake device.

BUG=none
TEST=suspend/resume test with EC wake up & suspend_stress_test over 3000
interations

Change-Id: Ic657ea24b964e82e5fe6070904442d001fe32a82
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186944
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: DTS: tegra: T124: add therm-caps in the DFLL for all speedo

Add therm-caps properties in the DFLL for all speedo-id

BUG=None
TEST=Verified. Can read vmax in t124_dfll from sysfs.

Change-Id: Ib3451d8b9e2786fb5483678029c8788cae75faad
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/187191
Tested-by: Wei Ni <wni.nvidia@gmail.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
UPSTREAM: usb: host: make USB_ARCH_HAS_?HCI obsolete

The three options USB_ARCH_HAS_{EHCI,OHCI,XHCI} are all well beyond
their recommended shelf life. They have caused numerous build failures
over the years because they are never completely correct, and with
the move to splitting out the platform specific back-ends out of the
driver, there is no real need for them any more. Also, the use of making
USB_ARCH_HAS_HCD depend on it is questionable since one can always enable
dummy_hc these days.

This patch enables them unconditionally for all platforms and
architectures, which means it is now possible to build host controller
drivers for machines that are known not to come with this hardware,
but that is just how we treat most other drivers.

In order to minimise the impact on existing architecture code and
defconfig files, all the Kconfig are left present for now. All platforms
that currently do 'select USB_ARCH_HAS_*' should subsequently be changed
not to select that. All drivers depending on USB_ARCH_HAS_HCD should
be changed to depend on USB_SUPPORT instead.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry-picked commit from d9ea21a779278da06d0cbe989594bf542ed213d7)
(cherry-picked from:
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git)

Change-Id: I7fec33bee10437c4a703167887fe665890554a78
Reviewed-on: https://chromium-review.googlesource.com/187377
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: tegra: Remove USB_ARCH_HAS_EHCI selection

Per the commit "usb: host: make USB_ARCH_HAS_?HCI obsolete", remove the
selection of USB_ARCH_HAS_?HCI from mach-tegra.

BUG=none
TEST=Booted nyan, and made sure USB still works.

Change-Id: I3aa5a58cd5b5475eef4832fe6f4c16540affc400
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/187378
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: config: Renormalize against USB_ARCH_HAS_?HCI obsolescence

Re-ran chromeos/scripts/kernelconfig oldconfig, and removed unrelated
changes, so that the splitconfigs are renormalized (after the commit
"usb: host: make USB_ARCH_HAS_?HCI obsolete").

BUG=none
TEST=Booted nyan, and made sure USB still works.

Change-Id: Ie62c84052d4797e0b829616cfdaf98a5fb803ddc
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/187379
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Rhyland Klein <rklein@nvidia.com>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: thermal: as3722 thermal alarm driver

Added driver which detects over temperature based on
sensors present along with the regulators SD0, SD1 and SD6.
If there is over temperature due to overcurrent drawn,
the driver helps in detecting it and start passive throttling

BUG=None
TEST=After adding dt nodes, we can read the temperature and
trigger throttling by raising the temeprature using a heat gun.

Change-Id: I3d67b9663edc3f0c1a0f39f8dd40bebea563024d
Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/184801
CHROMIUM: ARM: dts: nyan: add thermal zone for as3722 thermal

Add device node for as3722 thermal and add it to thermal-zones.
Bind this thermal zone with tj-temperature-throttling cooling device.

BUG=None
TEST=Can read temperature, detect thermal alarm and trigger throttling.

Change-Id: I0a6f8b24d45b932d221e9b7bdcb1a7d11d2215e4
Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/184802
CHROMIUM: config: enable AS3722 thermal alarm driver

Enable the AS3722 thermal alarm driver on Tegra.

BUG=None
TEST=Can read temperature, detect thermal alarm and trigger throttling.

Change-Id: Ie6f68e546721c1701c768f5f9ff9c314b19ce1e0
Signed-off-by: Bibek Basu <bbasu@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184803
CHROMIUM: cpufreq: interactive: move work out of CPU hotplug path

CPUFREQ_GOV_{START,STOP} are used to notify the governor of CPU
topology changes and need not be used to set-up/tear-down global
governor state such as input device handles and sysfs entries.
Move these operations into the CPUFREQ_GOV_POLICY_{INIT,EXIT}
paths which will run when binding/unbinding the governor to a
specific policy.

Also, since cpufreq_interactive_boost() may now be called with
the governor stopped, have it check if the governor is enabled
before requesting that a CPU be boosted.

BUG=chrome-os-partner:26084
TEST=Build and boot on Nyan.  Lock the interactive governor to
2.1Ghz and hotplug CPUs; observe that hotplug latency is down
to around ~5ms.  Switching governors, suspend/resume, etc. still
work.

Change-Id: I18ec45200ed8d0ff69c0cc5c5633afb403897c7d
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187472
Reviewed-by: Dylan Reid <dgreid@chromium.org>
ALSA: hda - Fix unbalanced runtime PM notification at resume

When a codec is resumed, it keeps the power on while the resuming
phase via hda_keep_power_on(), then turns down via
snd_hda_power_down().  At that point, snd_hda_power_down() notifies
the power down to the controller, and this may confuse the refcount if
the codec was already powered up before the resume.

In the end result, the controller goes to runtime suspend even before
the codec is kicked off to the power save, and the communication
stalls happens.

The fix is to add the power-up notification together with
hda_keep_power_on(), and clears the flag appropriately.

Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 0fc28fc030a85aa3d6d14e9e9fca0c8237c9ffb5)
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>

BUG=chromium:345500
TEST=Manual test on Peppy with steps:
1. Boot device, set_short_powerd_timeouts to make it idle to suspend
in a short time.
2. Wait for a while then press keyboard to wake device up, check
audio functions well.

Change-Id: Ib50de3ddb624339861893c6c9b6e7033a140e21f
Reviewed-on: https://chromium-review.googlesource.com/187421
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Hsinyu Chao <hychao@chromium.org>
Commit-Queue: Hsinyu Chao <hychao@chromium.org>