rpmsg/rpmsg.git
2 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg... rpmsg-ti-linux-4.14.y
Suman Anna [Mon, 24 Sep 2018 20:05:13 +0000 (15:05 -0500)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that includes the
fix for the CCS connection issues with DRA7xx DSPs.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: DRA7: hwmod_data: Fix second MMU's data on DSPs

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoMerge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Mon, 24 Sep 2018 19:59:27 +0000 (14:59 -0500)]
Merge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.14.y

Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in a fix on the DRA7 DSP hwmod data that fixes
the CCS connection issues to DSPs on 4.14 kernels.

* 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu:
  ARM: DRA7: hwmod_data: Fix second MMU's data on DSPs

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoARM: DRA7: hwmod_data: Fix second MMU's data on DSPs
Suman Anna [Sat, 15 Sep 2018 03:33:12 +0000 (22:33 -0500)]
ARM: DRA7: hwmod_data: Fix second MMU's data on DSPs

The DSPs on DRA7xx/AM57xx SoCs have two MMUs each, one for the
processor core and the other for the internal EDMA block. The
EDMA MMU relies on the primary MMU enabling sequence and so does
not contain any .clkctrl_offs, .module_mode and .context_offs
fields. The .context_offs field does not use a 0 value as a no-op
unlike the other two fields, and requires a special flag to be
set in the .prcm.omap4.flags field to ignore.

The missing flag has caused the omap_hwmod_enable() code to
erroneously modify the module's PWRSTCTRL register as part of the
context update logic, and resulted in the LOWPOWERSTATECHANGE bit
being set. While this hasn't resulted in any incorrect execution
behavior of the DSPs, it has affected the ability to connect a
debugger to the DSP core. CCS throws the following error upon
attempting to connect to DSPs:
"C66xx_DSP: Error connecting to the target: (Error -6305) PRSC
 module failed to write to a router register."

Add the desired flag to each of the second MMU hwmods to fix
the debugger connection issues.

Reported-by: Rex Chang <rchang@ti.com>
Fixes: f7b0b1e6b00a ("ARM: DRA7: hwmod data: Add MMU data for DSPs")
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 12 Sep 2018 13:57:08 +0000 (08:57 -0500)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that adds support to the
remoteproc core to allow individual remoteproc drivers to deny sysfs
operations for changing the firmware and starting/stopping the remoteprocs.
The Keystone remoteproc, Wakeup M3 remoteproc and PRU remoteproc drivers
have been updated to deny these operations for certain usage scenarios.
This fixes a kernel crash due to incorrect reference count management
on PRUs when using sysfs operations on PRU Ethernet owned remoteprocs.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/pru: deny rproc sysfs ops for PRU client driven boots
  Revert "remoteproc: deny sysfs operations with MPM userspace loader"
  remoteproc/keystone: set deny_sysfs_ops flag for MPM userspace loader
  remoteproc/wkup_m3: set deny_sysfs_ops flag
  remoteproc: introduce deny_sysfs_ops flag

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc/pru: deny rproc sysfs ops for PRU client driven boots
Suman Anna [Mon, 10 Sep 2018 19:40:07 +0000 (14:40 -0500)]
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>
2 years agoRevert "remoteproc: deny sysfs operations with MPM userspace loader"
Suman Anna [Mon, 10 Sep 2018 19:21:51 +0000 (14:21 -0500)]
Revert "remoteproc: deny sysfs operations with MPM userspace loader"

This reverts commit 775582b23076e23dbb03ec26c130bb749894c9a2.

This reverts the remoteproc sysfs denial logic for MPM userspace loader
introduced in commit 775582b23076 ("remoteproc: deny sysfs operations
with MPM userspace loader") in favor of the same functionality provided
by the generic remoteproc flag 'denys_sysfs_ops' in commit 385e53ab58f8
("remoteproc: introduce deny_sysfs_ops flag") and the corresponding
keystone remoteproc commit 1fa313fa64b8 ("remoteproc/keystone: set
deny_sysfs_ops flag for MPM userspace loader").

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc/keystone: set deny_sysfs_ops flag for MPM userspace loader
Suman Anna [Mon, 10 Sep 2018 19:11:27 +0000 (14:11 -0500)]
remoteproc/keystone: set deny_sysfs_ops flag for MPM userspace loader

The Keystone remoteproc driver supports two modes of loading and booting
the DSP processors - a traditional kernel auto-boot based loader and a
userspace driven load/boot mechanism called Multi Proc Manager (MPM).
The sysfs interfaces conflict with the MPM state-machine and are
currently denied using the 'use_userspace_loader' flag introduced
primarily to meet the keystone remoteproc driver needs. Use the newly
introduced remoteproc generic 'deny_sysfs_ops' flag to provide the same
restrictions. This allows the remoteproc sysfs code to be rid of the
code using the custom 'use_userspace_loader' flag.

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc/wkup_m3: set deny_sysfs_ops flag
Suman Anna [Mon, 10 Sep 2018 17:48:34 +0000 (12:48 -0500)]
remoteproc/wkup_m3: set deny_sysfs_ops flag

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

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: introduce deny_sysfs_ops flag
Suman Anna [Mon, 10 Sep 2018 17:30:26 +0000 (12:30 -0500)]
remoteproc: introduce deny_sysfs_ops flag

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Sun, 19 Aug 2018 17:06:05 +0000 (12:06 -0500)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that pulls in couple of
fixes - an OMAP IOMMU patch fixing the improper cache flushing of L2
MMU entries triggering false MMU faults, and a patch in remoteproc core
resolving kernel crashes in couple of code paths affecting remoteprocs
using CMA pools from HighMem.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: Fix kernel crashes for rprocs using HighMem CMA pools
  iommu/omap: Fix cache flushes on L2 table entries

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoremoteproc: Fix kernel crashes for rprocs using HighMem CMA pools
Suman Anna [Sat, 21 Jul 2018 01:32:48 +0000 (20:32 -0500)]
remoteproc: Fix kernel crashes for rprocs using HighMem CMA pools

The remoteproc core driver uses a table_ptr state variable for
handling and processing various resources and updating certain
fields in the resource table during the loading phase. This ptr
is pointing at one of two copies during the life cycle of a remote
processor. An initial cached table (allocated in linear kernel
memory and copied during firmware parsing step) is used until
the firmware segments are loaded, and thereafter a loaded table
reflecting the memory in one of the loaded segments where the
table is present just before releasing the processor from reset.
The loaded segments are allocated using the DMA API and can come
from the remoteproc device's CMA or carveout pools, and so can
be present anywhere in memory.

The current state machine logic has couple of use after free errors
in certain code paths resulting in kernel crashes:
 - Failure paths in rproc_fw_boot() after the table_ptr is updated
   to point to the loaded table
 - Shutdown paths either during a graceful shutdown (using sysfs
   stop or unbind opertions) or during a shutdown as part of the
   error recovery when the loaded segments are freed and the
   table_ptr still pointing to a memory in the loaded segment.

The kernel crashes were a result of freeing the vdevs using memory
that has already been freed. These use after free issues were exposed
specifically only when the memory segments are allocated from CMA
pools in HighMem, as they are mapped and unmapped at runtime into
kernel memory. The kernel mappings are linear (one-to-one and always
present) with memory segments allocated from CMA pools in LowMem,
and runtime mapped in vmalloc space linearly the first time permanently
for Carveouts irrespective of LowMem or HighMem, so the issues were
masked. Fix these by properly resetting the table_ptr variable back
to the cached table at appropriate places.

The common crash signature looks (only a snippet) as follows:

 Unable to handle kernel paging request at virtual address f3acf070
 pgd = ec83c000
 [f3acf070] *pgd=acaa9811, *pte=00000000, *ppte=00000000
 ...
 PC is at rproc_free_vring+0x170/0x1ec [remoteproc]
 ...
 Backtrace:
  [<bf001368>] (rproc_free_vring [remoteproc]) from [<bf001854>] (rproc_vdev_release+0x24/0x74 [remoteproc])
  r10:ed336800 r9:e0600000 r8:00100000 r7:f4013000 r6:ee29d810 r5:ed3369f8
  r4:ed336400
  [<bf001830>] (rproc_vdev_release [remoteproc]) from [<bf001cec>] (rproc_resource_cleanup+0x448/0x57c [remoteproc])
  r5:ed3369f8 r4:ed336a10
  [<bf0018a4>] (rproc_resource_cleanup [remoteproc]) from [<bf002478>] (rproc_shutdown+0x9c/0x154 [remoteproc])

[gdaubar@harris.com: reported issue with graceful shutdown]
Reported-by: Gerard Daubar <gdaubar@harris.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoMerge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Fri, 10 Aug 2018 16:48:48 +0000 (11:48 -0500)]
Merge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.14.y

Pull in the updated iommu feature branch into the remoteproc feature
branch. This merge pulls in a fix for a streaming DMA API cache flushing
bug affecting the L2 page table entries.

* 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: Fix cache flushes on L2 table entries

Signed-off-by: Suman Anna <s-anna@ti.com>
2 years agoiommu/omap: Fix cache flushes on L2 table entries
Ralf Goebel [Mon, 6 Aug 2018 15:00:36 +0000 (17:00 +0200)]
iommu/omap: Fix cache flushes on L2 table entries

The base address used for DMA operations on the second-level table
did incorrectly include the offset for the table entry. The offset
was then added again which lead to incorrect behavior.

Operations on the L1 table are not affected.

The calculation of the base address is changed to point to the
beginning of the L2 table.

Fixes: bfee0cf0ee1d ("iommu/omap: Use DMA-API for performing cache flushes")
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Ralf Goebel <ralf.goebel@imago-technologies.com>
[s-anna@ti.com: cherry-pick commit '04c532a1cdc7' planned for v4.19]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 18 Apr 2018 23:52:13 +0000 (18:52 -0500)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that enables the DSP and
and IPU processor subsystems on the DRA71-LCard board. All OMAP remoteproc
features are functional. The IVA and DSP remote processors would normally
be running at the default OPP_NOM clock frequencies, and at OPP_HIGH with
the appropriate U-Boot (TI U-Boot is configured for OPP_HIGH).

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: dts: dra71-lcard: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra71-lcard: Add common data for IPUs and DSP1

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra71-lcard: Add CMA pools and enable IPUs & DSP1 rprocs
Suman Anna [Sat, 3 Mar 2018 01:55:47 +0000 (19:55 -0600)]
ARM: dts: dra71-lcard: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA71-LCard board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA71 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra71-lcard: Add common data for IPUs and DSP1
Suman Anna [Wed, 7 Mar 2018 16:37:13 +0000 (10:37 -0600)]
ARM: dts: dra71-lcard: Add common data for IPUs and DSP1

The DRA71-LCard board currently doesn't have the IPU and DSP remote
processor nodes enabled, and neither it includes any of the OMAP
mailboxes, Timers or Watchdog Timers added to these remote processor
nodes. The common dra7-ipu-dsp-common.dtsi file, relevant for
all DRA72x/DRA71x boards, has all these properties added to the
various remoteproc nodes. Include this file to have these properties
added for DRA71-LCard board as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 6 Mar 2018 18:41:07 +0000 (12:41 -0600)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that pulls in a patch
from stable tree to fix the CMA allocation failures and thereby a
remoteproc boot during stress tests that boot a remote processor
repeatedly either through bind/unbind of the device, insmod/rmmod
of the driver or through error recovery of a processor. These paths
perform the boot in a workqueue context unlike the sysfs start/stop
interface and suffer from this failure.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  mm, memory_hotplug: do not back off draining pcp free pages from kworker context

3 years agomm, memory_hotplug: do not back off draining pcp free pages from kworker context
Michal Hocko [Thu, 30 Nov 2017 00:09:54 +0000 (16:09 -0800)]
mm, memory_hotplug: do not back off draining pcp free pages from kworker context

commit 4b81cb2ff69c8a8e297a147d2eb4d9b5e8d7c435 upstream.

drain_all_pages backs off when called from a kworker context since
commit 0ccce3b92421 ("mm, page_alloc: drain per-cpu pages from workqueue
context") because the original IPI based pcp draining has been replaced
by a WQ based one and the check wanted to prevent from recursion and
inter workers dependencies.  This has made some sense at the time
because the system WQ has been used and one worker holding the lock
could be blocked while waiting for new workers to emerge which can be a
problem under OOM conditions.

Since then commit ce612879ddc7 ("mm: move pcp and lru-pcp draining into
single wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a
rescuer so we shouldn't depend on any other WQ activity to make a
forward progress so calling drain_all_pages from a worker context is
safe as long as this doesn't happen from mm_percpu_wq itself which is
not the case because all workers are required to _not_ depend on any MM
locks.

Why is this a problem in the first place? ACPI driven memory hot-remove
(acpi_device_hotplug) is executed from the worker context.  We end up
calling __offline_pages to free all the pages and that requires both
lru_add_drain_all_cpuslocked and drain_all_pages to do their job
otherwise we can have dangling pages on pcp lists and fail the offline
operation (__test_page_isolated_in_pageblock would see a page with 0 ref
count but without PageBuddy set).

Fix the issue by removing the worker check in drain_all_pages.
lru_add_drain_all_cpuslocked doesn't have this restriction so it works
as expected.

Link: http://lkml.kernel.org/r/20170828093341.26341-1-mhocko@kernel.org
Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue context")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[s-anna@ti.com: cherry-pick commit 'b8d0c953d928' from v4.14.4]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rpmsg-linux-4.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Sat, 3 Mar 2018 19:52:39 +0000 (13:52 -0600)]
Merge branch 'rpmsg-linux-4.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.14.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-4.14.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>
3 years agoMerge branch 'rpmsg-linux-4.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Sat, 3 Mar 2018 19:39:54 +0000 (13:39 -0600)]
Merge branch 'rpmsg-linux-4.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.14.y

Pull in the updated rpmsg base feature branch that includes fixes
to various bugs and memory leak issues found during error recovery
with active open applications. Also included is a minor fix for an
out-of-bounds array access issue.

* rpmsg-linux-4.14.y:
  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
  rpmsg: rpc: fix potential out-of-bounds array access

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Sat, 3 Mar 2018 19:24:27 +0000 (13:24 -0600)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the remoteproc feature branch that restores the error recovery
functionality for remoteprocs with virtio devices and MMUs, and 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
are fixes couple of issues in remoteproc core w.r.t sysfs interface and
debugfs 'recovery' file; and fixes for some state-machine issues related
to OMAP remoteproc driver.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: fix auto-suspend failure warning during crashed state
  remoteproc: fix multiple back-to-back error recoveries
  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/omap: report device exceptions and trigger recovery
  remoteproc: implement last trace for remoteproc
  remoteproc: debugfs: fix a SRCU deadlock with recovery file
  Revert "remoteproc: Introduce rproc_{start,stop}() functions"
  Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/omap: fix auto-suspend failure warning during crashed state
Suman Anna [Thu, 11 May 2017 05:55:59 +0000 (05:55 +0000)]
remoteproc/omap: fix auto-suspend failure warning during crashed state

The runtime autosuspend on a OMAP remoteproc device is attempted when
the suspend timer expires (autosuspend delay elapsed since the last
time the device is busy). This is the normal autosuspend scenario
for a device functioning normally. This timer can also expire during
the debugging of a remoteproc crash when the remoteproc recovery is
disabled. This is an invalid pre-condition though, so check for the
RPROC_CRASHED state and bail out before the actual check for the
RPROC_RUNNING state. The auto-suspend is also not re-attempted until
the remoteproc is recovered and restored to normal functional state.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: fix multiple back-to-back error recoveries
Suman Anna [Fri, 10 Mar 2017 02:35:20 +0000 (20:35 -0600)]
remoteproc: fix multiple back-to-back error recoveries

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

This fixes an issue with error recovery upon MMU Faults on OMAP
IPU remote processors. An MMU fault on OMAP IPU sends two error
notifications - one a direct interrupt from the MMU, and the second
a mailbox-based crash notification after the remote processor has
collected some backtrace. The mailbox based interrupt mechanism,
added in commit f9d1d5605692 ("remoteproc/omap: report device
exceptions and trigger recovery"), is used for Attribute MMU (AMMU)
faults and other internal exceptions on the IPU. The backtrace
collection on the IPU remote processor is triggered by the same
interrupt which cannot be differentiated between an MMU fault and
an AMMU fault. The remoteproc core changes in 4.9 kernel around the
boot sequences has now caused the second notification to trigger a
secondary error recovery, which was avoided in previous kernels due
to the event detection in the work-function itself. The newer code
sequences changes the timing w.r.t previous kernels where the
recovery process was performed a bit later due to the asynchronous
firmware loading.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodes
Suman Anna [Wed, 21 Feb 2018 03:19:50 +0000 (21:19 -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>
3 years agoARM: dts: omap5-uevm: Add watchdog timers for IPU and DSP
Suman Anna [Tue, 5 Aug 2014 21:12:01 +0000 (16:12 -0500)]
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>
3 years agoARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSP
Suman Anna [Tue, 5 Aug 2014 21:13:09 +0000 (16:13 -0500)]
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>
3 years agoremoteproc/omap: add watchdog functionality for remote processors
Suman Anna [Thu, 22 Feb 2018 03:11:42 +0000 (21:11 -0600)]
remoteproc/omap: add watchdog functionality for remote processors

Remote processors can be stuck in a loop, and may not be recoverable
if they do not have a built-in watchdog. The watchdog implementation
for OMAP remote processors uses external gptimers that can be used
to interrupt both the Linux host as well as the remote processor.

Each remote processor is responsible for refreshing the timer during
normal behavior - during OS task scheduling or entering the idle loop
properly. During a watchdog condition (executing a tight loop causing
no scheduling), the host processor gets interrupts and schedules a
recovery for the corresponding remote processor. The remote processor
may also get interrupted to be able to print a back trace.

A menuconfig option has also been added to enable/disable the Watchdog
functionality, with the default as disabled.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/omap: report device exceptions and trigger recovery
Suman Anna [Tue, 22 Apr 2014 16:32:06 +0000 (11:32 -0500)]
remoteproc/omap: report device exceptions and trigger recovery

The OMAP remote processors send a special mailbox message
(RP_MBOX_CRASH) when they crash and detect an internal device
exception.

Add support to the mailbox handling function upon detection of
this special message to report this crash to the remoteproc core.
The remoteproc core can trigger a recovery using the prevailing
recovery mechanism, already in use for MMU Fault recovery.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: implement last trace for remoteproc
Suman Anna [Fri, 28 Apr 2017 21:46:12 +0000 (16:46 -0500)]
remoteproc: implement last trace for remoteproc

The last trace is a way of preserving the remoteproc traces past
remoteproc recovery. This is achieved by creating a new traceY_last
debugfs entry during a crash for each trace entry, and copying the
trace buffer contents into the corresponding last trace entry. This
copied contents can then be read out using a debugfs entry. The
trace entries themselves are cleaned up after the copy and are
recreated during a recovery reload.

Eg:
cat <debugfs_root>/remoteproc/remoteprocX/traceY_last
should give the traces that were printed out just before the recovery
happened on remoteproc X for trace Y.

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: debugfs: fix a SRCU deadlock with recovery file
Suman Anna [Thu, 23 Mar 2017 02:11:28 +0000 (21:11 -0500)]
remoteproc: debugfs: fix a SRCU deadlock with recovery file

The remoteproc debugfs file 'recovery' interface is provided to
aid developers to halt an error recovery and perform a post-mortem
analysis of a remote processor before continuing with the error
recovery. A write operation on this file can be used to disable
the recovery, recover once or to re-enable the error recovery
without halting.

This debugfs file is created using the debugfs_create_file(), so
supports the file lifetime management support intrinsically by means
of the srcu construct in the debugfs core (added in 4.7 kernel). The
remoteproc recovery process when triggered also involves the caching
and removal of the current traces and creation of the last traces
which operate on the same debugfs srcu lock, causing an SRCU deadlock
with the following signature,

"Illegal synchronize_srcu() in same-type SRCU (or in RCU) read-side
critical section!".

Use the debugfs_create_file_unsafe() to create the recovery file in a
non-proxying operation mode to avoid this deadlock. The file lifetime
management for the corresponding file_operations is skipped for now as
the creation of this recovery file is failrly self-managed within the
remoteproc core. A long term solution would probably be to revise the
crash handler workqueue to perform just the recovery in the workqueue
function.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoRevert "remoteproc: Introduce rproc_{start,stop}() functions"
Suman Anna [Thu, 1 Mar 2018 00:11:56 +0000 (18:11 -0600)]
Revert "remoteproc: Introduce rproc_{start,stop}() functions"

This reverts commit 1efa30d0895e7e9a58a59b0880b330b38245be68.

The commit 1efa30d0895e ("remoteproc: Introduce rproc_{start,stop}()
functions") has refactored code out from rproc_boot() and rproc_shutdown()
to optimize resource allocation overheads during the recovery. This
patch was made with an implicit assumption that the same firmware
image will always be used during recovery (rightfully so in a product
environment), and so the resources will also remain the same. The patch
had also changed the rproc state to RPROC_OFFLINE prior to cleaning up
all resources and disabling the MMU in rproc_shutdown(). This does not
play nice with doing any additional processing steps during recovery
in the resource cleanup function.

This patch is a custom revert of the above commit, accounting for
some additional changes done in commit 4765eb5f922f ("remoteproc:
add infrastructure to support user-space loading/booting") and
commit 8fbb8754da62 ("remoteproc: add support to handle device
specific resource types") thereby allowing a new last trace
mechanism to be supported in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoRevert "remoteproc: Modify recovery path to use rproc_{start,stop}()"
Suman Anna [Thu, 22 Feb 2018 22:20:15 +0000 (16:20 -0600)]
Revert "remoteproc: Modify recovery path to use rproc_{start,stop}()"

This reverts commit 7e83cab824a86704cdbd7735c19d34e0ce423dc5.

The commit 7e83cab824a8 ("remoteproc: Modify recovery path to use
rproc_{start,stop}()") has modified the rproc_trigger_recovery()
function to leverage rproc_stop() and rproc_start() functions
introduced in commit 1efa30d0895e ("remoteproc: Introduce
rproc_{start,stop}() functions") in place of the previous usage
of rproc_shutdown() and rproc_boot() functions. These new functions
execute only a portion of the previous functions, and are primarily
designed to optimize the allocation of memory resources. They do
not handle other resources like virtio devices and the resetting
of any IOMMUs. This results in a kernel crash like below when
performing error recovery on remoteprocs using both MMUs and
virtio devices like the OMAP remoteproc driver.

  omap-iommu 55082000.mmu: iommu fault: da 0x8004c000 flags 0x0
  remoteproc remoteproc1: crash detected in 55020000.ipu: type mmufault
  omap-iommu 55082000.mmu: 55082000.mmu: errs:0x00000002 da:0x8004c000 pgd:0xea066000 *pgd:px95f00002
  remoteproc remoteproc1: handling crash #1 in 55020000.ipu
  remoteproc remoteproc1: recovering 55020000.ipu
  omap-rproc 55020000.ipu: omap rproc 55020000.ipu crashed
  remoteproc remoteproc1: stopped remote processor 55020000.ipu
  kobject (eb783058): tried to init an initialized object, something is seriously wrong.
  CPU: 0 PID: 19 Comm: kworker/0:1 Not tainted 4.14.0-00414-g9fb7c019c63a #479
  Hardware name: Generic DRA74X (Flattened Device Tree)
  Workqueue: events rproc_crash_handler_work [remoteproc]
  [<c0111934>] (unwind_backtrace) from [<c010d6dc>] (show_stack+0x10/0x14)
  [<c010d6dc>] (show_stack) from [<c0885d1c>] (dump_stack+0xb0/0xe8)
  [<c0885d1c>] (dump_stack) from [<c0889c1c>] (kobject_init+0x78/0x94)
  [<c0889c1c>] (kobject_init) from [<c0596298>] (device_initialize+0x20/0xe4)
  [<c0596298>] (device_initialize) from [<c0598a10>] (device_register+0xc/0x18)
  [<c0598a10>] (device_register) from [<bf000490>] (register_virtio_device+0xd8/0xfc [virtio])
  [<bf000490>] (register_virtio_device [virtio]) from [<bf02a918>] (rproc_add_virtio_dev+0x54/0xb0 [remoteproc])
  [<bf02a918>] (rproc_add_virtio_dev [remoteproc]) from [<bf0275cc>] (rproc_start+0xf4/0x1f4 [remoteproc])
  [<bf0275cc>] (rproc_start [remoteproc]) from [<bf029730>] (rproc_trigger_recovery+0xb0/0xe4 [remoteproc])
  [<bf029730>] (rproc_trigger_recovery [remoteproc]) from [<c0157a78>] (process_one_work+0x28c/0x770)
  [<c0157a78>] (process_one_work) from [<c0157f90>] (worker_thread+0x34/0x58c)
  [<c0157f90>] (worker_thread) from [<c015e8f4>] (kthread+0x138/0x150)
  [<c015e8f4>] (kthread) from [<c01089e8>] (ret_from_fork+0x14/0x2c)
  virtio_rpmsg_bus virtio1: rpmsg host is online
  driver_bound: device virtio1 already bound
  remoteproc remoteproc1: registered virtio1 (type 7)
  remoteproc remoteproc1: remote processor 55020000.ipu is now up
  Unable to handle kernel NULL pointer dereference at virtual address 00000004

Revert the above commit to fix/restore the error recovery functionality.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Fri, 2 Mar 2018 20:16:06 +0000 (14:16 -0600)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that adds the support
for system suspend/resume and runtime auto-suspend/resume support on
the IPU and DSP remote processors on OMAP4, OMAP5 and DRA7 SoCs. The
feature branch merge also pulls in automatically the dependent OMAP
iommu feature branch with suspend/resume support. OMAP mailbox driver
already has the suspend/resume support in upstream 4.14 kernel.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc: Fix sysfs interface to stop a suspended processor
  remoteproc/omap: add support for runtime auto-suspend/resume
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  dt-bindings: remoteproc: Update omap remoteproc binding for suspend
  iommu/omap: introduce new API for runtime suspend/resume control
  iommu/omap: Add system suspend/resume support
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc: Fix sysfs interface to stop a suspended processor
J, KEERTHY [Wed, 15 Feb 2017 11:59:25 +0000 (11:59 +0000)]
remoteproc: Fix sysfs interface to stop a suspended processor

Commit 2aefbef04149 ("remoteproc: Add a sysfs interface for
firmware and state") has added an interface to be able to stop
a remote processor, change the firmware and start the remote
processor using the new firmware through the sysfs files 'state'
and 'firmware'. Any firmware change requires the processor to be
in a stopped state. The logic in 'stop' checks for a valid state
(RPROC_RUNNING) before a processor can be stopped. A booted remote
processor though can also be in RPROC_SUSPENDED state if the driver
controlling the device supports runtime auto-suspend, and any
attempt to stop such a processor throws an error,
"write error: Invalid argument".

It should be possible to stop a processor that is in suspended
state using the sysfs entry, as this is a perfectly functional
scenario when either removing the module, or unbinding the device
from the driver. Fix the sysfs logic to permit the same.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/omap: add support for runtime auto-suspend/resume
Suman Anna [Fri, 2 Mar 2018 03:06:44 +0000 (21:06 -0600)]
remoteproc/omap: add support for runtime auto-suspend/resume

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoremoteproc/omap: add support for system suspend/resume
Suman Anna [Thu, 22 Feb 2018 23:57:17 +0000 (17:57 -0600)]
remoteproc/omap: add support for system suspend/resume

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. These are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are automatically suspended by the PM core during the late
suspend stage, after the remoteproc suspend process is completed by
putting the remote processor cores into reset. Thereafter, the Linux
kernel can put the domain into further lower power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by starting the timers and finally releasing the processors
from reset. This requires that the remote processor side OS be able to
distinguish a power-resume boot from a power-on/cold boot, restore the
context of its private modules saved during the suspend phase, and
resume executing code from where it was suspended. The IOMMUs would
have been resumed by the PM core during early resume, so they are
already enabled by the time remoteproc resume callback gets invoked.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device
is put into. The management of the DDR contents will be managed by
the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA7: Add standby info for IPU & DSPs
Suman Anna [Thu, 14 May 2015 03:32:51 +0000 (22:32 -0500)]
ARM: dts: DRA7: Add standby info for IPU & DSPs

Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP5: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:29:54 +0000 (22:29 -0500)]
ARM: dts: OMAP5: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP4: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:28:56 +0000 (22:28 -0500)]
ARM: dts: OMAP4: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agodt-bindings: remoteproc: Update omap remoteproc binding for suspend
Suman Anna [Thu, 14 May 2015 03:55:25 +0000 (22:55 -0500)]
dt-bindings: remoteproc: Update omap remoteproc binding for suspend

The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Fri, 2 Mar 2018 20:07:32 +0000 (14:07 -0600)]
Merge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.14.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
    - improvements in the OMAP iommu to perform the enabling &
      disabling of the IOMMU from within the runtime pm callbacks
    - system suspend/resume support through late dev_pm_ops
    - two new API that needs to be invoked from the OMAP remoteproc
      driver to runtime suspend/resume the IOMMU
    - locked TLB save & restore logic
    - add needed pdata quirks to all supported IOMMUs

Suspend/resume support in the OMAP mailbox driver is already supported
in baseline upstream kernel.

* 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: introduce new API for runtime suspend/resume control
  iommu/omap: Add system suspend/resume support
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: introduce new API for runtime suspend/resume control
Suman Anna [Thu, 1 Mar 2018 04:09:08 +0000 (22:09 -0600)]
iommu/omap: introduce new API for runtime suspend/resume control

This patch adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by introducing two new API,
omap_iommu_domain_deactivate() and omap_iommu_domain_activate()
to allow the client users/master devices of the IOMMU devices to
deactivate & activate the IOMMU devices from their runtime
suspend/resume operations. There is no API exposed by the IOMMU
layer at present, and so these new API are added directly in the
OMAP IOMMU driver to minimize framework changes.

The API simply decrements and increments the runtime usage count
of the IOMMU devices and let the context be saved/restored using
the existing runtime pm callbacks.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: fix lockdep warnings in virtio rpmsg bus driver rpmsg-linux-4.14.y
Angela Stegmaier [Sat, 4 Mar 2017 22:29:19 +0000 (16:29 -0600)]
rpmsg: fix lockdep warnings in virtio rpmsg bus driver

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

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

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

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

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

1. Recursive locking dependency during RPMSG_NS_DESTROY message processing
 =============================================
 [ INFO: possible recursive locking detected ]
 ---------------------------------------------
 kworker/0:2/960 is trying to acquire lock:
  (&ept->cb_lock){+.+.+.}, at: [<c05f4e80>] __rpmsg_destroy_ept+0x48/0x8c [virtio_rpmsg_bus]

 but task is already holding lock:
  (&ept->cb_lock){+.+.+.}, at: [<c05f486c>] rpmsg_recv_done+0xe4/0x258 [virtio_rpmsg_bus]

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

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

  *** DEADLOCK ***

2. Circular locking dependency during error recovery of rpmsg-rpc driver
 ======================================================
 [ INFO: possible circular locking dependency detected ]
 -------------------------------------------------------
 kworker/0:5/991 is trying to acquire lock:
  (&ept->cb_lock){+.+.+.}, at: [<bf015068>] __rpmsg_destroy_ept+0x40/0x88 [virtio_rpmsg_bus]

 but task is already holding lock:
  (&rppcdev->lock){+.+...}, at: [<bf0226cc>] rppc_remove+0x90/0x22c [rpmsg_rpc]

 which lock already depends on the new lock.
 other info that might help us debug this:

 Chain exists of:
  &ept->cb_lock --> rppc_devices_lock --> &rppcdev->lock

  Possible unsafe locking scenario:
        CPU0                    CPU1
        ----                    ----
   lock(&rppcdev->lock);
                                lock(rppc_devices_lock);
                                lock(&rppcdev->lock);
   lock(&ept->cb_lock);

  *** DEADLOCK ***

3. Circular locking dependency during error recovery of rpmsg-proto driver
 ======================================================
 [ INFO: possible circular locking dependency detected ]
 -------------------------------------------------------
 kworker/0:5/962 is trying to acquire lock:
  (&ept->cb_lock){+.+.+.}, at: [<bf015068>] __rpmsg_destroy_ept+0x40/0x88 [virtio_rpmsg_bus]

 but task is already holding lock:
  (rpmsg_channels_lock){+.+.+.}, at: [<bf01c940>] rpmsg_proto_remove+0x28/0x164 [rpmsg_proto]

 which lock already depends on the new lock.
 other info that might help us debug this:

  Possible unsafe locking scenario:

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

  *** DEADLOCK ***

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: flip the subclass values, rewrite patch description for 4.9]
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agonet/rpmsg: unblock reader threads operating on errored sockets
Suman Anna [Sat, 4 Mar 2017 03:09:28 +0000 (21:09 -0600)]
net/rpmsg: unblock reader threads operating on errored sockets

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agonet/rpmsg: return ENOLINK upon Rx on errored sockets
Suman Anna [Tue, 28 Feb 2017 22:25:52 +0000 (16:25 -0600)]
net/rpmsg: return ENOLINK upon Rx on errored sockets

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agonet/rpmsg: return ESHUTDOWN upon Tx on errored sockets
Suman Anna [Fri, 24 Oct 2014 21:39:49 +0000 (16:39 -0500)]
net/rpmsg: return ESHUTDOWN upon Tx on errored sockets

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agonet/rpmsg: add support to handle a remote processor error recovery
Suman Anna [Sat, 4 Mar 2017 00:40:31 +0000 (18:40 -0600)]
net/rpmsg: add support to handle a remote processor error recovery

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

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

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

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: fix potential memory leak of unprocessed skbs
Suman Anna [Tue, 4 Nov 2014 20:49:06 +0000 (14:49 -0600)]
rpmsg: rpc: fix potential memory leak of unprocessed skbs

A user thread sends a request for a remote function execution
on the remote processor through a write() fop. All the responses
from the remote service are queued using allocated skbs in the
driver's rpmsg callback. The allocated skbs are processed and
freed in a read() fop. An error recovery causes a blocked user
thread to bail out immediately and any in-flight queued skbs
are left unprocessed. These in-flight skbs are never freed and
can result in a memory leak.

Fix the memory leak by checking for the presence of any of these
unprocessed skbs in the read queue, and freeing them during the
file descriptor's release() function. This also ensures no memory
is leaked for user applications with bugs and not using matching
write() and read() fops.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: fix ept memory leak during recovery
Suman Anna [Fri, 31 Oct 2014 23:17:56 +0000 (18:17 -0500)]
rpmsg: rpc: fix ept memory leak during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. An endpoint is created in the open() fops, and forms the
source end-point of a dedicated communication channel to allow an
application to send and receive remote function execution commands/
responses on this service. This endpoint address is a child of the
parent virtio device to which the rpmsg-rpc device belongs to. The
virtio devices are deleted and recreated during a remoteproc crash
and recovery process. The associated child endpoints are not deleted
at present during recovery, and the corresponding release() cannot
delete the end-points if it happens after a recovery as the parent
rpmsg-rpc device has already been removed, thereby resulting in a
memory leak during recovery amidst an active usage.

Fix this by deleting all the epts associated with the parent virtio
device of the corresponding rpmsg-rpc device. This is done during the
rpmsg-rpc driver's .remove() which is invoked during the deletion of
the virtio device.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: use the local device pointer in all file operations
Suman Anna [Fri, 7 Nov 2014 20:14:09 +0000 (14:14 -0600)]
rpmsg: rpc: use the local device pointer in all file operations

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and can become
NULL at any point if an error recovery happens. So, switch to using
the local reference device pointer in all the fop functions for
the exposed character device.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: maintain a reference device pointer per open fd
Suman Anna [Fri, 7 Nov 2014 17:17:13 +0000 (11:17 -0600)]
rpmsg: rpc: maintain a reference device pointer per open fd

The remote processor recovery process includes the deletion and
recreation of an rpmsg-rpc device. The representative rppc_device
structure is retained and reused if there are any open applications
using the exposed character device. The underlying device pointer
for a rppc_device is though deleted and recreated and is asynchronous
to any of the operations on the exposed character device. A reference
to this device pointer is to be maintained therefore for each open
application so that it can be used during regular fops and until the
file descriptor is closed instead of referencing the rppc_device's
dev pointer, which can become NULL at any point due to a recovery
process. The actual memory of the rppc_device's dev pointer deleted
in the driver's .remove() is freed when all the open applications
have closed either gracefully or forcefully. Any new applications
after a recovery will leverage a newly created device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: fix sysfs entry creation failures during recovery
Suman Anna [Sat, 1 Nov 2014 00:28:53 +0000 (19:28 -0500)]
rpmsg: rpc: fix sysfs entry creation failures during recovery

The rpmsg-rpc driver exposes a character device for each remote
service (a rpmsg-rpc device) providing a bunch of remote execution
functions. The remote service can be running on any of the available
remote processors, and the supported functions are published as
different sysfs entries on that particular device. These rpmsg-rpc
devices are deleted and recreated as part of the reboot of the remote
processor during an error recovery. The sysfs entries are also deleted
and recreated. The current logic retains the associated rppc_device
structure and the underlying device pointer if there are any
applications actively using the character device at the time of the
rpmsg-rpc device removal, and reuses it upon the reprobe of the same
rpmsg-rpc device. The creation of the sysfs entries fails with -ENOENT
due to an invalid reference to a non-existing parent object, and this
is exposed first in 3.14 kernel due to the repartitioning of the core
sysfs code into a new common kernfs code.

Fix this by deleting the underlying device pointer in the driver's
.remove, and recreating it with the appropriate new rpmsg server
device as its parent in the driver's .probe function. A name
description field is also added to the representative rppc_device
structure for looking up the service on reprobe as the device name
cannot be used due to the deletion of the device pointer.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agorpmsg: rpc: fix potential out-of-bounds array access
Suman Anna [Thu, 1 Mar 2018 01:39:17 +0000 (19:39 -0600)]
rpmsg: rpc: fix potential out-of-bounds array access

The sanity check for translation elements in rppc_xlate_buffers()
function initializes some local variables using an array index
variable prior to checking the validity of the index itself. This
can result in an out-of-bounds array access failure. Fix this by
initializing the variables after checking the array index value.

Fixes: 77e1bc79478b ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 28 Feb 2018 22:03:15 +0000 (16:03 -0600)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue, and couple
of fixes for idle support on the DSP remote processors on DRA7xx
family of SoCs.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
  ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
  ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
  ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Wed, 28 Feb 2018 21:47:48 +0000 (15:47 -0600)]
Merge branch 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-4.14.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue and
couple of DRA7 DSP idle issues with HW_AUTO setting. Also included
is a fix for errata i879.

* 'iommu-linux-4.14.y' of git://git.ti.com/rpmsg/iommu:
  ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
  ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
  ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoMerge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Wed, 28 Feb 2018 20:09:15 +0000 (14:09 -0600)]
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y

Pull in the remoteproc feature branch supporting the boot of all DSP and
IPU remote processors on OMAP4, OMAP5 and various DRA7xx/AM57xx SoCs. The
feature branch also pulls in automatically the dependent iommu feature
tree with DRA7 support into the rpmsg-ti-linux-4.14.y RPMsg integration
branch. OMAP mailbox is fully upstream in vanilla 4.14 kernel, but the
mailbox feature tree merge pulls in couple of minor fixes.

The merge also pulls in the latest platform base tree into the RPMsg
integration branch. The merge brings in support for couple of new boards
and the OMAP DMTimer driver conversion to a Clocksource driver. The
defconfig map file is updated with the proper conflict resolutions
during the merge.

The supported functional features in OMAP remoteproc include:
 - Device Tree based support for device-specific carveouts and CMA pools
 - Boot of device-tree based IPU and DSP remoteproc devices
 - Internal memory loading support on DSPs
 - BIOS Tick timer support using relocated OMAP DMTimer clocksource code
 - Cleanup of legacy platform device based code

Supported platforms include OMAP4 Pandaboard, OMAP5 uEVM, DRA7 EVMs,
DRA76 EVM, both DRA72 rev.B and rev.C EVMs, DRA71 EVM, all AM57xx
BeagleBoard-X15 boards and their derivative boards, AM572x IDK, AM571x
IDK and AM574x IDK boards. The IVA and DSP remote processors will be
running at OPP_NOM clock frequencies by default, and at OPP_HIGH with
the appropriate U-Boot on boards/SoCs that can support them (DRA71 only
supports OPP_NOM).

There are couple of issues with the booting of the IPU1 remote processor,
and having the DSPs entering low-power mode/losing context with HW_AUTO
setting consistently on all platforms, and this will be resolved in a
subsequent pull.

* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc: (240 commits)
  ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs
  ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs
  ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes
  ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files
  ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x
  ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7
  ARM: DRA7: hwmod_data: add data for DSP2 processor
  ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs
  ARM: dts: DRA72x: Add aliases for rproc nodes
  ARM: dts: DRA74x: Add aliases for rproc nodes
  ARM: dts: DRA74x: Add DSP2 processor device node
  ARM: dts: DRA7: Add common IPU and DSP nodes
  ARM: dts: omap5-uevm: Add system timers to DSP and IPU
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: Add system suspend/resume support
Suman Anna [Mon, 25 Jan 2016 21:27:44 +0000 (15:27 -0600)]
iommu/omap: Add system suspend/resume support

The MMU registers for the remote processors lose their context
in Open Switch Retention (OSWR) or device OFF modes. Hence, the
context of the IOMMU needs to be saved before it is put into any
of these lower power state (OSWR/OFF) and restored before it is
powered up to ON again. The IOMMUs need to be active as long as
the client devices that are present behind the IOMMU are active.

This patch adds the dev_pm_ops callbacks to provide the system
suspend/resume functionality through the appropriate runtime
PM callbacks. The PM runtime_resume and runtime_suspend callbacks
are already used to enable, configure and disable the IOMMUs during
the attaching and detaching of the client devices to the IOMMUs,
and the new PM callbacks reuse the same code by invoking the
pm_runtime_force_suspend() and pm_runtime_force_resume() API. The
functionality in dev_pm_ops .prepare() checks if the IOMMU device
was already runtime suspended, and skips invoking the suspend/resume
PM callbacks. The suspend/resume PM callbacks are plugged in through
the 'late' pm ops to ensure that the IOMMU devices will be suspended
only after its master devices (remoteproc devices) are suspended and
restored before them.

NOTE:
There are two other existing API, omap_iommu_save_ctx() and
omap_iommu_restore_ctx(). These are left as is to support
suspend/resume of devices on legacy OMAP3 SoC.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: add logic to save/restore locked TLBs
Suman Anna [Tue, 12 May 2015 21:52:59 +0000 (16:52 -0500)]
iommu/omap: add logic to save/restore locked TLBs

The MMUs provide a mechanism to lock TLB entries to avoid
eviction and fetching of frequently used page table entries.
These TLBs lose context when the MMUs are turned OFF. Add the
logic to save and restore these locked TLBS during suspend
and resume respectively. There are no locked TLBs during
initial power ON, and they need not be saved during final
shutdown.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: streamline enable/disable through runtime pm callbacks
Suman Anna [Fri, 18 Dec 2015 00:24:24 +0000 (18:24 -0600)]
iommu/omap: streamline enable/disable through runtime pm callbacks

The OMAP IOMMU devices are typically present within the respective
client processor subsystem and have their own dedicated hard-reset
line. Enabling an IOMMU requires the reset line to be deasserted
and the clocks to be enabled before programming the necessary IOMMU
registers. The IOMMU disable sequence follow the reverse order of
enabling. The OMAP IOMMU driver programs the reset lines through
pdata ops to invoke the omap_device_assert/deassert_hardreset API.
The clocks are managed through the pm_runtime framework, and the
callbacks associated with the device's pm_domain, implemented in
the omap_device layer.

Streamline the enable and disable sequences in the OMAP IOMMU
driver by implementing all the above operations within the
runtime pm callbacks. All the OMAP devices have device pm_domain
callbacks plugged in the omap_device layer for automatic runtime
management of the clocks. Invoking the reset management functions
within the runtime pm callbacks in OMAP IOMMU driver therefore
requires that the default device's pm domain callbacks in the
omap_device layer be reset, as the ordering sequence for managing
the reset lines and clocks from the pm_domain callbacks don't gel
well with the implementation in the IOMMU driver callbacks. The
omap_device_enable/omap_device_idle functions are invoked through
the newly added pdata ops.

Consolidating all the device management sequences within the
runtime pm callbacks allows the driver to easily support both
system suspend/resume and runtime suspend/resume using common
code.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
Suman Anna [Fri, 15 May 2015 04:40:26 +0000 (23:40 -0500)]
ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU

The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata. The OMAP IOMMU driver now requires the platform
data ops for device_enable/idle on all the IOMMU devices to be
able to enable/disable the clocks and maintain the reference
count and the omap_hwmod state machine. So, add the iommu pdata
quirks for the OMAP3 ISP IOMMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
Suman Anna [Fri, 15 May 2015 16:00:35 +0000 (11:00 -0500)]
ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs

The DSP processor subsystems in DRA7xx have two MMUs, one for the
processor port and another for an EDMA port. Both these MMUs share
a common reset line, and the reset management is done through the
pdata quirks for the MMU associated with the processor port, so the
DSP EDMA MMUs didn't need any pdata ops. The OMAP IOMMU driver now
requires the device_enable/idle platform data ops on all the IOMMU
devices to be able to enable/disable the clocks and maintain the
reference count and the omap_hwmod state machine. So, add the iommu
pdata quirks for the DSP EDMA MMUs.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
Suman Anna [Fri, 18 Dec 2015 00:29:45 +0000 (18:29 -0600)]
ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs

The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks. Plug in these pdata ops for all the existing IOMMUs
through pdata quirks.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: add pdata ops for omap_device_enable/idle
Suman Anna [Mon, 27 Apr 2015 22:26:21 +0000 (17:26 -0500)]
iommu/omap: add pdata ops for omap_device_enable/idle

Add two new platform data ops to allow the OMAP iommu driver to
be able to invoke the omap_device_enable and omap_device_idle
from within the driver. These are being added to streamline the
sequence between managing the hard reset lines and the clocks
during the suspend path, as the default device pm_domain callback
sequences in omap_device layer are not conducive for the OMAP
IOMMU driver.

This could have been done by expanding the existing pdata ops
for reset management (like in the OMAP remoteproc driver), but
this was chosen to avoid adding additional code in the separate
file in the mach-omap2 layer.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
Suman Anna [Thu, 20 Aug 2015 22:58:25 +0000 (17:58 -0500)]
ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879

Errata Title:
i879: DSP MStandby requires CD_EMU in SW_WKUP

Description:
The DSP requires the internal emulation clock to be actively toggling
in order to successfully enter a low power mode via execution of the
IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
other prerequisites and software sequence are followed.

Workaround:
The emulation clock to the DSP is free-running anytime CCS is connected
via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.

Implementation:
This patch implements this workaround by denying the HW_AUTO mode
for the EMU clockdomain during the power-up of any DSP processor
and re-enabling the HW_AUTO mode during the shutdown of the last
DSP processor (actually done during the enabling and disabling of
the respective DSP MDMA MMUs). Reference counting has to be used to
manage the independent sequencing between the multiple DSP processors.

This switching is done at runtime rather than a static clockdomain
flags value to meet the target power domain state for the EMU power
domain during suspend.

Note that the DSP MStandby behavior is not consistent across all
boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
details.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs
Suman Anna [Wed, 28 Feb 2018 04:07:05 +0000 (22:07 -0600)]
ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs

The C66-based DSPs on DRA7xx SoCs do not support a Powerdown-RET
mode, and only supports a Powerdown-Grid OFF mode which requires
a boot from reset. The HW_AUTO setting and a target power domain
state of OFF implies that the DSPs are powered off as soon as
they are idled by executing an IDLE instruction. The DSPs lose
their context as a result and will be unable to resume operations
from any wakeup event.

The DSP power domains therefore need to be restricted to ON state
for the duration a DSP processor is actively running. This is
similar to the restriction required for DRA7 IPU1 processor (albeit
because of a different reason). The IPU1 behavior is handled in
commit e978c8eba906 ("ARM: OMAP2+: use separate IOMMU pdata to fix
DRA7 IPU1 boot") which adds a .set_pwrdm_constraint ops to the OMAP
IOMMU platform data to restrict the IPU1 power domain to ON state
during the active period of the IPU1 remote processor.

Extend the IPU1 iommu pdata quirks to the DRA7 MDMA MMUs as well
to restrict the DSP power domains to ON state. The MDMA MMU module
configuration will be the first and last steps in the boot and
shutdown sequences of the DSP processors. The existing IPU1 IOMMU
pdata variable has also been renamed appropriately to reflect the
common usage between the IPU1 and the DSPs.

NOTE:
1. This patch is needed on 4.14 kernel for slightly different reasons
   due to difference in behavior between 4.14 kernel and 4.9 kernel.
   The DSP1 and DSP2 power domains are programmed for OFF target
   power state, and the power domain wakeup transition is automatic
   on any clock domain wakeup event. The DSP power domains are getting
   turned ON automatically on 4.14 kernel, but are not returned to
   OFF mode before this patch. This patch fixes this power-down issue
   by specifically programming the OFF state during the remoteproc
   shutdown. The difference in behavior is attributed to the small
   differences in commit f7b0b1e6b00a ("ARM: DRA7: hwmod data: Add
   MMU data for DSPs") on the second MMU hwmod data for each DSP.
2. This patch is also needed to preserve the DSP contexts when proper
   clock-gating is achieved during inactive periods. DSP power domains
   on these platforms should not be hitting OFF at the moment (even
   with firmware images executing an IDLE instruction) because of the
   issue described in errata i879 ("DSP MStandby requires CD_EMU in
   SW_WKUP") affecting these SoCs. The i879 errata fix in the following
   patch achieves the DSP clock-gating with HW_AUTO mode, and would
   also result in a power domain sleep transition to OFF mode without
   any software context save mechanism.
3. The functional behavior had also been inconsistent between different
   DRA74x and DRA72x SoCs and silicon revisions prior to this patch.
   DSP1 on DRA7 EVM rev.H (DRA752 ES2.0) and AM571x IDK (DRA722 ES2.0)
   boards is entering idle mode without any fix, but none of the other
   boards exhibit this behavior. They remained functional due to the
   behavioral difference in #1 on 4.14 kernel, but not on 4.9 kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
Suman Anna [Fri, 18 Mar 2016 00:20:32 +0000 (19:20 -0500)]
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot

The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in commit afe518400bdb ("iommu/omap: fix boot issue on
remoteprocs with AMMU/Unicache").

NOTE:
1. RET is not a valid target power domain state on DRA7 platforms,
   and IPU power domain is normally programmed for OFF. The IPU1
   still fails to boot though, and an unclearable l3_noc error is
   thrown currently on 4.14 kernel without this fix. This behavior
   is slightly different from previous 4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
   other affected processors on OMAP4/OMAP5/DRA7 are in domains
   that are not entering RET. IPU2 on DRA7 is in CORE power domain
   which is only programmed for ON power state. The fix can be easily
   scaled if these domains do hit RET in the future.
3. The issue was not seen on current DRA7 platforms if any of the
   DSP remote processors were booted and using one of the GPTimers
   5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
   errata fix for i874 implemented in commit 1cbabcb9807e ("ARM:
   DRA7: clockdomain: Implement timer workaround for errata i874")
   which keeps the IPU1 power domain from entering RET when the
   timers are active. But the timer workaround did not make any
   difference on 4.14 kernel, and an l3_noc error was seen still
   without this fix.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoiommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
Suman Anna [Thu, 10 Mar 2016 23:18:02 +0000 (17:18 -0600)]
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache

Support has been added to the OMAP IOMMU driver to fix a boot hang
issue on OMAP remoteprocs with AMMU/Unicache, caused by an improper
AMMU/Unicache state upon initial deassertion of the processor reset.
The issue is described in detail in the next three paragraphs.

All the Cortex M3/M4 IPU processor subsystems in OMAP SoCs have a
AMMU/Unicache IP that dictates the memory attributes for addresses
seen by the processor cores. The AMMU/Unicache is configured/enabled
by the SCACHE_CONFIG.BYPASS bit - a value of 1 enables the cache and
mandates all addresses accessed by M3/M4 be defined in the AMMU. This
bit is not programmable from the host processor. The M3/M4 boot
sequence starts out with the AMMU/Unicache in disabled state, and
SYS/BIOS programs the AMMU regions and enables the Unicache during
one of its initial boot steps. This SCACHE_CONFIG.BYPASS bit is
however enabled by default whenever a RET reset is applied to the IP,
irrespective of whether it was previously enabled or not. The AMMU
registers lose their context whenever this reset is applied. The reset
is effective as long as the MMU portion of the subsystem is enabled
and clocked. This behavior is common to all the IPU and DSP subsystems
that have an AMMU/Unicache.

The IPU boot sequence involves enabling and programming the MMU, and
loading the processor and releasing the reset(s) for the processor.
The PM setup code currently sets the target state for most of the
power domains to RET. The L2 MMU can be enabled, programmed and
accessed properly just fine with the domain in hardware supervised
mode, while the power domain goes through a RET->ON->RET transition
during the programming sequence. However, the ON->RET transition
asserts a RET reset, and the SCACHE_CONFIG.BYPASS bit gets auto-set.
An AMMU fault is thrown immediately when the M3/M4 core's reset is
released since the first instruction address itself will not be
defined in any valid AMMU regions. The ON->RET transition happens
automatically on the power domain after enabling the iommu due to
the hardware supervised mode.

This patch adds and invokes the .set_pwrdm_constraint pdata ops, if
present, during the OMAP IOMMU enable and disable functions to resolve
the above boot hang issue. The ops will allow to invoke a mach-omap2
layer API pwrdm_set_next_pwrst() in a multi-arch kernel environment.
The ops also returns the current power domain state while enforcing
the constraint so that the driver can store it and use it to set back
the power domain state while releasing the constraint. The pdata ops
implementation restricts the target power domain to ON during enable,
and back to the original power domain state during disable, and thereby
eliminating the conditions for the boot issue. The implementation is
effective only when the original power domain state is either RET or
OFF, and is a no-op when it is ON or INACTIVE.

The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.

Note that the current issue is seen only on kernels with the affected
power domains programmed to enter RET. For eg., IPU1 on DRA7xx is in a
separate domain and is susceptible to this bug, while the IPU2 subsystem
is within CORE power domain, and CORE RET is not supported on this SoC.
IPUs on OMAP4 and OMAP5 are also susceptible since they are in CORE power
domain, and CORE RET is a valid power target on these SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs
Suman Anna [Thu, 22 Feb 2018 17:41:11 +0000 (11:41 -0600)]
ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on the AM571x IDK board. These nodes are assigned
to the respective rproc device nodes, and both the IPUs and the DSP1
remote processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs
Suman Anna [Thu, 22 Feb 2018 17:38:23 +0000 (11:38 -0600)]
ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices in the am572x-idk-common.dtsi file that is common to
both the AM572x and AM574x IDK boards. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on
the AM57xx EVM board to maintain firmware compatibility between the
two boards. The CMA pools and sizes are defined using 64-bit values
to support LPAE. The starting addresses are fixed to meet current
dependencies on the remote processor firmwares, and this will go
away when the remote-side code has been improved to gather this
information runtime during its initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs
Suman Anna [Thu, 22 Feb 2018 17:49:32 +0000 (11:49 -0600)]
ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on all the AM57xx BeagleBoard-X15 boards. These nodes
are assigned to the respective rproc device nodes, and all the IPU and
DSP remote processors are enabled for all these boards.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs
Suman Anna [Fri, 18 Aug 2017 21:08:22 +0000 (16:08 -0500)]
ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and
the DSP remoteproc devices on the DRA76 EVM board, and assigned to
the respective rproc device nodes. These match the configuration
used on the DRA7 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA76 EVM board.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs
Suman Anna [Wed, 6 Sep 2017 19:07:12 +0000 (14:07 -0500)]
ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA71 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA72 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs
Suman Anna [Thu, 31 Mar 2016 19:54:28 +0000 (14:54 -0500)]
ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and
the DSP1 remoteproc devices on the DRA72 EVM rev C board, and assigned
to the respective rproc device nodes. These match the configuration
used on the DRA72 EVM board. Both the CMA nodes and the corresponding
rproc nodes are also enabled to enable these processors on the
DRA72 EVM rev C board.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs
Suman Anna [Thu, 17 Mar 2016 04:14:57 +0000 (23:14 -0500)]
ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocs

The CMA reserved memory nodes have been added for both the IPUs and the
DSP1 remoteproc devices on DRA72 EVM board. These nodes are assigned to
the respective rproc device nodes, and both the IPUs and the DSP1 remote
processors are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The addresses chosen are the same as the respective processors on the
DRA7 EVM board to maintain firmware compatibility between the two boards.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs
Suman Anna [Thu, 22 Feb 2018 16:47:49 +0000 (10:47 -0600)]
ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocs

The CMA reserved memory nodes have been added for all the IPU and DSP
remoteproc devices on DRA7 EVM board. These nodes are assigned to the
respective rproc device nodes, and all the IPU and DSP remote processors
are enabled for this board.

The current CMA pools and sizes are defined statically for each device.
The CMA pools and sizes are defined using 64-bit values to support LPAE.
The starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and this will go away when the remote-side
code has been improved to gather this information runtime during its
initialization.

An associated pair of the rproc node and its CMA node can be disabled
later on if there is no use-case defined to use that remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes
Suman Anna [Sat, 24 Feb 2018 01:51:06 +0000 (19:51 -0600)]
ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodes

The BIOS System Tick timers have been added for all the IPU and
DSP remoteproc devices in the DRA7 SoC family. The data is added
to the two common dra7-ipu-dsp-common and dra74-ipu-dsp-common
dtsi files that are included by all the desired board files. The
following timers are chosen, as per the timers used on the current
firmware images:
        IPU2: GPTimer 3
        IPU1: GPTimer 11
        DSP1: GPTimer 5
        DSP2: GPTimer 6

The timers are optional, but are mandatory to support advanced device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, if needed.

Each of the IPUs has two Cortex-M4 processors, and is currently
expected to be running in SMP-mode, so only a single timer suffices
to provide the BIOS tick timer. An additional timer should be added
for the second processor in IPU if it were to be run in non-SMP mode.
The timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes
Suman Anna [Sat, 24 Feb 2018 01:34:40 +0000 (19:34 -0600)]
ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodes

Add the required 'mboxes' property to all the IPU and DSP remote
processors (IPU1, IPU2, DSP1 and DSP2) in the two available common
dtsi files - dra7-ipu-dsp-common and dra74-ipu-dsp-common dtsi files.
The latter file is for platforms having DRA74x/DRA76x/AM572x/AM574x
SoCs which do have a DSP2 processor in addition to the other common
remote processors. The common data is added to the former file, and
the DSP2 only data is added to the latter file.

The mailboxes are required for running the Remote Processor Messaging
(RPMsg) stack between the host processor and each of the remote
processors. Each of the remote processors uses a single sub-mailbox
node, the IPUs are assumed to be running in SMP-mode. The chosen
sub-mailboxes match the values used in the current firmware images.
This can be changed, if needed, as per the system integration needs
after making appropriate changes on the firmware side as well.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files
Suman Anna [Fri, 23 Feb 2018 23:21:58 +0000 (17:21 -0600)]
ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common files

The System Mailboxes 5 and 6 and their corresponding child sub-mailbox
(IPC 3.x) nodes are enabled in each of the DRA7xx and AM57xx board
dts files individually at present. These mailboxes enable the Remote
Processor Messaging (RPMsg) communication stack between the MPU host
processor and each of the IPU1, IPU2, DSP1 and DSP2 remote processors.

Move these nodes into two common dtsi files - dra7-ipu-dsp-common and
dra74-ipu-dsp-common files, which are then included in various board
dts files. These files can be used to add all the common configuration
properties (except memory data) required by remote processor nodes.
The memory pools and the remote processor nodes themselves are to be
enabled in the actual board dts files. The first file is to used by
platforms using DRA72x/DRA71x/AM571x/AM570x SoCs, and the second file
is to be used by platforms using DRA74x/DRA76x/AM572x/AM574x SoCs.
The second file includes the first file and contains additional data
only applicable for DSP2 remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x
Suman Anna [Wed, 16 Mar 2016 19:49:57 +0000 (14:49 -0500)]
ARM: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74x

The pdata quirks for the DSP2 remote processor device, present
usually on DRA74x SoCs, has been added. The DSP2 remote processor
is another identical instance as the DSP1 remote processor, and
the required quirks are identical to the rest of the remote
processors on DRA7xx.

The pdata quirks will be removed once the dependencies against
the arch/arm layers are resolved.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7
Suman Anna [Wed, 16 Mar 2016 19:49:18 +0000 (14:49 -0500)]
ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7

The remote processors on DRA7xx requires similar device management
pdata-quirks (reset control, clocking, dmtimer API wrappers for
enabling both system and watchdog timers) as the IPU and DSP
processors on OMAP4/OMAP5. All these pdata ops are identical to
the ones used on OMAP4/OMAP5, so extend the existing rproc pdata
quirks to the most common remote processor subsystems on DRA7xx
family of SoCs - IPU1, IPU2 and DSP1.

The pdata quirks need to match the starting address in the auxdata
for the respective processors, as the same compatible string is used
for all the instances of the remote processor of the same type. The
pdata quirks will be removed once the dependencies against arch/arm
layers are resolved.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: DRA7: hwmod_data: add data for DSP2 processor
Suman Anna [Fri, 28 Jun 2013 00:10:37 +0000 (17:10 -0700)]
ARM: DRA7: hwmod_data: add data for DSP2 processor

The DRA7xx family of SoCs can have up to two identical DSP
processor subsystems, with most of them having a single DSP
processor subsystem. The second DSP is present only on DRA74x
variants currently. The relevant hwmod class and data structures
are added for this second DSP only for DRA74x SoC variants.
The hwmod data for this DSP2 is very similar to the data on
DSP1.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs
Suman Anna [Fri, 28 Jun 2013 00:10:37 +0000 (17:10 -0700)]
ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocs

The DRA7xx family of SoCs usually have two IPU and up to two DSP
remote processor subsystems. These subsystems are very similar to
the respective processor subsystems on OMAP4/OMAP5 in terms of clock
and reset integration. The relevant hwmod classes and data structures
are added for IPU1, IPU2 and DSP1 remoteproc devices, the most common
processors present on all DRA7xx SoCs.

Do note that these hwmod data structures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA72x: Add aliases for rproc nodes
Suman Anna [Mon, 11 Aug 2014 22:16:52 +0000 (17:16 -0500)]
ARM: dts: DRA72x: Add aliases for rproc nodes

Add aliases for all the 3 remote processor nodes common to
all DRA72x/DRA71x/AM571x/AM570x boards. The aliases uses the
stem "rproc", and are defined in the order of the most common
processors on the DRA72x family. The ids are same as DRA74x
except for the missing DSP2.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA74x: Add aliases for rproc nodes
Suman Anna [Thu, 7 Aug 2014 22:55:44 +0000 (17:55 -0500)]
ARM: dts: DRA74x: Add aliases for rproc nodes

Add aliases for all the IPU and DSP remoteproc processor
nodes common to all DRA74x/DRA76x/AM572x/AM574x boards.
The aliases uses the stem "rproc". The aliases are defined
in the order of the most common processors on the DRA74x
family.

The aliases can be overridden, if needed, in the respective
derivative board dts files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA74x: Add DSP2 processor device node
Suman Anna [Wed, 16 Mar 2016 19:47:28 +0000 (14:47 -0500)]
ARM: dts: DRA74x: Add DSP2 processor device node

The DRA7xx family of SoCs can contain upto two identical DSP
processor subsystems. The second DSP processor subsystem is
present only on the DRA74x/DRA76x variants. The processor
device DT node has therefore been added in disabled state for
this processor subsystem in the DRA74x specific DTS file.

NOTE:
1. The node does not have any mailboxes, timers or CMA region
   assigned, they should be added in the respective board dts
   files.
2. The node should also be enabled as per the individual product
   configuration in the corresponding board dts files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: DRA7: Add common IPU and DSP nodes
Suman Anna [Wed, 16 Mar 2016 19:46:47 +0000 (14:46 -0500)]
ARM: dts: DRA7: Add common IPU and DSP nodes

The DRA7xx family of SOCs have two IPUs and upto two DSP
processor subsystems in general. The IPU processor subsystem
contains dual-core ARM Cortex-M4 processors, while the DSP
processor subsystem is based on the TI's standard TMS320C66x
DSP CorePac core. The IPUs are very similar to those on OMAP5.

Two IPUs and one DSP processor subsystems is the most common
configuration. The processor device DT nodes have been added
for these processor subsystems, with the internal memories
added through 'reg' and 'reg-names' properties. The IPUs only
have an L2 RAM, whereas the DSPs have L1P, L1D and L2 RAM
memories.

NOTE:
1. The nodes do not have any mailboxes, timers or CMA regions
   assigned, they should be added in the respective board dts
   files.
2. The nodes haven been disabled by default and the enabling
   of these nodes is also left to the respective board dts
   files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap5-uevm: Add system timers to DSP and IPU
Suman Anna [Mon, 4 Aug 2014 21:00:04 +0000 (16:00 -0500)]
ARM: dts: omap5-uevm: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices for the OMAP5 uEVM boards. The following timers
(same as the timers on OMAP4 Panda boards) are chosen:
        IPU : GPT3 (SMP-mode)
        DSP : GPT5

IPU has two Cortex-M4 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap5-uevm: Enable IPU & DSP CMA and rproc nodes
Suman Anna [Fri, 7 Aug 2015 03:02:03 +0000 (22:02 -0500)]
ARM: dts: omap5-uevm: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for the OMAP5 uEVM board.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap5-uevm: Add CMA reserved memory nodes for rprocs
Suman Anna [Wed, 6 Sep 2017 18:46:16 +0000 (13:46 -0500)]
ARM: dts: omap5-uevm: Add CMA reserved memory nodes for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on OMAP5 uEVM board. The current CMA pools and
sizes are defined statically for each device. The starting addresses
are fixed to meet current dependencies on the remote processor
firmwares, and will go away when the remote-side code has been
improved to gather this information runtime during its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Extend OMAP4 IPU/DSP pdata-quirks to OMAP5
Suman Anna [Thu, 17 Mar 2016 00:10:43 +0000 (19:10 -0500)]
ARM: OMAP2+: Extend OMAP4 IPU/DSP pdata-quirks to OMAP5

OMAP5 requires the same device management pdata-quirks as OMAP4
for the IPU and DSP processor subsystems, so extend the OMAP4 IPU
and DSP pdata quirks to OMAP5 as well.

The pdata quirks uses the appropriate starting addresses in the
auxdata as per the current DT node definitions to find the devices
to add the necessary quirks as platform data. The pdata quirks will
be removed once the reset dependencies against omap_device and
omap_hwmod layers are resolved.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP5: hwmod_data: add data for IPU & DSP processors
Suman Anna [Mon, 25 Nov 2013 17:53:43 +0000 (11:53 -0600)]
ARM: OMAP5: hwmod_data: add data for IPU & DSP processors

OMAP5, like OMAP4, also has an IPU and a DSP processor subsystems.
The relevant hwmod classes and data structures are added for these
devices.

Do note that these hwmod data strucutures do not have a .modulemode
field as the devices are managed together with their corresponding
MMUs. Each of the processor subsystem and its MMU are present within
the same clock domain and requires the domain be clocked and enabled
until the last entity is disabled. The module is disabled properly
during the omap_device_idle processing of the MMU hwmod while
disabling the MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP5: Add aliases for rproc nodes
Suman Anna [Sat, 9 Aug 2014 02:32:49 +0000 (21:32 -0500)]
ARM: dts: OMAP5: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP5 boards. The aliases uses
the stem "rproc", and are identical to the values
chosen on OMAP4 boards.

The aliases can be overridden, if needed, in the
respective board files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP5: Add DSP and IPU nodes
Suman Anna [Thu, 17 Mar 2016 00:06:52 +0000 (19:06 -0500)]
ARM: dts: OMAP5: Add DSP and IPU nodes

OMAP5, like OMAP4, also has two remote processor subsystems,
DSP and IPU. The IPU subsystem though has dual Cortex-M4
processors instead of the dual Cortex-M3 processors in OMAP4,
but otherwise has almost the same set of features. Add the
DT nodes for these two processor sub-systems for all OMAP5
SoCs.

The nodes have the 'iommus' and 'mboxes' properties added,
and are disabled for now. The IPU node has its L2 RAM memory
specified through the 'reg' and 'reg-names' properties. The
DSP node doesn't have these since it doesn't have any L2
RAM memories, but has an additional 'syscon-bootreg' property
instead as it has a specific boot register that needs to be
programmed for booting.

These nodes should be enabled as per the individual product
configuration in the corresponding board dts files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP4: hwmod_data: remove modulemode from IPU/DSP hwmods
Suman Anna [Fri, 27 Jun 2014 22:52:22 +0000 (17:52 -0500)]
ARM: OMAP4: hwmod_data: remove modulemode from IPU/DSP hwmods

The .modulemode field is removed from both the IPU and DSP processor
hwmods. This fixes a kernel crash during the shutdown sequence of any
of these remoteproc devices, either during a normal teardown or during
a recovery.

The DSP and IPU processor subsystems are represented by multiple hwmods
- one for each of the MMUs present within the subsystem, and one for
the processor cores. The processor subsystem is clocked from a single
clock source with separate reset lines for each of the processors and
the MMUs. This clock and reset information is represented in separate
hwmods to allow the management of these entities in different drivers
operating on the corresponding platform devices. This doesn't fit quite
well into the current omap_hwmod layer due to these inter-dependencies.

A remoteproc startup sequence involves enabling and programming of
the MMUs, loading of the firmware into RAM mapped by the MMUs, and
releasing the processors from reset. A shutdown sequence follows a
reverse pattern with the processors put into reset first followed by
the unmapping and disabling of the MMUs. Both the processors and the
MMUs are present within a single clock domain and requires the domain
be clocked and enabled until the last entity. The kernel crash is
caused during the unmapping phase of the MMUs, as the hwmod layer
disables the module during the omap_device_idle processing of the
processor hwmod. This issue is fixed by not defining a modulemode
for the IPU/DSP processors, which results in keeping the module in
an activated state. The module is disabled properly during the
omap_device_idle processing of the MMU hwmod while disabling the
MMU.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap4-panda-common:: Add system timers to DSP and IPU
Suman Anna [Mon, 4 Aug 2014 20:58:58 +0000 (15:58 -0500)]
ARM: dts: omap4-panda-common:: Add system timers to DSP and IPU

The BIOS System Tick timers have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. The
following DMTimers are chosen:
IPU : GPT3 (SMP-mode)
DSP : GPT5

IPU has two Cortex-M3 processors, and is currently expected to be
running in SMP-mode, so only a single timer suffices to provide
the BIOS tick timer. An additional timer should be added for the
second processor in IPU if it were to be run in non-SMP mode. The
timer value also needs to be unique from the ones used by other
processors so that they can be run simultaneously.

The timers are optional, but are mandatory to support device
management features such as power management and watchdog support.
The above are added to successfully boot and execute firmware images
configured with the respective timers, images that use internal
processor subsystem timers are not affected. The timers can be
changed or removed as per the system integration needs, alongside
equivalent changes on the firmware side.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap4-panda-common: Enable IPU & DSP CMA and rproc nodes
Suman Anna [Fri, 7 Aug 2015 02:52:44 +0000 (21:52 -0500)]
ARM: dts: omap4-panda-common: Enable IPU & DSP CMA and rproc nodes

The IPU and DSP remote processor nodes and their associated
CMA pool nodes were previously disabled. The remote processor
nodes are enabled along with their corresponding CMA reserved
memory nodes for all the OMAP4-based Panda boards.

An associated pair of the rproc node and its CMA node can be
disabled later on if there is no use-case defined to use that
remote processor.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: omap4-panda-common: Add CMA reserved pools for rprocs
Suman Anna [Fri, 7 Aug 2015 02:50:47 +0000 (21:50 -0500)]
ARM: dts: omap4-panda-common: Add CMA reserved pools for rprocs

The CMA reserved memory nodes have been added for the IPU and DSP
remoteproc devices on all the OMAP4-based Panda boards. The current
CMA pools and sizes are defined statically for each device. The
starting addresses are fixed to meet current dependencies on the
remote processor firmwares, and will go away when the remote-side
code has been improved to gather this information runtime during
its initialization.

The nodes are assigned to the respective rproc device nodes, but are
disabled so that they are not created unnecessarily without enabling
the corresponding rproc devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: OMAP2+: Add pdata-quirks for DSP and IPU remoteprocs
Suman Anna [Wed, 16 Mar 2016 23:57:28 +0000 (18:57 -0500)]
ARM: OMAP2+: Add pdata-quirks for DSP and IPU remoteprocs

The OMAP remoteproc driver performs the device management (reset
control and clocking) for the remote processor sub-systems using
the omap_device API which are limited to only the mach-omap layer.
The OMAP mechanism of using pm_runtime API to achieve this is
insufficient as these devices have hard reset lines which are
managed separately. Use pdata quirks to manage the device reset
and clocking functionality through platform data ops, until the
reset portions are decoupled from omap_hwmod/omap_device into a
separate reset driver.

This patch adds the pdata quirks for both the DSP and IPU processor
subsystems on OMAP4, matching with the current DT node definitions
to find the devices to add platform data. The pdata quirks do not
use a starting address in the auxdata for the DSP device though as
it doesn't have any L2 RAM memory (and so no 'reg' value/address
for the device).

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP4: Add aliases for rproc nodes
Suman Anna [Sat, 9 Aug 2014 02:32:05 +0000 (21:32 -0500)]
ARM: dts: OMAP4: Add aliases for rproc nodes

Add aliases for the DSP and IPU remoteproc processor
nodes common to all OMAP4 boards. The aliases uses
the stem "rproc".

The aliases can be overridden, if needed, in the
respective board files.

Signed-off-by: Suman Anna <s-anna@ti.com>
3 years agoARM: dts: OMAP4: Add IPU DT node
Suman Anna [Wed, 16 Mar 2016 23:54:57 +0000 (18:54 -0500)]
ARM: dts: OMAP4: Add IPU DT node

The DT node for the Dual-Cortex M3 IPU processor sub-system
has been added for OMAP4 SoCs. The L2RAM memory region
information has been added to the node through the 'reg'
and 'reg-names' properties. The node has the 'iommus' and
'mboxes' properties also added, and is disabled for now. It
should be enabled as per the individual product configuration
in the corresponding board dts files.

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