CHROMIUM: clk: tegra: fix pll round rate output

The original pll round rate callback returns a wrong frequency,
which is actually the VCO frequency. The correct output frequency
shall be calculated by the parent clock rate and m/n/p dividers.

BUG=chrome-os-partner:28329
TEST=emerged the kernel, booted successfully.
on big DVT, pll_d was 278MHz without this change,
and now it's 139MHz.

Change-Id: I7de5129a015b7aa60bfe1a64b31b3d7e3dc775fe
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/196748
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: nyan: Add delay to panel prepoweroff callback

The delay between backlight disable and PWM off needs to
be applied in the panel prepoweroff callback.

BUG=chrome-os-partner:28118
TEST=emerged kernel, display worked fine on blaze.
power-off sequence meets the delay requirement of
the panel datasheet.

Change-Id: Icc251e9da6f873101f05a05ffb56deed7fa653e5
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/196753
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: tegra: dc: return max freq when for bandwidth requests 

If the max frequency can't meet the bandwidth requested in
tegra_dc_kbps_to_emc, stop searching for higher frequencies when the
max frequency is found.  Before this would cause an infinite loop.

BUG=chrome-os-partner:27651
TEST=build and test on Blaze

Change-Id: Ibe7f8c9cec3a1f2806e8de0021e4b0b48e320727
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197003
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
UPSTREAM: dm crypt: fix cpu hotplug crash by removing per-cpu structure

The DM crypt target used per-cpu structures to hold pointers to a
ablkcipher_request structure.  The code assumed that the work item keeps
executing on a single CPU, so it didn't use synchronization when
accessing this structure.

If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online,
the work item could be moved to another CPU.  This causes dm-crypt
crashes, like the following, because the code starts using an incorrect
ablkcipher_request:

 smpboot: CPU 7 is now offline
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt]
 ...
 Call Trace:
  [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt]
  [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0
  [<ffffffff81052a28>] ? process_one_work+0x168/0x470
  [<ffffffff8105366b>] ? worker_thread+0x10b/0x390
  [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290
  [<ffffffff81058d9f>] ? kthread+0xaf/0xc0
  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120
  [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0
  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120

Fix this bug by removing the per-cpu definition.  The structure
ablkcipher_request is accessed via a pointer from convert_context.
Consequently, if the work item is rescheduled to a different CPU, the
thread still uses the same ablkcipher_request.

This change may undermine performance improvements intended by commit
c0297721 ("dm crypt: scale to multiple cpus") on select hardware.  In
practice no performance difference was observed on recent hardware.  But
regardless, correctness is more important than performance.

BUG=chrome-os-partner:28317
TEST=still boot and can mount encrypted stateful.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
(cherry picked from commit 3e7d3e49af8f81e691eb982bb9dd20744b98cc77)

Change-Id: I5d784c175ba8dbcebf77849bf3f65e7704739a8d
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197035
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: clk: tegra: update SS settings for pll_dp

Update spread spectrum settings for pll_dp.

BUG=chrome-os-partner:28020
TEST=emerged nyan_big/nyan_blaze kernel, booted successfully,
used nvio to read PLLDP_SS_CFG_0, PLLDP_SS_CTRL1_0 and
PLLDP_SS_CTRL2_0, all are programmed to the right values.

Change-Id: I9bbd26f3a38a44391f18ea7ceb2a1ef08162d0f8
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/196184
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: dts: blaze: Add panel timings

Add delays between:
1. PWM signal on and backlight enable
2. backlight disable and PWM signal off
(this is same as CL:194527)

BUG=chrome-os-partner:28118
TEST=panel worked fine on blaze

Change-Id: I06604e2d50ce5f4447384db291ce2b9ba4cdc7cc
Signed-off-by: Ken Chang <kenc@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195475
CHROMIUM: usb: phy: tegra: enable wake events based on host/port setting

If the PHY device has wakeup enabled, enable all wake events on all
ports, including remote wake and wake-on-hotplug.  If a particular port
has wakeup enabled, enable remote wake for that port.  Otherwise, disable
all wake events for that port.

BUG=chrome-os-partner:27703
TEST=Hotplug still wakes host from runtime suspend.  On LP0 suspend
wake-on-hotplug does not occur unless the host has wakeup enabled.
Events from wakeup-enabled devices (e.g. mice) still wake the system
from LP0.

Change-Id: I1e18e5b87dea3b2542d4cac33ac6739d75cfd9ff
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195576
Reviewed-by: Julius Werner <jwerner@chromium.org>
CHROMIUM: usb: phy: tegra: stop parsing wakeup policy from DT

The PHY driver now enables the correct set of wake events for each
port.

BUG=chrome-os-partner:27703
TEST=Hotplug still wakes host from runtime suspend.  On LP0 suspend
wake-on-hotplug does not occur unless the host has wakeup enabled.
Events from wakeup-enabled devices (e.g. mice) still wake the system
from LP0.

Change-Id: Ic3965b9f061968e330be73890f34f02253054c3c
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196595
Reviewed-by: Julius Werner <jwerner@chromium.org>
CHROMIUM: ARM: dts: nyan: remove USB wakeup settings

These are no longer needed.

BUG=chrome-os-partner:27703
TEST=Hotplug still wakes host from runtime suspend.  On LP0 suspend
wake-on-hotplug does not occur unless the host has wakeup enabled.
Events from wakeup-enabled devices (e.g. mice) still wake the system
from LP0.

Change-Id: I314f86ffeed26ba659133f920b4f135585494f07
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196596
Reviewed-by: Julius Werner <jwerner@chromium.org>
UPSTREAM: mmc: sdhci: add card_event callback to sdhci

Add a card_event callback to sdhci so that clients can provide their
own card_event to be called when card_detect is triggered.

Signed-off-by: Christian Daudt <csd@broadcom.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 722e1280c932dd42c474390482429ce12aff9031)

BUG=chrome-os-partner:28018
TEST=Swap between UHS and non-UHS SD cards on Nyan

Change-Id: Ic4fe19da783529ad0148f625fc9cb3ae39c4058f
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196900
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Christopher Freeman <cfreeman@nvidia.com>
CHROMIUM: mmc: tegra: clear tuning_done flag on card event

On card events, clear the tuning_done flag so that the correct tap
value and loopback settings are chosen in tegra_sdhci_reset_exit().
This also allows us to simplify the logic for determining which
tap value to use in tegra_sdhci_reset_exit().

BUG=chrome-os-partner:28018
TEST=Swap between UHS and non-UHS SD cards on Nyan

Change-Id: Ie61d3e91aea3c63c22f4d588675ef0c41ed3891f
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196901
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Christopher Freeman <cfreeman@nvidia.com>
CHROMIUM: clk: tegra124-dfll: fix additional memory allocation

We misused the of_find_property() and wasted extra ~4K bytes of memory.
This patch fixes the kernel memory hole.

BUG=chrome-os-partner:28426
TEST=System boots ok

Change-Id: Ia950a48f70c6548f51387a9d7e85420a400b9bad
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/197500
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
BACKPORT: drm/i915: don't disable the DP port if the link is lost

Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.

Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).

Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.

See also the next patch fixing the other half of this issue.

Solution suggested by Ville.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 5d6a1116c6475404e6505b708320f9579ae19acd)
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

BUG=chromium:368395
TEST=builds and runs on samus

Change-Id: I7dda2373bec432a30abbe06b70be2276f43f59fb
Reviewed-on: https://chromium-review.googlesource.com/197546
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: video: tegra: Don't set HDA presence for DVI devices.

If the HDMI output is in DVI mode, don't indicate that the HDMI audio
output is plugged.

BUG=chrome-os-partner:28404
TEST=plug DVI monitor - no HDA jack detect.
     plug HDMI - HDA jack detect.

Change-Id: I732bbae7b7c3b92b3db3393d97ee66793aea4ebf
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197580
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: drm: Add short blanking upport for the second BYT panel

We apparently use different types of panels, so let's allow short blanking
on both.

BUG=none
TEST=builds

Change-Id: I8dcc59c69ff34cbed035b5e234058780c44e5241
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197386
Reviewed-by: Dominik Behr <dbehr@chromium.org>
CHROMIUM: ARM: dts: tegra: Don't build nonsupported dtbs

We don't want to install all tegra device trees, only for the SoCs we are
actually building the kernel for. This cuts down on wasted space on the
resulting kernel image as well.

BUG=none
TEST=build, make sure output directory has the 124 dtbs.

Change-Id: I21f66edece7900ca4d2fe2ee2ff1451423e0278e
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-on: https://chromium-review.googlesource.com/197561
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Olof Johansson <olofj@chromium.org>
Tested-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests

The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.

BUG=chrome-os-partner:24893
TEST=none

Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d86db25e53fa69e3e97f3b55dd82a70689787c5d)
Signed-off-by: Mohammed Habibulla <moch@chromium.org>

Change-Id: Ib30ceaccf76c3c7c6b8102a5291eccb3b0df44a1
Reviewed-on: https://chromium-review.googlesource.com/197396
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
UPSTREAM: usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e

We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.

BUG=chrome-os-partner:24893
TEST=none

Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a)
Signed-off-by: Mohammed Habibulla <moch@chromium.org>

Change-Id: Idefbd43fa12f6a907a7698b121218e536ad91336
Reviewed-on: https://chromium-review.googlesource.com/197378
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
CHROMIUM: iwl7000: add uapsd_disable module parameter

Some APs (e.g. TP-LINK TL-WA801N) are disabling aggregation (downlink
to station) when U-APSD is enabled, resulting in low throughput.
Add a module parameter to allow disabling U-APSD support in the driver.

BUG=chrome-os-partner:27440
TEST=run throughput test again affected AP with and without uAPSD

Change-Id: I35591b33a0b44de9724ee9e091228443344b7785
Signed-off-by: Matt Chen <matt.chen@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/197032
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: do not sched scan while associated

Currently the FW doesn't support sched scan while associated,
so prevent it.

BUG=chrome-os-partner:28055
TEST=run various scenarios that previously resulted in sysassert
due to scheduled scan

Change-Id: I9d223316164fceb8cc1cae9e1e014599f7ab4c9b
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/197001
Reviewed-by: Paul Stewart <pstew@chromium.org>