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>

iommu/omap: streamline enable/disable through runtime pm callbacks

The OMAP IOMMU devices are typically present within the respective
client processor subsystem and have their own dedicated hard-reset
line. Enabling an IOMMU requires the reset line to be deasserted
and the clocks to be enabled before programming the necessary IOMMU
registers. The IOMMU disable sequence follow the reverse order of
enabling. The OMAP IOMMU driver programs the reset lines through
pdata ops to invoke the omap_device_assert/deassert_hardreset API.
The clocks are managed through the pm_runtime framework, and the
callbacks associated with the device's pm_domain, implemented in
the omap_device layer.

Streamline the enable and disable sequences in the OMAP IOMMU
driver by implementing all the above operations within the
runtime pm callbacks. All the OMAP devices have device pm_domain
callbacks plugged in the omap_device layer for automatic runtime
management of the clocks. Invoking the reset management functions
within the runtime pm callbacks in OMAP IOMMU driver therefore
requires that the default device's pm domain callbacks in the
omap_device layer be reset, as the ordering sequence for managing
the reset lines and clocks from the pm_domain callbacks don't gel
well with the implementation in the IOMMU driver callbacks. The
omap_device_enable/omap_device_idle functions are invoked through
the newly added pdata ops.

Consolidating all the device management sequences within the
runtime pm callbacks allows the driver to easily support both
system suspend/resume and runtime suspend/resume using common
code.

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

ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU

The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata. The OMAP IOMMU driver now requires the platform
data ops for device_enable/idle on all the IOMMU devices to be
able to enable/disable the clocks and maintain the reference
count and the omap_hwmod state machine. So, add the iommu pdata
quirks for the OMAP3 ISP IOMMU.

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

ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs

The DSP processor subsystems in DRA7xx have two MMUs, one for the
processor port and another for an EDMA port. Both these MMUs share
a common reset line, and the reset management is done through the
pdata quirks for the MMU associated with the processor port, so the
DSP EDMA MMUs didn't need any pdata ops. The OMAP IOMMU driver now
requires the device_enable/idle platform data ops on all the IOMMU
devices to be able to enable/disable the clocks and maintain the
reference count and the omap_hwmod state machine. So, add the iommu
pdata quirks for the DSP EDMA MMUs.

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

ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs

The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks. Plug in these pdata ops for all the existing IOMMUs
through pdata quirks.

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

iommu/omap: add pdata ops for omap_device_enable/idle

Add two new platform data ops to allow the OMAP iommu driver to
be able to invoke the omap_device_enable and omap_device_idle
from within the driver. These are being added to streamline the
sequence between managing the hard reset lines and the clocks
during the suspend path, as the default device pm_domain callback
sequences in omap_device layer are not conducive for the OMAP
IOMMU driver.

This could have been done by expanding the existing pdata ops
for reset management (like in the OMAP remoteproc driver), but
this was chosen to avoid adding additional code in the separate
file in the mach-omap2 layer.

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

ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879

Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP

Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.

Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.

Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.

This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.

Note that the DSP MStandby behavior is not consistent across all
boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
details.

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

ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs

The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.

The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit 4e6bf3ca947b ("ARM: OMAP2+: Use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.

Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.

NOTE:
1. The functional behavior is inconsistent between different DSPs on
   DRA74x, DRA72x and DRA71x SoCs and silicon revisions. DSP1 on
   DRA7 EVM rev.H (DRA752 ES2.0), AM57xx GP EVM (DRA752 ES2.0) and
   AM572x IDK (DRA752 ES2.0) boards is entering idle mode without any
   fix and are getting powered down and losing context, but none of
   the other boards (DRA72 EVM, DRA71 EVM, AM571x IDK) exhibit this
   behavior. The idling behavior is unchanged even after this patch
   is applied. DSP2 is not idled on any board. These behaviors are
   different from those observed on 4.14 kernel.
2. This patch is also needed to preserve the DSP contexts when proper
   clock-gating is achieved during inactive periods. DSP power domains
   on these platforms should not be hitting OFF at the moment (even
   with firmware images executing an IDLE instruction) because of the
   issue described in errata i879 ("DSP MStandby requires CD_EMU in
   SW_WKUP") affecting these SoCs, but the behavior is different between
   different DSPs and SoCs as explained in #1. The i879 errata fix in
   the following patch achieves the DSP clock-gating with HW_AUTO mode,
   and would result in a power domain sleep transition to OFF mode
   without any software context save mechanism for all the DSPs.

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

ARM: OMAP2+: Use separate IOMMU pdata to fix DRA7 IPU1 boot

The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in commit 8fdc9a162e8d ("iommu/omap: Fix boot issue on
remoteprocs with AMMU/Unicache").

NOTE:
1. RET is not a valid target power domain state on DRA7 platforms,
   and IPU power domain is normally programmed for OFF. The IPU1
   still fails to boot though, and an unclearable l3_noc error is
   thrown currently on 4.19 kernel without this fix. This behavior
   is same as on 4.14 LTS kernel but slightly different from previous
   4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
   other affected IPU processors on OMAP4/OMAP5/DRA7 are in domains
   that are not entering RET. IPU2 on DRA7 is in CORE power domain
   which is only programmed for ON power state. The fix can be easily
   scaled if these domains do hit RET or OFF and loose context in the
   future.
3. The issue was not seen on current DRA7 platforms if any of the
   DSP remote processors were booted and using one of the GPTimers
   5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
   errata fix for i874 implemented in commit 1cbabcb9807e ("ARM:
   DRA7: clockdomain: Implement timer workaround for errata i874")
   which keeps the IPU1 power domain from entering RET when the
   timers are active. But the timer workaround did not make any
   difference on 4.14/4.19 kernels, and an l3_noc error was seen
   still without this fix.

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

ARM: dts: dra74x: Enable DSP2 IOMMU nodes

The DSP2 remote processor is present only on some SoCs of the DRA7
family - mainly the DRA74x/DRA76x and AM572x/AM574x and corresponding
derivative SoCs. The two MMU nodes for this DSP2 processor have all
been enabled by default, so that these nodes are automatically
enabled for all derivative boards using these SoCs.

Any derivative SoCs or boards not having these IPs or not intending to
enable/use these remote processors by default can mark these nodes
as "disabled" in their derivative SoC or board dts files.

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

iommu/omap: Fix boot issue on remoteprocs with AMMU/Unicache

Support has been added to the OMAP IOMMU driver to fix a boot hang
issue on OMAP remoteprocs with AMMU/Unicache, caused by an improper
AMMU/Unicache state upon initial deassertion of the processor reset.
The issue is described in detail in the next three paragraphs.

All the Cortex M3/M4 IPU processor subsystems in OMAP SoCs have a
AMMU/Unicache IP that dictates the memory attributes for addresses
seen by the processor cores. The AMMU/Unicache is configured/enabled
by the SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
mandates all addresses accessed by M3/M4 be defined in the AMMU. This
bit is not programmable from the host processor. The M3/M4 boot
sequence starts out with the AMMU/Unicache in disabled state, and
SYS/BIOS programs the AMMU regions and enables the Unicache during
one of its initial boot steps. This SCACHE_CONFIG.BYPASS bit is
however enabled by default whenever a RET reset is applied to the IP,
irrespective of whether it was previously enabled or not. The AMMU
registers lose their context whenever this reset is applied. The reset
is effective as long as the MMU portion of the subsystem is enabled
and clocked. This behavior is common to all the IPU and DSP subsystems
that have an AMMU/Unicache.

The IPU boot sequence involves enabling and programming the MMU, and
loading the processor and releasing the reset(s) for the processor.
The PM setup code currently sets the target state for most of the
power domains to RET. The L2 MMU can be enabled, programmed and
accessed properly just fine with the domain in hardware supervised
mode, while the power domain goes through a RET->ON->RET transition
during the programming sequence. However, the ON->RET transition
asserts a RET reset, and the SCACHE_CONFIG.BYPASS bit gets auto-set.
An AMMU fault is thrown immediately when the M3/M4 core's reset is
released since the first instruction address itself will not be
defined in any valid AMMU regions. The ON->RET transition happens
automatically on the power domain after enabling the iommu due to
the hardware supervised mode.

This patch adds and invokes the .set_pwrdm_constraint pdata ops, if
present, during the OMAP IOMMU enable and disable functions to resolve
the above boot hang issue. The ops will allow to invoke a mach-omap2
layer API pwrdm_set_next_pwrst() in a multi-arch kernel environment.
The ops also returns the current power domain state while enforcing
the constraint so that the driver can store it and use it to set back
the power domain state while releasing the constraint. The pdata ops
implementation restricts the target power domain to ON during enable,
and back to the original power domain state during disable, and thereby
eliminating the conditions for the boot issue. The implementation is
effective only when the original power domain state is either RET or
OFF, and is a no-op when it is ON or INACTIVE.

The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.

Note that the current issue is seen only on kernels with the affected
power domains programmed to enter RET. For eg., IPU1 on DRA7xx is in a
separate domain and is susceptible to this bug, while the IPU2 subsystem
is within CORE power domain, and CORE RET is not supported on this SoC.
IPUs on OMAP4 and OMAP5 are also susceptible since they are in CORE power
domain, and CORE RET is a valid power target on these SoCs.

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

ARM: dts: dra7: Enable common IPU and DSP IOMMU nodes

The IPU1, IPU2 and DSP1 are the most common remote processors present
on the DRA7xx/AM57xx family of SoCs. The MMU nodes for these common
processors have all been enabled by default, so that these nodes are
automatically enabled for all derivative boards.

Any derivative SoCs or boards not having these IPs or not intending to
enable/use these remote processors by default can mark these nodes
as "disabled" in their derivative SoC or board dts files.

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

ARM: OMAP2+: Extend iommu pdata-quirks to DRA74x DSP2

Extend the IOMMU pdata quirks for reset control to the primary
MMU within the DSP2 processor subsystem in DRA74x family of SoCs
as well.

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

ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs & DSP1

The IOMMUs within the IPU and DSP processor subsystems in
DRA7xx are very similar to those in OMAP4/OMAP5, so extend
the OMAP4 iommu pdata quirks for these MMUs as well.

The DSP processor subsystem in DRA7xx, though, has two MMUs,
one for the processor port and another for an EDMA port. Both
these MMUs share a common reset line, the MMU on the EDMA
port will always be mirror-programmed alongside the primary
MMU, so the pdata quirks for reset is only added for the MMU
associated with the processor port.

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

ARM: DRA7: hwmod data: Add MMU data for DSPs

Add the data structures for representing the MMUs within the DSP
processor subsystems present in DRA7xx/AM57xx SoCs. The DRA7xx
family of SoCs usually have one or two DSPs. The DRA74x/DRA76x
family has two DSPs, while DRA72x/DRA71x has only a single DSP.
Each DSP subsystem has two MMUs, one for the processor core and
the other for the internal EDMA block. The hwmod data for the
second DSP is only added for DRA74x/DRA76x family of SoCs.

Both these MMUs share a common reset line, the MMU on the EDMA
port is expected to be mirror-programmed alongside the primary
MMU. The reset data is added to both the MMUs to allow the
omap_hwmod layer to skip the enabling and idling of these devices,
as that would require the reset be released, which is outside
the scope of the hwmod core code. The other PRCM data fields are
also skipped for both the second MMUs, this will be handled as
part of the primary MMU enabling sequence. The second MMUs
needed the HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT as the .context_offs
field does not use a 0 value as a no-op. Without this, CCS throws
the following error upon attempting to connect to DSPs:
  "C66xx_DSP: Error connecting to the target: (Error -6305) PRSC
   module failed to write to a router register."

The pdata quirks will also not be added for the second MMU as the
OMAP IOMMU driver releases the reset once and is expected to program
both the MMUs together.

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

ARM: DRA7: hwmod data: Add MMU data for IPUs

A new MMU hwmod class and data structures are added for
representing the MMUs within the IPU1 and IPU2 processor
subsystems present on DRA7xx/AM57xx SoCs.

Note that the clock integration is slightly different between
IPU1 and IPU2. IPU2 functional clock is sourced directly from
dpll_core_h22x2_ck, while IPU1 has a mux clock for which one
of the inputs is dpll_core_h22x2_ck. This mux clock is configured
to be sourced from the dpll_core_h22x2_ck in turn, so that both
IPU1 and IPU2 run at the same clock frequency. This is already
addressed in commit 39879c7d963e ("ARM: dts: dra7xx-clocks:
Source IPU1 functional clock from CORE DPLL") originally, and
is re-implemented with the introduction of the clkctrl node
changes in commit 51199fa81a57 ("ARM: dts: dra7: Add clkctrl
nodes for IPU and DSP remote processors").

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

ARM: dts: dra7: Add clkctrl nodes for IPU and DSP remote processors

Add the clkctrl nodes for the DSP and IPU remote processors. Each of the
IPU and DSP processors are present within their own clock domains. The
previous ipu_cm clock domain is split properly into the correct ipu_cm
and ipu1_cm clock domains.

The ipu1_gfclk_mux clock is now created through the clkctrl driver and
so the corresponding clock node is dropped. The dpll_core_h22x2_ck clock
is also assigned as the default parent for the equivalent clock retaining
the functional behaviour introduced in commit 39879c7d963e ("ARM: dts:
dra7xx-clocks: Source IPU1 functional clock from CORE DPLL").

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: dra7: add clkctrl data for remote processor clocks

Add clkctrl clocks for the DSP1/2, PRUSS1/2 and IPU1/2 remote processors.
All the processors use a clock output that is a divider output of a
corresponding DPLL, except for IPU1. IPU1 is sourced from an additional
mux clock that can pick from two different DPLLs.

The IPU and DSP remote processor cores and their corresponding MMUs on
DRA7xx/AM57xx SoCs have hardreset lines associated with them and are
controlled by a PRCM reset line each. Any clkctrl enable/disable operations
cannot be checked for module enabled/disabled status independent of the
reset operation, and this causes some unwanted timeouts in the kernel
and unbalanced states for these clocks. These details should be handled
by the driver integration code itself. So, add the CLKF_NO_IDLEST flag
to both the IPU and DSP clkctrl clocks so that these module status checks
are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: add few more details to patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: clk: add dra7 remotecore clkctrl definitions

Add clkctrl offsets for the remotecore related clocks in the system;
these are PRUSS1/2, DSP1/2 and IPU1/2.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks

The IPU and DSP remote processor cores and their corresponding MMUs on
OMAP5 SoCs have hardreset lines associated with them and are controlled
by a PRCM reset line each. Any clkctrl enable/disable operations cannot
be checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for these clocks. These details should be handled by
the driver integration code itself.

Add the CLKF_NO_IDLEST flag to both the IPU and DSP clkctrl clocks so
that these module status checks are skipped.

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

clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks

The IPU and DSP remote processor cores and their corresponding MMUs on
OMAP4 SoCs have hardreset lines associated with them and are controlled
by a PRCM reset line each. Any clkctrl enable/disable operations cannot
be checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for these clocks. These details should be handled by
the driver integration code itself.

Add the CLKF_NO_IDLEST flag to both the IPU and DSP clkctrl clocks so
that these module status checks are skipped.

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

ARM: OMAP2+: hwmod_core: improve the support for clkctrl clocks

[ Upstream commit 1b9c30fe01df01c17c5ddd9b4ea02b2ca186d5e7 ]

This patch adds support for split memory ranges for clkctrl providers.
This is necessary to support the coming clockdomain based split of
clkctrl provider ranges, instead of the current CM instance based one.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick commit '1b9c30fe01df' from v4.20]
Signed-off-by: Suman Anna <s-anna@ti.com>

iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN

The macro SLAB_HWCACHE_ALIGN is of type slab_flags_t, but is currently
assigned in the OMAP IOMMU driver using a unsigned long variable. This
generates a sparse warning around the type check. Fix this by defining
the variable flags using the correct type.

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

soc: ti: pruss: enable OCP master ports in SYSCFG always

The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level,
and is being programmed for the PRCM Idle/Standby protocol properly
during probe and remove. The register is also programmed to enable
the OCP master ports (disable MStandby) by default during probe now
to allow the PRUs access to on-chip memories and peripherals outside
the PRUSS without having to do it in firmware (primarily for the PRU
Ethernet usecase currently, the firmware is not programming this
register).

NOTE:
1. The AM57xx TRM suggests to enable "No Standby" during the
   Idle + Standby state to an Active/Normal state, but this
   sequence is not documented in either of AM33xx and AM437x
   SoCs. Furthermore, it did not have an impact on the working
   of Ethernet Rx, so is left out.
2. This has an impact on the PM suspend/resume operation usually
   (same bit is used to trigger PRU standby), and even when the
   PRU cores are in halted state. The STANDBY_INIT has to be
   re-programmed to initiate a standby sequence and have the PM
   suspend/resume functional when PRUs are halted. This is already
   handled in commit c1d6b33cb8f7 ("soc: ti: pruss: Fix system
   suspend/MStandby config issues").

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

remoteproc/pru: add support for configuring GPMUX based on client setup

Client device node property ti,pruss-gp-mux-sel can now be used to
configure the GPMUX config value for PRU.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: simplify the pru id usage]
Signed-off-by: Suman Anna <s-anna@ti.com>