CHROMIUM: mwifiex: fix Tx timeout issue

https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Cc: <stable@vger.kernel.org>
Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com>
Reported-by: Linus Gasser <list@markas-al-nour.org>
Reported-by: Michael Hirsch <hirsch@teufel.de>
Tested-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=None
TEST=autotest

Change-Id: I9e62a02ec9b92f0ca0caddd9c10b343fe219ebd4
Reviewed-on: https://chromium-review.googlesource.com/204884
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
CHROMIUM: mwifiex: initialize Tx/Rx info of a packet correctly

There are few places at the begining of Tx/Rx paths where
tx_info/rx_info is not correctly initialized. This patch
takes care of it.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>

BUG=None
TEST=autotest

Change-Id: I30eca60de65cb915f3cf4f40aabe8e29f219bc39
Reviewed-on: https://chromium-review.googlesource.com/204885
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
Tested-by: Bing Zhao <bzhao@marvell.com>
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>
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>
CHROMIUM: drm/edid: Update short blanking modes

This updates the list of short blanking modes:
- remove CMN panels whose min clock is 72.6MHz. We could reduce the
  blanking on those panels, but since the minimum clock is 72.6MHz,
  this is more than what fits in a single eDP lane, so no power
  savings are possible there.
- add short blanking for a bunch of other panels where this is
  possible, this usually saves ~80mW.

BUG=chrome-os-partner:29738
TEST=on swanky/glimmer/squawks check that the panel works without artifacts

Change-Id: I38d55e449f0d5e1582122a0b330d40e413d6ef51
Reviewed-on: https://chromium-review.googlesource.com/205274
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@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>
CHROMIUM: drm/tegra: basic powergating implementation

Since the introduction of proper refcounting of power on tegra, the
DRM driver stopped working because it didn't use power gating. This
change adds very basic powergating support to it so that we can get it
back to a working state.

BUG=chromium:378998
TEST=I can remove one of my local hacks, and it still builds and runs on nyan_freon

Change-Id: I51fe3fe2e489adc9ada3e3782f9f93f1764bdcd7
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205953
Reviewed-by: Sean Paul <seanpaul@chromium.org>
CHROMIUM: config: Renormalize splitconfig
Ran ./chromeos/scripts/kernelconfig oldconfig and hit return for
inquiries.

Reverted removal of wireless IWL7000 parameters because they appear to
be incorrectly deleted.

Signed-off-by: Anup Chenthamarakshan <anupc@chromium.org>

BUG=chrome-os-partner:25859
TEST=kernel compile & boots.

Change-Id: Id32106b485ca24d928a22603ddff1a2fb6e27a63
Reviewed-on: https://chromium-review.googlesource.com/205703
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Tested-by: Anup Chenthamarakshan <anupc@chromium.org>
Commit-Queue: Anup Chenthamarakshan <anupc@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>
CHROMIUM: config: Change the kernel memory split to 3G/1G

BUG=chrome-os-partner:29134
TEST=System boots/HDMI works/LP0 works/WebGL aquarium works/
     Kernel va starts from 0xc0000000

Change-Id: I707290f3cb1e90af114bc9a080cece6ace6bd588
Signed-off-by: Mark Zhang <markz@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205933
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: 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>
CHROMIUM: drm: Shrink vblank off delay to 1s

Apparently this got lost in the 3.8 -> 3.10 transition. Since it saves
quite a bit of power, let's put it back

BUG=none
TEST=builds and runs on glimmer

Change-Id: I088c73107685ebaf191e4e15bb47bf9dad7b49b6
Reviewed-on: https://chromium-review.googlesource.com/206530
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: drm/udl: add vblank support

This is needed to be able to send page flip completion events.
Also while I'm at it, fix the error paths on init.

BUG=chromium:363461
TEST=compiles and runs on glimmer

Change-Id: I30292108c1b5f547284260ff67fed9b2384e1172
Reviewed-on: https://chromium-review.googlesource.com/206531
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: drm/udl: Implement page_flip ioctl

This is a very crude page_flip implementation for UDL. It should let
us implement user space on top.

BUG=chromium:363461
TEST=modetest -Mudl -s 9:800x480 -v

Change-Id: I4b7a5e1695154e25ef9b0670bcb991742017e991
Reviewed-on: https://chromium-review.googlesource.com/206532
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
CHROMIUM: video: tegra: Fixup bandwidth calculation

The current bandwidth calculation can overflow when the compiler
optimizer re-arranges some of the operands.  We add brackets to
expressions that makes sense and limits the overflow condition.

BUG=chrome-os-partner:29116
TEST=3840x2160 now works without flickering.

Change-Id: I874e7145e84109ef9f912aa4a4fd1d64daa9520c
Signed-off-by: David Ung <davidu@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206549
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Dylan Reid <dgreid@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>
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>
CHROMIUM: HACK: mmc: tegra: don't clock gate across suspend/resume

Sometimes the Marvell SD8897 generates a SDIO interrupt after it should
have been suspended, which will cause a hard hang if the SDIO IRQ thread
runs while the clock is gated.  Don't clock gate the SDHCI host to avoid
this hang.

Note that this only works around the hard hang issue.  If the SDIO IRQ
thread runs after the host has been suspended, there are likely to be
other issues, e.g. MMC transfers issued by the IRQ thread failing or
timing out.

BUG=chrome-os-partner:28553
TEST=10000 LP0 iterations pass

Change-Id: Icddc460332054503a26b495e7536468e4943847c
Signed-off-by: Peer Chen <pchen@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206800
CHROMIUM: ARM: tegra: add sor0 into core dvfs table

The core dvfs should take the sor0 clock into account.

BUG=None
TEST=cat tegra_dvfs/dvfs* and verifed.

Change-Id: Id7411984fb749384b0bacc4a4dc6a9641bbc3a78
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206792
Reviewed-by: Bill Huang <bilhuang@nvidia.com>
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>