| 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compatible property for the DSP node is updated to match
the OMAP remoteproc bindings. The node is moved from the soc
node to the ocp node, as this is better suited to use with
pdata-quirks.
The node is updated with the 'syscon-bootreg', 'iommus' and
'mboxes' properties. Note that the node does not have any
'reg' or 'reg-names' properties since it doesn't have any
L2 RAM memory, but only Unicaches.
The node is disabled for now, and 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 hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.
The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.
The dmtimer clocksource driver cannot use this clock to configure
its parents. The dmtimer consumers got lucky so far due to the
default clock matching the requested parent clock, and a silent
successful return in the omap_dm_timer_set_source() function. Fix
this by adding the actual mux clocks to the DMTimer nodes with
the "fck" clock-name. These clocks are expected to remain even
after the nodes have moved under a ti,sysc parent node.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hwmod and clkctrl integration code is currently assigning the
clkctrl clock associated with MODULEMODE as the main functional
clock for nodes that have the ti,hwmods property. This is wrong
for devices that actually use mux or gate clocks as their main
clock and that are not yet converted to the ti-sysc node hierarchy.
The dmtimer clocksource driver cannot use this clock to configure
its parents. All the DMTimer nodes except for those present in the
ABE domain have been converted to the new ti-sysc node hierarchy
style and do not face this issue. The dmtimer consumers got lucky
so far due to the default clock matching the requested parent clock,
and a silent successful return in the omap_dm_timer_set_source()
function. Fix the remaining DMTimer nodes in ABE domain by adding
the actual mux clocks to the DMTimer nodes with the "fck" clock-name.
These clocks are expected to remain even after the nodes have moved
under a ti,sysc parent node.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rproc-linux-4.19.y
Pull in the iommu tree into the remoteproc tree, since this is a minimum
for bringing up the OMAP remote processors successfully. This iommu merge
pulls in couple of minor cleanups and the basic OMAP IOMMU driver support
for all the IPU and DSP MMUs present on DRA7xx/AM57xx SoC families. The
merge includes fixes to restore the functionality on OMAP4 and OMAP5 SoCs
due to the clkctrl changes, and also adds the clkctrl clocks and nodes for
DRA7 remote processors. The MMUs are enabled in the common base dra7 dts
files, so are supported on all applicable DRA7xx/AM57xx boards automatically.
The base support for IPU and DSP MMUs on OMAP4 and OMAP5 SoC families, and
the necessary DPLL clock configuration of the clocks required for various
remoteproc devices on OMAP4/OMAP5 and DRA7 SoCs are all upstream.
* 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu:
ARM: dts: dra74x: Enable DSP2 IOMMU nodes
ARM: dts: dra7: Enable common IPU and DSP IOMMU nodes
ARM: OMAP2+: Extend iommu pdata-quirks to DRA74x DSP2
ARM: OMAP2+: Extend iommu pdata-quirks to DRA7 IPUs & DSP1
ARM: DRA7: hwmod data: Add MMU data for DSPs
ARM: DRA7: hwmod data: Add MMU data for IPUs
ARM: dts: dra7: Add clkctrl nodes for IPU and DSP remote processors
clk: ti: dra7: add clkctrl data for remote processor clocks
dt-bindings: clk: add dra7 remotecore clkctrl definitions
clk: ti: omap5: Drop idlest polling from IPU & DSP clkctrl clocks
clk: ti: omap4: Drop idlest polling from IPU & DSP clkctrl clocks
ARM: OMAP2+: hwmod_core: improve the support for clkctrl clocks
iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN
iommu/omap: Remove DEBUG_SEQ_FOPS_RO()
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The DSP2 remote processor is present only on some SoCs of the DRA7
family - mainly the DRA74x/DRA76x and AM572x/AM574x and corresponding
derivative SoCs. The two MMU nodes for this DSP2 processor have all
been enabled by default, so that these nodes are automatically
enabled for all derivative boards using these SoCs.
Any derivative SoCs or boards not having these IPs or not intending to
enable/use these remote processors by default can mark these nodes
as "disabled" in their derivative SoC or board dts files.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The IPU1, IPU2 and DSP1 are the most common remote processors present
on the DRA7xx/AM57xx family of SoCs. The MMU nodes for these common
processors have all been enabled by default, so that these nodes are
automatically enabled for all derivative boards.
Any derivative SoCs or boards not having these IPs or not intending to
enable/use these remote processors by default can mark these nodes
as "disabled" in their derivative SoC or board dts files.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the clkctrl nodes for the DSP and IPU remote processors. Each of the
IPU and DSP processors are present within their own clock domains. The
previous ipu_cm clock domain is split properly into the correct ipu_cm
and ipu1_cm clock domains.
The ipu1_gfclk_mux clock is now created through the clkctrl driver and
so the corresponding clock node is dropped. The dpll_core_h22x2_ck clock
is also assigned as the default parent for the equivalent clock retaining
the functional behaviour introduced in commit 39879c7d963e ("ARM: dts:
dra7xx-clocks: Source IPU1 functional clock from CORE DPLL").
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[s-anna@ti.com: revise patch description]
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
keystone-k2g.dtsi file, and so are inherited by all 66AK2G boards.
The PRU system events is the preferred approach over using the
alternate IPCGR registers, as it eliminates an external MMR access
from the PRU-side, and keeps the interrupt generation internal to
the PRUSS. The difference from MPU would be minimal in using one
versus the other. Note that the 66AK2G SoCs do not have the OMAP
Mailbox IP, so there is no option of using mailboxes.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS1 and PRU-ICSS2 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the common base
dra7.dtsi file, and so are inherited by all the AM57xx boards.
Do note that PRUSS is not available/supported on the DRA7xx SoCs
SoCs and is only limited to the AM57xx SoCs.
The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.
Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two PRU system events "vring" and "kick" have been added to each
PRU node in each of the PRU-ICSS0 and PRU-ICSS1 remote processor
subsystems to enable the virtio/rpmsg communication between MPU
and that PRU core. The additions are done in the base am4372.dtsi
file, and so are inherited by all the AM437x boards. Do note that
PRUSS is not available on all AM437x SoCs.
The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.
Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two PRU system events "vring" and "kick" have been added to each
of the PRU nodes in the PRU-ICSS remote processor subsystem to
enable the virtio/rpmsg communication between MPU and that PRU
core. The additions are done in the base am33xx.dtsi file, and
so are inherited by all the AM33xx boards. Do note that PRUSS
is not available on all AM335x SoCs.
The PRU system events is the preferred approach over using OMAP
mailboxes, as it eliminates an external peripheral access from
the PRU-side, and keeps the interrupt generation internal to the
PRUSS. The difference from MPU would be minimal in using one
versus the other.
Mailboxes can still be used if desired. Either approach would
require that an appropriate firmware image is loaded/booted on
the PRU.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the PRUSS GPIO controller nodes on the 66AK2G SoC. These can
be used to send interrupts to specific PRUSS subsystem instances
present on the SoC. Each PRUSS is capable of receiving an interrupt
each from two such nodes. The IP is identical to that of the
equivalent node for the DSP present on 66AK2G SoC.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The PRUSSs on 66AK2G SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each PRUSS. The MDIO module used
within the PRU-ICSS is an instance of the MDIO Controller used
in TI Davinci SoCs. The same bus frequency of 2.5 MHz is chosen
as the regular MDIO node.
The nodes are added to the common keystone-k2g dts file and are
disabled. These need to be enabled in the respective board files
supporting 66AK2G SoCs and where the ethernet is pinned out and
connected properly.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the DT nodes for the PRU-ICSS0 and PRU-ICSS1 processor subsystems
that are present on the 66AK2G SoC. The two PRU-ICSSs are identical
to each other. Each PRU-ICSS instance is represented by a pruss-soc-bus
node and a child PRUSS subsystem node. These nodes are enabled by
default.
The PRU-ICSSs on 66AK2G are very similar to the PRUSS on the AM57xx
SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS
crossbar. There are also few other minor integration differences
w.r.t IPC mechansims that can be attributed to the architecture
differences between Keystone and OMAP families.
The PRUSS subsystem node contains the entire address space and the
various interrupts generated towards the main MPU. The various
sub-modules of the PRU-ICSS are represented as individual child
nodes (so platform devices themselves) of the PRUSS subsystem node.
These include the two PRU cores and the interrupt controller. The
Industrial Ethernet Peripheral (IEP), the Real Time Media Independent
Interface controller (MII_RT), and the CFG sub-module are represented
as syscon nodes. All the Data RAMs are represented within a child
node of its own named 'memories' without any compatible.
The DT nodes use all standard properties. The regs property in the
PRU nodes define the addresses for the Instruction RAM, the Debug
and Control sub-modules for that PRU core. The firmware for each
PRU core is defined through a 'firmware-name' property.
The default names for the firmware images for each PRU core are
defined as follows (these can be adjusted either in derivative
board dts files or through sysfs at runtime if required):
PRU-ICSS0 PRU0 Core: k2g-pru0_0-fw
PRU-ICSS0 PRU1 Core: k2g-pru0_1-fw
PRU-ICSS1 PRU0 Core: k2g-pru1_0-fw
PRU-ICSS1 PRU1 Core: k2g-pru1_1-fw
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes (both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the AM571x, AM572x and AM574x IDK boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.
The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The two PRU-ICSS processor subsystem bus nodes and their corresponding
subsystem nodes were left in disabled state in the base dra7.dts file.
The PRU-ICSSs are supported on only the AM57xx SoCs, so enable these
nodes ((both PRU-ICSS1 and PRU-ICSS2 instances) to support them on
all the BeagleBoard-X15 and AM57xx GP EVM boards. The PRU nodes are
already enabled in the base dts file, and so become effective
automatically with the enabling of these PRU-ICSS nodes.
The corresponding PRU nodes can be disabled later on if there are
no use-cases defined to use a particular PRU core or the whole
PRU-ICSS subsystem itself if both its PRU cores are unused.
Signed-off-by: Suman Anna <s-anna@ti.com>
|