rpmsg/rpmsg.git
12 days agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-5.10.y
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>
12 days 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>
12 days 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>
12 days 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]

12 days 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>
13 days 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>
13 days 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
2 weeks 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>
3 weeks 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>
3 weeks agorpmsg: rpc: add the uapi rpmsg_rpc header rpmsg-linux-5.10.y
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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks 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>
3 weeks agoremoteproc: Properly deal with a stop request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:51 +0000 (09:24 -0700)]
remoteproc: Properly deal with a stop request when attached

Allow a remote processor that was started by another entity to be
switched off by the remoteproc core.  For that to happen a
rproc::ops::stop() 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-16-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit 'd2008a968330' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Properly deal with a start request when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:50 +0000 (09:24 -0700)]
remoteproc: Properly deal with a start request when attached

This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.

As with the case with the running state, the command can't be
carried out if the remote processor is already in operation.

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-15-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '83d4e6712c3b' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Properly deal with a kernel panic when attached
Mathieu Poirier [Fri, 12 Mar 2021 16:24:49 +0000 (09:24 -0700)]
remoteproc: Properly deal with a kernel panic when attached

The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-14-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '800dad0025ec' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Properly deal with the resource table when stopping
Mathieu Poirier [Fri, 12 Mar 2021 16:24:48 +0000 (09:24 -0700)]
remoteproc: Properly deal with the resource table when stopping

When a remote processor that was attached to is stopped, special care
must be taken to make sure the shutdown process is similar to what
it would be had it been started by the remoteproc core.

This patch takes care of that by making a copy of the resource
table currently used by the remote processor.  From that point on
the copy is used, as if the remote processor had been started by
the remoteproc core.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-13-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '8088dd4d9316' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Properly deal with the resource table when detaching
Mathieu Poirier [Fri, 12 Mar 2021 16:24:47 +0000 (09:24 -0700)]
remoteproc: Properly deal with the resource table when detaching

If it is possible to detach the remote processor, keep an untouched
copy of the resource table.  That way we can start from the same
resource table without having to worry about original values or what
elements the startup code has changed when re-attaching to the remote
processor.

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-12-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '9dc9507f1880' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Introduce function rproc_detach()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:46 +0000 (09:24 -0700)]
remoteproc: Introduce function rproc_detach()

Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.

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-11-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit 'd3962a397885' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Introduce function __rproc_detach()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:45 +0000 (09:24 -0700)]
remoteproc: Introduce function __rproc_detach()

Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach().  That way it is possible for the core
to release the resources associated with a remote processor while
the latter is kept operating.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-10-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '6070203fe433' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Add new detach() remoteproc operation
Mathieu Poirier [Fri, 12 Mar 2021 16:24:44 +0000 (09:24 -0700)]
remoteproc: Add new detach() remoteproc operation

Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating.  This could be the case when the system is
rebooted or when the platform driver is removed.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-9-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '7f3bd0c019cb' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Use prepare ops in rproc_attach
Arnaud POULIQUEN [Fri, 12 Mar 2021 16:24:43 +0000 (09:24 -0700)]
remoteproc: Use prepare ops in rproc_attach

Some actions such as memory resources reallocation are needed when
trying to reattach a co-processor. Use the prepare() operation for
these actions.

This is a custom backport of just the remoteproc core pieces from
the commit 6e20a05104e5 ("remoteproc: stm32: Move memory parsing to
rproc_ops")

Co-developed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-8-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: custom cherry-pick linux-next commit '6e20a05104e5' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Add new get_loaded_rsc_table() to rproc_ops
Mathieu Poirier [Fri, 12 Mar 2021 16:24:41 +0000 (09:24 -0700)]
remoteproc: Add new get_loaded_rsc_table() to rproc_ops

Add a new get_loaded_rsc_table() operation in order to support
scenarios where the remoteproc core has booted a remote processor
and detaches from it.  When re-attaching to the remote processor,
the core needs to know where the resource table has been placed
in memory.

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-6-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '1a631382be1d' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Properly represent the attached state
Mathieu Poirier [Fri, 12 Mar 2021 16:24:40 +0000 (09:24 -0700)]
remoteproc: Properly represent the attached state

There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core.  In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-5-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '76f4c87587e2' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Add new RPROC_ATTACHED state
Mathieu Poirier [Fri, 12 Mar 2021 16:24:39 +0000 (09:24 -0700)]
remoteproc: Add new RPROC_ATTACHED state

Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-4-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '4196d18903f9' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 weeks agoremoteproc: Rename function rproc_actuate()
Mathieu Poirier [Fri, 12 Mar 2021 16:24:38 +0000 (09:24 -0700)]
remoteproc: Rename function rproc_actuate()

Rename function rproc_actuate() to rproc_attach().  That way it is
easy to understand that it does the opposite of rproc_detach().

Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20210312162453.1234145-3-mathieu.poirier@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick linux-next commit '6a6c4dc0e5de' for v5.13]
Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Sun, 28 Mar 2021 16:11:03 +0000 (11:11 -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
infrastructure to enable the PRUSS Ethernet driver to be able to
load and boot Ethernet-specific firmwares onto the PRUs on various
TI industrial boards (AM335x ICEv2, AM437x IDK, AM572x IDK, AM571x
IDK, K2G-ICE, AM65x EVM, AM65x IDK, and J721E IDK boards).

The support is made possible by adding various new API to the PRUSS
platform drivers - these include API to get a PRU rproc instance,
and from it a PRUSS instance, request various memory regions, API
to program the various PRUSS syscon sub-modules and helper functions
to program certain common registers within the PRUSS CFG space. The
PRU remoteproc infrastructure is also enhanced to parse the client
DT nodes and program in client specific features such as the PRU
core firmware names, and the internal PinMux configuration. The
current infrastructure already supports a resource-table less PRU
firmwares, the PRU-side INTC event interrupt configuration is
provided through a no-load custom firmware ELF section.

The merge also includes an enhancement to the remoteproc core - a
state-machine fix for the sysfs path for the no auto-boot remoteprocs.
A public rproc_set_firmware() API to be able to configure the firmware
name at runtime (reused by sysfs code as well) from consumer DT nodes.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/pru: add support for configuring GPMUX based on client setup
  soc: ti: pruss: Add helper functions to get/set PRUSS_CFG_GPMUX
  soc: ti: pruss: Add helper function to enable OCP master ports
  soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR
  soc: ti: pruss: Add pruss_cfg_read()/update() API
  soc: ti: pruss: Add pruss_{request,release}_mem_region() API
  soc: ti: pruss: Add pruss_get()/put() API
  remoteproc: pru: Configure firmware based on client setup
  remoteproc: pru: Add pru_rproc_set_ctable() function
  remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
  remoteproc: pru: Add APIs to get and put the PRU cores
  dt-bindings: remoteproc: Add PRU consumer bindings
  remoteproc: wkup_m3: Set deny_sysfs_ops flag
  remoteproc: Introduce deny_sysfs_ops flag
  remoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs

Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoremoteproc/pru: add support for configuring GPMUX based on client setup
Tero Kristo [Sat, 27 Mar 2021 15:11:42 +0000 (10:11 -0500)]
remoteproc/pru: add support for configuring GPMUX based on client setup

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: simplify the pru id usage]
Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agosoc: ti: pruss: Add helper functions to get/set PRUSS_CFG_GPMUX
Tero Kristo [Sat, 27 Mar 2021 14:24:51 +0000 (09:24 -0500)]
soc: ti: pruss: Add helper functions to get/set PRUSS_CFG_GPMUX

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

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agosoc: ti: pruss: Add helper function to enable OCP master ports
Suman Anna [Fri, 26 Mar 2021 21:38:11 +0000 (16:38 -0500)]
soc: ti: pruss: Add helper function to enable OCP master ports

The PRU-ICSS subsystem on OMAP-architecture based SoCS (AM33xx, AM437x
and AM57xx SoCs) has a control bit STANDBY_INIT in the PRUSS_CFG register
to initiate a Standby sequence (when set) and trigger a MStandby request
to the SoC's PRCM module. This same bit is also used to enable the OCP
master ports (when cleared). The clearing of the STANDBY_INIT bit requires
an acknowledgment from PRCM and is done through the monitoring of the
PRUSS_SYSCFG.SUB_MWAIT bit.

Add a helper function pruss_cfg_ocp_master_ports() to allow the PRU
client drivers to control this bit and enable or disable the firmware
running on PRU cores access to any peripherals or memory to achieve
desired functionality. The access is disabled by default on power-up
and on any suspend (context is not maintained).

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>
5 weeks agosoc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR
Suman Anna [Fri, 11 Dec 2020 18:48:09 +0000 (19:48 +0100)]
soc: ti: pruss: Add helper functions to set GPI mode, MII_RT_event and XFR

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

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>
5 weeks agosoc: ti: pruss: Add pruss_cfg_read()/update() API
Suman Anna [Fri, 26 Mar 2021 21:27:34 +0000 (16:27 -0500)]
soc: ti: pruss: Add pruss_cfg_read()/update() API

Add two new generic API pruss_cfg_read() and pruss_cfg_update() to
the PRUSS platform driver to allow other drivers to read and program
respectively a register within the PRUSS CFG sub-module represented
by a syscon driver. This interface provides a simple way for client
drivers without having them to include and parse the CFG syscon node
within their respective device nodes. Various useful registers and
macros for certain register bit-fields and their values have also
been added.

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

Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agosoc: ti: pruss: Add pruss_{request,release}_mem_region() API
Andrew F. Davis [Fri, 26 Mar 2021 21:11:42 +0000 (16:11 -0500)]
soc: ti: pruss: Add pruss_{request,release}_mem_region() API

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

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agosoc: ti: pruss: Add pruss_get()/put() API
Tero Kristo [Fri, 26 Mar 2021 20:58:00 +0000 (15:58 -0500)]
soc: ti: pruss: Add pruss_get()/put() API

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

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

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agoremoteproc: pru: Configure firmware based on client setup
Tero Kristo [Fri, 26 Mar 2021 20:50:14 +0000 (15:50 -0500)]
remoteproc: pru: Configure firmware based on client setup

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

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agoremoteproc: pru: Add pru_rproc_set_ctable() function
Roger Quadros [Fri, 26 Mar 2021 20:43:53 +0000 (15:43 -0500)]
remoteproc: pru: Add pru_rproc_set_ctable() function

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

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

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

Co-developed-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agoremoteproc: pru: Deny rproc sysfs ops for PRU client driven boots
Suman Anna [Wed, 16 Dec 2020 16:52:37 +0000 (17:52 +0100)]
remoteproc: pru: Deny rproc sysfs ops for PRU client driven boots

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

Signed-off-by: Suman Anna <s-anna@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agoremoteproc: pru: Add APIs to get and put the PRU cores
Tero Kristo [Fri, 26 Mar 2021 20:32:29 +0000 (15:32 -0500)]
remoteproc: pru: Add APIs to get and put the PRU cores

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

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

Co-developed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
5 weeks agodt-bindings: remoteproc: Add PRU consumer bindings
Suman Anna [Fri, 26 Mar 2021 20:29:04 +0000 (15:29 -0500)]
dt-bindings: remoteproc: Add PRU consumer bindings

Add a YAML binding document for PRU consumers. The binding includes
all the common properties that can be used by different PRU consumer
or application nodes and supported by the PRU remoteproc driver.
These are used to configure the PRU hardware for specific user
applications.

The application nodes themselves should define their own bindings.

Co-developed-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
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>
5 weeks agoremoteproc: wkup_m3: Set deny_sysfs_ops flag
Suman Anna [Sat, 21 Nov 2020 03:01:56 +0000 (21:01 -0600)]
remoteproc: wkup_m3: Set deny_sysfs_ops flag

The Wakeup M3 remote processor is controlled by the wkup_m3_ipc
client driver, so set the newly introduced 'deny_sysfs_ops' flag
to not allow any overriding of the remoteproc firmware or state
from userspace.

Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
5 weeks agoremoteproc: Introduce deny_sysfs_ops flag
Suman Anna [Fri, 26 Mar 2021 18:05:28 +0000 (13:05 -0500)]
remoteproc: Introduce deny_sysfs_ops flag

The remoteproc framework provides sysfs interfaces for changing the
firmware name and for starting/stopping a remote processor through
the sysfs files 'state' and 'firmware'. The 'recovery' and 'coredump'
sysfs files can also be used similarly to control the error recovery
state machine and coredump of a remoteproc. These interfaces are
currently  allowed irrespective of how the remoteprocs were booted
(like remoteproc self auto-boot, remoteproc client-driven boot etc).
These interfaces can adversely affect a remoteproc and its clients
especially when a remoteproc is being controlled by a remoteproc
client driver(s). Also, not all remoteproc drivers may want to
support the sysfs interfaces by default.

Add support to deny the sysfs state/firmware/recovery/coredump change
by introducing a state flag 'deny_sysfs_ops' that the individual
remoteproc drivers can set based on their usage needs. The default
behavior is to allow the sysfs operations as before.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 25 Mar 2021 18:25:11 +0000 (13:25 -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 brings in the support
for two new sub-modules within a PRUSS IP - an Industrial Ethernet
Peripheral (IEP) and an Enhanced Capture (eCAP) sub-module. The changes
include:
 - Add YAML bindings for IEP sub-module and corresponding dts nodes on
   all SoCs.
 - Add YAML bindings for eCAP sub-module and the corresponding eCAP dts
   nodes for AM335x, AM437x, AM57xx and 66AK2G SoCs.

The eCAP module is also present on K3 SoCs but support for them is not
added currently. The PRUSS eCAP module will be used for adding
interrupt-pacing support within the PRU Ethernet drivers.

The IEP and eCAP platform drivers and their usage within PRU Ethernet
drivers is out of scope on this tree, and will be merged through the
Connectivity domain tree.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: keystone-k2g: Add PRUSS eCAP nodes
  ARM: dts: am57xx: Add PRUSS eCAP nodes
  ARM: dts: am437x: Add PRUSS eCAP node
  ARM: dts: am335x: Add PRUSS eCAP node
  dt-bindings: soc: ti: pruss: Add eCAP documentation
  dt-bindings: net: pruss_ecap: Add dt binding documentation
  ARM: dts: keystone-k2g: Add PRUSS IEP nodes
  ARM: dts: am57xx: Add PRUSS IEP nodes
  ARM: dts: am4372: Add PRUSS IEP nodes
  ARM: dts: am335x: Add PRUSS IEP node
  arm64: dts: ti: k3-j721e-main: Add ICSSG IEP nodes
  arm64: dts: ti: k3-am65-main: Add ICSSG IEP nodes
  dt-bindings: net: icss_iep: Add dt binding documentation

Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoti_config_fragments: rpmsg/v8_rpmsg: Enable PRUSS support
Suman Anna [Wed, 17 Mar 2021 03:26:10 +0000 (22:26 -0500)]
ti_config_fragments: rpmsg/v8_rpmsg: Enable PRUSS support

Add support to build all the PRUSS platform drivers - PRUSS driver, the
PRUSS INTC IrqChip driver and the PRU remoteproc driver as modules by
default. This will enable the PRU-ICSS instance(s) present on various
AM33xx, AM437x, AM57xx, 66AK2G, and the K3 AM65x and J721E family of
SoCs.

Note that the PRUSS INTC module is a silent Kconfig option, and so
need not be enabled explicitly, but is being added for conformity
with older kernels.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 25 Mar 2021 18:10:48 +0000 (13:10 -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 foundation
support for the PRUSS subsystem on OMAP-architecture based AM33xx,
AM437x, and AM57xx SoCs; Keystone-architecture based 66AK2G SoCs; and
K3 architecture based AM65x and J721E SoCs. 66AK2G is the first SoC in
the Keystone 2 family to have PRUSS IPs. The AM65x and J721E SoCs have
the next version of the IP called ICSSG. The drivers include a PRUSS
platform driver, a PRUSS INTC irqchip driver, and a PRU remoteproc driver
to load and boot the PRU cores within the PRU-ICSS subsystem. The new
modules that will be built are pruss.ko, irq-pruss-intc.ko and
pru_rproc.ko respectively. The PRU remoteproc driver follows a
no auto-boot architecture, and requires a client driver/application
to trigger a PRU boot.

The changes new to 5.10 kernel include revised compatibles for AM437x
PRUSS, reworking of PRUSS CFG sub-module clock muxes, making the
resource table optional, removal of exported API from PRUSS INTC driver
and leveraging DT for all Linux-side INTC mapping configuration using
modified #interrupt-cells value (3), and using a new non-loadable
".pru_irq_map" firmware ELF section for PRU-side interrupt mappings.

The PRUSS and PRUSS INTC irqchip drivers are already present in upstream
v5.10 kernel, and the PRU remoteproc driver support is backported from
upstream v5.11 kernel. The OMAP-architecture based support is built on
top of the already upstream ti-sysc interconnect driver and omap-prm
reset driver. The ti-sysc bus driver is already enhanced to deal with
the unique PRUSS SYSC type.

Supported instances include the single PRU-ICSS on AM335x; both the
regular PRU-ICSS1 and the smaller PRU-ICSS0 instances on AM437x SoCs;
both the PRU-ICSS1 and PRU-ICSS2 instances on AM57xx SoCs; both the
PRU-ICSS0 and PRU-ICSS1 instances on 66AK2G SoCs; all the three ICSSG0,
ICSSG1 and ICSSG2 instances on AM65x SoCs; and both the ICSSG0 and
ICSSG1 instances on J721E SoCs. Supported platforms include all the
TI supported AM33xx and AM437x boards, the AM57xx BeagleBoard-X15 boards,
AM57xx GP EVMs, all three of the AM571x, AM572x and AM574x IDKS, both
the K2G-EVM and K2G-ICE boards, the AM65x EVM and IDK boards, and the
J721E EVM and IDK boards.

The merge does not include the support for RPMsg stack yet, so the
infrastructure currently supports only very simple PRU firmware images.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc: (35 commits)
  ARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes
  ARM: dts: keystone-k2g: Add the PRU-ICSS nodes
  ARM: dts: am57xx: Add PRUSS MDIO controller nodes
  ARM: dts: am57xx: Add PRU-ICSS nodes
  ARM: dts: am4372: Add PRUSS MDIO controller node
  ARM: dts: am4372: Add the PRU-ICSS0 DT node
  ARM: dts: am4372: Add the PRU-ICSS1 DT node
  ARM: dts: am335x-icev2: Enable PRU-ICSS module
  ARM: dts: am335x-evmsk: Enable PRU-ICSS module
  ARM: dts: am335x-evm: Enable PRU-ICSS module
  ARM: dts: am335x-bone-common: Enable PRU-ICSS node
  ARM: dts: am33xx-l4: Add PRUSS MDIO controller node
  ARM: dts: am33xx-l4: Add PRUSS node
  arm64: dts: ti: k3-j721e-main: Add ICSSG MDIO nodes
  arm64: dts: ti: k3-am65-main: Add ICSSG MDIO nodes
  arm64: dts: ti: k3-j721e-main: Add ICSSG nodes
  arm64: dts: ti: k3-am65-main: Add ICSSG nodes
  remoteproc: pru: Fix and cleanup firmware interrupt mapping logic
  remoteproc: pru: Fix wrong success return value for fw events
  remoteproc: pru: Fixup interrupt-parent logic for fw events
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
5 weeks agoMerge branch 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 25 Mar 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 backports couple of
minor cleanups/fixes in the remoteproc core from upstream linux-next,
these are staged for v5.13 kernel.

* 'rproc-linux-5.10.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: core: Remove casting to rproc_handle_resource_t
  remoteproc: sysfs: Use sysfs_emit instead of sprintf

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoremoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs
Suman Anna [Sat, 21 Nov 2020 03:01:54 +0000 (21:01 -0600)]
remoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs

The remoteproc core performs automatic boot and shutdown of a remote
processor during rproc_add() and rproc_del() for remote processors
supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
require either a remoteproc client driver or a userspace client to
use the sysfs 'state' variable to perform the boot and shutdown. The
in-kernel client drivers hold the corresponding remoteproc driver
module's reference count when they acquire a rproc handle through
the rproc_get_by_phandle() API, but there is no such support for
userspace applications performing the boot through sysfs interface.

The shutdown of a remoteproc upon removing a remoteproc platform
driver is automatic only with 'auto-boot' and this can cause a
remoteproc with no auto-boot to stay powered on and never freed
up if booted using the sysfs interface without a matching stop,
and when the remoteproc driver module is removed or unbound from
the device. This will result in a memory leak as well as the
corresponding remoteproc ida being never deallocated. Fix this
by holding a module reference count for the remoteproc's driver
during a sysfs 'start' and releasing it during the sysfs 'stop'
operation.

Signed-off-by: Suman Anna <s-anna@ti.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
6 weeks agoARM: dts: keystone-k2g: Add PRUSS eCAP nodes
Murali Karicheri [Thu, 30 Jul 2020 19:20:15 +0000 (14:20 -0500)]
ARM: dts: keystone-k2g: Add PRUSS eCAP nodes

The PRUSS on 66AK2G SoCs has an Enhanced Capture (eCAP) sub-module
that can be used by PRU Ethernet to provide rx interrupt pacing
support.

Add the dt nodes for this eCAP module as child nodes within the
respective PRU-ICSS nodes.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am57xx: Add PRUSS eCAP nodes
Murali Karicheri [Thu, 30 Jul 2020 19:19:00 +0000 (14:19 -0500)]
ARM: dts: am57xx: Add PRUSS eCAP nodes

The PRUSS on AM57xx SoCs has an Enhanced Capture (eCAP) sub-module
that can be used by PRU Ethernet to provide rx interrupt pacing
support.

Add the dt nodes for this eCAP module as a child node within the
respective PRU-ICSS nodes.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am437x: Add PRUSS eCAP node
Murali Karicheri [Thu, 30 Jul 2020 19:13:59 +0000 (14:13 -0500)]
ARM: dts: am437x: Add PRUSS eCAP node

The PRUSS on AM437x SoCs has an Enhanced Capture (eCAP) sub-module
that can be used by PRU Ethernet to provide rx interrupt pacing
support.

Add the dt node for this eCAP module as a child node within the
PRU-ICSS1 node. The eCAP module is not pinned out on PRU-ICSS0
instance.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am335x: Add PRUSS eCAP node
Murali Karicheri [Thu, 30 Jul 2020 19:13:25 +0000 (14:13 -0500)]
ARM: dts: am335x: Add PRUSS eCAP node

The PRUSS on AM335x SoCs has an Enhanced Capture (eCAP) sub-module
that can be used by PRU Ethernet to provide rx interrupt pacing
support.

Add the dt node for this eCAP module as a child node within the
PRU-ICSS node.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agodt-bindings: soc: ti: pruss: Add eCAP documentation
Suman Anna [Wed, 17 Mar 2021 16:51:52 +0000 (11:51 -0500)]
dt-bindings: soc: ti: pruss: Add eCAP documentation

Update PRUSS bindings documentation to include the eCAP information.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agodt-bindings: net: pruss_ecap: Add dt binding documentation
Murali Karicheri [Wed, 17 Mar 2021 02:29:50 +0000 (21:29 -0500)]
dt-bindings: net: pruss_ecap: Add dt binding documentation

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) contains an Enhanced Capture (eCAP) Module
that has a counter and provides some time-stamp capture events. This
adds dt bindings documentation for this pruss_ecap device.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: keystone-k2g: Add PRUSS IEP nodes
Suman Anna [Tue, 16 Mar 2021 23:32:36 +0000 (18:32 -0500)]
ARM: dts: keystone-k2g: Add PRUSS IEP nodes

The PRU-ICSS IPs on 66AK2G SoCs has an Industrial Ethernet Peripheral (IEP)
to manage/generate Industrial Ethernet functions such as time stamping.
The IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSS_IEP_CLK or the ICSS_VCLK_CLK
clocks. Add the IEP node for both the PRU-ICSS instances.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agoARM: dts: am57xx: Add PRUSS IEP nodes
Suman Anna [Tue, 16 Mar 2021 23:29:41 +0000 (18:29 -0500)]
ARM: dts: am57xx: Add PRUSS IEP nodes

The PRU-ICSS IPs on AM57xx SoCs has an Industrial Ethernet Peripheral (IEP)
to manage/generate Industrial Ethernet functions such as time stamping.
The IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSS_IEP_CLK or the ICSS_CLK
clocks. Add the IEP node for both the PRU-ICSS instances.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agoARM: dts: am4372: Add PRUSS IEP nodes
Suman Anna [Tue, 16 Mar 2021 23:28:53 +0000 (18:28 -0500)]
ARM: dts: am4372: Add PRUSS IEP nodes

The PRU-ICSS IPs on AM437x SoCs has an Industrial Ethernet Peripheral (IEP)
to manage/generate Industrial Ethernet functions such as time stamping.
The IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's PRU_ICSS_IEP_GCLK or the
PRU_ICSS_OCP_GCLK clocks. Add the IEP node for both PRU-ICSS instances.
The PRU-ICSS0 instance is not pinned out, so it is disabled.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agoARM: dts: am335x: Add PRUSS IEP node
Suman Anna [Tue, 16 Mar 2021 23:23:44 +0000 (18:23 -0500)]
ARM: dts: am335x: Add PRUSS IEP node

The PRU-ICSS IP on AM335x SoCs has an Industrial Ethernet Peripheral (IEP)
to manage/generate Industrial Ethernet functions such as time stamping.
The IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's PRU_ICSS_IEP_GCLK or the
PRU_ICSS_OCP_GCLK clocks. Add the IEP node for the lone PRU-ICSS instance.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agoarm64: dts: ti: k3-j721e-main: Add ICSSG IEP nodes
Suman Anna [Tue, 16 Mar 2021 23:14:08 +0000 (18:14 -0500)]
arm64: dts: ti: k3-j721e-main: Add ICSSG IEP nodes

The ICSSG IP on J721E SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSSG_IEP_GCLK or ICSSG_ICLK.
Add both the IEP nodes for all the ICSSG instances.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agoarm64: dts: ti: k3-am65-main: Add ICSSG IEP nodes
Suman Anna [Tue, 16 Mar 2021 23:00:25 +0000 (18:00 -0500)]
arm64: dts: ti: k3-am65-main: Add ICSSG IEP nodes

The ICSSG IP on AM65x SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
sourced from either of the IP instance's ICSSG_IEP_GCLK or ICSSG_ICLK.
Add the IEP nodes for all the ICSSG instances.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
6 weeks agodt-bindings: net: icss_iep: Add dt binding documentation
Lokesh Vutla [Tue, 16 Mar 2021 22:19:36 +0000 (17:19 -0500)]
dt-bindings: net: icss_iep: Add dt binding documentation

Add DT binding documentation for ICSS IEP module.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes
Suman Anna [Wed, 22 Jan 2020 22:10:13 +0000 (16:10 -0600)]
ARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: keystone-k2g: Add the PRU-ICSS nodes
Suman Anna [Tue, 16 Mar 2021 17:56:22 +0000 (12:56 -0500)]
ARM: dts: keystone-k2g: Add the PRU-ICSS nodes

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

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

The PRUSS subsystem node contains the entire address space. The various
sub-modules of the PRU-ICSS are represented as individual child nodes
(so platform devices themselves) of the PRUSS subsystem node. These
include the two PRU cores and the interrupt controller. All the Data
RAMs are represented within a child node of its own named 'memories'
without any compatible. The Real Time Media Independent Interface
controller (MII_RT), and the CFG sub-module are represented as syscon
nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk
node is added under the CFG child node 'clocks'. The default source
for this mux clock is the ICSS_IEP_CLK clock.

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

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

Note:
1. There are few more sub-modules like the Industrial Ethernet Peripheral
   (IEPs), MDIO, UART, eCAP that do not have bindings and so will be added
   in the future.
2. The PRUSS INTC on 66AK2G SoCs route the host interrupts 0, 1, 2, 3, 4,
   6 and 7 to both the ARM GIC and CIC, so use the 'ti,irqs-reserved'
   property in derivative board dts files _if_ any of them should not be
   handled by the host OS. Host interrupt 5 is already marked reserved as
   it is connected to the other PRUSS instance.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am57xx: Add PRUSS MDIO controller nodes
Suman Anna [Tue, 16 Mar 2021 17:50:30 +0000 (12:50 -0500)]
ARM: dts: am57xx: Add PRUSS MDIO controller nodes

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

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

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am57xx: Add PRU-ICSS nodes
Suman Anna [Tue, 16 Mar 2021 17:49:32 +0000 (12:49 -0500)]
ARM: dts: am57xx: Add PRU-ICSS nodes

Add the DT nodes for the PRU-ICSS1 and PRU-ICSS2 processor subsystems
that are present on AM57xx family of SoCs. Each PRU-ICSS instance is
represented by a pruss node and other child nodes. The two PRU-ICSSs
are identical to each other. They are not supported on DRA7xx SoCs in
general, so the nodes are added under the respective interconnect target
module nodes in a common am57-pruss.dtsi file. The file is already
included only in the AM57xx related board files.

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

The PRUSS subsystem node contains the entire address space. The various
sub-modules of the PRU-ICSS are represented as individual child nodes
(so platform devices themselves) of the PRUSS subsystem node. These
include the two PRU cores and the interrupt controller. All the Data
RAMs are represented within a child node of its own named 'memories'
without any compatible. The Real Time Media Independent Interface
controller (MII_RT), and the CFG sub-module are represented as syscon
nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk
node is added under the CFG child node 'clocks'. The default source
for this mux clock is the ICSS_IEP_CLK clock.

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

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

Note:
1. There are few more sub-modules like the Industrial Ethernet Peripheral
   (IEPs), MDIO, UART, eCAP that do not have bindings and so will be added
   in the future.
2. The PRUSS INTC on AM57xx SoCs also connect the host interrupts 6 and 7
   as possible DMA events, so use the 'ti,irqs-reserved' property in
   derivative board dts files _if_ any of them should not be handled by
   the host OS.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
6 weeks agoARM: dts: am4372: Add PRUSS MDIO controller node
Andrew F. Davis [Tue, 30 Jan 2018 21:08:46 +0000 (15:08 -0600)]
ARM: dts: am4372: Add PRUSS MDIO controller node

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

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

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: fix reg address, add commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am4372: Add the PRU-ICSS0 DT node
Suman Anna [Tue, 16 Mar 2021 17:32:59 +0000 (12:32 -0500)]
ARM: dts: am4372: Add the PRU-ICSS0 DT node

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

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

The nodes are added under the corresponding interconnect target module
node in the common am4372 dtsi file. The PRU-ICSS instances are not
supported on AM4372 SoC though in the AM437x family, so the interconnect
target module node should be disabled in any derivative board dts file that
uses AM4372 SoCs. The individual PRUSS node can be disabled in the
corresponding board dts file if desired.

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

Note:
1. There are few more sub-modules like the Industrial Ethernet Peripheral
   (IEP), eCAP, UART, that do not have bindings and so will be added in the
   future. Only UART is pinned out, so others should be added in disabled
   state if added.
2. The PRUSS0 INTC on AM437x SoCs routes the host interrupt 5 to the other
   PRUSS1, so it is already marked reserved through the 'ti,irqs-reserved'
   property.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am4372: Add the PRU-ICSS1 DT node
Suman Anna [Tue, 16 Mar 2021 17:01:11 +0000 (12:01 -0500)]
ARM: dts: am4372: Add the PRU-ICSS1 DT node

Add the DT node for the PRU-ICSS1 instance on the AM437x family of SoCs.
Each PRU-ICSS instance is represented by a pruss node and other child
nodes. The nodes are added under the interconnect target module node in
the common am4372 dtsi file. The PRU-ICSS instances are not supported
on AM4372 SoC though in the AM437x family, so the interconnect target
module node should be disabled in any derivative board dts file that
uses AM4372 SoCs.

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

The PRUSS subsystem node contains the entire address space. The various
sub-modules of the PRU-ICSS are represented as individual child nodes
(so platform devices themselves) of the PRUSS subsystem node. These
include the two PRU cores and the interrupt controller. All the Data
RAMs are represented within a child node of its own named 'memories'
without any compatible. The Real Time Media Independent Interface
controller (MII_RT), and the CFG sub-module are represented as syscon
nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk
node is added under the CFG child node 'clocks'. The default source
for this mux clock is the PRU_ICSS_IEP_GCLK clock.

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

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

Note:
1. There are few more sub-modules like the Industrial Ethernet Peripheral
   (IEP), MDIO, UART, eCAP that do not have bindings and so will be added
   in the future.
2. The PRUSS INTC on AM437x SoCs also connect the host interrupt 0 to ADC0
   and ADC1; 6 and 7 as possible DMA events, so use the 'ti,irqs-reserved'
   property in derivative board dts files _if_ any of them should not be
   handled by the host OS. Host interrupt 5 is already marked reserved as
   it is connected to the other PRUSS instance.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am335x-icev2: Enable PRU-ICSS module
Suman Anna [Mon, 27 Jan 2020 20:36:56 +0000 (14:36 -0600)]
ARM: dts: am335x-icev2: Enable PRU-ICSS module

The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x ICEv2
board, so enable this node to support PRUSS on this board. The PRUSS
node and most of its child nodes are already enabled in the base dts
file, and so become effective automatically with the enabling of
this PRU-ICSS target module node.

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am335x-evmsk: Enable PRU-ICSS module
Suman Anna [Mon, 27 Jan 2020 20:34:43 +0000 (14:34 -0600)]
ARM: dts: am335x-evmsk: Enable PRU-ICSS module

The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x SK
EVM board, so enable this node to support PRUSS on this board. The
PRUSS node and most of its child nodes are already enabled in the
base dts file, and so become effective automatically with the
enabling of this PRU-ICSS target module node.

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am335x-evm: Enable PRU-ICSS module
Suman Anna [Mon, 27 Jan 2020 20:06:59 +0000 (14:06 -0600)]
ARM: dts: am335x-evm: Enable PRU-ICSS module

The PRU-ICSS target module node was left in disabled state in the
base am33xx-l4.dtsi file. PRU-ICSS is supported on the AM335x EVM,
so enable this node on the AM335x EVM. The PRUSS node and most of
its child nodes are already enabled in the base dts file, and so
become effective automatically with the enabling of this PRU-ICSS
target module node.

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am335x-bone-common: Enable PRU-ICSS node
Suman Anna [Mon, 27 Jan 2020 19:58:52 +0000 (13:58 -0600)]
ARM: dts: am335x-bone-common: Enable PRU-ICSS node

The PRU-ICSS target module node was left in disabled state in the base
am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
boards as they mostly use a AM3358 or a AM3359 SoC which do contain
the PRU-ICSS IP. The PRUSS node and most of its child nodes are already
enabled in the base dts file, and so become effective automatically
with the enabling of this PRU-ICSS target-module node.

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am33xx-l4: Add PRUSS MDIO controller node
Suman Anna [Tue, 16 Mar 2021 16:53:56 +0000 (11:53 -0500)]
ARM: dts: am33xx-l4: Add PRUSS MDIO controller node

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoARM: dts: am33xx-l4: Add PRUSS node
Suman Anna [Tue, 16 Mar 2021 16:37:53 +0000 (11:37 -0500)]
ARM: dts: am33xx-l4: Add PRUSS node

Add the DT nodes for the PRU-ICSS on AM33xx family of SoCs. The AM33xx
SoCs contain a single PRU-ICSS instance and is represented by a pruss
node and other child nodes. PRU-ICSS is not supported on AM3352 SoC
though in the AM33xx family, so the nodes are added under the
corresponding disabled interconnect target module node in the common
am33xx-l4 dtsi file. The target module node should be enabled in only
those derivative board files that use a SoC containing PRU-ICSS.

The PRUSS subsystem node contains the entire address space. The various
sub-modules of the PRU-ICSS are represented as individual child nodes
(so platform devices themselves) of the PRUSS subsystem node. These
include the two PRU cores and the interrupt controller. All the Data
RAMs are represented within a child node of its own named 'memories'
without any compatible. The Real Time Media Independent Interface
controller (MII_RT), and the CFG sub-module are represented as syscon
nodes. The PRUSS CFG module has a clock mux for IEP clock, this clk
node is added under the CFG child node 'clocks'. The default source
for this mux clock is the PRU_ICSS_IEP_GCLK clock.

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

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

Note:
1. There are few more sub-modules like the Industrial Ethernet Peripheral
   (IEP), MDIO, UART, eCAP that do not have bindings and so will be added
   in the future.
2. The PRUSS INTC on AM335x SoCs also connect the host interrupts 0 to
   TSC_ADC; 6 and 7 as possible DMA events, so use the 'ti,irqs-reserved'
   property in derivative board dts files _if_ any of them should not be
   handled by the host OS.

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoarm64: dts: ti: k3-j721e-main: Add ICSSG MDIO nodes
Suman Anna [Wed, 22 Jan 2020 21:22:49 +0000 (15:22 -0600)]
arm64: dts: ti: k3-j721e-main: Add ICSSG MDIO nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
6 weeks agoarm64: dts: ti: k3-am65-main: Add ICSSG MDIO nodes
Roger Quadros [Wed, 22 Jan 2020 21:37:20 +0000 (15:37 -0600)]
arm64: dts: ti: k3-am65-main: Add ICSSG MDIO nodes

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

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

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