aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node namesHEADrproc-linux-4.19.ySuman Anna2019-09-171-8/+8
| | | | | | | | | | | 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>
* ARM: dts: dra72-evm-revc: Fix rproc reserved-memory labels and node namesSuman Anna2019-09-171-6/+6
| | | | | | | | | | | 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>
* ARM: dts: dra7-ipu-dsp-common: Add watchdog timers to IPU and DSP nodesSuman Anna2019-03-112-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap5-uevm: Add watchdog timers for IPU and DSPSuman Anna2019-03-111-0/+2
| | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap4-panda-common: Add watchdog timers for IPU and DSPSuman Anna2019-03-111-0/+2
| | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7: Add standby info for IPU & DSPsSuman Anna2019-03-042-0/+4
| | | | | | | | | | 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>
* ARM: dts: omap5: Add standby info for IPU and DSPSuman Anna2019-03-041-0/+2
| | | | | | | | | | 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>
* ARM: dts: omap4: Add standby info for IPU and DSPSuman Anna2019-03-041-0/+2
| | | | | | | | | | 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>
* ARM: dts: am571x-idk: Add CMA pools and enable IPUs & DSP1 rprocsSuman Anna2019-03-041-0/+42
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: am572x-idk-common: Add CMA pools and enable IPU & DSP rprocsSuman Anna2019-03-041-0/+54
| | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: beagle-x15-common: Add CMA pools and enable IPU & DSP rprocsSuman Anna2019-03-041-0/+54
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra76-evm: Add CMA pools and enable IPU & DSP rprocsSuman Anna2019-03-041-0/+54
| | | | | | | | | | | 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>
* ARM: dts: dra71-evm: Add CMA pools and enable IPUs & DSP1 rprocsSuman Anna2019-03-041-0/+42
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra72-evm-revc: Add CMA pools and enable IPUs & DSP1 rprocsSuman Anna2019-03-041-0/+42
| | | | | | | | | | | 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>
* ARM: dts: dra72-evm: Add CMA pools and enable IPUs & DSP1 rprocsSuman Anna2019-03-041-0/+42
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7-evm: Add CMA pools and enable IPU & DSP rprocsSuman Anna2019-03-041-0/+54
| | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7-ipu-dsp-common: Add timers to IPU and DSP nodesSuman Anna2019-03-042-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7-ipu-dsp-common: Add mailboxes to IPU and DSP nodesSuman Anna2019-03-042-0/+16
| | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7-ipu-dsp-common: Move mailboxes into common filesSuman Anna2019-03-047-94/+38
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra72x: Add aliases for rproc nodesSuman Anna2019-03-041-0/+6
| | | | | | | | | | | | | 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>
* ARM: dts: dra74x: Add aliases for rproc nodesSuman Anna2019-03-041-0/+7
| | | | | | | | | | | | | 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>
* ARM: dts: dra74x: Add DSP2 processor device nodeSuman Anna2019-03-041-0/+12
| | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7: Add common IPU and DSP nodesSuman Anna2019-03-041-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap5-uevm: Add system timers to DSP and IPUSuman Anna2019-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap5-uevm: Enable IPU & DSP CMA and rproc nodesSuman Anna2019-03-041-2/+4
| | | | | | | | | | | | | 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>
* ARM: dts: omap5-uevm: Add CMA reserved memory nodes for rprocsSuman Anna2019-03-041-0/+28
| | | | | | | | | | | | | | | 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>
* ARM: dts: omap5: Add aliases for rproc nodesSuman Anna2019-03-041-0/+2
| | | | | | | | | | | | 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>
* ARM: dts: omap5: Add DSP and IPU nodesSuman Anna2019-03-041-0/+19
| | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap4-panda-common:: Add system timers to DSP and IPUSuman Anna2019-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap4-panda-common: Enable IPU & DSP CMA and rproc nodesSuman Anna2019-03-041-2/+4
| | | | | | | | | | | | | 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>
* ARM: dts: omap4-panda-common: Add CMA reserved pools for rprocsSuman Anna2019-03-041-0/+28
| | | | | | | | | | | | | | | | 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>
* ARM: dts: omap4: Add aliases for rproc nodesSuman Anna2019-03-041-0/+2
| | | | | | | | | | | 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>
* ARM: dts: omap4: Add IPU DT nodeSuman Anna2019-03-041-0/+10
| | | | | | | | | | | | 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>
* ARM: dts: omap4: Update the DSP nodeSuman Anna2019-03-041-5/+9
| | | | | | | | | | | | | | | | | | 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>
* ARM: dts: dra7: Fix functional clocks for DMTimer devicesSuman Anna2019-03-041-0/+30
| | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap5: Fix functional clocks for DMTimer devicesSuman Anna2019-03-041-0/+20
| | | | | | | | | | | | | | | | | | 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>
* ARM: dts: omap4: Fix functional clocks for ABE DMTimer devicesSuman Anna2019-03-041-0/+8
| | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into ↵Suman Anna2019-03-043-20/+63
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: dts: dra74x: Enable DSP2 IOMMU nodesSuman Anna2019-03-021-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: dts: dra7: Enable common IPU and DSP IOMMU nodesSuman Anna2019-03-021-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: dts: dra7: Add clkctrl nodes for IPU and DSP remote processorsTero Kristo2019-03-021-14/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: keystone-k2g: Add PRU system events for virtioSuman Anna2019-02-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: DRA7: Add PRU system events for virtioSuman Anna2019-02-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: AM4372: Add PRU system events for virtioSuman Anna2019-02-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: AM33xx: Add PRU system events for virtioSuman Anna2019-02-231-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: keystone-k2g: Add PRUSS GPIO controller nodesSuman Anna2019-02-231-0/+32
| | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: keystone-k2g: Add PRUSS MDIO controller nodesSuman Anna2019-02-231-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: keystone-k2g: Add the PRU-ICSS nodesSuman Anna2019-02-231-0/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: am57xx-idk-common: Enable PRU-ICSS nodesSuman Anna2019-02-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: dts: beagle-x15-common: Enable PRU-ICSS nodesSuman Anna2019-02-231-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>