rpmsg/rpmsg.git
2 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-5.10.y
Hari Nagalla [Wed, 27 Apr 2022 03:19:36 +0000 (22:19 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the remoteproc feature branch that extends PRU device tree
bindings for K3 AM62x SoCs.

2 months agodt-bindings: remoteproc: pru: Update bindings for K3 AM62x SoCs
Kishon Vijay Abraham I [Wed, 13 Apr 2022 13:33:58 +0000 (19:03 +0530)]
dt-bindings: remoteproc: pru: Update bindings for K3 AM62x SoCs

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

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2 months agodt-bindings: soc: ti: pruss: Update bindings for K3 AM62x SoCs
Kishon Vijay Abraham I [Wed, 13 Apr 2022 13:33:56 +0000 (19:03 +0530)]
dt-bindings: soc: ti: pruss: Update bindings for K3 AM62x SoCs

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

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Hari Nagalla [Wed, 27 Apr 2022 02:51:22 +0000 (21:51 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the remoteproc feature branch that supports various PRU cores on
K3 AM62x SoCs.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
2 months agoremoteproc: pru: Add support for various PRU cores on K3 AM62x SoCs
Kishon Vijay Abraham I [Wed, 13 Apr 2022 13:33:59 +0000 (19:03 +0530)]
remoteproc: pru: Add support for various PRU cores on K3 AM62x SoCs

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>
2 months agosoc: ti: pruss: Enable support for PRUSS-M subsystem on K3 AM62x SoCs
Kishon Vijay Abraham I [Wed, 13 Apr 2022 13:33:57 +0000 (19:03 +0530)]
soc: ti: pruss: Enable support for PRUSS-M subsystem on K3 AM62x SoCs

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>
4 months agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 23 Feb 2022 18:52:41 +0000 (12:52 -0600)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
4 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 23 Feb 2022 18:47:55 +0000 (12:47 -0600)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the remoteproc feature branch that fixes couple of issues with
error recovery. The error recovery base support is already upstream and
present in 5.10 kernel for both internal exceptions and Watchdog errors
on all IPU and DSP remote processors on OMAP4+ SoCs.

The merge also adds a debugfs last trace feature to remoteproc core. Also
included is a minor optimization in the remoteproc debugfs 'recovery' file
and a precautionary alias check required by rpmsg-proto driver; and fixes
for some state-machine issues related to MMU faults with OMAP remoteproc
driver.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: Trigger IOMMU during crash recovery sequence
  remoteproc: Fix multiple back-to-back error recoveries
  remoteproc: implement last trace for remoteproc
  remoteproc: debugfs: Optimize the trace va lookup
  remoteproc/omap: add a trace to print missing alias ids

Signed-off-by: Suman Anna <s-anna@ti.com>
4 months agoremoteproc/omap: Trigger IOMMU during crash recovery sequence
Tero Kristo [Wed, 23 Feb 2022 18:40:20 +0000 (12:40 -0600)]
remoteproc/omap: Trigger IOMMU during crash recovery sequence

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>
4 months agoMerge branch 'iommu-linux-5.10.y' of git://git.ti.com/rpmsg/iommu into rpmsg-ti-linux...
Suman Anna [Wed, 23 Feb 2022 17:56:43 +0000 (11:56 -0600)]
Merge branch 'iommu-linux-5.10.y' of git://git.ti.com/rpmsg/iommu into rpmsg-ti-linux-5.10.y

Merge in the iommu feature tree into the remoteproc tree to pull in the
compatibility support for older SoCs and a bug fix for couple of lockdep
issues. The compatibility support provides a transition between legacy
hwmod for older SoCs and the latest upstream ti-sysc framework supported
by all OMAP4+ SoCs. All the ti-sysc dependencies are already upstream and
present in vanilla 5.10.

The bug fix patch resolves a "BUG: sleeping function called from invalid
context" issue during starting and stopping of a remoteproc (seen with
CONFIG_DEBUG_ATOMIC_SLEEP enabled), and a "BUG: Invalid wait context" issue
during the OMAP remoteproc probe function for IPU1, DSP1 and DSP2
remoteprocs (seen with CONFIG_PROVE_LOCKING enabled).

* 'iommu-linux-5.10.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: convert spinlocks to mutexes
  iommu/omap: Add transition support between hwmod and ti,sysc

Signed-off-by: Suman Anna <s-anna@ti.com>
4 months agorpmsg: fix lockdep warnings in virtio rpmsg bus driver rpmsg-linux-5.10.y
Angela Stegmaier [Wed, 23 Feb 2022 16:55:50 +0000 (10:55 -0600)]
rpmsg: fix lockdep warnings in virtio rpmsg bus driver

The virtio rpmsg bus framework uses endpoints as the basis for
sending and receiving messages to/from a remote processor. Each
rpmsg bus device will have a primary endpoint if the corresponding
rpmsg bus driver supports a callback, and secondary child endpoints
associated with the same rpmsg bus device. The life-cycle of these
endpoints are tied to the corresponding rpmsg device. A virtio rpmsg
bus device can also have its own endpoint for supporting name service
announcements from a corresponding remote processor to create and
delete rpmsg devices dynamically.

Each endpoint has a callback lock associated with it to provide
protection/mutual exclusion between threads that process incoming
rpmsg messages and threads that want to delete the endpoint. The
virtio rpmsg name service endpoint callback will run while holding
it's ept->cb_lock to create/delete rpmsg devices for RPMSG_NS_CREATE
and RPMSG_NS_DELETE messages respectively. The latter message
processing will destroy the requested channel, and will ultimately
result in all the secondary rpmsg device endpoints also to be
destroyed. The ept->cb_lock for the channel's endpoint is also
locked during its destruction while setting the callback to NULL.
This results in a seemingly nested locking of the ept->cb_lock even
though the locking is on different mutexes. This will result in a
false warning from the lockdep validator when it is enabled because
the lockdep deals with classes and both are the same class, although
they are different instances.

Similar circular dependency scenarios also exist with remoteproc
error recovery and existing rpmsg driver - rpmsg_proto.

These issues are fixed by replacing the existing mutex_lock() calls
with the mutex_lock_nested() API variation and using different
subclasses for the NameService end-point and for the rpmsg channel
device end-points.

Following are example warning signatures that get fixed by this patch:

1. Recursive locking dependency during RPMSG_NS_DESTROY message processing
 ============================================
 WARNING: possible recursive locking detected
 --------------------------------------------
 kworker/0:1/20 is trying to acquire lock:
 c68c2c44 (&ept->cb_lock){+.+.}-{3:3}, at: __rpmsg_destroy_ept+0x44/0x98 [virtio_rpmsg_bus]

 but task is already holding lock:
 c69a8344 (&ept->cb_lock){+.+.}-{3:3}, at: rpmsg_recv_done+0x9c/0x2a0 [virtio_rpmsg_bus]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&ept->cb_lock);
   lock(&ept->cb_lock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 4 locks held by kworker/0:1/20:
  #0: c200a6a8 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x204/0x7c0
  #1: c30a5f20 ((work_completion)(&mq->work)){+.+.}-{0:0}, at: process_one_work+0x204/0x7c0
  #2: c69a8344 (&ept->cb_lock){+.+.}-{3:3}, at: rpmsg_recv_done+0x9c/0x2a0 [virtio_rpmsg_bus]
  #3: c59d74c8 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x18/0x1d4

2. Circular locking dependency during error recovery of rpmsg-proto driver
 ======================================================
 WARNING: possible circular locking dependency detected
 ------------------------------------------------------
 kworker/0:3/968 is trying to acquire lock:
 c59ba544 (&ept->cb_lock){+.+.}-{3:3}, at: __rpmsg_destroy_ept+0x44/0x98 [virtio_rpmsg_bus]

 but task is already holding lock:
 bf014038 (rpmsg_channels_lock){+.+.}-{3:3}, at: rpmsg_proto_remove+0x28/0x178 [rpmsg_proto]

 which lock already depends on the new lock.

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(rpmsg_channels_lock);
                                lock(&ept->cb_lock);
                                lock(rpmsg_channels_lock);
   lock(&ept->cb_lock);

  *** DEADLOCK ***

 6 locks held by kworker/0:3/968:
  #0: c200a6a8 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x204/0x7c0
  #1: c5f73f20 ((work_completion)(&rproc->crash_handler)){+.+.}-{0:0}, at: process_one_work+0x204/0x7c0
  #2: c5648364 (&rproc->lock){+.+.}-{3:3}, at: rproc_trigger_recovery+0x30/0x304
  #3: c58eb8f8 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x18/0x1d4
  #4: c59a70c8 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x18/0x1d4
  #5: bf014038 (rpmsg_channels_lock){+.+.}-{3:3}, at: rpmsg_proto_remove+0x28/0x178 [rpmsg_proto]

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values, update crash log examples for 5.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
[dfustini: fix trivial conflict in drivers/rpmsg/virtio_rpmsg_bus.c]
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
4 months agonet/rpmsg: unblock reader threads operating on errored sockets
Suman Anna [Sat, 5 Feb 2022 22:28:38 +0000 (14:28 -0800)]
net/rpmsg: unblock reader threads operating on errored sockets

The rpmsg_proto driver is used to provide a socket interface
to userspace under the AF_RPMSG address family, and is used
by the TI IPC MessageQ stack. The typical usage for receiving
messages include a thread blocked on a select() call with
appropriate socket fds, followed by a recvfrom() on the fd
returned/marked ready by select().

The rpmsg_sock_poll() function implements the logic needed
by the select() call, and marks a socket ready only when there
is data to be read currently. Any reader thread waiting on the
select() call to return is currently not unblocked when a remote
processor goes through an error recovery, and can remain blocked
forever as its remote processor peer thread may never send it
another message. Enhance the rpmsg_proto driver so that a waiting
thread can be unblocked by waking it up during the process of
marking the open sockets with the error status RPMSG_ERROR. This
is achieved by using the socket's .sk_error_report() ops, and is
preferred over the .sk_state_change() ops to wakeup only a single
exclusive thread.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
4 months agonet/rpmsg: return ENOLINK upon Rx on errored sockets
Suman Anna [Sat, 5 Feb 2022 22:28:37 +0000 (14:28 -0800)]
net/rpmsg: return ENOLINK upon Rx on errored sockets

The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the TI
IPC MessageQ stack. The rpmsg proto driver creates a rpmsg endpoint
per remote processor (a Rx socket) for each MessageQ object through
the socket's bind() call. These rpmsg endpoints are associated with
a published parent rpmsg device from that remote processor. These
endpoints are cleaned up normally either when the userspace program
/ application closes them or through the automatic cleanup of the
file descriptors when a process is terminated/closed. These endpoints
can also be cleaned up by the rpmsg_proto driver as part of the error
recovery of a remote processor, during the removal of their parent
rpmsg device, with the corresponding Rx sockets simply marked with
the error status RPMSG_ERROR.

This error status is not currently being returned to the userspace
in the socket's recvfrom() interface. Fix this by specifically
checking for this error status, and returning an error value of
ENOLINK back to userspace. The ENOLINK error code is used to allow
the userspace to differentiate this terminal error from other errors
on the Rx sockets and take appropriate action. This error code on
Rx sockets serves the same as the error code ESHUTDOWN used for Tx
sockets, and is chosen specifically to have a meaningful strerror
message appropriate to Rx sockets.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
4 months agonet/rpmsg: return ESHUTDOWN upon Tx on errored sockets
Suman Anna [Sat, 5 Feb 2022 22:28:36 +0000 (14:28 -0800)]
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets

The rpmsg proto driver uses a single rpmsg channel device
published from a remote processor to transmit all socket-based
messages intended for that remote processor. This channel will
be auto-removed and recreated if the remote processor goes
through an error recovery process. Any connected sockets are
marked with an error status, and further transmissions on these
connected sockets should gracefully return an error. This error
condition is specifically checked for and a new error ESHUTDOWN
is returned back to userspace to differentiate it from
transmissions on an unconnected socket.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
4 months agonet/rpmsg: add support to handle a remote processor error recovery
Suman Anna [Sat, 5 Feb 2022 22:28:35 +0000 (14:28 -0800)]
net/rpmsg: add support to handle a remote processor error recovery

The rpmsg_proto driver is used to provide a socket interface to
userspace under the AF_RPMSG address family, and is used by the
TI IPC MessageQ stack. The rpmsg proto driver uses a single rpmsg
channel device published from a remote processor to transmit and
receive all socket-based messages to/from that remote processor.
There can be any number of Tx and Rx sockets associated with each
remote processor's rpmsg device. This rpmsg channel device will be
auto-removed and recreated if the associated remote processor goes
through an error recovery process. Any existing open sockets (both
Tx and Rx) are oblivious if the underlying rpmsg channel has been
removed, and any further operations on such sockets can create
various kernel crashes due to invalid pointer dereferences.

This patch adds the error recovery support to the rpmsg-proto driver.
This is achieved by using the private field of the published rpmsg
channel device's endpoint (ept->priv) to maintain a list of all the
connected and bound sockets, and setting a new error status
(RPMSG_ERROR) on all these open sockets when the associated parent
rpmsg device is removed. This new error status allows the driver
to check for a valid state of a socket before performing any actions
on it thereby preventing any kernel crashes. The status is also used
to allow the userspace to perform appropriate cleanup and/or recovery
steps.

The logic is asymmetric because of the slight difference between the
Rx and Tx sockets. All the Tx sockets use the one-time published
rpmsg_channel devices for transmissions and just need to be marked
with the error status, while each of the Rx sockets have their own
derivative rpmsg endpoints, and so need to be removed alongside the
removal of the associated rpmsg channel device in addition. The
sockets themselves are freed up anytime either by the userspace
closing them or through an automatic close when the process is
terminated/closed.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Drew Fustini <dfustini@baylibre.com>
4 months agoremoteproc: Fix multiple back-to-back error recoveries
Suman Anna [Mon, 14 Feb 2022 19:24:43 +0000 (11:24 -0800)]
remoteproc: Fix multiple back-to-back error recoveries

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

This fixes an issue with error recovery upon MMU Faults on OMAP
IPU remote processors. An MMU fault on OMAP IPU sends two error
notifications - one a direct interrupt from the MMU, and the second
a mailbox-based crash notification after the remote processor has
collected some backtrace. The mailbox based interrupt mechanism,
added in commit 232ba6ca007c ("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>
4 months agoremoteproc: implement last trace for remoteproc
Suman Anna [Mon, 14 Feb 2022 19:24:45 +0000 (11:24 -0800)]
remoteproc: implement last trace for remoteproc

The last trace is a way of preserving the remoteproc traces past
remoteproc recovery. This is achieved by creating a new traceY_last
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copied contents can then be read out using a debugfs entry. 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>
4 months agoremoteproc: debugfs: Optimize the trace va lookup
Suman Anna [Mon, 14 Feb 2022 19:24:42 +0000 (11:24 -0800)]
remoteproc: debugfs: Optimize the trace va lookup

The commit a987e6b91a5a ("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>
4 months agoremoteproc/omap: add a trace to print missing alias ids
Suman Anna [Mon, 7 Feb 2022 03:51:23 +0000 (19:51 -0800)]
remoteproc/omap: add a trace to print missing alias ids

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

Signed-off-by: Suman Anna <s-anna@ti.com>
4 months agoiommu/omap: convert spinlocks to mutexes
Tero Kristo [Fri, 4 Feb 2022 06:30:38 +0000 (22:30 -0800)]
iommu/omap: convert spinlocks to mutexes

Current spinlock heavy implementation of the omap-iommu causes some
sleeping while atomic warnings with lockdep debugging enabled. To fix
these, convert iommu_lock and domain lock into mutexes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
4 months agoiommu/omap: Add transition support between hwmod and ti,sysc
Suman Anna [Fri, 4 Feb 2022 06:39:07 +0000 (22:39 -0800)]
iommu/omap: Add transition support between hwmod and ti,sysc

The OMAP IOMMU driver relies on hwmod layers and uses platform data
callbacks for clocking and reset functionality at present. The same
will be achieved through the ti-sysc parent interconnect node in the
future using the pm_runtime framework and the inherent parent-child
relationship.

Add support to the code so that both the newer ti-sysc based logic
and the older hwmod based logic are supported as the IOMMU DT nodes
are transitioned to the ti-sysc mode. The existing platform data
callbacks should continue to be invoked when using hwmods, but
should not be invoked with ti-sysc.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Hari Nagalla [Mon, 31 Jan 2022 16:22:59 +0000 (10:22 -0600)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that adds the support for
R5F and C7x DSP remote processor support to J721S2 SoC family.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs
  remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs
  dt-bindings: remoteproc: k3-dsp: Update bindings for J721S2 SoCs
  dt-bindings: remoteproc: k3-r5f: Update bindings for J721S2 SoCs

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
5 months agoremoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs
Hari Nagalla [Mon, 22 Nov 2021 12:27:26 +0000 (06:27 -0600)]
remoteproc: k3-r5: Extend support for R5F clusters on J721S2 SoCs

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>
5 months agoremoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs
Hari Nagalla [Mon, 22 Nov 2021 12:27:25 +0000 (06:27 -0600)]
remoteproc: k3-dsp: Extend support for C71x DSPs on J721S2 SoCs

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>
5 months agodt-bindings: remoteproc: k3-dsp: Update bindings for J721S2 SoCs
Hari Nagalla [Mon, 22 Nov 2021 12:27:24 +0000 (06:27 -0600)]
dt-bindings: remoteproc: k3-dsp: Update bindings for J721S2 SoCs

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>
5 months agodt-bindings: remoteproc: k3-r5f: Update bindings for J721S2 SoCs
Hari Nagalla [Mon, 22 Nov 2021 12:27:23 +0000 (06:27 -0600)]
dt-bindings: remoteproc: k3-r5f: Update bindings for J721S2 SoCs

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>
8 months agoti_config_fragments: rpmsg/v8_rpmsg: Enable rpmsg-pru driver
Suman Anna [Mon, 18 Oct 2021 11:29:19 +0000 (11:29 +0000)]
ti_config_fragments: rpmsg/v8_rpmsg: Enable rpmsg-pru driver

Enable the PRU messaging driver pru-rpmsg (RPMSG_PRU) in both the
ipc.cfg and v8_ipc.cfg so that the driver is built as a module
by default on all applicable TI platforms.  This driver is used
to showcase the remoteproc/rpmsg communication from userspace with
the various PRU or RTU cores present in PRUSS or ICSSG instances.

The driver presents a /dev/rpmsg_pruX (where X is the endpoint
number on PRU) for each rpmsg device that can probe this driver.
This published number needs to be unique across all PRU instances.

The module is built as rpmsg_pru.ko, and the driver name in sysfs
is rpmsg_pru.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
8 months agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 20 Oct 2021 22:30:48 +0000 (17:30 -0500)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

Pull in the updated rpmsg base feature branch that adds a new
rpmsg bus driver, rpmsg-pru. The rpmsg-pru driver provides a
simple character driver interface to userspace to send messages
to the PRU remote processors on the currently supported SoCs -
AM335x, AM437x, AM57xx, AM65x, J721E and AM64x.

The support for 66AK2G is not provided at present and requires an
additional enhancement in the virtio-rpmsg core to deal with aliased
32-bit addresses for vring buffers.

* 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: pru: add a PRU RPMsg driver

Signed-off-by: Suman Anna <s-anna@ti.com>
8 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 20 Oct 2021 22:23:19 +0000 (17:23 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that adds the support for
the RPMsg stack on the PRU remoteproc devices. The support is provided
through the usage of PRU system events (instead of OMAP mailboxes). This
is done to align on a common interrupt mechanism for PRUSS support on
all ICSS instances (AM437x does not have enough mailboxes) on the
OMAP architecture (AM33xx/AM43xx/AM57xx) and Keystone architecture
(66AK2G) SoCs and K3 architecture (AM65x/J721E/AM64x) SoCs. The PRU
remoteproc will be leveraging the Linux default CMA pools for virtio
ring buffers and control data.

Support is added for AM33xx, AM437x, AM57xx, AM65x and J721E SoCs at
present.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-j721e-main: Add PRU system events for virtio
  arm64: dts: ti: k3-am65-main: Add PRU system events for virtio
  ARM: dts: am57xx: Add PRU system events for virtio
  ARM: dts: AM4372: Add PRU system events for virtio
  ARM: dts: am335x: Add PRU system events for virtio
  remoteproc: pru: Add support for virtio rpmsg stack
  dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg

Signed-off-by: Suman Anna <s-anna@ti.com>
8 months agoarm64: dts: ti: k3-j721e-main: Add PRU system events for virtio
Suman Anna [Wed, 20 Oct 2021 22:14:02 +0000 (17:14 -0500)]
arm64: dts: ti: k3-j721e-main: Add PRU system events for virtio

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>
8 months agoarm64: dts: ti: k3-am65-main: Add PRU system events for virtio
Suman Anna [Mon, 18 Oct 2021 11:29:18 +0000 (11:29 +0000)]
arm64: dts: ti: k3-am65-main: Add PRU system events for virtio

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>
8 months agoARM: dts: am57xx: Add PRU system events for virtio
Nick Saulnier [Wed, 20 Oct 2021 21:23:56 +0000 (16:23 -0500)]
ARM: dts: am57xx: Add PRU system events for virtio

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>
8 months agoARM: dts: AM4372: Add PRU system events for virtio
Nick Saulnier [Wed, 20 Oct 2021 21:23:05 +0000 (16:23 -0500)]
ARM: dts: AM4372: Add PRU system events for virtio

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>
8 months agoARM: dts: am335x: Add PRU system events for virtio
Nick Saulnier [Wed, 20 Oct 2021 21:15:17 +0000 (16:15 -0500)]
ARM: dts: am335x: Add PRU system events for virtio

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>
8 months agoremoteproc: pru: Add support for virtio rpmsg stack
Suman Anna [Mon, 18 Oct 2021 11:29:16 +0000 (11:29 +0000)]
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 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>
8 months agodt-bindings: remoteproc: pru: Update bindings for supporting rpmsg
Suman Anna [Wed, 20 Oct 2021 21:09:23 +0000 (16:09 -0500)]
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>
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>
8 months agorpmsg: pru: add a PRU RPMsg driver
Jason Reeder [Mon, 18 Oct 2021 11:29:17 +0000 (11:29 +0000)]
rpmsg: pru: add a PRU RPMsg driver

An RPMsg driver that exposes interfaces to user space, to
allow applications to communicate with the PRU processors
on available TI SoCs has been added. This is restricted to
SoCs that have the PRUSS remoteproc support.

Signed-off-by: Jason Reeder <jreeder@ti.com>
[s-anna@ti.com: various cleanups, forward-port to 5.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
8 months agoti_config_fragments: remoteproc/v8_remoteproc: Enable K3 M4F remoteproc driver
Hari Nagalla [Sun, 17 Oct 2021 02:33:50 +0000 (21:33 -0500)]
ti_config_fragments: remoteproc/v8_remoteproc: Enable K3 M4F remoteproc driver

Enable the K3 M4 remoteproc driver in v8_ipc.cfg. This driver is built
as a module by default on all applicable K3 platforms. This driver is
used to showcase the remoteproc/rpmsg communication from userspace with
M4F cores on K3 SoC devices.

The driver presents a character driver interface through
'/dev/rpmsg_ctrlX', where X is the device endpoint number and can be
determined from the remoteproc instance number matching the M4F device name.

The module is built as 'ti_k3_m4_remoteproc.ko' and the driver name in
sysfs is 'xxxxxx.m4fss', where xxxxx is the bus address.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
8 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Hari Nagalla [Tue, 19 Oct 2021 12:14:15 +0000 (07:14 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that extends support for
M4F processor on AM64x SoCs.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
  dt-bindings: remoteproc: k3-m4f: Add bindings for K3 AM64x SoCs

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
8 months agoremoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
Hari Nagalla [Thu, 7 Oct 2021 15:12:47 +0000 (10:12 -0500)]
remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

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>
8 months agodt-bindings: remoteproc: k3-m4f: Add bindings for K3 AM64x SoCs
Hari Nagalla [Thu, 7 Oct 2021 13:07:49 +0000 (08:07 -0500)]
dt-bindings: remoteproc: k3-m4f: Add bindings for K3 AM64x SoCs

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>
11 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 20 Jul 2021 16:24:54 +0000 (11:24 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that fixes a minor build
warning in the PRUSS INTC irqchip driver on v7 platforms.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  irqchip/irq-pruss-intc: Fix build warning

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoirqchip/irq-pruss-intc: Fix build warning
Grygorii Strashko [Fri, 9 Jul 2021 14:12:24 +0000 (17:12 +0300)]
irqchip/irq-pruss-intc: Fix build warning

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: bbe0ff82f922 ("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>
12 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 17 Jun 2021 13:39:42 +0000 (08:39 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that pulls in the OMAP Mailbox
driver updates that include the OMAP Mailbox YAML conversion and related
node cleanups on various legacy SoCs.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  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

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoMerge branch 'mailbox-linux-5.10.y' of git://git.ti.com/rpmsg/mailbox into rproc...
Suman Anna [Thu, 17 Jun 2021 13:31:52 +0000 (08:31 -0500)]
Merge branch 'mailbox-linux-5.10.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-5.10.y

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>
12 months agodt-bindings: mailbox: Convert omap-mailbox.txt binding to YAML
Suman Anna [Thu, 20 May 2021 23:43:48 +0000 (18:43 -0500)]
dt-bindings: mailbox: Convert omap-mailbox.txt binding to YAML

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 'ed21e4cd291a' for v5.14]

12 months agoARM: dts: OMAP2+: Replace underscores in sub-mailbox node names
Suman Anna [Tue, 18 May 2021 17:36:45 +0000 (12:36 -0500)]
ARM: dts: OMAP2+: Replace underscores in sub-mailbox node names

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 '9e7f5ee11373' for v5.14]

12 months agoARM: dts: AM33xx/AM43xx: Rename wkup_m3 sub-mailbox node
Suman Anna [Tue, 18 May 2021 17:36:44 +0000 (12:36 -0500)]
ARM: dts: AM33xx/AM43xx: Rename wkup_m3 sub-mailbox node

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 '8e880dfefd61' for v5.14]

12 months agoARM: dts: OMAP2/OMAP3: Rename processor sub-mailbox nodes
Suman Anna [Tue, 18 May 2021 17:36:43 +0000 (12:36 -0500)]
ARM: dts: OMAP2/OMAP3: Rename processor sub-mailbox nodes

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 '94a69e062648' for v5.14]

12 months agoARM: dts: OMAP2420: Drop interrupt-names from mailbox node
Suman Anna [Tue, 18 May 2021 17:36:42 +0000 (12:36 -0500)]
ARM: dts: OMAP2420: Drop interrupt-names from mailbox node

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 '71f729ef73ce' for v5.14]

13 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 1 Jun 2021 13:42:50 +0000 (08:42 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that fixes couple of
issues in the PRUSS INTC irqchip driver. The patches mitigate some
spurious interrupts towards MPU before the IRQs are requested, fix
the PRUSS interrupt types printed in /proc/interrupts, and provide
a workaround for IEP timer events towards proper PPS functionality.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  HACK: irqchip/irq-pruss-intc: Fix processing of IEP interrupts
  irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts
  irqchip/irq-pruss-intc: Fix enabling of intc events

Signed-off-by: Suman Anna <s-anna@ti.com>
13 months agoHACK: irqchip/irq-pruss-intc: Fix processing of IEP interrupts
Suman Anna [Fri, 28 May 2021 20:51:37 +0000 (15:51 -0500)]
HACK: irqchip/irq-pruss-intc: Fix processing of IEP interrupts

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>
13 months agoirqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts
Grygorii Strashko [Fri, 28 May 2021 19:10:24 +0000 (14:10 -0500)]
irqchip/irq-pruss-intc: Fix listed IRQ type in /proc/interrupts

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>
13 months agoirqchip/irq-pruss-intc: Fix enabling of intc events
Suman Anna [Fri, 28 May 2021 19:00:50 +0000 (14:00 -0500)]
irqchip/irq-pruss-intc: Fix enabling of intc events

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>
13 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 26 May 2021 16:34:19 +0000 (11:34 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that adds the base support
to various PRUSS platform drivers for supporting the ICSSG IP on AM64x
SoCs. The ICSSG IP on AM64x SoCs is a minor revision of the version
present on J721E SoCs, with the chief difference being no support for
SGMII mode for ICSSG Ethernet applications.

Support is added through AM64x specific compatibles on PRUSS and PRU
remoteproc drivers, while the PRUSS INTC and IEP modules reuse the
existing compatibles. The YAML bindings are updated though to include
the AM64x in the supported SoC list.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  dt-bindings: net: icss_iep: Update binding for K3 AM64x SoCs
  remoteproc: pru: Add support for various PRU cores on K3 AM64x SoCs
  dt-bindings: remoteproc: pru: Update bindings for K3 AM64x SoCs
  dt-bindings: irqchip: Update pruss-intc binding for K3 AM64x SoCs
  soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs
  dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs

Signed-off-by: Suman Anna <s-anna@ti.com>
13 months agodt-bindings: net: icss_iep: Update binding for K3 AM64x SoCs
Suman Anna [Tue, 25 May 2021 16:05:12 +0000 (11:05 -0500)]
dt-bindings: net: icss_iep: Update binding for K3 AM64x SoCs

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>
13 months agoremoteproc: pru: Add support for various PRU cores on K3 AM64x SoCs
Suman Anna [Tue, 25 May 2021 15:39:23 +0000 (10:39 -0500)]
remoteproc: pru: Add support for various PRU cores on K3 AM64x SoCs

The K3 AM64x family of SoCs have a ICSSG IP that is similar to the
version on AM65x SR2.0 SoCs with some minor differences. The AM64x
SoCs contain two instances of this newer ICSSG IP. Each ICSSG processor
subsystem contains 2 primary PRU cores, 2 auxiliary PRU cores called
RTUs, and 2 new auxiliary cores called Transmit PRUs (Tx_PRUs).

Enhance the existing PRU remoteproc driver to support all these PRU,
RTU and Tx_PRU cores by using specific compatibles. The cores have the
same memory copying limitations as on AM65x, so reuses the custom memcpy
function within the driver's ELF loader implementation. 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: Suman Anna <s-anna@ti.com>
13 months agodt-bindings: remoteproc: pru: Update bindings for K3 AM64x SoCs
Suman Anna [Tue, 25 May 2021 15:48:31 +0000 (10:48 -0500)]
dt-bindings: remoteproc: pru: Update bindings for K3 AM64x SoCs

The K3 AM64x SoCs have an ICSSG IP that is similar to the IP revisions
used on K3 AM65x SR2.0 and J721E SoCs. The ICSSG IP on K3 AM64x SoCs
have the same set of two PRU cores, two RTU cores and two auxiliary PRU
cores called Transmit PRUs (Tx_PRUs). There are some minor differences
surrounding the PRU cores like different Broadside RAM (BSRAM) sizes
w.r.t AM65x SR1.0 SoCs.

Update the PRU remoteproc bindings for these PRU cores on AM64x SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
13 months agodt-bindings: irqchip: Update pruss-intc binding for K3 AM64x SoCs
Suman Anna [Tue, 25 May 2021 14:53:06 +0000 (09:53 -0500)]
dt-bindings: irqchip: Update pruss-intc binding for K3 AM64x SoCs

The K3 AM64x SoCs also have a ICSSG IP that is similar to existing K3
AM65x and J721E SoCs. The ICSSG interrupt controller is identical to
that of the INTC on J721E SoCs, and supports 20 host interrupts and
160 input events from various SoC interrupt sources. All the 8 output
host interrupts are routed to multiple entities though. Update the
PRUSS interrupt controller binding with this information, though the
same K3 compatible shall be used for the ICSSG INTC on AM64x SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
13 months agosoc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs
Suman Anna [Mon, 24 May 2021 22:37:06 +0000 (17:37 -0500)]
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs

The K3 AM64x family of SoCs have a similar version of the PRU-ICSS (ICSSG)
processor subsystem present on K3 J721E and K3 AM65x SR2.0 SoCs. These SoCs
contain typically two ICSSG instances named ICSSG0 and ICSSG1. The two
ICSSGs are identical to each other for the most part with minor SoC
integration differences and capabilities. SGMII mode is not supported at
all on these SoCs (unlike specific instances on AM65x, J721E). The ICSSG1
also has limited pins connected on some sub-modules compared to ICSSG0.

There is no change in the Interrupt Controller w.r.t either of AM65x or
J721E SoCs. All other integration aspects are also very similar to the
existing SoCs.

The existing pruss platform driver has been updated to support these
similar ICSSG instances through a new AM64x specific compatible.

Signed-off-by: Suman Anna <s-anna@ti.com>
13 months agodt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs
Suman Anna [Mon, 24 May 2021 22:31:43 +0000 (17:31 -0500)]
dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs

The K3 AM64x SoCs also have the Gigabit Ethernet capable PRU-ICSS IP
that is present on existing K3 AM65x and J721E SoCs (ICSSG). The IP
is similar to the ones used on K3 J721E or AM65x SR2.0 SoCs.

Update the PRUSS bindings for these ICSSG instances.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Fri, 23 Apr 2021 15:32:24 +0000 (10:32 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that includes few minor
fixes to the PRUSS and PRUSS INTC binding and the PRU remoteproc driver.
The merge also pulls in a change that reserves a portion of the MCU
SRAM for use by the MCU R5FSS Core0 on AM65x SoCs.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  dt-bindings: soc: ti: pruss: Add dma-coherent property
  remoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap
  dt-bindings: irqchip: Add node name to PRUSS INTC
  arm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agodt-bindings: soc: ti: pruss: Add dma-coherent property
Suman Anna [Fri, 23 Apr 2021 14:10:57 +0000 (09:10 -0500)]
dt-bindings: soc: ti: pruss: Add dma-coherent property

Update the PRUSS schema file to include the dma-coherent property
that indicates the coherency of the IP. The PRUSS IPs on 66AK2G
SoCs do use this property.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap
Suman Anna [Thu, 22 Apr 2021 18:56:21 +0000 (13:56 -0500)]
remoteproc: pru: Fix missing cleanup paths in pru_handle_intrmap

The downstream commit 9f048e48f2c6 ("remoteproc: pru: Fix and cleanup
firmware interrupt mapping logic") did not reset the variables on all
the failure paths. Fix the gaps.

This patch syncs up the code logic to the equivalent revised version
of the above patch merged into mainline kernel in commit 880a66e026fb
("remoteproc: pru: Fix and cleanup firmware interrupt mapping logic").

Fixes: 9f048e48f2c6 ("remoteproc: pru: Fix and cleanup firmware interrupt mapping logic")
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agodt-bindings: irqchip: Add node name to PRUSS INTC
Suman Anna [Tue, 26 Jan 2021 16:32:51 +0000 (10:32 -0600)]
dt-bindings: irqchip: Add node name to PRUSS INTC

[ Upstream commit 5ab931402a1703358b8a0466c6c9333c560dea6d ]

The current PRUSS Interrupt Controller binding doesn't exactly specify
the convention for the node name. These interrupt-controllers will always
have a unit address. Update the binding with the '$nodename' using the
expected generic name, this shall ensure the interrupt-controller.yaml
is automatically applied to this binding.

Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210126163251.29468-1-s-anna@ti.com
Signed-off-by: Rob Herring <robh@kernel.org>
[s-anna@ti.com: cherry-pick commit '5ab931402a17' from v5.12]

14 months agoarm64: dts: ti: k3-am65-mcu: Reserve some MCU SRAM for MCU R5F0
Suman Anna [Thu, 22 Apr 2021 19:12:50 +0000 (14:12 -0500)]
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>
14 months agoti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
Suman Anna [Wed, 21 Apr 2021 19:02:28 +0000 (14:02 -0500)]
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules

Add the keystone-dsp-mem module and UIO core modules to the rpmsg
defconfig fragment to enable the user-land Multi Proc Manager (MPM)
based remoteproc usecases on Keystone platforms.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 22 Apr 2021 13:45:38 +0000 (08:45 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that enhances the
Keystone remoteproc driver to provide an userspace interface
for supporting a userland driven Multi Proc Manager (MPM) loader.
An additional temporary keystone_dsp_mem driver is also added
that provides an mmap interface for MultiCore Shared Memory (MSM)
and portions of DDR for exclusive usage for the DSPs.

Both the keystone remoteproc driver and keystone_dsp_mem driver
provide sysfs interfaces for presenting the DSP internal memory
regions and the DDR & SRAM regions respectively to userspace.
The keystone_dsp_mem driver uses the SRAM driver infrastructure,
and uses specific child nodes to reserve portions of the MSM
RAM for exposing them to userspace for the MPM stack on all
Keystone 2 SoCs.

The support relies on couple of enhancements to the remoteproc
core, mainly that provides the infrastructure support to allow
userspace driver loading and to deny any sysfs operations using
flags configured by a remoteproc driver (used during MPM mode
by Keystone remoteproc driver).

This support has been added to all the currently supported TI
platforms - K2H EVM, K2L EVM, K2E EVM, K2G GP EVM and K2G-ICE
boards.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/keystone: add support for MPM userspace loader
  remoteproc: add infrastructure support for userspace driven loading
  TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
  TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
  ARM: dts: keystone-k2g: Reserve SRAM for MPM
  ARM: dts: keystone-k2e: Reserve SRAM for MPM
  ARM: dts: keystone-k2l: Reserve SRAM for MPM
  ARM: dts: keystone-k2hk: Reserve SRAM for MPM
  TEMP: soc: ti: add the keystone_dsp_mem driver
  TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc/keystone: add support for MPM userspace loader
Suman Anna [Wed, 21 Apr 2021 19:32:19 +0000 (14:32 -0500)]
remoteproc/keystone: add support for MPM userspace loader

The Keystone remoteproc driver performs the device management of
different DSP processor subsystems present on various Keystone 2
family of SoCs. The driver currently supports loading/booting using
the remoteproc core's 'auto-boot' feature and supports advanced
features like error recovery.

This patch enhances the Keystone remoteproc driver to add support
for a TI specific userspace based loading/booting mechanism called
the Multi Proc Manager (MPM) by exposing a character device interface
to userspace per device. A new module parameter 'use_rproc_core_loader'
is introduced to configure the driver for in-kernel auto-boot mode
or the MPM non auto-boot mode, with the default configured for MPM.
The standard platform driver's bind and unbind sysfs attributes are
suppressed for MPM-based stack so that the regular sysfs approach of
booting and shutting down a Keystone DSP remote processor does not
mess up the MPM-based state-machine by unbinding the device from the
driver even when it has open usage reference counts. The standard
remoteproc sysfs interfaces for changing 'state' and 'firmware'
conflict with the MPM state-machine and are denied using the
remoteproc generic 'deny_sysfs_ops' flag. An exception notification
is also provided through an UIO device exposed by the keystone
remoteproc driver for now.

The MPM loading/booting mechanism uses the file operations exported
by the character device. The mmap interface is used for mapping device
memory into userspace for loading and the ioctl interfaces are used
for reset and remoteproc resource table configuration and triggering
the boot and shutdown of the DSPs.

The address and size of the various DSP internal RAM memories to
be used with the mmap interface are provided through two sysfs
files 'addr' and 'size' for each region, and are created under the
respective dspX misc device for each DSP remoteproc processor. These
files are created in their own directory for each region accessible
under the /sys/class/misc/dspX/ path, where X is the DSP number
(indexed from 0). The MPM also relies on another memory mapping
character device (/dev/dspmem) to support loading images into
external DDR memory and the Multicore Shared Memory (MSM). This
sysfs logic allows the userspace-based Multi Proc Manager (MPM)
stack to not rely on procfs-based DT parsing for looking up the
memories.

The MPM supports various kinds of firmware images - images with and
without resource tables, images that have a resource table but with
or without the virtio device resource entries. The loadable regions
include images just using internal DSP memories, or images using
portions of the MSM RAM and/or external DDR. The load/boot of images
with and without resource tables are supported using separate ioctl
operations. The KEYSTONE_RPROC_IOC_SET_STATE ioctl is used to boot
and shutdown remote processors for images with resource tables, and
the KEYSTONE_RPROC_IOC_DSP_RESET/BOOT ioctls for images without a
resource table. The boot address/entry point is published during the
corresponding ioctls that trigger a boot, and is stored in a local
variable in driver instance and later picked up by remoteproc core
driver through fw_ops.

This logic is created anew using an older code from Cyril Chemparathy
as a baseline.

NOTE:
The remoteproc subsystem has gained a new character device functionality
recently in v5.9 kernel, but is not compatible with TI's existing
MPM userspace stack.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>
14 months agoremoteproc: add infrastructure support for userspace driven loading
Suman Anna [Wed, 21 Apr 2021 19:22:20 +0000 (14:22 -0500)]
remoteproc: add infrastructure support for userspace driven loading

The remoteproc infrastructure is enhanced to allow remoteproc drivers
to support userspace driven loading, with the actual boot triggered
through the kernel. This usecase is slightly different from the support
for remote processors that were already loaded and booted by bootloaders.
The support for the latter usecase is provided through RPROC_DETACHED
and new .attach() and detach() callbacks, while the userspace driven
load will usually have the remote processor firmwares loaded after
the userspace is up.

Support for the userspace loading feature is provided through a new field
in the rproc structure, 'skip_firmware_load'. This field is expected to
be set to true as per the mode/need required by the remoteproc drivers
before a rproc_add() call. The remoteproc core skips looking for firmware
and loading any firmware segments using this state flag. The default
behavior is unchanged. The sysfs 'firmware' file shows the firmware as
"unknown" and checks are added to ensure the 'auto_boot' field is not
set when the driver is configured for 'skip_firmware_load'.

The actual interface and implementation details is left to the individual
remoteproc drivers. This design will be used by the TI Keystone remoteproc
driver to support a userspace based loader. The remoteproc driver is
expected to invoke rproc_boot() and rproc_shutdown() for triggering the
boot and shutdown of the remote processor after the loading is completed
and the resource table information is published to the remoteproc driver.
The resource table is processed in-line during the rproc_boot() invocation.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:39:09 +0000 (11:39 -0600)]
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G ICE board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

This address and size are aligned with the values used on the
K2G EVM board so that same firmwares can be run on both the K2G
boards. Note that these values are different from those used on
the other K2HK/K2L/K2E EVM boards.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:36:47 +0000 (11:36 -0600)]
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2G EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Note that this carveout is smaller and at a different address in
comparision to those used on K2HK/K2L/K2E EVMs. This is done to
align with the usage on K2G ICE board which has a smaller DDR memory
footprint, and thereby allow same firmwares to be run on both the
K2G boards.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:36:02 +0000 (11:36 -0600)]
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2E EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 17:34:24 +0000 (11:34 -0600)]
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2L EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
Suman Anna [Tue, 23 Jan 2018 00:45:17 +0000 (18:45 -0600)]
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases

A reserved memory carveout node with the appropriate compatible property
is added on the K2HK EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.

A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: keystone-k2g: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:40 +0000 (15:33 -0500)]
ARM: dts: keystone-k2g: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2G
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: keystone-k2e: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:37 +0000 (15:33 -0500)]
ARM: dts: keystone-k2e: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2E
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: keystone-k2l: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:33 +0000 (15:33 -0500)]
ARM: dts: keystone-k2l: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2L
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: keystone-k2hk: Reserve SRAM for MPM
Suman Anna [Wed, 21 Apr 2021 20:33:29 +0000 (15:33 -0500)]
ARM: dts: keystone-k2hk: Reserve SRAM for MPM

Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2H
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.

A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: soc: ti: add the keystone_dsp_mem driver
Suman Anna [Mon, 19 Apr 2021 20:32:13 +0000 (15:32 -0500)]
TEMP: soc: ti: add the keystone_dsp_mem driver

A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.

The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.

The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.

The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoTEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Suman Anna [Mon, 19 Apr 2021 18:11:33 +0000 (13:11 -0500)]
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding

Add the device tree binding document for the userspace memory mapping
driver on TI Keystone SoCs. This driver is used to expose either some
portions of the DDR and/or some portions of the On-chip RAM controlled
by the Multicore Shared Memory Controller (MSMC) to userspace for the
Multi Proc Manager (MPM) stack.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 14 Apr 2021 18:15:55 +0000 (13:15 -0500)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

Pull in the base rpmsg tree that adds a uapi header for a new rpmsg
bus driver, rpmsg-rpc. This header will be used by MmRpc module in
IPC 3.x stack on OMAP4+ family of SoCs.

* 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: add the uapi rpmsg_rpc header

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agorpmsg: rpc: add the uapi rpmsg_rpc header
Suman Anna [Wed, 14 Apr 2021 16:42:21 +0000 (11:42 -0500)]
rpmsg: rpc: add the uapi rpmsg_rpc header

A new rpmsg client driver, rpmsg_rpc, will be introduced later that will
provide a framework for userspace applications to execute functions on
different remote processors.

The driver added in previous downstream TI kernels is not yet ready and
requires rework due to changes in dma-buf framework, to be ported and
be functional properly onto 5.10 kernel. Add and export the required
minimal uapi rpmsg_rpc.h header file for now to unblock the integration
of the TI IPC userspace components.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoti_config_fragments: rpmsg: Enable rpmsg-proto module
Suman Anna [Tue, 13 Apr 2021 21:46:44 +0000 (16:46 -0500)]
ti_config_fragments: rpmsg: Enable rpmsg-proto module

Add support to build the rpmsg sockets driver "rpmsg-proto"
explicitly now for both v5 and v7 platforms. The dependent
REMOTEPROC is already enabled as built-in in the needed
defconfigs (multi_v7_defconfig and davinci_all_defconfig).
The other dependent RPMSG_VIRTIO module is also already
enabled.

These options enable the TI MessageQ IPC stack for various
v5 (OMAP-L138) and v7 (66AK2x, DRA7xx, AM57xx etc) platforms.

The driver won't be supported for v8 (AM65x, J721E, J7200,
AM64x) platforms, and rpmsg-char driver continues to be the
default driver to use with userspace on these SoC families.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Wed, 14 Apr 2021 13:43:57 +0000 (08:43 -0500)]
Merge branch 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.10.y

Pull in the updated rpmsg base feature branch that adds a new
rpmsg bus driver, rpmsg-proto. The rpmsg-proto driver implements
a remote processor messaging socket interface, and supports the
MessageQ stack in the TI IPC product.

The merge also adds a new API to the rpmsg core to return the
maximum rpmsg transport payload size, that can be used by rpmsg
bus drivers when sending data over the virtio-rpmsg bus.

* 'rpmsg-linux-5.10.y' of git://git.ti.com/rpmsg/rpmsg:
  net/rpmsg: add support for new rpmsg sockets
  rpmsg: core: add API to get MTU

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 14 Apr 2021 13:42:30 +0000 (08:42 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the updated remoteproc feature branch that includes few cleanups
and enhancements to the Davinci remoteproc driver needed to support the
TI MessageQ stack with the DSP core on the OMAP-L138 SoCs.

The remoteproc driver continues to support the legacy-mode devices on
non-DT platforms, and the DT-mode device is supported on the OMAP-L138
LCDK board.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: da850: Add alias for DSP node
  remoteproc/davinci: Add a trace to print missing ids
  remoteproc/davinci: Switch a debug trace statement to use %pK

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: da850: Add alias for DSP node
Suman Anna [Wed, 2 Jan 2019 21:13:43 +0000 (15:13 -0600)]
ARM: dts: da850: Add alias for DSP node

Add alias for the lone DSP remoteproc processor node present
on the OMAP-L13x/DA8xx SoCs. The alias uses the stem "rproc".
The alias is added to assign a fixed remoteproc id to the DSP
processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc/davinci: Add a trace to print missing ids
Suman Anna [Mon, 15 Jan 2018 18:41:31 +0000 (12:41 -0600)]
remoteproc/davinci: Add a trace to print missing ids

The remoteproc fixed ids for Davinci 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 this unique id (alias id for DT devices and platform
device id for non-DT devices) is not defined for the DSP remoteproc
device.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc/davinci: Switch a debug trace statement to use %pK
Suman Anna [Wed, 2 Jan 2019 21:34:37 +0000 (15:34 -0600)]
remoteproc/davinci: Switch a debug trace statement to use %pK

Modify a debug trace statement to use %pK instead of %p for printing
the kernel virtual address for the mapped DSP internal memory regions.
The latter always prints a hashed address, and switching to %pK allows
the actual mapped address to be printed under proper conditions (by
writing a proper value to /proc/sys/kernel/kptr_restrict). The default
behavior is unchanged.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agonet/rpmsg: add support for new rpmsg sockets
Suman Anna [Tue, 13 Apr 2021 21:20:19 +0000 (16:20 -0500)]
net/rpmsg: add support for new rpmsg sockets

Add the support for a new socket address and protocol family -
remote-processor messaging sockets. This rpmsg protocol driver
provides the necessary support to expose a rpmsg communication
channel through the socket API to userspace under the AF_RPMSG
address family. The usage relies on leveraging the socket API's
connect() for Tx sockets and bind() for Rx sockets to exchange
messages to/from a remote processor. All message communication
is performed using the userspace created sockets, and even though
the probed rpmsg proto devices do create an embedded rpmsg endpoint
for receiving messages, they are not really designed to process
any such unexpected Rx messages.

This driver forms the kernel transport portion of the TI IPC
MessageQ stack. The MessageQ stack usage of the AF_RPMSG socket
interface is not really designed to handle multiple rpmsg-proto
devices published from the same remote processor, so a restriction
is imposed to allow only a single rpmsg device even though there
are no such restrictions imposed by the rpmsg bus infrastructure.
This can be scaled to make it more generic if needed but probably
will require some userspace interface adjustments.

This patch is based on some quite an old rpmsg socket support patch
from Ohad and some work by Rob Tivy. This has been updated rather
heavily to work with all the rpmsg framework changes in 4.9+ kernels.

Signed-off-by: Ohad Ben Cohen <ohad@wizery.com>
[s-anna@ti.com: adapted, improved and modified for latest kernel]
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agorpmsg: core: add API to get MTU
Arnaud Pouliquen [Tue, 13 Apr 2021 21:08:11 +0000 (16:08 -0500)]
rpmsg: core: add API to get MTU

Return the rpmsg buffer MTU for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Acked-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
[s-anna@ti.com: cherry-pick https://patchwork.kernel.org/project/linux-remoteproc/patch/20200324170407.16470-2-arnaud.pouliquen@st.com/]
[s-anna@ti.com: use EOPNOTSUPP to fix checkpatch warning]
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 13 Apr 2021 15:31:37 +0000 (10:31 -0500)]
Merge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.10.y

Pull in the remoteproc topic branch that enhances the remoteproc subsystem
and the K3 R5F and DSP remoteproc drivers to add support for 'IPC-only' mode.
The 'IPC-only' mode has the drivers attach/establish just the IPC/rpmsg stack
while the remote processors themselves would have been booted by a bootloader.

All R5F remote processors on AM65x, J721E and J7200 and all C66x & C71x DSP
remote processors on J721E SoCs are supported in this new 'IPC-only' mode.
The MCU R5FSS on J721E & J7200 SoCs serves as the Device Manager firmware
and would have been booted by MCU R5 SPL, with all the others early booted
from A53/A72 U-Boot.

The IPC-only mode support has been re-done completely w.r.t 5.4 LTS kernel,
and relies on a whole bunch of enhancements to the remoteproc subsystem
(currently staged attach/detach support patches for v5.13 kernel). The
design relies on newly introduced RPROC_ATTACHED and RPROC_DETACHED state
flags; new .attach(), .detach() and .get_loaded_rsc_table() rproc ops;
and changes to remoteproc sysfs and cdev interfaces. The .start() and
.stop() callbacks are not invoked in IPC-only mode.

The following is a quick summary of changes to remoteproc sysfs files
in IPC-only mode:
 - 'state' file shows either 'attached' or 'detached' instead of 'running'
   and 'offline' respectively. 'offline' state is shown if the drivers
   support stopping the early-booted remoteprocs
 - 'state' file gains a new 'detach' command in addition to 'start' and
   'stop' to specifically detach an early-booted remoteproc
 - 'firmware' file shows the firmware name as 'unknown'. Actual firmware
   file is shown only in remoteproc mode

The K3 firmwares follow a design-by-contract approach and are expected
to have the resource tables placed specifically at the base of the DDR
firmware region (base of carveout referenced at the second array index
position in the remoteproc node's memory-region property). The K3 R5F
and DSP remoteproc devices cannot be stopped in 'IPC-only' mode and
will only be detached. The firmwares are also not reloaded to do a
resource table lookup.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc: (21 commits)
  remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs
  remoteproc: k3-dsp: Refactor mbox request code in start
  remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
  remoteproc: k3-r5: Refactor mbox request code in start
  remoteproc: Add support for detach-only during shutdown
  remoteproc: Introduce rproc_detach_device() wrapper
  remoteproc: Refactor function rproc_cdev_release()
  remoteproc: Properly deal with a detach request when attached
  remoteproc: Properly deal with a stop request when attached
  remoteproc: Properly deal with a start request when attached
  remoteproc: Properly deal with a kernel panic when attached
  remoteproc: Properly deal with the resource table when stopping
  remoteproc: Properly deal with the resource table when detaching
  remoteproc: Introduce function rproc_detach()
  remoteproc: Introduce function __rproc_detach()
  remoteproc: Add new detach() remoteproc operation
  remoteproc: Use prepare ops in rproc_attach
  remoteproc: Add new get_loaded_rsc_table() to rproc_ops
  remoteproc: Properly represent the attached state
  remoteproc: Add new RPROC_ATTACHED state
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs
Suman Anna [Sat, 10 Apr 2021 06:06:21 +0000 (01:06 -0500)]
remoteproc: k3-dsp: Add support for IPC-only mode for all K3 DSPs

Add support to the K3 DSP remoteproc driver to configure all the C66x
and C71x cores on J721E SoCs to be either in IPC-only mode or the
traditional remoteproc mode. The IPC-only mode expects that the remote
processors are already booted by the bootloader, and only perform the
minimum steps required to initialize and deinitialize the virtio IPC
transports. The remoteproc mode allows the kernel remoteproc driver to
do the regular load and boot and other device management operations for
a DSP.

The IPC-only mode for a DSP is detected and configured at driver probe
time by querying the System Firmware for the DSP power and reset state
and/or status and making sure that the DSP is indeed started by the
bootloaders, otherwise the device is configured for remoteproc mode.

Support for IPC-only mode is achieved through .attach(), .detach() and
.get_loaded_rsc_table() callback ops and various other flags in both
remoteproc core and the K3 DSP remoteproc driver. The resource table
follows a design-by-contract approach and is expected to be at the base
of the DDR firmware region reserved for each remoteproc, it is mostly
expected to contain only the virtio device and trace resource entries.

NOTE:
The driver cannot configure a DSP core for remoteproc mode by any
means without rebooting the kernel if that R5F core has been started
by a bootloader.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: k3-dsp: Refactor mbox request code in start
Suman Anna [Sat, 10 Apr 2021 04:22:28 +0000 (23:22 -0500)]
remoteproc: k3-dsp: Refactor mbox request code in start

Refactor out the mailbox request and associated ping logic code
from k3_dsp_rproc_start() function into its own separate function
so that it can be re-used in the soon to be added .attach() ops
callback.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
Suman Anna [Sat, 10 Apr 2021 02:35:02 +0000 (21:35 -0500)]
remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs

Add support to the K3 R5F remoteproc driver to configure all the R5F
cores to be either in IPC-only mode or the traditional remoteproc mode.
The IPC-only mode expects that the remote processors are already booted
by the bootloader, and only performs the minimum steps required to
initialize and deinitialize the virtio IPC transports. The remoteproc
mode allows the kernel remoteproc driver to do the regular load and
boot and other device management operations for a R5F core.

The IPC-only mode for a R5F core is detected and configured at driver
probe time by querying the System Firmware for the R5F power and reset
state and/or status and making sure that the R5F core is indeed started
by the bootloaders, otherwise the device is configured for remoteproc
mode.

Support for IPC-only mode is achieved through .attach(), .detach() and
.get_loaded_rsc_table() callback ops and various other flags in both
remoteproc core and the K3 R5F remoteproc driver. The resource table
follows a design-by-contract approach and is expected to be at the base
of the DDR firmware region reserved for each remoteproc, it is mostly
expected to contain only the virtio device and trace resource entries.

NOTE:
The driver cannot configure a R5F core for remoteproc mode by any
means without rebooting the kernel if that R5F core has been started
by a bootloader.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: k3-r5: Refactor mbox request code in start
Suman Anna [Wed, 7 Apr 2021 14:46:30 +0000 (09:46 -0500)]
remoteproc: k3-r5: Refactor mbox request code in start

Refactor out the mailbox request and associated ping logic code
from k3_r5_rproc_start() function into its own separate function
so that it can be re-used in the soon to be added .attach() ops
callback.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: Add support for detach-only during shutdown
Suman Anna [Fri, 9 Apr 2021 22:07:29 +0000 (17:07 -0500)]
remoteproc: Add support for detach-only during shutdown

The remoteproc core has support for both stopping and detaching a
remote processor that was attached to previously, through both the
remoteproc sysfs and cdev interfaces. The rproc_shutdown() though
unconditionally only uses the stop functionality at present. This
may not be the default desired functionality for all the remoteproc
platform drivers.

Introduce a new rproc state flag 'detach_on_shutdown' that individual
remoteproc drivers can set to only allow detach in rproc_shutdown()
that would have been invoked when the driver is uninstalled, so that
remote processor continues to run undisturbed even after the driver
removal.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: Introduce rproc_detach_device() wrapper
Suman Anna [Fri, 9 Apr 2021 14:23:48 +0000 (09:23 -0500)]
remoteproc: Introduce rproc_detach_device() wrapper

The .attach() rproc ops is invoked through the helper
rproc_attach_device(), but the .detach() ops is invoked
directly at present. Introduce a similar wrapper function
rproc_detach_device() for .detach() ops so that the code
is symmetric.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: Refactor function rproc_cdev_release()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:53 +0000 (09:24 -0700)]
remoteproc: Refactor function rproc_cdev_release()

Refactor function rproc_cdev_release() to take into account the
current state of the remote processor when choosing the state to
transition to.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210312162453.1234145-18-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '6e71d2b2a2b7' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoremoteproc: Properly deal with a detach request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:52 +0000 (09:24 -0700)]
remoteproc: Properly deal with a detach request when attached

This patch introduces the capability to detach a remote processor
that has been attached to by the remoteproc core.  For that to happen
a rproc::ops::detach() operation needs to be available.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-17-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '5daaeb5f07ed' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>