- 18 Jun, 2021 4 commits
-
-
Suman Anna authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within the MAIN domain on the TI AM642 EVM and SK boards. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. An additional reserved memory node is also added to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS or baremetal firmwares. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The current carveout addresses and sizes are defined statically for each rproc device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments. NOTE: 1. The R5F1 carveouts are needed only if the R5F cluster is running in Split (non Single-CPU) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. 2. The AM64x SoCs do not have any DSPs and one less R5F cluster compared to J721E SoCs. So, while the carveout memories reserved for the R5F clusters present on the SoC match to those on J721E, the overall memory map reserved for firmwares is quite different. The number of R5F clusters on AM64x SoCs are same as on J7200 SoCs, but the AM64x SoCs also have an additional M4F core, so the RTOS IPC memory region is 1 MB higher than on J7200 SoCs. Signed-off-by:
Suman Anna <s-anna@ti.com> Reviewed-by:
Praneeth Bajjuri <praneeth@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210615195718.15898-4-s-anna@ti.com
-
Suman Anna authored
Add the required 'mboxes' property to all the R5F processors for the TI AM642 EVM and SK boards. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. 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. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Signed-off-by:
-
Suman Anna authored
The AM64x SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS) subsystems/clusters. Both the R5F clusters are present within the MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be configured at boot time to be either run in a new "Single-CPU" mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. The mode is restricted to "Single-CPU" on some devices with the appropriate eFuse bit set, but the most common devices support both modes. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in Single-CPU mode to provide a larger 128 KB of memory. The other notable difference is that the TCMs are spaced 1 MB apart on these SoCs unlike the existing SoCs. Add the DT nodes for both these MAIN domain R5F cluster/subsystems, the two R5F cores are added as child nodes to each of the corresponding R5F cluster node. Both the clusters are configured to run in Split mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MAIN R5FSS0 Core0: am64-main-r5f0_0-fw (both in Single-CPU & Split modes) MAIN R5FSS0 Core1: am64-main-r5f0_1-fw (needed only in Split mode) MAIN R5FSS1 Core0: am64-main-r5f1_0-fw (both in Single-CPU & Split modes) MAIN R5FSS1 Core1: am64-main-r5f1_1-fw (needed only in Split mode) NOTE: A R5FSS cluster can be configured in "Single-CPU" mode by using a value of 2 for the "ti,cluster-mode" property. Value of 1 is not permitted (fails the dtbs_check). Signed-off-by:
-
Nishanth Menon authored
Merge tag '20210327143117.1840-2-s-anna@ti.com' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc into ti-k3-dts-next v5.13-rc1 + 20210327143117.1840-2-s-anna@ti.com * tag '20210327143117.1840-2-s-anna@ti.com' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc: dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs Signed-off-by:
-
- 17 Jun, 2021 3 commits
-
-
Aswath Govindraju authored
Due to a limitation for USB DFU boot mode, SPL load address has to be less than or equal to 0x70001000. So, load address of SPL and TF-A have been moved to 0x70000000 and 0x701c0000 respectively, in U-Boot version 2021.10. Therefore, update TF-A's location in the device tree node. Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Reviewed-by:
-
Aswath Govindraju authored
The final 128KB in SRAM is reserved by default for DMSC-lite code and secure proxy communication buffer. The memory region used for DMSC-lite code can be optionally freed up by secure firmware API[1]. However, the buffer for secure proxy communication is not configurable. This default hardware configuration is unique for AM64. Therefore, indicate the area reserved for DMSC-lite code and secure proxy communication buffer in the oc_sram device tree node. [1] - http://downloads.ti.com/tisci/esd/latest/6_topic_user_guides/security_handover.html#triggering-security-handoverSigned-off-by:
-
Aswath Govindraju authored
The maximum size of TF-A 2.5 has been increased to 0x1c000 [1]. In order to account for future expansions too, increase the allocated size for TF-A to 0x20000, in the device tree node. Also, update the node name to "tfa-sram". [1] - https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=2fb5312f61a7de8b7a70e1639199c4f14a10b6f9Signed-off-by:
-
- 14 Jun, 2021 4 commits
-
-
Vignesh Raghavendra authored
8250_omap compatible UART IPs on all SoCs have registers aligned at 4 byte address boundary and constant byte addressability. Thus there is no need for reg-io-width or reg-shift DT properties. These properties are not used by 8250_omap driver nor documented as part of binding document. Therefore drop them. This is in preparation to move omap-serial.txt to YAML format. Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Aswath Govindraju authored
ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: 4fb6c046 ("arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM") Signed-off-by:
-
Aswath Govindraju authored
ti,pindir-d0-out-d1-in property is expected to be of type boolean. Therefore, fix the property accordingly. Fixes: e180f76d ("arm64: dts: ti: Add support for Siemens IOT2050 boards") Fixes: 5da94b50 ("arm64: dts: ti: k3-am654: Enable main domain McSPI0") Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by:
-
Grygorii Strashko authored
The current device tree CPSW3g node adds non-zero "mac-address" property to the ports, which prevents random MAC address assignment to network devices if bootloader failed to update DT. This may cause more then one host to have the same MAC in the network. mac-address = [00 00 de ad be ef]; mac-address = [00 01 de ad be ef]; In addition, there is one MAC address available in eFuse registers which can be used for default port 1. Hence, fix ports MAC properties by: - resetting "mac-address" property to 0 - adding ti,syscon-efuse = <&main_conf 0x200> to Port 1 Fixes: 3753b128 ("arm64: dts: ti: k3-am64-main: Add CPSW DT node") Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
-
- 11 Jun, 2021 1 commit
-
-
Jan Kiszka authored
Lockstep mode is not supported here. So turn it off to avoid warnings during startup. Signed-off-by:
-
- 08 Jun, 2021 9 commits
-
-
Kishon Vijay Abraham I authored
AM642-SK has no PCIe slot. Disable it here. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
-
Kishon Vijay Abraham I authored
Enable USB Super-Speed HOST port. Signed-off-by:
-
Kishon Vijay Abraham I authored
AM642 EVM has a x4 lane PCIe connector. Enable PCIe in RC mode here. Signed-off-by:
-
Kishon Vijay Abraham I authored
AM64 has one PCIe instance which can be configured in either host mode (RC) or device mode (EP). Add PCIe DT node for host mode and device mode here. Signed-off-by:
-
Kishon Vijay Abraham I authored
AM64 has one SERDES 10G instance. Add SERDES DT node for it. Signed-off-by:
-
Kishon Vijay Abraham I authored
Commit 66db854b ("arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances") and commit 02c35dca ("arm64: dts: ti: k3-j721e: Enable Super-Speed support for USB0") added PHY DT nodes with node name as "link" However nodes with #phy-cells should be named 'phy' as discussed in [1]. Re-name subnodes of serdes in J721E to 'phy'. [1] -> http://lore.kernel.org/r/20200909203631.GA3026331@bogus Fixes: 66db854b ("arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances") Fixes: 02c35dca ("arm64: dts: ti: k3-j721e: Enable Super-Speed support for USB0") Signed-off-by:
-
Kishon Vijay Abraham I authored
Use external clock for all the SERDES used by PCIe controller. This will make the same clock used by the local SERDES as well as the clock provided to the PCIe connector. Signed-off-by:
-
Kishon Vijay Abraham I authored
Add #clock-cells property to serdes DT node since the serdes is also now modeled as a clock provider and include the input clocks "pll0_refclk" and "pll1_refclk" which are parents to the clocks modeled by serdes. Signed-off-by:
-
Kishon Vijay Abraham I authored
Rename the external refclk inputs to the SERDES from dummy_cmn_refclk/dummy_cmn_refclk1 to cmn_refclk/cmn_refclk1 respectively. Also move the external refclk DT nodes outside the cbass_main DT node. Since in j721e common processor board, only the cmn_refclk1 is connected to 100MHz clock, fix the clock frequency. Fixes: afd094eb ("arm64: dts: ti: k3-j721e-main: Add WIZ and SERDES PHY nodes") Signed-off-by:
-
- 07 Jun, 2021 3 commits
-
-
Suman Anna authored
The ICSSGs on K3 J721E SoCs contain an MDIO controller that can be used to control external PHYs associated with the Industrial Ethernet peripherals within each ICSSG instance. The MDIO module used within the ICSSG is similar to the MDIO Controller used in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the MDIO operations. The nodes are added and enabled in the common k3-j721e-main.dtsi file by default, and disabled in the existing J721E board dts file. These nodes need pinctrl lines, and so should be enabled only on boards where they are actually wired and pinned out for ICSSG Ethernet. Any new board dts file should disable these if they are not sure. Signed-off-by:
-
Roger Quadros authored
The ICSSGs on K3 AM65x SoCs contain an MDIO controller that can be used to control external PHYs associated with the Industrial Ethernet peripherals within each ICSSG instance. The MDIO module used within the ICSSG is similar to the MDIO Controller used in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the MDIO operations. The nodes are added and enabled in the common k3-am65-main.dtsi file by default, and disabled in the existing AM65 board dts files. These nodes need pinctrl lines, and so should be enabled only on boards where they are actually wired and pinned out for ICSSG Ethernet. Any new board dts file should disable these if they are not sure. Signed-off-by:
Roger Quadros <rogerq@ti.com> [s-anna@ti.com: move the disabled status to board dts files] Signed-off-by:
-
Aswath Govindraju authored
UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1]. Add support by removing the no-1-8-v tag and including the voltage regulator device tree nodes for power cycling. However, the 4 bit interface of AM65 SR 1.0 cannot be supported at 3.3 V or 1.8 V because of erratas i2025 and i2026 [2]. As the SD card is the primary boot mode for development usecases, continue to enable SD card and disable UHS-I modes in it to minimize any ageing issues happening because of erratas. k3-am6528-iot2050-basic and k3-am6548-iot2050-advanced boards use S.R. 1.0 version of AM65 SoC. Therefore, add no-1-8-v in sdhci1 device tree node of the common iot2050 device tree file. [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1 [2] - https://www.ti.com/lit/er/sprz452e/sprz452e.pdfSigned-off-by:
-
- 28 May, 2021 5 commits
-
-
Grygorii Strashko authored
The MCU RGMII MCU_RGMII1_TXC pin is defined as input by mistake, although this does not make any difference functionality wise it's better to update to avoid confusion. Hence fix MCU RGMII MCU_RGMII1_TXC pin pinmux definitions to be an output in K3 am654x/j721e/j7200 board files. Signed-off-by:
-
Roger Quadros authored
Enable work around feature built into the controller to address issue with RX Sensitivity for USB2 PHY. Fixes: 6197d713 ("arm64: dts: ti: k3-j7200-main: Add USB controller") Signed-off-by:
-
Aswath Govindraju authored
GPIO device tree nodes do not have child nodes. Therefore, "#address-cells" property should not be added. Fixes: e0b2e6af ("arm64: dts: ti: k3-j7200: Add gpio nodes") Signed-off-by:
-
Aswath Govindraju authored
Fix the compatible string in mcu domain GPIO device tree node. Fixes: 01a91e01 ("arm64: dts: ti: k3-am64: Add GPIO DT nodes") Signed-off-by:
-
Suman Anna authored
The K3 AM64x SoCs have two dual-core Arm R5F clusters/subsystems, with 2 R5F cores each, both in the MAIN voltage domain. These clusters are a revised IP version compared to those present on J721E and J7200 SoCs, and supports a new "Single-CPU" mode instead of LockStep mode. Update the K3 R5F remoteproc bindings with the compatible info relevant to these R5F clusters/subsystems on K3 AM64x SoCs. Reviewed-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
- 22 May, 2021 1 commit
-
-
Suman Anna authored
There are no sub-mailbox devices defined currently for both the IOT2050 boards. These are usually dictated by the firmwares running on the R5F remote processors and the applications they provide. Defining the actual sub-mailboxes will also dictate the interrupts the clusters will use for interrupts on the Cortex-A53 cores. Disable all of the Mailbox clusters until the sub-mailboxes are defined and used. This fixes the warnings around the missing interrupts with the upcoming conversion of the OMAP Mailbox binding to YAML format. Signed-off-by:
-
- 14 May, 2021 8 commits
-
-
Nishanth Menon authored
Interrupt routers are memory mapped peripherals, that are organized in our dts bus hierarchy to closely represents the actual hardware behavior. However, without explicitly calling out the reg property, using 2021.03+ dt-schema package, this exposes the following problem with dtbs_check: /arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], ..... Even though we don't use interrupt router directly via memory mapped registers and have to use it via the system controller, the hardware block is memory mapped, so describe the base address in device tree. This is a valid, comprehensive description of hardware and permitted by the existing ti,sci-intr schema. Reviewed-by:Tero Kristo <kristo@kernel.org> Reviewed-by:
-
Nishanth Menon authored
Instead of using empty ranges property, lets map explicitly the address range that is mapped onto the dma / navigator subsystems (navss/dmss). This is also exposed via the dtbs_check with dt-schema newer than 2021.03 version by throwing out following: arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: main-navss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], ..... This has already been correctly done for J7200, however was missed for other k3 SoCs. Fix that oversight. Signed-off-by: -
Nishanth Menon authored
Lets rename the node name of TI-SCI node to be system-controller as it is a better standardized name for the function that TI-SCI plays in the SoC. Signed-off-by:
-
Nishanth Menon authored
The DMSC node does'nt require any of "#address-cells", "#size-cells" or "ranges" property as the child nodes are representations of SoC's system controller itself, so align it with the bindings. Signed-off-by:
-
Nishanth Menon authored
Lets add the TISCI debug region to TI-SCI region in line with TI-SCI documentation[1]. While at it, lets rename the node to indicate the address usage. [1] http://downloads.ti.com/tisci/esd/latest/4_trace/trace.htmlSigned-off-by:
-
Nishanth Menon authored
We currently use clocks as the node name for the node representing TI-SCI clock nodes. This is better renamed to being clock-controller as that is a better representative of the system controller function as a clock controller for the SoC. Signed-off-by:
-
Vignesh Raghavendra authored
Traffic through main NAVSS interconnect is coherent wrt ARM caches on J7200 SoC. Add missing dma-coherent property to main_navss node. Also add dma-ranges to be consistent with mcu_navss node and with AM65/J721e main_navss and mcu_navss nodes. Fixes: d361ed88 ("arm64: dts: ti: Add support for J7200 SoC") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by:
-
Tomi Valkeinen authored
AM654 EVM boards are not shipped with OV5640 sensor module, it is a separate purchase. OV5640 module is also just one of the possible sensors or capture boards you can connect. However, for some reason, OV5640 has been added to the board dts file, making it cumbersome to use other sensors. Remove the OV5640 from the dts file so that it is easy to use other sensors via DT overlays. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by:
Pratyush Yadav <p.yadav@ti.com> Signed-off-by:
-
- 09 May, 2021 2 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit b9d79e4c ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
