summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-08arm64: dts: renesas: falcon-cpu: Add SPI flash via RPCWolfram Sang1-0/+33
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20211006085836.42155-5-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-10-08arm64: dts: renesas: r8a779a0: Add RPC nodeDuc Nguyen1-0/+17
Add device node for RPC on R8A779A0 SoC. Signed-off-by: Duc Nguyen <duc.nguyen.ub@renesas.com> [wsa: rebased] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20211006085836.42155-4-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-10-08arm64: dts: renesas: r9a07g044: Add SPI Multi I/O Bus controller nodeLad Prabhakar1-0/+17
Add SPI Multi I/O Bus controller node to R9A07G044 (RZ/G2L) SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210928155852.32569-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-10-08arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0Enric Balletbo i Serra2-1/+5
Reset the DSI hardware is needed to prevent different settings between the bootloader and the kernel. While here, also remove the undocumented and also not used 'mediatek,syscon-dsi' property. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210930103105.v4.5.I933f1532d7a1b2910843a9644c86a7d94a4b44e1@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-10-08arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0Enric Balletbo i Serra2-0/+4
Reset the DSI hardware is needed to prevent different settings between the bootloader and the kernel. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210930103105.v4.4.I7bd7d9a8da5e2894711b700a1127e6902a2b2f1d@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-10-08dt-bindings: display: mediatek: add dsi reset optional propertyEnric Balletbo i Serra1-0/+6
Update device tree binding documentation for the dsi to add the optional property to reset the dsi controller. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210930103105.v4.3.Ifec72a83f224b62f24cfc967edfe78c5d276b2e3@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-10-08dt-bindings: mediatek: Add #reset-cells to mmsys system controllerEnric Balletbo i Serra1-0/+4
The mmsys system controller exposes a set of memory client resets and needs to specify the #reset-cells property in order to advertise the number of cells needed to describe each of the resets. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210930103105.v4.2.I3f7f1c9a8e46be07d1757ddf4e0097535f3a7d41@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-10-08arm64: dts: mediatek: Move reset controller constants into common locationEnric Balletbo i Serra5-4/+4
The DT binding includes for reset controllers are located in include/dt-bindings/reset/. Move the Mediatek reset constants in there. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20210930103105.v4.1.I514d9aafff3a062f751b37d3fea7402f67595b86@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-10-08ARM: dts: aspeed: p10bmc: Define secure boot gpioJoel Stanley2-2/+2
Input pin that indicates that the BMC is configured to boot with security protections enforced. Pulled up by default (secure). Placing the jumper will pull the pin down (bypass security). When in the secure boot state, it makes the EEPROM at 0x50 on bus 14 read only. Link: https://lore.kernel.org/r/20210923074606.283393-1-joel@jms.id.au Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-10-08ARM: dts: aspeed: mtjade: Add some gpiosQuan Nguyen1-1/+20
Add S0_SCP_AUTH_FAIL, S1_SCP_AUTH_FAIL gpios to indicates firmware authentication fail on each socket. Add gpio RTC_BAT_SEN_EN to enable RTC battery adc sensor. Add BMC_I2C4_O_EN gpio to go high at boot to enable access to I2C4 bus. Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> Signed-off-by: Thang Nguyen <thang@os.amperecomputing.com> Link: https://lore.kernel.org/r/20210917082945.19111-1-quan@os.amperecomputing.com Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-10-07dt-bindings: PCI: tegra194: Fix PCIe endpoint node namesMauro Carvalho Chehab1-1/+1
As defined by Documentation/devicetree/bindings/pci/pci-ep.yaml, PCIe endpoints match this pattern: properties: $nodename: pattern: "^pcie-ep@" Change the existing ones in the DT bindings examples to avoid warnings during DT bindings validation. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07arm64: tegra: Fix pcie-ep DT nodesMauro Carvalho Chehab3-5/+5
As defined by Documentation/devicetree/bindings/pci/pci-ep.yaml, PCIe endpoints match this pattern: properties: $nodename: pattern: "^pcie-ep@" Change the existing ones in order to avoid those warnings: arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0001.dt.yaml: pcie_ep@14160000: $nodename:0: 'pcie_ep@14160000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0001.dt.yaml: pcie_ep@14180000: $nodename:0: 'pcie_ep@14180000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0001.dt.yaml: pcie_ep@141a0000: $nodename:0: 'pcie_ep@141a0000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dt.yaml: pcie_ep@14160000: $nodename:0: 'pcie_ep@14160000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dt.yaml: pcie_ep@14180000: $nodename:0: 'pcie_ep@14180000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p3509-0000+p3668-0000.dt.yaml: pcie_ep@141a0000: $nodename:0: 'pcie_ep@141a0000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dt.yaml: pcie_ep@14160000: $nodename:0: 'pcie_ep@14160000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dt.yaml: pcie_ep@14180000: $nodename:0: 'pcie_ep@14180000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dt.yaml: pcie_ep@141a0000: $nodename:0: 'pcie_ep@141a0000' does not match '^pcie-ep@' From schema: Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07arm64: tegra: Remove useless usb-ehci compatible stringThierry Reding2-5/+5
There's no such thing as a generic USB EHCI controller. The EHCI controllers found on Tegra SoCs are instantiations that need Tegra- specific glue to work properly, so drop the generic compatible string and keep only the Tegra-specific ones. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07ARM: tegra: Remove useless usb-ehci compatible stringThierry Reding4-12/+11
There's no such thing as a generic USB EHCI controller. The EHCI controllers found on Tegra SoCs are instantiations that need Tegra- specific glue to work properly, so drop the generic compatible string and keep only the Tegra-specific ones. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07arm64: tegra: Extend APE audio support on Jetson platformsSameer Pujar5-0/+5481
Extend APE audio support by adding more audio components such as SFC, MVC, AMX, ADX and Mixer. These components can be plugged into an audio path and required processing can be done. ASoC audio-graph based sound driver is used to facilitate this and thus extend sound bindings as well. The components in the path may require different PCM parameters (such as sample rate, channels or sample size). Depending on the pre-defined audio paths, these can be statically configured with "convert-xxx" DT properties in endpoint subnode. The support for the rate and channel conversion is already available in generic audio-graph driver. Sample size conversion support can be added based on the need in future. The support is extended for following platforms: * Jertson TX1 * Jetson Nano * Jetson TX2 * Jetson AGX Xavier * Jetson Xavier NX Signed-off-by: Sameer Pujar <spujar@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07arm64: tegra: Add few AHUB devices for Tegra210 and laterSameer Pujar3-0/+313
Add DT nodes for following AHUB devices: * SFC (Sampling Frequency Converter) * MVC (Master Volume Control) * AMX (Audio Multiplexer) * ADX (Audio Demultiplexer) * Mixer Above devices are added for Tegra210, Tegra186 and Tegra194 generations of Tegra SoC. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07arm64: tegra: Remove unused backlight-boot-off propertyDavid Heidelberg1-2/+0
The backlight-boot-off property was proposed as a patch, but ended not being accepted since different solution was already in the place: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1406806970-12561-1-git-send-email-thierry.reding@gmail.com/#21327479 Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-07ARM: tegra: Remove unused backlight-boot-off propertyDavid Heidelberg1-2/+0
The backlight-boot-off property was proposed as a patch, but ended not being accepted since different solution was already in the place: https://patchwork.kernel.org/project/linux-arm-kernel/patch/1406806970-12561-1-git-send-email-thierry.reding@gmail.com/#21327479 Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-06arm64: tegra: Add NVDEC to Tegra186/194 device treesMikko Perttunen2-0/+54
Add a device tree node for NVDEC on Tegra186, and device tree nodes for NVDEC and NVDEC1 on Tegra194. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-06dt-bindings: Add YAML bindings for NVDECMikko Perttunen2-0/+107
Add YAML device tree bindings for NVDEC, now in a more appropriate place compared to the old textual Host1x bindings. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-10-06arm64: dts: broadcom: Add reference to RPi CM4 IO BoardStefan Wahren2-0/+3
This adds a reference to the dts of the Raspberry Pi Compute Module 4 IO Board, so we don't need to maintain the content in arm64. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1628334401-6577-11-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06ARM: dts: Add Raspberry Pi Compute Module 4 IO BoardStefan Wahren2-0/+139
This adds the matching carrier for Raspberry Pi Compute Module 4. Instead of xHCI USB host controller there is just a USB 2.0 interface connected to the DWC2 controller from the BCM2711. As a result there is a free PCIe Gen 2 socket. Also there are 2 full-size HDMI 2.0 connectors. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1628334401-6577-10-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06ARM: dts: Add Raspberry Pi Compute Module 4Stefan Wahren1-0/+113
The Raspberry Pi Compute Module 4 (CM4) are SoMs which contain the following: * BCM2711 quad core processor * up to 8 GB RAM * up to 32 GB eMMC * a GPIO expander * Gigabit PHY BCM54210PE * Wifi/BT module with internal and external antenna The eMMC and the Wifi/BT module are optional. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1628334401-6577-9-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06dt-bindings: arm: bcm2835: Add Raspberry Pi Compute Module 4Stefan Wahren1-0/+1
Add the Raspberry Pi Compute Module 4 to DT schema. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1628334401-6577-8-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06ARM: dts: bcm283x-rpi: Move Wifi/BT into separate dtsiStefan Wahren6-137/+74
A Wifi/BT chip is quite common for the Raspberry Pi boards. So move those definitions into a separate dtsi in order to avoid copy & paste. This change was inspired by a vendor tree patch from Phil Elwell. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1628334401-6577-7-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06dt-bindings: display: bcm2835: add optional property power-domainsStefan Wahren4-0/+12
The Raspberry Pi boards with BCM283x needs control of the power domains to get display components running. DT schema warns us that it's used, but not documented as a optional property: hdmi@7e902000: 'power-domains' does not match any of the regexes: ... Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1628334401-6577-4-git-send-email-stefan.wahren@i2se.com Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
2021-10-06ARM: dts: dra7: add entry for bb2d moduleGowtham Tammana1-0/+19
BB2D is a Vivante GC 2D Accelerator. This adds the node to the dts file within a target module node. Crossbar index number is used for interrupt mapping. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm: dts: omap3-gta04: cleanup led node namesAndreas Kemnade1-5/+6
Change led node names to match schema. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm: dts: omap3-gta04a4: accelerometer irq fixAndreas Kemnade1-1/+1
Fix typo in pinctrl. It did only work because the bootloader seems to have initialized it. Fixes: ee327111953b ("ARM: dts: omap3-gta04: Define and use bma180 irq pin") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm: dts: omap3-gta04a5: fix missing sensor supplyAndreas Kemnade1-0/+2
Add mandatory supply properties. The supply is always on, so it is just a syntax issue, no functional change. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm: dts: omap3-gta04: fix missing sensor supplyAndreas Kemnade1-0/+2
Add mandatory supply properties. The supply is always on, so it is just a syntax issue, no functional change. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm: dts: omap3-gta04: cleanup LCD definitionAndreas Kemnade1-4/+4
Replace depreciated nodenames, fix label name to match scheme. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06ARM: dts: omap3: fix cpu thermal label nameAndreas Kemnade1-1/+1
Hyphens should be used in label names. make dtbs_check complains about that since it does not match the corresponding pattern Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06ARM: dts: am335x-pocketbeagle: switch to pinconf-singleDrew Fustini1-0/+1
Switch the compatible for the am33xx_pinmux pin controller node from pinctrl-single to pinconf-single. The only change between these two compatibles is that PCS_HAS_PINCONF will be true. This then allows pinconf properties to be utilized. The purpose of this change is to allow the PocketBeagle to use: pinctrl-single,bias-pullup pinctrl-single,bias-pulldown This dts already defines these properites for gpio pins in the default pinctrl state but it has no effect unless PCS_HAS_PINCONF is set. The bias properties can then be modified on the corresponding gpio lines through the gpiod uapi. The mapping between the pins and gpio lines is defined by gpio-ranges under the gpio controller nodes in am33xx-l4.dtsi Signed-off-by: Drew Fustini <drew@pdp7.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-10-06arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodesSinthu Raja1-0/+144
Two carveout reserved memory nodes each have been added for each of the other remote processors devices within the MAIN domain on the TI J721E 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 C71x DSP processor does support a MMU called CMMU, but is not currently supported and as such requires the exact memory used by the firmware 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 Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-5-sinthu.raja@ti.com
2021-10-06arm64: dts: ti: k3-j721e-sk: Add IPC sub-mailbox nodesSinthu Raja1-0/+129
Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the J721E SoCs to the J721E EAIK board. These include the R5F remote processors in the dual-R5F cluster (MCU_R5FSS0) in the MCU domain and the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; the two C66x DSP remote processors and the single C71x DSP remote processor in the MAIN domain. These sub-mailbox nodes utilize the System Mailbox clusters 0 through 4. All the remaining mailbox clusters are currently not used on A72 core, and are hence disabled. The sub-mailbox nodes added match the hard-coded mailbox configuration used within the TI RTOS IPC software packages. The R5F processor sub-systems are assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. Only the sub-mailbox node for the first R5F core in each cluster is used in case of a Lockstep mode for that R5F cluster. Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-4-sinthu.raja@ti.com
2021-10-06arm64: dts: ti: Add support for J721E SKSinthu Raja2-0/+730
J721E Starter Kit (SK)[1] is a low cost, small form factor board designed for TI’s J721E SoC. TI’s J721E SoC comprises of dual core A72, high performance vision accelerators, video codec accelerators, latest C71x and C66x DSP, high bandwidth real-time IPs for capture and display, GPU, dedicated safety island and security accelerators. The SoC is power optimized to provide best in class performance for industrial and automotive applications. J721E SK supports the following interfaces: * 4 GB LPDDR4 RAM * x1 Gigabit Ethernet interface * x1 USB 3.0 Type-C port * x3 USB 3.0 Type-A ports * x1 PCIe M.2 E Key * x1 PCIe M.2 M Key * 512 Mbit OSPI flash * x2 CSI2 Camera interface (RPi and TI Camera connector) * 40-pin Raspberry Pi GPIO header Add basic support for J721E-SK. [1] https://www.ti.com/tool/SK-TDA4VM Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-3-sinthu.raja@ti.com
2021-10-06dt-bindings: arm: ti: Add compatible for J721E SKSinthu Raja1-0/+1
J721E Starter Kit (SK)[1] is a low cost, small form factor board designed for TI’s J721E SoC. Add j721e-sk into compatible enum. [1]https://www.ti.com/tool/SK-TDA4VM Signed-off-by: Sinthu Raja <sinthu.raja@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210929081333.26454-2-sinthu.raja@ti.com
2021-10-06arm64: dts: ti: iot2050: Add support for product generation 2 boardsJan Kiszka4-0/+106
This adds the devices trees for IOT2050 Product Generation 2 (PG2) boards. We have Basic and an Advanced variants again, differing in number of cores, RAM size, availability of eMMC and further details. The major difference to PG1 is the used silicon revision (SR2.x on PG2). Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/cc868da8264324bde2c87d0c01d4763e3678c706.1632657917.git.jan.kiszka@web.de
2021-10-06arm64: dts: ti: iot2050: Prepare for adding 2nd-generation boardsJan Kiszka6-125/+178
The current IOT2050 devices are Product Generation 1 (PG1), using SR1.0 AM65x silicon. Upcoming PG2 devices will use SR2.x SoCs and will therefore need separate device trees. Prepare for that by factoring out common bits that will be shared across both generations. At this chance, drop a link to the product homepage to in the top-level dts files. Also fix a typo in my email address in some headers. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/31fece05f9728a852c0632985c4fa537cced4ece.1632657917.git.jan.kiszka@web.de
2021-10-06dt-bindings: arm: ti: Add bindings for Siemens IOT2050 PG2 boardsJan Kiszka1-0/+2
Product Generation 2 (PG2) boards are based on SR2.x SoCs and will be released soon. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/5d99e69ff1e2fb78f51f03c351eff1fe1f6c3a71.1632657917.git.jan.kiszka@web.de
2021-10-06arm64: dts: ti: iot2050: Add/enabled mailboxes and carve-outs for R5F coresJan Kiszka1-2/+24
Analogously to the am654-base-board, configure the mailboxes for the two R5F cores, add them and the already existing memory carve-outs to the related MCU nodes. Allows to load applications under Linux onto the cores, e.g. the RTI watchdog firmware. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/1776f8be19b39a938d9248fcfc5332b753783c3e.1632657917.git.jan.kiszka@web.de
2021-10-06arm64: dts: ti: iot2050: Disable SR2.0-only PRUsJan Kiszka1-0/+24
The IOT2050 devices described so far are using SR1.0 silicon, thus do not have the additional PRUs of the ICSSG of the SR2.0. Disable them. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Aswath Govindraju <a-govindraju@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/189a91866fb1af02e4fd2345dc56774aa069d5ba.1632657917.git.jan.kiszka@web.de
2021-10-06arm64: dts: ti: iot2050: Flip mmc device ordering on Advanced devicesJan Kiszka1-0/+2
This ensures that the SD card will remain mmc0 across Basic and Advanced devices, also avoiding surprises for users coming from the downstream kernels. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/fe20d6346f119a28e47d129b616682001299cf0e.1632657917.git.jan.kiszka@web.de
2021-10-06arm64: dts: ti: k3-j7200-common-proc-board: Add j7200-evm compatibleNishanth Menon1-0/+3
Add j7200-evm compatible to the board to allow the board to distinguish itself from other platforms that may be added in the future. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210925201430.11678-5-nm@ti.com
2021-10-06arm64: dts: ti: k3-j721e-common-proc-board: Add j721e-evm compatibleNishanth Menon1-0/+3
Add j721e-evm compatible to the board to allow the board to distinguish itself from other platforms that are pending to be added. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210925201430.11678-4-nm@ti.com
2021-10-06dt-bindings: arm: ti: Add missing compatibles for j721e/j7200 evmsNishanth Menon1-2/+10
Add compatibles for j721e and j7200 evms to allow for newer platforms to distinguish themselves. While doing this, maintain support for older style of description where the board compatibility was not required. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210925201430.11678-2-nm@ti.com
2021-10-06arm64: dts: ti: Makefile: Collate AM64 platforms togetherNishanth Menon1-1/+0
Make sure that the platforms are grouped together per SoC. This helps keep the Makefile readable as newer platforms get added to the list. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210915121442.27112-1-nm@ti.com
2021-10-06arm64: dts: ti: k3-am64-main: Add ICSSG nodesSuman Anna3-0/+296
Add the DT nodes for the ICSSG0 and ICSSG1 processor subsystems that are present on the K3 AM64x SoCs. The two ICSSGs are identical to each other for the most part, with some of the peripheral pins from ICSSG1 not pinned out. Each ICSSG instance is represented by a PRUSS subsystem node and other child nodes. The nodes are all added and enabled in the common k3-am64-main.dtsi file by default. The MDIO 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. These are disabled in the existing AM64x board dts files to begin with. The ICSSGs on K3 AM64x SoCs are very similar to the versions of the ICSSG on K3 J721E and AM65x SR2.0 SoCs. The IRAM and BroadSize RAM sizes are all identical to those on J721E SoCs. 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: - two Programmable Real-Time Units (PRUs) - two auxiliary PRU cores called RTUs - two Transmit Programmable Real-Time Units (Tx_PRUs) - Interrupt controller (INTC) - a 'memories' node containing all the ICSSG level Data RAMs - Real Time Media Independent Interface controller (MII_RT) - Gigabit capable MII_G_RT - ICSSG CFG sub-module providing two internal clock muxes, with the default clock parents also assigned using the assigned-clock-parents property. The default names for the firmware images for each PRU, RTU and Tx_PRU cores are defined as follows using the 'firmware-name' property (these can be adjusted either in derivative board dts files or through sysfs at runtime if required): ICSSG0 PRU0 Core : am64x-pru0_0-fw ; PRU1 Core : am64x-pru0_1-fw ICSSG0 RTU0 Core : am64x-rtu0_0-fw ; RTU1 Core : am64x-rtu0_1-fw ICSSG0 Tx_PRU0 Core : am64x-txpru0_0-fw ; Tx_PRU1 Core : am64x-txpru0_1-fw ICSSG1 PRU0 Core : am64x-pru1_0-fw ; PRU1 Core : am64x-pru1_1-fw ICSSG1 RTU0 Core : am64x-rtu1_0-fw ; RTU1 Core : am64x-rtu1_1-fw ICSSG1 Tx_PRU0 Core : am64x-txpru1_0-fw ; Tx_PRU1 Core : am64x-txpru1_1-fw Note: 1. The ICSSG INTC on AM64x 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), eCAP, 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: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210919202935.15604-1-s-anna@ti.com
2021-10-05Merge tag 'renesas-dt-bindings-for-v5.16-tag1' of ↵Arnd Bergmann1-0/+61
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt Renesas DT binding updates for v5.16 - Document support for the new R-Car H3e, M3e, M3Ne(-2G), D3e, E3e, and H3Ne SoCs and boards. * tag 'renesas-dt-bindings-for-v5.16-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: dt-bindings: arm: renesas: Document more R-Car Gen3e Socs and boards Link: https://lore.kernel.org/r/cover.1633081158.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 02:14:59 +0300