TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots

The remoteproc 'late attach' functionality has the remote processors
configured, programmed and booted early even before the kernel is booted.
This includes loading the necessary firmware into memory, programming the
IOMMU, configuring the required timers, and programming the corresponding
device's clocks and resets.

The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU1 & IPU2 processor subsystems to support the
'late attach' feature on these devices, and change the omap hwmod init
behavior. The corresponding memory regions are also removed from the
default kernel memory map (DMA pools instead of CMA pools) so that the
kernel doesn't access anything in these regions until the remoteprocs
are booted.

The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-idle-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).

These attributes are added in a new common dtsi file that should be
included into the corresponding TI DRA7xx and AM57xx boards that have
actually early-booted the IPU processors. This file _must_ be included
_only_ when both the IPU1 and IPU2 processors have been booted by
SPL/U-boot.

TODO:
Evaluate the approach where U-Boot can directly add/modify these required
properties using code. Such an approach would eliminate the need for
maintaining one or more dtsi files/overlays and make the support
self-contained within the bootloader.

Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

TEMP: remoteproc/omap: add "late attach" support

Add the necessary support in the OMAP remoteproc driver to enable the
"late attach" functionality. The 'late attach' functionality has the
processors already loaded and running by the time the kernel has booted.

The 'late attach' support in OMAP remoteproc driver is added through
minimal changes like skipping the releasing of the processor reset.
The processor reset is skipped as this relies on the omap_hwmod /
omap_device API which perform a module disable/enable sequence in
addition to the reset programming. Other required functionality is
achieved through the late attach support in the remoteproc driver core.

During late attach, we use non-zeroing dma ops to prevent the kernel
from overwriting already loaded code and data segments. When shutting
down the processor, we restore the normal zeroing dma ops.  This allows
the kernel to clear memory when loading a new remoteproc binary or
during error recovery with the current remoteproc binary.

The 'late attach' capability is determined through a .device_is_enabled
pdata ops. The rproc nodes along with the corresponding IOMMU and timer
nodes should all have the "ti,no-idle-on-init" and "ti,no-reset-on-init"
properties set to prevent omap_hwmod from resetting and idling these
devices on boot.

The .late_attach field in the rproc data structure is used to denote
the mode and differentiate a normal boot from a late-attach boot. The
late_attach functionality is relevant only for the first time boot of
the kernel, and will be reset for subsequent probes of the remoteproc
node. The flag is also reset during the stopping of the remoteproc,
so that any error recovery results in a regular boot.

TODO:
Move away from modifying the dma_ops for the device completely.

Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

TEMP: iommu/omap: add support for performing a "late attach"

The remoteproc module has a concept of "late attach" whereby a remote
core is loaded externally to remoteproc, for which remoteproc must
attach to the core without disrupting its existing state. Introduce an
iommu-based "late attach" model for the same use case.

In the "late attach" model, the iommu subsystem is mostly unused since
the external loader will have programmed the remote core's mmu, but
certain "attach" functionality must be performed so that subsequent
"detach" functionality can complete.

This logic is detected in the driver through a "ti,late-attach" property
set on the IOMMU node in the device tree. The IOMMU node should also have
the "ti,no-init-on-reset" and "ti,no-init-on-idle" so that the omap_hwmod
and omap_device layers do not reset and idle/disable the device during
the initial kernel boot. This "ti,late-attach" is therefore removed from
the device tree on the first probe so that further probes or remoteproc
recovery boots treat the IOMMU device normally.

Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Subash Lakkimsetti <x0091084@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs

Add a new .device_is_enabled() platform data callback ops to both
the OMAP IOMMU and remoteproc devices to check if the corresponding
omap_device/hwmod is already enabled. This helps the OMAP IOMMU and
remoteproc drivers to figure out if the corresponding processors
have already been loaded and booted by bootloaders.

Signed-off-by: Keerthy <j-keerthy@ti.com>
[s-anna@ti.com: minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

clocksource: timer-ti-dm: Add support to handle late attach of rproc timers

During late attach, the dmtimers used by remote processors would already
have been configured and running. To prevent the kernel from resetting or
reconfiguring the timers,

- Set the late attach parameter if the timer is already running.
- If late attach flag is set, increment the dmtimer's usage counter
  immediately on probe and maintain this state until remoteproc starts
  the timer. This prevents kernel power management functionality from
  idling and disabling the dmtimers.
- If late attach flag is set, also prevent the dmtimer configuration
  code from modifying the dmtimer registers.

The late attach flag in the omap_dm_timer structure is cleared on timer
start to allow normal operation to resume.

Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

TEMP: remoteproc: call the non-zeroing allocation function

For DMA pool scenario the plugged in allocation ops are not
used for carveout allocation. It is necessary to call a differnt
function that does not zero the DMA pool memory gotten from
the call to dma_alloc_coherent.

Call the dma_malloc_coherent (non-zeroing) api in the case
of late attach to guarantee that the memory is not zero-ed for
either a CMA or DMA pool. The memory for virtio rings is not
used in U-Boot, so need not use the non-zeroing function.

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: remoteproc: add "late attach" support

The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.

The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.

The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.

Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>

HACK: dma-mapping: add non-zeroing coherent alloc function

Add a new function, dma_malloc_from_coherent(), which
takes a parameter that specifies if the allocated memory
should be zero-ed or not. Modify dma_alloc_from_coherent
to call dma_malloc_from_coherent with the flag set to
true in order to zero the memory. In this way
dma_alloc_from_coherent behaves the same as before.

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

HACK: ARM: dma-mapping: create non-zeroing dma_map_ops

A new dma_ops, 'arm_dma_m_ops', is created from a copy of the
standard 'arm_dma_ops' but with a new non-zeroing .alloc method.

These ops are added mainly to support a 'late attach' feature in
the OMAP remoteproc driver. When remoteproc does a 'late attach'
to a remote processor, it does not load any firmware contents into
memory, but it still needs to allocate the processor's CMA memory
to mark the memory as reserved/used from the kernel. The standard
'arm_dma_ops' contains an .alloc method that zeroes out the memory,
thereby overwriting the firmware code/data in the memory that was
pre-loaded before the Linux kernel has booted.

This scenario is handled by adding a new non-zeroing allocation
function and using it as the .alloc method in a copy of the
'arm_dma_ops'. The so created 'arm_dma_m_ops' will be assigned
as the rproc device's dma_ops when supporting the 'late attach'
functionality.

Signed-off-by: Martin Ambrose <martin@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>

ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names

The commit 1cc71af030c6 ("ARM: dts: dra76-evm: Add CMA pools and enable
IPU & DSP rprocs") erroneously used the old CMA terminology in the DSP
and IPU rproc reserved memory node names and labels. Fix these and align
with the node names and labels used in all the other TI DRA7xx/AM57xx
board dts files.

Fixes: 1cc71af030c6 ("ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs")
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: dra72-evm-revc: Fix rproc reserved-memory labels and node names

The commit 896cb04007c3 ("ARM: dts: dra72-evm-revc: Add CMA pools and
enable IPUs & DSP1 rprocs") erroneously used the old CMA terminology in
the DSP1 & IPU rproc reserved memory node names and labels. Fix these
and align with the node names and labels used in all the other TI
DRA7xx/AM57xx board dts files.

Fixes: 896cb04007c3 ("ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs")
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc: Add a sysfs interface for name

[ Upstream commit 6ed756aa0148a5ad0dbdced6f14f22e2f5748d35 ]

This patch adds a sysfs interface that provides the name of the
remote processor to userspace. This allows the userspace to identify
a remote processor as the remoteproc devices themselves are created
based on probe order and can change from one boot to another or
at runtime.

The name is made available in debugfs originally, and is being
retained for now. This can be cleaned up after couple of releases
once users get familiar with the new interface.

[s-anna@ti.com: cherry-pick commit '6ed756aa0148' from v5.4]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Merge branch 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc into rproc-linux-4.19.y

Merge in the PRUSS topic branch into the base remoteproc feature branch
that pulls in a fix for properly clearing and configuring the PRUSS INTC
event-to-channel and channel-to-host interrupt mapping.

* 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix incorrect macro replacement
  irqchip/irq-pruss-intc: Fix erroneous channel/host mapping logic
  irqchip/irq-pruss-intc: Use macros for operations on CMR and HMR
  TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events
  irqchip/irq-pruss-intc: Reset chained handlers during cleanup

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

irqchip/irq-pruss-intc: Fix incorrect macro replacement

The commit 57c76b3f2804 ("irqchip/irq-pruss-intc: Use macros
for operations on CMR and HMR") mistakenly replaced the number
of channels per Host Interrupt Map Register (4) with the wrong
macro HMR_CH_MAP_BITS which is the number of shift-bits to be
used per channel. Use the correct macro to fix this typo.

Fixes: 57c76b3f2804 ("irqchip/irq-pruss-intc: Use macros for operations on CMR and HMR")
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Fix erroneous channel/host mapping logic

The PRUSS INTC uses two-levels of many-to-one mappings to route various
PRU System Events to a limited number of output interrupt lines connected
to various processors on the SoC. This event mapping configuration logic
is optimized to program the associated Channel Map Registers (CMRx) and
Host Interrupt Map Registers (HMRx) only when a new program is being
loaded/started and simply disables the same events and interrupt channels
without zeroing out the corresponding map registers when stopping a PRU.

The map logic currently does not zero out the previous field value before
programming the new value, and thereby potentially mapping a completely
different value in the CMR and HMR registers (if previous values are not
zero) and resulting in non-functional interrupts. Fix this erroneous
bitwise logic.

Reported-by: Nick Saulnier <nsaulnier@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>

irqchip/irq-pruss-intc: Use macros for operations on CMR and HMR

The PRUSS INTC configuration code is currently using hard-coded numbers
directly for performing arithmatic operations on the Channel Map Registers
(CMRs) and Host Interrupt Map Registers (HMRs). Introduce and replace
these numbers with human readable macros.

While at this, use the modulo operator instead of bitwise-and for
the bit offset computation for the events and channels in CMR and
HMR registers.

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

TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events

The PRUSS INTC irqchip implementation provides a standard IRQ API
for consumers to directly use the PRU System Events as interrupts
and uses chained interrupts for connecting these to the main ARM
GIC interrupt controller. Add support to the irqchip driver to set
irq affinity for these consumer PRU interrupts.

These consumer PRU interrupts are not directly connected to the ARM
GIC, so it is not possible to directly set the affinity for these
interrupts. The affinity is instead set on the real system irq or
the actual chained interrupt that the PRU event is mapped to. The
system irq is looked up using the programmed channel map and host
map registers, and is validated against the configured channel and
hosts as the channel map and host map registers are not reset in
pruss_intc_unconfigure().

NOTE:
1. The affinity for a PRU event can only be set after its channel
   map and host map are configured.
2. The PRUSS INTC design allows multiple events on a single system
   irq, so the actual affinity on the corresponding chained interrupt
   will be set to the last programmed affinity on any of the connected
   PRU events. The IRQ affinity data for other events is not updated.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: add error checks, update affinity logic & patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Reset chained handlers during cleanup

The PRUSS INTC irqchip implementation provides a standard IRQ API
for consumers to directly use the PRU System Events as interrupts
and uses chained interrupts for connecting these to the main ARM
GIC interrupt controllers. These chained irq handlers are not removed
at present during any failures in probe, or uninstalled in remove.

Reset these chained handlers so that the interrupts at the GIC
level are deactivated properly when the INTC devices are unbound
from the driver.

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

TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events

The PRUSS INTC irqchip implementation provides a standard IRQ API
for consumers to directly use the PRU System Events as interrupts
and uses chained interrupts for connecting these to the main ARM
GIC interrupt controller. Add support to the irqchip driver to set
irq affinity for these consumer PRU interrupts.

These consumer PRU interrupts are not directly connected to the ARM
GIC, so it is not possible to directly set the affinity for these
interrupts. The affinity is instead set on the real system irq or
the actual chained interrupt that the PRU event is mapped to. The
system irq is looked up using the programmed channel map and host
map registers, and is validated against the configured channel and
hosts as the channel map and host map registers are not reset in
pruss_intc_unconfigure().

NOTE:
1. The affinity for a PRU event can only be set after its channel
   map and host map are configured.
2. The PRUSS INTC design allows multiple events on a single system
   irq, so the actual affinity on the corresponding chained interrupt
   will be set to the last programmed affinity on any of the connected
   PRU events. The IRQ affinity data for other events is not updated.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: add error checks, update affinity logic & patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Reset chained handlers during cleanup

The PRUSS INTC irqchip implementation provides a standard IRQ API
for consumers to directly use the PRU System Events as interrupts
and uses chained interrupts for connecting these to the main ARM
GIC interrupt controllers. These chained irq handlers are not removed
at present during any failures in probe, or uninstalled in remove.

Reset these chained handlers so that the interrupts at the GIC
level are deactivated properly when the INTC devices are unbound
from the driver.

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

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

Merge in the updated iommu feature branch into remoteproc tree to
pull in a minor build fix seen when CONFIG_OMAP_IOMMU is not defined
and used with COMPILE_TEST.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Fix a typo in the public omap-iommu.h file

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

iommu/omap: Fix a typo in the public omap-iommu.h file

The commit b8ee97c59fb1 ("iommu/omap: introduce new API for
runtime suspend/resume control") has introduced two new functions
omap_iommu_domain_deactivate() & omap_iommu_domain_activate(),
and has also added their stubs to allow COMPILE_TEST of consumer
drivers using this header file. The return values in these stubs
used a wrong error value of ENOTSUP instead of ENOTSUPP. Fix this
typo. While at this, include the errno header file that defines
this macro as well to make the omap-iommu.h self-contained.

Fixes: b8ee97c59fb1 ("iommu/omap: introduce new API for runtime suspend/resume control")
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes

The watchdog timer information has been added to all the IPU and DSP
remote processor device nodes in the DRA7xx/AM57xx SoC families. The
data has been added to the two common dra7-ipu-dsp-common and
dra74-ipu-dsp-common dtsi files that can be included by all the
desired board files. The following timers are chosen as the watchdog
timers, as per the usage on the current firmware images:
        IPU2: GPTimers 4 & 9 (one for each Cortex-M4 core)
        IPU1: GPTimers 7 & 8 (one for each Cortex-M4 core)
        DSP1: GPTimer 10
        DSP2: GPTimer 13

Each of the IPUs has two Cortex-M4 processors and so uses a timer
each for providing watchdog support on that processor irrespective of
whether the IPU is running in SMP-mode or non-SMP node. The chosen
timers also need to be unique from the ones used by other processors
(regular timers or watchdog timers) so that they can be supported
simultaneously.

The MPU-side drivers will use this data to initialize the watchdog
timer(s), and listen for any watchdog triggers. The BIOS-side code on
these processors needs to configure/refresh the corresponding timer
properly to not throw a watchdog error.

The watchdog timers are optional in general, but are mandatory to
be added to support watchdog error recovery on a particular processor.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

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

ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP

The watchdog timers have been added for the IPU and DSP remoteproc
devices for the OMAP5 uEVM board. The following timers (same as the
timers on OMAP4 Panda boards) are used as the watchdog timers,
        DSP : GPT6
        IPU : GPT9 & GPT11 (one for each Cortex-M4 core)

The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.

These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

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

ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP

The watchdog timers have been added for the IPU and DSP remoteproc
devices on all the OMAP4-based Panda boards. The following timers
are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M3 core)

The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.

These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

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: fix auto-suspend failure warning during crashed state

The runtime autosuspend on a OMAP remoteproc device is attempted when
the suspend timer expires (autosuspend delay elapsed since the last
time the device is busy). This is the normal autosuspend scenario
for a device functioning normally. This timer can also expire during
the debugging of a remoteproc crash when the remoteproc recovery is
disabled. This is an invalid pre-condition though, so check for the
RPROC_CRASHED state and bail out before the actual check for the
RPROC_RUNNING state. The auto-suspend is also not re-attempted until
the remoteproc is recovered and restored to normal functional state.

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

remoteproc: fix multiple back-to-back error recoveries

The remoteproc core uses a dedicated work item per remote processor
to perform an error recovery of that processor. This work item is
always scheduled upon notification of an error at the moment. The
error recovery process itself is performed when the workqueue gets
scheduled and executes the work function, but an error recovery
needs to be performed only once if there are multiple notifications
while an existing error recovery is in progress. Fix this by adding
a check to make sure the remote processor error recovery work item
is not already running or scheduled.

This fixes an issue with error recovery upon MMU Faults on OMAP
IPU remote processors. An MMU fault on OMAP IPU sends two error
notifications - one a direct interrupt from the MMU, and the second
a mailbox-based crash notification after the remote processor has
collected some backtrace. The mailbox based interrupt mechanism,
added in commit 7f275d21e240 ("remoteproc/omap: report device
exceptions and trigger recovery"), is used for Attribute MMU (AMMU)
faults and other internal exceptions on the IPU. The backtrace
collection on the IPU remote processor is triggered by the same
interrupt which cannot be differentiated between an MMU fault and
an AMMU fault. The remoteproc core changes in 4.9 kernel around the
boot sequences has now caused the second notification to trigger a
secondary error recovery, which was avoided in previous kernels due
to the event detection in the work-function itself. The newer code
sequences changes the timing w.r.t previous kernels where the
recovery process was performed a bit later due to the asynchronous
firmware loading.

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: 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 traceY_last
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copied contents 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>

Revert "remoteproc: Introduce rproc_{start,stop}() functions"

This reverts commit 1efa30d0895e7e9a58a59b0880b330b38245be68.

The commit 1efa30d0895e ("remoteproc: Introduce rproc_{start,stop}()
functions") has refactored code out from rproc_boot() and rproc_shutdown()
to optimize resource allocation overheads during the recovery. This
patch was made with an implicit assumption that the same firmware
image will always be used during recovery (rightfully so in a product
environment), and so the resources will also remain the same. The patch
had also changed the rproc state to RPROC_OFFLINE prior to cleaning up
all resources and disabling the MMU in rproc_shutdown(). This does not
play nice with doing any additional processing steps during recovery
in the resource cleanup function.

This patch is a custom revert of the above commit, accounting for all
the changes added to the rproc_start() and rproc_stop() functions since
kernel v4.13 and some additional changes added in commit 20afed1b45bf
("remoteproc: add infrastructure support to allow pre-loaded remoteprocs")
and commit 2794d1693b05 ("remoteproc: Add support to handle device
specific resource types") thereby allowing a new last trace mechanism
to be supported in a subsequent patch.

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

Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"

This reverts commit 7e83cab824a86704cdbd7735c19d34e0ce423dc5.

The commit 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()") has modified the rproc_trigger_recovery()
function to leverage rproc_stop() and rproc_start() functions
introduced in commit 1efa30d0895e ("remoteproc: Introduce
rproc_{start,stop}() functions") in place of the previous usage
of rproc_shutdown() and rproc_boot() functions. These new functions
execute only a portion of the previous functions, and are primarily
designed to optimize the allocation of memory resources. They do
not handle other resources like virtio devices and the resetting
of any IOMMUs. The new functions also do not re-initialize the
memory used by the firmware image sections during recovery. This
results in a kernel crash like below when performing error recovery
on remoteprocs using both MMUs and virtio devices like the OMAP
remoteproc driver.

  omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
  omap-iommu 55082000.mmu: iommu fault: da 0x8004cc60 flags 0x0
  remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
  omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x8004cc60 pgd:0x63ed70cb *pgd:px95f00002
  remoteproc remoteproc1: handling crash #1 in 55020000.ipu
  remoteproc remoteproc1: recovering 55020000.ipu
  omap-rproc 55020000.ipu: omap rproc 55020000.ipu crashed
  remoteproc remoteproc1: stopped remote processor 55020000.ipu
  kobject (44f48dcd): tried to init an initialized object, something is seriously wrong.
  CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 4.19.0-00420-gd9f97bb86434 #658
  Hardware name: Generic DRA74X (Flattened Device Tree)
  Workqueue: events rproc_crash_handler_work [remoteproc]
  [<c0114224>] (unwind_backtrace) from [<c010e618>] (show_stack+0x10/0x14)
  [<c010e618>] (show_stack) from [<c09585c8>] (dump_stack+0xb0/0xe8)
  [<c09585c8>] (dump_stack) from [<c095cec0>] (kobject_init+0x78/0x94)
  [<c095cec0>] (kobject_init) from [<c06224bc>] (device_initialize+0x20/0xf0)
  [<c06224bc>] (device_initialize) from [<bf0003d4>] (register_virtio_device+0x1c/0x110 [virtio])
  [<bf0003d4>] (register_virtio_device [virtio]) from [<bf02bf34>] (rproc_add_virtio_dev+0x44/0xa0 [remoteproc])
  [<bf02bf34>] (rproc_add_virtio_dev [remoteproc]) from [<bf028744>] (rproc_start+0x1c8/0x264 [remoteproc])
  [<bf028744>] (rproc_start [remoteproc]) from [<bf02acac>] (rproc_trigger_recovery+0x28c/0x2dc [remoteproc])
  [<bf02acac>] (rproc_trigger_recovery [remoteproc]) from [<c015d438>] (process_one_work+0x2ac/0x788)
  [<c015d438>] (process_one_work) from [<c015d940>] (worker_thread+0x2c/0x584)
  [<c015d940>] (worker_thread) from [<c0164648>] (kthread+0x140/0x15c)
  [<c0164648>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
  ... exception stack dump ...
  virtio_rpmsg_bus virtio1: rpmsg host is online
  driver_bound: device virtio1 already bound
  remoteproc remoteproc1: registered virtio1 (type 7)
  remoteproc remoteproc1: remote processor 55020000.ipu is now up
  Unable to handle kernel NULL pointer dereference at virtual address 00000004

Revert the above commit to fix/restore the error recovery functionality.
This patch is a custom revert of the above commit, accounting for some
additional changes done in commit 2666ca9197e3 ("remoteproc: Add remote
processor coredump support"). The coredump function is invoked in
rproc_stop() now.

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

Revert "remoteproc: Remove depricated crash completion"

This reverts commit b26210cda63564a7478486faaea713f6ea965633.

The commit b26210cda635 ("remoteproc: Remove depricated crash completion")
has dropped the crash_comp completion variable as it was not needed after
the rproc_trigger_recovery() function was modified to leverage rproc_stop()
and rproc_start() functions in commit 7e83cab824a8 ("remoteproc: Modify
recovery path to use rproc_{start,stop}()"). These new functions execute
only a portion of the previous functions, and break the error recovery
on OMAP remoteproc devices.

Reintroduce the crash completion variable by reverting the above commit
in preparation for reverting the error recovery logic to not use the
rproc_start() and rproc_stop() functions.

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

remoteproc: Fix sysfs interface to stop a suspended processor

Commit 2aefbef04149 ("remoteproc: Add a sysfs interface for
firmware and state") has added an interface to be able to stop
a remote processor, change the firmware and start the remote
processor using the new firmware through the sysfs files 'state'
and 'firmware'. Any firmware change requires the processor to be
in a stopped state. The logic in 'stop' checks for a valid state
(RPROC_RUNNING) before a processor can be stopped. A booted remote
processor though can also be in RPROC_SUSPENDED state if the driver
controlling the device supports runtime auto-suspend, and any
attempt to stop such a processor throws an error,
"write error: Invalid argument".

It should be possible to stop a processor that is in suspended
state using the sysfs entry, as this is a perfectly functional
scenario when either removing the module, or unbinding the device
from the driver. Fix the sysfs logic to permit the same.

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

remoteproc/omap: add support for runtime auto-suspend/resume

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

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

remoteproc/omap: add support for system suspend/resume

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.

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

ARM: dts: dra7: Add standby info for IPU & DSPs

Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.

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

ARM: dts: omap5: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.

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

ARM: dts: omap4: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.

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

dt-bindings: remoteproc: Update omap remoteproc binding for suspend

The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.

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

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

Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
   - improvements in the OMAP iommu to perform the enabling &
     disabling of the IOMMU from within the runtime pm callbacks
   - system suspend/resume support through late dev_pm_ops
   - two new API that needs to be invoked from the OMAP remoteproc
     driver to runtime suspend/resume the IOMMU
   - locked TLB save & restore logic
   - add needed pdata quirks to all supported IOMMUs

Suspend/resume support in the OMAP mailbox driver is already supported
in baseline upstream kernel.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: introduce new API for runtime suspend/resume control
  iommu/omap: Add system suspend/resume support
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

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

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

Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue and
couple of DRA7 DSP idle issues with HW_AUTO setting. The DSP idle
status is achieved across all the DSPs and boards only with the
fix for errata i879.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
  ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
  ARM: OMAP2+: Use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: Fix boot issue on remoteprocs with AMMU/Unicache

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

ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on the AM571x IDK board. These nodes are assigned
to the respective rproc device nodes, and both the IPUs and the DSP1
remote processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices in the am572x-idk-common.dtsi file that is common to
both the AM572x and AM574x IDK boards. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on
the AM57xx EVM board to maintain firmware compatibility between the
two boards. The CMA pools and sizes are defined using 64-bit values
to support LPAE. The starting addresses are fixed to meet current
dependencies on the remote processor firmwares, and this will go
away when the remote-side code has been improved to gather this
information runtime during its initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on all the AM57xx BeagleBoard-X15 boards. These nodes
are assigned to the respective rproc device nodes, and all the IPU and
DSP remote processors are enabled for all these boards.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and
the DSP remoteproc devices on the DRA76 EVM board, and assigned to
the respective rproc device nodes. These match the configuration
used on the DRA7 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA76 EVM board.

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

ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA71 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and
the DSP1 remoteproc devices on the DRA72 EVM rev C board, and assigned
to the respective rproc device nodes. These match the configuration
used on the DRA72 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA72 EVM rev C board.

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

ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA72 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on DRA7 EVM board. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

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

ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes

The BIOS System Tick timers have been added for all the IPU and
DSP remoteproc devices in the DRA7 SoC family. The data is added
to the two common dra7-ipu-dsp-common and dra74-ipu-dsp-common
dtsi files that are included by all the desired board files. The
following timers are chosen, as per the timers used on the current
firmware images:
        IPU2: GPTimer 3
        IPU1: GPTimer 11
        DSP1: GPTimer 5
        DSP2: GPTimer 6

The timers are optional, but are mandatory to support advanced device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, if needed.

Each of the IPUs has two Cortex-M4 processors, and is currently
expected to be running in SMP-mode, so only a single timer suffices
to provide the BIOS tick timer. An additional timer should be added
for the second processor in IPU if it were to be run in non-SMP mode.
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: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes

Add the required 'mboxes' property to all the IPU and DSP remote
processors (IPU1, IPU2, DSP1 and DSP2) in the two available common
dtsi files - dra7-ipu-dsp-common and dra74-ipu-dsp-common dtsi files.
The latter file is for platforms having DRA74x/DRA76x/AM572x/AM574x
SoCs which do have a DSP2 processor in addition to the other common
remote processors. The common data is added to the former file, and
the DSP2 only data is added to the latter file.

The mailboxes are required for running the Remote Processor Messaging
(RPMsg) stack between the host processor and each of the remote
processors. Each of the remote processors uses a single sub-mailbox
node, the IPUs are assumed to be running in SMP-mode. The chosen
sub-mailboxes match the values used in the current firmware images.
This can be changed, if needed, as per the system integration needs
after making appropriate changes on the firmware side as well.

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

ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files

The System Mailboxes 5 and 6 and their corresponding child sub-mailbox
(IPC 3.x) nodes are enabled in each of the DRA7xx and AM57xx board
dts files individually at present. These mailboxes enable the Remote
Processor Messaging (RPMsg) communication stack between the MPU host
processor and each of the IPU1, IPU2, DSP1 and DSP2 remote processors.

Move these nodes into two common dtsi files - dra7-ipu-dsp-common and
dra74-ipu-dsp-common files, which are then included in various board
dts files. These files can be used to add all the common configuration
properties (except memory data) required by remote processor nodes.
The memory pools and the remote processor nodes themselves are to be
enabled in the actual board dts files. The first file is to used by
platforms using DRA72x/DRA71x/AM571x/AM570x SoCs, and the second file
is to be used by platforms using DRA74x/DRA76x/AM572x/AM574x SoCs.
The second file includes the first file and contains additional data
only applicable for DSP2 remote processor.

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

ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x

The pdata quirks for the DSP2 remote processor device, present
usually on DRA74x SoCs, has been added. The DSP2 remote processor
is another identical instance as the DSP1 remote processor, and
the required quirks are identical to the rest of the remote
processors on DRA7xx.

The pdata quirks will be removed once the dependencies against
the arch/arm layers are resolved.

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

ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7

The remote processors on DRA7xx requires similar device management
pdata-quirks (reset control, clocking, dmtimer API wrappers for
enabling both system and watchdog timers) as the IPU and DSP
processors on OMAP4/OMAP5. All these pdata ops are identical to
the ones used on OMAP4/OMAP5, so extend the existing rproc pdata
quirks to the most common remote processor subsystems on DRA7xx
family of SoCs - IPU1, IPU2 and DSP1.

The pdata quirks need to match the starting address in the auxdata
for the respective processors, as the same compatible string is used
for all the instances of the remote processor of the same type. The
pdata quirks will be removed once the dependencies against arch/arm
layers are resolved.

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

ARM: DRA7: hwmod_data: add data for DSP2 processor

The DRA7xx family of SoCs can have up to two identical DSP
processor subsystems, with most of them having a single DSP
processor subsystem. The second DSP is present only on DRA74x
variants currently. The relevant hwmod class and data structures
are added for this second DSP only for DRA74x SoC variants.
The hwmod data for this DSP2 is very similar to the data on
DSP1.

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

ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs

The DRA7xx family of SoCs usually have two IPU and up to two DSP
remote processor subsystems. These subsystems are very similar to
the respective processor subsystems on OMAP4/OMAP5 in terms of clock
and reset integration. The relevant hwmod classes and data structures
are added for IPU1, IPU2 and DSP1 remoteproc devices, the most common
processors present on all DRA7xx SoCs.

Do note that these hwmod data structures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. 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: dts: dra72x: Add aliases for rproc nodes

Add aliases for all the 3 remote processor nodes common to
all DRA72x/DRA71x/AM571x/AM570x boards. The aliases uses the
stem "rproc", and are defined in the order of the most common
processors on the DRA72x family. The ids are same as DRA74x
except for the missing DSP2.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

ARM: dts: dra74x: Add aliases for rproc nodes

Add aliases for all the IPU and DSP remoteproc processor
nodes common to all DRA74x/DRA76x/AM572x/AM574x boards.
The aliases uses the stem "rproc". The aliases are defined
in the order of the most common processors on the DRA74x
family.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

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

ARM: dts: dra74x: Add DSP2 processor device node

The DRA7xx family of SoCs can contain upto two identical DSP
processor subsystems. The second DSP processor subsystem is
present only on the DRA74x/DRA76x variants. The processor
device DT node has therefore been added in disabled state for
this processor subsystem in the DRA74x specific DTS file.

NOTE:
1. The node does not have any mailboxes, timers or CMA region
   assigned, they should be added in the respective board dts
   files.
2. The node should also be enabled as per the individual product
   configuration in the corresponding board dts files.

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

ARM: dts: dra7: Add common IPU and DSP nodes

The DRA7xx family of SOCs have two IPUs and upto two DSP
processor subsystems in general. The IPU processor subsystem
contains dual-core ARM Cortex-M4 processors, while the DSP
processor subsystem is based on the TI's standard TMS320C66x
DSP CorePac core. The IPUs are very similar to those on OMAP5.

Two IPUs and one DSP processor subsystems is the most common
configuration. The processor device DT nodes have been added
for these processor subsystems, with the internal memories
added through 'reg' and 'reg-names' properties. The IPUs only
have an L2 RAM, whereas the DSPs have L1P, L1D and L2 RAM
memories.

NOTE:
1. The nodes do not have any mailboxes, timers or CMA regions
   assigned, they should be added in the respective board dts
   files.
2. The nodes haven been disabled by default and the enabling
   of these nodes is also left to the respective board dts
   files.

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

ARM: dts: omap5-uevm: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices for the OMAP5 uEVM boards. The following timers
(same as the timers on OMAP4 Panda boards) are chosen:
        IPU : GPT3 (SMP-mode)
        DSP : GPT5

IPU has two Cortex-M4 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

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

ARM: dts: omap5-uevm: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for the OMAP5 uEVM board.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

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

ARM: dts: omap5-uevm: Add CMA reserved memory nodes for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on OMAP5 uEVM board. 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
firmwares, and will go away when the remote-side code has been
improved to gather this information runtime during its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

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

ARM: OMAP2+: Extend OMAP4 IPU/DSP pdata-quirks to OMAP5

OMAP5 requires the same device management pdata-quirks as OMAP4
for the IPU and DSP processor subsystems, so extend the OMAP4 IPU
and DSP pdata quirks to OMAP5 as well.

The pdata quirks uses the appropriate starting addresses in the
auxdata as per the current DT node definitions to find the devices
to add the necessary quirks as platform data. The pdata quirks will
be removed once the reset dependencies against omap_device and
omap_hwmod layers are resolved.

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

ARM: OMAP5: hwmod_data: add data for IPU & DSP processors

OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
The relevant hwmod classes and data structures are added for these
devices.

Do note that these hwmod data strucutures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. 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: dts: omap5: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP5 boards. The aliases uses
the stem "rproc", and are identical to the values
chosen on OMAP4 boards.

The aliases can be overridden, if needed, in the
respective board files.

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

ARM: dts: omap5: Add DSP and IPU nodes

OMAP5, like OMAP4, also has two remote 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 set of features. Add the
DT nodes for these two processor sub-systems for all OMAP5
SoCs.

The nodes have the 'iommus' and 'mboxes' properties added,
and are disabled for now. The IPU node has its L2 RAM memory
specified through the 'reg' and 'reg-names' properties. The
DSP node doesn't have these since it doesn't have any L2
RAM memories, but has an additional 'syscon-bootreg' property
instead as it has a specific boot register that needs to be
programmed for booting.

These nodes should be enabled as per the individual product
configuration in the corresponding board dts files.

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: dts: omap4-panda-common:: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. The
following DMTimers are chosen:
IPU : GPT3 (SMP-mode)
DSP : GPT5

IPU has two Cortex-M3 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

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

ARM: dts: omap4-panda-common: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for all the OMAP4-based Panda boards.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

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

ARM: dts: omap4-panda-common: Add CMA reserved pools for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. 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 firmwares, and will go away when the remote-side
code has been improved to gather this information runtime during
its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

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

ARM: OMAP2+: Add pdata-quirks for DSP and IPU remoteprocs

The OMAP remoteproc driver performs the device management (reset
control and clocking) for the remote processor sub-systems using
the omap_device API which are limited to only the mach-omap layer.
The OMAP mechanism of using pm_runtime API to achieve this is
insufficient as these devices have hard reset lines which are
managed separately. Use pdata quirks to manage the device reset
and clocking functionality through platform data ops, until the
reset portions are decoupled from omap_hwmod/omap_device into a
separate reset driver.

This patch adds the pdata quirks for both the DSP and IPU processor
subsystems on OMAP4, matching with the current DT node definitions
to find the devices to add platform data. The pdata quirks do not
use a starting address in the auxdata for the DSP device though as
it doesn't have any L2 RAM memory (and so no 'reg' value/address
for the device).

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

ARM: dts: omap4: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP4 boards. The aliases uses
the stem "rproc".

The aliases can be overridden, if needed, in the
respective board files.

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

ARM: dts: omap4: Add IPU DT node

The DT node for the Dual-Cortex M3 IPU processor sub-system
has been added for OMAP4 SoCs. The L2RAM memory region
information has been added to the node through the 'reg'
and 'reg-names' properties. The node has the 'iommus' and
'mboxes' properties also added, and is disabled for now. It
should be enabled as per the individual product configuration
in the corresponding board dts files.

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

ARM: dts: omap4: Update the DSP node

The compatible property for the DSP node is updated to match
the OMAP remoteproc bindings. The node is moved from the soc
node to the ocp node, as this is better suited to use with
pdata-quirks.

The node is updated with the 'syscon-bootreg', 'iommus' and
'mboxes' properties. Note that the node does not have any
'reg' or 'reg-names' properties since it doesn't have any
L2 RAM memory, but only Unicaches.

The node is disabled for now, and should be enabled as per
the individual product configuration in the corresponding
board dts files.

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

remoteproc/omap: add a trace to print missing alias ids

The alias ids for OMAP remoteprocs are required by some
rpmsg client drivers to identify a remote processor in
a fixed manner to userspace. Add a trace during probe
to warn developers if the alias id is not defined for a
remoteproc DT node.

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

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

The remote processors in OMAP4+ SoCs 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 OMAP 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 OMAP remote processors to request
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 core timer functionality is provided by the OMAP DMTimer
clocksource driver, which does not export any API. The logic is
implemented through the timer device's platform data ops. The OMAP
remoteproc driver mainly requires ops to request/free a dmtimer,
and to start/stop a timer. The split ops helps in controlling the
timer state without having to request and release a timer everytime
it needs to use the timer.

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>

remoteproc/omap: Check for undefined mailbox messages

Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

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

remoteproc/omap: Remove the omap_rproc_reserve_cma declaration

The omap_rproc_reserve_cma() function is not defined at the moment.
This prototype was to be used to define a function to declare a
remoteproc device-specific CMA pool.

The remoteproc devices will be defined through DT going forward. A
device specific CMA pool will be defined under the reserved-memory
node, and will be associated with the appropriate remoteproc device
node. This function prototype will no longer be needed and has
therefore been cleaned up.

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

remoteproc/omap: Remove the unused fields from platform data

The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
.firmware, .ops and .set_bootaddr, are removed from the platform data,
as these are no longer needed after the addition of DT support to the
OMAP remoteproc driver.

The .name field was used to give a name to the remoteproc, and this
is replaced with the device name. The .ops field was never used by
the OMAP remoteproc driver. The .mbox_name was used to define the
sub-mailbox node used for communication with the remote processor,
and is retrieved using the 'mboxes' property in the DT node. The
.firmware field is encoded directly in the OMAP remoteproc driver and
is retrieved using driver match data. The .set_bootaddr ops was used
for using a OMAP Control Module API to configure the boot address for
the processor, and is now implemented within the driver using a
syscon property.

The .oh_name field is used to define the primary hwmod for the processor
node, and is represented using the 'ti,hwmods' property in the DT node.
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
representing both the processors in the IPU sub-system is defined.
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.

The OMAP remoteproc platform data structure is eventually expected
to be removed completely once the other dependencies with the
mach-omap layer are met.

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

remoteproc/omap: Add support for DRA7xx remote processors

DRA7xx/AM57xx SoCs have two IPU and up to two DSP processor subsystems
for offloading different computation algorithms. The IPU processor
subsystem contains dual-core ARM Cortex-M4 processors, and is very
similar to those on OMAP5. The DSP processor subsystem is based on
the TI's standard TMS320C66x DSP CorePac core.

Support has been added to the OMAP remoteproc driver through new
DRA7xx specific compatibles for properly probing and booting the
all the different processor subsystem instances on DRA7xx/AM57xx
SoCs - IPU1, IPU2, DSP1 & DSP2. A build dependency with SOC_DRA7XX
is added to enable the driver to be built in DRA7xx-only configuration.

The DSP boot address programming needed enhancement for DRA7xx as the
boot register fields are different on DRA7 compared to OMAP4 and OMAP5
SoCs. The register on DRA7xx contains additional fields within the
register and the boot address bit-field is right-shifted by 10 bits.
The internal memory parsing logic has also been updated to compute
the device addresses for the L2 RAM for DSP devices using relative
addressing logic, and to parse two additional RAMs at L1 level - L1P
and L1D. This allows the remoteproc driver to support loading into
these regions for a small subset of firmware images requiring as
such. The most common usage would be to use the L1 programmable
RAMs as L1 Caches.

The firmware lookup logic also has to be adjusted for DRA7xx as
there are (can be) more than one instance of both the IPU and DSP
remote processors for the first time in OMAP4+ SoCs.

The names for the firmware images are fixed for each processor and
are expected to be as follows:
IPU1: dra7-ipu1-fw.xem4
IPU2: dra7-ipu2-fw.xem4
DSP1: dra7-dsp1-fw.xe66
DSP2: dra7-dsp2-fw.xe66

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

remoteproc/omap: Initialize and assign reserved memory node

The reserved memory nodes are not assigned to platform devices by
default in the driver core to avoid the lookup for every platform
device and incur a penalty as the real users are expected to be
only a few devices.

OMAP remoteproc devices fall into the above category and the OMAP
remoteproc driver _requires_ specific CMA pools to be assigned
for each device at the moment to align on the location of the
vrings and vring buffers in the RTOS-side firmware images. So,
use the of_reserved_mem_device_init/release() API appropriately
to assign the corresponding reserved memory region to the OMAP
remoteproc device. Note that only one region per device is
allowed by the framework.

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

remoteproc/omap: Add the rproc ops .da_to_va() implementation

An implementation for the rproc ops .da_to_va() has been added
that provides the address translation between device addresses
to kernel virtual addresses for internal RAMs present on that
particular remote processor device. The implementation provides
the translations based on the addresses parsed and stored during
the probe.

This ops gets invoked by the exported rproc_da_to_va() function
and allows the remoteproc core's ELF loader to be able to load
program data directly into the internal memories.

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

remoteproc/omap: Add support to parse internal memories from DT

The OMAP remoteproc driver has been enhanced to parse and store
the kernel mappings for different internal RAM memories that may
be present within each remote processor IP subsystem. Different
devices have varying memories present on current SoCs. The current
support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
L2 RAM memories.

IPUs are expected to have the L2RAM at a fixed device address of
0x20000000, based on the current limitations on Attribute MMU
configurations.

NOTE:
The current logic doesn't handle the parsing of memories for DRA7
remoteproc devices, and will be added alongside the DRA7 support.

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

remoteproc/omap: Add a sanity check for DSP boot address alignment

The DSP remote processors on OMAP SoCs require a boot register to
be programmed with a boot address, and this boot address needs to
be on a 1KB boundary. The current code is simply masking the boot
address appropriately without performing any sanity checks before
releasing the resets. An unaligned boot address results in an
undefined execution behavior and can result in various bus errors
like MMU Faults or L3 NoC errors. Such errors are hard to debug and
can be easily avoided by adding a sanity check for the alignment
before booting a DSP remote processor.

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

remoteproc/omap: Add device tree support

OMAP4+ SoCs support device tree boot only. The OMAP remoteproc
driver is enhanced to support remoteproc devices created through
Device Tree, support for legacy platform devices has been
deprecated. The current DT support handles the IPU and DSP
processor subsystems on OMAP4 and OMAP5 SoCs.

The OMAP remoteproc driver relies on the omap_device, omap_hwmod
and control module layers for performing clock, reset and boot
vector management (DSP remoteprocs only) of the devices, but
some of these are limited only to the machine-specific layers
in arch/arm. The dependency against control module API for boot
vector management of the DSP remoteprocs has now been removed
with added logic to parse the boot register from the DT node
and program it appropriately directly within the driver.

The dependency on omap_device API for clock and reset control
remains though and is to be achieved through OMAP rproc specific
platform data ops, and the required implementations to boot and
shutdown have been added in the machine layer. These need to be
plugged in to the remoteproc devices through pdata quirks, for
properly booting the remote processors.

The OMAP remoteproc driver expects the firmware images to have
fixed names. This used to be defined through platform data
previously, and are now coded into the driver. The following
names are to be expected of the firmwares,
OMAP4 - IPU: omap4-ipu-fw.xem3
        DSP: omap4-dsp-fw.xe64T
OMAP5 - IPU: omap5-ipu-fw.xem4
        DSP: omap5-dsp-fw.xe64T

Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: remoteproc: Add OMAP remoteproc bindings

Add the device tree bindings document for the IPU and DSP
remote processor devices on OMAP4+ SoCs.

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

remoteproc/omap: Switch to SPDX license identifiers

Use the appropriate SPDX license identifiers in various OMAP remoteproc
source files and drop the previous boilerplate license text.

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

ARM: dts: dra7: Fix functional clocks for DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.

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

ARM: dts: omap5: Fix functional clocks for DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.

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

ARM: dts: omap4: Fix functional clocks for ABE DMTimer devices

The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.

The dmtimer clocksource driver cannot use this clock to configure
its parents. All the DMTimer nodes except for those present in the
ABE domain have been converted to the new ti-sysc node hierarchy
style and do not face this issue. The dmtimer consumers got lucky
so far due to the default clock matching the requested parent clock,
and a silent successful return in the omap_dm_timer_set_source()
function. Fix the remaining DMTimer nodes in ABE domain by adding
the actual mux clocks to the DMTimer nodes with the "fck" clock-name.
These clocks are expected to remain even after the nodes have moved
under a ti,sysc parent node.

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

clocksource: timer-ti-dm: Drop bogus omap_dm_timer_of_set_source()

The function omap_dm_timer_of_set_source() was originally added in
commit 31a7448f4fa8a ("ARM: OMAP: dmtimer: Add clock source from DT"),
and is designed to set a clock source from DT using the clocks property
of a timer node. This is a bad design as typically the clocks property
is used to specify the functional clocks for a device, and not its
parents.

The commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to
probe them with ti-sysc") adds a timer functional clock property to
almost all the timer nodes (except for GPTimers 5, 6, 7, 8 in ABE
domain) on OMAP4 SoCs and this results in an attempt to set the same
functional clock as its parent when a consumer driver attempts to
acquire any of these timers in the omap_dm_timer_prepare() function.
The resulting failure (-EINVAL) also prevents a fallback to the
omap_dm_timer_set_source() function. Fix this by simply dropping
this incorrect logic.

Any DT configuration of clock sources should be achieved using
assigned-clocks and assigned-clock-parents properties provided
by the Common Clock Framework.

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

clk: ti: dra7: Add back timer_sys_ck clock aliases

The commit a8202cd5174d ("clk: ti: dra7: drop unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: a8202cd5174d ("clk: ti: dra7: drop unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: omap5: Add back timer_sys_ck clock aliases

The commit d41e53040926 ("clk: ti: omap5: cleanup unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: d41e53040926 ("clk: ti: omap5: cleanup unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: omap4: Add back timer_sys_ck clock aliases

The commit 1c7de9f27a65 ("clk: ti: omap4: cleanup unnecessary clock
aliases") has cleaned up all timer_sys_ck clock aliases and retained
only the timer_32k_ck clock alias. The OMAP clocksource timer driver
though still uses this clock alias when reconfiguring the parent
clock source for the timer functional clocks, so add these aliases
back for all the timers.

This is required by the OMAP remoteproc driver to successfully
acquire a timer and configure the source clock to be driven from
timer_sys_ck clock.

Fixes: 1c7de9f27a65 ("clk: ti: omap4: cleanup unnecessary clock aliases")
Signed-off-by: Suman Anna <s-anna@ti.com>

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

Pull in the iommu tree into the remoteproc tree, since this is a minimum
for bringing up the OMAP remote processors successfully. This iommu merge
pulls in couple of minor cleanups and the basic OMAP IOMMU driver support
for all the IPU and DSP MMUs present on DRA7xx/AM57xx SoC families. The
merge includes fixes to restore the functionality on OMAP4 and OMAP5 SoCs
due to the clkctrl changes, and also adds the clkctrl clocks and nodes for
DRA7 remote processors. The MMUs are enabled in the common base dra7 dts
files, so are supported on all applicable DRA7xx/AM57xx boards automatically.

The base support for IPU and DSP MMUs on OMAP4 and OMAP5 SoC families, and
the necessary DPLL clock configuration of the clocks required for various
remoteproc devices on OMAP4/OMAP5 and DRA7 SoCs are all upstream.

* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
  ARM: dts: dra74x: Enable DSP2 IOMMU nodes
  ARM: dts: dra7: Enable common IPU and DSP IOMMU nodes
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA74x DSP2
  ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs & DSP1
  ARM: DRA7: hwmod data: Add MMU data for DSPs
  ARM: DRA7: hwmod data: Add MMU data for IPUs
  ARM: dts: dra7: Add clkctrl nodes for IPU and DSP remote processors
  clk: ti: dra7: add clkctrl data for remote processor clocks
  dt-bindings: clk: add dra7 remotecore clkctrl definitions
  clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
  clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
  ARM: OMAP2+: hwmod_core: improve the support for clkctrl clocks
  iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN
  iommu/omap: Remove DEBUG_SEQ_FOPS_RO()

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

iommu/omap: introduce new API for runtime suspend/resume control

This patch adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by introducing two new API,
omap_iommu_domain_deactivate() and omap_iommu_domain_activate()
to allow the client users/master devices of the IOMMU devices to
deactivate & activate the IOMMU devices from their runtime
suspend/resume operations. There is no API exposed by the IOMMU
layer at present, and so these new API are added directly in the
OMAP IOMMU driver to minimize framework changes.

The API simply decrements and increments the runtime usage count
of the IOMMU devices and let the context be saved/restored using
the existing runtime pm callbacks.

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

iommu/omap: Add system suspend/resume support

The MMU registers for the remote processors lose their context
in Open Switch Retention (OSWR) or device OFF modes. Hence, the
context of the IOMMU needs to be saved before it is put into any
of these lower power state (OSWR/OFF) and restored before it is
powered up to ON again. The IOMMUs need to be active as long as
the client devices that are present behind the IOMMU are active.

This patch adds the dev_pm_ops callbacks to provide the system
suspend/resume functionality through the appropriate runtime
PM callbacks. The PM runtime_resume and runtime_suspend callbacks
are already used to enable, configure and disable the IOMMUs during
the attaching and detaching of the client devices to the IOMMUs,
and the new PM callbacks reuse the same code by invoking the
pm_runtime_force_suspend() and pm_runtime_force_resume() API. The
functionality in dev_pm_ops .prepare() checks if the IOMMU device
was already runtime suspended, and skips invoking the suspend/resume
PM callbacks. The suspend/resume PM callbacks are plugged in through
the 'late' pm ops to ensure that the IOMMU devices will be suspended
only after its master devices (remoteproc devices) are suspended and
restored before them.

NOTE:
There are two other existing API, omap_iommu_save_ctx() and
omap_iommu_restore_ctx(). These are left as is to support
suspend/resume of devices on legacy OMAP3 SoC.

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

iommu/omap: add logic to save/restore locked TLBs

The MMUs provide a mechanism to lock TLB entries to avoid
eviction and fetching of frequently used page table entries.
These TLBs lose context when the MMUs are turned OFF. Add the
logic to save and restore these locked TLBS during suspend
and resume respectively. There are no locked TLBs during
initial power ON, and they need not be saved during final
shutdown.

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