- 12 Oct, 2023 6 commits
-
-
Keerthy authored
Patch adds the ESM instances for J784s4. It has 3 instances. One in the main domain and two in the mcu-wakeup domain. Signed-off-by:
Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20231008044657.25788-3-j-keerthy@ti.comSigned-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Keerthy authored
Patch adds the ESM instances for J721s2. It has 3 instances. One in the main domain and two in the mcu-wakeup domain. Signed-off-by:
-
Vaishnav Achath authored
J784S4 has a dedicated BCDMA controller for the Camera Serial Interface. Events from the BCDMA controller instance are routed through the main UDMA interrupt aggregator as unmapped events. Add the node for the DMA controller and keep it disabled by default. See J784S4 Technical Reference Manual (SPRUJ52) for further details: http://www.ti.com/lit/zip/spruj52Signed-off-by:
Vaishnav Achath <vaishnav.a@ti.com> Reviewed-by:
Jayesh Choudhary <j-choudhary@ti.com> Link: https://lore.kernel.org/r/20231010111723.17524-3-vaishnav.a@ti.comSigned-off-by:
-
Vaishnav Achath authored
J721S2 has a dedicated BCDMA controller for the Camera Serial Interface. Events from the BCDMA controller instance are routed through the main UDMA interrupt aggregator as unmapped events. Add the node for the DMA controller and keep it disabled by default. See J721S2 Technical Reference Manual (SPRUJ28) for further details: http://www.ti.com/lit/pdf/spruj28Signed-off-by:
-
Vignesh Raghavendra authored
"simple-mfd" as standalone compatible is frowned upon, so model main and MCU NAVSS (Navigator SubSystem) nodes as simple-bus as there is really no need for these nodes to be MFD. Link: https://lore.kernel.org/r/20231005151302.1290363-3-vigneshr@ti.comSigned-off-by:
-
Vignesh Raghavendra authored
"simple-mfd" as standalone compatible is frowned upon, so model DMSS (Data Movement Subsystem) node as simple-bus as there is really no need for these nodes to be MFD. Link: https://lore.kernel.org/r/20231005151302.1290363-2-vigneshr@ti.comSigned-off-by:
-
- 06 Oct, 2023 1 commit
-
-
Aradhya Bhatia authored
Apply HDMI audio overlay to AM625 and AM62-LP SK-EVMs DT binaries, instead of leaving it in a floating state. Fixes: b50ccab9 ("arm64: dts: ti: am62x-sk: Add overlay for HDMI audio") Reported-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Aradhya Bhatia <a-bhatia1@ti.com> Link: https://lore.kernel.org/r/20231003092259.28103-1-a-bhatia1@ti.comSigned-off-by:
-
- 05 Oct, 2023 24 commits
-
-
Jai Luthra authored
Add nodes for audio codec and sound card, enable the audio serializer (McASP1) under use and update pinmux. Reviewed-by:
Devarsh Thakkar <devarsht@ti.com> Link: https://www.ti.com/lit/zip/sprr459Signed-off-by:
Jai Luthra <j-luthra@ti.com> Link: https://lore.kernel.org/r/20231003-mcasp_am62a-v3-5-2b631ff319ca@ti.comSigned-off-by:
-
Julien Panis authored
This patch adds support for TPS6593 PMIC on main I2C0 bus. This device provides regulators (bucks and LDOs), but also GPIOs, a RTC, a watchdog, an ESM (Error Signal Monitor) which monitors the SoC error output signal, and a PFSM (Pre-configurable Finite State Machine) which manages the operational modes of the PMIC. Signed-off-by:
Julien Panis <jpanis@baylibre.com> Signed-off-by:
Esteban Blanc <eblanc@baylibre.com> Signed-off-by:
-
Jai Luthra authored
The TLV320AIC3106 audio codec is interfaced on the i2c-1 bus. With the default rate of 400Khz the i2c register writes fail to sync: [ 36.026387] tlv320aic3x 1-001b: Unable to sync registers 0x16-0x16. -110 [ 38.101130] omap_i2c 20010000.i2c: controller timed out Dropping the rate to 100Khz fixes the issue. Fixes: 38c4a08c ("arm64: dts: ti: Add support for AM62A7-SK") Reviewed-by:
-
Jai Luthra authored
VCC_3V3_MAIN is the output of LM5141-Q1, and it serves as an input to TPS22965DSGT which produces VCC_3V3_SYS. [1] Link: https://www.ti.com/lit/zip/sprr459 [1] Signed-off-by:
-
Jai Luthra authored
Same as AM62, AM62A has three instances of McASP which can be used for transmitting or receiving digital audio in various formats. Reviewed-by:
-
Matthias Schiffer authored
Replace the deprecated label property with color/function. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/79cb3cdfed19962ce0d4ae558de897695658a81f.1695901360.git.matthias.schiffer@ew.tq-group.comSigned-off-by:
-
Matthias Schiffer authored
Set the "embedded" chassis-type for the MBaX4XxL. Signed-off-by:
-
Matthias Schiffer authored
The pin headers X41 and X42 do not have a fixed function. All of these pins can be assigned to PRG0, but as a default, it makes more sense to configure them as simple GPIOs, as the MBaX4XxL is a starterkit/evaluation mainboard. Signed-off-by:
-
Matthias Schiffer authored
Describes the hardware better, and avoids a few warnings during boot: lm75 0-004a: supply vs not found, using dummy regulator at24 0-0050: supply vcc not found, using dummy regulator at24 0-0054: supply vcc not found, using dummy regulator Signed-off-by: -
Sinthu Raja authored
AM68 Starter kit has a USB3 hub that connects to the SerDes0 Lane 2. Update the SerDes configuration to support USB3. Signed-off-by:
Sinthu Raja <sinthu.raja@ti.com> Signed-off-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Link: https://lore.kernel.org/r/20230921100039.19897-4-r-gunasekaran@ti.comSigned-off-by:
-
Sinthu Raja authored
AM68 Starter kit features with one PCIe M.2 Key M connector interfaced via two SerDes lanes. Update the SerDes configuration for PCIe. Signed-off-by:
-
Sinthu Raja authored
Lanes 0 and 2 of the J721S2 SerDes WIZ are reserved for USB type-C lane swap. Update the macro definition for it. Signed-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the C71x DSP for the TI K3 AM69 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The C71x DSP processor supports a MMU called CMMU, but is not currently supported and as such requires the exact memory used by the firmware to be set-aside. Signed-off-by:
Apurva Nandan <a-nandan@ti.com> Reviewed-by:
Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20231001181417.743306-10-a-nandan@ti.comSigned-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor device within both the MCU and MAIN domains for the TI K3 AM69 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each 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 firmware images do not require any RSC_CARVEOUT entries in their resource tables either to allocate the memory for firmware memory segments. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non-LockStep) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Signed-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the C71x DSP for the TI K3 AM68 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The C71x DSP processor supports a MMU called CMMU, but is not currently supported and as such requires the exact memory used by the firmware to be set-aside. Signed-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor device within both the MCU and MAIN domains for the TI K3 AM68 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each 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 firmware images do not require any RSC_CARVEOUT entries in their resource tables either to allocate the memory for firmware memory segments. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non-LockStep) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Signed-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the C71x DSP for the TI J721S2 EVM 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The C71x DSP processor supports a MMU called CMMU, but is not currently supported and as such requires the exact memory used by the firmware to be set-aside. Signed-off-by:
Hari Nagalla <hnagalla@ti.com> Signed-off-by:
Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20231001181417.743306-6-a-nandan@ti.comSigned-off-by:
-
Apurva Nandan authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor device within both the MCU and MAIN domains for the TI J721S2 EVM 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 device, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each 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 firmware images do not require any RSC_CARVEOUT entries in their resource tables either to allocate the memory for firmware memory segments. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non-LockStep) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Signed-off-by:
-
Apurva Nandan authored
The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain. The C71x DSPs are 64 bit machine with fixed and floating point DSP operations. Similar to the R5F remote cores, the inter-processor communication between the main A72 cores and these DSP cores is achieved through shared memory and Mailboxes. The following firmware names are used by default for these DSP cores, and can be overridden in a board dts file if desired: MAIN C71_0 : j721s2-c71_0-fw MAIN C71_1 : j721s2-c71_1-fw Signed-off-by: -
Apurva Nandan authored
The J721S2 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS) subsystems/clusters in MAIN voltage domain. Each of these can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in LockStep-mode to provide a larger 128 KB of memory, but otherwise are functionally similar to those on J721E SoCs. Add the DT nodes for the MAIN domain R5F cluster/subsystems, the two R5F cores are added as child nodes to each of the R5F cluster nodes. The clusters are configured to run in LockStep mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MAIN R5FSS0 Core0: j721s2-main-r5f0_0-fw (both in LockStep & Split mode) MAIN R5FSS0 Core1: j721s2-main-r5f0_1-fw (needed only in Split mode) MAIN R5FSS1 Core0: j721s2-main-r5f1_0-fw (both in LockStep & Split mode) MAIN R5FSS1 Core1: j721s2-main-r5f1_1-fw (needed only in Split mode) Signed-off-by:
-
Apurva Nandan authored
The J721S2 SoCs have a dual-core Arm Cortex-R5F processor (R5FSS) subsystems/cluster in MCU voltage domain. It can be configured at boot time to be either run in a LockStep mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode. These subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal memories for each core split between two banks - ATCM and BTCM (further interleaved into two banks). The TCMs of both Cores are combined in LockStep-mode to provide a larger 128 KB of memory, but otherwise are functionally similar to those on J721E SoCs. Add the DT nodes for the MCU domain R5F cluster/subsystem, the two R5F cores are added as child nodes to each of the R5F cluster nodes. The clusters are configured to run in LockStep mode by default, with the ATCMs enabled to allow the R5 cores to execute code from DDR with boot-strapping code from ATCM. The inter-processor communication between the main A72 cores and these processors is achieved through shared memory and Mailboxes. The following firmware names are used by default for these cores, and can be overridden in a board dts file if desired: MCU R5FSS0 Core0: j721s2-mcu-r5f0_0-fw (both in LockStep and Split mode) MCU R5FSS0 Core1: j721s2-mcu-r5f0_1-fw (needed only in Split mode) Signed-off-by:
-
Neha Malcom Francis authored
Currently J721E defines only the main_esm in DTS. Add node for mcu_esm as well. According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm accordingly so that errors from main_esm are routed to mcu_esm and handled. [1] https://www.ti.com/lit/zip/spruil1Signed-off-by:
Neha Malcom Francis <n-francis@ti.com> Reviewed-by:
-
Wadim Egorov authored
Seems like the address value of the reg property was mistyped. Update reg to 0x9ca00000 to match node's definition. Fixes: f5a731f0 ("arm64: dts: ti: Add k3-am625-beagleplay") Signed-off-by:
Wadim Egorov <w.egorov@phytec.de> Reviewed-by:
Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20230925151444.1856852-1-w.egorov@phytec.deSigned-off-by:
-
Roger Quadros authored
A TCA9554 GPIO expander is present on I2C0. Add it. Signed-off-by:
Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230923080046.5373-3-rogerq@kernel.orgSigned-off-by:
-
- 02 Oct, 2023 9 commits
-
-
Francesco Dolcini authored
Keep the DPI to MIPI-DSI bridge disabled in the SoM dtsi file. The display chain is not wholly described in the device tree file, on Verdin product family the displays are additional accessories that are configured/enabled using DT overlays. With this enabled we have issues when a display is enabled on TIDSS port1 (LVDS) and port0 (DSI) is not used. Fixes: 9e772003 ("arm64: dts: ti: verdin-am62: Add DSI display support") Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20230922123003.25002-1-francesco@dolcini.itSigned-off-by:
-
Ravi Gunasekaran authored
AM654 baseboard has two TCA9554 I/O expander on the WKUP_I2C0 bus. The expander at address 0x38 is used to detect daughter cards. Add a node for this I/O expander. Signed-off-by:
-
Wadim Egorov authored
Wth commit 16b26f60 ("rtc: rv3028: Use IRQ flags obtained from device tree if available") we can now use the interrupt pin of the RTC. Let's add interrupt pin definitions to the SoM RTC. Signed-off-by:
-
Wadim Egorov authored
Use single instead of double tab. Signed-off-by:
-
Siddharth Vadapalli authored
Specify the base dtb file k3-j721s2-common-proc-board.dtb on which the k3-j721s2-evm-gesi-exp-board.dtbo overlay has to be applied. Name the resulting dtb as k3-j721s2-evm.dtb. Fixes: cac04e27 ("arm64: dts: ti: k3-j721s2: Add overlay to enable main CPSW2G with GESI") Reported-by:
Rob Herring <robh+dt@kernel.org> Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20230912043308.20629-1-s-vadapalli@ti.comSigned-off-by:
-
Nishanth Menon authored
bootph-all as phase tag was added to dt-schema (dtschema/schemas/bootph.yaml) to describe various node usage during boot phases with DT. Describe the same for AM642-sk boot devices. Signed-off-by:
-
Nishanth Menon authored
bootph-all as phase tag was added to dt-schema (dtschema/schemas/bootph.yaml) to describe various node usage during boot phases with DT. Describe the same for AM642-evm boot devices. Signed-off-by:
-
Nishanth Menon authored
bootph-all as phase tag was added to dt-schema (dtschema/schemas/bootph.yaml) to describe various node usage during boot phases with DT. On TI K3 AM642 SoC, only esm nodes are exclusively used by R5 bootloader, rest of the dts nodes with bootph-* are used by later boot stages also. Add bootph-all for all other nodes that are used in the bootloader on K3 AM642 SoC, and bootph-pre-ram is not needed specifically for any other node in kernel dts. Signed-off-by:
-
Nishanth Menon authored
bootph-all as phase tag was added to dt-schema (dtschema/schemas/bootph.yaml) to describe various node usage during boot phases with DT. Describe the same for am625-sk boot devices. Signed-off-by:
-
