CHROMIUMOS: mwifiex: Add debugfs file for testing reset of card

This is helpful in testing that the reset works.

Note that you need to be a little careful because there seems to be a
race where trying to reset the card while it's partway through the
reset process can eventually crash the system (memory corruption?).
Waiting 10 seconds between resets seems to work fairly reliably.

BUG=chrome-os-partner:21479
TEST=Run this for a while:
  while true; do
    sleep 10;
    echo 'y' > /sys/kernel/debug/mwifiex/mlan0/reset;
  done

Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Originally-Reviewed-on: https://gerrit.chromium.org/gerrit/65265

Change-Id: I0914c78d025d4ace25b6679f6c6779b7934acfe1
Reviewed-on: https://chromium-review.googlesource.com/184209
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: remove global user_scan_cfg variable

As the variable is used only for preparation of internal scan
commands, we don't need to keep it allocated until the entire
scan completes. We will define it as a local variable and free
immediately after it's use.

New flag 'scan_aborting' is added to handle race between
mwifiex_close() and scan handler. Previously user_scan_cfg
pointer used to take care of this.

This patch fixes a memory leak in mwifiex_cfg80211_scan after
running "iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio".

Reported-by: Daniel Drake <dsd@laptop.org>
Tested-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
(cherry picked from commit 75ab753d7704f0bd34e09d5e4081bc73fdddd775)
Equivalent to wireless-3.4 <https://chromium-review.googlesource.com/#/c/58848/>

Conflicts: drivers/net/wireless/mwifiex/main.h

BUG=chrome-os-partner:25318
TEST="iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio";
"echo scan > /sys/kernel/debug/kmemleak; cat /sys/kernel/debug/kmemleak"

Change-Id: I3c13704f04f96e85e9605101f886e635581c9d9d
Reviewed-on: https://chromium-review.googlesource.com/184213
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
UPSTREAM: mwifiex: abort remaining scan commands when association started

A full-channel scan is split to multiple scan commands in driver
before they are sent to firmware. When each scan result is back
the SSID entries are parsed and informed to cfg80211 directly.

It's observed that sometimes userspace may initiate association
as soon as the target AP is found. During the 4-way handshake
firmware may go off-channel to scan the remaining channels.
This causes the 4-way handshake to fail.

Fix it by checking 'scan_block' flag and aborting the remaining
scan in this case. 'scan_block' flag is set after association
and before 4-way handshake. It gets cleared after 4-way handshake
is completed.

Tested-by: Jason Abele <jabele@chromium.org>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
(cherry picked from commit 4c1079e1583958b83d7355ccbba686ad08b67015)

Equivalent to wireless-3.4 <https://chromium-review.googlesource.com/#/c/58849/>

BUG=chrome-os-partner:18188
TEST=autotest against CrOS_chaos_WesternDigital_5 (Jason Abele)

Change-Id: Icfc71fc249450b430f61bd7b6c8694c813685877
Reviewed-on: https://chromium-review.googlesource.com/184214
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
arm: exynos: Remove 5420 dead code from platsmp.c

We are no more dependent on smp_boot_secondary() for booting multi cores
on 5420/5422, instead we use MCPM for the same. Code inside
smp_boot_secondary() are dead now. This patch removes such dead code.

BUG=chrome-os-partner:24996
TEST=build and booted on pi/pit,
     can see all 8 core boots up fine

Change-Id: I4f1357aca9a1951c2a0444b970fb3cccb47cd1eb
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/184315
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
ARM: dts: peach-pi: Decrease the minimum supported voltages for MIF and G3D

The ASV tables for MIF and G3D on Exynos5422 have voltages as low
as 0.8375V and 0.775V respectively. Decrease the minimum supported
voltages for the two regulators.

BUG=chrome-os-partner:25272
TEST=Boot Peach Pi and verify in the bootlog:
vdd_mif: 800 <--> 1300 mV at 1000 mV
vdd_g3d: 700 <--> 1400 mV at 1000 mV

Change-Id: I926e185fa8d3f82de17fbff93416db28a3331d5f
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183775
Reviewed-by: Doug Anderson <dianders@chromium.org>
clock: exynos542x: Add 543MHz to VPLL table and 2.1GHz to APLL table

G3D can support 543MHz while ARM can support upto 2.1GHz on Exynos5422.
Add the PMS values for these new frequencies in respective tables.

BUG=chrome-os-partner:25272
TEST=Build and boot on peach_pi

Change-Id: Ia54a532bb485aa36ef8fc6557fd1413740a2c29b
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183416
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
mfd: tps65090: Stop caching registers

Nearly all of the registers in tps65090 combine control bits and
status bits.  Turn off caching of registers so that we can read status
bits reliably.

NOTE: the IRQnMASK and CG_CTRLn registers are the exception and could
be cached.  If we find that we spend a lot of time reading those we
can turn on cache for just those registers.

BUG=chromium:338657
TEST=Future changes that check tps65090 status now work.

Change-Id: I1850d7bb209a73c2cbe216289c0fe61be2252350
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184606
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
regulator: tps65090: Make FETs more reliable

This is a port (and squash) whole bunch of CLs that were in 3.4:

* regulator: tps65090: Set overcurrent wait time
  http://crosreview.com/29659
* regulator: tps65090: Check power good after enable
  http://crosreview.com/29813
* regulator: tps65090: Poll timeout bit on enable
  http://crosreview.com/31072
* CHROMIUM: snow: Change tps65090 power status check to a warning
  http://crosreview.com/35576
* regulator: tps65090: Retry FET enable in case of failure
  http://crosreview.com/38679

BUG=chromium:338657
TEST=Devices that were having trouble with backlight now work.
TEST=Use TEST from I35d924a2f2b0027eb49de10e5ced076c15e18a21
TEST=Boot and suspend/resume are still fine on normal devices.

Change-Id: I3e9c346358d82e83c327e852bee9267fb2749512
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michael Spang <spang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184607
Reviewed-by: Olof Johansson <olofj@chromium.org>
ARM: dts: Set FET overcurrent timeouts for snow

These are ported over from kernel 3.4.  This is the equivalent of
<http://crosreview.com/29812>, though I changed the property names to
match what's been done with other properties upstream.

BUG=chromium:338657
TEST=Run 'pmu' on EC and see that overcurrent timeouts got set.
Without this CL you see this after boot:
       00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18
  PMU: 0e 00 3e 00 03 20 4b bf ff ff 20 12 1e 1e 1e 1f 13 13 02 13 1f 13 20 00 00
With this CL you see:
       00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18
  PMU: 0e 00 3e 00 03 20 4b bf ff ff 20 12 1e 1e 1e 1f 1f 1f 02 1f 1f 1f 20 00 00

Change-Id: I86b387dcb1b8539cfab9da32657263a97ed14965
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184608
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
CHROMIUM: iwl7000: update to Core3 version

Update the iwl7000 driver to the latest release cycle. This update
fixes numerous bugs in various places (e.g. powersave), adds support
for new hardware SKUs and adds the following new features:
 * xVT support (configurable) - this is the test and production
   framework for iwlwifi
 * smart FIFO support - this feature reduces host wakeups
 * latency statistics (a mac80211 feature)
 * enable HT/VHT STBC support
 * low-priority scan support
 * multicast filtering support
 * fix scheduled scan support for older wpa_supplicant
 * and probably more small things

(iwlwifi commit 0cca5058afda4cbd7a414d642f0a511955320c6c)

Change-Id: I5fa0cf72d80541e67b1eb640e77b489b221d94c7
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184256
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: hid: quickstep: Initial add of driver

The ChomeOS Touch team uses a usb device built in-house to measure the
drag latency on touchpads.  This device communicates with the OS over
USB using a custom driver.  This CL adds that driver so that by default
Chromebooks will have the driver ready.  Previously, the kernel had to
be rebuilt for every device we wanted to test every time, so it will
save a lot of time on our end to already have it in there.

The device (named Quickstep) consists of a laser that lays across the
touchpad and hits a phototransistor on the other side.  The device
reports over USB HIDRAW a 1 or a 0 immediates each time the laser is
broken/unbroken by a finger inbetween the sensor and the laser.  This
driver simply listens for these events and records the time at which
they occur.  These events are stored in memory and can be accessed via
sysfs entries for later analysis by the latency-measuring scripts.

BUG=chromium:328451
TEST=Rebuilt kernel and used with the device.  Was able to access its
sysfs entries to both collect data and clear the logs.

Change-Id: I649c8625275bbdd68a301b96461c7b57c8f7ac8f
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179963
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: iwl7000: sort and extend element ID list

The element ID list is currently almost sorted by amendment
or similar topic, but the order is difficult to maintain and
not very transparent. Sort the list by ID instead, and add
a lot of missing IDs.

Change-Id: Ic4f6c4d832105dcbff0d0fadfc99d901b8ccffd0
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184787
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in probe request correctly

In probe request frames, the VHT IEs should come before any
vendor IEs, but after interworking and similar, so add code
to order them correctly wrt. the IEs passed from userspace.

Change-Id: Ic40e60a74e20f36331cf60a168fb4610d5e4ffbf
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184788
Reviewed-by: Paul Stewart <pstew@chromium.org>
CHROMIUM: iwl7000: order IEs in association request correctly

In association request frames, there may be IEs passed from
userspace (such as interworking IEs) between HT and VHT, so
add code to insert those inbetween them.

Change-Id: I9dac0fae8e5c7ead0c290fcacb8937f35266a419
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/184789
Reviewed-by: Paul Stewart <pstew@chromium.org>
mmc: dw_mmc: change to use recommended reset procedure

This changes the fifo reset code to follow the reset procedure
outlined in the documentation that we have.  It seems to help with
hangs seen during eMMC tuning.

BUG=chrome-os-partner:22839
TEST=booted on pit, rebooted machine over 100 time and no hangs seen.
     /wo this patch machine use to hangs once in 10~15 reboot cycles.

Change-Id: I1ec0cfcebe3a7787923ef504fe2e7d1ba37340fd
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178420
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: arm: dts: peach-pit: enable HS200

This enables HS200 using the upstream capability.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

BUG=chrome-os-partner:22839
TEST=`cat /sys/kernel/debug/mmc0/ios` shows clock at 200Mhz

Change-Id: I0e674297244c3e988c48673bc762d9f8de9880e3
Reviewed-on: https://chromium-review.googlesource.com/173534
Reviewed-by: Grant Grundler <grundler@chromium.org>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: ARM: exynos: Add pmu dts nodes for Exynos 542x

This adds two pmu nodes to the exynos542x.dtsi because the two types
of cores unfortunately have different interrupt parents. This is just a
first step in getting performance counters to work properly on 5420
with IKS.  There still needs to be work done to support the mulitple
pmu nodes and then context switch the counters properly in the
switcher code.

BUG=chrome-os-partner:22742
TEST="for i in $(seq 0 3) ;
	  do echo 700000 > \
	  /sys/devices/system/cpu/cpu${i}/cpufreq/scaling_min_freq;
	  perf top works"

Change-Id: I720bf655a527e8e9e67608dd136c9cbd9aa1f6ef
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180635
Reviewed-by: Olof Johansson <olofj@chromium.org>
BACKPORT: fence: dma-buf cross-device synchronization (v17)

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

When emitting a fence, call:
  + trace_fence_emit()

To annotate that a fence is blocking on another fence, call:
  + trace_fence_annotate_wait_on(fence, on_fence)

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
    dma_buf *fence_buf = seqno_fence->sync_buf;
    get_dma_buf(fence_buf);

    ... tell the hw the memory location to wait ...
    custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
  } else {
    /* fall-back to sw sync * /
    fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
    that dma-fence didn't need to care about the sw->hw signaling path
    (it can be handled same as sw->sw case), and therefore the fence->ops
    can be simplified and more handled in the core.  So remove the signal,
    add_callback, cancel_callback, and wait ops, and replace with a simple
    enable_signaling() op which can be used to inform a fence supporting
    hw->hw signaling that one or more devices which do not support hw
    signaling are waiting (and therefore it should enable an irq or do
    whatever is necessary in order that the CPU is notified when the
    fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
    we decided that we need to be able to attach one fence to N dma-buf's,
    so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
    about checking if fence fired or not. This is broken by design.
    waitqueue_active during destruction is now fatal, since the signaller
    should be holding a reference in enable_signalling until it signalled
    the fence. Pass the original dma_fence_cb along, and call __remove_wait
    in the dma_fence_callback handler, so that no cleanup needs to be
    performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
    fence wasn't signaled yet, for example for hardware fences that may
    choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
    header and fixed include mess. dma-fence.h now includes dma-buf.h
    All members are now initialized, so kmalloc can be used for
    allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
    enable_signaling to bool. Rework dma_fence_wait. Added
    dma_fence_is_signaled and dma_fence_wait_timeout.
    s/dma// and change exports to non GPL. Added fence_is_signaled and
    fence_enable_sw_signaling calls, add ability to override default
    wait operation.
v10: remove event_queue, use a custom list, export try_to_wake_up from
    scheduler. Remove fence lock and use a global spinlock instead,
    this should hopefully remove all the locking headaches I was having
    on trying to implement this. enable_signaling is called with this
    lock held.
v11:
    Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
    However I kept the guarantee that after fence_signal returns, it is
    guaranteed that enable_signaling has either been called to completion,
    or will not be called any more.

    Add contexts and seqno to base fence implementation. This allows you
    to wait for less fences, by testing for seqno + signaled, and then only
    wait on the later fence.

    Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
    An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
    spam, and another runtime option can turn it off at runtime.
v12:
    Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
    and fence->seqno members.
v13:
    Fixup CONFIG_FENCE_TRACE kconfig description.
    Move fence_context_alloc to fence.
    Simplify fence_later.
    Kill priv member to fence_cb.
v14:
    Remove priv argument from fence_add_callback, oops!
v15:
    Remove priv from documentation.
    Explicitly include linux/atomic.h.
v16:
    Add trace events.
    Import changes required by android syncpoints.
v17:
    Use wake_up_state instead of try_to_wake_up. (Colin Cross)
    Fix up commit description for seqno_fence. (Rob Clark)

BUG=chromium:340541
TEST=builds and runs on link (doesn't change the behaviour of anything for now)

Change-Id: Ib3f25d4c4cfc4445c668155285687a8a77a528b2
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184965
Reviewed-by: Sean Paul <seanpaul@chromium.org>
ASoC: max98090: Claim max98091 support

The max98091 is the same as the 98090 but with an extra microphone.
The max98090 driver already has support for the max98091.  This just
allows us to use the proper compatible string in the device tree.

BUG=chrome-os-partner:24838
TEST=With all changes pit and pi work for:
- youtube (speakers and headphones)
- aplay (speakers and headphones)
- google voice search w/ builtin mic

Change-Id: I4da4b1eeaab4f5dfc588aa41b36123fc9d2f7819
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184091
ASoC: samsung: Add max98091 to daisy_max98095.c

The max98091 is the same as the 98090 but with an extra microphone.

This change considers 98091 as 98090 which is driver for both of 98090
and 98091 so that we use represented name max98091 in device tree.

BUG=chrome-os-partner:24838
TEST=With all changes pit and pi work for:
- youtube (speakers and headphones)
- aplay (speakers and headphones)
- google voice search w/ builtin mic

Change-Id: I36d0a399a10fbcdb503ade75162789a6693adecc
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183923