| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
The commit 1cc71af030c6 ("ARM: dts: dra76-evm: Add CMA pools and enable
IPU & DSP rprocs") erroneously used the old CMA terminology in the DSP
and IPU rproc reserved memory node names and labels. Fix these and align
with the node names and labels used in all the other TI DRA7xx/AM57xx
board dts files.
Fixes: 1cc71af030c6 ("ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocs")
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The commit 896cb04007c3 ("ARM: dts: dra72-evm-revc: Add CMA pools and
enable IPUs & DSP1 rprocs") erroneously used the old CMA terminology in
the DSP1 & IPU rproc reserved memory node names and labels. Fix these
and align with the node names and labels used in all the other TI
DRA7xx/AM57xx board dts files.
Fixes: 896cb04007c3 ("ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocs")
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rproc-linux-4.19.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.19.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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rproc-linux-4.19.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. The DSP idle
status is achieved across all the DSPs and boards only with the
fix for errata i879.
* 'iommu-linux-4.19.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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 4e6bf3ca947b ("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. The functional behavior is inconsistent between different DSPs on
DRA74x, DRA72x and DRA71x SoCs and silicon revisions. DSP1 on
DRA7 EVM rev.H (DRA752 ES2.0), AM57xx GP EVM (DRA752 ES2.0) and
AM572x IDK (DRA752 ES2.0) boards is entering idle mode without any
fix and are getting powered down and losing context, but none of
the other boards (DRA72 EVM, DRA71 EVM, AM571x IDK) exhibit this
behavior. The idling behavior is unchanged even after this patch
is applied. DSP2 is not idled on any board. These behaviors are
different from those observed on 4.14 kernel.
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, but the behavior is different between
different DSPs and SoCs as explained in #1. The i879 errata fix in
the following patch achieves the DSP clock-gating with HW_AUTO mode,
and would result in a power domain sleep transition to OFF mode
without any software context save mechanism for all the DSPs.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 8fdc9a162e8d ("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.19 kernel without this fix. This behavior
is same as on 4.14 LTS kernel but slightly different from previous
4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected IPU 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 or OFF and loose context 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/4.19 kernels, and an l3_noc error was seen
still without this fix.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|