Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Pull in a bug fix from the iommu feature branch.

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Fix a sleeping function invocation in atomic context bug

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

iommu/omap: Fix a sleeping function invocation in atomic context bug

The kzalloc function in the omap_iommu_attach_init() function is
invoked with GFP_KERNEL flag, but the function is called with a
spinlock held (atomic context). This throws up the following warning
with CONFIG_DEBUG_ATOMIC_SLEEP enabled,

 "BUG: sleeping function called from invalid context at mm/slab.c:3167"

Fix the same by using the appropriate GFP_ATOMIC flag. Note that
the fix does not convert the spinlock into a mutex, even though the
attach is done usually in a process context. This is done to keep the
IOMMU API generic and allow them to be called from any context.

Fixes: e7eb9c11 ("iommu/omap: add support to program multiple iommus")
Tested-by: Vishal Mahaveer <vishalm@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Pull in a minor typo fix from the iommu feature branch.

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Fix a minor typo in debugfs output

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

virtio: fix memory leak of virtio ida cache layers

The virtio core uses an static ida named virtio_index_ida for
assigning index numbers to virtio devices during registration.
The ida core may allocate some internal ida cache layers upon
any ida assignment, and all these layers are truely freed only
upon the ida destruction. The virtio_index_ida is not destroyed
at present, leading to a minor memory leak, if the virtio core
is built as a module and atleast one virtio device is registered
and unregistered.

Fix this by invoking ida_destroy() in the virtio core module
exit.

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

remoteproc: fix memory leak of remoteproc ida cache layers

The remoteproc core uses an static ida named rproc_dev_index for
assigning an automatic index number to a registered remoteproc.
The ida core may allocate some internal ida cache layers upon
any ida assignment, and all these layers are truely freed only
upon the ida destruction. The rproc_dev_index ida is not destroyed
at present, leading to a minor memory leak, if the remoteproc core
is built as a module and atleast one rproc device is registered
and unregistered.

Fix this by invoking ida_destroy() in the remoteproc core module
exit.

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

iommu/omap: Fix a minor typo in debugfs output

The second-level page table dump is being printed with
a prefix value of 1, which is meant for Level-1 PTEs.
This should have been a 2, so fix it.

Fixes: cb2006d (iommu/omap: Switch pagetable debugfs entry to use seq_file)
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP: remoteproc: correct watchdog timer data for OMAP4/5 IPU

The watchdog timers chosen for the IPU remoteproc device on OMAP4
and OMAP5 is wrong. The correct watchdog timer for the second
Cortex-M3/M4 core in the IPU is GPTimer 11, and not GPTimer 4.
The timer data was erroneously copied from the corresponding DRA7
watchdog data. GPTimer 4 is used as the SYS/BIOS tick source for
the second core if the IPUs were not running SMP-mode SYS/BIOS.

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

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the various OMAP IOMMU cleanup and fixes. The following
are the main changes:
 - pagetable debugfs entry lists all valid ptes, write operation
   no longer allowed on this entry
 - ver debugfs entry removed
 - permission fixes for the debugfs files
 - code cleanup of unused fields

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Switch pagetable debugfs entry to use seq_file
  iommu/omap: make pagetable debugfs entry read-only
  iommu/omap: Fix bus error on debugfs access of unattached IOMMU
  iommu/omap: reset the domain field upon detaching
  iommu/omap: Fix the permissions on nr_tlb_entries
  iommu/omap: Simplify omap2_iommu_fault_isr()
  iommu/omap: Remove bogus version check in context save/restore
  iommu/omap: Remove omap_iommu_arch_version() and version field
  iommu/omap: Remove ver debugfs entry
  iommu/omap: Remove conditional definition of dev_to_omap_iommu()
  iommu/omap: Remove duplicate declarations
  iommu/omap: remove refcount field from omap_iommu object
  iommu/omap: Remove omap_iommu unused owner field
  drivers/iommu/omap-iommu-debug.c: fix decimal permissions
  drivers/iommu/omap-iopgtable.h: remove unneeded cast of void*
  drivers/iommu: remove unnecessary platform_set_drvdata()

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

iommu/omap: Switch pagetable debugfs entry to use seq_file

The debugfs entry 'pagetable' that shows the page table entry
(PTE) data currently outputs only data that can be fit into a
page. Switch the entry to use the seq_file interface so that
it can show all the valid page table entries.

The patch also corrected the output for L2 entries, and prints
the proper L2 PTE instead of the previous L1 page descriptor
pointer.

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

iommu/omap: make pagetable debugfs entry read-only

Remove the writeability on the 'pagetable' debugfs entry,
so that the mapping/unmapping into an OMAP IOMMU is only
limited to actual client devices/drivers at kernel-level.

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

iommu/omap: Fix bus error on debugfs access of unattached IOMMU

Any debugfs access on an OMAP IOMMU that is not enabled (done during
attach) results in a bus error due to access of registers without
the clock or the reset enabled for the respective IOMMU. So, add a
check to make sure the IOMMU is enabled/attached by a client device.
This gracefully prints a "Operation not permitted" trace when the
corresponding IOMMU is not enabled.

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

iommu/omap: reset the domain field upon detaching

The .domain field in omap_iommu struct is set properly when the
OMAP IOMMU device is attached to, but is never reset properly
on detach. Reset this properly so that the OMAP IOMMU debugfs
logic can depend on this field before allowing the debugfs
operations.

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

iommu/omap: Fix the permissions on nr_tlb_entries

The permissions on the debugfs entry "nr_tlb_entries" should
have been octal, not decimal, so fix it.

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

iommu/omap: Simplify omap2_iommu_fault_isr()

The function omap2_iommu_fault_isr() does an unnecessary
recomputation of the return value. The logic relies on
setting the same bit fields as the MMU fault error status
bits, so simplify this function and remove the unneeded
macros. These macros were originally exported to notify
MMU faults to users prior to the IOMMU framework adaptation,
but are now redundant.

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

iommu/omap: Remove bogus version check in context save/restore

The omap2_iommu_save_ctx() and omap2_iommu_restore_ctx()
performs a sanity version check against a fixed value
that is correct only for OMAP2/OMAP3 IOMMUs. This fixed check
does not scale for all OMAP2+ IOMMUs and is not absolutely
required, so it has been removed.

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

iommu/omap: Remove omap_iommu_arch_version() and version field

The function omap_iommu_arch_version() is not used anymore,
and is not required either, so remove it. The .version field
in struct iommu_functions that this function uses is also
removed, as it is not really an ops to retrieve a version and
there won't be any usage for this field either.

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

iommu/omap: Remove ver debugfs entry

The debugfs entry 'ver' to read the OMAP IOMMU version is
not much useful for developers, so it has been removed. The
same can be deduced from the register dump, provided by the
debugfs entry 'regs', REVISION register. This also allows us
to remove the omap_iommu_arch_revision() which is currently
returning a fixed value.

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

iommu/omap: Remove conditional definition of dev_to_omap_iommu()

The dev_to_omap_iommu() is local to the OMAP IOMMU modules, and
need not be defined conditionally. The CONFIG_IOMMU_API dependency
check was added in the past to fix a compilation issue back when
the header resided in the arch/arm layers, and is no longer
needed.

While at this, fix the header against double inclusion as well.

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

iommu/omap: Remove duplicate declarations

The omap_iommu_save_ctx() and omap_iommu_restore_ctx() declarations
are defined in include/linux/omap-iommu.h and do not belong in the
internal drivers/iommu/omap-iommu.h header, so remove them.

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

iommu/omap: remove refcount field from omap_iommu object

The refcount field in omap_iommu object is primarily used to check
if an IOMMU device has already been enabled, but this is already
implicit in the omap_iommu_attach_dev() which ensures that only
a single client device can attach to an IOMMU. This field is
redundant, and so has been cleaned up.

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

iommu/omap: Remove omap_iommu unused owner field

The owner field is never set. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Conflicts:
drivers/iommu/omap-iommu.c

drivers/iommu/omap-iommu-debug.c: fix decimal permissions

These should have been octal.

Signed-off-by: Joe Perches <joe@perches.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[s-anna@ti.com: cherry-pick commit 'ff3a2b7' from v3.14]
Signed-off-by: Suman Anna <s-anna@ti.com>

drivers/iommu/omap-iopgtable.h: remove unneeded cast of void*

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[s-anna@ti.com: cherry-pick commit 'a2529ad' from v3.13]
Signed-off-by: Suman Anna <s-anna@ti.com>

drivers/iommu: remove unnecessary platform_set_drvdata()

The driver core clears the driver data to NULL after device_release or
on probe failure.  Thus, it is not needed to manually clear the device
driver data to NULL.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Suman Anna <s-anna@ti.com>
Acked-by: Libo Chen <libo.chen@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[s-anna@ti.com: cherry-pick commit '5e42781' from v3.12]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP: remoteproc: add watchdog timer data for DRA7 IPU2

The watchdog timer information has been added to the device data
(timer data) associated with the IPU2 remoteproc device on DRA7 SoC.
The watchdog functionality will use GPTimers 4 and 9 for each of
the cores in IPU2. No watchdog timer is added to the remaining IPU
and DSP processors, but can be easily added as per need.

The BIOS-side code on IPU2 needs to configure/refresh this timer
properly to not throw a watchdog error.

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

ARM: OMAP: remoteproc: add watchdog timer data for OMAP4/5 remoteprocs

The watchdog timer information has been added to the device data
(timer data) associated with each of IPU and DSP remoteproc devices
on OMAP4 and OMAP5 SoCs. The watchdog functionality will use GPTimers
4 and 9 for IPU, and GPTimer 6 for DSP.

The chosen watchdog timers are identical for common IPU and DSP
processors across OMAP4 and OMAP5. This data will be used to
initialize the watchdog timers. The BIOS-side code needs to configure
and refresh this timer properly to not throw a watchdog error.

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

remoteproc/omap: add watchdog functionality for remote processors

Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.

Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.

A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.

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

remoteproc/omap: report device exceptions and trigger recovery

The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.

Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: introduce watchdog and device exception error types

Introduce two new error types: watchdog and generic device exception,
that can be used for error reporting and recovery.

A Watchdog error is detected through a timer interrupt, due to that
timer not getting refreshed by a remote processor because it is stuck
in a busy loop. The generic device exception is a catch-all for all
other internal exceptions that can be reported to the host processor
through some mechanism.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: implement last trace for remoteproc

The last trace is a way of preserving the remoteproc traces past
remoteproc recovery. This is achieved by creating a new last_trace
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copy can then be read out using a debugfs entry. The trace entries
themselves are cleaned up after the copy and are recreated during
a recovery reload

Eg:
cat <debugfs root>/remoteproc/remoteprocX/traceY_last
should give the traces that were printed out just before the recovery
happened on remoteproc X for trace Y.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: DRA7: hwmod_data: remove modulemode from IPU/DSP hwmods

The .modulemode field is removed from all the IPU and DSP processor
hwmods. This fixes a kernel crash during the shutdown sequence of any
of the remoteproc devices, either during a normal teardown or during
a recovery.

The DSP and IPU processor subsystems are represented by multiple
hwmods - one for each of the MMUs present within the subsystem,
and one for the processor cores. The processor subsystem is clocked
from a single clock source with separate reset lines for each of
the processors and the MMUs. This clock and reset information is
represented in separate hwmods to allow the management of these
entities in different drivers operating on the corresponding
platform devices. This doesn't fit quite well into the current
omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of
the MMUs, loading of the firmware into RAM mapped by the MMUs, and
releasing the processors from reset. A shutdown sequence follows a
reverse pattern with the processors put into reset first followed by
the unmapping and disabling of the MMUs. Both the processors and the
MMUs are present within a single clock domain and requires the domain
be clocked and enabled until the last entity. The kernel crash is
caused during the unmapping phase of the MMUs, as the hwmod layer
disables the module during the omap_device_idle processing of the
processor hwmod. This issue is fixed by not defining a modulemode
for the IPU/DSP processors, which results in keeping the module in
an activated state. The module is disabled properly during the
omap_device_idle processing of the MMU hwmod while disabling the
MMU.

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

ARM: OMAP5: hwmod_data: remove modulemode from IPU/DSP hwmods

The .modulemode field is removed from both the IPU and DSP processor
hwmods. This fixes a kernel crash during the shutdown sequence of any
of these remoteproc devices, either during a normal teardown or during
a recovery.

The DSP and IPU processor subsystems are represented by multiple hwmods
- one for each of the MMUs present within the subsystem, and one for
the processor cores. The processor subsystem is clocked from a single
clock source with separate reset lines for each of the processors and
the MMUs. This clock and reset information is represented in separate
hwmods to allow the management of these entities in different drivers
operating on the corresponding platform devices. This doesn't fit quite
well into the current omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of
the MMUs, loading of the firmware into RAM mapped by the MMUs, and
releasing the processors from reset. A shutdown sequence follows a
reverse pattern with the processors put into reset first followed by
the unmapping and disabling of the MMUs. Both the processors and the
MMUs are present within a single clock domain and requires the domain
be clocked and enabled until the last entity. The kernel crash is
caused during the unmapping phase of the MMUs, as the hwmod layer
disables the module during the omap_device_idle processing of the
processor hwmod. This issue is fixed by not defining a modulemode
for the IPU/DSP processors, which results in keeping the module in
an activated state. The module is disabled properly during the
omap_device_idle processing of the MMU hwmod while disabling the
MMU.

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

ARM: OMAP4: hwmod_data: remove modulemode from IPU/DSP hwmods

The .modulemode field is removed from both the IPU and DSP processor
hwmods. This fixes a kernel crash during the shutdown sequence of any
of these remoteproc devices, either during a normal teardown or during
a recovery.

The DSP and IPU processor subsystems are represented by multiple hwmods
- one for each of the MMUs present within the subsystem, and one for
the processor cores. The processor subsystem is clocked from a single
clock source with separate reset lines for each of the processors and
the MMUs. This clock and reset information is represented in separate
hwmods to allow the management of these entities in different drivers
operating on the corresponding platform devices. This doesn't fit quite
well into the current omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of
the MMUs, loading of the firmware into RAM mapped by the MMUs, and
releasing the processors from reset. A shutdown sequence follows a
reverse pattern with the processors put into reset first followed by
the unmapping and disabling of the MMUs. Both the processors and the
MMUs are present within a single clock domain and requires the domain
be clocked and enabled until the last entity. The kernel crash is
caused during the unmapping phase of the MMUs, as the hwmod layer
disables the module during the omap_device_idle processing of the
processor hwmod. This issue is fixed by not defining a modulemode
for the IPU/DSP processors, which results in keeping the module in
an activated state. The module is disabled properly during the
omap_device_idle processing of the MMU hwmod while disabling the
MMU.

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

ARM: OMAP: remoteproc: use separate timer data for DRA7 & OMAP4/OMAP5

DRA7xx SoC has a crossbar IP (a kinda interrupt router/multiplexer)
before each of the processor subsystems' interrupt controllers. This
allows a more flexible assignment of the dmtimers for the various
needs of the remote processor subsystems on DRA7xx unlike on OMAP4/5.

DRA7xx already has dedicated timer data for IPU1 and DSP2 processors.
Separate out the timer data that is currently common across the
remaining DSP/IPU processors on DRA7xx and those on OMAP4/OMAP5 SoCs.
This increases the flexibility of using different timers (including
watchdog timers) for these processors on DRA7xx. The data is however
not separated between OMAP4 and OMAP5 SoCs, to maintain complete
compatibility between firmware images on these two SoCs.

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

remoteproc: add support to handle internal memories

A remote processor may need to load certain firmware sections into
internal memories (eg: RAM at L1 or L2 levels) for performance or
other reasons. Introduce a new resource type (RSC_INTMEM) and add
an associated handler function to handle such memories. The handler
creates a kernel mapping for the resource's 'pa' (physical address).

Note that no iommu mapping is performed for this resource, as the
resource is primarily used to represent physical internal memories.
If the internal memory region can only be accessed through an iommu,
a devmem resource entry should be used instead.

Signed-off-by: Robert Tivy <rtivy@ti.com>
[s-anna@ti.com: add dedicated resource structure, and lots of cleanup]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP2+: remoteproc: add the second MMUs to DRA7 DSPs

The DRA7xx DSP subsystem has two MMUs, one intended for the
processor core, and the other intended for the EDMA port. Add
the second MMU information to the corresponding DSP rproc device
archdata.

This will allow the OMAP IOMMU driver core to mirror program
the second MMU alongside the first MMU, and present identical
translations to both the processor core and the EDMA port within
the DSP sub-system. This helps avoid any special translations
needed in the firmware for EDMA operations on DRA7xx DSPs
specifically. All other OMAP SoCs share the same MMU for both
the ports.

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

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Merge in the omap iommu driver enhancements and fixes from the
iommu feature tree that allows programming of multiple iommus
within a single domain. This provides the necessary framework
for programming and enabling the second MMU in each of the DSP
processor sub-systems in DRA7xx family of SoCs.

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: add support to program multiple iommus
  iommu/omap: change the attach detection logic
  ARM: OMAP2+: devices: use sentinel terminated iommu archdata for ISP
  ARM: DRA7: hwmod data: remove resets from MMU1 for DSPs
  ARM: DRA7: hwmod data: add iommu index values to dev_attr data
  iommu/omap: fix dra7 syscfg programming
  iommu/omap: add a index field for each iommu

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

iommu/omap: add support to program multiple iommus

A client user instantiates and attaches to an iommu_domain
to program the IOMMU associated with the domain. The iommus
programmed by a client user are bound with the iommu_domain
through the user's device archdata. The OMAP IOMMU driver
currently supports only one IOMMU per IOMMU domain per
user.

The OMAP IOMMU driver has been enhanced to support allowing
multiple IOMMUs to be programmed by a single client user. This
support is being added mainly to handle the DSP subsystems in
the DRA7xx SoC, which have two MMUs within the same subsystem.
These MMUs provide translations to a processor core port and
an EDMA port. This support allows the both the MMUs to be
programmed together, but with each one retaining this own
internal state objects.

The multiple iommus are expected to be provided through a
sentinel terminated array of omap_iommu_archdata objects
through the client user's device archdata. The OMAP driver
core is enhanced to loop through the array of attached
iommus and program them for all common operations.

NOTE:
1. Any existing OMAP iommu users are required to be converted
   to use the sentinel-terminated array form for programming
   the MMUs associated with the devices.
2. The dev_to_omap_iommu() macro which operates on a device's
   archdata is not adjusted, as its current users can work
   without any additional changes. The OMAP iommu debug code
   relies on operating on each individual iommu object. The
   omap iovmm module is also not fixed up to support multiple
   MMUs as the sole user of this module, OMAP3 ISP driver, has
   only one iommu. The omap iovmm module is expected to be
   deprecated, and is not used by any of the MMUs on OMAP4+
   SoCs.

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

iommu/omap: change the attach detection logic

The OMAP IOMMU driver allows only a single device (eg: a rproc
device) to be attached per domain. The current detection logic
relies on an attached iommu for the client device. Change this
logic to use dedicated flags in preparation for supporting
multiple iommu devices to be bound to a single iommu domain.

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

ARM: OMAP2+: devices: use sentinel terminated iommu archdata for ISP

A client user of an IOMMU is tied to use a single IOMMU at the
moment, with both of them bound together through the client user
device's archdata field.

Update the OMAP3 ISP device to use a sentinel terminated iommu
archdata array. OMAP3 ISP will still be using only one MMU device,
but this logic allows the OMAP3 ISP driver to work properly even
after OMAP IOMMU driver is enhanced to program multiple IOMMUs
together.

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

ARM: DRA7: hwmod data: remove resets from MMU1 for DSPs

The second MMU in the DSP processor subsystems, intended for
the providing address translations to the EDMA port, is also
controlled by the same reset as the first MMU, that provides
the translations to the processor cores.

This second MMU will not be programmed independently, it will
be programmed along-side the first MMU as a simple mirror copy.
The reset information need not be duplicated in both the MMUs,
as the resets will be ensured to be programmed properly while
configuring the first MMU. The reset data has therefore been
cleaned up. This also fixes a reset failure error in the hwmod
layer caused by the reset already being deasserted when the
data is not removed.

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

ARM: DRA7: hwmod data: add iommu index values to dev_attr data

A common omap_mmu_dev_attr data is defined currently for both
the MMU0 and MMU1 instances within the DSP processor subsystems.
Use separate copies of this data with an added iommu index value
to identify the exact MMU within the DSP processor subsystem.
Subsystems with only 1 MMU will use the inherent default index
value of 0.

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

iommu/omap: fix dra7 syscfg programming

The dra7_cfg_dspsys_mmu() function currently can enable
only the first MMU within the DSP processor sub-system
in DRA7xx. Fix this function to actually use the index
from the IOMMU object so that it can program both MMU0
and MMU1 in the DSP processor sub-system correctly.

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

iommu/omap: add a index field for each iommu

Add an index field in omap_iommu object to store the index
of the IOMMU instance within a processor subsystem. The index
allows to identify each IOMMU instance in a processor subsystem
having multiple IOMMUs. The index 0 will be used by the default
MMU that a processor core goes through. The index is expected
to be supplied through the corresponding platform data.

This is in preparation to enable all the MMUs within DRA7xx
DSP sub-systems. DRA7xx is the first SoC in the OMAP family
to have more than a single MMU within a processor sub-system.

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

ARM: OMAP2+: remoteproc: use sentinel terminated iommu archdata

A remoteproc device is tied with a single IOMMU at the moment,
and both are bound together through the rproc device's archdata
field, which is defined as a single element at present.

Change this iommu archdata information to be represented through
a sentinel terminated array, so that more than one MMU can be
added to a rproc device. The sentinel allows the IOMMU driver
core to be adapted to recognize multiple IOMMUs without having
to change the iommu archdata structure.

This logic scales well with both the current single IOMMU
instance per processor as well as with the upcoming enhanced
support in the OMAP IOMMU driver to program multiple IOMMUs
together.

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

ARM: OMAP2+: remoteproc: split iommu archdata information

A remoteproc device is tied with its IOMMU through it's device
archdata field. The way this information is assigned currently
uses an array of iommu archdata elements, with each element
representing an IOMMU corresponding to a processor.

Split this iommu archdata array into discrete declarations to
prepare for supporting multiple iommus per processor. This info
could have been filled in directly in the respective platform
device declarations, but the discrete declarations keep both
the platform device and iommu archdata declarations to a minimum
with better code readability. The new iommu archdata is integrated
by introducing a new element to the struct omap_rproc_pdev_data.

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

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Merge in the changes from iommu feature tree that enables the
bus error response back to the IPU cores on MMU faults on OMAP4,
OMAP5 and DRA7 SoCs.

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  ARM: DRA7: hwmod data: add bus-error back flag to ipu iommu attrs
  ARM: OMAP5: hwmod data: add bus-error back flag to ipu iommu attrs
  ARM: OMAP4: hwmod data: add bus-error back flag to ipu iommu attrs
  iommu/omap: enable bus-error back on supported iommus

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

ARM: DRA7: hwmod_data: correct main clk for IPU1

The IPU1 functional clock is currently misconfigured to have the
dpll_core_h22x2_mux clock as the main clock, but it is actually
the output of a mux clock, ipu1_gfclk_mux. Correct the hwmod data
appropriately to use this mux clock as the main clock. The mux clock
in turn will be configured to be sourced from the dpll_core_h22x2_ck,
and this ensures both IPU1 and IPU2 to be running from the same
clock source and at the same clock frequency.

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

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Merge in the IPU1 clock fixes from the iommu tree into the remoteproc
tree.

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  ARM: DRA7: clock: source IPU1 functional clock from CORE DPLL
  ARM: DRA7: hwmod_data: correct main clk for IPU1 MMU

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

ARM: DRA7: hwmod data: add bus-error back flag to ipu iommu attrs

The bus-error back response flag information has been added to
the iommu device attributes for IPU processor on DRA7. This raises
a bus error to the IPU processor, which can give out additional
stack trace of the MMU fault.

NOTE: This register is defined for the DSP MMUs as well, but
enabling it for DSPs suppresses the MMU fault address being
reported properly in the MMU_FAULT_AD register. The MMU_FAULT_PC
and MMU_FAULT_STATUS registers are not functional already on the
new C66 DSPs in DRA7. The MMU_FAULT_AD suppression also happens
for IPU, but the stack trace from the BIOS-side gives out the
necessary information.

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

ARM: OMAP5: hwmod data: add bus-error back flag to ipu iommu attrs

The bus-error back response flag information has been added to
the iommu device attributes for IPU processor on OMAP4. This flag
is not relevant for DSP.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP4: hwmod data: add bus-error back flag to ipu iommu attrs

The bus-error back response flag information has been added to
the iommu device attributes for IPU processor on OMAP4. This flag
is not relevant for DSP.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

iommu/omap: enable bus-error back on supported iommus

The remoteproc MMUs in OMAP4+ SoCs have some additional debug
registers that can give out the PC value in addition to the
MMU fault address. The PC value can be extracted properly only
on the DSP cores, and is not available on the ARM processors
within the IPU sub-systems. Instead, the MMUs have been enhanced
to throw a bus-error response back to the IPU processors.

This functionality is programmable through the MMU_GP_REG register.
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 provide additional debug
information. This feature is turned on by default by the driver on
iommus supporting it.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: DRA7: clock: source IPU1 functional clock from CORE DPLL

The IPU1 functional clock is actually the output of a mux clock,
ipu1_gfclk_mux. The mux clock is sourced by default from the
DPLL_ABE_X2_CLK, and this results in a rather odd clock frequency
(361 MHz) for the IPU1 functional clock. Reconfigure the mux clock
to be sourced from CORE_IPU_ISS_BOOST_CLK (dpll_core_h22x2_ck), so
that both the IPU1 and IPU2 are running from the same clock and
clocked at the same nominal frequency of 425 MHz.

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

ARM: DRA7: hwmod_data: correct main clk for IPU1 MMU

The IPU1 functional clock is currently misconfigured to be
sourced from dpll_core_h22x2_ck. While this is true for IPU2,
there is a mux clock in between dpll_core_h22x2_ck and the
IPU1_GFCLK. Correct the hwmod data for the IPU1 MMU accordingly.
The mux clock is expected to be configured to be sourced from
the dpll_core_h22x2_ck in turn, so that both IPU1 and IPU2
are running at the same clock frequency.

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

ARM: OMAP: remoteproc: adjust the CMA pool size for OMAP5 IPU

The CMA pool size for IPU on OMAP5 is reduced from the previous
168 MB to 56 MB. This reduction is done to account for the removal
of the OMAP camera stack, and to match to that of the size used
on DRA7xx IPU2 processor. The DSP CMA start address and size are
unchanged. This reduced size causes the CMA pools to end at
0x99000000 instead of the previous 0xA0000000.

NOTE: This requires the BIOS-side images to use the reduced carveout
entries in the resource table, so older images with different resource
tables will not boot after this change.

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

ARM: OMAP: remoteproc: adjust the CMA pools for DRA7

The CMA base addresses and sizes are adjusted to meet the current
usecase requirements for the various processors for DRA7XX. The
IPU2 size is decreased by 112MB to account for the removal of
the OMAP camera stack, and the sizes for DSP1 and IPU1 are increased
to meet the current image needs. The CMA base addresses are also
adjusted and calculated using 0x95800000 as the starting base for
IPU2 and using the higher addresses for subsequent processors based
on the changed CMA pool sizes. The current CMA pool would end at
0x9F800000.

NOTE: This requires the BIOS-side images to use matching addresses
in the resource table, so older images with different resource
tables may not boot after this change.

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

ARM: OMAP: remoteproc: request timers for DRA7xx DSP2 processor

The GPTimer #6 is chosen as the BIOS tick source for the DRA7xx
DSP2 processor, so add this timer data to be able to successfully
boot and run a DSP2 image configured with this timer.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The timer value also needs to be unique from the ones used by
other processors so that they can be run simultaneously.

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

ARM: OMAP: remoteproc: update timer request logic to use device nodes

OMAP remote processors use dmtimers for purposes like the BIOS
tick timer or the watchdog timer. The firmware images typically
use specific timers for specific functionalities, and these
timers have to be initially enabled by the remoteproc driver.

The remoteproc driver leverages the dmtimer driver api to request
a timer and currently relies on omap_dm_timer_request_specific api
in non-DT boot and omap_dm_timer_request_by_cap in DT-boot. The
logic around using omap_dm_timer_request_by_cap function does not
scale well for requesting various timers as it requests the timers
by capabilities, and cannot guarantee requesting a specific timer.
A specific timer can be requested only if it has unique capabilities,
and usually there can be multiple timers with same capabilities.

The remoteproc driver is updated to use a new omap_dm_timer_request_by_node
function, and cleans up the usage of requesting timers by capabilities.
The new function allows to request a specific timer using its device
node. The device node is currently being looked up within the driver
by parsing the DT blob and finding the desired timer node using its
hwmod name. The implemented match logic leveraged the hwmod name
instead of the device name to minimize the SoC-specific timer data.

NOTE: This will be replaced through a DT phandle when remoteproc
devices are represented as DT nodes themselves.

Tested-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP: Add function to request timer by node

Add a function so that OMAP dmtimers can be requested by device-tree
node. This allows for devices, such as the internal DSP, or drivers,
such as PWM, to reference a specific dmtimer node via the device-tree.

Given that there are several APIs available for requesting dmtimers
(by ID, by capability or by node) consolidate the code for all these
functions into a single helper function that can be used by these
request functions.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
[s-anna@ti.com: cherrypick upstream commit 8fc7fcb from v3.10]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add api for retrieving the rproc platform id

A new api, rproc_get_platform_id, is added to allow remoteproc/rpmsg
clients to be able to retrieve a fixed id associated with a rproc
device. Each of the rproc's is given an ida index as well, but this
is dynamic depending on the order rproc_alloc is called, and also
depends on what remote processor devices are instantiated. The
platform device id is therefore chosen, with the assumption that
a remoteproc device is assigned a static platform device id.

The OMAP remoteproc devices do satisfy this requirement, since
static platform devices are needed anyway for declaring the
corresponding CMA pools.

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

ARM: OMAP: remoteproc: request timers for DRA7xx DSP1 processor

The GPTimer #3 is chosen as the BIOS tick source for the DRA7xx
DSP1 processor, so add this timer data to be able to successfully
boot and run a DSP1 image configured with this timer. The timers
are optional, but are mandatory to support device management features
such as power management and watchdog support. The timer value also
needs to be unique from the ones used by other processors so that
they can be run simultaneously.

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

ARM: OMAP: remoteproc: assign timers for DRA7xx IPU processors

The GPTimers #3 and #11 are chosen as the BIOS tick source for the
DRA7xx IPU2 and IPU1 processors respectively, so add this timer data
to the DRA7xx remoteproc platform data. This is needed for successfully
booting an IPU image configured with these timers. The timers are
optional, but are mandatory to support device management features
such as power management and watchdog support.

The timer id for each processor needs to be unique so that other
processors can be run simultaneously. The IPUs are currently expected
to be running in SMP-mode, which requires only a single BIOS tick
timer per processor sub-system.

NOTE: The capability match logic for DRA7xx is very tricky since all
the timers are capable of interrupting all the cores, courtesy of the
Crossbar. This patch is based on the current capabilities listed for
each of the timers in the DRA7xx DTS file, and GPT11 happens to have a
unique combination (for now), enabling it to be acquired successfully
for IPU1.

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

ARM: dts: DRA7: Add IPU timer capabilities

Add the ti,timer-ipu capability to a couple of DRA7xx DMTimers
(currently limited to the ones that have default interrupt mappings
into the IPU processors, they are the same set as those on OMAP4).
This enables the timers to be requested by the remoteproc code
using the timer capabilities.

NOTE: No distinction has been made between IPU1 and IPU2, both of
them have the same default interrupt mappings. The timers are
expected to be assigned statically between the two processors from
the common set. There are some more timers actually that are capable
of interrupting an IPU through a crossbar, but this is beyond the
current scope since the crossbar programming for a particular
processor is expected to be handled by the code running on that
processor.

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

ARM: OMAP2+: add support for DRA7xx processors

DRA7xx SoC has two IPU and two DSP processor subsystems for
offloading different computation algorithms. This patch adds
the initial support to enable booting all these 4 processor
subsystems - IPU1, IPU2, DSP1 & DSP2.

Separate menuconfig options have been added to enable/disable
the booting of these processors. Do note that new config options
are added for IPU1 and DSP2, while IPU2 and DSP1 reuse the ones
defined for OMAP4/OMAP5. Separate macros have also been defined
for the CMA addresses with some reuse of sizes for DRA7xx since
they may have different memory layout/footprints compared to
either of OMAP4/OMAP5.

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

ARM: OMAP2+: define a common reserve function for DRA7xx

A new common reserve function for DRA7xx, dra7_reserve has been
added to enable creating CMA pools specific to the remoteproc
devices on the DRA7xx SoC. This function passes the DRA7xx SoC
identifier to the remoteproc cma reservation function, and can
be used by all DRA7xx related derivative board files.

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

ARM: OMAP2+: control: add dsp boot programming support for DRA7xx

DRA7xx has two instances of DSP processors, each with its own boot
control register. The format of the boot register is also different
from the earlier OMAP2+ SoCs. Support for this is added by adding a
new dra7_dsp_ctrl_write_boot_addr() function and reusing it for
omap_dsp_ctrl_write_boot_addr().

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

ARM: DRA7: hwmod_data: add data for ipu & dsp processors

DRA7xx has two IPUs and two DSPs. The relevant hwmod class
and data structures are added for these devices.

Signed-off-by: G Anthony <a0783926@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP: remoteproc: use separate CMA pool data for OMAP5

OMAP5 has to support a larger memory footprint on IPU compared to
OMAP4. Adjust the CMA addresses and sizes for OMAP5 by defining new
SoC pertinent macros. The SoC detection logic is already supported
by means of the SoC-specific identifier passed from the corresponding
board reserve functions.

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

ARM: OMAP: remoteproc: separate out omap_rproc_pdev_data for OMAP5

The remoteproc platform device creation currently uses common
data structures between OMAP4 and OMAP5. A separate instance of
the omap_rproc_pdev_data structure has been created for OMAP5, in
preparation for using different CMA addresses and sizes for the
OMAP5 SoC. The remoteproc platform device creation code is made
generic so that this can be scaled easily for other newer SoCs
as well.

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

ARM: OMAP2+: add support for OMAP5 remote processors

Support has been added to enable the remoteproc device
registration for OMAP5. OMAP5, like OMAP4, also has two
processor subsystems - DSP and IPU. The IPU subsystem
though has dual Cortex-M4 processors instead of the
dual Cortex-M3 processors in OMAP4, but otherwise has
almost the same features.

The support includes adding a common function for reserving
CMA pools with the OMAP5 SoC identifier. The OMAP5 support
reuses the same data structures as that of OMAP4, and an
adjustment has been made only for DMTimers 5 and 6. These
timers are capable of PWM functionality also in OMAP5, and
the logic is adjusted (at runtime to avoid creating separate
static data structures for OMAP5) so that the timers can be
successfully acquired for the DSP sub-system.

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

ARM: OMAP2+: pass a SoC identifier to omap_rproc_reserve_cma

OMAP5 has to support a larger memory footprint compared to
OMAP4. Support has been added to be able to pick different
CMA addresses and sizes based on a SoC identifier for that
SoC. These SoC identifiers are required since the SoC/CPU
revision check api is not available until the machine
init_early, and the CMA pool reservation for the remoteproc
devices has to be performed earlier during the board memory
setup phase.

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

remoteproc/omap: request a timer(s) for remoteproc usage

The remote processors in OMAP are equipped with internal timers,
like the internal SysTick timer in a Cortex M3/M4 NVIC or the
CTM timer within Unicache in IPU & DSP. However, these timers
are gated when the processor subsystem clock is gated, making
them rather difficult to use as OS tick sources. They will not
be able to wakeup the processor from any processor-sleep induced
clock-gating states.

This can be avoided by using an external timer as the tick source,
which can be controlled independently by the core remoteproc
driver code, but still allowing the processor subsystem clock to
be auto-gated when the remoteproc cores are idle.

This patch adds the support for remote processors to request a
timer(s) to be used by the remoteproc. The timers are enabled and
disabled in line with the enabling/disabling of the remoteproc.
The timer data is not mandatory if the advanced device management
features are not required.

The current design relies on OMAP dmtimer api, which are only
present in machine-specific layers, but this needs to be
revisited as and when the dmtimer code moves under the /drivers
folder.

The following timers are used as the tick sources for OMAP4+
remoteprocs, these are picked through the platform data.
DSP : GPT5
IPU : GPT3

Additional timer(s) can be used in similar fashion for purposes
like watchdog functionality or as a tick source to the second
processor in IPU (in non-SMP mode).

NOTE: If the gptimer is already in use by the time IPU and/or
DSP are loaded, the processors will fail to boot.

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

ARM: OMAP2+: add remoteproc devices for OMAP4

OMAP4 has two remote processor subsystems - a dual ARM Cortex-M3 IPU
and a TI C6400-based DSP subsystem. This patch adds the support for
creating remoteproc platform devices, and other necessary platform
specific hooks needed for enabling and booting the remote processors.

A OMAP_REMOTEPROC dependent config option is defined for each rproc
device that provides the choice to enable/disable creating the
corresponding rproc device. The clock and reset management for these
devices is provided by the omap_device/omap_hwmod layer and hence
has to be implemented through platform data functions ops. The
omap_device layer does not program the resets when enabling a device
and is handled by the remoteproc platform hooks. The hooks perform
the reset management based on the remoteproc subsystem type. An IPU
subsystem has two resets, and the remoteproc device management code
asserts/deasserts these together because of the intrinsic device
management dependencies such as a shared MMU and shared cache between
the two Cortex-M3 processors. This allows the OMAP IPU to be run in
either a SMP-mode or a non-SMP mode (using a post-processed combined
image), and is transparent to the remoteproc core driver code.

Each of the devices is bound to its dedicated IOMMU device, used for
managing the MMU; and a dedicated mailbox instance for signalling
message availability and inter processor communication. These slave
devices are used by the remoteproc driver core through the respective
API provided by the iommu and mailbox drivers. A dedicated CMA pool,
tied with each remoteproc device, is used for managing the various
memory needs of the remote processors.

The current CMA pools and sizes are defined statically for each
device. The starting addresses are fixed to meet current dependencies
on the remote processor side, and will go away when the remote-side
code has been improved to gather this information runtime during its
initialization. There are no Kconfig symbols associated with the CMA
bases and sizes, since it would not scale well for remoteproc devices
on multiple SoCs without making the configuration code cumbersome.

The remoteproc CMA pools are also defined to be within the first 512MB
of RAM and end exactly at 0xA000000. The CMA base addresses are
computed by subtracting the required size from 0xA0000000. This allows
a vmalloc size of upto 496MB [__pa(VMALLOC_START) value of 0xA0800000],
without eliciting invalid pfn warnings when the cma regions are
activated.

Based on patches developed previously for TI product kernels, and
includes contributions from:
    Fernando Guzman Lugo <fernando.lugo@ti.com>
    Ohad Ben-Cohen <ohad@wizery.com>
    Juan Gutierrez <jgutierrez@ti.com>

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: remove the oh_name_opt field from platform data

The oh_name_opt field was primarily defined to identify the hwmod for
the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
hwmod entry is no longer defined usually, but rather a single hwmod
with two reset lines is used to represent both the processors in the
IPU sub-system. A single firmware image (either in SMP-mode or a combined
image for non-SMP mode) is used, with both the resets released together
always as part of the device management. Any power management and
recovery aspects require that both the processors be managed as one
entity due to the presence of shared MMU and unicache within the IPU
sub-system.

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

remoteproc/omap: check for undefined mailbox messages

In case the remoteproc sends a message that is beyond the
last valid message, print it as an error message.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.8.y

Merge the iommu tree into the remoteproc tree, since this is a minimum
for bringing up a remote processor successfully. The remoteproc core
needs to be able to program the IOMMU. The iommu tree supports the
ability to program IOMMUs on all OMAP4+ SoCs including DRA7xx (only
MMU1 on the DSPs in DRA7xx).

* 'iommu-linux-3.8.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: add support for configuring dsp iommus on DRA7xx
  ARM: DRA7: hwmod data: add the DSP_SYSTEM address space
  ARM: DRA7: hwmod data: add mmu data for ipu & dsp
  ARM: DRA7: clock: initialize DSP DPLL and associated output clocks
  ARM: OMAP5: hwmod data: add mmu data for ipu & dsp
  ARM: OMAP5: clock: initialize IVA DPLL and associated output clocks
  ARM: OMAP4: clock: initialize IVA DPLL and associated output clocks
  ARM: OMAP4: hwmod data: correct dsp mmu address range
  iommu/omap: disable mmu interrupts after the first fault
  iommu/omap: dmm fixes
  iommu/omap: add cache flushing operation for L2 cache
  iommu/omap: fix checkpatch warnings in omap iommu code
  iommu/omap: Remove unnecessary null pointer check

Signed-off-by: Suman Anna <s-anna@ti.com>
Conflicts:
arch/arm/mach-omap2/omap_hwmod_54xx_data.c

Merge branch 'mailbox-linux-3.8.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-3.8.y

Merge the mailbox tree into the remoteproc tree, since mailbox is a
slave driver of remoteproc is essential for remoteproc functionality.
This pull request also pulls in the required platform support for all
OMAP4+ SoC including DRA7xx (ramdisk boot only for DRA7xx).

* 'mailbox-linux-3.8.y' of git://git.ti.com/rpmsg/mailbox: (275 commits)
  ARM: dts: DRA7: Add mailbox nodes
  mailbox/omap: check for status of platform_get_irq
  ARM: dts: OMAP2+: add mailbox nodes
  mailbox/omap: add support for parsing dt devices
  mailbox: add support for multiple instances
  ARM: OMAP2+: add user and fifo info to mailbox platform data
  mailbox: introduce irq_flags per mailbox
  mailbox: remove mailbox_type_t from mailbox_ops
  mailbox: remove unused function prototype
  ARM: OMAP4+: Init the target pwrdm state before the pwrdms are setup
  ARM: DRA7: clock: Fix the wrong ABE PLL lock frequency
  mailbox: add documentation to core code and headers
  ARM: DRA7: dts: Remove the non existent l3_main_3 entry
  ARM: DRA7: dpll: No freqsel on DRA7
  ARM: DRA7: dpll: Lock GMAC PLL at boot
  ARM: DRA7: dpll: Lock ABE PLL according to ATL needs
  ARM: DRA7: id: Change control_id_code register address
  ARM: DRA7: Prevent any low power entry in suspend
  ARM: DRA7: Add the build support
  ARM: DRA7: Add PRM dev_inst module offset in global_warm_reset function
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
Conflicts:
arch/arm/mach-omap2/common.h

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 firmware file having a special section
containing the version info. The version info has to be stored into
this section in the remote processor image build step.

This is currently implemented for ELF images by storing the version
information in a specific ELF section named ".version".

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

This is based on a patch developed by Juan Gutierrez on 3.4 kernel,
and has been reworked and ported to 3.8 kernel.

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

remoteproc: add an api to do pa to da conversion

Added an api to provide memory translation from a
physical address to a device virtual address.
Since, carveouts and mappings are stored separately,
we need to traverse both lists.

Also stored the physical addresses for RSC_DEVMEM entries
to enable pa to da conversion for dev mem address spaces too.

Signed-off-by: Subramaniam C.A <subramaniam.ca@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: add safe version of vdev_to_rproc

vdev_to_rproc assumes that the virtio device was created by remoteproc.
In some cases, however, this assumption might not hold. For instance,
when deducing a remoteproc from a given virtio device of a rpmsg
channel. In such cases the function should return an error instead of a
bogus pointer.

Signed-off-by: Ido Yariv <ido@wizery.com>
[s-anna@ti.com: move the rproc_type to internal header]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: 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>

ARM: OMAP4+: Add a timer attribute for timers that can interrupt IPU

Some instances of the DMTIMER peripheral on OMAP4+ devices have the
ability to interrupt the on-chip image processor unit (IPU) subsystem
(a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
Cortex-M4 subsystem on OMAP5) in addition to the ARM CPU. Add a
DMTIMER attribute to indicate which timers can interrupt the IPU.

This patch is similar to the patch, 5c3e4ec (ARM: OMAP: Add a timer
attribute for timers that can interrupt the DSP) that adds a similar
capability for DSP.

DMTIMERs that have the ability to interrupt the IPU on OMAP devices
are as follows:
    OMAP1/2/3 devices : not applicable
    OMAP4/5 devices   : DMTIMERs 3,4,9 & 11

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

remoteproc: fix 80-char checkpatch errors in remoteproc code

This patch fixes the existing checkpatch errors and warnings
related to 80-char limit in the remoteproc source files. These
changes were dropped during upstream acceptance of commit
'5797115', but add them back to maintain 0 checkpatch errors.

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

ARM: dts: OMAP4+: Remove multimedia carveouts

The carveouts that have been reserved for multimedia usecases
are not being used currently by any driver and so have been
cleaned up. Memory will be allocated runtime through CMA for
enabling the multimedia usecases.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
[s-anna@ti.com: cherry-pick commit '3ab65f2' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: OMAP5: Fix missing PWM capability to timer nodes

OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers.

Add ti,timer-pwm attribute for timer 5, 6, 8 and 11.

Signed-off-by: Suman Anna <s-anna@ti.com>
[benoit.cousson@linaro.org: Update changelog and subject to highlight
the fix]
Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
[s-anna@ti.com: cherry-pick commit '8341613' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: OMAP2+: control: add OMAP5 support for dsp boot programming

Support for OMAP5 is added to the omap_dsp_ctrl_write_boot_addr()
to enable the DSP boot.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '668468b' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Cocci spatch "memdup.spatch"

Use kmemdup instead of kmalloc + memcpy.

Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '95cee62' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: free carveout memories only after unmapping them

It is not preferable to have the allocated pages for carveout
memories freed before they are unmapped. The code that deals
with the cleanup of carveout memories is therefore moved after
the corresponding mapping entries were cleaned up.

This is mostly a no-op since the remote processors are already
stopped when the cleanup function is called, but this will make
the cleanup code follow the exact reverse path of allocation.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'b6356a0' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: fix a sparse warning

This patch fixes a sparse warning in the omap remoteproc code
when OMAP_REMOTEPROC is disabled.

include/linux/platform_data/remoteproc-omap.h:76:13: warning: symbol 'omap_rproc_reserve_cma' was not declared. Should it be static?

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'e476036' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: fix checkpatch errors in remoteproc code

This patch fixes relevant checkpatch errors and warnings
in the remoteproc source files.

Signed-off-by: Suman Anna <s-anna@ti.com>
[drop 80-char-lines checkpatch fixes and update commit log accordingly]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '5797115' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: fix error return code in rproc_fw_boot()

Set 'ret' to -EINVAL when needed, so a sensible return value
is returned on errors.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
[fix additional instances of this bug as well, update commit log]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '89970d2' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/davinci: add a remoteproc driver for OMAP-L13x DSP

Adding a new remoteproc driver for OMAP-L13x DSP

Signed-off-by: Robert Tivy <rtivy@ti.com>
[removed 'EXPERIMENTAL' and fixed some indentation issues]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '13be543' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: support default firmware name in rproc_alloc()

If rproc_alloc isn't given a firmware name, look for a default
one using the "rproc-%s-fw" template.

Signed-off-by: Robert Tivy <rtivy@ti.com>
[add commit log, document change, use snprintf, minor style change]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '8b4aec9' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/omap: support OMAP5 too

This allows building remoteproc on OMAP5 too.

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
[edit commit log]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'e5bc029' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: set vring addresses in resource table

Set the vring addresses in the resource table so that
the remote device can read the actual addresses used.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Ido Yariv <ido@wizery.com>
[rebase]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'c0d6315' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: support virtio config space.

Support virtio configuration space and device status. The virtio
device can now access the resource table in shared memory.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Ido Yariv <ido@wizery.com>
[rebase and style changes]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '92b38f8' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: perserve resource table data

Copy resource table from first to second firmware loading.
After firmware is loaded to memory, update the vdevs resource
pointer to the resource table kept in device memory.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Ido Yariv <ido@wizery.com>
[rebase, terminology and style changes]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'a2b950a' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>
Conflicts:
drivers/remoteproc/Kconfig

remoteproc: calculate max_notifyid by counting vrings

Simplify handling of max_notifyid by simply counting the
number of vrings.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Ido Yariv <ido@wizery.com>
[small terminology changes]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'ba7290e' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: code cleanup of resource parsing

Combine the almost identical functions rproc_handle_virtio_rsc
and rproc_handle_boot_rsc.

Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Acked-by: Ido Yariv <ido@wizery.com>
[small terminology and style changes]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit '232fcdb' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>