This patch adds support for graceful shutdown of the K3 M4F remoteproc
driver on a stop command. On K3 SoCs, the remote processor needs to be
in a quiescent state, before a reset is asserted by the remoteproc
driver. This patch introduces a mailbox handshake mechanism between the
MPU and the remote processor to allow the remote processor to gracefully
shutdown its peripheral drivers and applications before entering a
quiescent state, which is typically entering 'wfi' with interrupts
disabled.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

This patch adds support for graceful shutdown of the TI remoteproc
driver on a stop command. On some TI SoCs, the remote processor
(ex: M4F on AM64/AM62 SoCs) needs to be in quiescent state, before a
reset is asserted. This patch introduces a mailbox handshake mechanism
between the MPU and the remote processor to allow the remote processor
to gracefully shutdown its peripherals and enter a quiescent state.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

Add support to the K3 DSP remoteproc driver to configure the C7xv
subsystem core on AM62A SoCs. The C7xv susbsytem is based on C71 DSP
with anlytics engine for deep learning purposes. The remoteproc
handling for device management is similar to the C66/C71 DSPs on K3
J7 family SoCs, even though there are additional hardware accelerators
and IP updates to C7xv subsystem.

Signed-off-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>

The TI AM62A SoCs have a C7xv DSP and Analytics engine for deep
learning purposes. The DSP part is similar to the C71x DSP found on
K3 J7 SoCs, but additional hardware accelerators and IP are added to
the subsystem for deep learning.

Compatible info is updated to match AM62A SoCs.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

AM62 and AM62A SoCs have a single core R5F subsystem. So, use the flag
'PROC_BOOT_CFG_FLAG_R5_SIGNLE_CORE' for boot configuration.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>

AM62x uses single core R5F which is a new scenario
different than existing ones.
Allow single core usage when compatible set to am62.

Tested IPC with DM R5 :
https://gist.github.com/devarsht/2ca1cfaedabd01aaa2b10579c83eae92



Signed-off-by: Devarsh Thakkar <devarsht@ti.com>

AM62x family of devices have single core DM R5F
so add new compatible for the same.

When this new compatible is used don't allow cluster-mode
property usage as there is no cluster involved and only
single R5F core is available.

Signed-off-by: Devarsh Thakkar <devarsht@ti.com>

Update the PRU remoteproc bindings for the PRU cores on AM62x SoCs.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Update the PRUSS bindings for the PRUSSM instance present in
AM625 SoC.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

The K3 AM62x family of SoC has one PRUSS-M instance and it has two
Programmable Real-Time Units (PRU0 and PRU1). This does not support
Industrial Communications Subsystem features like Ethernet.

Enhance the existing PRU remoteproc driver to support the PRU 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.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

The K3 AM62x family of SoC has one PRUSS-M instance and it has two
Programmable Real-Time Units (PRU0 and PRU1). This does not support
Industrial Communications Subsystem features like Ethernet.

The existing pruss platform driver has been updated to support this
through a new AM62x specific compatible.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

Trigger IOMMU during crash recovery sequence to reset IOMMU also.
Otherwise IOMMU may end up in a stale state, causing the remoteproc to
hang or crash again. This issue is particularly seen on DRA7xx/AM57xx
DSP remoteprocs.

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

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 232ba6ca

 ("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>

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. All the
trace entries are cleaned up during the resource cleanup phase when
shutting down a remoteproc. The design assumes that the same firmware
is being used for the error recovery.

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: Suman Anna <s-anna@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
[dfustini: resolved trivial conflicts for 5.10]
Signed-off-by: Drew Fustini <dfustini@baylibre.com>

The commit a987e6b9

 ("remoteproc: fix trace buffer va initialization")
computes the trace va given the trace device address every time a debugfs
read is done. This can be optimized to perform the lookup only the first
time, and store the value in the va field of the embedded rproc_mem_entry
structure for the debug trace. This restores how the trace va was stored
prior to the above commit in the original trace resource entry handling.

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

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

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

The K3 J721S2 SoCs have three dual-core R5F subsystems, one in MCU voltage
domain and the other two in MAIN voltage domain. These R5F clusters are
similar to the R5F clusters in J7200 SoCs.

Compatible Info is updated to support J721S2 SoCs.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain,
and there are no C66x DSP subsystems on these SoCs. The C71x DSP subsystem
is a slighly updated version of the C71x DSP subsystem on J721e. The
C71x DSPs are 64 bit machine with fixed and floating point DSP
operations.

Extend support to the C71x DSPs with J721S2 compatible strings.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

The TI K3 J721S2 SoCs have two TMS320C71x DSP subsystems, and does not
have any TMS320C66x DSP subsystems. The C71x DSP subsystem in J721S2
SoCs is a similar to the C71x DSP on J721e with some minor core IP updates.

Compatible info is updated for intuitvely matching to the new J721S2
SoCs.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Acked-by: Rob Herring <robh@kernel.org>

The TI K3 J721S2 SoCs have three dual-core Arm R5F clusters/subsystems,
with 2 R5F cores each, one in MCU voltage domain and the other two in
MAIN voltage domain.

These clusters are similar to J7200 R5F clusters. Compatible info is
updated for intuitively matching to the new J721S2 SoCs.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Acked-by: Rob Herring <robh@kernel.org>

A PRU system event "vring" has been added to each PRU and RTU node
in each of the ICSSG0 and ICSSG1 remote processor subsystems to enable
the virtio/rpmsg communication between MPU and that PRU/RTU core. No
events have been added to the Tx_PRU cores at present. The additions
are done in the base k3-j721e-main.dtsi, and so are inherited by all
the K3 J721E 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>

A PRU system event "vring" has 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>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

A PRU system event "vring" has 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 common am57-pruss.dtsi, and so are inherited by all the AM57xx
boards.

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, but currently there is no
support on firmware-side for the SoC to use mailboxes. Either approach
would require that an appropriate firmware image is loaded/booted on
the PRU.

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

A PRU system event "vring" has 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 am4372.dtsi, and so are inherited by all the AM437x boards.
Do note that PRUSS is available only on all AM4376+ 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, but currently there is no
support on firmware-side for the SoC to use mailboxes. Either approach
would require that an appropriate firmware image is loaded/booted on
the PRU.

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

A PRU system event "vring" has 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-l4.dtsi, and so are inherited by all the AM335x
boards. Do note that PRUSS is available only on all AM3356+ 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, but currently there is no
support on firmware-side for the SoC to use mailboxes. Either approach
would require that an appropriate firmware image is loaded/booted on
the PRU.

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

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 through two PRU system
events - one event used in each direction for kicking from one processor
and receiving notification on the other processor. It provides an
uniform solution across all the OMAP, Keystone and Davinci architectures.
The virtio-ring based communication requires the corresponding firmware
support though.

Because the vring irq mappings described in DT may conflict with
some PRU client irq mappings described in DT, move part responsible for
gathering vring irq to pru_rproc_start stage and perform it only if
rvdevs are present.

Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
[grzegorz.jaszczyk@linaro.org: Gather vring irq only when rvdevs
are present]
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

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>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

The AM64x SoC of TI K3 family has a Cortex  M4F core in the MCU
domain. This core is typically used for safety applications in a stand
alone mode. However, some application (non safety related) may want to
use the M4F core as a generic remote processor with IPC to the host
processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.

A remoteproc driver is added to support this subsystem to be able to
load and boot M4F core. Loading includes to M4F internal memories and
to any predefined external code/data memory. The carveouts for external
contiguous memory is defined in the M4F device node and should match
with the external memory declarations in the M4F image binary. The M4F
subsystem has two resets. One reset is for the entire subsystem i.e
including the internal memories and the other, a local reset is only
for the M4F processing core. For loading the image remoteproc driver
first releases the subsystem reset, loads the firmware image and then
releases the local reset to let the M4F processing core to run.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

K3 AM64x SoC has a Cortex M4F subsystem in the MCU volatge domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and starting the M4F subsystems.

The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>

Fix build warning on v7 platforms:

  CC [M]  drivers/irqchip/irq-pruss-intc.o
In file included from ../include/linux/bits.h:6,
                 from ../include/linux/bitops.h:5,
                 from ../include/linux/kernel.h:12,
                 from ../include/linux/interrupt.h:6,
                 from ../drivers/irqchip/irq-pruss-intc.c:15:
../include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
 #define BIT(nr)   (UL(1) << (nr))
                          ^~
../drivers/irqchip/irq-pruss-intc.c:668:32: note: in expansion of macro ‘BIT’
  .quirky_events = BIT_ULL(7) | BIT(56), /* IEP{0,1} capture/compare events */
                                ^~~
The quirky_events is u64 so BIT_ULL() has to be used.

Fixes: bbe0ff82

 ("HACK: irqchip/irq-pruss-intc: Fix processing of IEP interrupts")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Pull in the mailbox feature branch into the remoteproc tree. The OMAP
Mailbox support and corresponding sub-mailboxes nodes are all upstream
and present in vanilla 5.10 kernel (except for AM64x nodes), and this
merge pulls in the OMAP Mailbox YAML binding conversion and related
dts node cleanups.

* 'mailbox-linux-5.10.y' of git://git.ti.com/rpmsg/mailbox

:
  dt-bindings: mailbox: Convert omap-mailbox.txt binding to YAML
  ARM: dts: OMAP2+: Replace underscores in sub-mailbox node names
  ARM: dts: AM33xx/AM43xx: Rename wkup_m3 sub-mailbox node
  ARM: dts: OMAP2/OMAP3: Rename processor sub-mailbox nodes
  ARM: dts: OMAP2420: Drop interrupt-names from mailbox node
  TEMP: dt-bindings: mailbox: omap: Add example for AM64x SoCs
  mailbox: omap: Add support for K3 AM64x SoCs
  dt-bindings: mailbox: omap: Update binding for AM64x SoCs

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

Convert the current OMAP Mailbox binding from text format to YAML
format/DT schema, and delete the legacy text binding file.

The new YAML binding conversion is an updated version compared to
the original. The descriptions for certain properties have been
improved to provide more clarity. Constraints are added to the
properties 'ti,mbox-num-users', 'ti,mbox-num-fifos' and 'interrupts'.
The 'ti,hwmods' is a legacy property and is retained only to reflect
the existing usage on some older OMAP2 and OMAP3 platforms.

All the existing examples have also been updated to reflect the
latest dts nodes (ti,hwmods removed from OMAP4 and AM33xx examples,
and interrupts value updated for AM65x SoCs).

Signed-off-by: Suman Anna <s-anna@ti.com>
[robh: Update ref in ti,omap-remoteproc.yaml]
Link: https://lore.kernel.org/r/20210520234348.4479-1-s-anna@ti.com


Signed-off-by: Rob Herring <robh@kernel.org>
[s-anna@ti.com: cherry-pick linux-next commit 'ed21e4cd' for v5.14]

A number of sub-mailbox node names in various OMAP2+ dts files are
currently using underscores. This is not adhering to the node name
convention, fix all of these to use hiphens.

These nodes are already using the prefix mbox, so they will be in
compliance with the sub-mailbox node name convention being added in
the OMAP Mailbox YAML binding as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick linux-next commit '9e7f5ee1' for v5.14]

The OMAP sub-mailbox used to communicate with the Wakeup M3 remote
processor is currently named wkup_m3. This name can be confused with
the remote processor node. So, rename this to mbox-wkup-m3 to remove
the ambiguity and to also adhere to the sub-mailbox node name convention
being added in the OMAP Mailbox YAML binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick linux-next commit '8e880dfe' for v5.14]

The OMAP sub-mailbox used to communicate with the DSP and IVA remote
processors are currently named after the processor name. These can be
confused with the remote processors themselves. Rename them to remove
the ambiguity and use the prefix mbox to also adhere to the sub-mailbox
node name convention being added in the OMAP Mailbox YAML binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick linux-next commit '94a69e06' for v5.14]

The interrupt-names property is neither defined nor used in either
of the OMAP Mailbox binding or the driver. So, drop them. This is
in preparation for converting the OMAP Mailbox binding to YAML
format.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[s-anna@ti.com: cherry-pick linux-next commit '71f729ef' for v5.14]

It was discovered that IEP capture/compare IRQs (event #7 on all SoCs
and event #56 on K3 SoCs) are always triggered twice when PPS is
generated and CMP hit event detected by IEP.

An example of the problem is:
  pruss_intc_irq_handler
   generic_handle_irq
    handle_level_irq
      mask_ack_irq -> IRQ 7 masked and asked in INTC,
                      but it's not yet cleared on HW level
      handle_irq_event()
        <threaded on RT>
           icss_iep_cap_cmp_handler() -> IRQ 7 is actually processed in HW
        irq_finalize_oneshot()
         unmask_irq()
           pruss_intc_irq_unmask() -> IRQ 7 status is still observed as set

The solution is to actually ack these IRQs from pruss_intc_irq_unmask()
after the IRQ source is cleared in HW.

NOTE:
1. The current solution provides a decent generic framework to scale
   for any additional events that might be discovered in the future.
2. The solution can be reworked using soc_device_attributes() if a
   per-SoC solution is desired. The current solution applies to all
   SoCs accounting for single IEP on non-K3 SoCs and for 2 IEPs on
   all K3 SoCs.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

The PRUSS INTC driver doesn't have .irq_set_type() callback implemented and
supports only IRQ_TYPE_LEVEL_HIGH. This resulted in the IRQ properties not
being updated properly and the PRUSS INTC IRQs were listed incorrectly in
/proc/interrupts as Edge.

Example:
  218:          0  4b220000.interrupt-controller  26 Edge      pru10

Fix this by adding a simple .irq_set_type() implementation which checks the
requested IRQ triggering type.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

PRUSS INTC events are enabled by default once IRQ events are mapped to
channel:host pair. This may cause issues with undesirable IRQs triggering
even before a PRU IRQ is requested which are silently processed by
pruss_intc_irq_handler().

Fix it by masking all events by default except those which are routed to
various PRU cores (Host IRQs 0, 1; 10 through 19 on K3 SoCs), and any
other reserved IRQs routed to other processors. The unmasking of IRQs is
the responsibility of Linux IRQ core when IRQ is actually requested.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

The K3 AM64x SoCs have an ICSSG IP that has two IEP instances
that are compliant with existing K3 AM65x and J721E SoCs. Just
update a binding comment to reflect the usage for AM64x SoCs.

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