FROMLIST: clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend

Save and restore this register since the LP1 restore assembly routines
fiddle with it. Otherwise the CPU would keep running on PLLX after
resume from suspend even when DFLL was the original clocksource.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
(am from http://patchwork.ozlabs.org/patch/381817/)
Signed-off-by: Vince Hsu <vinceh@nvidia.com>

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: I9f8cb34ea8645d5a8ec47ddd88f675086eb07253
Reviewed-on: https://chromium-review.googlesource.com/213099
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: Vince Hsu <vinceh@nvidia.com>
Commit-Queue: David Riley <davidriley@chromium.org>
FROMLIST: clk: tegra: Add the DFLL as a possible parent of the cclk_g clock

The DFLL clocksource was missing from the list of possible parents for
the fast CPU cluster. Add it to the list.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
(am from http://patchwork.ozlabs.org/patch/381814/)
Signed-off-by: Vince Hsu <vinceh@nvidia.com>

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: Id19aa12102baf266e8f4a64f0722e4c5765b1ea9
Reviewed-on: https://chromium-review.googlesource.com/213100
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: Vince Hsu <vinceh@nvidia.com>
Commit-Queue: David Riley <davidriley@chromium.org>
FROMLIST: cpufreq: tegra124: Add device tree bindings

The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
(am from http://patchwork.ozlabs.org/patch/381812/)
Signed-off-by: Vince Hsu <vinceh@nvidia.com>

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: I07bddbd38a929a289c11a444b86917daa7ef06e9
Reviewed-on: https://chromium-review.googlesource.com/213101
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: Vince Hsu <vinceh@nvidia.com>
Commit-Queue: David Riley <davidriley@chromium.org>
FROMLIST: cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

The Tegra124 will use a different driver for frequency scaling, so
rename the old driver (which handles only Tegra20) appropriately.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
(am from http://patchwork.ozlabs.org/patch/381811/)
[vinceh: fixed conflicts manually]
Signed-off-by: Vince Hsu <vinceh@nvidia.com>

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: If9806c6c3d0b8afc8b130fb64d3cedfe7c91eecc
Reviewed-on: https://chromium-review.googlesource.com/213102
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: Vince Hsu <vinceh@nvidia.com>
Commit-Queue: David Riley <davidriley@chromium.org>
FROMLIST: cpufreq: Add cpufreq driver for Tegra124

Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
the CPU clocksource, switch immediately to the DFLL. It allows the use
of higher clock rates, and will automatically scale the CPU voltage as
well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
for all the cpufreq operations.

This driver also relies on the DFLL driver to fill the OPP table for the
CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
use.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
(am from http://patchwork.ozlabs.org/patch/381807/)
Signed-off-by: Vince Hsu <vinceh@nvidia.com>

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: Ie28b867a09e09dd6c0b3ce9adb1c5d97f83b6c7d
Reviewed-on: https://chromium-review.googlesource.com/213103
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: Vince Hsu <vinceh@nvidia.com>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: arm64: dts: add tegra132 ccplex device

BUG=None
TEST=Can see the cclk_g in clk/clk_summary

Change-Id: I99e21f5a27ac2bcd3be4155008594f53beb0c325
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/212908
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: clk: tegra: export DVCO reset functions for Tegra132

In Tegra132, the DFLL DVCO reset has been moved out from
CAR to CCPLEX. Export the reset functions for Tegra132
DFLL driver.

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: I0ca43b40eb63ea180260d52c6d6e387ae3f910a8
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213105
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: clk: tegra: enable two flags for cclk_g

The cclk_g needs the following flags to be clocked by dfll:

* CLK_SET_RATE_NO_REPARENT - the parent of cclk_g is strictly
  controlled by platform cpufreq driver.
* CLK_SET_RATE_PARENT - the clock rate is from cclk_g's parent
  instead of itself.

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: I60c4c42f65cdae9eea59252d3b5c13f4ba19ef4f
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213106
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: clk: tegra: add support for Tegra132 DFLL

This patch reuses the Tegra124 DFLL driver and addes the
Tegra132 cvb and tuning data.

The opp framework is also enabled by default for generating opp
table to be used by other drivers like cpufreq.

The minimum voltage is set as 890mV for now because the thermal
function is not ready yet.

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: Id900cc17a3330238d663bee6726b43addc34aa59
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213107
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: arm64: dts: tegra: add DFLL into device tree for Tegra132

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: I4f626fca71491ca6cd1a44ea1c5f2f7c6f75702e
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213108
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: arm64: dts: add DFLL support for Tegra132 Norrin

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: Ic2987655b6da37259296dfe576f362fa7b3b78bf
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213109
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: arm64: dts: add clocks for Tegra132 cpufreq

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: Ib2b6ef874c974a59d7c69f3f1bc9fd0337fc9dcb
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213110
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
CHROMIUM: cpufreq: tegra: use Tegra124 cpufreq driver for Tegra132

Add Tegra132's compatible and let the two platforms share the
same cpufreq driver.

BUG=chrome-os-partner:31429
TEST=Compile and boot tested with ARCH=arm64

Change-Id: If5d19357221bec23e0d6e9067478e5bbff8f6e0a
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/213111
Reviewed-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
UPSTREAM: libahci: Allow drivers to override start_engine

Allwinner A10 and A20 ARM SoCs have an AHCI sata controller which needs a
special register to be poked before starting the DMA engine.

This register gets reset on an ahci_stop_engine call, so there is no other
place then ahci_start_engine where this poking can be done.

This commit allows drivers to override ahci_start_engine behavior for use by
the Allwinner AHCI driver (and potentially other drivers in the future).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 039ece38da45f5e6a94be3aa7611cf3634bc2461)
BUG=chrome-os-partner:31587
TEST=build/boot on AP-148 and storm P0

Change-Id: Ibfdc3fd057bab5e8695b8b12b22f81fa5a99c98d
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215020
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ahci-platform: Add support for devices with more then 1 clock

The allwinner-sun4i AHCI controller needs 2 clocks to be enabled and the
imx AHCI controller needs 3 clocks to be enabled.

tj: Minor comment formatting updates.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 156c5887948cd191417f18026aab9ce26e5a95da)
BUG=chrome-os-partner:31587
TEST=build/boot on AP-148 and storm P0

Change-Id: Ib624872e7b59eef1abeab193af696478ee3d9975
Signed-off-by: Grant Grundler <grundler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215021
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: mwifiex: handle AMPDU supported check for AP interface

This patch fixes a bug where we were checking for AP's AMPDU param
setting even when transmitting traffic to associated station.
Patch adds provision to pass additional parameter ra_list pointer
to function which checks if AMPDU is allowed. If current BSS type is
AP, we check station's AMPDU params else we check AP's AMPDU params.

BUG=chrome-os-partner:24153
TEST=With all patches in this series applied on Clapper, test TDLS functionality.
1. run wpa_cli on peer device
2. Discover TDLS peer by command
tdls_discover <Clapper WLAN mac address>
3. Setup TDLS link with clapper
tdls_setup <Clapper WLAN mac address>
4. Teardown existing TDLS link
tdls_teardown <Clapper WLAN mac address>
From Clapper, DBus command can be used to setup TDLS link as follows:
dbus-send --system --dest=fi.w1.wpa_supplicant1 --print-reply \
/fi/w1/wpa_supplicant1/Interfaces/0 \
fi.w1.wpa_supplicant1.Interface.TDLSSetup string:<peer-mac-address>

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/202844
(cherry picked from commit 0ef45839174ccde885e8ad97458cb8c6ff46c9c4)
Signed-off-by: Paul Stewart <pstew@chromium.org>

Change-Id: If284b816a7c0589d75a03c07d6d904ab48a86747
Reviewed-on: https://chromium-review.googlesource.com/215743
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: make tos_to_tid_inv part of mwifiex_private structure

tos_to_tid_inv values are needed even during TDLS operations.
Currently tos_to_tid_inv is part of wmm.c and declared static.
Make it part of private structure so that it can be used in
other files as well.

BUG=chrome-os-partner:24153
TEST=With all patches in this series applied on Clapper, test TDLS functionality.
1. run wpa_cli on peer device
2. Discover TDLS peer by command
tdls_discover <Clapper WLAN mac address>
3. Setup TDLS link with clapper
tdls_setup <Clapper WLAN mac address>
4. Teardown existing TDLS link
tdls_teardown <Clapper WLAN mac address>
From Clapper, DBus command can be used to setup TDLS link as follows:
dbus-send --system --dest=fi.w1.wpa_supplicant1 --print-reply \
/fi/w1/wpa_supplicant1/Interfaces/0 \
fi.w1.wpa_supplicant1.Interface.TDLSSetup string:<peer-mac-address>

Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Originally-reviewed-on: https://chromium-review.googlesource.com/202845
(cherry picked from commit e1903ddb6a004f0402eaf236c4fb256dea7fa156)
Signed-off-by: Paul Stewart <pstew@chromium.org>

Change-Id: Ibe7f7844f35c33aa55217d563a8490961cc52c19
Reviewed-on: https://chromium-review.googlesource.com/215744
Reviewed-by: mukesh agrawal <quiche@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: clk: rockchip: fix function type for CLK_OF_DECLARE

Adding function type checking to CLK_OF_DECLARE found a type mismatch with
rk2928_gate_clk_init. The function only takes a single struct device_node
parameter.

BUG=chromium:403201
TEST=Build and boot, no warning.

Change-Id: Ib8e436fa52b47b88c375813267abc790a2914cb1
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from commit 5c46f43f08004d6d25772c9b6e24fa048c8c3efc)
Reviewed-on: https://chromium-review.googlesource.com/216143
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: config: arm64: remove hard-code command line

In order utilize the typical chromeos boot flow we can't
be hard-coding the command line. Therefore, remove the
hard-coded command line.

BUG=chrome-os-partner:31509
BRANCH=None
TEST=Built and booted off of usb and emmc after chrome-os-install.

Change-Id: I305a1ca081846e1e1815baa7e9a1dc30d1fb1d16
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213570
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
UPSTREAM: clk: rockchip: make rockchip_clk_register_branch static

It is only used locally in clk/rockchip/clk.c and thus can be static.

BUG=chrome-os-partner:30167
TEST=Build and boot

Change-Id: I028b49c6fd342363b08a641392baaf6485dabda0
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
(cherry picked from git.linaro.org/people/mike.turquette/linux.git clk-next
 commit 1a4b1819950a278e44dd2e28c5cdb7d8b804dd73)
Reviewed-on: https://chromium-review.googlesource.com/216150
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>