OMAP4: PM: Add errata id for handling Errata i745

The errata handler is present in kernel 3.0. The patch adds the
Errata id for simplification of search in the kernel sources

Change-Id: I251c0bd09754e5af9ec40c01c50e24e25eba9227
Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
OMAP4: EMIF: unify access to EMIF_PWR_MGMT_CTRL.REG_LP_MODE

Use set_lp_mode for changing EMIF_PWR_MGMT_CTRL.REG_LP_MODE.

Change-Id: Ia6410f97c8937faee6fbfc335d5d1158de41583b
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
cache-2dmanager: initial work.

Change-Id: Id3b07b44fea92794ed4e0e02f9081d66ecd2b38e
Signed-off-by: Jack Yen <jyen@ti.com>
gcx: add cache ioctl.

Add GC_CACHE_IOCTL to allow usermode to call into cache manager.

Change-Id: I01e29c6878a69b0b3b6a82fb5af37bb2b5657912
Signed-off-by: Jack Yen <jyen@ti.com>
gcx: fixed color conversion table.

Change-Id: Ic366eaaa8f1df95c74571ad292ce79c04b0ce47a
Signed-off-by: Alexei Shlychkov <shlychkov@gmail.com>
gcx: add kernel gcbv_cache implementation

Change-Id: Ie6b40422bee3d295e3c84ee1d42a202b3b15385d
Signed-off-by: Jack Yen <jyen@ti.com>
gcx: add virtual gcx platform driver for versioning

Change-Id: Ib8eacf6812a8239540600cd06735419f2dbb926b
Signed-off-by: Craig Stout <craig.stout@ti.com>
gcx: fixed error handling.

Change-Id: I684d925f23eae3bede5b38b73181cc001404b563
Signed-off-by: Alexei Shlychkov <shlychkov@gmail.com>
OMAP4: IRQ: Fix OMAP44XX_IRQ_CPUIDLE_POKE0 definition

According to OMAP4470 TRM the MA_IRQ_60 is busy for
L3_STAT_ALARM_IRQ L3 NoC statistics collector alarm interrupt.

The MA_IRQ_106 is reserved in all OMAP4 chips, so it's selected
for using as OMAP44XX_IRQ_CPUIDLE_POKE0.

Change-Id: Iba7f727035c71db009defe684a66fb8c58ee3f93
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
omap2plus: cpufreq: Modify lpj recalculation logic

Somethimes "mdelay" function provide delay
that several times shorter than it should be.

This happens because recalculating lpj
performed after switching OPP. In this case,
for short period of time, when OPP on MPU
was switched but lpj was not recalculated,
"udelay" function can provide incorrect
delay - upto 5 times shorter
(if OPP was switched from lowest to highest).

This patch changes lpj recalculation logic to:
if OPP will be switched to higher - recalculate lpj before switching OPP,
if OPP will be switched to lower - recalculate lpj after switching OPP.

Change-Id: I3258e756c471fd0258a849d712ab00f4e1279ea9
Signed-off-by: Sergii Postulga <x0153364@ti.com>
sched: Cleanup cpu_active madness

Stepan found:

CPU0		CPUn

_cpu_up()
  __cpu_up()

		boostrap()
		  notify_cpu_starting()
		  set_cpu_online()
		  while (!cpu_active())
		    cpu_relax()

<PREEMPT-out>

smp_call_function(.wait=1)
  /* we find cpu_online() is true */
  arch_send_call_function_ipi_mask()

  /* wait-forever-more */

<PREEMPT-in>
		  local_irq_enable()

  cpu_notify(CPU_ONLINE)
    sched_cpu_active()
      set_cpu_active()

Now the purpose of cpu_active is mostly with bringing down a cpu, where
we mark it !active to avoid the load-balancer from moving tasks to it
while we tear down the cpu. This is required because we only update the
sched_domain tree after we brought the cpu-down. And this is needed so
that some tasks can still run while we bring it down, we just don't want
new tasks to appear.

On cpu-up however the sched_domain tree doesn't yet include the new cpu,
so its invisible to the load-balancer, regardless of the active state.
So instead of setting the active state after we boot the new cpu (and
consequently having to wait for it before enabling interrupts) set the
cpu active before we set it online and avoid the whole mess.

Change-Id: Ibad68784d481672eed23b0e8ad1d5fefc8755bd7
Reported-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1323965362.18942.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>
[taras@ti.com: backported from v3.4-rc1]
Signed-off-by: Taras Kondratiuk <taras@ti.com>
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>
OMAP2PLUS:fix for TF doesn't work when CPU1 on/off

TI thermal framework: rework initialization sequence

The initialization of max_thermal was placed in function
which is executed for each CPU1 start. The old value of
max_thermal is lost in this case and is set to max_freq.
As result, the omap_thermal_step_freq_down() can't
reduce the frequency if CPU1 is  switched on/off often.

Signed-off-by: Eugen Mandrenko <ievgen.mandrenko@ti.com>
Change-Id: Idcbc6a56407595b8f71743b91d994990a279593b
Add a generic OMAP Remote Procedure Call Driver

Change-Id: I7c54eb41f62c104c7a1d0f525e1fd85450441cd3
Signed-off-by: Erik Rainey <erik.rainey@ti.com>
Signed-off-by: Alberto Aguirre <a-aguirre@ti.com>
rpmsg: omx: copy_from_user() errors should return -EFAULT

Change-Id: Ib4a2d92dd3b8afa18e60019871cfea2e6b446a4d
Signed-off-by: David Schleef <ds@ti.com>
remoteproc: fix obsolete comment about memory_maps

memory_maps in remoteproc platform data has been replaced
with memory_pool, but the comment still remained. It has
been cleaned up.

Change-Id: Iae78c0b8e8d4caccce2fc0248b89a9d18f8d7cca
Signed-off-by: David Schleef <ds@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
rpmsg: omx: return ENXIO in rpmsg_omx_write

The error code, ENXIO is used in rpmsg_omx driver to indicate
a terminal error on the remote processor side. This status is
maintained during the recovery of the remote processor, while
the cdev gets reinitialized/recreated.

The rpmsg_omx's write file operation is currently not returning
this error. This has been added now to have it behave in the
same way as the read file operation.

Change-Id: I61d6e6c07aa39208d913da622ed32d809c51d409
Signed-off-by: Vidhoon Viswanathan <vidhoon@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc: add a notify event for firmware preload

Added a new rproc event, RPROC_PRELOAD, to send a notification
about commencement of loading of a image into remoteproc's
memory. This event will currently be used for bumping up the
remoteproc frequency to optimize the overall boot time of the
remote processor.

Change-Id: I7e36e54fe938b3242b9e87fd33d6e190a1233083
Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
omap: rpmsg: bump to max freq while booting remote processor

Reduce the remote processor booting time by bumping to the max
frequency. This is achieved by putting in constraints before
the loading of the remote processor. The latter is known through
the RPROC_PRELOAD notification.

Once the remote processor has reached a certain point, it would
send a message, RP_MSG_BOOTINIT_DONE via mailbox to notify the
host that the remote processor has completed the basic boot and
initization. The constraints are released upon receipt of this
message. They are also released in case of an error during
loading.

NOTE: The current implementation used tput api for ipu since
freq scale api is not supported directly yet.

Change-Id: I1fe936087f00872756c7b532ee58d923e695ff28
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Chandra Sekhar.Anagani <chandu@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAPDSS: CEC: Physical address discovery form edid

HDMI sink device will set the physical address for
CEC devices

Change-Id: I6419834816978dfc8bcb8ef9a7b6c36276e5792c
Signed-off-by: Muralidhar Dixit <murali.dixit@ti.com>