summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-10ARM: dts: Properly configure dra7 edma sysconfig registersTony Lindgren1-6/+27
Looks like the TRM is not listing the sysconfig for edma, let's add it based on am437x TRM edma registers as listed in sections "Table 10-26. EDMA3CC Registers" and "Table 10-99. EDMA3TC Registers". Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10ARM: dts: Configure interconnect target module for dra7 pcieTony Lindgren1-4/+30
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10ARM: dts: Update pcie ranges for dra7Tony Lindgren1-11/+18
In order to update pcie to probe with ti-sysc and genpd, let's update the pcie ranges to not use address 0 for 0x20000000 and 0x30000000. The range for 0 is typically used for child devices as the offset from the module base. In the following patches, we will update pcie to probe with ti-sysc, and the patches become a bit confusing to read compared to other similar modules unless we update the ranges first. So let's just use the full addresses for ranges for the 0x20000000 and 0x30000000 ranges. Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driverTony Lindgren1-6/+7
After updating pci-dra7xx driver to probe with ti-sysc and genpd, I noticed that dra7xx_pcie_probe() would not run if a power-domains property was configured for the interconnect target module. Turns out that module_platform_driver_probe uses platform_driver_probe(), while builtin_platform_driver uses platform_driver_register(). Only platform_driver_register() works for deferred probe as noted in the comments for __platform_driver_probe() in drivers/base/platform.c with a line saying "Note that this is incompatible with deferred probing". With module_platform_driver_probe, we have platform_driver_probe() produce -ENODEV error at device_initcall() level, and no further attempts are done. Let's fix this by using module_platform_driver instead. Note this is not an issue currently as we probe devices with simple-bus, and only is needed as we start probing the device with ti-sysc, or when probed with simple-pm-bus. Note that we must now also remove __init for probe related functions to avoid a section mismatch warning. Cc: linux-pci@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10clk: ti: omap5: Add missing gpmc and ocmc clkctrlTony Lindgren2-0/+4
The gpmc clock is needed to update omap5 to boot with genpd with the related devicetree patches. The ocmc clock is currently not used but let's add it so we have all the clocks for the l3main2 defined. Cc: Stephen Boyd <sboyd@kernel.org> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10soc: ti: omap-prm: Allow hardware supported retention when idleTony Lindgren1-4/+12
When moving the l4 interconnect instances to probe with simple-pm-bus and genpd, we will have l4per and core domains stop idling unless we configure the domain bits to allow retention when idle. As the TI SoCs have hardware autoidle capabilities, this is safe to do. The domains will only enter retention on WFI when none of the devices on the domain block autoidle in the hardware. This follows what we are already currently doing. Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Tero Kristo <kristo@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10ARM: OMAP2+: Init both prm and prcm nodes early for clocksTony Lindgren1-8/+21
We need to probe both prm and prcm nodes early for clocks as they are needed by system timers. Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10bus: ti-sysc: Check for old incomplete dtbTony Lindgren1-0/+16
Let's be nice and show an error on the SoCs about old imcomplete devicetree if the dtb is still using "simple-bus" instead of "simple-pm-bus" for the root OCP node. Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-10arm64: dts: renesas: r8a779a0: Add TMU supportPhong Hoang1-0/+65
This patch adds TMU{0|1|2|3|4} device nodes for R-Car V3U (r8a779a0) SoC. Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com> [wsa: rebased, double checked values] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210305143259.12622-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-03-10arm64: dts: renesas: falcon: Add Ethernet sub-boardGeert Uytterhoeven2-0/+16
Add a DTS file for the Falcon Ethernet sub-board (RTP0RC779A0ETS0010S), and include it from the main r8a779a0-falcon.dts. For now its contents are limited to the Board ID EEPROM. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210304153257.4059277-4-geert+renesas@glider.be
2021-03-10arm64: dts: renesas: falcon: Add CSI/DSI sub-boardGeert Uytterhoeven2-0/+16
Add a DTS file for the Falcon CSI/DSI sub-board (RTP0RC779A0DCS0010S), and include it from the main r8a779a0-falcon.dts. For now its contents are limited to the Board ID EEPROM. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210304153257.4059277-3-geert+renesas@glider.be
2021-03-10arm64: dts: renesas: falcon: Add I2C EEPROM nodesGeert Uytterhoeven2-0/+16
Add device nodes for the I2C EEPROMs on the Falcon CPU and BreakOut boards. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210304153257.4059277-2-geert+renesas@glider.be
2021-03-10ARM: dts: rza2mevb: Upstream Linux requires SDRAMGeert Uytterhoeven1-23/+32
As upstream Linux does not support XIP (eXecute-In-Place) for ARMv7-A platforms that are part of the ARCH_MULTIPLATFORM framework, it cannot run in the 8 MiB of HyperRAM present on the RZ/A2M CPU board. Hence the 64 MiB of SDRAM on the sub-board needs to be enabled, which has the following ramifications: - SCIF4 connected to the on-board USB-serial can no longer be used as the serial console, - Instead, SCIF2 is used as the serial console, by connecting a 3.3V TTL USB-to-Serial adapter to the CMOS camera connector, - The first Ethernet channel can no longer be used, - USB Channel 1 loses the overcurrent input signal. Based on the Linux-4.19 BSP for RZ/A2. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Chris Brandt <chris.brandt@renesas.com> Link: https://lore.kernel.org/r/20210304094945.4003097-1-geert+renesas@glider.be
2021-03-10arm64: dts: renesas: Consolidate Salvator-X(S) HDMI0 handlingGeert Uytterhoeven9-337/+41
Now all Salvator-X(S) SoC/board combinations have support for HDMI sound, all HDMI0 connector and sound descriptions are identical. Replace them by shared descriptions in salvator-common.dtsi, to reduce duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20210303140529.3941670-1-geert+renesas@glider.be
2021-03-10arm64: dts: broadcom: bcm4908: describe Netgear R8000P switchRafał Miłecki1-0/+25
R8000P model has 4 LAN ports and 1 WAN port. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-10arm64: dts: broadcom: bcm4908: describe Ethernet controllerRafał Miłecki1-0/+19
BCM4908 SoCs have an integrated Ethernet controller. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-10arm64: dts: broadcom: bcm4908: describe USB PHYRafał Miłecki3-4/+55
BCM4908 uses slightly modified STB family USB PHY. It handles OHCI/EHCI and XHCI. It requires powering up using the PMB. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-09arm64: dts: ti: k3-j721e-main: Add ICSSG nodesSuman Anna1-0/+262
Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are present on the K3 J721E SoCs. The two ICSSGs are identical to each other for the most part, with the ICSSG1 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node and other child nodes. These nodes are enabled by default. The ICSSGs on K3 J721E SoCs are revised versions of the ICSSG on the first AM65x SR1.0 SoCs. The PRU IRAMs are slightly smaller, and the IP includes two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. All The ICSSG host interrupts intended towards the main Arm core are also shared with other processors on the SoC, and can be partitioned as per system integration needs. The ICSSG subsystem node contains the entire address space. The various sub-modules of the ICSSG are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the two PRU cores, two RTU cores, two Tx_PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controller (MII_RT), the Gigabit capable MII_G_RT and the CFG sub-module are represented as syscon nodes. The ICSSG CFG sub-module provides two internal clock muxes, and these are represented as children of the CFG child node 'clocks' by the 'coreclk-mux' and iepclk-mux' clk nodes. The default parents for these mux clocks are also defined using the assigned-clock-parents property. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : j7-pru0_0-fw ; PRU1 Core : j7-pru0_1-fw ICSSG0 RTU0 Core : j7-rtu0_0-fw ; RTU1 Core : j7-rtu0_1-fw ICSSG0 Tx_PRU0 Core : j7-txpru0_0-fw ; Tx_PRU1 Core : j7-txpru0_1-fw ICSSG1 PRU0 Core : j7-pru1_0-fw ; PRU1 Core : j7-pru1_1-fw ICSSG1 RTU0 Core : j7-rtu1_0-fw ; RTU1 Core : j7-rtu1_1-fw ICSSG1 Tx_PRU0 Core : j7-txpru1_0-fw ; Tx_PRU1 Core : j7-txpru1_1-fw Note: 1. The ICSSG INTC on J721E SoCs share all the host interrupts with other processors, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. 2. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210304160712.8452-3-s-anna@ti.com
2021-03-09arm64: dts: ti: k3-am65-main: Add ICSSG nodesSuman Anna1-0/+393
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems that are present on the K3 AM65x SoCs. The three ICSSGs are identical to each other for the most part, with the ICSSG2 supporting slightly enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance is represented by a PRUSS subsystem node. These nodes are enabled by default. The ICSSGs on K3 AM65x SoCs are super-sets of the PRUSS on the AM57xx/ 6AK2G SoCs except for larger Shared Data RAM and the lack of a PRU-ICSS crossbar. They include two auxiliary PRU cores called RTUs and few other additional sub-modules. The interrupt integration is also different on the K3 AM65x SoCs and are propagated through various SoC-level Interrupt Router and Interrupt Aggregator blocks. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP used on J721E SoCs, and has two new auxiliary PRU cores called Tx_PRUs. The Tx_PRUs have 6 KB of IRAMs and leverage the same host interrupts as the regular PRU cores. The Broadside (BS) RAM within each core is also sized differently w.r.t SR1.0. The ICSSG subsystem node contains the entire address space. The various sub-modules of the ICSSG are represented as individual child nodes (so platform devices themselves) of the PRUSS subsystem node. These include the various PRU cores and the interrupt controller. All the Data RAMs are represented within a child node of its own named 'memories' without any compatible. The Real Time Media Independent Interface controllers (MII_RT and MII_G_RT), and the CFG sub-module are represented as syscon nodes. The ICSSG CFG module has clock muxes for IEP clock and CORE clock, these clk nodes are added under the CFG child node 'clocks'. The default parents for these mux clocks are also assigned. The DT nodes use all standard properties. The regs property in the PRU/RTU/Tx_PRU nodes define the addresses for the Instruction RAM, the Debug and Control sub-modules for that PRU core. The firmware for each PRU/RTU/Tx_PRU core is defined through a 'firmware-name' property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : am65x-pru0_0-fw ; PRU1 Core : am65x-pru0_1-fw ICSSG0 RTU0 Core : am65x-rtu0_0-fw ; RTU1 Core : am65x-rtu0_1-fw ICSSG0 Tx_PRU0 Core : am65x-txpru0_0-fw ; Tx_PRU1 Core : am65x-txpru0_1-fw ICSSG1 PRU0 Core : am65x-pru1_0-fw ; PRU1 Core : am65x-pru1_1-fw ICSSG1 RTU0 Core : am65x-rtu1_0-fw ; RTU1 Core : am65x-rtu1_1-fw ICSSG1 Tx_PRU0 Core : am65x-txpru1_0-fw ; Tx_PRU1 Core : am65x-txpru1_1-fw ICSSG2 PRU0 Core : am65x-pru2_0-fw ; PRU1 Core : am65x-pru2_1-fw ICSSG2 RTU0 Core : am65x-rtu2_0-fw ; RTU1 Core : am65x-rtu2_1-fw ICSSG2 Tx_PRU0 Core : am65x-txpru2_0-fw ; Tx_PRU1 Core : am65x-txpru2_1-fw Note: 1. The ICSSG nodes are all added as per the SR2.0 device. Any sub-module IP differences need to be handled within the driver using SoC device match logic or separate dts/overlay files (if needs to be supported) with the Tx_PRU nodes expected to be disabled at the minimum. 2. The ICSSG INTC on AM65x SoCs share 5, 6, 7 host interrupts with other processors, so use the 'ti,irqs-reserved' property in derivative board dts files _if_ any of them should not be handled by the host OS. 3. There are few more sub-modules like the Industrial Ethernet Peripherals (IEPs), MDIO, PWM, UART that do not have bindings and so will be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210304160712.8452-2-s-anna@ti.com
2021-03-09arm64: dts: ti: k3-am642-sk: Add CPSW DT nodesVignesh Raghavendra1-0/+73
AM642 SK board has 2 CPSW3g ports connected through TI DP83867 PHYs. Add DT entries for the same. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-5-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodesVignesh Raghavendra1-0/+93
On am642-evm the CPSW3g ext. Port1 is directly connected to TI DP83867 PHY and Port2 is connected to TI DP83869 PHY which is shared with ICSS subsystem. The TI DP83869 PHY MII interface is configured using pinmux for CPSW3g, while MDIO bus is connected through GPIO controllable 2:1 TMUX154E switch (MDIO GPIO MUX) which has to be configured to route MDIO bus from CPSW3g to TI DP83869 PHY. Hence add networking support for am642-evm: - add CPSW3g MDIO and RGMII pinmux entries for both ext. ports; - add CPSW3g nodes; - add mdio-mux-multiplexer DT nodes to represent above topology. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-4-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: add main CPTS entryGrygorii Strashko1-0/+15
Add DT node for the Main domain CPTS. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-3-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: Add CPSW DT nodeVignesh Raghavendra2-0/+76
Add CPSW3g DT node with two external ports, MDIO and CPTS support. For CPSW3g DMA channels the ASEL is set to 15 (AM642x per DMA channel coherency feature), so that CPSW DMA channel participates in Coherency and thus avoid need to cache maintenance for SKBs. This improves bidirectional TCP performance by up to 100Mbps (on 1G link). Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210304211038.12511-2-grygorii.strashko@ti.com
2021-03-09arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodesJan Kiszka1-0/+2
This is demanded by the parent binding of ti,am654-pcie-rc, see Documentation/devicetree/bindings/pci/designware-pcie.txt. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/881dfd6c75423efce1d10261909939cd5ef19937.1613071976.git.jan.kiszka@siemens.com
2021-03-09arm64: dts: ti: Add support for AM642 SKLokesh Vutla2-0/+175
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20210226184251.26451-3-lokeshvutla@ti.com
2021-03-09dt-bindings: arm: ti: Add bindings for AM642 SKLokesh Vutla1-0/+1
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. Add DT binding documentation for AM642 SK. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210226184251.26451-2-lokeshvutla@ti.com
2021-03-09arm64: dts: ti: Add support for AM642 EVMDave Gerlach2-1/+249
The AM642 EValuation Module (EVM) is a board that provides access to various peripherals available on the AM642 SoC, such as PCIe, USB 2.0, CPSW Ethernet, ADC, and more. Introduce support for the AM642 EVM to enable mmc boot, including enabling UART and I2C on the board. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-6-d-gerlach@ti.com
2021-03-09arm64: dts: ti: k3-am64-main: Enable DMA supportPeter Ujfalusi1-0/+73
Add the nodes for DMSS INTA, BCDMA and PKTDMA to enable the use of the DMAs in the system. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-5-d-gerlach@ti.com
2021-03-09arm64: dts: ti: Add support for AM642 SoCDave Gerlach4-0/+576
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Introduce basic support for the AM642 SoC to enable ramdisk or MMC boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals under cbass_main and the i2c, spi, and uart MCU domain periperhals under cbass_mcu. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-4-d-gerlach@ti.com
2021-03-09dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64Dave Gerlach1-1/+4
Add pinctrl macros for AM64 SoC. These macro definitions are similar to that of previous platforms, but adding new definitions to avoid any naming confusions in the soc dts files. Unlike what checkpatch insists, we do not need parentheses enclosing the values for this macro as we do intend it to generate two separate values as has been done for other similar platforms. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210226144257.5470-3-d-gerlach@ti.com
2021-03-09dt-bindings: arm: ti: Add bindings for AM642 SoCDave Gerlach1-0/+6
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20210226144257.5470-2-d-gerlach@ti.com
2021-03-08arm64: dts: meson: add initial device-tree for Minix NEO U9-HChristian Hewitt2-0/+121
Minix NEO U9-H is based on the Amlogic Q200 reference board with an S912-H chip and the following specs: - 2GB DDR3 RAM - 16GB eMMC - 10/100/1000 Base-T Ethernet - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1) - RTC chip - HDMI 2.1 video - S/PDIF optical output - ES8323 audio codec - Analogue headphone output - 3x USB 2.0 ports (1x OTG) - IR receiver - 1x Power LED (white) - 1x Power button (rear) - 1x Update/Reset button (underside) - 1x micro SD card slot Tested-by: Wes Bradley <komplex@live.ie> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20210201210508.1528-2-christianshewitt@gmail.com
2021-03-08dt-bindings: arm: amlogic: add support for the Minix NEO U9-HChristian Hewitt1-0/+1
The Minix NEO U9-H is a small form-factor Android STB based on the Amlogic Q200 reference board with an S912-H chip. Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20210201210508.1528-1-christianshewitt@gmail.com
2021-03-08arm64: dts: zynqmp: Remove si5328 device nodesQuanyang Wang2-38/+2
The function of_i2c_get_board_info will call of_modalias_node to check if a device_node contains "compatible" string. But for the device si5328 at zcu102/zcu106 boards, there is no proper DT bindings for them. So remove si5328 device nodes from dts files to eliminate the error info in the boot message: i2c i2c-10: of_i2c: modalias failure on /axi/i2c@ff030000/i2c-mux@74/i2c@4/clock-generator@69 i2c i2c-10: Failed to create I2C device for /axi/i2c@ff030000/i2c-mux@74/i2c@4/clock-generator@69 Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Link: https://lore.kernel.org/r/20210308115437.2232847-1-quanyang.wang@windriver.com Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-03-08arm64: dts: zynqmp: Add power domain for the DisplayPort DMA controllerLaurent Pinchart1-0/+1
The DisplayPort DMA controller (DPDMA) is located in the same power domain as the DisplayPort Subsystem (DPSUB). Specify the power domain in the device tree. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20210306230915.14979-1-laurent.pinchart@ideasonboard.com Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2021-03-08arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connectionSamuel Holland3-37/+37
On boards where the only peripheral connected to PL0/PL1 is an X-Powers PMIC, configure the connection to use the RSB bus rather than the I2C bus. Compared to the I2C controller that shares the pins, the RSB controller allows a higher bus frequency, and it is more CPU-efficient. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210103100007.32867-5-samuel@sholland.org
2021-03-08ARM: dts: sunxi: h2-plus-bananapi-m2-zero: Add HDMI outPieter Beers1-0/+25
Add HDMI out, including the display engine, to the BananaPi M2 Zero. Signed-off-by: Pieter Beers <pjbrs@floorenpj.xs4all.nl> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210304191456.2895-2-pjbrs@floorenpj.xs4all.nl
2021-03-08bus: ti-sysc: Detect more modules for debuggingTony Lindgren1-0/+7
We want to see what the interconnect target module names are for debugging. Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-08bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices firstTony Lindgren1-0/+49
We want to probe l4_wkup and l4_cfg interconnect devices first to avoid issues with missing resources. Otherwise we attempt to probe l4_per devices first causing pointless deferred probe and also annoyingh renumbering of the MMC devices for example. Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-08bus: ti-sysc: Fix initializing module_pa for modules without sysc registerTony Lindgren1-3/+3
We have interconnect target modules with no known registers using only clocks and resets, but we still want to detect them based on the module IO range. So let's call sysc_parse_and_check_child_range() earlier so we have module_pa properly initialized. Fixes: 2928135c93f8 ("bus: ti-sysc: Support modules without control registers") Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-08Merge branch 'fixes-rc2' into fixesTony Lindgren11104-283140/+481171
2021-03-08ARM: dts: Fix moving mmc devices with aliases for omap4 & 5Tony Lindgren2-0/+10
Fix moving mmc devices with dts aliases as discussed on the lists. Without this we now have internal eMMC mmc1 show up as mmc2 compared to the earlier order of devices. Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-08ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable raceTony Lindgren1-8/+0
We have a duplicate legacy clock defined for sha2md5_fck that can sometimes race with clk_disable() with the dts configured clock for OMAP4_SHA2MD5_CLKCTRL when unused clocks are disabled during boot causing an "Unhandled fault: imprecise external abort". Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-08arm64: dts: renesas: Add mmc aliases into board dts filesYoshihiro Shimoda9-0/+23
After the commit 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14"), the order of /dev/mmcblkN was not fixed in some SoCs which have multiple sdhi controllers. So, we were hard to use an sdhi device as rootfs by using the kernel parameter like "root=/dev/mmcblkNpM". According to the discussion on a mainling list [1], we can add mmc aliases to fix the issue. So, add such aliases into Renesas arm64 board dts files. Notes that mmc0 is an eMMC channel if available. [1] https://lore.kernel.org/linux-arm-kernel/CAPDyKFptyEQNJu8cqzMt2WRFZcwEdjDiytMBp96nkoZyprTgmA@mail.gmail.com/ Fixes: 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1614596786-22326-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-03-08arm64: dts: renesas: r8a77961-ulcb: add HDMI Display supportYuya Hamamachi1-0/+11
This patch enables HDMI Display on M3ULCB with R-Car M3-W+. Signed-off-by: Yuya Hamamachi <yuya.hamamachi.sx@renesas.com> Link: https://lore.kernel.org/r/20210217090603.1517-1-yuya.hamamachi.sx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-03-08ARM: dts: renesas: Add mmc aliases into R-Car Gen2 board dts filesYoshihiro Shimoda6-0/+16
After set PROBE_PREFER_ASYNCHRONOUS flag on the mmc host drivers, the order of /dev/mmcblkN was not fixed in some SoCs which have multiple SDHI and/or MMCIF controllers. So, we were hard to use such a device as rootfs by using the kernel parameter like "root=/dev/mmcblkNpM". According to the discussion on a mainling list [1], we can add mmc aliases to fix the issue. So, add such aliases into R-Car Gen2 board dts files. Note that, since R-Car Gen2 is even more complicated about SDHI and/or MMCIF channels variations and they share pins, add the aliases into board dts files instead of SoC dtsi files. [1] https://lore.kernel.org/linux-arm-kernel/CAPDyKFptyEQNJu8cqzMt2WRFZcwEdjDiytMBp96nkoZyprTgmA@mail.gmail.com/ Fixes: 7320915c8861 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14") Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1613131316-30994-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-03-08arm64: dts: renesas: Group tuples in pin control propertiesGeert Uytterhoeven6-6/+6
To improve human readability and enable automatic validation, the tuples in "pinctrl-*" properties should be grouped using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210204130517.1647073-6-geert+renesas@glider.be
2021-03-08arm64: dts: renesas: Group tuples in playback and capture propertiesGeert Uytterhoeven5-8/+8
To improve human readability and enable automatic validation, the tuples in "playback" and "capture" properties in sound device nodes should be grouped using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210204130517.1647073-5-geert+renesas@glider.be
2021-03-08ARM: dts: renesas: Group tuples in pin control propertiesGeert Uytterhoeven11-18/+18
To improve human readability and enable automatic validation, the tuples in "pinctrl-*" properties should be grouped using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210204130517.1647073-4-geert+renesas@glider.be
2021-03-08ARM: dts: renesas: Group tuples in playback and capture propertiesGeert Uytterhoeven6-12/+12
To improve human readability and enable automatic validation, the tuples in "playback" and "capture" properties in sound device nodes should be grouped using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210204130517.1647073-3-geert+renesas@glider.be
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 19:19:20 +0300