The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8mp-venice boards.
The IMX8M reference manuals indicate in the USDHC Clock generator section
that the clock rate for DDR is 1/2 the input clock therefore HS400 rates
clocked at 200Mhz require a 400Mhz SDHC clock.
This showed about a 1.5x improvement in read performance for the eMMC's
used on the various imx8m{m,n,p}-venice boards.
Fixes: 6f30b27c5ef5 ("arm64: dts: imx8mm: Add Gateworks i.MX 8M Mini Development Kits") Signed-off-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Yannic Moog [Wed, 11 Jun 2025 13:05:31 +0000 (15:05 +0200)]
arm64: dts: add imx95-libra-rdk-fpsc board
Add device tree for the Libra-i.MX 95 FPSC board. The Libra is a
pure development board and has hardware to support FPSC-24-A.0 set of
features. The phyCORE-i.MX 95 FPSC [1] SoM uses only a subset of
the hardware features of the Libra board. The phyCORE-i.MX 95 FPSC
itself is a System on Module designed around the i.MX 95 SoC.
The SoM and board utilize the Future Proof Solder Core [2] BGA standard
to connect to each other.
To be able to easily map FPSC interface names to SoC interfaces, the
FPSC interface names are added as inline comments. Example:
Here, I2C2 is the FPSC interface name. The lpi2c5 instance of the i.MX 95
SoC is used to fulfill the i2c functionality and its signals are routed
to the FPSC I2C2 signal pins:
Add overlay to support PHYTEC PEB-WLBT-07 WiFi/Bluetooth evaluation
adapter on phyBOARD-Nash-i.MX93 board. Adapter uses the u-blox MAYA-W2
module (IW612 chipset) which is capable of Wi-Fi 6 and Bluetooth 5.4 LE.
Add support for PEB-WLBT-05 WLAN/BT adapter on phyBOARD-Segin-i.MX93.
The PEB-WLBT-05 is equipped with a Sterling-LWB radio module, which is
capable of Wi-Fi 802.11 b/g/n and Bluetooth 4.2.
Add overlay to support PEB-EVAL-01 adapter on phyBOARD-Segin-i.MX93.
This is a PHYTEC evaluation module with three LEDs and two input buttons
that users can attach to the board expansion connector X16.
Note that, due to compatibility with existing PHYTEC platforms using the
phyBOARD-Segin carrier board such as i.MX6UL and STM32MP1, we face some
hardware limitations and can thus only support one user LED (D2) and one
button (S2) on the i.MX93 variant of the phyBOARD-Segin.
Alexander Stein [Tue, 1 Jul 2025 06:24:54 +0000 (08:24 +0200)]
arm64: dts: tqmls1046a: Enable SFP interfaces
There are two SFP interfaces usable on TQMLS1046A. Enable all the
corresponding nodes. U-Boot will configure the connection if the RCW
is configured accordingly.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Alexander Stein [Tue, 1 Jul 2025 06:24:53 +0000 (08:24 +0200)]
arm64: dts: tqmls1043a: Enable SFP interface
There is an SFP interface usable on TQMLS1043A. Enable all the
corresponding nodes. U-Boot will configure the connection if the RCW
is configured accordingly.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Alexander Stein [Tue, 1 Jul 2025 06:24:50 +0000 (08:24 +0200)]
arm64: dts: fsl-ls1046a: Remove superfluous address and size cells
The jedec SPI-NOR flash node itself has no partitions, but the partitions
subnode.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Alexander Stein [Tue, 1 Jul 2025 06:24:49 +0000 (08:24 +0200)]
arm64: dts: fsl-ls1043a: Remove superfluous address and size cells
The jedec SPI-NOR flash node itself has no partitions, but the partitions
subnode.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Adam Ford [Thu, 3 Jul 2025 11:38:10 +0000 (06:38 -0500)]
arm64: dts: imx8mn: Configure DMA on UART2
UART2 is often used as the console, so the DMA was likely left
off on purpose, since it's recommended to not use the DMA on the
console. Because, the driver checks to see if the UART is used for
the console when determining if it should initialize DMA, it
should be safe to enable DMA on UART2 for all users.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Adam Ford [Thu, 3 Jul 2025 11:38:09 +0000 (06:38 -0500)]
arm64: dts: imx8mm: Configure DMA on UART2
UART2 is often used as the console, so the DMA was likely left
off on purpose, since it's recommended to not use the DMA on the
console. Because, the driver checks to see if the UART is used for
the console when determining if it should initialize DMA, it
should be safe to enable DMA on UART2 for all users.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
On phyCORE-i.MX93 SoM, the SoC WDOG_ANY output line is connected to the
external pca9451a PMIC WDOG_B input. Apply pinctrl and set the property
"fsl,ext-reset-output" for watchdog to trigger board reset via PMIC on
timeout/reset.
The reference manual for the i.MX8MN states the clock rate in
MMC mode is 1/2 of the input clock, therefore to properly run
at HS400 rates, the input clock must be 400MHz to operate at
200MHz. Currently the clock is set to 200MHz which is half the
rate it should be, so the throughput is half of what it should be
for HS400 operation.
Fixes: 36ca3c8ccb53 ("arm64: dts: imx: Add Beacon i.MX8M Nano development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The reference manual for the i.MX8MM states the clock rate in
MMC mode is 1/2 of the input clock, therefore to properly run
at HS400 rates, the input clock must be 400MHz to operate at
200MHz. Currently the clock is set to 200MHz which is half the
rate it should be, so the throughput is half of what it should be
for HS400 operation.
Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Alexander Stein [Thu, 19 Jun 2025 05:45:11 +0000 (07:45 +0200)]
arm64: dts: tqma8mpql-mba8mpxl-lvds: Rename overlay to include display name
This platform supports several displays, so rename the overlay to reflect
the actual display being used. This also aligns the name to the other
TQMa8M* modules. Apply the same change for MBa8MP-RAS314 as well, as it
uses the same overlay.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
arm64: dts: imx8qm-mek: support revd board's wm8962 codec
The i.MX8QM MEK RevD board is a reworked version of the i.MX8QM MEK
board, which includes some sensor and component changes. One of these
components is the WM8962 codec, which is meant to replace the WM8960
codec present on i.MX8QM MEK. To avoid having to introduce a devicetree
overlay or another DTS, the WM8962 can be supported by using a virtual
I2C MUX since both of the codecs share the same I2C address.
arm64: dts: imx8qxp-mek: support wcpu board's wm8962 codec
The i.MX8QXP WCPU MEK board is a reworked version of the i.MX8QXP MEK
board, which includes some sensor and component changes. One of these
components is the WM8962 codec, which is meant to replace the WM8960
codec present on i.MX8QXP MEK. To avoid having to introduce a devicetree
overlay or another DTS, the WM8962 can be supported by using a virtual
I2C MUX since both of the codecs share the same I2C address.
Joy Zou [Mon, 16 Jun 2025 18:12:59 +0000 (14:12 -0400)]
arm64: dts: imx93: add edma error interrupt support
Add edma error irq for imx93.
Signed-off-by: Joy Zou <joy.zou@nxp.com> Reviewed-by: Alberto Merciai <alb3rt0.m3rciai@gmail.com> Tested-by: Alberto Merciai <alb3rt0.m3rciai@gmail.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
arm64: dts: freescale: imx8mp-toradex-smarc: add fan cooling levels
The fan controller on this board cannot work in automatic mode, and
requires software control, the reason is that it has no temperature
sensor connected.
Given that this board is a development kit and does not have any
specific fan, add a default single cooling level that would enable the
fan to spin with a 100% duty cycle, enabling a safe default.
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Adam Ford [Thu, 12 Jun 2025 00:39:22 +0000 (19:39 -0500)]
arm64: dts: imx8mp: Configure VPU clocks for overdrive
The defaults for this SoC are configured for overdrive mode, but
the VPU clocks are currently configured for nominal mode.
Increase VPU_G1_CLK_ROOT to 800MHZ from 600MHz,
Increase VPU_G2_CLK_ROOT to 700MHZ from 500MHz, and
Increase VPU_BUS_CLK_ROOT to 800MHz from 600MHz.
This requires adjusting the clock parents. Since there is already
800MHz clock references, move the VPU_BUS and G1 clocks to it.
This frees up the VPU_PLL to be configured at 700MHz to run
the G2 clock at 700MHz.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
In preparation for increasing the default VPU clocks to overdrive,
configure the nominal values first to avoid running the nominal
devices out of spec when imx8mp.dtsi is changed.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Marco Felsch [Thu, 12 Jun 2025 00:39:19 +0000 (19:39 -0500)]
arm64: dts: imx8mp: drop gpcv2 vpu power-domains and clocks
The GPCv2 G1, G2 and VC8000E power-domain don't need to reference the
VPUMIX power-domain nor their module clocks since the power and reset
handling is done by the VPUMIX blkctrl driver.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Adam Ford <aford173@gmail.com>
LGTM: Peng Fan <peng.fan@nxp.com> Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon-kit Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Horia Geantă [Wed, 11 Jun 2025 11:38:09 +0000 (11:38 +0000)]
arm64: dts: freescale: imx8qxp/imx8qm: Add CAAM support
The iMX8QXP and iMX8QM have a CAAM (Cryptographic Acceleration and
Assurance Module) like many other iMXs.
Add the definitions for it.
Job Rings 0 and 1 are bound to the SECO (Security Controller) ARM core
and are not exposed outside it. There's no point to define them in the
bindings as they cannot be used outside the SECO.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: John Ernberg <john.ernberg@actia.se> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Joy Zou [Mon, 9 Jun 2025 16:52:37 +0000 (12:52 -0400)]
arm64: dts: imx93-11x11-evk: remove the duplicated pinctrl_lpi2c3 node
Remove the duplicated pinctrl_lpi2c3 node.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Joy Zou <joy.zou@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Clark Wang [Mon, 9 Jun 2025 16:52:35 +0000 (12:52 -0400)]
arm64: dts: imx93-11x11-evk: disable all realtek ethernet phy CLKOUT
The realtek phy CLKOUT signal is not used. Disable it to save power.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Clark Wang [Mon, 9 Jun 2025 16:52:33 +0000 (12:52 -0400)]
arm64: dts: imx93: remove eee-broken-1000t for eqos node
The "eee-broken-1000t" was added on 8mm for FEC to avoid issue of ptp sync.
EQoS haven't such issue. So, remove this for EQoS phys.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Haibo Chen [Mon, 9 Jun 2025 16:52:32 +0000 (12:52 -0400)]
arm64: dts: imx93-9x9-qsb: add IMU sensor support
The i.MX93 9x9 qsb has a ST LSM6DSO connected to I2C, which a is 6-axis
IMU (inertial measurement unit = accelerometer & gyroscope). So add the
missing parts to the DTS file.
Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
arm64: dts: freescale: imx8mp-var-som: Add EQoS support with MaxLinear PHY
Enable the EQoS Ethernet controller on the i.MX8MP VAR-SOM with the
integrated Maxlinear MXL86110 PHY. The PHY is connected to the EQOS
MDIO bus at address 4.
This patch adds:
- EQOS controller configuration with RGMII interface.
- Proper reset timings.
- PHY power supply regulators.
- RGMII pinmux configuration for all data, control and clock signals.
- LED configuration for link status indication via the LED subsystem
under /sys/class/leds/, leveraging the support implemented in the.
mxl86110 PHY driver (drivers/net/phy/mxl-86110.c).
Two LEDs are defined to match the LED configuration on the Variscite
VAR-SOM Carrier Boards:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
The RGMII TX/RX delays are implemented in SOM via PCB passive
delays, so no software delay configuration is required.
Thomas Richard [Mon, 9 Jun 2025 12:02:34 +0000 (14:02 +0200)]
arm64: dts: imx8qm: add system controller watchdog support
Add system controller watchdog support for i.MX8QM.
Acked-by: Oliver Graute <oliver.graute@kococonnector.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Luke Wang [Fri, 6 Jun 2025 19:00:43 +0000 (15:00 -0400)]
arm64: dts: imx95-19x19-evk: adjust pinctrl settings for usdhc2
The driver strength is too high for SDR104 mode. Change the driver strength
to x3 according to hardware recommendation.
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add USB3 PHY tuning properties for imx95-15x15-evk and imx95-19x19-evk
boards according to signal measurement results.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
arm64: dts: freescale: imx93-var-som: update eqos support for MaxLinear PHY
Variscite has updated the Ethernet PHY on the VAR-SOM-MX93 from the
ADIN1300BCPZ to the MaxLinear MXL86110, as documented in the
August 2023 revision changelog. Link: https://variwiki.com/index.php?title=VAR-SOM-MX93_rev_changelog
Update the device tree accordingly:
- Drop the regulator node used to power the previously PHY.
- Add support for the reset line using GPIO1_IO07 with proper timings.
- Configure the PHY LEDs via the LED subsystem under /sys/class/leds/,
leveraging the support implemented in the mxl86110 PHY driver
(drivers/net/phy/mxl-86110.c).
Two LEDs are defined to match the LED configuration on the Variscite
VAR-SOM Carrier Boards:
* LED@0: Yellow, netdev trigger.
* LED@1: Green, netdev trigger.
- Adjust the RGMII clock pad control settings to match the updated PHY
requirements.
These changes ensure proper PHY initialization and LED status indication
for the new MaxLinear MXL86110, improving board compatibility with the
latest hardware revision.
Primoz Fiser [Mon, 2 Jun 2025 12:52:07 +0000 (14:52 +0200)]
arm64: dts: freescale: imx93-phyboard-nash: Move ADC vref to SoM
Move configuration for ADC voltage reference from board DTS to a SoM
include file. The SoC ADC reference voltage is connected to a "VDDA_1V8"
voltage node and supplied by the PMIC's BUCK5 regulator. The reference
voltage is thus defined by the SoM and cannot be changed by the carrier
board design and as such belongs into the SoM include file.
Moreover, with this in place, customers designing own carrier boards can
simply include imx93-phycore-som.dtsi and enable adc1 in their own DTS
without the need to define dummy ADC vref regulator themselves anymore.
Carlos Song [Wed, 28 May 2025 01:58:34 +0000 (09:58 +0800)]
arm64: dts: imx943-evk: add i2c io expander support
Add i2c io expander support for imx943 evk board.
Signed-off-by: Carlos Song <carlos.song@nxp.com> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Carlos Song [Wed, 28 May 2025 01:58:33 +0000 (09:58 +0800)]
arm64: dts: imx943-evk: add lpi2c support
Add lpi2c and i2c-mux support for imx943 evk board.
Signed-off-by: Carlos Song <carlos.song@nxp.com> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Larisa Grigore [Thu, 22 May 2025 14:51:43 +0000 (15:51 +0100)]
arm64: dts: Add DSPI entries for S32G platforms
S32G3 and S32G2 have the same 6 SPI devices, add the DT entries. Devices
are all the same except spi0 has 8 chip selects instead of 5. Clock
settings for the chip rely on ATF Firmware [1].
[1]: https://github.com/nxp-auto-linux/arm-trusted-firmware Co-developed-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Primoz Fiser [Thu, 22 May 2025 08:39:09 +0000 (10:39 +0200)]
arm64: dts: freescale: imx93-phyboard-segin: Set ethernet1 alias
Set ethernet1 alias to EQOS interface on phyBOARD-Segin-i.MX93 marking
it the secondary networking interface. The primary ethernet0 interface
is already set by the SoM include file (imx93-phycore-som.dtsi).
Primoz Fiser [Thu, 22 May 2025 08:39:08 +0000 (10:39 +0200)]
arm64: dts: freescale: imx93-phycore-som: Move ethernet0 alias to SoM
Move alias for ethernet0 interface to the phyCORE-i.MX93 SoM include
file. The reason behind it is that the physical location of the PHY chip
connected to FEC interface is on the SoM itself and alias thus belongs
into the SoM device-tree. Consequently, it can be used by all boards
based on the phyCORE-i.MX93 SoM (phyBOARD-Segin and phyBOARD-Nash).
This also enables us to mark FEC interface as the primary / first for
networking in the bootloader and systemd (predictable interface names).
Maud Spierings [Tue, 20 May 2025 06:34:56 +0000 (08:34 +0200)]
arm64: dts: freescale: Add the BOE av101hdt-a10 variant of the Moduline Display
Add the BOE av101hdt-a10 variant of the Moduline Display, this variant
comes with a 10.1 1280x720 display with a touchscreen (not working in
mainline).
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Maud Spierings [Tue, 20 May 2025 06:34:55 +0000 (08:34 +0200)]
arm64: dts: freescale: Add the GOcontroll Moduline Display baseboard
The Moduline Display platform is a part of the wider GOcontroll Moduline
ecosystem. These are embedded controllers that focus on modularity with
their swappable IO modules.
The base Moduline Display board includes a board-to-board connector with
various busses to enable adding new display types required by the
application. It includes 2 Moduline IO module slots, a simple mono
codec/amplifier, a four channel adc, 2 CAN busses, an RTC and optional
wifi/bluetooth.
busses to the display adapter include:
- 4 lane LVDS
- 4 lane MIPI-DSI
- 4 lane MIPI-CSI
- HDMI 2.0a
- USB 2.0
- I2S
- I2C
- SPI
Also a couple of GPIO and PWM pins for controlling various ICs on the
display adapter board.
Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this
register is written in the dts, these values are not obvious. Add defines
which describe the fields of this register which can be or-ed together to
produce readable settings.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Haibo Chen [Tue, 20 May 2025 03:46:14 +0000 (11:46 +0800)]
arm64: dts: add ngpios for vf610 compatible gpio controllers
After commit da5dd31efd24 ("gpio: vf610: Switch to gpio-mmio"),
the vf610 GPIO driver no longer uses the static number 32 for
gc->ngpio. This allows users to configure the number of GPIOs
per port.
And some gpio controllers did have less pads. So add 'ngpios' here,
this can save some memory when request bitmap, and also show user
more accurate information when use gpio tools.
Besides, some gpio controllers have hole in the gpio ranges, so use
'gpio-reserved-ranges' to cover that, then the gpioinfo tool show the
correct result.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Starting with commit e6ef4f8ede09f ("gpio: vf610: make irq_chip immutable")
gpio-vf610 supports locking GPIO being used for IRQ. This already prevents
configuring the GPIO as output, so there is no need for a GPIO hog.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Linus Torvalds [Sun, 8 Jun 2025 18:33:00 +0000 (11:33 -0700)]
Merge tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer cleanup from Thomas Gleixner:
"The delayed from_timer() API cleanup:
The renaming to the timer_*() namespace was delayed due massive
conflicts against Linux-next. Now that everything is upstream finish
the conversion"
* tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename from_timer() to timer_container_of()
Linus Torvalds [Sun, 8 Jun 2025 18:27:20 +0000 (11:27 -0700)]
Merge tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Thomas Gleixner:
"A small set of x86 fixes:
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread
via exit_thread(). exit_thread() invokes io_bitmap_exit() which
does the IO bitmap cleanups, which unfortunately assume that the
cleanup is related to the current task, which is obviously bogus.
Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the
command buffer in two places, which keeps stale error messages
around. Bring them back.
- Remove unused trace events"
* tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
x86/fpu: Remove unused trace events
Zhang Rui [Fri, 30 May 2025 00:09:28 +0000 (08:09 +0800)]
tools/power turbostat: Avoid probing the same perf counters
For the RAPL package energy status counter, Intel and AMD share the same
perf_subsys and perf_name, but with different MSR addresses.
Both rapl_counter_arch_infos[0] and rapl_counter_arch_infos[1] are
introduced to describe this counter for different Vendors.
As a result, the perf counter is probed twice, and causes a failure in
in get_rapl_counters() because expected_read_size and actual_read_size
don't match.
Fix the problem by skipping the already probed counter.
Note, this is not a perfect fix. For example, if different
vendors/platforms use the same MSR value for different purpose, the code
can be fooled when it probes a rapl_counter_arch_infos[] entry that does
not belong to the running Vendor/Platform.
In a long run, better to put rapl_counter_arch_infos[] into the
platform_features so that this becomes Vendor/Platform specific.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Zhang Rui [Sat, 17 May 2025 09:44:50 +0000 (17:44 +0800)]
tools/power turbostat: Allow probing RAPL with platform_features->rapl_msrs cleared
platform_features->rapl_msrs describes the RAPL MSRs supported. While
RAPL Perf counters can be exposed from different kernel backend drivers,
e.g. RAPL MSR I/F driver, or RAPL TPMI I/F driver.
Thus, turbostat should first blindly probe all the available RAPL Perf
counters, and falls back to the RAPL MSR counters if they are listed in
platform_features->rapl_msrs.
With this, platforms that don't have RAPL MSRs can clear the
platform_features->rapl_msrs bits and use RAPL Perf counters only.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
probe_rapl_msr() is reused for probing RAPL MSR counters, cstate MSR
counters and MPERF/APERF/SMI MSR counters, thus its name is misleading.
Similar to add_perf_counter(), introduce add_msr_counter() to probe a
counter via MSR. Introduce wrapper function add_rapl_msr_counter() at
the same time to add extra check for Zero return value for specified
RAPL counters.
No functional change intended.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_cstate_perf_counter_(),
add_cstate_perf_counter() just gives extra debug output on top. There is
no need to keep both functions.
Remove add_cstate_perf_counter_() and move all the logic to
add_cstate_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
commit 05a2f07db888 ("tools/power turbostat: read RAPL counters via
perf") that adds support to read RAPL counters via perf defines the
notion of a RAPL domain_id which is set to physical_core_id on
platforms which support per_core_rapl counters (Eg: AMD processors
Family 17h onwards) and is set to the physical_package_id on all the
other platforms.
However, the physical_core_id is only unique within a package and on
platforms with multiple packages more than one core can have the same
physical_core_id and thus the same domain_id. (For eg, the first cores
of each package have the physical_core_id = 0). This results in all
these cores with the same physical_core_id using the same entry in the
rapl_counter_info_perdomain[]. Since rapl_perf_init() skips the
perf-initialization for cores whose domain_ids have already been
visited, cores that have the same physical_core_id always read the
perf file corresponding to the physical_core_id of the first package
and thus the package-energy is incorrectly reported to be the same
value for different packages.
Note: This issue only arises when RAPL counters are read via perf and
not when they are read via MSRs since in the latter case the MSRs are
read separately on each core.
Fix this issue by associating each CPU with rapl_core_id which is
unique across all the packages in the system.
Fixes: 05a2f07db888 ("tools/power turbostat: read RAPL counters via perf") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Len Brown <len.brown@intel.com>
projects / thirdparty / kernel / stable.git / log
