aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-10-11dt-bindings: net: Remove gpmc-eth.txtRoger Quadros1-97/+0
There is no GPMC Ethernet compatible or device driver. GPMC is just a bus interface over which devices like Ethernet controller can be to. For SMSC 911x Ethernet chip bindings, please refer to Documentation/devicetree/bindings/net/smsc,lan9115.yaml Signed-off-by: Roger Quadros <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-10-11dt-bindings: mtd: Remove gpmc-nor.txtRoger Quadros1-98/+0
There is no GPMC NOR compatible or device driver. GPMC is just a bus interface over which standard (CFI/JEDC) NOR Flash chips can be attached. For NOR chip bindings, please refer to Documentation/devicetree/bindings/mtd/mtd-physmap.yaml Signed-off-by: Roger Quadros <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-10-11arm64: dts: renesas: rzg2l-smarc: Enable microSD on SMARC platformBiju Das1-0/+62
This patch enables microSD card slot connected to SDHI1 on RZ/G2L SMARC platform. Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2021-10-11arm64: dts: renesas: rzg2l-smarc-som: Enable eMMC on SMARC platformBiju Das1-0/+143
RZ/G2L SoM has both 64 GB eMMC and microSD connected to SDHI0. Both these interfaces are mutually exclusive and the SD0 device selection is based on the XOR between GPIO_SD0_DEV_SEL and SW1[2] switch position. This patch sets GPIO_SD0_DEV_SEL to high in DT. Use the below switch setting logic for device selection between eMMC and microSD slot connected to SDHI0. Set SW1[2] to position 2/OFF for selecting eMMC Set SW1[2] to position 3/ON for selecting microSD This patch enables eMMC on RZ/G2L SMARC platform by default. Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2021-10-08Merge tag 'tags/bcm2835-dt-next-2021-10-06' into devicetree/nextFlorian Fainelli16-137/+342
Stefan Wahren adds devicetree support for the Raspbery Pi Compute Module 4 and its IO board Signed-off-by: Florian Fainelli <[email protected]>
2021-10-08dt-bindings: arm: Add MT6589 Fairphone 1Luca Weiss1-0/+1
Add the compatible for Fairphone 1 smartphone with MT6589 SoC. Signed-off-by: Luca Weiss <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]>
2021-10-08arm64: dts: renesas: r9a07g044: Add SDHI nodesBiju Das1-0/+32
Add SDHI{0, 1} nodes to RZ/G2L SoC DTSI. Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2021-10-08arm64: dts: renesas: falcon-cpu: Add SPI flash via RPCWolfram Sang1-0/+33
Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
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 <[email protected]> [wsa: rebased] Signed-off-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
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 <[email protected]> Reviewed-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20210930103105.v4.5.I933f1532d7a1b2910843a9644c86a7d94a4b44e1@changeid Signed-off-by: Matthias Brugger <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20210930103105.v4.4.I7bd7d9a8da5e2894711b700a1127e6902a2b2f1d@changeid Signed-off-by: Matthias Brugger <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20210930103105.v4.3.Ifec72a83f224b62f24cfc967edfe78c5d276b2e3@changeid Signed-off-by: Matthias Brugger <[email protected]>
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 <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/20210930103105.v4.2.I3f7f1c9a8e46be07d1757ddf4e0097535f3a7d41@changeid Signed-off-by: Matthias Brugger <[email protected]>
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 <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Link: https://lore.kernel.org/r/20210930103105.v4.1.I514d9aafff3a062f751b37d3fea7402f67595b86@changeid Signed-off-by: Matthias Brugger <[email protected]>
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/[email protected] Signed-off-by: Joel Stanley <[email protected]>
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 <[email protected]> Signed-off-by: Thang Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joel Stanley <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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/[email protected]/#21327479 Signed-off-by: David Heidelberg <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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/[email protected]/#21327479 Signed-off-by: David Heidelberg <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
2021-10-06ARM: dts: bcm2711-rpi-4-b: fix sd_io_1v8_reg regulator statesStefan Wahren1-2/+2
DT schema check complains at sd_io_1v8_reg about the following: [1800000, 1, 3300000, 0] is too long Additional items are not allowed (3300000, 0 were unexpected) So fix the states definition. Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
2021-10-06ARM: dts: bcm2711: fix MDIO #address- and #size-cellsStefan Wahren1-2/+2
The values of #address-cells and #size-cells are swapped. Fix this and avoid the following DT schema warnings for mdio@e14: #address-cells:0:0: 1 was expected #size-cells:0:0: 0 was expected Fixes: be8af7a9e3cc ("ARM: dts: bcm2711-rpi-4: Enable GENET support") Signed-off-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
2021-10-06ARM: dts: bcm283x: Fix VEC address for BCM2711Mateusz Kwiatkowski3-8/+16
The VEC has a different address (0x7ec13000) on the BCM2711 (used in e.g. Raspberry Pi 4) compared to BCM283x (e.g. Pi 3 and earlier). This was erroneously not taken account for. Definition of the VEC in the devicetrees had to be moved from bcm283x.dtsi to bcm2711.dtsi and bcm2835-common.dtsi to allow for this differentiation. Fixes: 7894bdc6228f ("ARM: boot: dts: bcm2711: Add BCM2711 VEC compatible") Signed-off-by: Mateusz Kwiatkowski <[email protected]> Signed-off-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]>
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 <[email protected]> Signed-off-by: Jyri Sarha <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-10-05arm64: 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 <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-10-05arm64: 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 <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-10-05arm64: 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 <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-10-05dt-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 <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-10-05arm64: 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 <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/cc868da8264324bde2c87d0c01d4763e3678c706.1632657917.git.jan.kiszka@web.de
2021-10-05arm64: 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 <[email protected]> Signed-off-by: Nishanth Menon <[email protected]> Link: https://lore.kernel.org/r/31fece05f9728a852c0632985c4fa537cced4ece.1632657917.git.jan.kiszka@web.de