Vaishnav Achath [Fri, 9 May 2025 09:19:11 +0000 (14:49 +0530)]
arm64: dts: ti: k3-j722s-evm: Add overlay for TEVI OV5640
TechNexion TEVI OV5640 camera is a 5MP camera that can be used with
J722S EVM through the 22-pin CSI-RX connector. Add a reference overlay
for quad TEVI OV5640 modules on J722S EVM.
Vaishnav Achath [Fri, 9 May 2025 09:19:10 +0000 (14:49 +0530)]
arm64: dts: ti: k3-j722s-evm: Add overlay for quad IMX219
RPi v2 Camera (IMX219) is an 8MP camera that can be used with J722S EVM
through the 22-pin CSI-RX connector. Add a reference overlay for quad
IMX219 RPI camera v2 modules on J722S EVM
arm64: dts: ti: j722s-evm: Add MUX to control CSI2RX
J722S EVM has the CSI2RX routed to a MIPI CSI connector and to 22-pin RPi
camera connector through an analog mux with GPIO control, model mux so
that an overlay can control the mux state according to connected cameras.
arm64: dts: ti: j722s-evm: Add DT nodes for power regulators
Add device tree nodes for two regulators on the J722S-EVM. VSYS_3V3 is the
output of LM5141-Q1, and it serves as an input to TPS22990 which produces
VSYS_3V3_EXP [1]. VSYS_3V3_EXP serves as vin-supply to CSI RPI Connectors.
For every remote processor, set up dedicated memory regions and
associate the required mailbox channels. Allocate two memory areas
per remote core: one 1MB region for vring shared buffers, and
another for external memory used by the remote processor for its
resource table and trace buffer.
For every remote processor, set up dedicated memory regions and
associate the required mailbox channels. Allocate two memory areas
per remote core: one 1MB region for vring shared buffers, and
another for external memory used by the remote processor for its
resource table and trace buffer.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250507070008.1231611-2-d.schultz@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
Rename 'main0_thermal_trip0' to a more descriptive name that
includes 'fan', as the current name is too generic for a fan control
trip point.
Move the fan to a new cooling map to avoid overwriting the passive
trip point used for CPU frequency throttling when this overlay is
enabled. Also, add the fan to the existing cooling map.
Matt Coster [Mon, 28 Apr 2025 11:07:15 +0000 (12:07 +0100)]
arm64: dts: ti: k3-j721s2: Add GPU node
The J721S2 binding is based on the TI downstream binding in commit 54b0f2a00d92 ("arm64: dts: ti: k3-j721s2-main: add gpu node") from [1]
but with updated compatible strings.
The clock[2] and power[3] indices were verified from HTML docs, while
the interrupt index comes from the TRM[4] (appendix
"J721S2_Appendix_20241106_Public.xlsx", "Interrupts (inputs)",
"GPU_BXS464_WRAP0_GPU_SS_0_OS_IRQ_OUT_0").
Kishon Vijay Abraham I [Wed, 30 Apr 2025 14:43:43 +0000 (09:43 -0500)]
arm64: dts: ti: k3-am62-main: Add PRUSS-M node
Add the DT node for the PRUSS-M processor subsystem that is present
on the K3 AM62x SoCs. The K3 AM62x family of SoC has one PRUSS-M
instance and it has two Programmable Real-Time Units (PRU0 and PRU1).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[ Judith: Fix pruss_iclk id for pruss_coreclk_mux ] Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Acked-by: Hari Nagalla <hnagalla@ti.com> Link: https://lore.kernel.org/r/20250430144343.972234-1-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Hari Nagalla [Fri, 2 May 2025 22:03:25 +0000 (17:03 -0500)]
arm64: dts: ti: k3-am64: Reserve timers used by MCU FW
AM64x device has 4 R5F cores in the main domain. TI MCU firmware uses
main domain timers as tick timers in these firmwares. Hence keep them
as reserved in the Linux device tree.
Hari Nagalla [Fri, 2 May 2025 22:03:22 +0000 (17:03 -0500)]
arm64: dts: ti: k3-am62x-sk-common: Enable IPC with remote processors
For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-9-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Devarsh Thakkar [Fri, 2 May 2025 22:03:21 +0000 (17:03 -0500)]
arm64: dts: ti: k3-am62p5-sk: Enable IPC with remote processors
For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-8-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Devarsh Thakkar [Fri, 2 May 2025 22:03:20 +0000 (17:03 -0500)]
arm64: dts: ti: k3-am62a7-sk: Enable IPC with remote processors
For each remote proc, reserve memory for IPC and bind the mailbox
assignments. Two memory regions are reserved for each remote processor.
The first region of 1MB of memory is used for Vring shared buffers
and the second region is used as external memory to the remote processor
for the resource table and for tracebuffer allocations.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-7-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
AM62A SoCs have a C7xv DSP subsystem with Analytics engine capability.
This subsystem is intended for deep learning purposes. Define the
device node for C7xv DSP.
Signed-off-by: Jai Luthra <j-luthra@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Tested-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250502220325.3230653-6-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Judith Mendez [Fri, 2 May 2025 22:03:15 +0000 (17:03 -0500)]
arm64: dts: ti: k3-am62: Add ATCM and BTCM cbass ranges
Add cbass ranges for ATCM and BTCM on am62x device, without
these, remoteproc driver fails to probe and attach to the DM
r5 core and IPC communication is broken.
Rishikesh Donadkar [Fri, 2 May 2025 16:25:37 +0000 (21:55 +0530)]
arm64: dts: ti: k3-am62x: Add required voltage supplies for IMX219
The device tree overlay for the IMX219 sensor requires three voltage
supplies to be defined: VANA (analog), VDIG (digital core), and VDDL
(digital I/O) [1].
Add the corresponding voltage supply definitions in the overlay so
that the same topography as dt-bindings is present in the DT overlay.
arm64: dts: ti: k3-am62p-j722s-common-main: Set eMMC clock parent to default
Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
for eMMC. This change is necessary since DM is not implementing the
correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
not glich-free. As a preventative action, lets switch back to the defaults.
arm64: dts: ti: k3-am62a-main: Set eMMC clock parent to default
Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
for eMMC. This change is necessary since DM is not implementing the
correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
not glich-free. As a preventative action, lets switch back to the defaults.
arm64: dts: ti: k3-am62-main: Set eMMC clock parent to default
Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT
for eMMC. This change is necessary since DM is not implementing the
correct procedure to switch PLL clock source for eMMC and MMC CLK mux is
not glich-free. As a preventative action, lets switch back to the defaults.
Francesco Dolcini [Wed, 30 Apr 2025 10:28:11 +0000 (12:28 +0200)]
arm64: dts: ti: Add Toradex Verdin AM62P
Add support for Toradex Verdin AM62P computer on module which can be
used on different carrier boards and for the Toradex Verdin Development
Board carrier board.
The module consists of an TI AM62P family SoC, a TPS65219 PMIC, a
Gigabit Ethernet PHY, up to 8GB of LPDDR4 RAM, an eMMC, a TLA2024 ADC,
an I2C EEPROM, an RX8130 RTC, plus an optional Bluetooth/Wi-Fi module.
Anything that is not self-contained on the module is disabled by
default.
arm64: dts: ti: k3-j784s4-j742s2-evm-common: Enable ACSPCIE0 output for PCIe1
The PCIe reference clock required by the PCIe Endpoints connected to the
PCIe connector corresponding to the PCIe1 instance of PCIe on J784S4-EVM
and J742S2-EVM is driven by the ACSPCIE0 module. Add the device-tree
support for enabling the same.
The ACSPCIE0 module on TI's J784S4 SoC is capable of driving the
reference clock required by the PCIe Endpoint device. It is an
alternative to on-board and external reference clock generators.
Add the device-tree node for the same.
arm64: dts: ti: k3-j784s4-j742s2-main-common: Switch to 64-bit address space for PCIe0 and PCIe1
The PCIe0 and PCIe1 instances of PCIe in J742S2 and J784S4 SoCs support:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-j722s-main: Switch to 64-bit address space for PCIe0
The PCIe0 instance of PCIe in J722S SoC supports:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-j721s2-main: Switch to 64-bit address space for PCIe1
The PCIe1 instance of PCIe in J721S2 SoC supports:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-j721e-main: Switch to 64-bit address space for PCIe0 and PCIe1
The PCIe0 and PCIe1 instances of PCIe in J721E SoC support:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-j721e: Add ranges for PCIe0 DAT1 and PCIe1 DAT1
The PCIe0 DAT1 and PCIe1 DAT1 are 4 GB address regions in the 64-bit
address space of the respective PCIe Controllers. Hence, update the
ranges to include them.
arm64: dts: ti: k3-j7200-main: Switch to 64-bit address space for PCIe1
The PCIe0 instance of PCIe in J7200 SoC supports:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-am64-main: Switch to 64-bit address space for PCIe0
The PCIe0 instance of PCIe in AM64 SoC supports:
1. 128 MB address region in the 32-bit address space
2. 4 GB address region in the 64-bit address space
The default configuration is that of a 128 MB address region in the
32-bit address space. While this might be sufficient for most use-cases,
it is insufficient for supporting use-cases which require larger address
spaces. Therefore, switch to using the 64-bit address space with a 4 GB
address region.
arm64: dts: ti: k3-am6*: Add boot phase flag to support MMC boot
The bootph-all flag was introduced in dt-schema
(dtschema/schemas/bootph.yaml) to define node usage across
different boot phases.
For eMMC and SD boot modes, voltage regulator nodes, io-expander
nodes, gpio nodes, and MMC nodes need to be present in all boot
stages, so add missing bootph-all phase flag to these nodes to
support SD boot and eMMC boot.
PWM signals can be routed to the user expansion header on am625
SK and am62 lp sk. Enable eCAP0, eCAP1, eHRPWM1, and route the
output PWM signals to pins on J3 header.
PWM signals can be routed to the user expansion header on am62a7
SK. Enable eCAP0, eCAP1, eHRPWM1, and route the output PWM signals
to pins on J3 header.
PWM signals can be routed to the user expansion header on am62p5
SK. Enable eCAP0, eCAP1, eHRPWM0, eHRPWM1 and route the output PWM
signals to pins on J4 header.
arm64: dts: ti: Add basic support for phyBOARD-Izar-AM68x
The phyCORE-AM68x/TDA4x [1] is a SoM (System on Module) featuring TI's
AM68x/TDA4x SoC. It can be used in combination with different carrier
boards. This module can come with different sizes and models for DDR,
eMMC, SPI NOR Flash and various SoCs from the AM68x/TDA4x (J721S2) family.
A reference carrier board design, called phyBOARD-Izar is used for the
phyCORE-AM68x/TDA4x development kit [2].
arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix length of serdes_ln_ctrl
Commit under Fixes corrected the "mux-reg-masks" property but did not
update the "length" field of the "reg" property to account for the
newly added register offsets which extend the region. Fix this.
Andrew Davis [Mon, 21 Apr 2025 21:46:20 +0000 (16:46 -0500)]
arm64: dts: ti: am65x: Add missing power-supply for Rocktech-rk101 panel
Add the 5v0 supply that is provided over the display panel cable and
used by the LCD. This is required by "simple panels" or we get the
following warning from DTBS_CHECK:
k3-am654-gp-evm.dtb: display0: 'power-supply' is a required property
Andrew Davis [Mon, 21 Apr 2025 21:46:18 +0000 (16:46 -0500)]
dt-bindings: mfd: ti,j721e-system-controller: Add compatible string for AM654
Add the child nodes that can be found under this node. Then as done
for other similar devices (J7200 and J721s2) add support for the AM654
system controller to this binding.
arm64: dts: ti: k3-j721e-common-proc-board-infotainment: Update to comply with device tree schema
Fix hdmi-connector and tfp bridge node as per the bindings,
- Remove 'digital' property which is required for DVI connector not HDMI
- Add 'ti,deskew' property which is a required property
- Fix ports property for tfp410 bridge
- Change node names appropriately
Redefine the ports for dss and for k3-j721e-common-proc-board.dts, add
reg property for the port (@0) to get rid of dtbs_check warnings in
infotainment overlay when ports for dss are re-defined.
arm64: dts: ti: k3-j784s4-j742s2-evm: Add overlay to enable USB0 Type-A
The USB0 instance of the USB controller on both the J742S2 EVM and the
J784S4 EVM supports a single USB interface at a time among the following:
1. USB3.1 Gen1 Type C interface
2. Two USB2.0 Type A interfaces via an on-board USB Hub.
By default, the USB3.1 Gen1 Type C interface is supported on both of the
EVMs. Enable the USB2.0 Type A interface by configuring the USB2.0_MUX_SEL
mux. Additionally, set the Dual-Role Mode to Host since a Type-A interface
is only associated with the Host Mode of operation.
Robert Nelson [Tue, 15 Apr 2025 22:59:40 +0000 (17:59 -0500)]
arm64: dts: ti: Add k3-am62-pocketbeagle2
BeagleBoard.org PocketBeagle 2 is an upgraded version of the popular
PocketBeagle. It is based on Texas Instruments AM6232 or AM6254 SoC.
Its dual or quad A53 cores can provide higher performance than classic
PocketBeagle. The new design comes with pre-soldered headers, a
3-pin JST-SH 1.00mm UART debug port, a USB-C port, Texas Instruments
MSPM0L1105 Cortex-M0+ MCU for ADC, 512MB RAM, and a LiPo Battery
charger.
Michael Walle [Tue, 1 Apr 2025 08:32:46 +0000 (10:32 +0200)]
arm64: dts: ti: k3-am62p-j722s: Add rng node
Add the node for the random number generator inside the crypto module.
Marked reserved since the default usage is with the RNG node being
controlled by OP-TEE.
Andrew Davis [Wed, 2 Apr 2025 11:32:01 +0000 (17:02 +0530)]
arm64: dts: ti: k3-am64: Add PCIe ctrl node to main_conf region
This region is used for controlling the function of the PCIe IP. It is
compatible with "ti,j784s4-pcie-ctrl", add this here and use it with
the PCIe node.
Signed-off-by: Andrew Davis <afd@ti.com>
[j-choudhary@ti.com: Add changes to k3-am642-evm-pcie0-ep.dtso] Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250402113201.151195-6-j-choudhary@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Andrew Davis [Wed, 2 Apr 2025 11:32:00 +0000 (17:02 +0530)]
arm64: dts: ti: k3-j721s2: Add PCIe ctrl node to scm_conf region
This region is used for controlling the function of the PCIe IP. It is
compatible with "ti,j784s4-pcie-ctrl", add this here and use it with
the PCIe node.
Signed-off-by: Andrew Davis <afd@ti.com>
[j-choudhary@ti.com: Add changes to k3-am68-sk-base-board-pcie1-ep.dtso] Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250402113201.151195-5-j-choudhary@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Andrew Davis [Wed, 2 Apr 2025 11:31:59 +0000 (17:01 +0530)]
arm64: dts: ti: k3-j7200: Add PCIe ctrl node to scm_conf region
This region is used for controlling the function of the PCIe IP. It is
compatible with "ti,j784s4-pcie-ctrl", add this here and use it with
the PCIe node.
Signed-off-by: Andrew Davis <afd@ti.com>
[j-choudhary@ti.com: Add changes to k3-j7200-evm-pcie1-ep.dtso] Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250402113201.151195-4-j-choudhary@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Andrew Davis [Wed, 2 Apr 2025 11:31:58 +0000 (17:01 +0530)]
arm64: dts: ti: k3-j721e: Add PCIe ctrl node to scm_conf region
This region is used for controlling the function of the PCIe IP. It is
compatible with "ti,j784s4-pcie-ctrl", add this here and use it with
the PCIe nodes.
Signed-off-by: Andrew Davis <afd@ti.com>
[j-choudhary@ti.com: Add changes to k3-j721e-evm-pcie1-ep.dtso] Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20250402113201.151195-3-j-choudhary@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in OV5640 overlay
The OV5640 device tree overlay incorrectly defined an I2C switch
instead of an I2C mux. According to the DT bindings, the correct
terminology and node definition should use "i2c-mux" instead of
"i2c-switch". Hence, update the same to avoid dtbs_check warnings.
arm64: dts: ti: k3-am62x: Rename I2C switch to I2C mux in IMX219 overlay
The IMX219 device tree overlay incorrectly defined an I2C switch
instead of an I2C mux. According to the DT bindings, the correct
terminology and node definition should use "i2c-mux" instead of
"i2c-switch". Hence, update the same to avoid dtbs_check warnings.
arm64: dts: ti: k3-am62x: Remove clock-names property from IMX219 overlay
The IMX219 sensor device tree bindings do not include a clock-names
property. Remove the incorrectly added clock-names entry to avoid
dtbs_check warnings.
arm64: dts: ti: k3-j721e-sk: Add requiried voltage supplies for IMX219
The device tree overlay for the IMX219 sensor requires three voltage
supplies to be defined: VANA (analog), VDIG (digital core), and VDDL
(digital I/O). Add the corresponding voltage supply definitions to
avoid dtbs_check warnings.
arm64: dts: ti: k3-j721e-sk: Remove clock-names property from IMX219 overlay
The IMX219 sensor device tree bindings do not include a clock-names
property. Remove the incorrectly added clock-names entry to avoid
dtbs_check warnings.
Update the vin-supply of the TLV71033 regulator from LM5141 (vsys_3v3)
to LM61460 (vsys_5v0) to match the schematics. Add a fixed regulator
node for the LM61460 5V supply to support this change.
arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators
Add device tree nodes for two power regulators on the J721E SK board.
vsys_5v0: A fixed regulator representing the 5V supply output from the
LM61460 and vdd_sd_dv: A GPIO-controlled TLV71033 regulator.
arm64: dts: ti: k3-j722s-main: Don't disable serdes0 and serdes1
Since serdes0 and serdes1 are the child nodes of serdes_wiz0 and
serdes_wiz1 respectively, and, given that serdes_wiz0 and serdes_wiz1
are already disabled, it is not necessary to disable serdes0 and serdes1.
Moreover, having serdes_wiz0/serdes_wiz1 enabled and serdes0/serdes1
disabled is not a working configuration.
Hence, remove 'status = "disabled"' from the serdes0 and serdes1 nodes.
arm64: dts: ti: k3-j722s-main: Disable "serdes_wiz0" and "serdes_wiz1"
Since "serdes0" and "serdes1" which are the sub-nodes of "serdes_wiz0"
and "serdes_wiz1" respectively, have been disabled in the SoC file already,
and, given that these sub-nodes will only be enabled in a board file if the
board utilizes any of the SERDES instances and the peripherals bound to
them, we end up in a situation where the board file doesn't explicitly
disable "serdes_wiz0" and "serdes_wiz1". As a consequence of this, the
following errors show up when booting Linux:
wiz bus@f0000:phy@f000000: probe with driver wiz failed with error -12
...
wiz bus@f0000:phy@f010000: probe with driver wiz failed with error -12
To not only fix the above, but also, in order to follow the convention of
disabling device-tree nodes in the SoC file and enabling them in the board
files for those boards which require them, disable "serdes_wiz0" and
"serdes_wiz1" device-tree nodes.
arm64: dts: ti: k3-j722s-evm: Enable "serdes_wiz0" and "serdes_wiz1"
In preparation for disabling "serdes_wiz0" and "serdes_wiz1" device-tree
nodes in the SoC file, enable them in the board file. The motivation for
this change is that of following the existing convention of disabling
nodes in the SoC file and only enabling the required ones in the board
file.
Fixes: 485705df5d5f ("arm64: dts: ti: k3-j722s: Enable PCIe and USB support on J722S-EVM") Cc: stable@vger.kernel.org Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20250417123246.2733923-2-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
Thomas Weißschuh [Wed, 2 Apr 2025 20:21:57 +0000 (21:21 +0100)]
tools/include: make uapi/linux/types.h usable from assembly
The "real" linux/types.h UAPI header gracefully degrades to a NOOP when
included from assembly code.
Mirror this behaviour in the tools/ variant.
Test for __ASSEMBLER__ over __ASSEMBLY__ as the former is provided by the
toolchain automatically.
Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/lkml/af553c62-ca2f-4956-932c-dd6e3a126f58@sirena.org.uk/ Fixes: c9fbaa879508 ("selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20250321-uapi-consistency-v1-1-439070118dc0@linutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'soundwire-6.15-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire
Pull soundwire fix from Vinod Koul:
- add missing config symbol CONFIG_SND_HDA_EXT_CORE required for asoc
driver CONFIG_SND_SOF_SOF_HDA_SDW_BPT
* tag 'soundwire-6.15-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire:
ASoC: SOF: Intel: Let SND_SOF_SOF_HDA_SDW_BPT select SND_HDA_EXT_CORE
Len Brown [Sun, 6 Apr 2025 18:49:20 +0000 (14:49 -0400)]
tools/power turbostat: v2025.05.06
Support up to 8192 processors
Add cpuidle governor debug telemetry, disabled by default
Update default output to exclude cpuidle invocation counts
Bug fixes
Merge tag 'perf-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf event fix from Ingo Molnar:
"Fix a perf events time accounting bug"
* tag 'perf-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/core: Fix child_total_time_enabled accounting bug at task exit
Merge tag 'sched-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
- Fix a nonsensical Kconfig combination
- Remove an unnecessary rseq-notification
* tag 'sched-urgent-2025-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
rseq: Eliminate useless task_work on execve
sched/isolation: Make CONFIG_CPU_ISOLATION depend on CONFIG_SMP
... and don't error out so hard on missing module descriptions.
Before commit 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()")
we used to warn about missing module descriptions, but only when
building with extra warnigns (ie 'W=1').
After that commit the warning became an unconditional hard error.
And it turns out not all modules have been converted despite the claims
to the contrary. As reported by Damian Tometzki, the slub KUnit test
didn't have a module description, and apparently nobody ever really
noticed.
The reason nobody noticed seems to be that the slub KUnit tests get
disabled by SLUB_TINY, which also ends up disabling a lot of other code,
both in tests and in slub itself. And so anybody doing full build tests
didn't actually see this failre.
So let's disable SLUB_TINY for build-only tests, since it clearly ends
up limiting build coverage. Also turn the missing module descriptions
error back into a warning, but let's keep it around for non-'W=1'
builds.
Len Brown [Sun, 6 Apr 2025 15:18:39 +0000 (11:18 -0400)]
tools/power turbostat: report CoreThr per measurement interval
The CoreThr column displays total thermal throttling events
since boot time.
Change it to report events during the measurement interval.
This is more useful for showing a user the current conditions.
Total events since boot time are still available to the user via
/sys/devices/system/cpu/cpu*/thermal_throttle/*
Document CoreThr on turbostat.8
Fixes: eae97e053fe30 ("turbostat: Support thermal throttle count print") Reported-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Cc: Chen Yu <yu.c.chen@intel.com>
Justin Ernst [Wed, 19 Mar 2025 20:27:31 +0000 (15:27 -0500)]
tools/power turbostat: Increase CPU_SUBSET_MAXCPUS to 8192
On systems with >= 1024 cpus (in my case 1152), turbostat fails with the error output:
"turbostat: /sys/fs/cgroup/cpuset.cpus.effective: cpu str malformat 0-1151"
A similar error appears with the use of turbostat --cpu when the inputted cpu
range contains a cpu number >= 1024:
# turbostat -c 1100-1151
"--cpu 1100-1151" malformed
...
Both errors are caused by parse_cpu_str() reaching its limit of CPU_SUBSET_MAXCPUS.
It's a good idea to limit the maximum cpu number being parsed, but 1024 is too low.
For a small increase in compute and allocated memory, increasing CPU_SUBSET_MAXCPUS
brings support for parsing cpu numbers >= 1024.
Increase CPU_SUBSET_MAXCPUS to 8192, a common setting for CONFIG_NR_CPUS on x86_64.
Signed-off-by: Justin Ernst <justin.ernst@hpe.com> Signed-off-by: Len Brown <len.brown@intel.com>