gcx: fixed color conversion table.

Change-Id: I9f0c8ed5f6a341ca8d6a2460a1b5225d78a505e4
Signed-off-by: Alexei Shlychkov <shlychkov@gmail.com>
gcx: fixed error handling.

Change-Id: I4e38c35b51fbff71f2f9070e67478ebb726c3c4a
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>
TILER: Add tiler_backpages method

tiler_backpages method can be used to get the number of pages
required for a tiler allocation.  This method is called before
the memory is partitioned, therefore, we cannot rely on tiler
being initialized.  Separated geometry initialization for this
purpose.

Change-Id: Ia68cbd81c31a357fdc51036753db222d21994996
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
gpu: ion: group heap allocations by id in the debugfs

Multiple ion heaps can have the same type.  These heaps will have
separate debugfs files, but any allocation for a heap with the same
type will be listed in them.

Change-Id: Iad2f660c539e151d62e76f8f99ecc9ad80b16dd5
Signed-off-by: Lajos Molnar <lajos@ti.com>
Singed-off-by: Dima Svetlov <svetlov@ti.com>
gpu: ion: omap: Set correct heap for TILER allocations

OMAP has two TILER heaps, but all allocations are logged under
the first TILER heap, as ion_alloc only takes a heap type mask.
Correct the heap after ion_alloc, so the buffer is maintained
under the correct heap.

Change-Id: I7b4eb690a6cde6f07632f5254c91374c6088cb8a
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@ti.com>
OMAPDSS: DSSCOMP: Export dsscomp_set_platform_data

This is used by android-display to set up default tiler1d slot
size.

Change-Id: Ic6fe49b9338d8ce41c2ac2b444d8ef018ee5fc7a
Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Dima Svetlov <svetlov@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>
ARM: OMAP4: Initialize the cooling level properly

Initialize the cooling level properly to 0 since at
init the device is at max frequency

Change-Id: I69c0ba6ca5a2f5490b0afeb4fec2e9dbd1a0a18b
Signed-off-by: Dan Murphy <dmurphy@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