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>

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>

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>

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 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/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>

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 '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>

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: 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>

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>

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>

arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Add a child SRAM node to reserve a portion of the MCU domain on-chip
SRAM memory for use by the MCU domain R5F Core0. A preliminary size
of 256 KB (half of the current SRAM) is reserved to begin with and
can be adjusted as per need.

This memory is also added to the R5F0 remoteproc node using the
sram property.

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

remoteproc/k3-r5: add loading support for on-chip SRAM regions

The K3 SoCs has various internal on-chip SRAM memories like the SRAM
within the MCU domain or the shared MSMC RAM within NavSS that can be
used for multiple purposes. One such purpose is to have the R5F cores
to use a portion of such on-chip SRAM for fast-access data or to
directly execute code.

Add support to the K3 R5 remoteproc driver to parse and support
loading into such memories.

These SRAM regions are completely optional as not all firmware images
require these memories, and any such memory has to be reserved as such
in the DTS files.

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

dt-bindings: remoteproc: k3-r5f: Update bindings for on-chip SRAM support

The K3 SoCs have various internal on-chip SRAM memories like the SRAM
within the MCU domain or the shared MSMC RAM within NavSS that can be
used for multiple purposes. One such purpose is to have the MCU domain
R5F cores to use a portion of such on-chip SRAM for executing code.

Update the K3 R5F remoteproc bindings to add the properties required to
support the optional on-chip SRAM loading support.

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

arm64: dts: ti: k3-am65: Add aliases for R5F rproc nodes

Add aliases for both the R5F remoteproc processor cores present
within the MCU domain and common to all K3 AM65x boards. The aliases
uses the stem "rproc". Note that the R5F1 core and it's alias is
uniquely identified and used only if the R5F cluster/subsystem is
running in Split (non-LockStep) mode.

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

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

arm64: dts: ti: k3-am654-base-board: Add DDR carveout memory nodes for R5Fs

The R5F processors do not have an MMU, and as such require the exact memory
used by the firmwares to be set-aside. Four carveout reserved memory nodes
have been added with two each (1 MB and 15 MB in size) used for each of the
MCU R5F remote processor devices on all the K3 AM65x boards. These nodes
are assigned to the respective rproc device nodes as well.

The current carveout addresses and sizes are defined statically for each
device. The first region will be used as the DMA pool for the rproc
devices, and the second region will furnish the static carveout regions
for the firmware memory.

Note that the R5F1 carveouts are needed only if the corresponding R5F
cluster is running in Split (non-LockStep) mode. The corresponding
reserved memory nodes can be disabled later on if there is no use-case
defined to use the corresponding remote processor.

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

arm64: dts: ti: k3-am65-mcu: Add MCU domain R5F cluster node

The AM65x SoCs have a single dual-core Arm Cortex-R5F processor (R5FSS)
subsystem/cluster. This R5F cluster (MCU_R5FSS0) is present within the
MCU domain, and can be configured at boot time to be either run in a
LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in
Split-mode. This subsystems has 64 KB each Tightly-Coupled Memory (TCM)
internal memories for each core split between two banks - TCMA and TCMB
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5F clusters such as the absence of an ACP
port, presence of an additional TI-specific Region Address Translater
(RAT) module for translating 32-bit CPU addresses into larger system
bus addresses etc.

Add the DT node for this R5F cluster/subsystem, the two R5F cores are
added as child nodes to the main cluster node. The cluster is configured
to run in LockStep mode by default, with the ATCMs enabled to allow the
R5 cores to execute code from DDR with boot-strapping code from ATCM.
The inter-processor communication between the main A53 cores and these
processors is achieved through shared memory and Mailboxes.

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

arm64: dts: ti: k3-am65: add R5F ranges in interconnect nodes

Add the address spaces for the R5F cores in MCU domain to the ranges
property of the cbass_mcu interconnect node so that the addresses
within the R5F nodes can be translated properly by the relevant OF
address API.

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

HACK: remoteproc: silence devmem error for rprocs with no MMU

The R5F remote processors on K3 AM65x SoCs do not have an MMU, but
the current firmware images still use a TYPE_DEVMEM entry for the
initial 1 MB of the device carveout pool (akin to the usage on the
DRA7xx/AM57xx SoCs). This entry is currently exercised by the firmware
code to perform some address translations, but the current error
check fails to load such firmwares. Silence the error for the
time being to successfully load such firmwares.

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

remoteproc/k3-r5: add a remoteproc driver for R5F subsystem

The AM65x SoCs have a single dual-core Arm Cortex R5F processor cluster/
subsystem (R5FSS) in the MCU voltage domain. This R5F subsystem/cluster
can be configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem
has 64 KB each Tightly-Coupled Memory (TCM) internal memories for each
core split between two banks - TCMA and TCMB (further interleaved into
two banks). The subsystem does not have an MMU, but has a Region Address
Translater (RAT) module that is accessible only from the R5Fs for providing
translations between 32-bit CPU addresses into larger system bus addresses.

Add a remoteproc driver to support this subsystem to be able to load and
boot the R5F cores primarily in LockStep mode. The code also includes the
base support for Split mode. Error Recovery and Power Management features
are not currently supported. Loading support includes the internal TCMs
and DDR. RAT support is left for a future patch, and as such the reserved
memory carveout regions are all expected to be using memory regions within
the first 2 GB.

The R5F remote processors do not have an MMU, and so require fixed memory
carveout regions matching the firmware image addresses. Support for this
is provided by mandating multiple memory regions to be attached to the
remoteproc device. The first memory region will be used to serve as the
DMA pool for all dynamic allocations like the vrings and vring buffers.
The remaining memory regions are mapped into the kernel at device probe
time, and are used to provide address translations for firmware image
segments without the need for any RSC_CARVEOUT entries. Any firmware
image using memory outside of the supplied reserved memory carveout
regions will be errored out.

The R5F processors on TI K3 SoCs require a specific sequence for booting
and shutting down the processors. This sequence is also dependent on the
mode (LockStep or Split) the R5F cluster is configured for. The R5F cores
have a Memory Protection Unit (MPU) that has a default configuration that
does not allow the cores to run out of DDR out of reset. This is resolved
by using the TCMs for boot-strapping code that applies the appropriate
executable permissions on desired DDR memory. The loading into the TCMs
requires that the resets be released first with the cores in halted state.
The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores
be in WFI/WFE states with no active bus transactions before the cores can
be put back into reset. Support for this is provided by using the newly
introduced .prepare() and .unprepare() ops in the remoteproc core. The
.prepare() ops is invoked before any loading, and the .unprepare() ops
is invoked after the remoteproc resource cleanup. The R5F core resets
are deasserted in .prepare() and asserted in .unprepare(), and the cores
themselves are started and halted in .start() and .stop() ops. This
ensures symmetric usage and allows the R5F cores state machine to be
maintained properly between using the sysfs 'state' variable, bind/unbind
and regular module load/unload flows.

The subsystem is represented as a single remoteproc in LockStep mode, and
as two remoteprocs in Split mode. The driver uses various TI-SCI interfaces
to talk to the System Controller (DMSC) for managing configuration, power
and reset management of these cores. IPC between the A53 cores and the R5
cores is supported through the virtio rpmsg stack using shared memory and
OMAP Mailboxes.

The driver expects the following firmware names to be used for these
cores:
    am65x-mcu-r5f0_0-fw (LockStep mode and for Core0 in Split mode)
    am65x-mcu-r5f0_1-fw (Core1 in Split mode)

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

remoteproc/k3-r5: add TI-SCI processor control helper functions

Texas Instruments' K3 generation SoCs have specific modules/register
spaces used for configuring the various aspects of a remote processor.
These include power, reset, boot vector and other configuration features
specific to each compute processor present on the SoC. These registers
are managed by the System Controller such as DMSC on K3 AM65x SoCs.

The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used to communicate to the System Controller from various compute
processors to invoke specific services provided by the firmware running
on the System Controller.

Add a common processor control interface header file that can be used by
multiple remoteproc drivers. The helper functions within this header file
abstract the various TI SCI protocol ops for the remoteproc drivers, and
allow them to request the System Controller to be able to program and
manage various remote processors on the SoC. The remoteproc drivers are
expected to manage the life-cycle of their ti_sci_proc_dev local
structures.

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

dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

The Texas Instruments K3 family of SoCs have one of more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.

The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.

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: use a local copy for the name field

The current name field used in the remoteproc structure is simply
a pointer to a name field supplied during the rproc_alloc() call.
The pointer passed in by remoteproc drivers during registration is
typically a dev_name pointer, but it is possible that the pointer
will no longer remain valid if the devices themselves were created
at runtime like in the case of of_platform_populate(), and were
deleted upon any failures within the respective remoteproc driver
probe function.

So, allocate and maintain a local copy for this name field to
keep it agnostic of the logic used in the remoteproc drivers.

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

remoteproc: add prepare and unprepare ops

On some SoC architecture, it is needed to enable HW like
clock, bus, regulator, memory region... before loading
co-processor firmware.

This patch introduces prepare and unprepare ops to execute
platform specific function before firmware loading and after
stop execution.

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
[s-anna@ti.com: cherry-pick linux-remoteproc patchwork id '10251897']
Signed-off-by: Suman Anna <s-anna@ti.com>

Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into topic/4.19/am65x

Resync/pull in the latest platform base tree (golden/vanilla equivalent
patches) into the AM65x remoteproc topic branch. The merge pulls in
the necessary TI-SCI processor control API and the MCU SRAM support on
AM65x SoCs. Also included are few important TI-SCI clock fixes and
crypto patches.

This merges establishes the baseline to allow the R5F remoteproc driver
support to be added on K3 AM65x platforms. The OMAP Mailbox support for
K3 platforms and the board support for various AM65x boards is already
available in the topic branch with the previous mailbox feature branch
merge.

* platform-ti-linux-4.19.y: (23 commits)
  clk: keystone: sci-clk: add support from parsing clock info from DT
  dt-bindings: clock: ti,sci-clk: Add support for parsing clock info from DT
  soc: ti: Add TI_MESSAGE_MANAGER to default K3 AM65x SoC options
  firmware: ti_sci: Add support for processor control
  arm64: dts: ti: k3-am65-mcu: Add the MCU RAM node
  arm64: dts: ti: k3-am65: add MCU SRAM ranges in interconnect nodes
  kbuild: dtbinst: Install overlays
  dmaengine: ti: k3-udma: Fix compiler warning in udma_get_chan_pair
  clk: keystone: sci-clk: add slack to clk-set-rate passed to firmware
  clk: keystone: sci-clk: increase the max gap size to 50 for clk ids
  HACK: firmware: ti_sci: increase timeout to 10000ms
  arm64: dts: ti: am6: Add the trng node
  char: hwrng: Kconfig: Or ARCH_K3 dependency for HW_RANDOM_OMAP
  arm64: dts: k3-am6: Add crypto accelarator node
  sa2ul: Add 3DES ECB & CBC Mode support
  crypto: sa2ul: Add hmac(sha256) HMAC algorithm support
  crypto: sa2ul: Add hmac(sha1) HMAC algorithm support
  crypto: sa2ul: Add hmac(sha256)cbc(aes) AEAD Algo support
  crypto: sha256_generic: Export the Transform function
  crypto: sa2ul: Add aead support for hmac(sha1)cbc(aes) algorithm
  ...

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

arm64: dts: ti: k3-am65-main: Add ICSSG MDIO nodes

The ICSSGs on K3 AM65x SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.

The nodes are added to the common k3-am65-main.dtsi file and are
disabled. These need to be enabled in the respective board files
supporting AM654 SoCs and where the ethernet is pinned out and
connected properly.

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

arm64: dts: ti: k3-am65-main: Add mii-g-rt nodes in ICSSG

MII_G_RT is a new block that comes with ICSSG. Add it to all the
ICSSG instances on AM65x SoCs.

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

arm64: dts: ti: k3-am65-main: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU and RTU node in each of the ICSSG0, ICSSG1 and ICSSG2 remote
processor subsystems to enable the virtio/rpmsg communication
between MPU and that PRU/RTU core. The additions are done in the
base k3-am65-main.dtsi, and so are inherited by all the K3 AM65x
boards.

The PRU system events is the preferred approach over using TI
mailboxes, as it eliminates an external peripheral access from
the PRU/RTU-side, and keeps the interrupt generation internal to
the ICSSG. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired, but currently there is
no support on firmware-side for K3 SoCs to use mailboxes. Either
approach would require that an appropriate firmware image is
loaded/booted on the PRU.

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

arm64: dts: ti: k3-am65-main: Add ICSSG nodes

Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM65x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a pruss-soc-bus node and a child PRUSS subsystem node.
These nodes are enabled by default.

The ICSSGs on K3 AM65x SoCs are super-sets of the PRUSS on the AM57xx/
6AK2G SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS
crossbar. They include two auxiliary PRU cores called RTUs and few other
additional sub-modules. The interrupt integration is also different on
the K3 AM65x SoCs and are propagated through various SoC-level Interrupt
Router and Interrupt Aggregator blocks.

The ICSSG subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the ICSSG are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU/RTU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU/RTU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU and RTU core
are defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
  ICSSG0 PRU0 Core: am65x-pru0_0-fw ; ICSSG0 RTU0 Core: am65x-rtu0_0-fw
  ICSSG0 PRU1 Core: am65x-pru0_1-fw ; ICSSG0 RTU1 Core: am65x-rtu0_1-fw
  ICSSG1 PRU0 Core: am65x-pru1_0-fw ; ICSSG1 RTU0 Core: am65x-rtu1_0-fw
  ICSSG1 PRU1 Core: am65x-pru1_1-fw ; ICSSG1 RTU1 Core: am65x-rtu1_1-fw
  ICSSG2 PRU0 Core: am65x-pru2_0-fw ; ICSSG2 RTU0 Core: am65x-rtu2_0-fw
  ICSSG2 PRU1 Core: am65x-pru2_1-fw ; ICSSG2 RTU1 Core: am65x-rtu2_1-fw

TODO:
Add sub-nodes for new additional sub-modules like IEP2, MII_RT2 etc.

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

soc: ti: pruss: Configure different internal ICSSG source clocks

The ICSSG processor subsystems has multiple functional and interface
clock inputs like CORE_CLK, IEP_CLK, UART_CLK, ICLK etc that are sourced
from different PLLs and run at different frequences. Some of these
input clocks are configurable through external muxes, while further
muxing can be achieved on the actual internal ICSSG Core and IEP clocks
used by the ICSSG sub-modules through registers in the CFG space to
choose between the different IP-level input clocks.

The default functional source clock for IEP module within ICSSG
instances on K3 AM65x SoCs is CPSWHWDIV_CLKOUT2, which runs at a
frequency of 200 MHz. The default CORE_CLK is derived from
PER1HSDIV_CLKOUT1 and runs at a frequency of 225 MHz. The ICLK
is derived from the SYSCLK0 and runs at a frequency of 250 MHz.

Configure the internal clock muxes so that both the internal ICSSG
Core Clock and the IEP functional clock are sourced from the ICLK
(VBUSP Clock) clock input so that they run at identical speeds and
at the highest frequency of 250 MHz. This one-time configuration is
performed during the probe (resetting would require a hardware reset
of the ICSSG). This is required to get the lowest latency and achieve
high speed for various ICSSG functionalities (eg: mandatory for
achieving 1G speeds on the ICSSG Ethernet ports).

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

remoteproc/pru: Add support for various PRU cores on K3 AM65x SoCs

The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem contain two primary PRU cores and two new auxiliary PRU cores
called RTUs. Each RTU core has its own dedicated IRAM (smaller than a
PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, but can also be used to run
independent applications. The RTU cores though share the same Data RAMs
as the PRU cores, so the memories have to be partitioned carefully
between different applications. The new cores also support a new
sub-module called Task Manager to support two different context thread
executions.

Enhance the existing PRU remoteproc driver to support these new PRU
and RTU cores by using specific compatibles. The initial names for the
firmware images for each PRU core are retrieved from DT nodes, and can
be adjusted through sysfs if required.

The PRU remoteproc driver has to be specifically modified to use a
custom ELF loader implementation for these new cores in order to
overcome a limitation with copying data into each of the core's IRAM
memories. These memory ports support only 4-byte writes, and any
sub-word order byte writes clear out the remaining bytes other than
the bytes being written within the containing word. The default ARM64
memcpy also cannot be used as it throws an exception when the preferred
8-byte copy operation is attempted.

The ICSSG instances on AM65x SoCs also have more System Events, Interrupt
Channels and Host Interrupts compared to the previous generation PRUSS
instances on other SoCs. The logic in pru_rproc_get() function to parse
and program the interrupts from DT is also updated to use proper values
relevant for K3 SoCs by using a state flag that is set only on K3 SoCs.
This can be reworked to use match data to scale beyond current SoCs if
needed.

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

remoteproc/pru: Introduce new vendor interrupt resource for K3 AM65x SoCs

The PRU-ICSS IP present within K3 AM65x SoCs, commonly called ICSSG, has
an INTC that supports more System Events (160 vs 64), more Interrupt
Channels and Host Interrupts (20 vs 10) compared to the current generation
PRUSS INTC instances. The current custom vendor interrupt resource
configuration used by the pru_rproc driver is not adequate to support
this ICSSG INTC.

Add a new version of the custom vendor interrupt resource named
fw_rsc_custom_intrmap_k3 and enhance the pru_handle_vendor_intrmap()
function to add support for configuring this newer INTC sub-module.
This new resource structure is a revised version of the existing
fw_rsc_custom_intrmap resource, with additional fields for the
increased number of channels. Support for both resource types is
provided through the PRUSS_RSC_INTRS vendor resource type and
distinguished using a version field in the sub_type.

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

dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SoCs

The K3 AM65x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. The ICSSG IP on K3 SoCs has two PRU cores and two additional
custom PRU cores called Real Time Units (RTUs). Update the PRU binings
for these newer generarion ICSSG instances.

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

irqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs

The K3 AM65x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. The PRUSS INTC present within the ICSSG supports more
System Events (160 vs 64), more Interrupt Channels and Host Interrupts
(20 vs 10) compared to the current generation PRUSS INTC instances.

Enhance the PRUSS INTC driver to add support for this ICSSG INTC
instance. This support is adding using SoC-specific data and updating
the code to use this data instead of the current hard-coded macros.
The INTC config structure is updated to use the higher events and
channels on all SoCs, while limiting the actual processing to only
the relevant number of events/channels/interrupts.

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

dt-bindings: irqchip: pruss-intc: Update bindings for K3 AM65x SoCs

The K3 AM65x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. The ICSSG interrupt controller on K3 SoCs provide a higher
number of host interrupts (20 vs 10) and can handle an increased number
of input events (160 vs 64) from various SoC interrupt sources. Update
the PRUSS interrupt controller binings for these newer generarion ICSSG
instances.

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

soc: ti: pruss: enable support for ICSSG subsystems on K3 AM65x SoCs

The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem capable of supporting Gigabit Ethernet, and is
commonly referred to as ICSSG. These SoCs contain typically three
ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are
identical to each other for the most part with minor SoC integration
differences and capabilities. The ICSSG2 supports slightly enhanced
features like SGMII mode Ethernet, while the ICSS0 and ICSSG1 instances
are limited to MII mode only.

The ICSSGs on K3 AM65x SoCs are in general super-sets of the PRUSS on the
AM57xx/66AK2G SoCs. They include two additional auxiliary PRU cores called
RTUs and few other additional sub-modules. The interrupt integration is
also different on the K3 AM65x SoCs and are propagated through various
SoC-level Interrupt Router and Interrupt Aggregator blocks. Other IP level
differences include different constant tables, differences in system event
interrupt input sources etc. They also do not have a programmable module
reset line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.

The existing pruss_soc_bus and pruss platform drivers have been updated to
support these new ICSSG instances through new AM65x specific compatibles.
A build dependency with ARCH_K3 is added to enable building all the
existing PRUSS platform drivers for this ARMv8 platform.

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

dt-bindings: soc: ti: pruss: Update bindings for K3 AM65x SoCs

The K3 AM65x SoCs have the next generation of the PRU-ICSS IP, commonly
called ICSSG. The ICSSG IP on K3 SoCs has couple of additional sub-modules
(two IEP and MII_RT sub-modules each vs one, a new MII_G_RT sub-module)
w.r.t previous generation PRU-ICSS IPs. Update the PRUSS bindings for
these newer ICSSG instances including the info for MII_G_RT.

NOTE:
- The usage of the second IEP and MII_RT sub-module instances are yet
  to be determined, and so are yet to be added.

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

remoteproc/pru: use macros and types from omap mailbox

The actual payload size for OMAP Mailboxes is 32-bits, and the type
to use with the OMAP Mailbox driver is mbox_msg_t. This type can vary
in size (32-bits or 64-bits) depending on the platform the driver is
being built for. Update the PRU remoteproc driver to use the types and
macros provided by the OMAP Mailbox driver to always convert safely
between the mailbox payload size and the pointers the data is exchanged
between the OMAP Mailbox implementation driver and its client drivers.

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

Pull in the mailbox feature branch into a new topic remoteproc branch
dedicated for adding remoteproc support patches for the remote processors
present on K3 AM65x SoCs. The merge brings in the base platform and board
support for K3 AM65x SoCs, including the support for the Mailbox IP present
within the Main NavSS sub-module on K3 AM65x SoCs.

* 'mailbox-linux-4.19.y' of git://git.ti.com/rpmsg/mailbox: (134 commits)
  dt-bindings: mailbox: omap: Update example for TI K3 AM65x SoCs
  arm64: dts: ti: k3-am65-main: Rename IPC sub-mailboxes
  arm64: dts: ti: k3-am65-main: Add IPC sub-mailbox nodes for R5Fs
  arm64: dts: ti: k3-am65-main: Add mailbox cluster nodes
  ti_config_fragments: v8_rpmsg: Enable OMAP Mailbox support
  mailbox/omap: add support for TI K3 SoCs
  dt-bindings: mailbox: omap: Update bindings for TI K3 AM65x SoCs
  ti_config_fragments: v8_defconfig_map: Add v8 rpmsg config file
  ti_config_fragments: v8_rpmsg: Add RPMsg domain config fragment file
  ti_config_fragments: defconfig_map: Include RPMsg config fragment
  ti_config_fragments: rpmsg: Add RPMsg domain config fragment file
  dmaengine: ti: k3-udma: Try to use the highest TPL channels for MEM_TO_MEM
  dmaengine: ti: k3-udma: Only allow MEM_TO_MEM transfer on the main UDMA
  ti_config_fragments/defconfig_map.txt: add missing baseport.cfg entries
  ti_config_fragments: v8_baseport: Forward port v8_baseport cfg from 4.14
  arm64: dts: ti: k3-am6: Add NAVSS and PDMA nodes
  dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
  dmaengine: ti: New driver for K3 UDMA
  dmaengine: ti: Add cppi5 header for UDMA
  dt-bindings: dma: ti: Add document for K3 UDMA
  ...

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>

soc: ti: pruss: add helper functions to get/set PRUSS_CFG_GPMUX

Add two new helper functions pruss_cfg_get_gpmux() & pruss_cfg_set_gpmux()
to get and set the GP MUX mode for programming the PRUSS internal wrapper
mux functionality as needed by usecases.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: reuse pruss_regmap functions and inline them]
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: add helper functions to set GPI mode, MII_RT_event and XFR

The PRUSS CFG module is represented as a syscon node and is currently
managed by the PRUSS platform driver. Add easy accessor functions to set
GPI mode, MII_RT event enable/disable and XFR (XIN XOUT) enable/disable
to enable the PRUSS Ethernet usecase. These functions reuse the generic
pruss_regmap_update() API function.

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

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

Add two new generic API pruss_regmap_read() and pruss_regmap_update()
to the PRUSS platform driver to allow other drivers to read and program
respectively a register within one of the PRUSS sub-modules represented
by a syscon driver. The sub-modules include PRUSS CFG, IEP and MII_RT
at present. This interface provides a simple way for client drivers
without having them to include and parse these syscon nodes within
their respective device nodes. Various useful registers (mainly CFG
module) and macros for certain register bit-fields and their values
have also been added.

It is the responsibility of the client drivers to reconfigure or
reset a particular register upon any failures.

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

soc: ti: pruss: add pruss_{request,release}_mem_region() API

Add two new API - pruss_request_mem_region() & pruss_release_mem_region(),
to the PRUSS platform driver to allow client drivers to acquire and release
the common memory resources present within a PRU-ICSS subsystem. This
allows the client drivers to directly manipulate the respective memories,
as per their design contract with the associated firmware.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: rename functions, add error checking, comments]
Signed-off-by: Suman Anna <s-anna@ti.com>

soc: ti: pruss: add pruss_get()/put() API

Add two new get and put API, pruss_get() and pruss_put(), to the
PRUSS platform driver to allow client drivers to request a handle
to a PRUSS device. This handle will be used by client drivers to
request various operations of the PRUSS platform driver through
additional API that will be added in the following patches.

The pruss_get() function returns the pruss handle corresponding
to a PRUSS device referenced by a PRU remoteproc instance. The
pruss_put() is the complimentary function to pruss_get().

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: various fixups and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: add pru_rproc_get_id() API to retrieve the PRU id

Export an API pru_rproc_get_id() to allow other PRUSS platform
drivers to clients to retrieve the PRU id from a remoteproc handle
associated with a PRU. The new function takes in a struct rproc
pointer as argument.

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

remoteproc/pru: add support for parsing pru interrupt mapping from DT

PRU interrupt mapping can now be parsed from devicetree also. The design
uses a single property "ti,pru-interrupt-map" in the PRU consumer nodes
to list all the interrupt mapping data associated with all the PRUs used
by the PRU consumer/application. This is an alternative configuration
method in addition to the legacy resource table config, and supercedes
any firmware provided intc configuration structure.

The design parses and configures the PRU INTC when a client driver
acquires a PRU core through pru_rproc_get(), and unconfigures the INTC
when it releases the PRU core through pru_rproc_put(). The design also
allows any referenced PRU cores with zero corresponding entries in the
"ti,pru-interrupt-map" property to fallback to use the interrupt mapping
data through the firmware intc vendor resource type, that is processed
during the loading/starting of the core through rproc_boot(). This
provides the maximum flexibility for PRU client drivers/applications.
If both are provided, the config in DT takes precedence. It is possible
that a client neither has the DT property nor uses the vendor resource
in its firmware, implying that particular PRU core doesn't use/need any
interrupts.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rogerq@ti.com: refactor DT-parse logic into a separate function]
Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: various fixes and cleanups, update patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: configure firmware based on client setup

Client device node property firmware-name is now used to configure
firmware for the PRU instances. The default firmware is also
restored once releasing the PRU resource.

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

remoteproc/pru: Add pru_rproc_set_ctable() function

Some firmwares expect the OS drivers to configure the CTABLE
entries publishing dynamically allocated memory regions. For
example, the PRU Ethernet firmwares use the C28 and C30 entries
for retrieving the Shared RAM and System SRAM (OCMC) areas
allocated by the PRU Ethernet client driver.

Provide a way for users to do that through a new API,
pru_rproc_set_ctable(). The API returns 0 on success and
a negative value on error.

NOTE:
The programmable CTABLE entries are typically re-programmed by
the PRU firmwares when dealing with a certain block of memory
during block processing. This API provides an interface to the
PRU client drivers to publish a dynamically allocated memory
block with the PRU firmware using a CTABLE entry instead of a
negotiated address in shared memory. Additional synchronization
may be needed between the PRU client drivers and firmwares if
different addresses needs to be published at run-time reusing
the same CTABLE entry.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: add the NOTE: on patch description, minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

remoteproc/pru: deny rproc sysfs ops for PRU client driven boots

The PRU remoteproc driver is not configured for 'auto-boot' by default,
and allows to be booted either by in-kernel PRU client drivers or by
userspace using the generic remoteproc sysfs interfaces. The sysfs
interfaces should not be permitted to change the remoteproc firmwares
or states when a PRU is being managed by an in-kernel client driver.
Use the newly introduced remoteproc generic 'deny_sysfs_ops' flag to
provide these restrictions by setting and clearing it appropriately
during the PRU acquire and release steps.

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

remoteproc/pru: add APIs to get and put the PRU cores

Add two new APIs, pru_rproc_get() and pru_rproc_put(), to the PRU
driver to allow client drivers to acquire and release the remoteproc
device associated with a PRU core. The PRU cores are treated as
resources with only one client owning it at a time.

The pru_rproc_get() function returns the rproc handle corresponding
to a PRU core identified by the device tree "prus" property under
the client node. The pru_rproc_put() is the complementary function
to pru_rproc_get().

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: improve error checking, various fixes and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>

dt-bindings: remoteproc: pru: Document application node bindings

Add documentation for the common properties that can be used by the
PRU consumer/application nodes and supported by the PRU remoteproc
driver. These are used to configure the PRU hardware for specific
user applications.

The application nodes themselves should define their own bindings.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: some binding updates]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: keystone-k2g: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
keystone-k2g.dtsi file, and so are inherited by all 66AK2G boards.

The PRU system events is the preferred approach over using the
alternate IPCGR registers, as it eliminates an external MMR access
from the PRU-side, and keeps the interrupt generation internal to
the PRUSS. The difference from MPU would be minimal in using one
versus the other. Note that the 66AK2G SoCs do not have the OMAP
Mailbox IP, so there is no option of using mailboxes.

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

ARM: dts: DRA7: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS1 and PRU-ICSS2 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
dra7.dtsi file, and so are inherited by all the AM57xx boards.
Do note that PRUSS is not available/supported on the DRA7xx SoCs
SoCs and is only limited to the AM57xx SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

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

ARM: dts: AM4372: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the base am4372.dtsi
file, and so are inherited by all the AM437x boards. Do note that
PRUSS is not available on all AM437x SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

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

ARM: dts: AM33xx: Add PRU system events for virtio

Two PRU system events "vring" and "kick" have been added to each
of the PRU nodes in the PRU-ICSS remote processor subsystem to
enable the virtio/rpmsg communication between MPU and that PRU
core. The additions are done in the base am33xx.dtsi file, and
so are inherited by all the AM33xx boards. Do note that PRUSS
is not available on all AM335x SoCs.

The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.

Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.

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

remoteproc/pru: Add support for virtio rpmsg stack

The PRU remoteproc driver has been enhanced to support the optional
rpmsg stack using the virtio-ring based communication transport
between MPU and a PRU core. This provides support to any firmware
images supporting the virtio devices.

The virtio-ring signalling support is provided either through a OMAP
mailbox or through two PRU system events on OMAP-architecture based
SoCs - one event used in each direction for kicking from one processor
and receiving notification on the other processor. The virtio rpmsg
signalling is enabled only using using PRU system events for interrupts
on the Keystone-architecture based 66AK2G SoCs (it is possible to
implement using an alternate Keystone specific IPCGR registers as well).
The driver supports both signalling options, though the PRU events based
signalling is the recommended option as it avoids an external peripheral
access from the PRU side. It also provides a uniform solution across
both the OMAP, Keystone and Davinci architectures. The PRU events based
signalling takes precedence if both options are mentioned. Either of the
options would require the corresponding firmware support though. A build
dependency against MAILBOX is also added. Note that the OMAP Mailbox
IP is not present on 66AK2G and Davinci SoCs, so it is only selected
for OMAP-based SoCs.

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

dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg

Update the PRU remoteproc DT bindings to add the properties required
to support the optional virtio rpmsg stack using the virtio-ring based
communication transport between MPU and a PRU core.

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

ARM: dts: keystone-k2g: Add PRUSS GPIO controller nodes

Add the PRUSS GPIO controller nodes on the 66AK2G SoC. These can
be used to send interrupts to specific PRUSS subsystem instances
present on the SoC. Each PRUSS is capable of receiving an interrupt
each from two such nodes. The IP is identical to that of the
equivalent node for the DSP present on 66AK2G SoC.

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

ARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes

The PRUSSs on 66AK2G SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each PRUSS. The MDIO module used
within the PRU-ICSS is an instance of the MDIO Controller used
in TI Davinci SoCs. The same bus frequency of 2.5 MHz is chosen
as the regular MDIO node.

The nodes are added to the common keystone-k2g dts file and are
disabled. These need to be enabled in the respective board files
supporting 66AK2G SoCs and where the ethernet is pinned out and
connected properly.

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

ARM: dts: keystone-k2g: Add the PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS0 and PRU-ICSS1 processor subsystems
that are present on the 66AK2G SoC. The two PRU-ICSSs are identical
to each other. Each PRU-ICSS instance is represented by a pruss-soc-bus
node and a child PRUSS subsystem node. These nodes are enabled by
default.

The PRU-ICSSs on 66AK2G are very similar to the PRUSS on the AM57xx
SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS
crossbar. There are also few other minor integration differences
w.r.t IPC mechansims that can be attributed to the architecture
differences between Keystone and OMAP families.

The PRUSS subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
    PRU-ICSS0 PRU0 Core: k2g-pru0_0-fw
    PRU-ICSS0 PRU1 Core: k2g-pru0_1-fw
    PRU-ICSS1 PRU0 Core: k2g-pru1_0-fw
    PRU-ICSS1 PRU1 Core: k2g-pru1_1-fw

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

ARM: dts: am57xx-idk-common: Enable PRU-ICSS nodes

The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes (both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the AM571x, AM572x and AM574x IDK boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: beagle-x15-common: Enable PRU-ICSS nodes

The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes ((both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the BeagleBoard-X15 and AM57xx GP EVM boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants

The AM57xx family of SoCs have two PRU-ICSS remote processor
subsystems, each supporting two PRU processor cores. These
subsystems are not supported on the DRA7 family of SOCs. They
are very similar to the respective processor subsystems on
AM33xx/AM43xx SoCs except for a few differences. The relevant
hwmod classes and data structures have been added for the
PRU-ICSS1 and PRU-ICSS2 subsystems to enable support for
these on the AM57xx SoC variants.

Do note that these subsystems do not have a programmable module
reset line unlike those present in AM33xx/AM43xx. The modules
are reset just like any other IP with the SoC's global cold/warm
resets.

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

ARM: dts: DRA7: Add PRUSS MDIO controller nodes

The PRUSSs on AM57xx SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each PRUSS. The MDIO module used
within the PRU-ICSS is an instance of the MDIO Controller used
in TI Davinci SoCs. The same bus frequency of 1 MHz is chosen as
the regular MDIO node.

The nodes are added to the common DRA7 dts file and are disabled.
These need to be enabled in the respective board files supporting
AM57xx SoCs and where the ethernet is pinned out and connected
properly.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: DRA7: Add the PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor subsystems
that are present on AM57xx family of SoCs. Each PRU-ICSS instance is
represented by a pruss-soc-bus node and a child PRUSS subsystem node.
The two PRU-ICSSs are identical to each other. They are not supported
on DRA7xx SoCs in general, so the nodes are added in disabled state
to the common dra7 DTS file. They should be enabled only in the AM57xx
related board files.

The PRU-ICSSs on AM57xx are very similar to the PRUSS in AM33xx and
AM437x except for variations in the RAM sizes and the number of
interrupts coming into the MPU INTC. The interrupt events into the
PRU-ICSS also requires programming of the corresponding crossbars
properly.

The PRUSS subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
    PRU-ICSS1 PRU0 Core: am57xx-pru1_0-fw
    PRU-ICSS1 PRU1 Core: am57xx-pru1_1-fw
    PRU-ICSS2 PRU0 Core: am57xx-pru2_0-fw
    PRU-ICSS2 PRU1 Core: am57xx-pru2_1-fw

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

ARM: dts: am437x-idk: Enable PRU-ICSS nodes

The AM437x IDK board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am437x-sk: Enable PRU-ICSS nodes

The AM437x SK EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am437x-gp-evm: Enable PRU-ICSS nodes

The AM437x GP EVM board uses a AM437x SoC that supports two PRU-ICSS
instances. The PRU-ICSS processor bus nodes and subsystem nodes were
left in disabled state in the base am4372.dtsi file. All these nodes
(both PRU-ICSS1 and PRU-ICSS0 instances) have been enabled now. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: OMAP2+: extend pruss pdata-quirks to AM437x SoCs

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly.

AM437x requires the same functional reset management with PRUSS
as on AM33xx, so extend the AM33xx pruss pdata quirks to AM437x
as well. AM33xx relied on pdata quirks and platform data ops for
the PRUSS IP, to plumb the required omap_device API with the PRUSS
SoC bus driver ops to achieve the required reset functionality.
This was implemented in this fashion as there is no separate reset
driver at the moment.

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

ARM: dts: AM4372: Add PRUSS MDIO controller node

The PRU-ICSS1 instance on AM437x SoCs has a MDIO sub-module that
can be used to control external PHYs associated with the Industrial
Ethernet peripherals within the PRUSS. The MDIO module used within
this PRU-ICSS is an instance of the MDIO Controller used in TI
Davinci SoCs. The same bus frequency of 1 MHz is chosen as the
regular MDIO node. Note that there is no MDIO node added to the
smaller PRU-ICSS0 instance as the MDIO pins are not pinned out.

The node is added to the common am4372 dtsi file and is disabled.
This needs to be enabled in the respective board files using the
relevant AM437x SoCs supporting PRUSS and where the ethernet is
pinned out and connected properly.

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: fix reg address, add commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: AM4372: Add the PRU-ICSS0 DT node

The AM437x SoC has a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 has less
DRAM per PRU, and no Shared DRAM among other minor differences.
The IEP and MII_RT modules even though present within the IP are
are not pinned out.

This PRUSS0 instance has a weird SoC integration. It shares the
same L3 OCP interconnect interface with PRUSS1, and also shares
its reset line and clocks. Any external accesses from PRUSS0
requires the PRUSS1's PRUSS_SYSCFG register to be programmed
properly. That said, it is its own IP instance (a cut-down version),
and so it has been added as an independent node (sibling node to
PRUSS1 node) and a child node of the PRUSS SoC bus node. This
allows the PRUSS0 instance to be enabled/disabled independently
of the PRUSS1 instance.

The nodes are added in disabled state as not every SoC in the
AM437x family has the PRU-ICSSs (AM4372 SoC lacks the support).
They need to be enabled in the respective board dts file based
on the SoC being used.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS0 PRU0 Core: am437x-pru0_0-fw
     PRU-ICSS0 PRU1 Core: am437x-pru0_1-fw

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

ARM: dts: AM4372: Add the PRU-ICSS1 DT node

Add the DT node for the PRU-ICSS1 instance on the AM437x family
of SoCs. Each PRU-ICSS instance is represented by the pruss-soc-bus
node and a child PRUSS subsystem node. The PRU-ICSS instances are
not supported on AM4372 SoC though in the AM437x family, so the
nodes are added in disabled state in the common am4372 dtsi file.
They should be enabled in only those derivative board files that
use a SoC containing PRU-ICSS.

The PRU-ICSS1 on AM437x is very similar to the PRUSS in AM33xx,
except for variations in the RAM sizes, bus addresses and the
number of interrupts coming into the MPU INTC (host interrupt
7 is routed to the other PRUSS instead of MPU).

The PRUSS subsystem node contains the entire address space and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child node
of its own named 'memories' without any compatible.

The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.

The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
     PRU-ICSS1 PRU0 Core: am437x-pru1_0-fw
     PRU-ICSS1 PRU1 Core: am437x-pru1_1-fw

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

ARM: dts: am335x-icev2: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x ICEv2 board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-evmsk: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x SK EVM board, so enable both these PRU-ICSS nodes. The
PRU nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-evm: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. PRU-ICSS is supported
on the AM335x EVM, so enable both these PRU-ICSS nodes. The PRU
nodes are already enabled in the base dts file, and so become
effective automatically with the enabling of these PRU-ICSS nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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

ARM: dts: am335x-bone-common: Enable PRU-ICSS nodes

The PRU-ICSS processor bus node and subsystem nodes were left in
disabled state in the base am33xx.dtsi file. Enable both these
PRU-ICSS nodes on all the AM335x beaglebone boards as they mostly
use a AM3358 or a AM3359 SoC which do contain the PRU-ICSS IP.
The PRU nodes are already enabled in the base dts file, and so
become effective automatically with the enabling of these PRU-ICSS
nodes.

The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.

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