OMAP4 U-Boot migration DPLL settings

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
OMAP4: U-Boot migration: Do pad config for ABE

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
HACK: ARM: omap4: retrigger localtimers after re-enabling gic

commit 09391f5c332bb1c521141a34f3f8687cf93a7125
(OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control
register change) disables the gic distributor while the secondary
cpu is being booted.  If a localtimer interrupt on the primary cpu
occurs when the distributor is turned off, the interrupt is lost,
and the localtimer never fires again.

Make the primary cpu wait for the secondary cpu to reenable the
gic distributor (with interrupts off for safety), and then
check if the pending bit is set in the localtimer but not the
gic.  If so, ack it in the localtimer, and reset the timer with
the minimum timeout to trigger a new timer interrupt.

Signed-off-by: Colin Cross <ccross@android.com>
[s-jan@ti.com: adapted to k3.4 + validated functionality]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
omap4: enable discrimination between 4430 and 4460 in clock data

Does not bring any functional change to either 4430 or 4460, but enables
support for 4430 dedicated entries.

Signed-off-by: Sebastien Jan <s-jan@ti.com>
omap4460: fix smp_twd clock definition

Add a 4460 dedicated smp_twd entry using the virtual mpu dpll.

Using the bad clock data for smp_twd on 4460 has the effect of providing
a bad mpu clock value, resulting in a bad (too short) programming of
the twd (local timer). Hence any timer interrupt fires too early.
Kernel (hrtimer_interrupt) notices that the next timer event is not there
yet and reprograms the timer interrupt for the same (not elapsed) event,
which is again programmed too early for the same reason, ...
The effect is multiple additional (and unused / useless) timer interrupts
for each real timer event (including scheduler tick). (I observed 5
additional interrupts for the schedulter tick with MPU @ 1.2GHz. Note that
lower MPU freqs led to less interrupts).

This patch fixes this 'fancy' effect, with effectively observed reduced
twd triggering rate, verified on each MPU OPP.

Signed-off-by: Sebastien Jan <s-jan@ti.com>
omap: remoteproc: adjust CMA base addresses to be within 512MB

The remoteproc CMA based addresses have been adjusted to lie
within the first 512MB of DDR, and end exactly at 0xA0000000.

The CMA regions will be included as part of the kernel memory
and should lie outside of the memory that would be used for
vmalloc. The current CMA addresses are determined based on
the default vmalloc size of 240M in 3.3+ kernel (see commit
0536bdf33faff4d940ac094c77998cfac368cfff "ARM: move iotable
mappings within the vmalloc region").

The new CMA base addresses are computed by subtracting the
required rproc CMA size from 0xA0000000. This adjustment allows
flexibility for increasing the vmalloc size by a further 256MB
to 496MB [__pa(VMALLOC_START) should be 0xA0800000] from the
current value.

Change-Id: Idfd31357f302045c2b1fc46ed18c96ed0bdb0632
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
remoteproc/omap: correct the CMA sizes used for IPU & DSP

The CMA carveout sizes used for OMAP4 & OMAP5 targets are
stale and outdated. These do not match the current memory
regions defined in the BIOS-side remote processor platform
files.

The IPU carveout sizes are adjusted to the correct sizes
after reducing an additional 1MB region used in older kernel
for secure usecases. The DSP carveout size is adjusted to
actually include the two separate 1MB regions used for the
IPC VRING & IPC DATA sections instead of a single 1MB as used
for both in the previous kernel.

This mismatch didn't cause any major issues because of the
8MB alignment enforced during the definition of the CMA regions.

Change-Id: I778d4bccbac44008873e6113a174de3cd75441a6
Signed-off-by: Suman Anna <s-anna@ti.com>
omap: remoteproc: adjust the CMA start addresses for OMAP4

The CMA start addresses for OMAP4 are computed based on the
carveout size value of 104MB for IPU. The OMAP4 CMA start
addresses have been shifted down by 8MB (accounting for the
8MB alignment requirement for CMA) to allow an additional
2MB of memory for OMAP4 IPU.

These new addresses will suffice for IPU carveout memory
size increases until 112MB.

Change-Id: Ic77b9c0b3d13a6cb0f1798bbc52c5f85585604bf
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: increase default CMA size for OMAP4 IPU to 106MB

The default CMA carveout size for OMAP4 IPU has been increased from
104MB to 106MB to allow the IPU heap to be increased by the same
amount. This change is being done to resolve failures in various
multimedia usecases due to heap memory exhaustion.

Change-Id: Iecc722a5871747dc0280e43b88cd57b16d43459d
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/omap: increase default CMA size for DSP by 2MB

The default CMA carveout size for DSP has been increased from
5MB to 7MB to accomodate adding new libraries to the DSP product
base-image. This change does not require any change in the CMA
start addresses as the increase is still within the CMA-aligned
8MB.

Change-Id: I7c0c81c6cbd7f29588c82b1a40079032364b31f2
Signed-off-by: Suman Anna <s-anna@ti.com>
gitignore

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Do not disable clock when wait_target_ready complains

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Unblock Benelli firmware loading v2

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! More firmware alignments between omap4/5

* One single OMAP_IPU_CMA_SIZE

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! iommu omap5 take both Benelli and Tesla out of reset

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
omapdrm no need to die if no detect callback

Signed-off-by: Andy Green <andy.green@linaro.org>
ARM: mm: Flush only CPU local cache instead of all cache levels.

The ARMv7 processor setup functions clean and invalidates the
cpu cache before enabling MMU. The intention here is to start
with clean CPU local cache.

But on architectures like Cortex-[A15/A8], this code will end
up flushing the L2 cache as well which undesirable and incorrect.
The setup functions are used in CPU hotplug scenario's too and
hence flushing all cache levels should be avoided.

Fix this code by restricting the cache flush to local cpu
cache or L1.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
remoteproc: add debugfs entry to print the firmware version info

A debugfs entry called "version" is created under the corresponding
remoteproc directory when the firmware image is processed. The
design relies on the ELF baseimage having a special ELF section
with the name '.version'. The version info has to be stored into
this section in the remote processor image build step.

A read on the entry will print the contents of the version section.
The following shows an example usage:
    cat /d/remoteproc/remoteproc0/version

Change-Id: I205485c5bfc8330231ff668f88c25c47182edaf4
Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>

Conflicts:

	drivers/remoteproc/remoteproc_core.c
omapdce: add a separate ioctl for getting version string

The version call uses a separate buffer to return the version string,
and this address needs to be translated and sent via RPC.
To avoid breaking backwards compatibility, a new ioctl is used.
dce: pm_runtime implementation