omap: Adding opp functions to gpu platform data.

This is required for providing opp framework access to SGX kernel module.

Change-Id: Ie968a6c51ac636b70909257be4c51430c4cc3d48
Signed-off-by: Rogelio Garcia <rgarcia@ti.com>
omap: Adds access_process_vm to gpu platform data

omap: Adds access_process_vm to gpu platform data

This core API function is needed by modular PVR driver.

Change-Id: I409bf934aa3c2566f468715e490c911b97b247bc
Signed-off-by: Rogelio Garcia <rgarcia@ti.com>
Signed-off-by: Atanas (Tony) Zlatinski <zlatinski@gmail.com>
OMAP2+: PM: Voltage: allow software margin per OPP

Allow per OPP software margin to be defined in OPP table
for the voltage definitions.

Note: OMAP4460 has currently recommended 10mV margin to be added.

This also introduces /sys/kernel/debug/voltage/*/curr_margin_volt
to show the current voltage margin used.

Change-Id: Id49185ffb224d03ac05a41780ad35b1c7a20f4a0
Signed-off-by: Nishanth Menon <nm@ti.com>

Conflicts:

	arch/arm/mach-omap2/omap_opp_data.h
	arch/arm/mach-omap2/opp4xxx_data.c
	arch/arm/mach-omap2/voltage.h
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.

Change-Id: I34bedb461f77bfe4af78ef5ddd3fb3a230ca3551
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>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
OMAP4: DVFS: Fix scaling dependent frequencies.

When scaling dependent frequencies down it is observed that the order
in which frequencies are changed is incorrect.  For example, when core
domain changes OPP down from OPP119 to OPP50 the order is:
a) scale L3 freq down to OPP50
b) scale SGX freq down to OPP50
which is wrong.

Frequencies are scaled in order devices are registered in omap dvfs
framework in device list. Devices are inserted to the list in order,
such as dependences are satisfied if scaling frequencies up.

When scaling frequencies down traverse list backwards.

This patch is related to defect OMAPS00268574 "OMAP4xxx: DVFS down
scale issue with L3 clock.

Change-Id: I752bcb264cac12514f358986a906f29ee81ba75e
Signed-off-by: Oleksandr Kozaruk <oleksandr.kozaruk@ti.com>

Patch Set 3
I2C: OMAP: Fix the crash in i2c remove

Should fix the crash at arch/arm/mach-omap2/omap_l3_noc.c