CHROMIUM: video: tegra: Fix sched error and recovery race

Fix race between channel recovery and sched error.

BUG=chrome-os-partner:29236
TEST=emerged kernel, pass Graphic stress 24 hours

Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Change-Id: I7194d5b602f403a7c28c671ff5ce2a0f339600f4
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206966
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit cf53de5a2a7760a1c82a29820874a7f7b6068645)
Reviewed-on: https://chromium-review.googlesource.com/207280
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/206998
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/207508
Commit-Queue: Ken Chang <kenc@nvidia.com>
CHERRY-PICK: CHROMIUM: ARM: dts: blaze: update T-SKIN trip temperature

Update T-skin trip temperature to 45 Celsius.

BUG=chrome-os-partner:29744
TEST=build, download and verified by thermal test
Signed-off-by: Neil Chen <neilc@nvidia.com>

Original-Change-Id: I6eddfd61385160f1b749824e8e31d3a8fbc5ad0f
Reviewed-on: https://chromium-review.googlesource.com/207309
Tested-by: Neil Chen <neilc@nvidia.com>
Reviewed-by: Chen Wisley <wisley.chen@quantatw.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 20f79b970cc2339c49295e606b4b4df8a9283d04)

Change-Id: I004beaacecca9f10115b3074dc7bba309b6e9510
Reviewed-on: https://chromium-review.googlesource.com/207509
Tested-by: Neil Chen <neilc@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@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/206997
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
UPSTREAM: Bluetooth: btmrvl: wait for HOST_SLEEP_ENABLE event in suspend

After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should
wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete
suspend procedure.
Without this patch the suspend handler would return success
earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event
comes in the controller driver could have already turned off the
bus clock. This causes kernel crash or system reboot eventually.

Cc: <stable@vger.kernel.org> # 3.13+
Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Jeff CF Chen <jeffc@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

BUG=chrome-os-partner:29565,chrome-os-partner:28553,chrome-os-partner:25091
TEST=WLAN connected to AP; BT running A2DP; suspend_stress_test.
Unit test passed overnight.
Based on ODM's test result, 10 out of 13 passed 600 iterations.
It used to fail on every unit.
Without this patch, the current in suspend mode was 7.1mA,
deep sleep 2.2mA. With this patch applied, the current in suspend
mode drops to 2.2mA, same as in deep sleep mode.

Change-Id: I0341c5a5bd938b419af68d3f1671f7c137531fd3
Reviewed-on: https://chromium-review.googlesource.com/206341
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
(cherry picked from commit ddab6fb066da0d3e7cb8f49ef71e4329679adbf8)
Reviewed-on: https://chromium-review.googlesource.com/207780
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: thermal: tegra: return gpu throttling result

If update state failed, it would not change the cur_state.
And return the actual result for set_cur_state and let
the user space decide what to do next.

BUG=chrome-os-partner:30260
TEST=Ran WebGl Aquarium to let the GPU temp hit 60C
then hack the trip temp of gpu-balanced to 40C then reboot
the unit.
Observed tegra_gpu_set_speed_cap() failed on some
throttling states then succeeded in the next target state
which is set by the governor policy or the next passive retry.

Change-Id: I99fd71bde7a5b745ff27ecc720e0bf45afd32463
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/207299
Reviewed-by: Ken Chang <kenc@nvidia.com>
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 af126a2b0680fbb5121a1425d035660e7aec0402)
Reviewed-on: https://chromium-review.googlesource.com/208051
Commit-Queue: Ken Chang <kenc@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
CHROMIUM: video: tegra: check driver initialization before access

The tegra throttling driver might access the gk20a clk driver
before clk is initialized due to overheating when booting.
So we have to check the driver's readiness first.

BUG=chrome-os-partner:30260
TEST=None

Change-Id: I0b9461ca4e395e6428b7b2a86e676bb8c923415f
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/207320
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Ken Chang <kenc@nvidia.com>
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 2b92289c837727ec7fb29dd29de4b3d3186eb7ee)
Reviewed-on: https://chromium-review.googlesource.com/208031
Commit-Queue: Ken Chang <kenc@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
CHROMIUM: thermal: update cdev updated field

Set cdev->updated to false, whatever the target state is same as
current state or not.
Because if a cooling device return an error in set_cur_state
callback, we should give the cooling device a chance in the next
passive check to configure itself to the target state.

BUG=chrome-os-partner:30260
TEST=hack the trip temp of gpu-balanced to 40C and the pid
governor to return the max throttle state, then observe below
on boot:
1. without this change, thermal_cdev_update failed then no retry.
2. while with this change, succeeded after couple retries.

Change-Id: I1999b5840b8a85837f4303fae2992bfecba40a82
Signed-off-by: Ken Chang <kenc@nvidia.com>
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/207501
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit b73a27e7a1e24a9af3c44ec6821a9815aae61dd4)
Reviewed-on: https://chromium-review.googlesource.com/208052
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
CHROMIUM: ARM: tegra: enable ram-repair

The RAMs in the CPU cluster need to support RAM repair. Since the power
rail to the CPU cluster would be shut down in the CPU idle cluster power
down state and cluster switching, the RAM repair information will be
lost. It needs to be reprogrammed again after power resume. There is a
HW approach to do that by disabling RAM_REPAIR_BYPASS_EN in the flow
controller.

BUG=chrome-os-partner:30430
TEST=boot on nyan and suspend_stress_test

Change-Id: Ieb44da94ca8e0060b3af020d92207a9da06f976b
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208614
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 8d31a21d806a6a232d74fcd079dd20303406dc5a)
Reviewed-on: https://chromium-review.googlesource.com/208872
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
Tested-by: Artiste Hsu <chhsu@nvidia.com>
CHROMIUM: clk: tegra124: enable fuse clock during CPU cluster suspend/resume

The RAMs in the CPU cluster need to support RAM repair. But the logic is
depended on the fuse clock. So enable it during CPU cluster
suspend/resume routine.

BUG=chrome-os-partner:30430
TEST=boot on nyan

Change-Id: I1eb4eb330f432f62dd8ec4ed5300a869f897e001
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208613
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 86c912d0305efded476abd23520ef0a4de53701a)
Reviewed-on: https://chromium-review.googlesource.com/208881
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
Tested-by: Artiste Hsu <chhsu@nvidia.com>
CHROMIUM: video: tegra: Correct the gk20a fifo interrupt mask

We disable the gk20a fifo schedule error interrupt when doing
gk20a_fifo_recovery. But we disabled fifo channel interrupt
accidentally when doing that. We need to correct that despite
currently gk20a driver doesn't care about fifo channel interrupt.

BUG=chrome-os-partner:30499
TEST=System boots OK

Change-Id: I68cfa8b201d4afeb45f0abc1aca835a1282bdb68
Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208293
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit b767f8574888185c42d92f52e3bf44747fdbaa27)
Reviewed-on: https://chromium-review.googlesource.com/208877
Tested-by: Artiste Hsu <chhsu@nvidia.com>
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
CHROMIUM: dark resume: fix memory leak

This fixes the sysfs files getting leaked for non-source dark resume devices

BUG=chrome-os-partner:28391
TEST=On squawks
Enable kernel configs:
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=4000
Boot system
Plug and unplug usb drive several times
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak
See that there's nothing from the usb stack leaking

Change-Id: Id005084b1d4daa79541a12e650af52781b0dcaac
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207202
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 6028177abe8014fef6128bb544cf6cfac302314d)
Reviewed-on: https://chromium-review.googlesource.com/209140
Tested-by: Neil Chen <neilc@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Neil Chen <neilc@nvidia.com>
UPSTREAM: drivercore: deferral race condition fix

When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need for external event to kick the deferred queue to probe
these drivers.

The issue has been observed on embedded systems with CONFIG_PREEMPT enabled,
audio support built as modules and using nfsroot for root filesystem.

The following log fragment shows such sequence when all audio modules
were loaded but the sound card is not present since the machine driver has
failed to probe due to missing dependency during it's probe.
The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm
machine driver:

...
[   12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER
[   12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER
[   12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card
[   12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component
[   12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE
[   12.950839] davinci_evm sound.3: ASoC: platform (null) not registered
[   12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517)
[   13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list
[   13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2
[   13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517)
[   13.346755] davinci_mcasp_driver_init: LEAVE
[   13.377446] platform sound.3: Driver davinci_evm requests probe deferral
[   13.592527] platform sound.3: really_probe: probe_count = 0

In the log the machine driver enters it's probe at 12.719969 (this point it
has been removed from the deferred lists). McASP driver already executing
it's probing (since 12.615118).
The machine driver tries to construct the sound card (12.950839) but did
not found one of the components so it fails. After this McASP driver
registers all the ASoC components (the machine driver still in it's probe
function after it failed to construct the card) and the deferred work is
prepared at 13.099026 (note that this time the machine driver is not in the
lists so it is not going to be handled when the work is executing).
Lastly the machine driver exit from it's probe and the core places it to
the deferred list but there will be no other driver going to load and the
deferred queue is not going to be kicked again - till we have external event
like connecting USB stick, etc.

The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.

This way we can avoid drivers stuck in the deferred queue.

Signed-off-by: Grant Likely <grant.likely@linaro.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Stable <stable@vger.kernel.org> # v3.4+
(cherry picked from commit 58b116bce13612e5aa6fcd49ecbd4cf8bb59e835)

BUG=chrome-os-partner:29272
TEST=ASoC drivers now reliably finish probing on Nyan

Change-Id: I4d2bd05b91b893d5ae5b3de93747251e4d7ded78
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202170
Reviewed-by: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit 54835c373b46a4c1254185e68c87d4c27d8ab963)
Reviewed-on: https://chromium-review.googlesource.com/209123
Tested-by: Neil Chen <neilc@nvidia.com>
Commit-Queue: Neil Chen <neilc@nvidia.com>
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/209252
Tested-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
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>
(cherry picked from commit 9a9389a45218220e21c6ef7bf881d0d26edb99f6)
Reviewed-on: https://chromium-review.googlesource.com/209990
Tested-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
CHROMIUM: video: tegra: host: fix disable_clk() sequence

nvhost_module_disable_clk() currently first disables the clocks
and then suspends the channels as follows :
clk_disable_unprepare()
nvhost_channel_suspend()

reverse this sequence as below and keep clock disabling after
the channel operations
nvhost_channel_suspend()
clk_disable_unprepare()

This eliminates a kernel hung task that cdma_stop waits for
the semaphore while this semaphore is triggered by syncpt
IRQ. And host1x clients can't report IRQ when it's clock is
disabled.

BUG=chrome-os-partner:29716
TEST=The kernel hung task crash is fixed

Change-Id: I338ffbb38bb381b39b3406e87ba30a895b2e61cf
Signed-off-by: Deepak Nibade <dnibade@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/204491
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Mark Zhang <markz@nvidia.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
(cherry picked from commit a0ccac1a70fbe4fd9bd047b9b19f8dda055df4fd)
Reviewed-on: https://chromium-review.googlesource.com/209759
Tested-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
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/209729
Tested-by: Artiste Hsu <chhsu@nvidia.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
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/210025
Commit-Queue: Artiste Hsu <chhsu@nvidia.com>
Tested-by: Artiste Hsu <chhsu@nvidia.com>
CHROMIUM: video: tegra: Not resume when PM runtime is disabled

During LP0, the runtime PM is disabled in "pm_genpd_prepare", and
this function calls "pm_runtime_resume" to make sure the device is
power on.

So we don't need to call "pm_runtime_get_sync" in "nvhost_module_busy"
when devices' PM runtime is disabled. Otherwise "pm_runtime_get_sync"
returns an error but the device's power usage_count has been increased.
This makes sometimes some devices fail to suspend.

BUG=chrome-os-partner:29709
TEST=System boots and LP0 stress(with HDMI) passed 30 cycles

Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/204515
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
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 f5f8f7e50426869f080827c835d6c306105f2f83)

Change-Id: I7d529d34770776a91064224414a67fa4a42757c1
Reviewed-on: https://chromium-review.googlesource.com/210392
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Tested-by: Mark Zhang <markz@nvidia.com>
Commit-Queue: Mark Zhang <markz@nvidia.com>