aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm
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>
* Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into ↵Suman Anna2019-03-041-0/+22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMUSuman Anna2019-03-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUsSuman Anna2019-03-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: plug in device_enable/idle ops for IOMMUsSuman Anna2019-03-031-0/+6
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'iommu-linux-4.19.y' of git://git.ti.com/rpmsg/iommu into ↵Suman Anna2019-03-043-3/+102
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879Suman Anna2019-03-021-3/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUsSuman Anna2019-03-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ARM: OMAP2+: Use separate IOMMU pdata to fix DRA7 IPU1 bootSuman Anna2019-03-021-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * iommu/omap: Fix boot issue on remoteprocs with AMMU/UnicacheSuman Anna2019-03-022-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | 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: OMAP2+: Extend rproc pdata-quirks for DSP2 rproc on DRA74xSuman Anna2019-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: OMAP2+: Extend rproc pdata-quirks for IPUs & DSP1 on DRA7Suman Anna2019-03-041-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: DRA7: hwmod_data: add data for DSP2 processorSuman Anna2019-03-041-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: DRA7: hwmod_data: add data for IPU and DSP1 rprocsSuman Anna2019-03-041-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | 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: OMAP2+: Extend OMAP4 IPU/DSP pdata-quirks to OMAP5Suman Anna2019-03-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: OMAP5: hwmod_data: add data for IPU & DSP processorsSuman Anna2019-03-041-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | 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: OMAP4: hwmod_data: remove modulemode from IPU/DSP hwmodsSuman Anna2019-03-041-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | 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: OMAP2+: Add pdata-quirks for DSP and IPU remoteprocsSuman Anna2019-03-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | 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>