camera: comment unused code

Change-Id: I98109372693372ab3c949de02020be059abb5d03
msm: smsm: Use interrupt mask for local SMSM notifications

Only trigger SMSM callback processing for the local processor if
callbacks have been registered.

Without this fix, excessive SMSM bit toggles may overflow the SMSM
snapshot queue.

CRs-Fixed: 378402
Signed-off-by: Eric Holmberg <eholmber@codeaurora.org>
Signed-off-by: Angshuman Sarkar <angshuman@codeaurora.org>
(cherry picked from commit 51676a19760897c1d3fe35dde50738827d25598c)

Change-Id: I35f9db5568ef53319dcd2c6e78904ca446f65645
Signed-off-by: Ram Kumar Chakravarthy Chebathini <rcheba@codeaurora.org>
i2c-algo-bit: Don't resched on clock stretching

Clock stretching is not supposed to last long, so asking to be
rescheduled while waiting for the clock line to be released by a slave
makes little sense. Odds are that the clock line will long have been
released when we run again, so we will have lost time and may even
get an SMBus timeout because of this.

So just busy-wait in that case. This also participates in the effort
to make i2c-algo-bit usable in contexts that can't sleep.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
qup_i2c: Reset QUP before registering for interrupts.

If bootloaders leave a pending interrupt on certain GSBI's,
the driver registers for an interrupt handler during boot up.
The interrupt handler immediately fires because the interrupt was
triggered in the bootloader. The ahb clock is also off at this time,
hence any register writes in the interrupt handler does not go through.
Thus we loop forever in the interrupt handler effectively hanging the
device.

CRs-Fixed: 345805
Change-Id: I5545785142a39f8b78132745e74dfc55a8a5c917
Signed-off-by: Harini Jayaraman <harinij@codeaurora.org>
qup_i2c: Set the clock rate before enabling the clock.

There is a warning during boot up since the driver
enables the QUP clock before setting its rate. Hence,
make sure clock rate is set for applicable targets to
fix warning.

Change-Id: I249d642f5f14c5ff627c00766f9d399f48f55610
Signed-off-by: Harini Jayaraman <harinij@codeaurora.org>
i2c-gpio: Use linux/gpio.h rather than asm/gpio.h

Direct inclusion of asm/gpio.h has been deprecated for a while now due
to the cross platform gpiolib.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
sched: Fix select_fallback_rq() vs cpu_active/cpu_online

Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was
supposed to finally sort the cpu_active mess, instead uncovered more.

Since CPU_STARTING is ran before setting the cpu online, there's a
(small) window where the cpu has active,!online.

If during this time there's a wakeup of a task that used to reside on
that cpu select_task_rq() will use select_fallback_rq() to compute an
alternative cpu to run on since we find !online.

select_fallback_rq() however will compute the new cpu against
cpu_active, this means that it can return the same cpu it started out
with, the !online one, since that cpu is in fact marked active.

This results in us trying to scheduling a task on an offline cpu and
triggering a WARN in the IPI code.

The solution proposed by Chuansheng Liu of setting cpu_active in
set_cpu_online() is buggy, firstly not all archs actually use
set_cpu_online(), secondly, not all archs call set_cpu_online() with
IRQs disabled, this means we would introduce either the same race or
the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on
wrong CPU") -- albeit much narrower.

[ By setting online first and active later we have a window of
  online,!active, fresh and bound kthreads have task_cpu() of 0 and
  since cpu0 isn't in tsk_cpus_allowed() we end up in
  select_fallback_rq() which excludes !active, resulting in a reset
  of ->cpus_allowed and the thread running all over the place. ]

The solution is to re-work select_fallback_rq() to require active
_and_ online. This makes the active,!online case work as expected,
OTOH archs running CPU_STARTING after setting online are now
vulnerable to the issue from fd8a7de17 -- these are alpha and
blackfin.

Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: linux-alpha@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-hubqk1i10o4dpvlm06gq7v6j@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Conflicts:

	kernel/sched/core.c

Change-Id: Ib22f61c28494bcccc40f9f7fa3812c72e5528203