rpmsg/rpmsg.git
3 years agoremoteproc/k3-r5: add a remoteproc driver for R5F subsystem
Suman Anna [Tue, 4 Dec 2018 22:07:43 +0000 (17:07 -0500)]
remoteproc/k3-r5: add a remoteproc driver for R5F subsystem

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

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

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/k3-r5: add TI-SCI processor control helper functions
Suman Anna [Tue, 21 Aug 2018 16:09:50 +0000 (11:09 -0500)]
remoteproc/k3-r5: add TI-SCI processor control helper functions

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
Suman Anna [Wed, 28 Nov 2018 20:13:12 +0000 (15:13 -0500)]
dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/omap: Check for undefined mailbox messages
Suman Anna [Thu, 22 Feb 2018 21:07:43 +0000 (15:07 -0600)]
remoteproc/omap: Check for undefined mailbox messages

Add some checks in the mailbox callback function to limit
any processing in the mailbox callback function to only
certain currently valid messages, and drop all the remaining
messages. A debug message is added to print any such invalid
messages when the appropriate trace control is enabled.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: use a local copy for the name field
Suman Anna [Tue, 30 Oct 2018 18:06:34 +0000 (13:06 -0500)]
remoteproc: use a local copy for the name field

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: add prepare and unprepare ops
Loic Pallardy [Thu, 1 Mar 2018 16:23:55 +0000 (17:23 +0100)]
remoteproc: add prepare and unprepare ops

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

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

Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
[s-anna@ti.com: cherry-pick linux-remoteproc patchwork id '10251897']
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Suman Anna [Mon, 25 Feb 2019 23:04:32 +0000 (17:04 -0600)]
Merge branch 'platform-ti-linux-4.19.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into topic/4.19/am65x

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoarm64: dts: ti: k3-am65-main: Add ICSSG MDIO nodes
Roger Quadros [Thu, 21 Feb 2019 03:15:49 +0000 (21:15 -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>
3 years agoarm64: dts: ti: k3-am65-main: Add mii-g-rt nodes in ICSSG
Roger Quadros [Thu, 21 Feb 2019 03:13:31 +0000 (21:13 -0600)]
arm64: dts: ti: k3-am65-main: Add mii-g-rt nodes in ICSSG

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

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoarm64: dts: ti: k3-am65-main: Add PRU system events for virtio
Suman Anna [Thu, 21 Feb 2019 03:16:45 +0000 (21:16 -0600)]
arm64: dts: ti: k3-am65-main: Add PRU system events for virtio

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoarm64: dts: ti: k3-am65-main: Add ICSSG nodes
Suman Anna [Thu, 21 Feb 2019 03:09:32 +0000 (21:09 -0600)]
arm64: dts: ti: k3-am65-main: Add ICSSG nodes

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

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

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: Configure different internal ICSSG source clocks
Suman Anna [Thu, 21 Feb 2019 02:47:05 +0000 (20:47 -0600)]
soc: ti: pruss: Configure different internal ICSSG source clocks

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: Add support for various PRU cores on K3 AM65x SoCs
Suman Anna [Thu, 21 Feb 2019 02:43:27 +0000 (20:43 -0600)]
remoteproc/pru: Add support for various PRU cores on K3 AM65x SoCs

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: Introduce new vendor interrupt resource for K3 AM65x SoCs
Suman Anna [Sat, 28 Apr 2018 19:37:33 +0000 (14:37 -0500)]
remoteproc/pru: Introduce new vendor interrupt resource for K3 AM65x SoCs

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: remoteproc: pru: Update bindings for K3 AM65x SoCs
Suman Anna [Thu, 21 Feb 2019 02:11:23 +0000 (20:11 -0600)]
dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SoCs

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoirqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs
Suman Anna [Thu, 21 Feb 2019 02:06:33 +0000 (20:06 -0600)]
irqchip/pruss-intc: Add support for ICSSG INTC on K3 AM65x SoCs

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: irqchip: pruss-intc: Update bindings for K3 AM65x SoCs
Suman Anna [Thu, 21 Feb 2019 01:50:26 +0000 (19:50 -0600)]
dt-bindings: irqchip: pruss-intc: Update bindings for K3 AM65x SoCs

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: enable support for ICSSG subsystems on K3 AM65x SoCs
Suman Anna [Thu, 21 Feb 2019 02:40:11 +0000 (20:40 -0600)]
soc: ti: pruss: enable support for ICSSG subsystems on K3 AM65x SoCs

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: soc: ti: pruss: Update bindings for K3 AM65x SoCs
Suman Anna [Tue, 1 May 2018 23:39:52 +0000 (18:39 -0500)]
dt-bindings: soc: ti: pruss: Update bindings for K3 AM65x SoCs

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: use macros and types from omap mailbox
Suman Anna [Fri, 22 Feb 2019 23:37:49 +0000 (17:37 -0600)]
remoteproc/pru: use macros and types from omap mailbox

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'mailbox-linux-4.19.y' of git://git.ti.com/rpmsg/mailbox into topic...
Suman Anna [Sun, 24 Feb 2019 03:15:13 +0000 (21:15 -0600)]
Merge branch 'mailbox-linux-4.19.y' of git://git.ti.com/rpmsg/mailbox into topic/4.19/am65x

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: enable OCP master ports in SYSCFG always
Suman Anna [Thu, 22 Nov 2018 11:39:03 +0000 (13:39 +0200)]
soc: ti: pruss: enable OCP master ports in SYSCFG always

The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level,
and is being programmed for the PRCM Idle/Standby protocol properly
during probe and remove. The register is also programmed to enable
the OCP master ports (disable MStandby) by default during probe now
to allow the PRUs access to on-chip memories and peripherals outside
the PRUSS without having to do it in firmware (primarily for the PRU
Ethernet usecase currently, the firmware is not programming this
register).

NOTE:
1. The AM57xx TRM suggests to enable "No Standby" during the
   Idle + Standby state to an Active/Normal state, but this
   sequence is not documented in either of AM33xx and AM437x
   SoCs. Furthermore, it did not have an impact on the working
   of Ethernet Rx, so is left out.
2. This has an impact on the PM suspend/resume operation usually
   (same bit is used to trigger PRU standby), and even when the
   PRU cores are in halted state. The STANDBY_INIT has to be
   re-programmed to initiate a standby sequence and have the PM
   suspend/resume functional when PRUs are halted. This is already
   handled in commit c1d6b33cb8f7 ("soc: ti: pruss: Fix system
   suspend/MStandby config issues").

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: add support for configuring GPMUX based on client setup
Tero Kristo [Mon, 29 Jan 2018 15:53:49 +0000 (17:53 +0200)]
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>
3 years agosoc: ti: pruss: add helper functions to get/set PRUSS_CFG_GPMUX
Tero Kristo [Tue, 19 Feb 2019 17:41:37 +0000 (11:41 -0600)]
soc: ti: pruss: add helper functions to get/set PRUSS_CFG_GPMUX

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: reuse pruss_regmap functions and inline them]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: add helper functions to set GPI mode, MII_RT_event and XFR
Suman Anna [Thu, 15 Feb 2018 02:01:14 +0000 (20:01 -0600)]
soc: ti: pruss: add helper functions to set GPI mode, MII_RT_event and XFR

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: add pruss_regmap_read()/update() API
Suman Anna [Tue, 19 Feb 2019 17:27:10 +0000 (11:27 -0600)]
soc: ti: pruss: add pruss_regmap_read()/update() API

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: add pruss_{request,release}_mem_region() API
Andrew F. Davis [Mon, 11 Jan 2016 22:18:38 +0000 (16:18 -0600)]
soc: ti: pruss: add pruss_{request,release}_mem_region() API

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

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: rename functions, add error checking, comments]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: add pruss_get()/put() API
Tero Kristo [Tue, 19 Feb 2019 17:35:06 +0000 (11:35 -0600)]
soc: ti: pruss: add pruss_get()/put() API

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

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: various fixups and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: add pru_rproc_get_id() API to retrieve the PRU id
Suman Anna [Mon, 26 Nov 2018 07:52:43 +0000 (09:52 +0200)]
remoteproc/pru: add pru_rproc_get_id() API to retrieve the PRU id

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: add support for parsing pru interrupt mapping from DT
Tero Kristo [Wed, 20 Feb 2019 21:14:16 +0000 (15:14 -0600)]
remoteproc/pru: add support for parsing pru interrupt mapping from DT

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

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[rogerq@ti.com: refactor DT-parse logic into a separate function]
Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: various fixes and cleanups, update patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: configure firmware based on client setup
Tero Kristo [Mon, 26 Nov 2018 07:52:47 +0000 (09:52 +0200)]
remoteproc/pru: configure firmware based on client setup

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: Add pru_rproc_set_ctable() function
Roger Quadros [Tue, 19 Feb 2019 01:05:32 +0000 (19:05 -0600)]
remoteproc/pru: Add pru_rproc_set_ctable() function

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

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

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

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: add the NOTE: on patch description, minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: deny rproc sysfs ops for PRU client driven boots
Suman Anna [Tue, 19 Feb 2019 02:03:11 +0000 (20:03 -0600)]
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>
3 years agoremoteproc/pru: add APIs to get and put the PRU cores
Tero Kristo [Mon, 26 Nov 2018 07:52:42 +0000 (09:52 +0200)]
remoteproc/pru: add APIs to get and put the PRU cores

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

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: improve error checking, various fixes and cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: remoteproc: pru: Document application node bindings
Tero Kristo [Tue, 19 Feb 2019 23:12:16 +0000 (17:12 -0600)]
dt-bindings: remoteproc: pru: Document application node bindings

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

The application nodes themselves should define their own bindings.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: some binding updates]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: keystone-k2g: Add PRU system events for virtio
Suman Anna [Tue, 31 Jan 2017 00:50:18 +0000 (18:50 -0600)]
ARM: dts: keystone-k2g: Add PRU system events for virtio

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA7: Add PRU system events for virtio
Suman Anna [Mon, 29 Jan 2018 21:41:00 +0000 (15:41 -0600)]
ARM: dts: DRA7: Add PRU system events for virtio

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: AM4372: Add PRU system events for virtio
Suman Anna [Thu, 2 Feb 2017 23:39:13 +0000 (17:39 -0600)]
ARM: dts: AM4372: Add PRU system events for virtio

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: AM33xx: Add PRU system events for virtio
Suman Anna [Wed, 1 Feb 2017 19:37:58 +0000 (13:37 -0600)]
ARM: dts: AM33xx: Add PRU system events for virtio

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: Add support for virtio rpmsg stack
Suman Anna [Fri, 22 Feb 2019 00:20:28 +0000 (18:20 -0600)]
remoteproc/pru: Add support for virtio rpmsg stack

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: remoteproc: pru: Update bindings for supporting rpmsg
Suman Anna [Fri, 15 Feb 2019 17:24:25 +0000 (11:24 -0600)]
dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: keystone-k2g: Add PRUSS GPIO controller nodes
Suman Anna [Wed, 20 Feb 2019 16:22:05 +0000 (10:22 -0600)]
ARM: dts: keystone-k2g: Add PRUSS GPIO controller nodes

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: keystone-k2g: Add PRUSS MDIO controller nodes
Suman Anna [Tue, 7 Nov 2017 20:07:55 +0000 (14:07 -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 dts file and are
disabled. These need to be enabled in the respective board files
supporting 66AK2G SoCs and where the ethernet is pinned out and
connected properly.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: keystone-k2g: Add the PRU-ICSS nodes
Suman Anna [Mon, 18 Feb 2019 19:44:39 +0000 (13:44 -0600)]
ARM: dts: keystone-k2g: Add the PRU-ICSS nodes

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

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am57xx-idk-common: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:56:44 +0000 (13:56 -0600)]
ARM: dts: am57xx-idk-common: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: beagle-x15-common: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:55:39 +0000 (13:55 -0600)]
ARM: dts: beagle-x15-common: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants
Suman Anna [Fri, 5 Dec 2014 00:46:56 +0000 (18:46 -0600)]
ARM: DRA7: hwmod_data: Add PRU-ICSS data for AM57xx variants

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA7: Add PRUSS MDIO controller nodes
Andrew F. Davis [Tue, 7 Nov 2017 19:57:19 +0000 (13:57 -0600)]
ARM: dts: DRA7: Add PRUSS MDIO controller nodes

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

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

Signed-off-by: Andrew F. Davis <afd@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA7: Add the PRU-ICSS nodes
Suman Anna [Mon, 18 Feb 2019 19:43:45 +0000 (13:43 -0600)]
ARM: dts: DRA7: Add the PRU-ICSS nodes

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

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am437x-idk: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:44:19 +0000 (13:44 -0600)]
ARM: dts: am437x-idk: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am437x-sk: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:43:20 +0000 (13:43 -0600)]
ARM: dts: am437x-sk: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am437x-gp-evm: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:42:32 +0000 (13:42 -0600)]
ARM: dts: am437x-gp-evm: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: extend pruss pdata-quirks to AM437x SoCs
Suman Anna [Wed, 8 Nov 2017 23:15:18 +0000 (17:15 -0600)]
ARM: OMAP2+: extend pruss pdata-quirks to AM437x SoCs

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
3 years 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>
3 years agoARM: dts: AM4372: Add the PRU-ICSS0 DT node
Suman Anna [Mon, 18 Feb 2019 19:42:52 +0000 (13:42 -0600)]
ARM: dts: AM4372: Add the PRU-ICSS0 DT node

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: AM4372: Add the PRU-ICSS1 DT node
Suman Anna [Mon, 18 Feb 2019 19:42:05 +0000 (13:42 -0600)]
ARM: dts: AM4372: Add the PRU-ICSS1 DT node

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

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

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am335x-icev2: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:40:45 +0000 (13:40 -0600)]
ARM: dts: am335x-icev2: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am335x-evmsk: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:39:00 +0000 (13:39 -0600)]
ARM: dts: am335x-evmsk: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am335x-evm: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:38:00 +0000 (13:38 -0600)]
ARM: dts: am335x-evm: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am335x-bone-common: Enable PRU-ICSS nodes
Suman Anna [Tue, 30 Jan 2018 19:36:42 +0000 (13:36 -0600)]
ARM: dts: am335x-bone-common: Enable PRU-ICSS nodes

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x
Suman Anna [Thu, 14 Feb 2019 21:27:16 +0000 (15:27 -0600)]
ARM: OMAP2+: use pdata quirks for PRUSS reset lines on AM335x

The omap_device API is needed to perform the reset management for
any IP instances with PRCM RSTCTRL registers (hard reset lines).
This API is limited to the mach-omap2 layer, and cannot be exposed
to drivers layer directly. So use platform data ops and pdata quirks
for the PRUSS IP in AM335x SoCs to plumb the required omap_device
API. The PRUSS SoC bus driver can then use these pdata ops to
achieve the required reset functionality.

This is being implemented this way as there is no separate reset
driver at the moment.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
3 years agoARM: dts: AM33xx: Add PRUSS MDIO controller node
Suman Anna [Tue, 7 Nov 2017 19:52:42 +0000 (13:52 -0600)]
ARM: dts: AM33xx: 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 dts 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>
3 years agoARM: dts: AM33xx: Add the PRU-ICSS DT nodes
Suman Anna [Mon, 18 Feb 2019 19:41:19 +0000 (13:41 -0600)]
ARM: dts: AM33xx: Add the PRU-ICSS DT nodes

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 the pruss-soc-bus node and a child PRUSS node. PRU-ICSS is not
supported on AM3352 SoC though in the AM33xx family, so the nodes
are added in disabled state to the common am33xx dtsi file. They
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 and
the various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
Suman Anna [Fri, 15 Feb 2019 18:38:35 +0000 (12:38 -0600)]
soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC

The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1,
each of which has two PRU processor cores. The two PRU-ICSS instances
are identical to each other with few minor SoC integration differences,
and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The Shared Data
RAM size is larger and the number of interrupts coming into MPU INTC
is like the instances on AM437x. There are also few other differences
attributing to integration in Keystone architecture (like no SYSCFG
register or PRCM handshake protocols). Other IP level differences
include different constant table, differences in system event interrupt
input sources etc. They also do not have a programmable module reset
line like those present on AM33xx/AM43xx SoCs. The modules are reset
just like any other IP with the SoC's global cold/warm resets.

The existing PRUSS platform drivers have been enhanced to support
these 66AK2G PRU-ICSS instances through new 66AK2G specific compatibles
for properly probing and booting all the different PRU cores in each
PRU-ICSS processor subsystem. The SoC-level integration differences
are dealt with using match data within the PRUSS INTC and PRUSS SoC
bus drivers. A build dependency with ARCH_KEYSTONE is added to enable
the driver to be built in K2G-only configuration. The initial names
for the firmware images for each PRU core are retrieved from DT nodes,
and can be adjusted through sysfs if required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: Configure SYSCFG properly during probe/remove
Suman Anna [Thu, 22 Nov 2018 11:39:01 +0000 (13:39 +0200)]
soc: ti: pruss: Configure SYSCFG properly during probe/remove

The PRUSS CFG module's SYSCFG register is used for managing the
PRCM clock management settings at the PRU-ICSS subsystem level.

Add two helper functions pruss_{enable/disable}_module() that
programs this SYSCFG register during probe and remove. The
register is currently programmed for the default Smart-Idle
and Smart-Standby always during probe. The MStandby is enabled
during remove to undo the settings in probe to properly configure
the SYSCFG in the case that a firmware has disabled MStandby.
This is needed on SoCs like AM57xx that do not have a reset line
and so cannot reset the register properly.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agosoc: ti: pruss: Fix system suspend/MStandby config issues
Suman Anna [Thu, 22 Nov 2018 11:39:00 +0000 (13:39 +0200)]
soc: ti: pruss: Fix system suspend/MStandby config issues

The PRU-ICSS subsystem has a separate PRUSS_CFG module that contains
various configuration registers. This includes a control bit STANDBY_INIT
in 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 system
suspend/resume functionality on AM33xx/AM437x/AM57xx SoCs requires
all initiators to assert their MStandby signal properly inorder to
successfully enter suspend, and resume on a wakeup event.

Certain firmwares can enable the OCP master ports through the
STANDBY_INIT programming on the firmware side in order to access
peripherals or memories external to the PRUSS. This causes a hang
in the resume sequence on AM33xx/AM437x boards and requires a
board reset to come out of the hang.

This patch adds the preliminary System PM callbacks in the PRUSS SoC
bus driver, and fixes this system resume hang by setting the STANDBY_INIT
in the PM system suspend callback and resetting it back in the PM system
resume callback, if so configured. The clearing of the STANDBY_INIT
during resume requires an acknowledgment from PRCM and is done through
the monitoring of the PRUSS_SYSCFG.SUB_MWAIT bit.

NOTE:
1. This patch only adds the PM callbacks with code to fix the System
   Suspend/Resume hang issue on AM33xx/AM437x SoCs, but does not
   implement the full context save and restore required for the PRUSS
   drivers to work across system suspend/resume when the power domain
   is switched off (L4PER domain is switched OFF on AM335x/AM437x
   during system suspend/resume, so PRUSS modules do lose context).
2. The PRUSS driver functionality on AM57xx SoCs is not affected that
   much because the PER power domain to which the PRUSS IPs belong is
   not switched OFF during suspend/resume.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agosoc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
Suman Anna [Fri, 15 Feb 2019 18:28:35 +0000 (12:28 -0600)]
soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs

The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the number of interrupts coming into the MPU INTC. They do
not have a programmable module reset line unlike those present on
AM33xx/AM43xx SoCs. The modules are reset just like any other IP
with the SoC's global cold/warm resets. Each PRU-ICSS's INTC is also
preceded by a Crossbar that enables multiple external events to be
routed to a specific number of input interrupt events. Any interrupt
event directed towards PRUSS needs this crossbar to be setup properly
on the firmware side.

The existing PRUSS platform drivers have been enhanced to support
these AM57xx PRU-ICSS instances through new AM57xx specific
compatibles for properly probing and booting all the different PRU
cores in each PRU-ICSS processor subsystem. The SoC-level integration
differences are dealt with using match data within the PRUSS SoC bus
driver. A build dependency with SOC_DRA7XX is also added to enable
the driver to be built in AM57xx-only configuration (there is no
separate Kconfig option for AM57xx vs DRA7xx). The initial names
for the firmware images for each PRU core are retrieved from DT
nodes, and can be adjusted through sysfs if required.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: Add support for PRU-ICSS0 on AM437x SoCs
Suman Anna [Fri, 15 Feb 2019 18:20:35 +0000 (12:20 -0600)]
soc: ti: pruss: Add support for PRU-ICSS0 on AM437x SoCs

The AM437x SoCs have a second smaller PRU-ICSS subsystem (PRUSS0)
in addition to the primary PRUSS1 instance. The PRUSS0 is another
instantiation of the IP, but is not identical to PRUSS1. It is
essentially a cut-down version of the IP, with less DRAM per PRU,
no Shared DRAM etc. It also does not have direct access to L3 bus
regions, there is a single interface to L3 for both PRUSS0 and
PRUSS1, and it would have to go through the PRUSS1's interface.
The PRUSS_SYSCFG register is reserved on PRUSS0, so any external
access requires the programming the corresponding PRUSS_SYSCFG
register in PRUSS1. It does have its own dedicated I/O lines
though. Note that this instance does not support any PRU Ethernet
related usecases.

The PRUSS remoteproc drivers have been enhanced to support this
smaller PRUSS0 instance using instance-specific data. The adaptation
uses a newly introduced pruss_match_private_data structure and the
pruss_get_private_data() function to retrieve a PRUSS instance
specific data using a device-name based lookup logic. The reset
and the L3 external access are managed by the common PRUSS SoC bus
driver so that PRUSS1 and PRUSS0 can be independently supported.
The initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agosoc: ti: pruss: Add support for PRU-ICSS1 on AM437x SoCs
Suman Anna [Fri, 15 Feb 2019 18:00:32 +0000 (12:00 -0600)]
soc: ti: pruss: Add support for PRU-ICSS1 on AM437x SoCs

Enhance all the PRUSS platform drivers to support the PRU-ICSS1
sub-system on the AM437x family of SoCs. AM437x has two PRU-ICSS
instances, and support has been added only for the PRU-ICSS1 at
the moment. PRU-ICSS1 on AM437x is very similar to the PRU-ICSS
on AM33xx except for few minor differences - increased Instruction
RAM, increased Shared Data RAM2, and 1 less interrupt (PRUSS host
interrupt 7 which is redirected to the other PRUSS) towards the
MPU INTC.

The adaptation uses newly introduced compatibles in each driver
and relying on match data within the PRUSS INTC and PRUSS SoC bus
drivers to account for the SoC-level integration differences. The
initial names for the firmware images for each PRU core are
retrieved from DT nodes, and can be adjusted through sysfs if
required.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
3 years agoremoteproc/pru: Add pru-specific debugfs support
Suman Anna [Fri, 15 Feb 2019 01:54:48 +0000 (19:54 -0600)]
remoteproc/pru: Add pru-specific debugfs support

The remoteproc core creates certain standard debugfs entries,
that does not give a whole lot of useful information for the
PRUs. The PRU remoteproc driver is enhanced to add additional
debugfs entries for PRU. These will be auto-cleaned up when
the parent rproc debug directory is removed.

The enhanced debugfs support adds two new entries: 'regs' and
'single_step'. The 'regs' dumps out the useful CTRL sub-module
registers as well as each of the 32 GPREGs and CT_REGs registers.
The GPREGs and CT_REGs though are printed only when the PRU is
halted and accessible as per the IP design.

The 'single_step' utilizes the single-step execution of the PRU
cores. Writing a non-zero value performs a single step, and a
zero value restores the PRU to execute in the same mode as the
mode before the first single step. (note: if the PRU is halted
because of a halt instruction, then no change occurs).

Logic for setting the PC and jumping over a halt instruction shall
be added in the future.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/pru: Add a PRU remoteproc driver
Suman Anna [Fri, 15 Feb 2019 02:01:21 +0000 (20:01 -0600)]
remoteproc/pru: Add a PRU remoteproc driver

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.

The PRU remoteproc driver uses the standard remoteproc core ELF
loader. However, the PRUs do not have a unified address space,
(has an Instruction RAM and a primary Data RAM at both 0x0) and
leverage an added .da_to_va ops to use the standard ELF loader.
This remoteproc driver does not have support for error recovery
and system suspend/resume features. Different compatibles are
used to allow providing scalability for instance-specific device
data if needed. The driver uses a default firmware-name retrieved
from device-tree, and the firmwares are expected to be present
in the standard Linux firmware search paths. They can also be
adjusted by userspace if required through the sysfs interface
provided by the remoteproc core.

The PRU remoteproc driver uses a client-driven boot methodology
- it does _not_ support auto-boot so that the PRU load and boot
is dictated by the corresponding client drivers for achieving
various usecases. This allows flexibility for the client drivers
or applications to set a firmware name (if needed) based on their
desired functionality and boot the PRU. The sysfs bind and unbind
attributes have also been suppressed so that the PRU devices cannot
be unbound and thereby shutdown a PRU from underneath a PRU client
driver.

The PRU interrupt configuration is handled within the PRUSS INTC
platform driver, and leverages the system events to interrupt
channels and host interrupts mapping configuration through a
PRU firmware resource table for now. This will be revisited and
enhanced in the future for a better interface. The mappings
are currently programmed during the booting/shutdown of the PRU.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
3 years agodt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS
Suman Anna [Fri, 15 Feb 2019 17:19:15 +0000 (11:19 -0600)]
dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS

The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual
32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program
execution. This patch adds the bindings for these PRU cores.

The binding currently covers the OMAP architecture SoCs - AM33xx,
AM437x and AM57xx; and a Keystone 2 architecture based 66AK2G SoC.
The Davinci based OMAPL138 SoCs and K3 architecture based AM65x SoCs
will be covered in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agoremoteproc: Extend rproc_da_to_va() API with a flags parameter
Suman Anna [Sat, 23 Feb 2019 17:42:06 +0000 (11:42 -0600)]
remoteproc: Extend rproc_da_to_va() API with a flags parameter

The rproc_da_to_va() API is currently used to perform any device
to kernel address translations to meet the different needs of the
remoteproc core/platform drivers (eg: loading). The function also
invokes the da_to_va ops, if present, to allow the remoteproc
platform drivers to provide address translation. However, not all
platform implementations have linear address spaces, and may need
an additional parameter to be able to perform proper translations.

The rproc_da_to_va() API and the rproc .da_to_va ops have therefore
been expanded to take in an additional flags field enabling some
remoteproc implementations (like the TI PRUSS remoteproc driver)
to use these flags. Also, define some semantics for this flags
argument as this can vary from one implementation to another. A
new flags type is encoded into the upper 16 bits along side the
actual value in the lower 16-bits for the flags argument, to
allow different individual implementations to have better
flexibility in interpreting the flags as per their needs.

Also, update the various remoteproc implementations that use the
.da_to_va() ops for the new signature.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: move rproc_da_to_va declaration to remoteproc.h
Suman Anna [Fri, 2 Nov 2018 10:29:05 +0000 (15:59 +0530)]
remoteproc: move rproc_da_to_va declaration to remoteproc.h

The rproc_da_to_va() API is an exported function, so move its
declaration from the remoteproc local remoteproc_internal.h
to the public remoteproc.h file.

This will allow drivers outside of the remoteproc folder to be
able to use this API.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: Add support to handle device specific resource types
Suman Anna [Fri, 15 Feb 2019 19:06:08 +0000 (13:06 -0600)]
remoteproc: Add support to handle device specific resource types

The remoteproc framework handles a fixed set of resource table entries
today. To make it scalable across multiple platforms, it makes sense
for the framework to provide a way for the device specific implementation
to define and handle vendor specific resource types. These resource types
would be very specific to an implementation instance that it does not
make sense for the framework to handle it. There can be two types of
such resources depending on whether they need to be handled prior to
the loading of the firmware segments or after. A post-loading resource
type is typically needed because it references a loaded segment pointer
for conveying the resource information.

For instance, a remoteproc implementation might want timers information
embedded in the resource table so that the driver could parse the binary
and enable accordingly. Another example would be hwspinlocks that it
is using, to properly share system wide resources. A PRU post-loading
vendor resource handler for interrupts requires the PRU event - interrupt
channel information to be loaded into device memory.

This patch adds a function pointer to the list of rproc_ops for the
driver implementation to handle such custom vendor resources, and
reuses the same handler between pre-loading and post-loading resource
types, with the sub-types in the implementation handling the processing
of those resource types.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs
Suman Anna [Fri, 14 Jul 2017 22:39:08 +0000 (17:39 -0500)]
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>
3 years agoremoteproc: Add a rproc_set_firmware() API
Suman Anna [Wed, 20 Feb 2019 23:52:00 +0000 (17:52 -0600)]
remoteproc: Add a rproc_set_firmware() API

A new API, rproc_set_firmware() is added to allow the remoteproc platform
drivers and remoteproc client drivers to be able to configure a custom
firmware name that is different from the default name used during
remoteproc registration. This function is being introduced to provide
a kernel-level equivalent of the current sysfs interface to remoteproc
client drivers, and can only change firmwares when the remoteproc is
offline. This allows some remoteproc drivers to choose different firmwares
at runtime based on the functionality the remote processor is providing.
The TI PRU Ethernet driver will be an example of such usage as it
requires to use different firmwares for different supported protocols.

Also, update the firmware_store() function used by the sysfs interface
to reuse this function to avoid code duplication.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: Add missing kernel-doc comment for auto-boot
Suman Anna [Mon, 10 Sep 2018 23:58:22 +0000 (18:58 -0500)]
remoteproc: Add missing kernel-doc comment for auto-boot

The commit ddf711872c9d ("remoteproc: Introduce auto-boot flag")
introduced the auto-boot flag but missed adding the corresponding
kernel-doc comment. Add the same.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoclk: ti: am43xx: drop idlest polling from pruss clkctrl clock
Tero Kristo [Wed, 30 May 2018 12:34:13 +0000 (15:34 +0300)]
clk: ti: am43xx: drop idlest polling from pruss clkctrl clock

The PRUSS modules on AM43xx SoCs have a hardreset line and are controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoclk: ti: am33xx: drop idlest polling from pruss clkctrl clock
Tero Kristo [Wed, 30 May 2018 12:36:25 +0000 (15:36 +0300)]
clk: ti: am33xx: drop idlest polling from pruss clkctrl clock

The PRUSS module on AM33xx SoCs has a hardreset line and is controlled
by a PRCM reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the PRUSS clocks. These details should be handled
by the driver integration code itself.

Add the CLKF_NO_IDLEST flag to the PRUSS clkctrl clock so that these
module status checks are skipped.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoirqchip/irq-pruss-intc: Add API to trigger a PRU sysevent
Suman Anna [Thu, 14 Feb 2019 22:54:04 +0000 (16:54 -0600)]
irqchip/irq-pruss-intc: Add API to trigger a PRU sysevent

The PRUSS INTC can generate an interrupt to various processor
subsystems on the SoC through a set of 64 possible PRU system
events. These system events can be used by PRU client drivers
or applications for event notifications/signalling between PRUs
and MPU or other processors. A new API, pruss_intc_trigger() is
provided to MPU-side PRU client drivers/applications to be able
to trigger an event/interrupt using IRQ numbers provided by the
PRUSS-INTC irqdomain chip.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoirqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts
Suman Anna [Fri, 15 Feb 2019 23:07:52 +0000 (17:07 -0600)]
irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

The PRUSS INTC platform driver manages this PRUSS interrupt
controller and implements an irqchip driver to provide a Linux
standard way for the PRU client users to enable/disable/ack/
re-trigger a PRUSS system event. The system events to interrupt
channels and host interrupts relies on the mapping configuration
provided through a firmware resource table for now. This will be
revisited and enhanced in the future for a better interface. The
mappings will currently be programmed during the boot/shutdown
of the PRU.

The PRUSS INTC module is reference counted during the interrupt
setup phase through the irqchip's irq_request_resources() and
irq_release_resources() ops. This restricts the module from being
removed as long as there are active interrupt users.

The driver currently supports the AM335x SoC, and support for other
TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agodt-bindings: irqchip: Add PRUSS interrupt controller bindings
Suman Anna [Fri, 15 Feb 2019 16:54:19 +0000 (10:54 -0600)]
dt-bindings: irqchip: Add PRUSS interrupt controller bindings

The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.

Add the bindings document for this interrupt controller. The binding
currently covers the OMAP architecture SoCs - AM33xx, AM437x and AM57xx;
and a Keystone 2 architecture based 66AK2G SoC. The Davinci based
OMAPL138 SoCs and K3 architecture based AM65x SoCs will be covered
in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agosoc: ti: pruss: Parse various syscon nodes and store their regmaps
Suman Anna [Tue, 19 Feb 2019 21:24:40 +0000 (15:24 -0600)]
soc: ti: pruss: Parse various syscon nodes and store their regmaps

The PRUSS device node currently uses three different syscon nodes for
CFG, IEP and MII_RT sub-modules. Parse these syscon nodes and store
their regmap handles to allow adding functions to program any register
within these sub-modules.

The MFD_SYSCON Kconfig option is also enabled whenever the PRUSS remoteproc
driver is enabled. The MFD_SYSCON is a boolean option, and the select
dependency option is chosen following the majority usage style within the
kernel, as well as to align with similar usage in couple of other
remoteproc drivers.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
3 years agosoc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
Suman Anna [Fri, 15 Feb 2019 02:09:59 +0000 (20:09 -0600)]
soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs

The PRUSS platform driver deals with the overall PRUSS and is
used for managing the subsystem level resources like various
memories. It is responsible for the creation and deletion of
the platform devices for the child PRU devices and other child
devices (Interrupt Controller or MDIO node or some syscon nodes)
so that they can be managed by specific platform drivers.

This design provides flexibility in representing the different
modules of PRUSS accordingly, and at the same time allowing the
PRUSS driver to add some instance specific configuration within
an SoC.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
3 years agosoc: ti: pruss: Add pruss_soc_bus platform driver
Suman Anna [Thu, 22 Nov 2018 11:38:59 +0000 (13:38 +0200)]
soc: ti: pruss: Add pruss_soc_bus platform driver

The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single PRUSS, while AM437x has
two PRUSS instances PRUSS1 and PRUSS0, with the PRUSS0 being
a cut-down version of the PRUSS1.

The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.

The PRU-ICSS functionality is achieved through four different
modules, each implementing a platform driver addressing a
specific portion of the PRUSS. Some sub-modules of the PRU-ICSS
IP reuse some of the existing drivers (like davinci mdio driver
or the generic syscon driver). The pruss_soc_bus driver deals
with the SoC integration aspects of the PRUSS IP(s) and manages
the common clock, reset and interconnect configuration and
creates the child PRUSS devices. The second pruss driver is
responsible for the creation and deletion of various platform
devices for the child PRU device and other child devices. A third
driver manages the PRUSS interrupt controller and implements an
irqchip driver to provide a Linux standard way of interrupt
management to PRU clients. The fourth platform driver is a
remoteproc driver and performs the individual PRU RISC cores
management. This design provides flexibility in representing
the different modules of PRUSS accordingly.

The driver currently supports the AM335x SoC, and support for
other TI SoCs will be added in subsequent patches.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agosoc: ti: pruss: Define platform data for PRUSS bus driver
Suman Anna [Thu, 22 Nov 2018 11:38:58 +0000 (13:38 +0200)]
soc: ti: pruss: Define platform data for PRUSS bus driver

The PRUSS can have a PRCM reset line associated with the IP on
some OMAP architecture based SoCs. The reset needs to be programmed
properly before accessing any of the internal registers in the PRUSS.
This functionality is achieved through the omap_device layer, which
is not exposed outside of mach-omap2 layer. Define a platform data
structure for PRUSS so that this API can be invoked through platform
data ops from the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agodt-bindings: soc: ti: Add TI PRUSS bindings
Suman Anna [Thu, 14 Feb 2019 00:57:54 +0000 (18:57 -0600)]
dt-bindings: soc: ti: Add TI PRUSS bindings

This patch adds the bindings for the Programmable Real-Time Unit
and Industrial Communication Subsystem (PRU-ICSS) present on various
TI SoCs. The IP is present on multiple TI SoC architecture families
including the OMAP architecture SoCs such as AM33xx, AM437x and
AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is
also present on the Davinci based OMAPL138 SoCs and K3 architecture
based AM65x SoCs as well (not covered for now).

The IP has a number of sub-modules some of which have their own
devices. This binding covers only the top-level sub-system devices,
and some sub-modules like MDIO, MII_RT and IEP. The remaining
sub-modules bindings shall be defined in the respective driver
subsystem bindings folders. Couple of full examples have also
been added demonstrating the devices on AM335x and the unique
configuration on AM437x SoCs.

The binding status is also marked as unstable as the binding does
not cover all the sub-modules that are present within the PRU-ICSS.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
3 years agodt-bindings: mailbox: omap: Update example for TI K3 AM65x SoCs
Suman Anna [Mon, 4 Feb 2019 20:20:14 +0000 (14:20 -0600)]
dt-bindings: mailbox: omap: Update example for TI K3 AM65x SoCs

Update the current example node for the K3 AM65x SoCs in the OMAP
Mailbox bindings to reflect the updated node names and labels in
the actual source code.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoarm64: dts: ti: k3-am65-main: Rename IPC sub-mailboxes
Suman Anna [Fri, 1 Feb 2019 23:34:19 +0000 (17:34 -0600)]
arm64: dts: ti: k3-am65-main: Rename IPC sub-mailboxes

The name "mcu" is no longer to be used to represent the R5F processor
subsystem, and is being replaced with the name "r5fss". It will continue
to be used as a prefix for peripherals that are present within the MCU
voltage domain on the TI K3 SoCs.

Rename the current sub-mailbox nodes that are used to communicate
between the MPU and the two R5F remote processors in the MCU domain
accordingly. The name ipc3x is also dropped to keep the node names
generic and be agnostic of the RTOS IPC product to be used for future
scalability.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/keystone: add support for MPM userspace loader
Suman Anna [Thu, 17 Jan 2019 22:01:07 +0000 (16:01 -0600)]
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.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>
3 years agoremoteproc/keystone: Switch to SPDX license identifier
Suman Anna [Thu, 17 Jan 2019 18:32:03 +0000 (12:32 -0600)]
remoteproc/keystone: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the keystone
remoteproc driver source file and drop the previous boilerplate
license text.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: add infrastructure support to allow pre-loaded remoteprocs
Suman Anna [Mon, 8 Oct 2018 22:55:32 +0000 (17:55 -0500)]
remoteproc: add infrastructure support to allow pre-loaded remoteprocs

The remoteproc infrastructure is enhanced to allow remoteproc drivers to
be able to connect to already loaded and/or booted remote processors. The
added infrastructure is designed to allow multiple different scenarios:
 - Support userspace driven loading, with the actual boot triggered
   through the kernel.
 - Support remote processors loaded and booted by bootloaders, with
   resource table either directly provided by the remoteproc driver or
   by remoteproc core by requesting the firmware and processing only
   the resource table.

Support for these features are provided through two new fields in the
rproc structure - 'skip_firmware_request' and 'skip_load'. These fields
are 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/or loading any firmware segments using these two
state flags. The default behavior is unchanged.

The interface and implementation details for either of the above scenarios
is left to the individual remoteproc drivers. This design will be used
to achieve the following different usecases on TI SoCs:
 - Allow 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.
 - Allow the K3 R5F remoteproc driver to be invoked in an IPC-only mode
   (No load, boot or error recovery functionality, but only establish
   IPC mechanism). The driver relies on still using the regular state
   machine flow for creating the virtio devices. The rproc .start() and
   .stop() ops are not bypassed, and the actual boot bypass is implemented
   within the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years 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>
3 years 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>
3 years 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>
3 years 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>
3 years 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>
3 years agoARM: dts: keystone-k2g: Reserve SRAM for MPM
Suman Anna [Wed, 7 Sep 2016 18:18:42 +0000 (13:18 -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>
3 years agoARM: dts: keystone-k2e: Reserve SRAM for MPM
Suman Anna [Wed, 7 Sep 2016 18:18:30 +0000 (13:18 -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>