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

Pull in the updated rpmsg base feature branch that includes a minor fix
in the rpmsg-rpc driver for issues reported by the static code checker
tool Klocwork.

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix static checker errors

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

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

Pull in the dedicated AM65x remoteproc topic branch that includes a fix
for probe failures in remoteproc mode on devices where the R5FSS is
only capable of Split-mode.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: fix probe failure on Split-mode _only_ devices

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

remoteproc/k3-r5: fix probe failure on Split-mode _only_ devices

The R5F subsystem/cluster on K3 SoCs can support both LockStep and
Split-modes (superset) or just Split-mode depending on an eFUSE
capability register. The k3_r5_rproc_configure() function is used to
configure the R5F remote processors in remoteproc mode, and performs
this by requesting the System Firmware as per the requested DT properties.
This function initializes identical settings for both cores in LockStep
mode by first programming it for Split-mode and then reverting back
to LockStep mode after the settings initialization. The Split-mode
setting is done on Core0 always irrespective of the mode.

The LockStep configuration bit is Read-only though on Split-mode _only_
devices and as such the System Firmware does not allow the LockStep
mode bit to be configured on such devices. The current logic in
k3_r5_rproc_configure() fails on Split-mode devices because of this
unconditional programming of the LockStep mode bit.

Fix this by limiting the LockStep mode bit clear configuration only on
devices supporting both LockStep/Split-modes.

Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: rpc: fix static checker errors

Fix couple of minor issues reported by the Klocwork static checker
analysis tool:
 - Perform a sanity check on the function index against the available
   number of functions supported by the rppc device to avoid out-of-bound
   array access in rppc_write().
 - Remove a stale local variable redefinition to avoid returning an
   uninitialized return value in certain paths in rppc_probe().

Fixes: 1b5a3b2ef344 ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in the dedicated remoteproc dra7-late-attach topic branch that limits
the "late-attach" mode to only IPU1. This change is done as the default IPU2
firmware file for MultiMedia use-cases is incompatible with the 'no-map'
carveouts needed by the late-attach functionality.

* 'topic/4.19/dra7-late-attach' of ssh://bitbucket.itg.ti.com/rpmsg/remoteproc:
  TEMP: ARM: dts: dra7-ipu-common: Limit IPU early boot to only IPU1

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

TEMP: ARM: dts: dra7-ipu-common: Limit IPU early boot to only IPU1

The dra7-ipu-common-early-boot.dtsi file has the necessary changes to
configure both the IPU1 and IPU2 remote processors for 'late attach' mode.
Remove the changes for IPU2 for the moment to limit the 'late attach' mode
for IPU1 only. This is being done due to the limitations with some of the
current IPU2 firmware files.

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

Merge branch 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Add required DT support for early-booted IPU on am57x and dra7xx
platforms and revert previous hack for using CMA pools.

* 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc:
  Revert "HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots"
  ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
  ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Revert "HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots"

This reverts commit ed2d95b1520770319b74c58d69d0e5116f9dccdc.

This patch must be reverted to enable IPU early boot when configured
as default in SPL config.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

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

Pull in the am65x topic branch that includes a fix for initializing TCM
memories for ECC.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: initialize TCM memories for ECC

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

remoteproc/k3-r5: initialize TCM memories for ECC

The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that
support 32-bit ECC. The TCMs are typically loaded with some boot-up
code to initialize the R5 MPUs to further execute code out of DDR.
The ECC for the TCMs is enabled by default on K3 SoCs due to internal
default tie-off values, but the TCM memories are not initialized on
device power up. Any read access without the corresponding TCM memory
location initialized will generate an ECC error, and any such access
from a A72 or A53 core will trigger a SError.

So, zero initialize both the TCM memories before loading any firmware
onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would
require a similar initialization in the bootloader. Note that both
the TCMs are initialized unconditionally as the TCM enable config bits
only manage the access and visibility from R5. The Core1 TCMs are not
used and accessible in LockStep mode, so they are only initialized
in Split-mode.

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

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

Pull in the dedicated AM65x remoteproc topic branch that includes various
fixes in the K3 R5F remoteproc driver for kernel crashes in memcpy() and
memset() caused during remoteproc loading into the R5F TCMs and on-chip
SRAMs due to the mapping of these regions as device-type memory.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: fix memzero issues on reserved SRAM regions
  remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses
  remoteproc/k3-r5: fix unaligned data faults with TCMs during loading

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

remoteproc/k3-r5: fix memzero issues on reserved SRAM regions

The K3 R5 remoteproc driver can support loading into and executing
code from various on-chip SRAM regions like MCU SRAM or NavSS SRAM,
and these regions are mapped as device type memory because of the
usage of ioremap().

The remoteproc core ELF loader function zeroes out any remaining
portions of a program segment if the actual memory size (p_memsz)
is more than the loadable content (p_filesz), and this memset is
throwing a kernel crash on these reserved SRAM regions at present.
This is because of the usage of the "DC ZVA" instruction within the
Arm64 memset library function when zeroing out memory, which throws
an alignment fault on device type memory.

Fix this by switching to ioremap_wc() function instead of ioremap()
function for mapping the SRAM regions. The ioremap_wc() maps the
SRAM regions as normal non-cacheable memory instead. The solution
follows the similar logic used in the core SRAM driver in
commit 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap").

Fixes: 7091176e2f99 ("remoteproc/k3-r5: add loading support for on-chip SRAM regions")
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/k3-r5: fix loading into BTCM when using R5 local addresses

A R5F remote processor can access its TCMs either using its local address
views at address 0x0 and/or 0x41010000 depending on the LOCZRAMA setting,
or using the corresponding SoC-bus address views (one-to-one views since
there are no MMUs).

The K3 R5F remoteproc driver provides the translations for the TCMs
through the k3_r5_rproc_da_to_va() function to allow loading into TCMs.
This function is translating the SoC-view addresses just fine, but is
only translating ATCMs at address 0x0 at present. This results in a
failure to load any segments into BTCMs when using the R5 local address
range at 0x41010000. Update the logic in this function to fix these
BTCM load issues.

Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/k3-r5: fix unaligned data faults with TCMs during loading

The R5F processors on TI K3 SoCs all have Tightly Coupled Memory (TCM)
and has both the ATCM and two banks of BTCM. The K3 R5F remoteproc driver
leverages the TCMs to perform boot-strapping and support further execution
of code from DDR. These TCMs are currently mapped into the kernel as device
type memory due to the usage of devm_ioremap_resource(). The remoteproc
core ELF loader uses the regular memcpy function for loading program
segments.

The Arm64 architecture causes an alignment fault on any unaligned access
to any type of device memory. The R5F firmwares can have a TCM program
segment unaligned (due to the presence of the unaligned Elf32 header)
and cause issues with the Arm64 memcpy() function. The TCMs are furthermore
designed in general to support RAM-like backing memories.

So, update the TCM mapping logic to instead use the devm_ioremap_wc()
function to map these memory regions as Normal Non-Cached memories, and
thereby fix any potential unaligned data accesses during remoteproc
loading. This also helps with zeroing out the TCMs using memset().

An example crash log looks like below:
  Unable to handle kernel paging request at virtual address ffff0000128c0004
  Mem abort info:
    ESR = 0x96000061
    Exception class = DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
  Data abort info:
    ISV = 0, ISS = 0x00000061
    CM = 0, WnR = 1
  swapper pgtable: 64k pages, 48-bit VAs, pgdp = 000000002c996fc5
  [ffff0000128c0004] pgd=00000008fffe0003, pud=00000008fffe0003, pmd=00000008fffd0003, pte=00e8000005c00707
  Internal error: Oops: 96000061 [#1] PREEMPT SMP
  Modules linked in: ti_k3_r5_remoteproc virtio_rpmsg_bus remoteproc
  Process kworker/1:2 (pid: 129, stack limit = 0x00000000d72d3758)
  CPU: 1 PID: 129 Comm: kworker/1:2 Not tainted 4.19.73-00042-g9c815c9f00bd #347
  Hardware name: Texas Instruments K3 J721E SoC (DT)
  Workqueue: events request_firmware_work_func
  pstate: 00000005 (nzcv daif -PAN -UAO)
  pc : __memcpy+0x48/0x180
  lr : rproc_elf_load_segments+0x174/0x1c8 [remoteproc]
  sp : ffff00000bbcfc80
  x29: ffff00000bbcfc80 x28: ffff800843a23838
  x27: 0000000000000034 x26: 0000000000000040
  x25: ffff800843a23800 x24: ffff80084a8d2c00
  x23: ffff000012b10000 x22: 0000000000000000
  x21: 0000000000000040 x20: 0000000000000000
  x19: ffff000012ca50c0 x18: 0000000000000000
  x17: 0000000000000000 x16: 0000000000000000
  x15: 0000000000000400 x14: 0000000000000400
  x13: 0000000000000044 x12: 0000000000000000
  x11: 0000000000000001 x10: 0000000000000980
  x9 : ffff00000bbcf860 x8 : ffff8008435609e0
  x7 : ffff800843560240 x6 : ffff0000128c0004
  x5 : ffff80087fae17e8 x4 : 000000000000000c
  x3 : e59ff018e59ff018 x2 : 0000000000000034
  x1 : ffff000012b10040 x0 : ffff0000128c0000
  Call trace:
   __memcpy+0x48/0x180
   rproc_boot+0x404/0x668 [remoteproc]
   rproc_auto_boot_callback+0x18/0x30 [remoteproc]
   request_firmware_work_func+0x48/0x88
   process_one_work+0x1e0/0x318
   worker_thread+0x40/0x428
   kthread+0x124/0x128
   ret_from_fork+0x10/0x18
  Code: b8404423 b80044c3 36180064 f8408423 (f80084c3)
  ---[ end trace cbd6238f81b6eda1 ]---

Fixes: 80d807f572e9 ("remoteproc/k3-r5: add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>

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

Pull in the dedicated AM65x remoteproc topic branch that increases the
IPC DDR carveout region used by the MCU domain R5F cores on AM65x platforms
to match the current usage on the PDK IPC LLD firmwares.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC

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

TEMP: arm64: dts: ti: k3-am654-base-board: Increase reserve memory for RTOS IPC

A 1 MB of carveout memory at 0xa2000000 is reserved currently for achieving
IPC between the two MCU R5F cores when running in split-mode. The PDK IPC
RTOS code though is currently accessing some memory beyond this 1 MB, used
to also achieve IPC with the A53 cores running RTOS (Linux uses a separate
1 MB region per core as part of the overall 16 MB region). Reserve an
additional 1 MB of memory temporarily until the RTOS code logic is fixed
up to avoid memory corruptions with the linux kernel.

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

Merge branch 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in a dedicated remoteproc topic branch that adds the infrastructure
support to allow "late-attach" of the IPU1 and IPU2 remote processors on
DRA7xx/AM57xx SoCs. The late-attach feature is the kernel counterpart to
the early-boot of these processors from U-Boot/SPL to achieve key system
response time goals.

The support is provided through temporary HACKs or workarounds to various
subsystems that includes the DMA API layers, remoteproc core, OMAP IOMMU,
OMAP DMTimer and OMAP remoteproc drivers. The early-booted remoteproc
devices need couple of DT modifications, and these are provided through
a common dtsi file. This common dtsi file needs to be included in the
desired target DRA7/AM57xx board dts files (not merged but available on
the above topic branch).

The following are the main HACKs and needs further rework:
 - Introduce new non-zeroing DMA API to allow the remoteproc core to
   still process the RSC_CARVEOUTs but not zero them (This will need to
   be replaced with static carveout support)
 - The new "late_attach" field added to remoteproc core needs to be
   replaced with equivalent fields already present that supports the
   K3 IPC-only mode and Keystone 2 Multi Proc Manager (MPM) stack.
 - The .device_is_enabled() logic is only temporary and applicable only
   with hwmod layers, this will need to be replaced with logic around
   reset status from OMAP PRM reset driver (next LTS).
 - The reserved memory regions used should actually be carveouts (DMA
   pools), and this needs some resource table RSC_CARVEOUT entries split
   on all the existing firmwares.
 - The addition of the DT modifications needs to be evaluated if it can
   be moved into U-Boot itself. The current logic requires that both
   U-Boot and kernel configs are matched, without which kernel crashes
   are seen.

* 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc:
  HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
  TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
  TEMP: remoteproc/omap: add "late attach" support
  TEMP: iommu/omap: add support for performing a "late attach"
  ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
  clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
  TEMP: remoteproc: call the non-zeroing allocation function
  TEMP: remoteproc: add "late attach" support
  HACK: dma-mapping: add non-zeroing coherent alloc function
  HACK: ARM: dma-mapping: create non-zeroing dma_map_ops

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

ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the AM571x IDK board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors in the am572x-idk-common.dtsi file that applies
to both the AM572x and AM574x IDK boards. These processors should have been
booted earlier by either the U-Boot or SPL. All the necessary node changes
are applied by including the common dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors on all the AM57xx BeagleBoard-X15 boards. These
processors should have been booted earlier by either the U-Boot or SPL.
All the necessary node changes are applied by including the common
dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA71 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on both the DRA72 EVM and DRA72
rev.C EVM boards. These processors should have been booted earlier
by either the U-Boot or SPL. All the necessary node changes are
applied by including the common dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA76 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.

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

ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2

Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA7 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.

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

HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots

The patch d1a42fca5944 ("TEMP: ARM: dts: dra7-ipu-common: Add a common
file for IPU early boots") converts the default CMA pools used in regular
remoteproc mode to carveouts/DMA pools for early-boot usage scenarios
using the "no-map" property to avoid the kernel from corrupting the
remoteproc firmware image sections.

The allocation scheme with DMA pools though is different than with CMA
pools, and this may cause some of the existing firmwares used in the
regular remoteproc mode with CMA to fail. The DMA pools may require a
number of changes in general:
 - Split the firmware RSC_CARVEOUT sections into better aligned memory
   regions conducive to the DMA pool allocation scheme.
 - Increase the vmalloc size, as the DMA pools are no longer mapped by
   default in kernel linear memory (for DDR < 2 GB) and needs to be
   mapped into vmalloc space to be accessed. This may depend on system
   configuration, number of remote cores using a DMA pool, and the sizes
   of the DMA pools.
 - Increase the size of the carveouts (last resort)

Revert back to CMA pools temporarily to make the current firmware images
be functional. A short-term fix would be to update the firmwares and the
long-term fix would be to eliminate the allocation logic altogether and
rely on fixed memory carveout support.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TEMP: remoteproc: call the non-zeroing allocation function

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

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

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

TEMP: remoteproc: add "late attach" support

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

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

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

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

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

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

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

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

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

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

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

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

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

Pull in the updated remoteproc feature branch that renames the node names
and labels for the reserved memory regions on DRA76 and DRA72 rev.C EVM
boards to not use the CMA terminology.

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names
  ARM: dts: dra72-evm-revc: Fix rproc reserved-memory labels and node names

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

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

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

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

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

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

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

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

Pull in the updated remoteproc feature branch that adds a new sysfs
file 'name' to allow userspace to easily identify a remoteproc. An
equivalent file was already present in debugfs as well, but sysfs
provides a more standardized userspace interface since debugfs is
optional.

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: Add a sysfs interface for name

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

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

Pull in the updated rpmsg base feature branch that includes minor
typo fixes in the rpmsg core and minor dynamic-debug related printk
improvements to the virtio_rpmsg_bus and rpmsg_client_sample drivers.

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
  rpmsg: core: fix comments
  samples/rpmsg: Replace print_hex_dump() with print_hex_dump_debug()

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

remoteproc: Add a sysfs interface for name

[ Upstream commit 6ed756aa0148a5ad0dbdced6f14f22e2f5748d35 ]

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

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

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

rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"

[ Upstream commit de4064af76537f13d74a814a962f4524e81436ac ]

The virtio_rpmsg_bus driver uses the "%p" format-specifier for
printing the vring buffer address. This prints only a hashed
pointer even for previliged users. Use "%pK" instead so that
the address can be printed during debug using kptr_restrict
sysctl.

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

rpmsg: core: fix comments

[ Upstream commit 9ff166def8c1f5759555c2c94ddd0fef11a18c2b ]

Minor typos, grammar and copy/paste issues. Fix for consistency. No
functional or semantic change.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '9ff166def8c1' from v5.4]
Signed-off-by: Suman Anna <s-anna@ti.com>

samples/rpmsg: Replace print_hex_dump() with print_hex_dump_debug()

[ Upstream commit 2519fbb39711e5e6696685f29fe049af93c5987c ]

Replace the raw print_hex_dump() call in the rpmsg_sample_cb() function
with the equivalent print_hex_dump_debug() better suited for dynamic
debug. This switch allows flexibility of controlling this trace through
dynamic debug when enabled.

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

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

Pull in the dedicated AM65x remoteproc topic branch that updates the
the DDR carveout regions used by the MCU domain R5F cores on AM65x
platforms in preparation for also supporting the PDK IPC LLD firmwares.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-am654-base-board: Reserve memory for IPC between R5F cores
  arm64: dts: ti: k3-am654-base-board: Update R5F DDR carveout memory nodes

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

arm64: dts: ti: k3-am654-base-board: Reserve memory for IPC between R5F cores

Add a reserved memory node to reserve a portion of the DDR memory to be
used for performing inter-processor communication between all the MCU R5F
remote processors running RTOS on all the TI AM654 boards. This memory
shall be exercised only if the MCU R5FSS cluster is configured for Split
mode.  A single 1 MB of memory at 0xa2000000 is reserved for this purpose,
and this accounts for all the vrings and vring buffers between pair of
these R5F remote processors.

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

arm64: dts: ti: k3-am654-base-board: Update R5F DDR carveout memory nodes

The commit 144cef9df918 ("arm64: dts: ti: k3-am654-base-board: Add DDR
carveout memory nodes for R5Fs") has reserved some static carveouts
(8 MB @ 0x9c000000 for Core0 and 16 MB @ 0x9b000000 for Core1) for both
of the R5F cores in the MCU domain.

Update these regions to reserve 16 MB each for each core starting at
0xa0000000. This is to align and match the memory map for these MCU
R5Fs on both AM65x and J721E SoCs. All the existing firmware images
need to be updated to match these static reserved regions.

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

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

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

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

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

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

Pull in the dedicated AM65x remoteproc topic branch that fixes up an
incorrect macro usage in the pruss_intc_irq_set_affinity() function
introduced by code added in the most recent merge that pulled in a
bug fix for the INTC mapping configuration logic.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix incorrect macro replacement

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

Merge branch 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc into topic/4.19/am65x

Merge in the PRUSS topic branch into the AM65x remoteproc topic branch that
fixes an incorrect macro replacement in the pruss_intc_irq_set_affinity()
function.

* 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix incorrect macro replacement

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

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

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

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

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

Pull in the dedicated AM65x remoteproc topic branch that cleans up
the PRUSS INTC configuration code to use human-readable macros, and
a fix for an INTC mapping configuration logic bug exposed when running
different applications using different system event-to-channel and/or
channel-to-host interrupt mappings back to back.

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

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

Merge branch 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc into topic/4.19/am65x

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

* 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix erroneous channel/host mapping logic
  irqchip/irq-pruss-intc: Use macros for operations on CMR and HMR

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge branch 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc into topic/4.19/am65x

Merge in the PRUSS topic branch into the AM65x remoteproc topic branch
that pulls in the support for setting affinity for the PRU System Events
and a fix for deactivating the PRUSS INTC interrupts when the module is
removed.

* 'topic/4.19/pruss' of git://git.ti.com/rpmsg/remoteproc:
  TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events
  irqchip/irq-pruss-intc: Reset chained handlers during cleanup

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

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

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

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

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

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

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

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

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

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

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

Pull in the dedicated AM65x remoteproc topic branch that drops the
MII-RT management from the PRUSS platform driver and some cleanup
in the PRUSS INTC platform drivers. The pruss_regmap_read() and
pruss_regmap_update() API are also cleaned up and renamed to
pruss_cfg_read() and pruss_cfg_update() respectively.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  soc: ti: pruss: Rename pruss_regmap_read()/update() API
  soc: ti: pruss: Drop MII-RT management from PRUSS driver
  soc: ti: pruss: Remove stale iep variable
  irqchip/irq-pruss-intc: Use bitmap to simplify event configuration

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

soc: ti: pruss: Rename pruss_regmap_read()/update() API

The pruss_regmap_read() and pruss_regmap_update() API were designed
to support reading and updating any of the registers within the
CFG, MII-RT or IEP sub-modules. The management of MII-RT and IEP
submodules is dropped from the PRUSS platform driver, so simplify
the functionality of these functions to just deal with the CFG
sub-module. Both the functions have been renamed appropriately to
pruss_cfg_read() and pruss_cfg_update(), and all existing callsites
updated accordingly.

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

soc: ti: pruss: Drop MII-RT management from PRUSS driver

The MII-RT sub-module is represented as a syscon node and is
managed by the PRUSS platform driver at the moment. The usage
of MII-RT is limited to PRU Ethernet drivers, and so makes sense
to manage this sub-module by those drivers directly. So, drop
the code from the PRUSS platform driver that deals with parsing
of the mii-rt DT nodes or providing an API wrapper for accessing
any registers within this sub-module.

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

soc: ti: pruss: Remove stale iep variable

The commit 7cff1bbab114 ("soc: ti: pruss: Drop IEP management from
PRUSS driver") has removed the management of IEP from PRUSS platform
driver, but missed cleaning up the iep variable. Drop this variable
from the pruss structure.

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

irqchip/irq-pruss-intc: Use bitmap to simplify event configuration

Simplify the PRUSS System Event management code to use the bitmap API in
the pruss_intc_configure() and pruss_intc_unconfigure() functions.

Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>

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

Pull in the dedicated AM65x remoteproc topic branch to bring in couple
of AM65x mailbox cleanup patches. Changes include mbox_msg_t type
simplification and the relocation of the AM65x Mailbox DT nodes from
the cbass_main interconnect node to the more accurate main_navss
interconnect node.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  mailbox/omap: Simplify mbox_msg_t usage
  arm64: dts: ti: k3-am65-main: Move mailbox nodes to main_navss interconnect

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

Merge branch 'mailbox-linux-4.19.y' of git://git.ti.com/rpmsg/mailbox into topic/4.19/am65x

Merge in the mailbox feature tree into the AM65x remoteproc topic branch
that pulls in the changes to simplify the mbox_msg_t usage and move the
AM65x Mailbox DT node from cbass_main interconnect node to the more
accurate main_navss interconnect node.

* 'mailbox-linux-4.19.y' of git://git.ti.com/rpmsg/mailbox:
  mailbox/omap: Simplify mbox_msg_t usage
  arm64: dts: ti: k3-am65-main: Move mailbox nodes to main_navss interconnect

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

mailbox/omap: Simplify mbox_msg_t usage

Simplify the mbox_msg_t type definition and the to_omap_mbox_msg
macro to use the uintptr_t type that can scale better to both
32-bit and 64-bit platforms.

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

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

Pull in the hwspinlock feature tree that moves the AM65x HwSpinlock DT
node from cbass_main interconnect node to the more accurate main_navss
interconnect node.

* 'hwspinlock-linux-4.19.y' of git://git.ti.com/rpmsg/hwspinlock:
  arm64: dts: ti: k3-am65-main: Move hwspinlock node to main_navss interconnect

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

arm64: dts: ti: k3-am65-main: Move mailbox nodes to main_navss interconnect

All the Mailbox cluster nodes were currently added directly under the
cbass_main interconnect node, even though the Mailbox IP is present within
the Main NavSS sub-module and is accessible from the MPU through the Main
NavSS local interconnect. The Main NavSS interconnect is represented as
its own interconnect node, so move all these nodes under the main_navss
interconnect node.

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

arm64: dts: ti: k3-am65-main: Move hwspinlock node to main_navss interconnect

The commit c18a938bdbac ("arm64: dts: ti: k3-am65-main: Add hwspinlock
node") had previously added the HwSpinlock node directly under the
cbass_main interconnect node even though it is connected on the Main
NavSS local interconnect. The Main NavSS interconnect is represented
as its own interconnect node, so move this node under the main_navss
interconnect node.

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

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

Pull in the dedicated AM65x remoteproc topic branch that adds the
preliminary support for representing PRUSS clocks as clocks nodes
in DT. The support is added _only_ for the ICSSG instances on K3
AM65x SoCs at the moment, and will be enhanced in the future to
scale for all applicable SoCs that have a PRUSS.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-am65-main: Add input clock to IEP nodes
  dt-bindings: soc: ti: pruss: Update IEP node bindings
  TEMP: soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX
  TEMP: arm64: dts: ti: k3-am65-main: Add IEP and CORE clock muxes
  TEMP: dt-bindings: soc: ti: pruss: Add IEP and CORE clock mux

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

arm64: dts: ti: k3-am65-main: Add input clock to IEP nodes

The IEP module gets its clock from a IEP clock mux.
Add this clock to the IEP nodes.

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

dt-bindings: soc: ti: pruss: Update IEP node bindings

IEP driver needs to know the clock rate of the IEP
core clock. Provide a clocks property for that.

TODO: Update the existing examples once these clocks are
added on those SoCs

Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: add under the proper sub-section]
Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX

The IEPCLK_MUX is present on all SoCs whereas the CORECLK_MUX
is present only on AM65.

Add support for both these CLK muxes.

NOTE: even though IEPCLK_MUX is present on all SoCs we
currently check for it only for it for AM65 as DT needs to be
fixed for other SoCs.

Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: few minor fixups]
Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: arm64: dts: ti: k3-am65-main: Add IEP and CORE clock muxes

The ICSSG module has clock muxes for IEP clock and CORE clock.
Add these clock muxes. The default parents for these mux clocks
are also assigned.

Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: minor formatting changes]
Signed-off-by: Suman Anna <s-anna@ti.com>

TEMP: dt-bindings: soc: ti: pruss: Add IEP and CORE clock mux

ICSS/ICSSG modules have an IEP clock mux that allow selection
of internal IEP clock from 2 clock sources.

ICSSG module has a CORE clock mux that allows selection
of internal CORE clock from 2 clock sources.

Add binding information for these 2 clock muxes.

Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: few minor fixups]
Signed-off-by: Suman Anna <s-anna@ti.com>

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

Pull in the updated remoteproc feature branch that adds the support
for setting affinity for the PRU System Events. The added support also
sets the affinity for the corresponding parent PRUSS INTC interrupt,
but the parent affinity will get overwritten with the affinity from
a most recent event if multiple events use the same parent PRUSS INTC
interrupt. This can be attributed to a lack of proper affinity support
for chained (non-hierarchical domain) interrupts, and to optimize both
an irq threaded handlers and the actual GIC interrupt to be on the same
CPU. PRU Application integrators have to design their event mappings
accordingly.

The merge also pulls in a fix for deactivating the PRUSS INTC interrupts
when the module is removed.

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
  TEMP: irqchip/irq-pruss-intc: Allow setting irq affinity for PRU events
  irqchip/irq-pruss-intc: Reset chained handlers during cleanup

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

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

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

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

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

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

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

Pull in the dedicated AM65x remoteproc topic branch that removes the
management of IEP from the PRUSS platform drivers to accomodate the
two IEP instances on ICSSG.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-am65-main: Add IEP1 instance for all ICSSG nodes
  soc: ti: pruss: Drop IEP management from PRUSS driver

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

arm64: dts: ti: k3-am65-main: Add IEP1 instance for all ICSSG nodes

Each ICSSG instance has 2 IEP instances. Add the 2nd IEP
instance (IEP1) for each ICSSG.

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

soc: ti: pruss: Drop IEP management from PRUSS driver

With ICSSG containing multiple IEPs per instance
it is simpler if the drivers manage IEP directly
instead of via pruss helpers.

prueth.c is already doing that so this helper
is unused for IEP.

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

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

Pull in the dedicated AM65x remoteproc topic branch that includes fixes
for couple of minor issues in the PRUSS INTC irqchip driver introduced
by the ICSSG support patch.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix an incorrect loop counter limit value
  irqchip/irq-pruss-intc: Fix potential NULL pointer dereferences

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

irqchip/irq-pruss-intc: Fix an incorrect loop counter limit value

The ICSSG IP on K3 AM65x SoCs has greater PRU host interrupts than
the regular PRUSS IP on all other SoCs. The commit 3f154172451e
("irqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs")
missed replacing the previous host interrupt loop counter limit value
MAX_PRU_HOST_INT in the pruss_intc_unconfigure() function with an
appropriate variable reflecting the PRU host interrupts number. Fix
this properly in line with the usage in the pruss_intc_configure()
function.

Fixes: 3f154172451e ("irqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs")
Signed-off-by: Suman Anna <s-anna@ti.com>

irqchip/irq-pruss-intc: Fix potential NULL pointer dereferences

The commit 3f154172451e ("irqchip/pruss-intc: Add support for ICSSG INTC
on K3 AM65x SoCs") initializes some variables in pruss_intc_configure()
and pruss_intc_unconfigure() functions using the looked up intc variable,
but this can potentially be NULL, and can cause kernel crashes due to
the resulting NULL pointer dereferences. Fix this properly by initializing
the variables after checking the intc variable.

Fixes: 3f154172451e ("irqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs")
Signed-off-by: Suman Anna <s-anna@ti.com>

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

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

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

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

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

Pull in the updated remoteproc feature branch that includes a
fix for a minor build issue with OMAP IOMMU driver.

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

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

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

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

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

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

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

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

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

ti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support

Enable the Watchdog timer support for the OMAP remoteproc driver. This
enables the OMAP remoteproc driver to recovery any remote processor
executions stuck in a loop. This also mandatas that that all the IPU
and DSP firmwares to be used with the OMAP remoteproc driver support
the Watchdog timers and are petting the corresponding dmtimers to avoid
a recurring reboot of that processor.

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

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

Pull in the updated rpmsg base feature branch that adds the support
to the rpmsg-proto driver for handling error recovery with active open
sockets.

The merge also includes a bug fix in the virtio rpmsg core to fix
various mutex circular/recursive dependency issues in rpmsg-rpc and
rpmsg-proto drivers during error recovery.

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: fix lockdep warnings in virtio rpmsg bus driver
  net/rpmsg: unblock reader threads operating on errored sockets
  net/rpmsg: return ENOLINK upon Rx on errored sockets
  net/rpmsg: return ESHUTDOWN upon Tx on errored sockets
  net/rpmsg: add support to handle a remote processor error recovery

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

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

Pull in the updated rpmsg base feature branch that includes fixes
to various bugs and memory leak issues found during error recovery
with active open applications.

* 'rpmsg-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix potential memory leak of unprocessed skbs
  rpmsg: rpc: fix ept memory leak during recovery
  rpmsg: rpc: use the local device pointer in all file operations
  rpmsg: rpc: maintain a reference device pointer per open fd
  rpmsg: rpc: fix sysfs entry creation failures during recovery

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

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

Pull in the remoteproc feature branch that restores the error recovery
functionality for remoteprocs with virtio devices and MMUs, and adds the
support for error recovery from both internal exceptions and Watchdog
errors on all IPU and DSP remote processors on OMAP4+ SoCs. The merge
also adds a debugfs last trace feature to remoteproc core. Also included
are fixes couple of issues in remoteproc core w.r.t sysfs interface and
debugfs 'recovery' file; and fixes for some state-machine issues related
to OMAP remoteproc driver.

* 'rproc-linux-4.19.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
  ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
  ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
  remoteproc/omap: add watchdog functionality for remote processors
  remoteproc/omap: fix auto-suspend failure warning during crashed state
  remoteproc: fix multiple back-to-back error recoveries
  remoteproc/omap: report device exceptions and trigger recovery
  remoteproc: implement last trace for remoteproc
  Revert "remoteproc: Introduce rproc_{start,stop}() functions"
  Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
  Revert "remoteproc: Remove depricated crash completion"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

remoteproc/omap: add watchdog functionality for remote processors

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

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

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

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

remoteproc/omap: fix auto-suspend failure warning during crashed state

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

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

remoteproc: fix multiple back-to-back error recoveries

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

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

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

remoteproc/omap: report device exceptions and trigger recovery

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

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

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

remoteproc: implement last trace for remoteproc

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

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

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

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

This reverts commit 1efa30d0895e7e9a58a59b0880b330b38245be68.

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

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

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