Linus Walleij [Wed, 6 Oct 2021 22:40:08 +0000 (00:40 +0200)]
ARM: dts: ux500: Switch battery nodes to standard
This force-converts the per-device battery node into the standard
properties using "simple-battery" for the HREF machines and the
corresponding Samsung battery for the mobile phones.
This is fine to do since the battery data in the DTS files has never
been deployed or used. In commit a1149ae97554
"ARM: ux500: Disable Power Supply and Battery Management by default"
it was turned off and has not been switched back on since. In
the meantime standardized bindings for batteries have appeared
making the old AB8500 battery bindings obsolete.
The battery node which is now in the middle of an included file
is obviously a per-device piece of information so push this down
to each board. The HREF machines all have the same battery and can
share a single node in the HREF dtsi file.
Niklas Söderlund [Tue, 12 Oct 2021 18:34:31 +0000 (20:34 +0200)]
arm64: dts: renesas: Add ports node to all adv7482 nodes
The different port@ entries of the adv7482 nodes shall be encapsulated
in a ports node, add one. This change does not change how the driver
parses the DT and no driver change is needed.
The change however makes it possible to validate the source files with a
correct json-schema.
The 'microchip,24c02' compatible does not match the at24 driver, so
add this generic fallback to the device node compatible string to
make the device to match the driver using the OF device ID table.
Also set this eeprom to read-only mode because it stores the mac
address of the onboard usb network card.
Marcel Ziswiler [Thu, 7 Oct 2021 20:56:59 +0000 (22:56 +0200)]
ARM: dts: mvebu: add device tree for netgear gs110emx switch
Add the device tree for a Netgear GS110EMX switch featuring 8 Gigabit
ports and 2 Multi-Gig ports (100M/1G/2.5G/5G/10G). An 88E6390X switch
sits at its core connecting to two 88X3310P 10G PHYs. The control plane
is handled by an 88F6811 Armada 381 SoC.
The following functionality is tested:
- 8 gigabit Ethernet ports connecting via 88E6390X to the 88F6811
- serial console UART
- 128 MB commercial grade DDR3L SDRAM
- 16 MB serial SPI NOR flash
The two 88X3310P 10G PHYs while detected during boot seem neither to
detect any link nor pass any traffic.
The unit address is supposed to represent '<device>,<function>'. Which
are both 0 for RPi4b's XHCI controller. On top of that although
OpenFirmware states bus number goes in the high part of the last reg
parameter, FDT doesn't seem to care for it[1], so remove it.
ARM: dts: bcm2711-rpi-4-b: Fix pcie0's unit address formatting
dtbs_check currently complains that:
arch/arm/boot/dts/bcm2711-rpi-4-b.dts:220.10-231.4: Warning
(pci_device_reg): /scb/pcie@7d500000/pci@1,0: PCI unit address format
error, expected "0,0"
Unsurprisingly pci@0,0 is the right address, as illustrated by its reg
property:
&pcie0 {
pci@0,0 {
/*
* As defined in the IEEE Std 1275-1994 document,
* reg is a five-cell address encoded as (phys.hi
* phys.mid phys.lo size.hi size.lo). phys.hi
* should contain the device's BDF as 0b00000000
* bbbbbbbbdddddfff00000000. The other cells
* should be zero.
*/
reg = <0 0 0 0 0>;
};
};
Arnd Bergmann [Tue, 12 Oct 2021 12:51:23 +0000 (14:51 +0200)]
Merge tag 'ti-k3-dt-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/dt
Devicetree changes for TI K3 platforms for v5.16 merge window:
* New Platforms:
- AM654: Siemens IOT2050 PG2 boards
- J721E: Low cost SK board
* New features:
- mmc aliases introduced
- AM64 ICSSG nodes, mcu pinctrl added
* Fixes:
- Schema fixups for pcie, thermal zones
- Fixup to include board specific property for J721e-evm and j7200-evm
- Misc fixups including cleaning up order in Makefile
* tag 'ti-k3-dt-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux: (24 commits)
arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodes
arm64: dts: ti: k3-j721e-sk: Add IPC sub-mailbox nodes
arm64: dts: ti: Add support for J721E SK
dt-bindings: arm: ti: Add compatible for J721E SK
arm64: dts: ti: iot2050: Add support for product generation 2 boards
arm64: dts: ti: iot2050: Prepare for adding 2nd-generation boards
dt-bindings: arm: ti: Add bindings for Siemens IOT2050 PG2 boards
arm64: dts: ti: iot2050: Add/enabled mailboxes and carve-outs for R5F cores
arm64: dts: ti: iot2050: Disable SR2.0-only PRUs
arm64: dts: ti: iot2050: Flip mmc device ordering on Advanced devices
arm64: dts: ti: k3-j7200-common-proc-board: Add j7200-evm compatible
arm64: dts: ti: k3-j721e-common-proc-board: Add j721e-evm compatible
dt-bindings: arm: ti: Add missing compatibles for j721e/j7200 evms
arm64: dts: ti: Makefile: Collate AM64 platforms together
arm64: dts: ti: k3-am64-main: Add ICSSG nodes
arm64: dts: ti: k3-am65: Relocate thermal-zones to SoC specific location
arm64: dts: ti: ti-k3*: Introduce aliases for mmc nodes
arm64: dts: ti: k3-am65-main: Cleanup "ranges" property in "pcie" DT node
arm64: dts: ti: j7200-main: Add *max-virtual-functions* for pcie-ep DT node
arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIe
...
Chanho Park [Tue, 12 Oct 2021 00:23:14 +0000 (09:23 +0900)]
arm64: dts: exynos: add minimal support for exynosautov9 sadk board
SADK(Samsung Automotive Development Kit) is the development kit to
evaluate Exynos Auto v9 SoC. It has 16GB LPDDR4 DRAM and two
256GB Samsung UFS. This patch enables only serial console and ufs0
device.
Chanho Park [Tue, 12 Oct 2021 00:23:13 +0000 (09:23 +0900)]
arm64: dts: exynos: add initial support for exynosautov9 SoC
Add minimal support for ExynosAuto v9 SoC[1].
- Enumarate all pinctrl nodes
- UART with exynos850 compatible
- UFS0 HCI + Phy
Like exynos850, this also uses fixed-rate clock nodes until clock driver
has been supported. The clock nodes are initialized on bootloader stage
thus we don't need to control them so far.
Add the power-config-full-load described in:
https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md#power-config-full-load
The power-config-full-load gpio is designed to be used to specify how
many power supplies the system should have, in rainier it is 2 or 4. If
enough power supplies fail so that the system no longer has redundancy
(no longer n+1), the hardware will signal to the Onboard Chip Controller
that the system may be oversubscribed, and performance may need to be
reduced so the system can maintain it's powered on state.
Arnd Bergmann [Mon, 11 Oct 2021 21:01:29 +0000 (23:01 +0200)]
Revert "arm64: dts: Add support for Unisoc's UMS512"
The patch uses the "dt-bindings/clock/sprd,ums512-clk.h header, which
is not merged yet. This caused a build regression, and it means the
patch was not ready to get merged anyway.
Arnd Bergmann [Mon, 11 Oct 2021 20:37:33 +0000 (22:37 +0200)]
Merge tag 'at91-dt-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/dt
AT91 DT #1 for 5.16:
- Addition of a new variant in the sama5d2 family: the sama5d29 with
significant updates being CAN and Ethernet controllers;
- Add support for Exegin Q5xR5 and CalAmp LMU5000 boards which were
maintained up to this moment, separately, in OpenWrt tree;
- Two more boards gained I2C bus recovery support;
- Tse850 updated with one Ethernet fix;
- Sama7g5ek gained ADC nodes and sama5d27_wlsom1 WiFi support.
* tag 'at91-dt-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: at91: dts: sama5d29: Add dtsi file for sama5d29
ARM: dts: at91-sama5d2_icp.dts: Added I2C bus recovery support
ARM: dts: at91: tse850: the emac<->phy interface is rmii
ARM: dts: at91: add Exegin Q5xR5 board
dt-bindings: ARM: at91: document exegin q5xr5 board
dt-bindings: add vendor prefix for exegin
ARM: dts: at91: add CalAmp LMU5000 board
dt-bindings: ARM: at91: document CalAmp LMU5000 board
dt-bindings: add vendor prefix for calamp
ARM: dts: at91: at91sam9260: add pinctrl label
ARM: dts: at91-sama5d27_som1_ek: Added I2C bus recovery support
ARM: dts: at91: sama7g5ek: enable ADC on the board
ARM: dts: at91: sama7g5: add node for the ADC
ARM: dts: at91: sama5d27_wlsom1: add wifi device
Arnd Bergmann [Mon, 11 Oct 2021 20:10:20 +0000 (22:10 +0200)]
Merge tag 'tegra-for-5.16-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
arm64: tegra: Device tree changes for v5.16-rc1
This enables additional interrupts on the Tegra194 GPIO controller for
better load balancing and/or virtualization, adds audio support on
Jetson TX2 NX, enables the NVDEC video decoder on Tegra186 and later and
enables more audio processors that are found on Tegra210 and later.
Various cleanups across the board top things off.
* tag 'tegra-for-5.16-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Fix pcie-ep DT nodes
arm64: tegra: Remove useless usb-ehci compatible string
arm64: tegra: Extend APE audio support on Jetson platforms
arm64: tegra: Add few AHUB devices for Tegra210 and later
arm64: tegra: Remove unused backlight-boot-off property
arm64: tegra: Add NVDEC to Tegra186/194 device trees
arm64: tegra: Add new USB PHY properties on Tegra132
arm64: tegra: Update HDA card name on Jetson TX2 NX
arm64: tegra: Audio graph sound card for Jetson TX2 NX
arm64: tegra: Add additional GPIO interrupt entries on Tegra194
Arnd Bergmann [Mon, 11 Oct 2021 19:55:07 +0000 (21:55 +0200)]
Merge tag 'tegra-for-5.16-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
dt-bindings: Changes for v5.16-rc1
This contains the DT bindings for the NVDEC hardware video decoder found
on Tegra210 and later chips as well as a node name fix for the examples
in the Tegra194 PCIe controller (endpoint mode) DT bindings.
* tag 'tegra-for-5.16-dt-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
dt-bindings: PCI: tegra194: Fix PCIe endpoint node names
dt-bindings: Add YAML bindings for NVDEC
This binding is meant for the child nodes of the TI GPMC node. The node
represents any device connected to the GPMC bus. It may be a Flash chip,
RAM chip or Ethernet controller, etc. These properties are meant for
configuring the GPMC settings/timings and will accompany the bindings
supported by the respective device.
Biju Das [Sun, 10 Oct 2021 14:25:19 +0000 (15:25 +0100)]
arm64: dts: renesas: rzg2l-smarc-som: Enable eMMC on SMARC platform
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.
dt-bindings: mediatek: Add #reset-cells to mmsys system controller
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.
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
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.
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.
arm64: tegra: Extend APE audio support on Jetson platforms
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
Stefan Wahren [Sat, 7 Aug 2021 11:06:40 +0000 (13:06 +0200)]
ARM: dts: Add Raspberry Pi Compute Module 4 IO Board
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.
Stefan Wahren [Sat, 7 Aug 2021 11:06:39 +0000 (13:06 +0200)]
ARM: dts: Add Raspberry Pi Compute Module 4
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
Stefan Wahren [Sat, 7 Aug 2021 11:06:37 +0000 (13:06 +0200)]
ARM: dts: bcm283x-rpi: Move Wifi/BT into separate dtsi
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.
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: ...
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.
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.
Drew Fustini [Wed, 25 Aug 2021 20:25:19 +0000 (13:25 -0700)]
ARM: dts: am335x-pocketbeagle: switch to pinconf-single
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:
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
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
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.
Sinthu Raja [Wed, 29 Sep 2021 08:13:31 +0000 (13:43 +0530)]
arm64: dts: ti: Add support for J721E SK
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
Jan Kiszka [Sun, 26 Sep 2021 12:05:17 +0000 (14:05 +0200)]
arm64: dts: ti: iot2050: Add support for product generation 2 boards
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).
Jan Kiszka [Sun, 26 Sep 2021 12:05:16 +0000 (14:05 +0200)]
arm64: dts: ti: iot2050: Prepare for adding 2nd-generation boards
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.
Jan Kiszka [Sun, 26 Sep 2021 12:05:14 +0000 (14:05 +0200)]
arm64: dts: ti: iot2050: Add/enabled mailboxes and carve-outs for R5F cores
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.
This ensures that the SD card will remain mmc0 across Basic and Advanced
devices, also avoiding surprises for users coming from the downstream
kernels.
Suman Anna [Sun, 19 Sep 2021 20:29:35 +0000 (15:29 -0500)]
arm64: dts: ti: k3-am64-main: Add ICSSG nodes
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.
Arnd Bergmann [Tue, 5 Oct 2021 14:31:01 +0000 (16:31 +0200)]
Merge tag 'renesas-dt-bindings-for-v5.16-tag1' of 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
projects / linux.git / log