summaryrefslogtreecommitdiffstats
path: root/arch/arm64/boot/dts/ti/k3-am65.dtsi
AgeCommit message (Collapse)AuthorFilesLines
2022-02-22arm64: dts: ti: k3-am65: Fix gic-v3 compatible regsNishanth Menon1-0/+1
Though GIC ARE option is disabled for no GIC-v2 compatibility, Cortex-A53 is free to implement the CPU interface as long as it communicates with the GIC using the stream protocol. This requires that the SoC integration mark out the PERIPHBASE[1] as reserved area within the SoC. See longer discussion in [2] for further information. Update the GIC register map to indicate offsets from PERIPHBASE based on [3]. Without doing this, systems like kvm will not function with gic-v2 emulation. [1] https://developer.arm.com/documentation/ddi0500/e/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 [2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ [3] https://developer.arm.com/documentation/ddi0500/e/generic-interrupt-controller-cpu-interface/gic-programmers-model/memory-map Cc: stable@vger.kernel.org # 5.10+ Fixes: ea47eed33a3f ("arm64: dts: ti: Add Support for AM654 SoC") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220215201008.15235-2-nm@ti.com
2021-09-20arm64: dts: ti: ti-k3*: Introduce aliases for mmc nodesNishanth Menon1-0/+2
Since probe order of mmc can vary depending on device tree dependencies, Lets try and introduce a consistent definition of what mmc0, 1 are across platforms. NOTE: Certain platforms may choose to have overrides due to various legacy reasons, we permit that in the board specific alias definition. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20210915135415.5706-1-nm@ti.com
2021-01-28arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specificNishanth Menon1-1/+1
We can use CPU specific pmu configuration to expose the appropriate CPU specific events rather than just the basic generic pmuv3 perf events. Reported-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Suman Anna <s-anna@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210120195145.32259-1-nm@ti.com
2020-08-31arm64: dts: ti: k3-am65: Fix interconnect node namesSuman Anna1-3/+3
The various CBASS interconnect nodes on K3 AM65x SoCs are defined using the node name "interconnect". This is not a valid node name as per the dt-schema. Fix these node names to use the standard name used for SoC interconnects, "bus". Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20200723211137.26641-2-s-anna@ti.com
2020-07-17arm64: dts: ti: k3-*: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2020-03-26arm64: dts: ti: k3-am65-mcu: add cpsw nuss nodeGrygorii Strashko1-0/+1
Add DT node for the TI AM65x SoC Gigabit Ethernet two ports Switch subsystem (CPSW NUSS). Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Murali Karicheri <m-karicheri2@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17arm64: dts: ti: k3-am65-mcu: add system control module nodeGrygorii Strashko1-0/+2
The MCU System control module support is added to the device tree to allow drivers to access to their System control module registers. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2020-01-17arm64: dts: ti: k3-am65: Add OSPI DT nodeVignesh Raghavendra1-2/+9
AM654 SoC has two Cadence OSPI controller instances under Flash subsystem (FSS). Add DT nodes for the same. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-08-29arm64: dts: ti: k3-am654: Update the power domain cellsLokesh Vutla1-0/+1
Update the power-domain cells to 2 and mark all devices as exclusive. Main uart 0 is the debug console for based boards and it is used by different software entities like u-boot, atf, linux. So just mark main_uart0 as shared device for base board. Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-17arm64: dts: k3-am6: Add PCIe Root Complex DT nodeKishon Vijay Abraham I1-0/+1
Add PCIe Root Complex DT node. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-17arm64: dts: ti: k3-am65: Add MSMC RAM ranges in interconnect nodeRoger Quadros1-0/+1
Add the MSCM RAM address space to the ranges property of the cbass_main interconnect node so that the addresses can be translated properly. This fixes the probe failure in the sram driver for the MSMC RAM node. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-17arm64: dts: ti: k3-am65: Add R5F ranges in interconnect nodesSuman Anna1-0/+4
Add the address spaces for the R5F cores in MCU domain to the ranges property of the cbass_mcu interconnect node so that the addresses within the R5F nodes can be translated properly by the relevant OF address API. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2019-06-17arm64: dts: ti: k3-am65: Add MCU SRAM ranges in interconnect nodesSuman Anna1-0/+2
Add the address space for the MCU SRAM memory to the ranges property of the cbass_mcu interconnect node so that the addresses within the mcu_sram nodes and its children can be translated properly by the relevant OF address API. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2018-12-14arm64: dts: ti: k3-am654-base-board: Add I2C nodesVignesh R1-0/+6
Add DT entries for I2C instances present in AM654 SoC. Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2018-12-14arm64: dts: ti: k3-am65: Add pinctrl regionsTero Kristo1-0/+1
Add pinctrl regions for the main and wkup mmr. The range for main pinctrl region contains a gap at offset 0x2e4, and because of this, the pinctrl range is split into two sections. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
2018-09-18arm64: dts: ti: am654: Add uart nodesNishanth Menon1-0/+10
Add uart nodes for AM654 device tree components. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2018-09-18arm64: dts: ti: k3-am65: Change #address-cells and #size-cells of ↵Kishon Vijay Abraham I1-22/+22
interconnect to 2 AM65 has two PCIe controllers and each PCIe controller has '2' address spaces one within the 4GB address space of the SoC and the other above the 4GB address space of the SoC (cbass_main) in addition to the register space. The size of the address space above the 4GB SoC address space is 4GB. These address ranges will be used by CPU/DMA to access the PCIe address space. In order to represent the address space above the 4GB SoC address space and to represent the size of this address space as 4GB, change address-cells and size-cells of interconnect to 2. Since OSPI has similar need in MCU Domain Memory Map, change address-cells and size-cells of cbass_mcu interconnect also to 2. Fixes: ea47eed33a3fe3d919 ("arm64: dts: ti: Add Support for AM654 SoC") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Vignesh R <vigneshr@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com>
2018-07-18arm64: dts: ti: Add Support for AM654 SoCNishanth Menon1-0/+87
The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * Dual lock-step capable R5F uC for safety-critical applications * High data throughput capable distributed DMA architecture under NAVSS * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * Centralized System Controller for Security, Power, and Resource management. * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD * Flash subsystem with OSPI and Hyperbus interfaces * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO See AM65x Technical Reference Manual (SPRUID7, April 2018) for further details: http://www.ti.com/lit/pdf/spruid7 NOTE: 1. AM654 is the first of the device variants, hence we introduce a generic am65.dtsi. 2. We indicate the proper bus topology, the ranges are elaborated in each bus segment instead of using the top level ranges to make sure that peripherals in each segment use the address space accurately. 3. Peripherals in each bus segment is maintained in a separate dtsi allowing for reuse in different bus segment representation from a different core such as R5. This is also the reason for maintaining a 1-1 address map in the ranges. 4. Cache descriptions follow the ARM64 standard description. Further tweaks may be necessary as we introduce more complex devices, but can be introduced in context of the device introduction. Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>