CHROMIUM: clk: tegra124: initialize pll_d

There are chances in some chips that pll_d will fail to lock with
the hardware default m, n, and p value if the bootloader doesn't init
the pll first. Therefore we should init the pll instead of relying on
the bootloader.

BUG=chrome-os-partner:29836
TEST=Built kernel and boot. PLL_D can be enabled correctly.

Change-Id: I681b993dd0f3794048caed74143ebb9c0c6113bc
Signed-off-by: Danny Huang <dahuang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205752
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 6b915ebdd63ed478a3dd1d09cf1e1402161c91d3)
Reviewed-on: https://chromium-review.googlesource.com/206170
CHROMIUM: video: tegra: host: Reorder job completion

Job completion currently first turns off the hardware and then
checks which jobs were completed . This is vulnerable as we
cannot turn off the hardware until jobs have been completed.

This ordering was introduced to avoid race between channel release
and devfreq callbacks. At the time the ordering was selected, it
worked correctly as we were not relying on runtime pm and therefore
we did not start power down sequence at that point.

However, with runtime pm we may start powering down the device at
this point. As we no longer have the race for scaling (it does not
use .deinit()/.init() callbacks) it is safe to reorder this sequence
back to the original form.

BUG=chrome-os-partner:29716
TEST=LP0 stress with video playback passed 3300+ cycles and
     didn't hit the kernel hung task issue

Change-Id: Ib78831ee21ebeaca2c6da6f87e91ad8439c57212
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205340
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 1fe8e6523eef74aea1977c3676fc95062b6febb7)
Reviewed-on: https://chromium-review.googlesource.com/206313
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
CHROMIUM: mmc: sdhci: handle busy-end interrupt during command

Patch derived from https://lkml.org/lkml/2014/2/3/12

When controller supports busy-end interrupts, they may send it
before commands complete. If the host sends a new command too early,
it will result in CRC errors.

CMD  : CMD | ,,,, |   RESPONSE   |
DATA :     |    busy    |
                        .        .
                        .        . sdhci_cmd_irq (command interupt)
                        .
                        . sdhci_data_irq ("busy end" interrupt)

Before this patch, if the CPU is very fast, when sdhci_data_irq is
executed, it would complete the command and issue a new one while
CMD line is still driven by the device, resulting in a CRC error.

With this patch, we wait for both interrupts to be received before
completing the command.

TEST=On swanky with Tohisba eMMC, check the error messages:
 mmc0: Got command interrupt 0x00000001 even though no command operation was in progress.
and
 mmc0: unexpected status 0x800800 after switch
are gone.
BUG=chrome-os-partner:29817

Change-Id: I43b7467d59eb133d8c545115b48a5acbc450c2dd
Signed-off-by: Hankyung Yu <hankyung.yu@lge.com>
Signed-off-by: Chanho Min <chanho.min@lge.com>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206033
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Yung Leem <yungleem@chromium.org>
(cherry picked from commit e794c9f173a20d7788ca50cf543fce65fbda3f29)
Reviewed-on: https://chromium-review.googlesource.com/206551
Reviewed-by: Benson Leung <bleung@chromium.org>
CHROMIUM: ARM: dts: blaze: Update Samsung 4GB DFS table

Update the DFS table for Samsung K4B8G1646Q memory, ramcode = 10.

BUG=chrome-os-partner:30087
TEST=emerged kernel, booted successfully on blaze.

Change-Id: I41667c456f314dc489adfc8a0a7befea01f2b9f2
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205908
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit b7288422a289a9be0ca718bb458bf759d84c10a1)
Reviewed-on: https://chromium-review.googlesource.com/206841
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: tegra: add back the missing mutex_lock call

The commit 165869bff7a8470399e101ea39ddd89e3c62f4b2 (CHROMIUM:
video: tegra: host: gk20a: Support gPMU versions) removed the
mutex_lock call unexpectedly. This patch adds it back.

BUG=chrome-os-partner:30059
TEST=Enable CONFIG_DEBUG_MUTEXES. No warning like below observed
when booting.

------------[ cut here ]------------
WARNING: at kernel/mutex-debug.c:78 debug_mutex_unlock+0xc4/0x144()
gk20a 57000000.gk20a: gr_gk20a_init_ctx_vars_fw: NETLIST_REGIONID_CTXREG_PMPPC skipped
DEBUG_LOCKS_WARN_ON(lock->owner != current)
Modules linked in:
cfg80211 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables joydev
CPU: 2 PID: 1175 Comm: irq/189-gk20a Not tainted 3.10.18 #1
[<8020d014>] (unwind_backtrace+0x0/0x118) from [<8020a0c8>] (show_stack+0x20/0x24)
gk20a 57000000.gk20a: state restore latency exceeded, new value 68356167 ns
[<8020a0c8>] (show_stack+0x20/0x24) from [<80761990>] (dump_stack+0x20/0x28)
[<80761990>] (dump_stack+0x20/0x28) from [<8022619c>] (warn_slowpath_common+0x5c/0x7c)
[<8022619c>] (warn_slowpath_common+0x5c/0x7c) from [<80226208>] (warn_slowpath_fmt+0x4c/0x6c)
[<80226208>] (warn_slowpath_fmt+0x4c/0x6c) from [<80273ef4>] (debug_mutex_unlock+0xc4/0x144)
gk20a 57000000.gk20a: stop latency exceeded, new value 129000 ns
[<80273ef4>] (debug_mutex_unlock+0xc4/0x144) from [<80763b98>] (__mutex_unlock_slowpath+0x110/0x174)
[<80763b98>] (__mutex_unlock_slowpath+0x110/0x174) from [<80763c14>] (mutex_unlock+0x18/0x1c)
[<80763c14>] (mutex_unlock+0x18/0x1c) from [<80483ecc>] (pmu_seq_release+0xa0/0xa4)
[<80483ecc>] (pmu_seq_release+0xa0/0xa4) from [<8048a75c>] (gk20a_pmu_isr+0xd3c/0x1044)
[<8048a75c>] (gk20a_pmu_isr+0xd3c/0x1044) from [<8045b2d4>] (gk20a_intr_thread+0xf8/0x4f4)
[<8045b2d4>] (gk20a_intr_thread+0xf8/0x4f4) from [<8028aa24>] (irq_thread+0xf0/0x224)
[<8028aa24>] (irq_thread+0xf0/0x224) from [<80249a60>] (kthread+0xc8/0xd8)
[<80249a60>] (kthread+0xc8/0xd8) from [<80206098>] (ret_from_fork+0x14/0x20)
---[ end trace c0cc948dfcc22091 ]---

Change-Id: Idedeb8ad30cb5b06da47e5152c4c54289bba8cc7
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205906
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 0bd7a613958c93af2ee7afd68af45efe7988d4b8)
Reviewed-on: https://chromium-review.googlesource.com/207150
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: dts: blaze: update skin temp calibration data

Updated the skin temperature calibrated coefficients and toffset
based on the position "KB cover-1".

The new coefficients at ambient 30C are:

Array 0 Thermal_Device_ID_NCT_EXT
-16 -10 -7 -2
2 3 5 5
5 5 3 4
6 4 3 0
0 3 6 10

Array 1 Thermal_Device_ID_NCT_INT
-44 -16 -8 -3
-2 -8 -5 0
5 -1 -5 -9
-4 0 5 5
10 13 31 81

Skin offset: 3726

BUG=chrome-os-partner:29744
TEST=emerged blaze kenrel, cat values under
/sys/devices/soc0/therm-est.11/, got correct values.
Signed-off-by: Ken Chang <kenc@nvidia.com>

Change-Id: Ie9439169cf8fa47dd9b159238dc866be6fc34fba
Reviewed-on: https://chromium-review.googlesource.com/205346
Tested-by: Ken Chang <kenc@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit fc20cd22711f9ac41f41d640653f3472bf8ba114)
Reviewed-on: https://chromium-review.googlesource.com/207152
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: tegra: Correct dc windows number

On Tegra124, the second dc(display controller) "dcb"(or tegradc.1)
only supports A/B/C 3 windows.

So correct the windows number of different dc, also correct the
"valid_windows" of dcb. This removes a kernel warning when HDMI
is connected, which is caused by kernel tries to update the 4th
window on dcb.

BUG=chrome-os-partner:29675
TEST=System boots and the kernel warning disappears when HDMI is
connected

Change-Id: I009d4df40fd4c5fc7ae5483f202bda83279c8118
Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/203950
Tested-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 28ad0a14a5285f2eaf46bb5e49c7c831777b7802)
Reviewed-on: https://chromium-review.googlesource.com/207153
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: tegra: dc: retry out-of-sync handler

Change the implementation of sink out-of-sync handler from the
delay worker to a blocking function. This is because the dp
driver shall block the dc enable callback until it confirms
the sink deivce is already in synchronization wtih main stream.

Sometimes re-do link training does not recover the sink device
from out-of-sync state. In this case, the dp driver will retry
and the max retry count is 3.
In addition, we will increase the delay to read SINK STATUS in
case the sink device is skipping more-than-expected frames before
it starts to receive main stream.

BUG=chrome-os-partner:30039
TEST=panels works fine and can be recoved if out-of-sync is oberved
during boot-up and hdmi hotplug test.

Change-Id: Ifb803dc555fdccfc5fd004189770119635a24848
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206673
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 12d7da2ff77831523a99b0385bce3d5c20f112a5)
Reviewed-on: https://chromium-review.googlesource.com/207158
CHROMIUM: video: tegra: host: add channel_suspend in module_suspend

Call nvhost_channel_suspend to wait channel job completed, so that
the power.usage_count can be balanced before running into suspend.

BUG=chrome-os-partner:30246
TEST=run lp0 overnight test, didn't hit this issue.

Change-Id: I5516f56974f040e88b04b3305966d782efee0374
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206647
Tested-by: Wei Ni <wni.nvidia@gmail.com>
Reviewed-by: Mark Zhang <markz@nvidia.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 5bbfaa9785088d34b8714a2a259c430b663201da)
Reviewed-on: https://chromium-review.googlesource.com/207137
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: dts: blaze: Limit SD card to SDR50 mode

BUG=chrome-os-partner:30264
TEST=UHS-I SDHC SD card works fine on blaze and big.

Change-Id: I169155c15a552bbb976230ec1d3c5bef3e4b7284
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206789
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit f9b4e3cb0d31d6fd4407167b76ed8d74163449eb)
Reviewed-on: https://chromium-review.googlesource.com/206965
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: video: tegra: dc: increase the hpd drop timeout time

The hdmi state machine will enter the RESET state when it
can't see a hpd reassertion during the hpd drop timeout time.
The X won't know this and still think it has the monitor work
fine. So chrome://settings/display can show the hdmi monitor
information, but users see nothing on the monitor. This patch
extends the drop timeout time and ensure that the state
machine could see hpd reassertion.

BUG=chrome-os-partner:28417
TEST=Can have hdmi output correctly after several hotplugs.

Change-Id: Ia0395b8d997d58f203b8f0aa691e8c3183a65ce1
Signed-off-by: David Ung <davidu@nvidia.com>
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206420
Reviewed-by: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 515950572cea648126d922c3a3d629cad4689f4f)
Reviewed-on: https://chromium-review.googlesource.com/207214
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ASoC: Intel: Fix no audio if suspend is aborted early

After user close the lid and open quickly the suspend is aborted.
if the abortion occurs before sst_byt_pcm_dev_suspend_late is
called there will be no audio after resume.LPE is actually never
went to S3 so close/open should act as audio pause and play. no need
restore context and reload fw etc .In sst_byt_pcm_trigger it should
go to SNDRV_PCM_TRIGGER_PAUSE_RELEASE instead of SNDRV_PCM_TRIGGER_RESUME.

Now added a flag to remember if sst_byt_pcm_dev_suspend_late is called
or not so that will call the correct resume function correctly.

Signed-off-by: yang fang <yang.a.fang@intel.com>

BUG=chrome-os-partner:28651
TEST=play any audio and close/open lid quickly.make sure audio is
resuming

Change-Id: I0fee904619dabb3bb480c1caff0038171ce7d9d7
Reviewed-on: https://chromium-review.googlesource.com/206911
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Joe Konno <joe.konno@intel.com>
Commit-Queue: Yang Fang <yang.a.fang@intel.com>
(cherry picked from commit 6118e999a62740fce3402dbaf93925538034009d)
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207216
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
CHROMIUM: smart battery: Indicate not present on i2c error.

When the sbs battery is removed while the system is operational and
externally powered, the sysfs "present" file is returning garbage.
On systems without gpio_detect, indicate the battery is not present
when I2C operations fail.

BUG=chrome-os-partner:29753
TEST=cat /sys/class/power_supply/sbs-5-000b/present

Change-Id: I58aba2b167ad044611371c95bd0dffb04201a8f1
Signed-off-by: Bryan Freed <bfreed@chromium.org>
Previous-Reviewed-on: https://chromium-review.googlesource.com/204624
(cherry picked from commit cfcd79bc452fd67ad8927af92cd62f3fe6055879)
Reviewed-on: https://chromium-review.googlesource.com/207195
Reviewed-by: Bryan Freed <bfreed@google.com>
Commit-Queue: Bryan Freed <bfreed@google.com>
Tested-by: Bryan Freed <bfreed@google.com>