omap_hwspinlock: somewhat reduces sparse warning

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
omap: mailbox: fix sparse warnings

The following sparse warnings have been fixed:

arch/arm/mach-omap2/mailbox.c:295:18: warning: symbol 'mbox_dsp_info' was not declared. Should it be static?
arch/arm/mach-omap2/mailbox.c:303:18: warning: symbol 'omap3_mboxes' was not declared. Should it be static?
arch/arm/mach-omap2/mailbox.c:333:18: warning: symbol 'omap2_mboxes' was not declared. Should it be static?
arch/arm/mach-omap2/mailbox.c:361:18: warning: symbol 'mbox_1_info' was not declared. Should it be static?
arch/arm/mach-omap2/mailbox.c:384:18: warning: symbol 'mbox_2_info' was not declared. Should it be static?
arch/arm/mach-omap2/mailbox.c:390:18: warning: symbol 'omap4_mboxes' was not declared. Should it be static?

Signed-off-by: Suman Anna <s-anna@ti.com>
omap: mailbox: fix NULL nb in omap_mbox_put

omap_mbox_put must check nb for NULL before trying to unregister it

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Iliyan Malchev <malchev@google.com>
omap: mailbox: call request_irq after mbox queues are allocated

Calling request_irq first could provoke that ISR function is executed
before the mbox queues are allocated causing a kernel panic when they are
dereference inside the ISR.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
omap: mailbox: check iomem resource before dereferencing it

Add a NULL check for iomem resource in mailbox probe functions

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
ARM: OMAP: iommu-added cache flushing operation for L2 cache

Signed-off-by: Ramesh Gupta <grgupta@ti.com>
Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
ARM: OMAP: iommu-dmm fixes

This fixes the following:
  1. pgd and pte entries weren't getting flushed out leading to MMU faults.
  2. Cache invalidate was setting wrong size parameter to
     memory_regain_ownership leading cache invalidate function to fail.

Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
iommu/omap: disable mmu interrupts after the first fault

Signed-off-by: Guzman Lugo, Fernando <fernando.lugo@ti.com>
iommu/omap: fix checkpatch warnings in omap iommu code

This patch fixes the checkpatch warnings in omap iommu
code related to broken strings.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP3/4: iommu: migrate to hwmod framework

Use hwmod data and device attributes to build and register an
omap device for iommu driver.

 - Update the naming convention in isp module.
 - Remove unneeded check for number of resources, as this is now
   handled by omap_device and prevents driver from loading.
 - Now unused, remove platform device and resource data, handling
   of sysconfig register for softreset purposes, use default
   latency structure.
 - Use hwmod API for reset handling.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
ARM: OMAP3/4: iommu: adapt to runtime pm

Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.

Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
omap: iommu: deny clkdm idle when iommu fault is not handle until shutdown

When and iommu fault happen and it could not be handled (that means a
valid physical address could not be found) we cannot ack the status bit
of the interrupt. Therefore, we need to deny clkdm idle for the clock of
the iommu until the ack can be done. Otherwise, if there is no
clkdm activity (that can happen if the processor associated with the
processor is put under reset) the clkdm will try to go to idle and it will
fail and get stuck in transition state because of the pending interrupt.
In order to avoid that scenario we deny idle in the mmufault ISR and then
in the shutdown of the iommu we ack the interrupt and then allow idle
again.

Also, for omap4 and omap5 the IPU and DSP processors have a shared MMU
which try to use the iommu again once it is acked even if the processor
is already under reset. For that reason the shared MMU must be reset.
The shared MMU only has hardreset and it is shared with the iommu, for
that reason we need to do a hardreset en the iommuu device. In order
to accomplish that we use hwmod functions.

Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
omap: iommu: enable bus-error back response to remoteproc

The OMAP remoteproc MMUs can give out the fault address as well
as the PC value that caused the fault. This feature is not
available on ARM cores, and instead the value is retrieved
using a bus-error response back to the remote processor.

This functionality is programmable through the MMU_GP_REG
register (only defined for IPU).  The cores are simply
stalled if the MMU_GP_REG.BUS_ERR_BACK_EN bit is not set.
When set, a bus-error exception is raised allowing the
processor to handle it as a bus fault and print the
exception context.

Signed-off-by: Wajahat Khan <w-khan@ti.com>
Signed-off-by: Shahid Akhtar <sakhtar@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
OMAP: remoteproc: set dependency on CONFIG_CMA

Commit f1ae98da8525c6b8b1c301c3a2b0bd2b6515cca2
(ARM: dma-mapping: remove unconditional dependency on CMA)
removes the unconditional selection of CMA for ARM platforms,
however omap remoteproc needs it for its pool allocation,
so make it depend on its Kconfig.

Now CMA must be selected before OMAP_REMOTEPROC can be
made available.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
remoteproc: fix checkpatch warnings in remoteproc core

This patch fixes all sparse warnings in the remoteproc core file.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: OMAP: add remoteproc devices for OMAP4

Add an omap-rproc device with which one can start using OMAP4's
dual-M3 "Ducati" ipu subsystem.

Currently we're adding support only for the first M3 core (hence
the name "ipu_c0"); support for the second M3 core, as well as for
the DSP subsystem, will be added later on.

Bind this device to its dedicated IOMMU device, and assign it a
dedicated mailbox instance too.

In addition, reserve it a physically contiguous memory region using
the upcoming CMA mechanism (this makes this patch impossible to merge
at this point).

Note: at this point we're using a fixed CMA base address (as defined by
OMAP_RPROC_CMA_BASE), but this will go away once the generic iommu-based
DMA API will materialize, because at that point we will (almost) not care about
the physical location of the CMA memory.

Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com>.

Designed with Brian Swetland <swetland@google.com>.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>

ARM: OMAP4: adapt rproc CMA base addr to 3.3 RAM truncation

On 3.3 the System RAM is truncated earlier than it was before,
due to an increase in the vmalloc region to 240MB (from 120MB);
see commit 0536bdf33faff4d940ac094c77998cfac368cfff "ARM: move
iotable mappings within the vmalloc region".

Adapt the rproc CMA region to accomodate that (otherwise some of the pages
will elicit invalid pfn warnings when the cma regions are activated).

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
OMAP: remoteproc: add reset handling

Recent changes in hwmod now require for drivers to handle reset
lines. Otherwise rproc initialization will fail.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
OMAP: remoteproc: hwmod name change for ipu

ipu_c0 no longer exists, now ipu must be used.

[Not for upstream]
Separated from iommu hwmod series since this is not applicable
to mainline.

Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org>
omap4: remoteproc: add support for dsp/tesla subsystem

Add the omap-rproc device for using OMAP4's DSP "Tesla"
subsystem.

Bind this device to its dedicated iommu, and assign it to
mailbox-2.

Contiguos memory region was allocated for DSP. Macros for
CMA allocation were renamed to reflect the memory owner.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
omap: add ipu and dsp as configurable remoteproc instances

OMAP4 supports two remoteproc instances - ipu & dsp. The
CONFIG_OMAPREMOTE_PROC menuconfig option enabled
support for all OMAP remoteproc instances, but there was no
choice to enable/disable a specific remoteproc instance.

This patch adds two additional dependent config options for
finer control over these remoteproc instances. The option
CONFIG_OMAPREMOTE_PROC will continue to be the generic
option for enabling remoteproc driver support for OMAP.

Signed-off-by: Juan Gutierrez <jgutierrez@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>