rpmsg/rpmsg.git
5 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-5.4.y
Suman Anna [Fri, 11 Dec 2020 17:06:37 +0000 (11:06 -0600)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that enhances the K3
R5F remoteproc driver to add support for the revised R5FSS IP on
AM64x SoCs. The merge only includes the dt-bindings and the driver
changes, and the current vanilla integration branch cannot be used
to verify the R5Fs on AM64x boards.

The dts nodes will only be added on the RPMsg Domain Integration
branch 'rpmsg-ti-linux-5.4.y-intg' where the required AM64x dtsi
files are available.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
  dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoremoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
Suman Anna [Fri, 11 Dec 2020 00:14:48 +0000 (18:14 -0600)]
remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs

The K3 AM64x SoC family has a revised R5F sub-system and contains a
subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).

The revised IP has the following distinct features:
 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
    mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
    to LockStep-mode on J7200 SoCs in terms of TCM usage without the
    fault-tolerant safety feature provided by the LockStep mode.

    The Core1 TCMs are combined with the Core0 TCMs effectively doubling
    the amount of TCMs available in Single-CPU mode. The LockStep-mode
    on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
    combined TCMs appear contiguous at the respective Core0 TCM addresses.
    The code though is executed only on a single CPU (on Core0), and as
    such, requires the halt signal to be programmed only for Core0, while
    the resets need to be managed for both the cores.

 2. TCMs are auto-initialized during module power-up, and the behavior
    is programmable through a MMR bit. This feature is the same as on
    the recent J7200 SoCs.

Extend the support to these clusters in the K3 R5F remoteproc driver
using AM64x specific compatibles. New TI-SCI flags and a unique cluster
mode are also needed for the cluster mode detection on these SoCs. The
reset assert and deassert sequence of both the cores in Single-CPU mode
is agnostic of the order, so the same LockStep reset and release sequences
are re-used.

The integration of these clusters is very much similar to existing SoCs
otherwise.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs
Suman Anna [Tue, 8 Dec 2020 22:53:55 +0000 (16:53 -0600)]
dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs

The K3 AM64x SoCs have two dual-core Arm R5F clusters/subsystems, with
2 R5F cores each, both in the MAIN voltage domain.

These clusters are a revised IP version compared to those present on
J721E and J7200 SoCs, and supports a new "Single-CPU" mode instead of
LockStep mode. Update the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 AM64x SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 10 Dec 2020 21:53:11 +0000 (15:53 -0600)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that includes couple of
cleanups to the K3 DSP remoteproc bindings, and upstream compabitility
updates to the K3 R5F remoteproc driver w.r.t bindings and properties.
The changes are done in preparation for enhancing the K3 R5F remoteproc
driver for AM64x SoCs using YAML bindings only.

The following is the summary of changes:
 - Clean up some whitespace errors in the K3 DSP YAML binding and mark
   the current Text binding as obsolete
 - Backport YAML bindings for the K3 R5F remoteproc driver, the old text
   binding doc is retained for now, but marked obsolete
 - Enhance the K3 R5F remoteproc driver to be able to parse the new
   upstreamed properties: 'ti,cluster-mode', 'ti,atcm-enable',
   'ti,btcm-enable' and 'ti,loczrama'
 - Switch the AM65x and J7200 R5F nodes from using legacy TI SDK
   property-names to the upstreamed property-names

The dts node changes for J7200 will be added on the RPMsg Domain
Integration branch 'rpmsg-ti-linux-5.4.y-intg' directly.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-j721e: Update R5F nodes to use upstream properties
  arm64: dts: ti: k3-am65-mcu: Update R5F nodes to use upstream properties
  dt-bindings: remoteproc: k3-r5f: mark text binding document as obsolete
  remoteproc: k3_r5: add support for upstreamed DT property names
  dt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs
  dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
  dt-bindings: remoteproc: k3-dsp: mark text binding document as obsolete
  dt-bindings: remoteproc: k3-dsp: clean up whitespace errors

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoarm64: dts: ti: k3-j721e: Update R5F nodes to use upstream properties
Suman Anna [Wed, 9 Dec 2020 16:43:24 +0000 (10:43 -0600)]
arm64: dts: ti: k3-j721e: Update R5F nodes to use upstream properties

Update all the MCU and MAIN R5F nodes on J721E SoCs to use the
upstream-friendly property-names compliant with the YAML-format
binding document,
  Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml

The following properties were substituted:
  lockstep-mode => ti,cluster-mode
  atcm-enable   => ti,atcm-enable
  btcm-enable   => ti,btcm-enable
  loczrama      => ti,loczrama

The driver continues to support legacy property names, but these will
not be supported in a future LTS kernel. Any dynamic fdt fixups or
overlays should migrate to use the newer property names.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoarm64: dts: ti: k3-am65-mcu: Update R5F nodes to use upstream properties
Suman Anna [Wed, 9 Dec 2020 16:35:03 +0000 (10:35 -0600)]
arm64: dts: ti: k3-am65-mcu: Update R5F nodes to use upstream properties

Update the MCU R5F nodes on AM65x SoCs to use the upstream-friendly
property-names compliant with the YAML-format binding document,
  Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml

The following properties were substituted:
  lockstep-mode => ti,cluster-mode
  atcm-enable   => ti,atcm-enable
  btcm-enable   => ti,btcm-enable
  loczrama      => ti,loczrama

The driver continues to support legacy property names, but these will
not be supported in a future LTS kernel. Any dynamic fdt fixups or
overlays should migrate to use the newer property names.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: remoteproc: k3-r5f: mark text binding document as obsolete
Suman Anna [Tue, 8 Dec 2020 21:36:45 +0000 (15:36 -0600)]
dt-bindings: remoteproc: k3-r5f: mark text binding document as obsolete

Add a binding status note to the TI K3 R5F text-format binding document
marking it obsolete. The YAML-format binding "ti,k3-r5f-rproc.yaml"
replaces the existing "ti,k3-r5f-rproc.txt" binding.

The text binding document file is intentionally not removed to provide
continuity for existing customers.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoremoteproc: k3_r5: add support for upstreamed DT property names
Suman Anna [Wed, 9 Dec 2020 16:28:46 +0000 (10:28 -0600)]
remoteproc: k3_r5: add support for upstreamed DT property names

The R5F cluster mode configuration parameter - "lockstep-mode" was
upstreamed using the DT property name "ti,cluster-mode". The individual
R5F core config parameters - "atcm-enable", "btcm-enable" and "loczrama"
were upstreamed using the "ti,atcm-enable", "ti,btcm-enable" and
"ti,loczrama" property names respectively.

Add support to the K3 R5F remoteproc driver to parse these new DT
properties, while maintaining backward compatibility for the original
non-upstream properties. The legacy properties take precedence over
the newer properties for now until the existing users are migrated
over. This precedence order is temporary and will be flipped in the
future.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoMerge branch 'mailbox-linux-5.4.y' of git://git.ti.com/rpmsg/mailbox into rpmsg-ti...
Suman Anna [Wed, 9 Dec 2020 16:41:16 +0000 (10:41 -0600)]
Merge branch 'mailbox-linux-5.4.y' of git://git.ti.com/rpmsg/mailbox into rpmsg-ti-linux-5.4.y

Pull in the updated mailbox feature branch that enhances the OMAP Mailbox
driver to add support for the slightly revised Mailbox IP on AM64x SoCs.
The merge only includes the dt-bindings and the driver changes, and the
current vanilla integration branch cannot be used to verify the Mailbox
IP on AM64x boards.

The dts nodes will only be added on the RPMsg Domain Integration branch
'rpmsg-ti-linux-5.4.y-intg' where the required AM64x dtsi files are
available.

* 'mailbox-linux-5.4.y' of git://git.ti.com/rpmsg/mailbox:
  mailbox: omap: Add support for K3 AM64x SoCs
  dt-bindings: mailbox: omap: Update binding for AM64x SoCs

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoMerge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg...
Suman Anna [Wed, 9 Dec 2020 15:59:47 +0000 (09:59 -0600)]
Merge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg-ti-linux-5.4.y

Pull in the hwspinlock tree that updates the YAML dt-binding document
for AM64x SoCs.

The dts nodes will only be added on the RPMsg Domain Integration branch
'rpmsg-ti-linux-5.4.y-intg' where the required AM64x dtsi files are
available.

* 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock:
  dt-bindings: hwlock: Update OMAP HwSpinlock binding for AM64x SoCs

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs
Suman Anna [Thu, 19 Nov 2020 01:05:29 +0000 (19:05 -0600)]
dt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs

The TI K3 J7200 SoCs have two dual-core Arm R5F clusters/subsystems,
with 2 R5F cores each, one in each of the MCU and MAIN voltage domains.

These clusters are a revised IP version compared to those present on
J721E SoCs. Update the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 J7200 SoCs.

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20201119010531.21083-2-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '41e6f43f3b24' intended for v5.11]

5 months agodt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
Suman Anna [Fri, 2 Oct 2020 23:42:31 +0000 (18:42 -0500)]
dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

The Texas Instruments K3 family of SoCs have one or more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). The clusters
can be split between multiple voltage domains as well. 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 R5F processors can also optionally use any internal on-chip SRAM
memories either for executing code or using it as fast-access data.

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>
Link: https://lore.kernel.org/r/20201002234234.20704-2-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '5ee79c2ed5bd' from v5.10]

5 months agodt-bindings: remoteproc: k3-dsp: mark text binding document as obsolete
Suman Anna [Tue, 8 Dec 2020 21:32:15 +0000 (15:32 -0600)]
dt-bindings: remoteproc: k3-dsp: mark text binding document as obsolete

Add a binding status note to the TI K3 DSP text-format binding document
marking it obsolete. The YAML-format binding "ti,k3-dsp-rproc.yaml"
replaces the previous "ti,k3-dsp-rproc.txt" binding.

The text binding document file is intentionally not removed to provide
continuity for existing customers.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: remoteproc: k3-dsp: clean up whitespace errors
Suman Anna [Tue, 8 Dec 2020 21:25:07 +0000 (15:25 -0600)]
dt-bindings: remoteproc: k3-dsp: clean up whitespace errors

The YAML binding format uses two spaces for list indentation from the
preceding keyword. Clean-up the incorrect indentation on the 'required'
property list.

These changes were custom backported from upstream commit f516fb704d02
("dt-bindings: Whitespace clean-ups in schema files").

Fixes: a6fbc81f20d0 ("dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs")
Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 9 Dec 2020 15:38:25 +0000 (09:38 -0600)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that backports couple of
minor fixes from upstream in the K3 R5F and DSP remoteproc drivers for
issues around incorrect failure path checks and build warnings.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()
  remoteproc: k3-r5: Fix error check on devm_remap_wc()
  remoteproc: ti_k3: fix -Wcast-function-type warning

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agomailbox: omap: Add support for K3 AM64x SoCs
Suman Anna [Tue, 8 Dec 2020 16:13:15 +0000 (10:13 -0600)]
mailbox: omap: Add support for K3 AM64x SoCs

The AM64x SoC contains a Mailbox IP instance with multiple clusters
in the MAIN domain, and is a variant of the IP on current AM65x and
J721E SoCs. The AM64x SoC has only 8 clusters with no interrupts
routed to the A53 core on the first 2 clusters. The interrupt outputs
from the IP do not go through any Interrupt Routers and are hard-wired
to each processor, with only couple of interrupts from each cluster
reaching the A53 core. The IP is also not built with the K3 safety
feature in hardware.

Add the support for this IP through a new compatible.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: mailbox: omap: Update binding for AM64x SoCs
Suman Anna [Tue, 8 Dec 2020 16:11:43 +0000 (10:11 -0600)]
dt-bindings: mailbox: omap: Update binding for AM64x SoCs

Update the existing OMAP Mailbox binding to include the info for
AM64x SoCs. There are some minor IP integration differences between
the AM64x SoCs and the previous AM65x and J721E SoC families.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agodt-bindings: hwlock: Update OMAP HwSpinlock binding for AM64x SoCs
Suman Anna [Tue, 8 Dec 2020 15:28:06 +0000 (09:28 -0600)]
dt-bindings: hwlock: Update OMAP HwSpinlock binding for AM64x SoCs

Update the existing OMAP HwSpinlock binding text to also include
the info for AM64x SoCs. The same compatible from AM65x SoCs is
reused for AM64x SoCs, and a new example is added showcasing the
difference in the IP's presence on the interconnect.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoremoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()
YueHaibing [Sat, 5 Sep 2020 12:25:03 +0000 (20:25 +0800)]
remoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()

In case of error, the function devm_ioremap_wc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.

Fixes: d4a6d5885316 ("remoteproc/k3-dsp: add a remoteproc driver of K3 C66x DSPs")
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200905122503.17352-1-yuehaibing@huawei.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '9b3b3c9531e8' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoremoteproc: k3-r5: Fix error check on devm_remap_wc()
Suman Anna [Mon, 7 Dec 2020 23:20:39 +0000 (17:20 -0600)]
remoteproc: k3-r5: Fix error check on devm_remap_wc()

The devm_ioremap_wc() function return a NULL pointer on failures, but the
logic in the k3_r5_core_of_get_internal_memories() is incorrectly using
an IS_ERR check. Fix this erroneous return value check.

Fixes: 78414dbc126f ("remoteproc/k3-r5: Add a remoteproc driver for R5F subsystem")
Signed-off-by: Suman Anna <s-anna@ti.com>
5 months agoremoteproc: ti_k3: fix -Wcast-function-type warning
Arnd Bergmann [Mon, 26 Oct 2020 16:05:23 +0000 (17:05 +0100)]
remoteproc: ti_k3: fix -Wcast-function-type warning

The function cast causes a warning with "make W=1"

drivers/remoteproc/ti_k3_r5_remoteproc.c: In function 'k3_r5_probe':
drivers/remoteproc/ti_k3_r5_remoteproc.c:1368:12: warning: cast between incompatible function types from 'int (*)(struct platform_device *)' to 'void (*)(void *)' [-Wcast-function-type]

Rewrite the code to avoid the cast, and fix the incorrect return
type of the callback.

Fixes: f578559e0d0c ("remoteproc/k3-r5: Use devres functions to simplify cleanup")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201026160533.3705998-1-arnd@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '2316822989a3' from upstream]
Signed-off-by: Suman Anna <s-anna@ti.com>
7 months agoMerge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Tue, 13 Oct 2020 18:03:31 +0000 (13:03 -0500)]
Merge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.4.y

Pull in the updated rpmsg base feature branch that has couple of minor
enhancements to the rpmsg-char driver for supporting a new ti-rpmsg-char
library in userspace. The changes allow the driver to be auto-probed for
rpmsg devices with name "rpmsg_chrdev" and updates the sysfs 'src' file
for local end-points created with RPMSG_ADDR_ANY from userspace.

* 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: char: Update local endpt address for virtio-rpmsg backend
  rpmsg: char: Add device id_table for auto-probe

Signed-off-by: Suman Anna <s-anna@ti.com>
7 months agorpmsg: char: Update local endpt address for virtio-rpmsg backend rpmsg-linux-5.4.y
Suman Anna [Tue, 15 Sep 2020 00:13:52 +0000 (19:13 -0500)]
rpmsg: char: Update local endpt address for virtio-rpmsg backend

The rpmsg char driver creates a local end-point when the actual endpt
device is opened. The virtio-rpmsg backend can dynamically allocate the
local end-point address if the endpt creation is done using the address
RPMSG_ADDR_ANY. This is not reflected in the sysfs src file, so update
the stored address with the allocated address in such a case. This
allows the userspace to be able to retrieve the local end-point address
through sysfs.

Signed-off-by: Suman Anna <s-anna@ti.com>
7 months agorpmsg: char: Add device id_table for auto-probe
Suman Anna [Thu, 10 Sep 2020 18:39:41 +0000 (13:39 -0500)]
rpmsg: char: Add device id_table for auto-probe

The rpmsg char driver is not auto-probed for any rpmsg device
without relying on the device's driver_override feature. Add a
device id_table to the rpmsg-char driver to facilitate this
auto-probe. Any rpmsg device with the name "rpmsg_chrdev" will
be auto-probed to begin with.

The driver_override will continue to work just fine as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
7 months agoMerge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg...
Suman Anna [Mon, 12 Oct 2020 14:59:42 +0000 (09:59 -0500)]
Merge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg-ti-linux-5.4.y

Pull in the hwspinlock tree that backports a dt-binding YAML fix
for warnings generated with k3.yaml from upstream.

* 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock:
  dt-bindings: hwlock: omap: Fix warnings with k3.yaml

Signed-off-by: Suman Anna <s-anna@ti.com>
7 months agodt-bindings: hwlock: omap: Fix warnings with k3.yaml
Suman Anna [Mon, 28 Sep 2020 22:51:55 +0000 (17:51 -0500)]
dt-bindings: hwlock: omap: Fix warnings with k3.yaml

[ Upstream commit 891adc1303fe482cd683d8a3054040577484051a ]

Update the AM65x HwSpinlock example to fix couple of warnings
that started showing up after the conversion of K3 bindings to
YAML format in commit 66e06509aa37 ("dt-bindings: arm: ti:
Convert K3 board/soc bindings to DT schema").

 compatible: ['ti,am654'] is not valid under any of the given schemas (Possible causes of the failure):
 compatible: ['ti,am654'] is too short
 compatible:0: 'ti,am654' is not one of ['ti,am654-evm']

Also, fix one of the node names while at this.

Reviewed-by: Rob Herring <robh@kernel.org>
[s-anna@ti.com: cherry-pick commit '891adc1303fe' staged for v5.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200928225155.12432-1-s-anna@ti.com
Signed-off-by: Rob Herring <robh@kernel.org>
8 months agoMerge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg...
Suman Anna [Fri, 11 Sep 2020 14:20:21 +0000 (09:20 -0500)]
Merge branch 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock into rpmsg-ti-linux-5.4.y

Pull in the hwspinlock tree that backports the dt-binding conversion
to YAML from upstream.

* 'hwspinlock-linux-5.4.y' of git://git.ti.com/rpmsg/hwspinlock:
  dt-bindings: hwlock: omap: Convert binding to YAML

Signed-off-by: Suman Anna <s-anna@ti.com>
8 months agodt-bindings: hwlock: omap: Convert binding to YAML
Suman Anna [Fri, 28 Aug 2020 04:14:47 +0000 (23:14 -0500)]
dt-bindings: hwlock: omap: Convert binding to YAML

[ Upstream commit d8db9dc348712bbe972e1edd952b67279e774ecc ]

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

The new YAML binding conversion is a slightly updated version compared
to the original. The legacy "ti,hwmods" property is now obsolete and
is dropped altogether, and the K3 example is updated to showcase the
actual dts node usage.

[s-anna@ti.com: cherry-pick commit 'd8db9dc34871' staged for v5.10]
Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200828041447.5900-1-s-anna@ti.com
Signed-off-by: Rob Herring <robh@kernel.org>
9 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 6 Aug 2020 22:20:09 +0000 (17:20 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that enhances the K3
R5F remoteproc driver to add support for the revised R5FSS IP on
J7200 SoCs. The merge only includes the dt-bindings and the driver
changes, and the current vanilla integration branch cannot be used
to verify the R5Fs on J7200 boards.

The dts nodes will only be added on the RPMsg Domain Integration
branch 'rpmsg-ti-linux-5.4.y-intg' where the required J7200 dtsi
files are available.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs
  remoteproc: k3-r5: Extend support to R5F clusters on J7200 SoCs
  dt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs
Suman Anna [Wed, 5 Aug 2020 22:34:58 +0000 (17:34 -0500)]
remoteproc: k3-r5: Adjust TCM sizes in Split-mode on J7200 SoCs

The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t
TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM
and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised
IP however doubles the total available TCM in LockStep mode by making the
Core1 TCM visible immediately after the corresponding Core0 TCM.

The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM
size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the
above. This increased TCM memory is only usable in LockStep-mode, and
has to be adjusted to the normal 32 KB size in Split mode. Enhance the
TI K3 R5F remoteproc for this logic through a new function. The adjustment
is a no-op on prior SoCs and relies on the correct DTS node sizes in
LockStep-mode on applicable SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc: k3-r5: Extend support to R5F clusters on J7200 SoCs
Suman Anna [Wed, 5 Aug 2020 22:20:46 +0000 (17:20 -0500)]
remoteproc: k3-r5: Extend support to R5F clusters on J7200 SoCs

The K3 J7200 SoC family has a revised R5F sub-system and contains a
subset of the R5F clusters present on J721E SoCs. The K3 J7200 SoCs
only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
each. One cluster is present within the MCU voltage domain (MCU_R5FSS0),
while the other is present in the MAIN voltage domain (MAIN_R5FSS0).

The revised IP has the following two new features:
 1. TCMs are auto-initialized during module power-up, and the behavior
    is programmable through a MMR bit.
 2. The LockStep-mode allows the Core1 TCMs to be combined with the
    Core0 TCMs effectively doubling the amount of TCMs available.
    The LockStep-mode on previous SoCs could only use the Core0 TCMs.
    This combined TCMs appear contiguous at the respective Core0 TCM
    addresses.

Extend the support to these clusters in the K3 R5F remoteproc driver
using J7200 specific compatibles. Logic for the second feature is
added in the next patch. The integration of these clusters is very
much similar to J721E SoCs otherwise.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 5 Aug 2020 21:02:51 +0000 (16:02 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that includes couple of
bug fixes in the K3 R5F remoteproc driver and a number of cleanups to
both the K3 R5F and DSP remoteproc drivers. These changes were made as
part of the code sync with the upstream accepted and reviewed driver
code.

The following is the summary of changes:
 - Add a new rproc_of_parse_firmware() helper function to remoteproc
   core, and adapt the drivers to use this new core function
 - Add YAML bindings for K3 DSP remoteproc driver, the old text binding
   doc is retained for now
 - Streamline the K3 DSP remoteproc driver to use IP-specific device
   data
 - Remove stale code and comments, add new comments to improve the
   readability for some complex logic
 - Streamline the cleanup code path in K3 R5F remoteproc by extensive
   use of devres functions
 - Fix couple of initialization logic bugs in K3 R5F remoteproc driver

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: Cleanup various minor miscellaneous items
  remoteproc/k3-r5: Use cluster_mode enums in expressions
  remoteproc/k3-r5: Use devres functions to simplify cleanup
  remoteproc/k3-r5: Use rproc_of_parse_firmware()
  remoteproc/k3-r5: Fix initialization logic in k3_r5_rproc_configure()
  remoteproc/k3-r5: Fix TCM initialization upon reset deassertion failures
  remoteproc/k3-dsp: Cleanup various minor miscellaneous items
  remoteproc/k3-dsp: Use rproc_of_parse_firmware()
  remoteproc/k3-dsp: Use device-specific match data
  remoteproc/k3-dsp: Remove unneeded pm_runtime usage
  remoteproc/k3: Move ti_sci_protocol.h header into ti_sci_proc.h
  dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
  dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
  dt-bindings: arm: keystone: Add common TI SCI bindings
  remoteproc: Introduce rproc_of_parse_firmware() helper

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agodt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs
Suman Anna [Tue, 7 Jul 2020 19:46:22 +0000 (14:46 -0500)]
dt-bindings: remoteproc: k3-r5f: Update bindings for J7200 SoCs

The K3 J7200 SoCs have two dual-core Arm R5F clusters/subsystems, with
2 R5F cores each, one in each of the MCU and MAIN voltage domains.

These clusters are a revised IP version compared to those present on
J721E SoCs. Update the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 J7200 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Cleanup various minor miscellaneous items
Suman Anna [Tue, 4 Aug 2020 22:02:05 +0000 (17:02 -0500)]
remoteproc/k3-r5: Cleanup various minor miscellaneous items

Cleanup the K3 R5F remoteproc driver to include various minor
miscellaneous items incorporating some of the comments from the
latest upstream reviewed version. These include:
 - Reorder the header files in alphabetical order
 - Fix a kerneldoc warning in struct k3_r5_core
 - Remove a stale no-op condition check in the cleanup path in
   k3_r5_reserved_mem_init().
 - Add some extra comments for additional clarifications
 - Use dev_of_node() instead of directly referencing dev->of_node
 - Revise couple of debug trace statement formats
 - Drop the debug trace around devm_of_platform_populate()

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Use cluster_mode enums in expressions
Suman Anna [Tue, 4 Aug 2020 20:56:45 +0000 (15:56 -0500)]
remoteproc/k3-r5: Use cluster_mode enums in expressions

The K3 R5F remoteproc driver relies on using the actual values 0 and 1
for the cluster modes CLUSTER_MODE_SPLIT and CLUSTER_MODE_LOCKSTEP
respectively in expressions. Replace this inherent logic in various
expressions to use the actual enums to improve the code readability.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Use devres functions to simplify cleanup
Suman Anna [Tue, 4 Aug 2020 20:05:00 +0000 (15:05 -0500)]
remoteproc/k3-r5: Use devres functions to simplify cleanup

The K3 R5F remoteproc driver currently uses a mixture of devres and
regular functions, and unwinds all the previously acquired resources
manually upon any failures in cleanup paths, some even using the
devres cleanup functions themselves. Simplify these failure path
code cleanups by updating the driver to use more devres functions.

A lot of the code has been cleaned up courtesy of using
devm_add_action_or_reset() in the driver probe function for the
cluster-level cleanup, and devres_open_group() & devres_release_group()
functions for the core-level cleanups, and using any available
equivalent devres functions for regular functions.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Use rproc_of_parse_firmware()
Suman Anna [Tue, 4 Aug 2020 19:52:32 +0000 (14:52 -0500)]
remoteproc/k3-r5: Use rproc_of_parse_firmware()

The K3 R5F remoteproc driver uses a local function
k3_r5_rproc_get_firmware() to parse the 'firmware-name' property
from DT. Drop this local function and switch to using the new
common helper function in remoteproc core, rproc_of_parse_firmware().
This function is added in commit dc67dfcc77bd ("remoteproc: Introduce
rproc_of_parse_firmware() helper").

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Fix initialization logic in k3_r5_rproc_configure()
Suman Anna [Tue, 4 Aug 2020 21:03:45 +0000 (16:03 -0500)]
remoteproc/k3-r5: Fix initialization logic in k3_r5_rproc_configure()

The function k3_r5_rproc_configure() is used to initialize various R5F
cluster and core level configurations to some sane default values during
the probe function. One of the steps it does is to program the individual
cores symmetrically in LockStep-mode and does this by initially configuring
the cluster to Split-mode and then switching back the mode once all the
core configurations are done. This logic used a wrong variable for
halting both the cores. Fix this.

This clever logic is confusing for developers and reviewers alike, so
improve the code readability by adding some detailed function description.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-r5: Fix TCM initialization upon reset deassertion failures
Suman Anna [Tue, 7 Jul 2020 21:07:15 +0000 (16:07 -0500)]
remoteproc/k3-r5: Fix TCM initialization upon reset deassertion failures

The R5F TCMs are zeroed out for proper ECC functionality in the .prepare()
callback, and is performed after the required resets are deasserted. This
logic however is incorrectly ignoring the status of the TI-SCI proc
control APIs for releasing the resets, and would result in a bus error.
Fix this properly for the reset deassertion failure path.

Fixes: 002de8948d39 ("remoteproc/k3-r5: Initialize TCM memories for ECC")
Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-dsp: Cleanup various minor miscellaneous items
Suman Anna [Tue, 4 Aug 2020 17:10:04 +0000 (12:10 -0500)]
remoteproc/k3-dsp: Cleanup various minor miscellaneous items

Cleanup the K3 DSP remoteproc driver to include various minor
miscellaneous items incorporating some of the comments from the
upstream accepted version. These include:
 - Reorder the header files in alphabetical order.
 - Align couple of function arguments in a new line with the
   corresponding first function argument character in previous line.
 - Remove the stale comment about zeroing out the DSP internal memories
   to start in a pristine state in k3_dsp_rproc_of_get_memories(). This
   is not possible anyway until the .prepare() callback is invoked.
 - Remove a stale no-op condition check in the cleanup path in
   k3_dsp_reserved_mem_init().

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-dsp: Use rproc_of_parse_firmware()
Suman Anna [Tue, 4 Aug 2020 16:52:04 +0000 (11:52 -0500)]
remoteproc/k3-dsp: Use rproc_of_parse_firmware()

The K3 DSP remoteproc driver uses a local function
k3_dsp_rproc_get_firmware() to parse the 'firmware-name' property
from DT. Drop this local function and switch to using the new common
helper function in remoteproc core, rproc_of_parse_firmware(). This
function is added in commit dc67dfcc77bd ("remoteproc: Introduce
rproc_of_parse_firmware() helper").

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-dsp: Use device-specific match data
Suman Anna [Mon, 3 Aug 2020 23:43:16 +0000 (18:43 -0500)]
remoteproc/k3-dsp: Use device-specific match data

The K3 DSP remoteproc driver is used to boot two different classes
of DSPs - a 32-bit C66x DSP and a 64-bit C71x DSP. There are couple
of differences in the features managed by the driver between the
two DSP classes - number of internal RAMs and their addresses, the
local reset integration, and the boot vector address alignment. These
are currently handled in code.

Introduce and use device-specific data which is retrieved using the
compatible match data logic. Following are the main summary of changes:
 - The k3_dsp_rproc_of_get_memories() is simplified to remove the
   hard-coded string names and compatible-check logic to skip over
   irrelevant memories; and the DSP address view for each of the
   internal memories.
 - Add the boot vector alignment to the device data and use it to
   perform a sanity-check of the boot address in k3_dsp_rproc_start().
   The added logic introduces the correct alignment check for C71x
   cores.
 - The uses_lreset is also moved from the remoteproc strucutre to the
   device-specific data, which is cached in the k3_dsp_rproc structure.
 - The structure k3_dsp_rproc_mem is renamed to k3_dsp_mem.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3-dsp: Remove unneeded pm_runtime usage
Suman Anna [Mon, 3 Aug 2020 21:56:53 +0000 (16:56 -0500)]
remoteproc/k3-dsp: Remove unneeded pm_runtime usage

The TI K3 DSP remoteproc driver uses couple of pm_runtime API in probe
and remove to turn on and off the necessary clocks associated with the
DSP internal memories. However, these are no-ops for this driver, as
the DTS nodes do not use any power-domains, and so there is no real
back-end behind these calls. These clocks are instead turned on and
off during the .prepare() and .unprepare() callbacks. So, eliminate
the dead pm_runtime API usage from the driver.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agoremoteproc/k3: Move ti_sci_protocol.h header into ti_sci_proc.h
Suman Anna [Mon, 3 Aug 2020 21:43:41 +0000 (16:43 -0500)]
remoteproc/k3: Move ti_sci_protocol.h header into ti_sci_proc.h

The common ti_sci_proc.h header file has references to couple of
structures defined in ti_sci_protocol.h header file. So, move the
ti_sci_protocol.h header file from the individual driver source
files into the common ti_sci_proc.h header file.

The links to ti.com in the license templates in each of the modified
files is also updated to use the robust https protocol than http.

Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agodt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
Suman Anna [Fri, 12 Jun 2020 22:53:56 +0000 (17:53 -0500)]
dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs

[ Upstream commit c6caf22eaa2347e75ef639ccfafd277ce466e1ca ]

Some Texas Instruments K3 family of SoCs have one of more newer
generation TMS320C71x CorePac processor subsystem in addition to
the existing TMS320C66x CorePac processor subsystems. Update the
device tree bindings document for the C71x DSP devices.

The example is also updated to show the single C71 DSP present
on J721E SoCs.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200612225357.8251-2-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'c6caf22eaa23' from v5.9]

9 months agodt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs
Suman Anna [Tue, 21 Jul 2020 22:36:15 +0000 (17:36 -0500)]
dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs

[ Upstream commit 2a2180206ab62b42c6a7fd3d77c47c3675cbc893 ]

Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200721223617.20312-5-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '2a2180206ab6' from v5.9]

9 months agodt-bindings: arm: keystone: Add common TI SCI bindings
Suman Anna [Tue, 21 Jul 2020 22:36:12 +0000 (17:36 -0500)]
dt-bindings: arm: keystone: Add common TI SCI bindings

[ Upstream commit 44aa656f22d287b33f33bdb28dfb900846e1fc60 ]

Add a bindings document that defines the common TI SCI properties
used by various K3 device management nodes such as clock controllers,
interrupt controllers, reset controllers or remoteproc devices.

The required properties for each device management node shall be
specified in the respective binding document.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20200721223617.20312-2-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit '44aa656f22d2' from v5.9]

9 months agoremoteproc: Introduce rproc_of_parse_firmware() helper
Suman Anna [Tue, 21 Jul 2020 22:36:13 +0000 (17:36 -0500)]
remoteproc: Introduce rproc_of_parse_firmware() helper

[ Upstream commit a8aa5ee100df45f4988975822f5af7c2b67ee9e6 ]

Add a new helper function rproc_of_parse_firmware() to the remoteproc
core that can be used by various remoteproc drivers to look up the
the "firmware-name" property from a rproc device node. This property
is already being used by multiple drivers, so this helper can avoid
repeating equivalent code in remoteproc drivers.

Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200721223617.20312-3-s-anna@ti.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[s-anna@ti.com: cherry-pick commit 'a8aa5ee100df' from v5.9]

9 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Mon, 3 Aug 2020 19:57:41 +0000 (14:57 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that adds a new YAML bindings
document for the PRUSS Enhanced Capture (eCAP) module and the corresponding
eCAP dts nodes for AM335x, AM437x, AM57xx and 66AK2G SoCs. The eCAP module
is also present on K3 SoCs but support for them is currently not added.
The PRUSS eCAP module will be used for adding interrupt-pacing support
within the PRU Ethernet drivers.

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

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: keystone-k2g: Add PRUSS eCAP nodes
  ARM: dts: am57xx: Add PRUSS eCAP nodes
  ARM: dts: am437x: Add PRUSS eCAP node
  ARM: dts: am335x: Add PRUSS eCAP node
  dt-bindings: soc: ti: pruss: Add eCAP documentation
  dt-bindings: net: pruss_ecap: Add dt binding documentation

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

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

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

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

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

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

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

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

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

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

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

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

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agodt-bindings: soc: ti: pruss: Add eCAP documentation
Murali Karicheri [Thu, 30 Jul 2020 19:00:07 +0000 (14:00 -0500)]
dt-bindings: soc: ti: pruss: Add eCAP documentation

Update PRUSS bindings documentation to include the eCAP information.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
9 months agodt-bindings: net: pruss_ecap: Add dt binding documentation
Murali Karicheri [Thu, 30 Jul 2020 02:23:32 +0000 (02:23 +0000)]
dt-bindings: net: pruss_ecap: Add dt binding documentation

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

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 23 Jun 2020 15:19:39 +0000 (10:19 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that brings in a number
of improvements/cleanups to the PRUSS platform drivers. These include:
 - Extend the support for IEP clock muxes to all SoCs (only K3 SoCs
   supported previously).
 - Add YAML bindings for IEP sub-module and corresponding dts nodes
   on all SoCs.
 - Add three new YAML bindings 'ti,pruss-intc.yaml', 'ti,pru-rproc.yaml'
   and 'ti,pru-consumer.yaml' for PRUSS INTC, PRU remoteproc and PRU
   consumers respectively. The corresponding text bindings are dropped.
 - Drop the added pruss_intc_trigger() API, and convert the PRU
   remoteproc driver to direct use an equivalent IRQ subsystem API.

The IEP changes would also require corresponding adjustments to the PRU
Ethernet drivers (out of scope on this tree, changes handled through
the connectivity domain tree).

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc: (25 commits)
  Revert "dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS"
  Revert "dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg"
  Revert "dt-bindings: remoteproc: pru: Document application node bindings"
  Revert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x & J721E SoCs"
  Revert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs"
  Revert "dt-bindings: irqchip: Add PRUSS interrupt controller bindings"
  dt-bindings: remoteproc: Add PRU consumer bindings
  dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg
  dt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSS
  dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings
  Revert "TEMP: irqchip/irq-pruss-intc: Add an inline pruss_intc_trigger() helper"
  remoteproc/pru: Deprecate usage of pruss_intc_trigger()
  arm64: dts: ti: k3-j721e-main: Update the compatible for ICSS IEP nodes
  arm64: dts: ti: k3-am65-main: Update the compatible for ICSS IEP nodes
  ARM: dts: keystone-k2g: Update the PRUSS IEP nodes
  ARM: dts: dra7-pruss: Update the PRUSS IEP nodes
  ARM: dts: am4372: Update the PRUSS IEP nodes
  ARM: dts: am335x: Update the PRUSS IEP node
  dt-bindings: soc: ti: pruss: Update IEP documentation
  dt-bindings: net: icss_iep: Add dt binding documentation
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS"
Suman Anna [Fri, 19 Jun 2020 20:21:07 +0000 (15:21 -0500)]
Revert "dt-bindings: remoteproc: Add binding doc for PRU Cores in the PRU-ICSS"

This reverts commit 299339cc6091b11735ea6364a09cdfb1906c2e61.

The plain text-format binding document for the PRU remoteproc device has
been replaced by an equivalent upstream preferred YAML-format binding
document in commit d74629e20229 ("dt-bindings: remoteproc: Add binding
doc for PRU cores in the PRU-ICSS"), so revert the original text-based
binding patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg"
Suman Anna [Mon, 15 Jun 2020 19:17:03 +0000 (14:17 -0500)]
Revert "dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg"

This reverts commit 04c472a20fa30a7ab8551ff88955771b8599c1a0.

The plain text-format document update for the rpmsg support in the PRU
remoteproc binding has been replaced by an equivalent upstream preferred
YAML-format binding document in commit 1563d95e53a7 ("dt-bindings:
remoteproc: pru: Update bindings for supporting rpmsg"), so revert the
above text-based binding update patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: remoteproc: pru: Document application node bindings"
Suman Anna [Fri, 19 Jun 2020 20:20:04 +0000 (15:20 -0500)]
Revert "dt-bindings: remoteproc: pru: Document application node bindings"

This reverts commit 286069bc89647a0f17b52ddbaa33cb5569b07865.

The plain text-format binding document update to the PRU remoteproc
binding for the PRU application nodes has been replaced by a separate
equivalent upstream preferred YAML-format binding document in
commit 8f54d76f31ed ("dt-bindings: remoteproc: Add PRU consumer
bindings"), so revert the above text-based binding update patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x & J721E SoCs"
Suman Anna [Fri, 19 Jun 2020 20:19:03 +0000 (15:19 -0500)]
Revert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x & J721E SoCs"

This reverts commit 71680bc1f3476e4730860e2a5900f069df0260f3.

The plain text-format binding document for the PRU remoteproc device has
been replaced by an equivalent upstream preferred YAML-format binding
document in commit d74629e20229 ("dt-bindings: remoteproc: Add binding
doc for PRU cores in the PRU-ICSS"), so revert the above text-based
binding update patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs"
Suman Anna [Fri, 19 Jun 2020 20:18:34 +0000 (15:18 -0500)]
Revert "dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs"

This reverts commit 6bed57545aa1d4e9c4a10dcceb58b2faa3b2a1a7.

The plain text-format binding document for the PRU remoteproc device has
been replaced by an equivalent upstream preferred YAML-format binding
document in commit d74629e20229 ("dt-bindings: remoteproc: Add binding
doc for PRU cores in the PRU-ICSS"), so revert the above text-based
binding update patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoRevert "dt-bindings: irqchip: Add PRUSS interrupt controller bindings"
Suman Anna [Mon, 15 Jun 2020 19:10:47 +0000 (14:10 -0500)]
Revert "dt-bindings: irqchip: Add PRUSS interrupt controller bindings"

This reverts commit 2e00d1d28e067fb99aad0c23c7ae14203498a138.

Drop the plain text-format binding document for the PRUSS interrupt
controller. This has been replaced by an equivalent upstream preferred
YAML-format binding document in commit 52d5b9d47ca4 ("dt-bindings:
irqchip: Add PRU-ICSS interrupt controller bindings").

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agodt-bindings: remoteproc: Add PRU consumer bindings
Suman Anna [Thu, 18 Jun 2020 18:55:03 +0000 (13:55 -0500)]
dt-bindings: remoteproc: Add PRU consumer bindings

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

The application nodes themselves should define their own bindings.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
10 months agodt-bindings: remoteproc: pru: Update bindings for supporting rpmsg
Suman Anna [Fri, 19 Jun 2020 20:06:50 +0000 (15:06 -0500)]
dt-bindings: remoteproc: pru: Update bindings for supporting rpmsg

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

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agodt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSS
Suman Anna [Tue, 16 Jun 2020 21:41:05 +0000 (16:41 -0500)]
dt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSS

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
RISC cores (Programmable Real-Time Units, or PRUs) for program execution.

The K3 AM65x amd J721E SoCs have the next generation of the PRU-ICSS IP,
commonly called ICSSG. The ICSSG IP on AM65x SoCs has two PRU cores,
two auxiliary custom PRU cores called Real Time Units (RTUs). The K3
AM65x SR2.0 and J721E SoCs have a revised version of the ICSSG IP, and
include two additional custom auxiliary PRU cores called Transmit PRUs
(Tx_PRUs).

This patch adds the bindings for these PRU cores. The binding covers the
OMAP architecture SoCs - AM33xx, AM437x and AM57xx; Keystone 2 architecture
based 66AK2G SoC; and the K3 architecture based SoCs - AM65x and J721E. The
Davinci based OMAPL138 SoCs will be covered in a future patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
10 months agodt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings
Suman Anna [Wed, 17 Jun 2020 00:48:31 +0000 (19:48 -0500)]
dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply 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 on
most SoCs with individual control configuration and h/w prioritization.
These events are mapped onto 10 output interrupt lines through two levels
of many-to-one mapping support. Different interrupt lines are routed to
the individual PRU cores or to the host CPU or to other PRUSS instances.

The K3 AM65x and J721E 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.

Add the bindings document for these interrupt controllers on all the
applicable SoCs. It covers the OMAP architecture SoCs - AM33xx, AM437x
and AM57xx; the Keystone 2 architecture based 66AK2G SoC; the Davinci
architecture based OMAPL138 SoCs, and the K3 architecture based AM65x
and J721E SoCs.

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>
10 months agoRevert "TEMP: irqchip/irq-pruss-intc: Add an inline pruss_intc_trigger() helper"
Suman Anna [Fri, 19 Jun 2020 16:33:32 +0000 (11:33 -0500)]
Revert "TEMP: irqchip/irq-pruss-intc: Add an inline pruss_intc_trigger() helper"

This reverts commit ae2f2f489cf7efe6ad761a27094d54a9adb84c3d.

Drop the header file that introduces the pruss_intc_trigger() helper.
Any PRU client drivers are expected to use the irq_set_irqchip_state()
function with appropriate arguments directly to send an event to the
PRUs.

Signed-off-by: Suman Anna <s-anna@ti.com>
10 months agoremoteproc/pru: Deprecate usage of pruss_intc_trigger()
Suman Anna [Thu, 18 Jun 2020 19:00:02 +0000 (14:00 -0500)]
remoteproc/pru: Deprecate usage of pruss_intc_trigger()

The only user of the pruss_intc_trigger() API is the PRU remoteproc
driver itself. Use the API irq_set_irqchip_state() provided by the
kernel IRQ subsystem directly instead. This is in preparation for
dropping the pruss_intc_trigger() API and the corresponding header
fil, and is the recommended way going forward for any new PRU client
drivers as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoarm64: dts: ti: k3-j721e-main: Update the compatible for ICSS IEP nodes
Suman Anna [Tue, 9 Jun 2020 15:11:51 +0000 (10:11 -0500)]
arm64: dts: ti: k3-j721e-main: Update the compatible for ICSS IEP nodes

Update the compatible for all ICSSG IEP nodes to ti,am654-icss-iep, so
that icss_iep driver can be probed.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoarm64: dts: ti: k3-am65-main: Update the compatible for ICSS IEP nodes
Lokesh Vutla [Sun, 7 Jun 2020 15:07:48 +0000 (15:07 +0000)]
arm64: dts: ti: k3-am65-main: Update the compatible for ICSS IEP nodes

Update the compatible for all ICSSG IEP nodes to ti,am654-icss-iep, so
that icss_iep driver can be probed.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoARM: dts: keystone-k2g: Update the PRUSS IEP nodes
Lokesh Vutla [Tue, 9 Jun 2020 18:18:18 +0000 (13:18 -0500)]
ARM: dts: keystone-k2g: Update the PRUSS IEP nodes

Update the compatible for all PRU-ICSS IEP nodes to ti,am5728-icss-iep,
so that icss_iep driver can be probed. Also add the required clocks
property to IEP nodes.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: update iep clocks]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoARM: dts: dra7-pruss: Update the PRUSS IEP nodes
Lokesh Vutla [Tue, 9 Jun 2020 18:16:32 +0000 (13:16 -0500)]
ARM: dts: dra7-pruss: Update the PRUSS IEP nodes

Update the compatible for all PRU-ICSS IEP nodes to ti,am5728-icss-iep,
so that icss_iep driver can be probed. Also add the required clocks
property to IEP nodes.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: update iep clock]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoARM: dts: am4372: Update the PRUSS IEP nodes
Lokesh Vutla [Tue, 9 Jun 2020 18:14:56 +0000 (13:14 -0500)]
ARM: dts: am4372: Update the PRUSS IEP nodes

Update the compatible for all PRU-ICSS IEP nodes to ti,am3356-icss-iep,
so that icss_iep driver can be probed. Also add the required clocks
property to IEP nodes.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: update iep clock]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoARM: dts: am335x: Update the PRUSS IEP node
Lokesh Vutla [Tue, 9 Jun 2020 18:11:53 +0000 (13:11 -0500)]
ARM: dts: am335x: Update the PRUSS IEP node

Update the compatible for the PRU-ICSS IEP node to ti,am3356-icss-iep, so
that icss_iep driver can be probed. Also add the required clocks property
to IEP node.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: update iep clock]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agodt-bindings: soc: ti: pruss: Update IEP documentation
Lokesh Vutla [Tue, 9 Jun 2020 18:08:06 +0000 (13:08 -0500)]
dt-bindings: soc: ti: pruss: Update IEP documentation

Update the PRUSS documentation to point to IEP documentation.
The examples have also been updated to add the required clocks
property, with the IEP mux clocks added.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[s-anna@ti.com: Update examples]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agodt-bindings: net: icss_iep: Add dt binding documentation
Lokesh Vutla [Tue, 9 Jun 2020 18:00:43 +0000 (13:00 -0500)]
dt-bindings: net: icss_iep: Add dt binding documentation

Add DT binding documentation for ICSS IEP module.

Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoTEMP: soc: ti: pruss: Extend IEPCLK_MUX support to non-K3 SoCs
Suman Anna [Tue, 9 Jun 2020 17:52:38 +0000 (12:52 -0500)]
TEMP: soc: ti: pruss: Extend IEPCLK_MUX support to non-K3 SoCs

The commit 1b7637e503cc ("TEMP: soc: ti: pruss: support CORECLK_MUX
and IEPCLK_MUX") has added limited support for the internal PRU-ICSS
mux clocks IEPCLK_MUX and CORECLK_MUX only on K3 AM65x and J721E
SoCs.

The IEPCLK_MUX is present on the other SoC families supporting PRUSS
like the OMAP-architecture SoCs AM335x, AM437x, AM57xx and the
Keystone 2 66AK2G SoCs. Enhance the PRUSS platform driver to extend
the IEPCLK_MUX support on all these SoCs.

While at this, a small typo is also fixed that used the wrong clk
variable during the IEPCLK_MUX clock registration.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoTEMP: ARM: dts: keystone-k2g: Add PRUSS IEP clock muxes
Suman Anna [Tue, 9 Jun 2020 17:46:05 +0000 (12:46 -0500)]
TEMP: ARM: dts: keystone-k2g: Add PRUSS IEP clock muxes

The PRUSS module has an internal clock mux for the IEP source clock,
that can be sourced from either of the ICSS_IEP_CLK or the ICSS_VCLK_CLK
and configured through a register in the PRUSS CFG sub-module. Add a
clock mux node for this in each of the PRUSS instances on 66AK2G SoCs.
The default source for these mux clocks is the ICSS_IEP_CLK clock.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoTEMP: ARM: dts: dra7: Add PRUSS IEP clock muxes
Suman Anna [Tue, 9 Jun 2020 17:26:50 +0000 (12:26 -0500)]
TEMP: ARM: dts: dra7: Add PRUSS IEP clock muxes

The PRUSS module has an internal clock mux for the IEP source clock,
that can be sourced from either of the ICSS_IEP_CLK or the ICSS_CLK
and configured through a register in the PRUSS CFG sub-module. Add a
clock mux node for this in each of the PRUSS instances on AM57xx SoCs.
The default source for these mux clocks is the ICSS_IEP_CLK clock.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoTEMP: ARM: dts: am4372: Add PRUSS IEP clock muxes
Suman Anna [Tue, 9 Jun 2020 17:06:59 +0000 (12:06 -0500)]
TEMP: ARM: dts: am4372: Add PRUSS IEP clock muxes

The PRUSS module has an internal clock mux for the IEP source clock,
that can be sourced from either of the PRU_ICSS_IEP_GCLK or the
PRU_ICSS_OCP_GCLK and configured through a register in the PRUSS
CFG sub-module. Add a clock mux node for this in each of the PRUSS
instances on AM437x SoCs. The default source for these mux clocks
is the PRU_ICSS_IEP_GCLK clock.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoTEMP: ARM: dts: am335x: Add PRUSS IEP clock mux
Suman Anna [Tue, 9 Jun 2020 16:49:50 +0000 (11:49 -0500)]
TEMP: ARM: dts: am335x: Add PRUSS IEP clock mux

The PRUSS module has an internal clock mux for the IEP source clock,
that can be sourced from either of the PRU_ICSS_IEP_GCLK or the
PRU_ICSS_OCP_GCLK and configured through a register in the PRUSS
CFG sub-module. Add a clock mux node for this. The default source
for this mux clock is PRU_ICSS_IEP_GCLK.

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Mon, 1 Jun 2020 16:18:36 +0000 (11:18 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that fixes couple of issues
with the OMAP remoteproc driver. The issues fixed include restoring the
Error Recovery functionality of the DSP remote processors, and re-enables
the MMU Faults upon error recovery on all the IPU and DSP remote processors.
The Error Recovery functionality is now on-par with the 2019 LTS functionality
except for the below NOTE.

The merge also pulls in couple of other issues in the OMAP IOMMU driver
related to "BUG: sleeping function called from invalid context" and a
probe deferral warning message.

NOTE:
The MMU page tables (TTBs) are not re-allocated, the MMUs are simply
restarted preserving the same previously allocated/programmed Page Tables.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: Trigger IOMMU during crash recovery sequence
  iommu/omap: Add registration for DT fwnode pointer
  iommu/omap: convert spinlocks to mutexes

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoremoteproc/omap: Trigger IOMMU during crash recovery sequence
Tero Kristo [Mon, 11 May 2020 19:17:31 +0000 (19:17 +0000)]
remoteproc/omap: Trigger IOMMU during crash recovery sequence

Trigger IOMMU during crash recovery sequence to reset IOMMU also.
Otherwise IOMMU may end up in a stale state, causing the remoteproc to
hang or crash again.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoMerge branch 'iommu-linux-5.4.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Fri, 29 May 2020 22:27:09 +0000 (17:27 -0500)]
Merge branch 'iommu-linux-5.4.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-5.4.y

Merge in the updated iommu feature branch into remoteproc tree to pull
in couple of fixes that resolve a "BUG: sleeping function called from
invalid context" issue during starting and stopping of a remoteproc,
and the "ignoring dependency for device, assuming no driver" traces
seen during the OMAP remoteproc probe function for each remote processor.

* 'iommu-linux-5.4.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Add registration for DT fwnode pointer
  iommu/omap: convert spinlocks to mutexes

Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoiommu/omap: Add registration for DT fwnode pointer
Tero Kristo via iommu [Fri, 24 Apr 2020 14:58:28 +0000 (17:58 +0300)]
iommu/omap: Add registration for DT fwnode pointer

[ Upstream commit 5df362a53f7d36e032668e7e6725d80622b98525 ]

The fwnode pointer must be passed to the iommu core, so that the core
can map the IOMMU towards device requests properly. Without this, some
IOMMU clients like OMAP remoteproc will fail the iommu configuration
multiple times with -EPROBE_DEFER, which will eventually be ignored with
a kernel warning banner.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Link: https://lore.kernel.org/r/20200424145828.3159-1-t-kristo@ti.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
[s-anna@ti.com: cherry-pick commit '5df362a53f7d' from v5.8]
Signed-off-by: Suman Anna <s-anna@ti.com>
11 months agoiommu/omap: convert spinlocks to mutexes
Tero Kristo [Mon, 11 May 2020 19:17:30 +0000 (19:17 +0000)]
iommu/omap: convert spinlocks to mutexes

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 29 Apr 2020 14:41:07 +0000 (09:41 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that changes the default
mode for Main R5FSS1 cluster on J721E SoCs from LockStep to Split mode.
This makes the default number of R5F cores from 4 to 5 on the latest
kernel.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  arm64: dts: ti: k3-j721e-main: Configure MAIN R5FSS1 for Split-mode

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoarm64: dts: ti: k3-j721e-main: Configure MAIN R5FSS1 for Split-mode
Suman Anna [Tue, 28 Apr 2020 17:43:07 +0000 (12:43 -0500)]
arm64: dts: ti: k3-j721e-main: Configure MAIN R5FSS1 for Split-mode

Switch the MAIN R5FSS1 cluster to be configured for Split-mode as the
default so that two different applications can be run on each of the
R5F cores in performance mode. LockStep-mode would be available only
on SoCs efused with the appropriate capability bit, and Split-mode is
the mode that is available on all J721E SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoti_config_fragments: rpmsg/v8_rpmsg: Enable rpmsg_char driver
Suman Anna [Tue, 28 Apr 2020 04:12:09 +0000 (04:12 +0000)]
ti_config_fragments: rpmsg/v8_rpmsg: Enable rpmsg_char driver

Enable the generic rpmsg_char driver (RPMSG_CHAR) in both the
ipc.cfg and v8_ipc.cfg so that the driver is built as a module
by default on all applicable TI platforms. The module is built
as a rpmsg_char.ko, and the driver name in sysfs is rpmsg_chrdev.

The driver presents a /dev/rpmsg_ctrlX (where X is an allocated
number) for each rpmsg device that can probe this driver. The
driver currently does not get auto-probed, but if desired, can
have the published rpmsg devices be bound to this driver using
udev rules or some userspace admin process.

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Mon, 27 Apr 2020 16:00:58 +0000 (11:00 -0500)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the updated remoteproc feature branch that adds the base
support to the PRU remoteproc driver for supporting the enhanced
ICSSG IP in AM65x SR2.0 SoCs. The merge also includes some cleanup
to the PRU remoteproc driver to introduce device match data so as
to move away from runtime of_device_is_compatible() usage in code.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/pru: Add support for Tx PRU cores on K3 AM65x SR2.0 SoCs
  dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs
  remoteproc/pru: Cleanup of_device_is_compatible() usage

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoremoteproc/pru: Add support for Tx PRU cores on K3 AM65x SR2.0 SoCs
Suman Anna [Sat, 25 Apr 2020 04:10:26 +0000 (04:10 +0000)]
remoteproc/pru: Add support for Tx PRU cores on K3 AM65x SR2.0 SoCs

The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the
subsequent IP revision used on J721E SoCs. This IP instance has two
new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in
addition to the existing PRUs and RTUs.

The Tx_PRU cores have their own dedicated IRAM (smaller than a PRU
or RTY), Control and debug feature sets. The RTU and Tx_PRU cores
though share the same Data RAMs as the PRU cores, so the memories
have to be partitioned carefully between different applications.

Enhance the existing PRU remoteproc driver to support these new Tx
PRU cores by using specific compatibles.

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agodt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs
Suman Anna [Sat, 25 Apr 2020 04:10:25 +0000 (04:10 +0000)]
dt-bindings: remoteproc: pru: Update bindings for K3 AM65x SR2.0 SoCs

The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the
subsequent IP revision used on J721E SoCs, yet retaining some of the
features from AM65x SR1.0 like the PRU IRAM size etc. The ICSSG IP
on K3 AM65x SR2.0 SoCs have two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.

Update the PRU remoteproc bindings for these Tx PRU cores.

Signed-off-by: Suman Anna <s-anna@ti.com>
12 months agoremoteproc/pru: Cleanup of_device_is_compatible() usage
Suman Anna [Sat, 25 Apr 2020 04:10:24 +0000 (04:10 +0000)]
remoteproc/pru: Cleanup of_device_is_compatible() usage

The PRU remoteproc driver uses the of_device_is_compatible() function
during probe to dynamically assign some flags and properties for each
PRU core. This usage is not recommended and makes the code a bit
cumbersome. Cleanup most of this usage by using device compatible
match data. The check for K2G to conditionally avoid the mailbox
usage is the only check left-out.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support
Suman Anna [Sun, 23 Feb 2020 16:10:09 +0000 (10:10 -0600)]
ti_config_fragments: rpmsg: Enable OMAP remoteproc watchdog support

Enable the Watchdog timer support for the OMAP remoteproc driver. This
enables the OMAP remoteproc driver to recovery any remote processor
executions stuck in a loop. This also mandatas that that all the IPU
and DSP firmwares to be used with the OMAP remoteproc driver support
the Watchdog timers and are petting the corresponding dmtimers to avoid
a recurring reboot of that processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Sun, 23 Feb 2020 16:08:32 +0000 (10:08 -0600)]
Merge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.4.y

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Sun, 23 Feb 2020 16:05:33 +0000 (10:05 -0600)]
Merge branch 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-5.4.y

Pull in the updated rpmsg base feature branch that includes fixes to the
rpmsg-rpc driver for various bugs and memory leak issues found during
error recovery with active open applications

* 'rpmsg-linux-5.4.y' of git://git.ti.com/rpmsg/rpmsg:
  rpmsg: rpc: fix potential memory leak of unprocessed skbs
  rpmsg: rpc: fix ept memory leak during recovery
  rpmsg: rpc: use the local device pointer in all file operations
  rpmsg: rpc: maintain a reference device pointer per open fd
  rpmsg: rpc: fix sysfs entry creation failures during recovery

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoMerge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Sun, 23 Feb 2020 15:59:41 +0000 (09:59 -0600)]
Merge branch 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-5.4.y

Pull in the remoteproc feature branch that adds the support for error recovery
from both internal exceptions and Watchdog errors on all IPU and DSP remote
processors on OMAP4+ SoCs. The merge also adds a debugfs last trace feature
to remoteproc core. Also included is a fix for a memory leak issue in virtio
ring core, and a minor optimization in the remoteproc debugfs 'recovery' file;
and fixes for some state-machine issues related to MMU faults with OMAP
remoteproc driver.

NOTE: DSP error recovery is going through fine, but the DSP is not booting
currently. This will be fixed up in a future patch series.

* 'rproc-linux-5.4.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
  ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
  ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
  remoteproc/omap: Add watchdog functionality for remote processors
  remoteproc: Fix multiple back-to-back error recoveries
  remoteproc/omap: Report device exceptions and trigger recovery
  remoteproc: implement last trace for remoteproc
  remoteproc: debugfs: Optimize the trace va lookup
  virtio_ring: Fix mem leak with vring_new_virtqueue()

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
Suman Anna [Tue, 18 Feb 2020 23:51:31 +0000 (17:51 -0600)]
ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes

The watchdog timer information has been added to all the IPU and DSP
remote processor device nodes in the DRA7xx/AM57xx SoC families. The
data has been added to the two common dra7-ipu-dsp-common and
dra74-ipu-dsp-common dtsi files that can be included by all the
desired board files. The following timers are chosen as the watchdog
timers, as per the usage on the current firmware images:
        IPU2: GPTimers 4 & 9 (one for each Cortex-M4 core)
        IPU1: GPTimers 7 & 8 (one for each Cortex-M4 core)
        DSP1: GPTimer 10
        DSP2: GPTimer 13

Each of the IPUs has two Cortex-M4 processors and so uses a timer
each for providing watchdog support on that processor irrespective of
whether the IPU is running in SMP-mode or non-SMP node. The chosen
timers also need to be unique from the ones used by other processors
(regular timers or watchdog timers) so that they can be supported
simultaneously.

The MPU-side drivers will use this data to initialize the watchdog
timer(s), and listen for any watchdog triggers. The BIOS-side code on
these processors needs to configure/refresh the corresponding timer
properly to not throw a watchdog error.

The watchdog timers are optional in general, but are mandatory to
be added to support watchdog error recovery on a particular processor.
These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
Suman Anna [Tue, 18 Feb 2020 23:50:01 +0000 (17:50 -0600)]
ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP

The watchdog timers have been added for the IPU and DSP remoteproc
devices for the OMAP5 uEVM board. The following timers (same as the
timers on OMAP4 Panda boards) are used as the watchdog timers,
        DSP : GPT6
        IPU : GPT9 & GPT11 (one for each Cortex-M4 core)

The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.

These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

Signed-off-by: Suman Anna <s-anna@ti.com>
14 months agoARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
Suman Anna [Tue, 18 Feb 2020 23:49:03 +0000 (17:49 -0600)]
ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP

The watchdog timers have been added for the IPU and DSP remoteproc
devices on all the OMAP4-based Panda boards. The following timers
are used as the watchdog timers,
DSP : GPT6
IPU : GPT9 & GPT11 (one for each Cortex-M3 core)

The MPU-side drivers will use this data to initialize the watchdog
timers, and listen for any watchdog triggers. The BIOS-side code
needs to configure and refresh these timers properly to not throw
a watchdog error.

These timers can be changed or removed as per the system integration
needs, alongside appropriate equivalent changes on the firmware side.

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