Revert "Revert "Revert "Revert "arm/dt: hammerhead: Disable the Invensense IIO based Sensors""""

(enable qcom sensors)

This reverts commit 8e2530791e2a35278692bffc481d5110a2d50bcd.

Change-Id: I188cf678522df26aed7ea356227ee3c58cb1addb
Signed-off-by: Patrick Tjin <pattjin@google.com>
ASoC: pcm: Protect FE dai list during dai open/close

When dai open/close, the FE dai list must be protected.
If this list is accessed at the same time, list can
be broken. Then the kernel panic may be generated.
So, the mutex lock is changed to the dai open/close funtions.

Change-Id: Ic75a8d5b9d13eaa38d9edca46b0154cecad29a8e
Signed-off-by: sangwoo <sangwoo2.park@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Sensors: Invensense Motion Apps 5.1.6 Release Candidate 33

Changes:
- Improved the handling of the biases both for factory calibration and
  runtime calibration via the gyro and accel offset and dmp_bias sysfs
  entries
- Prevented a possible race condition in batch mode settings
- Improved the data flow handling for some sensors and sensor scenarios
- Keep track of the batch mode requests for sensors even if the system
  proceeds in continuous mode - necessary when batch mode is restored
- Changed pressure values to floating point for better resolution
- Pedometer time and steps representation is now 64 bits
- Fixes a number of sensor combination corner cases involving Pedometer
  Step Detector
- Fixed long term drift issue in batched Game Rotation Vector
- Fixed misconfiguration caused by Significant Motion getting detected
  while working with other sensors
- Fixed Linear Accelerometer sample count in batching
- Fixed handling of the rates with combination of sensors involving
  virtual sensors
- Output all the data in the FIFO when a Significant Motion is detected.
  Do the same when the system comes back up from suspended.
- Fixed sensors getting left wrongly configured and not outputting any
  data when other sensors are enabled or disabled
- Fixed duplicated timestamp issues with Gravity vector sensor
- Fixed problems with the sensor rates in continuous and batch mode
- Fixed a problem causing high timestamp variance for the Gyroscope sensor
  while running the Step Detector sensor
- Applied patch to self-test fail on heamerhead

Change-Id: I6c54e5aadd9a57fc38a8de8015fc009f1652a90c
Signed-off-by: chohee.park <chohee.park@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
Motion Apps 5.1.6 Release Candidate 54

Changes since MA 5.1.6 RC33

- Integrated flush feature within batching support with FLUSH_COMPLETE
  metadata indicator
- Handling accelerometer biases through the device's offset registers
  as for the gyroscope
- Added ability to write the accelerometer and gyroscope biases
  on the offset registers directly after self-test test execution
  for more seamless production floor handling
- Fixed batch mode timestamps across system suspend and resumes
- Estimate the timestamps using the devices's clock more reliably;
- Output the data in the FIFO when switching data mode (batching
  to continuous and vice versa, change of rate, addition/removal of a sensor)
- Accelerometer auto calibration does not overwrite the self-test accelerometer
  biases unless they are improving
- Added dynamic control of the HAL and SensorService logging
  using Android properties.

Change-Id: I94cf6eaedeb719f0bc2292c1dcfd20e24d8134f7
Signed-off-by: chohee.park <chohee.park@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
video: slimport: support DP compatibility and low bandwidth

This patch supports DP cable recognization and
proper max resolution for low bandwitdh sink. (2.7G/1.62G)
not affect with HDMI sink(5.4G)

Change-Id: I557ab0ce8722a12fd878989faf14e7e5feb143b0
Signed-off-by: jihyun.seong <jihyun.seong@lge.com>
random: make 'add_interrupt_randomness()' do something sane

commit 775f4b297b780601e61787b766f306ed3e1d23eb upstream.

We've been moving away from add_interrupt_randomness() for various
reasons: it's too expensive to do on every interrupt, and flooding the
CPU with interrupts could theoretically cause bogus floods of entropy
from a somewhat externally controllable source.

This solves both problems by limiting the actual randomness addition
to just once a second or after 64 interrupts, whicever comes first.
During that time, the interrupt cycle data is buffered up in a per-cpu
pool.  Also, we make sure the the nonblocking pool used by urandom is
initialized before we start feeding the normal input pool.  This
assures that /dev/urandom is returning unpredictable data as soon as
possible.

(Based on an original patch by Linus, but significantly modified by
tytso.)

Tested-by: Eric Wustrow <ewust@umich.edu>
Reported-by: Eric Wustrow <ewust@umich.edu>
Reported-by: Nadia Heninger <nadiah@cs.ucsd.edu>
Reported-by: Zakir Durumeric <zakir@umich.edu>
Reported-by: J. Alex Halderman <jhalderm@umich.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin.google.com>
random: use lockless techniques in the interrupt path

commit 902c098a3663de3fa18639efbb71b6080f0bcd3c upstream.

The real-time Linux folks don't like add_interrupt_randomness() taking
a spinlock since it is called in the low-level interrupt routine.
This also allows us to reduce the overhead in the fast path, for the
random driver, which is the interrupt collection path.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
random: create add_device_randomness() interface

commit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream.

Add a new interface, add_device_randomness() for adding data to the
random pool that is likely to differ between two devices (or possibly
even per boot).  This would be things like MAC addresses or serial
numbers, or the read-out of the RTC. This does *not* add any actual
entropy to the pool, but it initializes the pool to different values
for devices that might otherwise be identical and have very little
entropy available to them (particularly common in the embedded world).

[ Modified by tytso to mix in a timestamp, since there may be some
  variability caused by the time needed to detect/configure the hardware
  in question. ]

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
usb: feed USB device information to the /dev/random driver

commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream.

Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Greg KH <greg@kroah.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
	drivers/usb/core/hub.c

Signed-off-by: Patrick Tjin <pattjin@google.com>
net: feed /dev/random with the MAC address when registering a device

commit 7bf2357524408b97fec58344caf7397f8140c3fd upstream.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: David Miller <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
random: use the arch-specific rng in xfer_secondary_pool

commit e6d4947b12e8ad947add1032dd754803c6004824 upstream.

If the CPU supports a hardware random number generator, use it in
xfer_secondary_pool(), where it will significantly improve things and
where we can afford it.

Also, remove the use of the arch-specific rng in
add_timer_randomness(), since the call is significantly slower than
get_cycles(), and we're much better off using it in
xfer_secondary_pool() anyway.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
random: add new get_random_bytes_arch() function

commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.

Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present.  Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.

The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door.  (For example, an
increasing counter encrypted by an AES key known to the NSA.)

It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
  --- especially since Bull Mountain is documented to use AES as a
whitener.  Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel.  Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.

Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.

This way we get almost of the benefits of the HW RNG without any
potential liabilities.  The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.

For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
random: remove rand_initialize_irq()

commit c5857ccf293968348e5eb4ebedc68074de3dcda6 upstream.

With the new interrupt sampling system, we are no longer using the
timer_rand_state structure in the irq descriptor, so we can stop
initializing it now.

[ Merged in fixes from Sedat to find some last missing references to
  rand_initialize_irq() ]

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
msm: krait-regulator: switch mode on the same cpu

The driver currently runs LDO-BHS mode switches while possibly
running on a different CPU. The CPU for which the mode switch is
issued could be running its SPM sequence as a part of going in or
coming out of power collapse. The LDO-BHS switching executed from a
different CPU could race with the mode switches done in SPM sequence
leaving the CPU in a bad state.

Fix this by executing LDO-BHS mode switches on the target CPU. This
guarantees that the SPM sequence won't be running on that CPU while
changing modes.

CRs-Fixed: 523449
Change-Id: I863ce3bcd6dd9ba3155c4573071f01e7a020ef48
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
msm: krait-regulator: rename online to reg_en

The online variable is confusing, since it does not mean whether
the core is online or offline. It actually used to indicate whether
the regulator is enabled or disabled.
Change the variable name to indicate so.

Change-Id: I20c270162df57cf81c17e808d383880b5b2e4eef
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
msm: krait-regulator: fix race conditions in regulator enable/disable

The driver suffers from the following race conditions:
* when a core is being onlined and is in its PREPARE_UP stage regulator
enable for that core is called. This call may cause a switch between
ldo-bhs but since the core if not online yet and ldo-bhs calls are
strictly executed on the target cpu - this leads to smp function calls
to fail.
* before the core in onlined and after the PREPARE_UP stage there could
be another frequency change that causes a gang voltage change that in turn
causes this core to switch states. This too leads to failed smp function
calls since they are targeted towards offline core
* when a cpu is offlined but a DEAD notification is not sent a frequency
change on another core may cause a switch on this cpu. This also leads
to failed smp function calls on offline core.

Fix the above by forcing the core to BHS when it is in its transitory
phase and while it is offlined. In other words a core will switch to
bhs/ldo based on the voltage requests only between CPU_ONLINE and
CPU_DOWN_PREPARE notifications. A core can run on BHS if it
can run on LDO since LDO just acts as a voltage step down, the core
can run when fed higher voltage from BHS.

To do this add hooks to get cpu hotplug notifications in the driver and
appropriately force bhs or switch to ldo or bhs based on gang voltage.

CRs-Fixed: 529593
Change-Id: I7210f62072853ed6f807df2d78bc2144f67eaf31
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
msm: vidc: Add VP8 version set-up via Profile and Level

VP8 specification does not define level or profile concept but
specify a version. The OpenMax IL version 1.1.2 specify a single
profile and multiple levels for VP8 codec, the levels are indeed the
version numbers. The way of setting the codec version using level
field comes from the definitions at OpenMax IL. Since is a single
profile, level value is use to set-up the version but FW expects the
version value to be pass in the profile field, for that reason
incoming level is copy to FW profile.

Change-Id: I1ddc47b7a25efd1d31bed18e54c2b576427d1564
Signed-off-by: Jorge Solano Altamirano <jsolano@codeaurora.org>
msm: vidc: Remove redundant check

Removing a check that was previously done by
get_vb_from_device_addr() call. Also modify the
buffer data check print's to provide more concise
information.

Change-Id: Idf320a5ae89bf104e1ea66192fe0ea621f39185f
Signed-off-by: Jorge Solano Altamirano <jsolano@codeaurora.org>
msm: vidc: Initialize data_offset to avoid trash values

When data_offset is used by client this may get
trash values causing unexpected results.

Change-Id: Iaa7ca85f6dd81c4246580047f915cbb6327e7361
Signed-off-by: Jorge Solano Altamirano <jsolano@codeaurora.org>
usb: dwc3-msm: use only vbus to determine device mode

hs_phy_irq is used as wake_up source when in host mode. However leaving
this irq line enabled, has dual flows of detection for device mode  i.e
hs_phy_irq and vbus. Though  hs_hy_irq would not be  wakeup enabled, we
would still get an interrupt when the system has been woken up by other
interrupts like the vbus line. So in  summary now we will have vbus for
device  mode, id for  host mode detection and  hs_phy_irq for wakeup in
host mode suspend.

Change-Id: Ib848d2cddeba2afdf571390490ac3da6be6e774b
Signed-off-by: mohamed.khadri <mohamed.khadri@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>