CHROMIUM: [media] V4L: Add camera pan/tilt speed controls

The V4L2_CID_PAN_SPEED and V4L2_CID_TILT_SPEED controls allow to move the
camera by setting its rotation speed around its axis.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chromium:375008
TEST=plug a Logitech ConferenceCam C3000e USB camera
and control pan/tilt from userspace using the VIDIOC_S_CTRL ioctl.
Verify that it can pan and tilt at the same time in both directions.

Change-Id: I923521f1a1251e815c21f446606dfe6ceff5f24e
Reviewed-on: https://chromium-review.googlesource.com/207058
Reviewed-by: Zach Kuznia <zork@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Zach Kuznia <zork@chromium.org>
Tested-by: Zach Kuznia <zork@chromium.org>
CHROMIUM: V4L: uvcvideo: Add support for pan/tilt speed controls

Map V4L2_CID_TILT_SPEED and V4L2_CID_PAN_SPEED to the standard UVC
CT_PANTILT_RELATIVE_CONTROL terminal control request.

Tested by plugging a Logitech ConferenceCam C3000e USB camera
and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
Verified that it can pan and tilt at the same time in both directions.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chromium:375008
TEST=plug a Logitech ConferenceCam C3000e USB camera
and control pan/tilt from userspace using the VIDIOC_S_CTRL ioctl.
Verify that it can pan and tilt at the same time in both directions.

Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
Reviewed-on: https://chromium-review.googlesource.com/203440
Reviewed-by: Zach Kuznia <zork@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Zach Kuznia <zork@chromium.org>
Tested-by: Zach Kuznia <zork@chromium.org>
CHROMIUM: Remove architected timer from exynos 542x boards

We added architected timers for 542x systems in (979a4b5: ARM: dt:
exynos5: add architected timers).  It turns out that architected timers
aren't actually supported on 542x systems because Samsung didn't close
the timing.  Thanks, Samsung (=_=).

BUG=chrome-os-partner:13805
TEST=manual
Booted on peach_pi and checked that the architected timer message did
not appear.

Change-Id: I656840927f6467323654263d180f096740810ce9
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218959
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
CHROMIUM: HACK: arm: Use 32 bit variant of arch timer as sched_clock

Hack to get around the fact that the current sched_clock implementation
does not support timers with a resolution higher than 32 bits.

BUG=chrome-os-partner:13805
TEST=manual
Built and booted on snow

Change-Id: Ife361997325ca06f94b4eab837eb6cc3a1421035
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201142
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
BACKPORT: clocksource: exynos_mct: Don't reset the counter during boot and resume

Unfortunately on some exynos systems, resetting the mct counter also
resets the architected timer counter.  This can cause problems if the
architected timer driver has already been initialized because the kernel
will think that the counter has wrapped around, causing a big jump in
printk timestamps and delaying any scheduled clock events until the
counter reaches the value it had before it was reset.

The kernel code makes no assumptions about the initial value of the mct
counter so there is no reason from a software perspective to clear the
counter before starting it.  This also fixes the problems described in
the previous paragraph.

Cc: Olof Johansson <olof@lixom.net>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
(cherry picked from commit 1d80415db64b54141ef02ae58bd2f273d0ac3c38)
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>

Conflicts:
	drivers/clocksource/exynos_mct.c

- Conflict because we have code to print out the initial timer value and
  upstream does not.

BUG=chrome-os-partner:13805
TEST=manual
Booted on snow with both mct and architected timers and didn't see any
of the problems described in the commit message.

Change-Id: I953af9fb82ada7140fc30bd95a6fecf6c73f0f3d
Reviewed-on: https://chromium-review.googlesource.com/218960
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
ARM: exynos5250: Select ARM_ARCH_TIMER

Now that we have support for architected timers and they have been
enabled in the respective device trees, lets turn them on so they are
compiled into the kernel on all exynos platforms.

BUG=chrome-os-partner:13805
TEST=Built and booted the kernel on snow and spring

Checked for the string "Architected local timer running at
24.00MHz (phys)." in the dmesg output for each board.

Ran a simple program to call gettimeofday() 100000000 times and saw a
50%-64% improvement in runtime on all boards.

Change-Id: Ib7202fae4e47cae68d642d6c77880e7a0276a50a
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201146
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
BACKPORT: clocksource: exynos_mct: Register the timer for stable udelay

This patch registers the exynos mct clocksource as the current timer
as it has constant clock rate. This will generate correct udelay for
the exynos platform and avoid using unnecessary calibrated
jiffies. This change has been tested on exynos5420 based board and
udelay is very close to expected.

Without this patch udelay() on exynos5400 / exynos5800 is wildly
inaccurate due to big.LITTLE not adjusting loops_per_jiffy correctly.
Also without this patch udelay() on exynos5250 can be innacruate
during transitions between frequencies < 800 MHz (you'll go 200 MHz ->
800 MHz -> 300 MHz and will run at 800 MHz for a time with the wrong
loops_per_jiffy).

[dianders: reworked and created version 3]

Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
(cherry picked from commit 8bf13a4346996b5a53d5f0c64b0914693c818fc2)
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>

- _exynos_frc_read has a different name and signature in our tree so I
  updated the patch to use that one.

BUG=chromium:416094
TEST=kernel_Delay

Change-Id: I6ee7064601ac82fb84bb3d5ba00710010da0b6e8
Reviewed-on: https://chromium-review.googlesource.com/218961
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: clocksource: exynos_mct: Use readl_relaxed/writel_relaxed

Using the __raw functions is discouraged.  Update the file to
consistently use the proper functions.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
(cherry picked from commit fdb06f66d53e3c9ba7eeab3c0629c450aee76937)
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>

Conflicts:
	drivers/clocksource/exynos_mct.c

- Conflict because exynos4_read_sched_clock was added in a different
  patch in our tree vs. upstream.  Also, we cache the high 32 bits of
  the timer value while upstream doesn't.

BUG=chromium:416094
TEST=manual
Booted on peach_pi, did not notice any timing issues.

Change-Id: If55f233b618e74f3e7a0bf54b54109df77895b1a
Reviewed-on: https://chromium-review.googlesource.com/218962
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
BACKPORT: clocksource: exynos_mct: Only use 32-bits where possible

The MCT has a nice 64-bit counter.  That means that we _can_ register
as a 64-bit clocksource and sched_clock.  ...but that doesn't mean we
should.

The 64-bit counter is read by reading two 32-bit registers.  That
means reading needs to be something like:
- Read upper half
- Read lower half
- Read upper half and confirm that it hasn't changed.

That wouldn't be terrible, but:
- THe MCT isn't very fast to access (hundreds of nanoseconds).
- The clocksource is queried _all the time_.

In total system profiles of real workloads on ChromeOS, we've seen
exynos_frc_read() taking 2% or more of CPU time even after optimizing
the 3 reads above to 2 (see below).

The MCT is clocked at ~24MHz on all known systems.  That means that
the 32-bit half of the counter rolls over every ~178 seconds.  This
inspired an optimization in ChromeOS to cache the upper half between
calls, moving 3 reads to 2.  ...but we can do better!  Having a 32-bit
timer that flips every 178 seconds is more than sufficient for Linux.
Let's just use the lower half of the MCT.

Times on 5420 to do 1000000 gettimeofday() calls from userspace:
* Original code:                      1323852 us
* ChromeOS cache upper half:          1173084 us
* ChromeOS + ldmia to optimize:       1045674 us
* Use lower 32-bit only (this code):  1014429 us

As you can see, the time used doesn't increase linearly with the
number of reads and we can make 64-bit work almost as fast as 32-bit
with a bit of assembly code.  But since there's no real gain for
64-bit, let's go with the simplest and fastest implementation.

Note: with this change roughly half the time for gettimeofday() is
spent in exynos_frc_read().  The rest is timer / system call overhead.

Also note: this patch disables the use of the MCT on ARM64 systems
until we've sorted out how to make "cycles_t" always 32-bit.  Really
ARM64 systems should be using arch timers anyway.

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

(cherry picked from commit 3252a646aa2cf706b2a26433a8bd9cb2e5dce410)
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>

Conflicts:
	drivers/clocksource/Kconfig
	drivers/clocksource/exynos_mct.c

- The history for this file is completely garbled because we added some
  things and then pulled back changes from upstream but then upstream
  added the same things we did but with just enough differences to cause
  conflicts and just generally make things messy.  I've tried to
  preserve the spirit of the changes and things seem to work just fine
  but I think it would be good if these changes are closely reviewed.
- BUILD_BUG_ON doesn't appear to exist in 3.8 so I just took it out.  It
  was just a warning about not using the mct on ARM64, which we don't do
  anyway.
- The sched_clock infrastructure in this version doesn't support timers
  with resolutions of more than 32 bits so I just took out the
  exynos4_read_sched_clock function and replaced its usage with
  exynos4_read_count_32.

BUG=chromium:416094
TEST=manual
Booted on peach_pi since daisy is no longer using this timer.

Change-Id: Ie86cc89b9c6617a4033c7751cd96680dcaed9917
Reviewed-on: https://chromium-review.googlesource.com/218963
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
CHROMIUM: input: Add "inhibited" property for input devices

Under certain circumstances, we want to disable some input devices from
userspace. In particular, when we detect that the lid of a laptop is
closed, we want to be able to disable touchpad and touchscreen to avoid
bogus input.

To facilitate this, we introduce the "inhibited" sysfs property for
input devices. Using this property, userspace can tell a driver that the
events it can provide are not currently of interest and should be
ignored. We provide hooks so that the driver can take additional
actions, such as powering down the device.

We deliberately keep this limited to input devices for now to keep the
implementation as straightforward as possible.

BUG=chromium:391046
TEST=Tested on peppy.
1. evtest /dev/input/input7 &
2. verify that touchpad works
3. echo 1 > /sys/bus/i2c/drivers/cyapa/8-0067/input/input7/inhibited
4. touchpad stops working
5. echo 0 > /sys/bus/i2c/drivers/cyapa/8-0067/input/input7/inhibited
6. touchpad works again

Conflicts:
	drivers/input/input.c

Change-Id: I43a87cb5b52a3a83b375d7fbcf20f792554adb6a
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207989
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit a1a19e4af2491f9ebc4aad3cd52e498a7db80457)
Reviewed-on: https://chromium-review.googlesource.com/219400
CHROMIUM: input: Revise inhibit interface

We might want to be able to return errors to userspace at some point in
the future.

BUG=chromium:391046
TEST=compiles

Change-Id: I6fbad775760c98c1eb2c655ad072faa5ce75765e
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218280
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
(cherry picked from commit c519206bb1796a3ee2404160af4260d06b8edc56)
Reviewed-on: https://chromium-review.googlesource.com/219401
Reviewed-by: Benson Leung <bleung@chromium.org>
CHROMIUM: input: Migrate cyapa to inhibit

Remove the lid filtering code from the cyapa driver and use the new
inhibit infrastructure instead. We also clean up suspend/resume a bit.

BUG=chromium:391046
TEST=Tested on peppy.
 1. evtest /dev/input/event7 &
 2. check that touchpad works
 3. echo 1 > /sys/class/input/input7/inhibited
 4. check that touchpad doesn't work
 5. echo 0 > /sys/class/input/input7/inhibited
 6. check that touchpad works
 7. echo mem > /sys/power/state
 8. touch touchpad; should wake the system
 9. echo 1 > /sys/class/input/input7/inhibited
10. echo mem > /sys/power/state
11. touch touchpad; should not wake the system
12. wake up system (press key on keyboard)
13. check that touchpad doesn't work
14. echo 0 > /sys/class/input/input7/inhibited
15. check that touchpad works

Change-Id: Iae1f7863ed47f2ee05cfbae5b18280f071d11bf5
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216351
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Dudley Du <dudl@cypress.com>
(cherry picked from commit f764c6a4088eb1f2f6b6d4a04b4e3c544a6fc5bd)
Reviewed-on: https://chromium-review.googlesource.com/219402
Reviewed-by: Benson Leung <bleung@chromium.org>
UPSTREAM: mwifiex: fix probable memory corruption while processing TDLS frame

Size of RSN IE buffer in driver is 254 while maximum size of received buffer
to be copied to RSN IE buffer can be 255. Add boundary check to copy maximum
of 254 bytes into RSN IE buffer.

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>

Change-Id: Id7dc138f31a1a880c77434bdeaaef07fed7f09b0
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/216417
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218734
UPSTREAM: mwifiex: support for event done interrupt

This patch adds support for writing CPU event interrupt done back
to device.
Patch also increases interrupt buffer ring size from 4 to 8.

BUG=None
TEST=set device in power save and start ping traffic.
This generates lot of SLEEP/AWAKE events.Driver writes
config register upon event processing.

Change-Id: I3cd1b6fc837f3ebb12cc32f3222e68bace659396
Signed-off-by: Avinash Patil <patila@marvell.com>
Tested-by: Avinash Patil <patila@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/216418
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218735
UPSTREAM: mwifiex: fix left_len calculation issue

While updating 'left_len' in each iteration, we should subtract
last TLV length not the accumulated length of TLVs parsed till
now.
This bug in parsing logic is exposed by newer firmware which adds
two TLVs in GET_HW_SPEC command response. Earlier firmwares used to
add only one TLV.

Bug=none
Test=Load mwifiex driver and check if interface is enumarated.

Change-Id: I07e308a3b28d31515bf45814ee3a758f9cf63c15
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Tested-by: Avinash Patil <patila@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/216419
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218736
UPSTREAM: mwifiex: rename macro and variables related to API revision

We will remove 'fw' prefix from these variable and macro
names and make them generic.

Bug=none
Test=Load mwifiex driver and check if interface is enumarated.

Change-Id: Ifc66bf70ae67f5644efbf94bdf6486f13bfe98bb
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Tested-by: Avinash Patil <patila@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/216620
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218737
UPSTREAM: mwifiex: use firmware API revision from GET_HW_SPEC response

Newer firmware returns API revision in GET_HW_SPEC command
response. We will make use of it instead of parsing this
information from FW release number.

Bug=none
Test=Load mwifiex driver and check if interface is enumarated.

Change-Id: I0c85f7b7fbab0c4600d78b72d92fa24552422843
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/216621
Reviewed-by: Paul Stewart <pstew@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218738
Merge branch 'chromeos-3.8' of https://chromium.googlesource.com/chromiumos/third_party/kernel into chromeos-3.8