* [PATCH v2 1/2] dt-bindings: arm: aspeed: Add Meta Rainiera6 board
From: Neil Cheng @ 2026-05-19 2:38 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, joel, andrew, geert+renesas, magnus.damm
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-renesas-soc, Neil Cheng, Conor Dooley
In-Reply-To: <cover.1779157117.git.neilcheng0417@gmail.com>
Document the new compatibles used on Meta Rainiera6.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Cheng <neilcheng0417@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 8ec7a3e74a21..1a2252eb08f1 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -95,6 +95,7 @@ properties:
- facebook,greatlakes-bmc
- facebook,harma-bmc
- facebook,minerva-cmc
+ - facebook,rainiera6-bmc
- facebook,santabarbara-bmc
- facebook,yosemite4-bmc
- facebook,yosemite5-bmc
--
2.25.1
^ permalink raw reply related
* [PATCH v2 0/2] Add Meta Rainiera6 BMC support
From: Neil Cheng @ 2026-05-19 2:38 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, joel, andrew, geert+renesas, magnus.damm
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-renesas-soc, Neil Cheng
In-Reply-To: <cover.1779088499.git.neilcheng0417@gmail.com>
Add initial device tree support for the Meta Rainiera6 platform.
Changes in v2:
- reorder adc0/adc1 properties
- add Acked-by from Conor Dooley
This series adds:
- Meta Rainiera6 compatible entry
- Rainiera6 BMC DTS
The DTS has been validated with:
- make dtbs
- make dt_binding_check
- make CHECK_DTBS=y
Neil Cheng (2):
dt-bindings: arm: aspeed: Add Meta Rainiera6 board
ARM: dts: aspeed: rainiera6: Add Meta Rainiera6 BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../aspeed/aspeed-bmc-facebook-rainiera6.dts | 1012 +++++++++++++++++
3 files changed, 1014 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-rainiera6.dts
--
2.25.1
^ permalink raw reply
* Re: [PATCH v4 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Kyle Hsieh @ 2026-05-19 2:38 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <39b9a80fe4f49d72cefb8d3f8f1bb3776b9c4226.camel@codeconstruct.com.au>
On Mon, May 18, 2026 at 3:18 PM Andrew Jeffery
<andrew@codeconstruct.com.au> wrote:
>
> Hi Kyle,
>
> Firstly, are you trying to represent multiple revisions of the hardware
> design in this devicetree? I'm curious due to the 'legacy' labels
> below.
>
In the previous Ventura hardware generation, these pins were
implemented as a set of direct, native physical GPIO signals. In the V2
design, we introduced alternative interfaces and routed these paths
through the CPLD to convert them into GPIOs before reaching the
BMC.
We chose to retain the 'legacy' prefix to maintain backward
compatibility with our existing userspace software stack and scripts
that transitioned from the previous Ventura platform. Altering these
labels now would break compatibility with applications that rely on
these specific naming conventions. I will add comments in the DTS to
clarify this context.
> On Fri, 2026-04-24 at 17:30 +0800, Kyle Hsieh wrote:
> > Add linux device tree entry related to the Meta(Facebook) rmc-node.
> > The system use an AT2600 BMC.
> > This node is named "ventura2".
> >
> > Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> > ---
> > arch/arm/boot/dts/aspeed/Makefile | 1 +
> > .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2925 ++++++++++++++++++++
> > 2 files changed, 2926 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
> > index 9adf9278dc94..6b96997629d4 100644
> > --- a/arch/arm/boot/dts/aspeed/Makefile
> > +++ b/arch/arm/boot/dts/aspeed/Makefile
> > @@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> > aspeed-bmc-facebook-minipack.dtb \
> > aspeed-bmc-facebook-santabarbara.dtb \
> > aspeed-bmc-facebook-tiogapass.dtb \
> > + aspeed-bmc-facebook-ventura2.dtb \
> > aspeed-bmc-facebook-wedge40.dtb \
> > aspeed-bmc-facebook-wedge100.dtb \
> > aspeed-bmc-facebook-wedge400-data64.dtb \
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> > new file mode 100644
> > index 000000000000..8d4ddb473862
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
> > @@ -0,0 +1,2925 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2023 Facebook Inc.
> > +/dts-v1/;
> > +
> > +#include "aspeed-g6.dtsi"
> > +#include <dt-bindings/i2c/i2c.h>
> > +#include <dt-bindings/gpio/aspeed-gpio.h>
> > +
> > +/ {
> > + model = "Facebook Ventura2 RMC";
> > + compatible = "facebook,ventura2-rmc", "aspeed,ast2600";
> > + aliases {
> > + serial2 = &uart3;
> > + serial4 = &uart5;
> > +
> > + /*
> > + * i2c switch 0-0077, pca9548, 8 child channels assigned
> > + * with bus number 16-23.
> > + */
> > + i2c16 = &i2c0mux0ch0;
> > + i2c17 = &i2c0mux0ch1;
> > + i2c18 = &i2c0mux0ch2;
> > + i2c19 = &i2c0mux0ch3;
> > + i2c20 = &i2c0mux0ch4;
> > + i2c21 = &i2c0mux0ch5;
> > + i2c22 = &i2c0mux0ch6;
> > + i2c23 = &i2c0mux0ch7;
> > +
> > + /*
> > + * i2c switch 1-0077, pca9548, 8 child channels assigned
> > + * with bus number 24-31.
> > + */
> > + i2c24 = &i2c1mux0ch0;
> > + i2c25 = &i2c1mux0ch1;
> > + i2c26 = &i2c1mux0ch2;
> > + i2c27 = &i2c1mux0ch3;
> > + i2c28 = &i2c1mux0ch4;
> > + i2c29 = &i2c1mux0ch5;
> > + i2c30 = &i2c1mux0ch6;
> > + i2c31 = &i2c1mux0ch7;
> > +
> > + /*
> > + * i2c switch 4-0077, pca9548, 8 child channels assigned
> > + * with bus number 32-39.
> > + */
> > + i2c32 = &i2c4mux0ch0;
> > + i2c33 = &i2c4mux0ch1;
> > + i2c34 = &i2c4mux0ch2;
> > + i2c35 = &i2c4mux0ch3;
> > + i2c36 = &i2c4mux0ch4;
> > + i2c37 = &i2c4mux0ch5;
> > + i2c38 = &i2c4mux0ch6;
> > + i2c39 = &i2c4mux0ch7;
> > +
> > + /*
> > + * i2c switch 5-0077, pca9548, 8 child channels assigned
> > + * with bus number 40-47.
> > + */
> > + i2c40 = &i2c5mux0ch0;
> > + i2c41 = &i2c5mux0ch1;
> > + i2c42 = &i2c5mux0ch2;
> > + i2c43 = &i2c5mux0ch3;
> > + i2c44 = &i2c5mux0ch4;
> > + i2c45 = &i2c5mux0ch5;
> > + i2c46 = &i2c5mux0ch6;
> > + i2c47 = &i2c5mux0ch7;
> > +
> > + /*
> > + * i2c switch 8-0077, pca9548, 8 child channels assigned
> > + * with bus number 48-55.
> > + */
> > + i2c48 = &i2c8mux0ch0;
> > + i2c49 = &i2c8mux0ch1;
> > + i2c50 = &i2c8mux0ch2;
> > + i2c51 = &i2c8mux0ch3;
> > + i2c52 = &i2c8mux0ch4;
> > + i2c53 = &i2c8mux0ch5;
> > + i2c54 = &i2c8mux0ch6;
> > + i2c55 = &i2c8mux0ch7;
> > +
> > + /*
> > + * i2c switch 11-0077, pca9548, 8 child channels assigned
> > + * with bus number 56-63.
> > + */
> > + i2c56 = &i2c11mux0ch0;
> > + i2c57 = &i2c11mux0ch1;
> > + i2c58 = &i2c11mux0ch2;
> > + i2c59 = &i2c11mux0ch3;
> > + i2c60 = &i2c11mux0ch4;
> > + i2c61 = &i2c11mux0ch5;
> > + i2c62 = &i2c11mux0ch6;
> > + i2c63 = &i2c11mux0ch7;
> > +
> > + /*
> > + * i2c switch 13-0077, pca9548, 8 child channels assigned
> > + * with bus number 64-71.
> > + */
> > + i2c64 = &i2c13mux0ch0;
> > + i2c65 = &i2c13mux0ch1;
> > + i2c66 = &i2c13mux0ch2;
> > + i2c67 = &i2c13mux0ch3;
> > + i2c68 = &i2c13mux0ch4;
> > + i2c69 = &i2c13mux0ch5;
> > + i2c70 = &i2c13mux0ch6;
> > + i2c71 = &i2c13mux0ch7;
> > +
> > + /*
> > + * i2c switch 15-0077, pca9548, 8 child channels assigned
> > + * with bus number 72-79.
> > + */
> > + i2c72 = &i2c15mux0ch0;
> > + i2c73 = &i2c15mux0ch1;
> > + i2c74 = &i2c15mux0ch2;
> > + i2c75 = &i2c15mux0ch3;
> > + i2c76 = &i2c15mux0ch4;
> > + i2c77 = &i2c15mux0ch5;
> > + i2c78 = &i2c15mux0ch6;
> > + i2c79 = &i2c15mux0ch7;
>
> Can you please add comments justifying why all of these aliases are
> necessary given a number of them are for busses with no devices
> described under them?
These I2C aliases are pre-allocated because these empty channels are
strictly reserved for future hardware feature expansions, which will
interface with add-on boards. I will add clear comments in the code to
justify their necessity in the next patch.
>
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial4:57600n8";
> > + };
> > +
> > + fan_leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + label = "fcb0fan0_ledd1_blue";
>
> Given the labels are exposed to userspace and is something applications
> likely consume, is the double 'd' in led intentional?
Yes, the double 'd' in "ledd1" is intentional. It aligns with our hardware
schematic design naming convention, where these specific onboard
indicators are designated as LEDD1, LEDD2, etc.
>
> > + default-state = "off";
> > + gpios = <&fan_io_expander0 0 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-1 {
> > + label = "fcb0fan1_ledd2_blue";
> > + default-state = "off";
> > + gpios = <&fan_io_expander0 1 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-2 {
> > + label = "fcb0fan2_ledd3_blue";
> > + default-state = "off";
> > + gpios = <&fan_io_expander1 0 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-3 {
> > + label = "fcb0fan3_ledd4_blue";
> > + default-state = "off";
> > + gpios = <&fan_io_expander1 1 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-4 {
> > + label = "fcb0fan0_ledd1_amber";
> > + default-state = "off";
> > + gpios = <&fan_io_expander0 4 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-5 {
> > + label = "fcb0fan1_ledd2_amber";
> > + default-state = "off";
> > + gpios = <&fan_io_expander0 5 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-6 {
> > + label = "fcb0fan2_ledd3_amber";
> > + default-state = "off";
> > + gpios = <&fan_io_expander1 4 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + led-7 {
> > + label = "fcb0fan3_ledd4_amber";
> > + default-state = "off";
> > + gpios = <&fan_io_expander1 5 GPIO_ACTIVE_LOW>;
> > + };
> > + };
> > +
>
> ...
>
> > +
> > +&fmc {
> > + status = "okay";
> > + flash@0 {
> > + status = "okay";
> > + m25p,fast-read;
> > + label = "bmc";
> > + spi-max-frequency = <50000000>;
> > + #include "openbmc-flash-layout-128.dtsi"
> > + };
> > + flash@1 {
> > + status = "okay";
> > + m25p,fast-read;
> > + label = "alt-bmc";
> > + spi-max-frequency = <50000000>;
>
> Perhaps include the alternate flash layout dtsi here?
The `flash@1` (`alt-bmc`) node is intentionally left unpartitioned
without the layout DTSI.
In our dual-flash design, `flash@1` serves as the secondary/backup
flash chip. Keeping it without sub-partitions allows the kernel and
userspace tools to treat this flash as a single, contiguous raw MTD
device. This is required by our firmware update mechanism, which
flashes a single, full-size composite image directly to the entire
backup flash.
This structure follows the existing upstream pattern established in
`aspeed-bmc-facebook-yosemite5.dts`.
>
> > + };
> > +};
> > +
> > +&peci0 {
>
> Can you please order the nodes alphabetically. P is not between F and
> G.
I will ensure all nodes are strictly sorted in alphabetical order in
the next version.
>
> > + status = "okay";
> > +};
> > +
> >
>
> ...
>
> > +
> > +&i2c10 {
> > + status = "okay";
> > +
> > + legacy_prsnt_io_expander0: gpio@11 {
>
> Why 'legacy'?
>
> > + compatible = "nxp,pca9555";
> > + reg = <0x11>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PRSNT1_N_BUF_R", "TRAY_PRSNT2_N_BUF_R",
> > + "TRAY_PRSNT3_N_BUF_R", "TRAY_PRSNT4_N_BUF_R",
> > + "TRAY_PRSNT5_N_BUF_R", "TRAY_PRSNT6_N_BUF_R",
> > + "TRAY_PRSNT7_N_BUF_R", "TRAY_PRSNT8_N_BUF_R",
> > + "TRAY_PRSNT9_N_BUF_R", "TRAY_PRSNT10_N_BUF_R",
> > + "TRAY_PRSNT11_N_BUF_R", "TRAY_PRSNT12_N_BUF_R",
> > + "TRAY_PRSNT13_N_BUF_R", "TRAY_PRSNT14_N_BUF_R",
> > + "TRAY_PRSNT15_N_BUF_R", "TRAY_PRSNT16_N_BUF_R";
> > + };
> > +
> > + legacy_prsnt_io_expander1: gpio@12 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x12>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PRSNT17_N_BUF_R", "TRAY_PRSNT18_N_BUF_R",
> > + "TRAY_PRSNT19_N_BUF_R", "TRAY_PRSNT20_N_BUF_R",
> > + "TRAY_PRSNT21_N_BUF_R", "TRAY_PRSNT22_N_BUF_R",
> > + "TRAY_PRSNT23_N_BUF_R", "TRAY_PRSNT24_N_BUF_R",
> > + "TRAY_PRSNT25_N_BUF_R", "TRAY_PRSNT26_N_BUF_R",
> > + "TRAY_PRSNT27_N_BUF_R", "TRAY_PRSNT28_N_BUF_R",
> > + "TRAY_PRSNT29_N_BUF_R", "TRAY_PRSNT30_N_BUF_R",
> > + "TRAY_PRSNT31_N_BUF_R", "TRAY_PRSNT32_N_BUF_R";
> > + };
> > +
> > + legacy_prsnt_io_expander2: gpio@13 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x13>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PRSNT33_N_BUF_R", "TRAY_PRSNT34_N_BUF_R",
> > + "TRAY_PRSNT35_N_BUF_R", "TRAY_PRSNT36_N_BUF_R",
> > + "TRAY_PRSNT37_N_BUF_R", "TRAY_PRSNT38_N_BUF_R",
> > + "TRAY_PRSNT39_N_BUF_R", "TRAY_PRSNT40_N_BUF_R",
> > + "", "",
> > + "", "",
> > + "", "",
> > + "", "";
> > + };
> > +
> > + power-monitor@14 {
> > + compatible = "infineon,xdp710";
> > + reg = <0x14>;
> > + };
> > +
> > + legacy_pwrgd_io_expander1: gpio@15 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x15>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PWRGD17_N_BUF_R", "TRAY_PWRGD18_N_BUF_R",
> > + "TRAY_PWRGD19_N_BUF_R", "TRAY_PWRGD20_N_BUF_R",
> > + "TRAY_PWRGD21_N_BUF_R", "TRAY_PWRGD22_N_BUF_R",
> > + "TRAY_PWRGD23_N_BUF_R", "TRAY_PWRGD24_N_BUF_R",
> > + "TRAY_PWRGD25_N_BUF_R", "TRAY_PWRGD26_N_BUF_R",
> > + "TRAY_PWRGD27_N_BUF_R", "TRAY_PWRGD28_N_BUF_R",
> > + "TRAY_PWRGD29_N_BUF_R", "TRAY_PWRGD30_N_BUF_R",
> > + "TRAY_PWRGD31_N_BUF_R", "TRAY_PWRGD32_N_BUF_R";
> > + };
> > +
> > + legacy_pwrgd_io_expander2: gpio@16 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x16>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PWRGD33_N_BUF_R", "TRAY_PWRGD34_N_BUF_R",
> > + "TRAY_PWRGD35_N_BUF_R", "TRAY_PWRGD36_N_BUF_R",
> > + "TRAY_PWRGD37_N_BUF_R", "TRAY_PWRGD38_N_BUF_R",
> > + "TRAY_PWRGD39_N_BUF_R", "TRAY_PWRGD40_N_BUF_R",
> > + "", "",
> > + "", "",
> > + "", "",
> > + "", "";
> > + };
> > +
> > + legacy_leak_io_expander0: gpio@17 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x17>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_LEAK_DETECT1_N_BUF_R", "TRAY_LEAK_DETECT2_N_BUF_R",
> > + "TRAY_LEAK_DETECT3_N_BUF_R", "TRAY_LEAK_DETECT4_N_BUF_R",
> > + "TRAY_LEAK_DETECT5_N_BUF_R", "TRAY_LEAK_DETECT6_N_BUF_R",
> > + "TRAY_LEAK_DETECT7_N_BUF_R", "TRAY_LEAK_DETECT8_N_BUF_R",
> > + "TRAY_LEAK_DETECT9_N_BUF_R", "TRAY_LEAK_DETECT10_N_BUF_R",
> > + "TRAY_LEAK_DETECT11_N_BUF_R", "TRAY_LEAK_DETECT12_N_BUF_R",
> > + "TRAY_LEAK_DETECT13_N_BUF_R", "TRAY_LEAK_DETECT14_N_BUF_R",
> > + "TRAY_LEAK_DETECT15_N_BUF_R", "TRAY_LEAK_DETECT16_N_BUF_R";
> > + };
> > +
> > + legacy_leak_io_expander1: gpio@18 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x18>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_LEAK_DETECT17_N_BUF_R", "TRAY_LEAK_DETECT18_N_BUF_R",
> > + "TRAY_LEAK_DETECT19_N_BUF_R", "TRAY_LEAK_DETECT20_N_BUF_R",
> > + "TRAY_LEAK_DETECT21_N_BUF_R", "TRAY_LEAK_DETECT22_N_BUF_R",
> > + "TRAY_LEAK_DETECT23_N_BUF_R", "TRAY_LEAK_DETECT24_N_BUF_R",
> > + "TRAY_LEAK_DETECT25_N_BUF_R", "TRAY_LEAK_DETECT26_N_BUF_R",
> > + "TRAY_LEAK_DETECT27_N_BUF_R", "TRAY_LEAK_DETECT28_N_BUF_R",
> > + "TRAY_LEAK_DETECT29_N_BUF_R", "TRAY_LEAK_DETECT30_N_BUF_R",
> > + "TRAY_LEAK_DETECT31_N_BUF_R", "TRAY_LEAK_DETECT32_N_BUF_R";
> > + };
> > +
> > + legacy_leak_io_expander2: gpio@19 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x19>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_LEAK_DETECT33_N_BUF_R", "TRAY_LEAK_DETECT34_N_BUF_R",
> > + "TRAY_LEAK_DETECT35_N_BUF_R", "TRAY_LEAK_DETECT36_N_BUF_R",
> > + "TRAY_LEAK_DETECT37_N_BUF_R", "TRAY_LEAK_DETECT38_N_BUF_R",
> > + "TRAY_LEAK_DETECT39_N_BUF_R", "TRAY_LEAK_DETECT40_N_BUF_R",
> > + "", "",
> > + "", "",
> > + "", "",
> > + "", "";
> > + };
> > +
> > + legacy_small_leak_io_expander0: gpio@1a {
> > + compatible = "nxp,pca9555";
> > + reg = <0x1a>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_SMALL_LEAK1_N_BUF_R", "TRAY_SMALL_LEAK2_N_BUF_R",
> > + "TRAY_SMALL_LEAK3_N_BUF_R", "TRAY_SMALL_LEAK4_N_BUF_R",
> > + "TRAY_SMALL_LEAK5_N_BUF_R", "TRAY_SMALL_LEAK6_N_BUF_R",
> > + "TRAY_SMALL_LEAK7_N_BUF_R", "TRAY_SMALL_LEAK8_N_BUF_R",
> > + "TRAY_SMALL_LEAK9_N_BUF_R", "TRAY_SMALL_LEAK10_N_BUF_R",
> > + "TRAY_SMALL_LEAK11_N_BUF_R", "TRAY_SMALL_LEAK12_N_BUF_R",
> > + "TRAY_SMALL_LEAK13_N_BUF_R", "TRAY_SMALL_LEAK14_N_BUF_R",
> > + "TRAY_SMALL_LEAK15_N_BUF_R", "TRAY_SMALL_LEAK16_N_BUF_R";
> > + };
> > +
> > + legacy_small_leak_io_expander1: gpio@1b {
> > + compatible = "nxp,pca9555";
> > + reg = <0x1b>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_SMALL_LEAK17_N_BUF_R", "TRAY_SMALL_LEAK18_N_BUF_R",
> > + "TRAY_SMALL_LEAK19_N_BUF_R", "TRAY_SMALL_LEAK20_N_BUF_R",
> > + "TRAY_SMALL_LEAK21_N_BUF_R", "TRAY_SMALL_LEAK22_N_BUF_R",
> > + "TRAY_SMALL_LEAK23_N_BUF_R", "TRAY_SMALL_LEAK24_N_BUF_R",
> > + "TRAY_SMALL_LEAK25_N_BUF_R", "TRAY_SMALL_LEAK26_N_BUF_R",
> > + "TRAY_SMALL_LEAK27_N_BUF_R", "TRAY_SMALL_LEAK28_N_BUF_R",
> > + "TRAY_SMALL_LEAK29_N_BUF_R", "TRAY_SMALL_LEAK30_N_BUF_R",
> > + "TRAY_SMALL_LEAK31_N_BUF_R", "TRAY_SMALL_LEAK32_N_BUF_R";
> > + };
> > +
> > + legacy_small_leak_io_expander2: gpio@1c {
> > + compatible = "nxp,pca9555";
> > + reg = <0x1c>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_SMALL_LEAK33_N_BUF_R", "TRAY_SMALL_LEAK34_N_BUF_R",
> > + "TRAY_SMALL_LEAK35_N_BUF_R", "TRAY_SMALL_LEAK36_N_BUF_R",
> > + "TRAY_SMALL_LEAK37_N_BUF_R", "TRAY_SMALL_LEAK38_N_BUF_R",
> > + "TRAY_SMALL_LEAK39_N_BUF_R", "TRAY_SMALL_LEAK40_N_BUF_R",
> > + "", "",
> > + "", "",
> > + "", "",
> > + "", "";
> > + };
> > +
> > + legacy_pwrgd_io_expander0: gpio@28 {
> > + compatible = "nxp,pca9555";
> > + reg = <0x28>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + interrupt-parent = <&sgpiom0>;
> > + interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + gpio-line-names =
> > + "TRAY_PWRGD1_N_BUF_R", "TRAY_PWRGD2_N_BUF_R",
> > + "TRAY_PWRGD3_N_BUF_R", "TRAY_PWRGD4_N_BUF_R",
> > + "TRAY_PWRGD5_N_BUF_R", "TRAY_PWRGD6_N_BUF_R",
> > + "TRAY_PWRGD7_N_BUF_R", "TRAY_PWRGD8_N_BUF_R",
> > + "TRAY_PWRGD9_N_BUF_R", "TRAY_PWRGD10_N_BUF_R",
> > + "TRAY_PWRGD11_N_BUF_R", "TRAY_PWRGD12_N_BUF_R",
> > + "TRAY_PWRGD13_N_BUF_R", "TRAY_PWRGD14_N_BUF_R",
> > + "TRAY_PWRGD15_N_BUF_R", "TRAY_PWRGD16_N_BUF_R";
> > + };
> > +
>
> ...
>
> > +
> > +&mdio0 {
> > + status = "okay";
> > +};
> > +
> > +&peci0 {
> > + status = "okay";
> > +};
>
> Ah, so the earlier peci node is redundant. Can you please remove it?
Got it. I will remove the redundant peci0 node and ensure all nodes
are strictly sorted in alphabetical order in the next version.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
From: Prasanth @ 2026-05-19 2:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: joel, andrew, robh, krzk+dt, conor+dt, andrew+netdev, devicetree,
linux-aspeed, linux-arm-kernel
In-Reply-To: <ddb781dd-e117-4f9a-a5a3-94c192d8c2ef@lunn.ch>
Hi Andrew,
Understood. I will not rely only on the vendor DTB value for this.
For the next revision, I will drop rgmii-rxid and use the conservative
rgmii setting unless I can provide board-level evidence that the
required RGMII delay is added by the PCB/PHY configuration.
I am arranging hardware validation for this board, and I will update
the Ethernet node only with evidence from the board/manual/logs.
Thanks,
Prasanth
On Mon, May 18, 2026 at 5:42 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > +&mac0 {
> > + status = "okay";
> > + phy-mode = "rgmii-rxid";
>
> It does not matter if this is what the vendor does, it is still wrong,
> unless you can show the PCB is adding the delay.
>
> Andrew
^ permalink raw reply
* RE: [PATCH v3 0/7] media: synopsys: enhancements and i.MX95 support
From: G.N. Zhou (OSS) @ 2026-05-19 2:20 UTC (permalink / raw)
To: Sakari Ailus, G.N. Zhou (OSS)
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Bryan O'Donoghue, Mehdi Djait,
Hans Verkuil, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, Krzysztof Kozlowski
In-Reply-To: <aguDpxP4SIcJWdcc@kekkonen.localdomain>
Hi Sakari,
Thanks for letting me know.
> -----Original Message-----
> From: Sakari Ailus <sakari.ailus@linux.intel.com>
> Sent: Tuesday, May 19, 2026 5:25 AM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> Frank Li <frank.li@nxp.com>; Bryan O'Donoghue
> <bryan.odonoghue@linaro.org>; Mehdi Djait <mehdi.djait@linux.intel.com>;
> Hans Verkuil <hverkuil+cisco@kernel.org>; linux-media@vger.kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; imx@lists.linux.dev; linux-
> arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org; Krzysztof
> Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Subject: Re: [PATCH v3 0/7] media: synopsys: enhancements and i.MX95
> support
>
> Hi Guoniu,
>
> Thanks for the set.
>
> On Wed, May 06, 2026 at 04:53:59PM +0800, Guoniu Zhou wrote:
> > This series enhances the Synopsys DesignWare MIPI CSI-2 receiver
> > driver with multiple stream support and adds i.MX95 platform support.
> >
> > The i.MX95 variant is similar to i.MX93 but uses IDI instead of IPI.
> > Since IDI is software transparent, only a different register map is needed.
> >
> > Tested on i.MX93 and i.MX95 platforms.
> >
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
>
> This doesn't seem to apply to the media committers' tree anymore. Could you
> rebase it, please? (Or are there dependencies still out there?)
The conflict is caused by commit 658810422076 ("media: dt-bindings:
rockchip,rk3568-mipi-csi2: add rk3588 compatible") which touches the
same area as my patch. There are no other dependencies.
I have already rebased and addressed this in v4 of the series, which
has been sent to the list. Could you please check if v4 applies cleanly?
Best Regards
G.N Zhou
>
> --
> Kind regards,
>
> Sakari Ailus
^ permalink raw reply
* [PATCH v5] arm64: dts: imx95: Correct PCIe outbound address space configuration
From: Richard Zhu @ 2026-05-19 2:22 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
Fix the PCIe outbound memory ranges for both pcie0 and pcie1
controllers on i.MX95.
The memory window size was incorrectly set to 256MB during initial
bring-up, but the hardware supports up to 4GB of outbound address space
per controller. Expand the memory region from 256MB (0x10000000) to
~3840MB (0xf0000000), starting at the base of each controller's
assigned CPU address range (0x9_00000000 for pcie0, 0xa_00000000 for
pcie1).
Additionally, ECAM cannot be mapped as I/O space. Use a memory region
to map the I/O space instead, and relocate the 1MB I/O region to
immediately follow the memory region at offset 0xf0000000 within each
window.
Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
---
Changes in v5:
- Expand the outbound address space from 256MB to 3840MB, starting at the
base of each controller's assigned CPU address range.
- Use a memory region to map the I/O space.
Changes in v4:
Update the flag from 0x82000000 to 0x83000000 to declare a 64-bit PCI space.
Changes in v3:
Update the commit message, and set the region size to the max hardware-supported memory space 4G.
Changes in v2:
Add the Fixes tag, and rebase to latest imx/dt64 branch.
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index adcc0e1d3696..c43f2bec99d0 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1939,8 +1939,8 @@ pcie0: pcie@4c300000 {
<0 0x4c360000 0 0x10000>,
<0 0x4c340000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
- <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
+ ranges = <0x82000000 0x0 0x00000000 0x9 0x00000000 0x0 0xf0000000>,
+ <0x81000000 0x0 0xf0000000 0x9 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -2014,8 +2014,8 @@ pcie1: pcie@4c380000 {
<0 0x4c3e0000 0 0x10000>,
<0 0x4c3c0000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0 0x00000000 0x8 0x8ff00000 0 0x00100000>,
- <0x82000000 0 0x10000000 0xa 0x10000000 0 0x10000000>;
+ ranges = <0x82000000 0x0 0x00000000 0xa 0x00000000 0x0 0xf0000000>,
+ <0x81000000 0x0 0xf0000000 0xa 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
base-commit: 5f9e9f83aee0fa8f2124c6f192505de2cdf7c5dc
--
2.37.1
^ permalink raw reply related
* [PATCH v8 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..a152c874b53b 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
power-domains:
maxItems: 1
@@ -51,6 +54,10 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the smi_larb node.
+
required:
- compatible
- reg
@@ -60,6 +67,27 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v8 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 30 +++++++++++++++----
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..f75871e72633 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,17 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
+
reg:
maxItems: 1
@@ -45,6 +49,10 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the smi_larb node.
+
required:
- compatible
- reg
@@ -54,6 +62,16 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgenc
+ then:
+ required:
+ - mediatek,larb
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v8 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..14f2991a4053 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1868,6 +1868,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1899,6 +1903,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1938,6 +1974,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v8 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on linux-next tag next-20260508.
This series depends on commit 7560349ee0d9 ("media: mediatek: jpeg:
support 34bits"), which introduced the `support_34bit` field in struct
mtk_jpeg_variant. That commit has already been merged via the media
tree and is present in linux-next as of next-20260508.
Changes compared with v7:
- Patches 1/3 (dt-bindings: decoder):
- In the allOf constraints, only keep maxItems: 1 in the then
branch and minItems: 2 in the else branch; remove duplicated
constraints already defined at the top level
Changes compared with v6:
- Patches 1/3 (dt-bindings: decoder):
update the existing `allOf` condition for mediatek,mt8189-jpgdec to
make the 'mediatek,larb' property strictly required for MT8189 SoC.
- Patches 2/3 (dt-bindings: encoder):
Add an `allOf` condition to enforce that the `mediatek,larb` property
is strictly required when the compatible string contains
mediatek,mt8189-jpgenc.
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 30 ++++++++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
3 files changed, 104 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* Re: [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: kernel test robot @ 2026-05-19 0:21 UTC (permalink / raw)
To: Guangshuo Li, Minghsiu Tsai, Houlong Wei, Andrew-CT Chen,
Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Hans Verkuil, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: llvm, oe-kbuild-all, linux-media, Guangshuo Li
In-Reply-To: <20260518125500.1000083-1-lgs201920130244@gmail.com>
Hi Guangshuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on linuxtv-media-pending/master]
[also build test ERROR on media-tree/master linus/master v7.1-rc4 next-20260518]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Guangshuo-Li/media-mediatek-mdp-avoid-double-free-on-video-register-failure/20260518-211648
base: https://git.linuxtv.org/media-ci/media-pending.git master
patch link: https://lore.kernel.org/r/20260518125500.1000083-1-lgs201920130244%40gmail.com
patch subject: [PATCH] media: mediatek: mdp: avoid double free on video register failure
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260519/202605190845.KlMSPp80-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605190845.KlMSPp80-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605190845.KlMSPp80-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c:1217:33: error: expected ';' after expression
1217 | video_device_release(mdp->vdev)
| ^
| ;
1 error generated.
vim +1217 drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
1172
1173 int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
1174 {
1175 struct device *dev = &mdp->pdev->dev;
1176 int ret;
1177
1178 mdp->variant = &mtk_mdp_default_variant;
1179 mdp->vdev = video_device_alloc();
1180 if (!mdp->vdev) {
1181 dev_err(dev, "failed to allocate video device\n");
1182 ret = -ENOMEM;
1183 goto err_video_alloc;
1184 }
1185 mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
1186 mdp->vdev->fops = &mtk_mdp_m2m_fops;
1187 mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
1188 mdp->vdev->release = video_device_release_empty;
1189 mdp->vdev->lock = &mdp->lock;
1190 mdp->vdev->vfl_dir = VFL_DIR_M2M;
1191 mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
1192 snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
1193 MTK_MDP_MODULE_NAME);
1194 video_set_drvdata(mdp->vdev, mdp);
1195
1196 mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
1197 if (IS_ERR(mdp->m2m_dev)) {
1198 dev_err(dev, "failed to initialize v4l2-m2m device\n");
1199 ret = PTR_ERR(mdp->m2m_dev);
1200 goto err_m2m_init;
1201 }
1202
1203 ret = video_register_device(mdp->vdev, VFL_TYPE_VIDEO, 2);
1204 if (ret) {
1205 dev_err(dev, "failed to register video device\n");
1206 goto err_vdev_register;
1207 }
1208 mdp->vdev->release = video_device_release;
1209
1210 v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
1211 mdp->vdev->num);
1212 return 0;
1213
1214 err_vdev_register:
1215 v4l2_m2m_release(mdp->m2m_dev);
1216 err_m2m_init:
> 1217 video_device_release(mdp->vdev)
1218 mdp->vdev = NULL;
1219 err_video_alloc:
1220
1221 return ret;
1222 }
1223
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Kohei Enju @ 2026-05-19 2:12 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Sami Mujawar, Gavin Shan, Steven Price,
Suzuki K Poulose, linux-arm-kernel, linux-kernel
In-Reply-To: <agtKlvxAvCHXvX-z@arm.com>
On 05/18 18:21, Catalin Marinas wrote:
> Hi Kohei,
>
> On Mon, May 18, 2026 at 10:38:53PM +0900, Kohei Enju wrote:
> > On 05/18 13:33, Catalin Marinas wrote:
> > > On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote:
> > > > diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > > index 0c9ea24a200c..2d450caee3e4 100644
> > > > --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > > +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > > @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> > > > * allocate outblob based on the returned value from the 'init'
> > > > * call and that cannot be done in an atomic context.
> > > > */
> > > > - cpu = smp_processor_id();
> > > > + cpu = raw_smp_processor_id();
> > >
> > > That's just hiding the warning which might be genuine, irrespective of
> > > what the comment says. Sashiko has some good points:
> > >
> > > https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com
> > >
> > > Basically what guarantees that the cpu won't go offline? Can we use
> > > migrate_disable() and ignore the smp_call_function_single() altogether?
> > > It looks like a hack anyway.
> [...]
> > You've raised a very valid point about raw_smp_processor_id()
> > potentially hiding a genuine issue. I agree this would be a concern in
> > most contexts.
> >
> > However, this implementation was intentionally designed not to block CPU
> > hotplug:
> > https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/
> >
> > As mentioned in the thread above, the potential failure from the target
> > CPU going offline (resulting in -ENXIO) is an expected and tolerated
> > condition in this path.
> > Using migrate_disable() would go against the non-blocking design goal.
> >
> > Given the context, the debug warning looks false positive for our
> > specific use case to me, and I believe raw_smp_processor_id() correctly
> > reflects the design intent by simply acquiring a CPU number without
> > debug checks.
>
> Thanks, I wasn't aware of the old discussion. If user-space can
> tolerate, than it's fine.
>
> Would you mind updating the comment above the changed line? It talks
> about not allocating memory in atomic context, so migrate_disable()
> would solve this. Just mention that it can't block CPU hotplug events
> either and user-space can handle spurious errors.
Sure, I'm happy to do. Thank you for the suggestion.
I'll work on v2.
Thanks,
Kohei
>
> With that:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
^ permalink raw reply
* [PATCH v4 6/6] media: synopsys: Add support for i.MX95
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
Add support for the i.MX95 MIPI CSI-2 receiver. The i.MX95 variant is
nearly identical to i.MX93, with the main difference being the use of
IDI (Image Data Interface) instead of IPI (Image Pixel Interface).
However, the IDI interface is transparent to software, requiring only
a different register map definition while sharing the same PHY control
functions with i.MX93.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Add Reviewed-by tag from Frank Li <Frank.Li@nxp.com>
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 8a34aec550ad..41e48365167e 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -154,6 +154,17 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
[DW_MIPI_CSI2RX_IPI_SOFTRSTN] = DW_REG(0xa0),
};
+static const u32 imx95_regs[DW_MIPI_CSI2RX_MAX] = {
+ [DW_MIPI_CSI2RX_N_LANES] = DW_REG(0x4),
+ [DW_MIPI_CSI2RX_RESETN] = DW_REG(0x8),
+ [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
+ [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
+ [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
+ [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
+ [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
+ [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
+};
+
static const struct v4l2_mbus_framefmt default_format = {
.width = 3840,
.height = 2160,
@@ -914,11 +925,22 @@ static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
.wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
};
+static const struct dw_mipi_csi2rx_drvdata imx95_drvdata = {
+ .regs = imx95_regs,
+ .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
+ .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
+ .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
+};
+
static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
{
.compatible = "fsl,imx93-mipi-csi2",
.data = &imx93_drvdata,
},
+ {
+ .compatible = "fsl,imx95-mipi-csi2",
+ .data = &imx95_drvdata,
+ },
{
.compatible = "rockchip,rk3568-mipi-csi2",
.data = &rk3568_drvdata,
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/6] media: dt-bindings: add NXP i.MX95 compatible string
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou, Krzysztof Kozlowski
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
main difference being the data output interface:
i.MX93 use IPI (Image Pixel Interface), which requires:
- Pixel clock input
- Software configuration through registers
i.MX95 uses IDI (Image Data Interface), which:
- Does not require pixel clock
- Is software transparent (no register configuration needed)
Due to these differences in register layout and initialization needs,
the two variants cannot share the same compatible string. The driver
needs to distinguish between them to handle the interface correctly.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v3:
- Add Reviewed-by tag from Krzysztof Kozlowski
Changes in v2:
- Add dedicated constraint block for i.MX95 to reflect different clock
requirements (only per clock needed vs i.MX93 which needs both per
and pixel clocks)
- Update commit message to include more details about interface differences
---
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
index fbcf28e9e1da..8bfad0fca3b7 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
@@ -19,6 +19,7 @@ properties:
oneOf:
- enum:
- fsl,imx93-mipi-csi2
+ - fsl,imx95-mipi-csi2
- rockchip,rk3568-mipi-csi2
- items:
- enum:
@@ -140,6 +141,21 @@ allOf:
clock-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,imx95-mipi-csi2
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+ interrupt-names: false
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+
examples:
- |
#include <dt-bindings/clock/rk3568-cru.h>
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
ensures proper PHY initialization by verifying that the clock lane and
all active data lanes have entered the stop state before proceeding with
further operations.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Removes redundant register availability check
- Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
readl_poll_timeout() with direct register address
- Fixes stopstate condition logic
- Check PHY stopstate after sensor enable instead of before to ensure
correct timing.
- Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
balance performance and responsiveness.
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36 ++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 92178a3dec5d..8a34aec550ad 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -11,6 +11,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy/phy.h>
@@ -35,6 +36,8 @@
#define DW_REG_EXIST BIT(31)
#define DW_REG(x) (DW_REG_EXIST | (x))
+#define DPHY_STOPSTATE_CLK_LANE BIT(16)
+
#define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
#define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0), (x))
@@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
DW_MIPI_CSI2RX_PHY_TST_CTRL0,
DW_MIPI_CSI2RX_PHY_TST_CTRL1,
DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
+ DW_MIPI_CSI2RX_PHY_STOPSTATE,
DW_MIPI_CSI2RX_IPI_DATATYPE,
DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
DW_MIPI_CSI2RX_IPI_MODE,
@@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
+ int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
};
struct dw_mipi_csi2rx_format {
@@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
[DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
[DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
[DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
+ [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
[DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
[DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
[DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80),
@@ -556,10 +562,19 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
if (ret)
goto err_csi_stop;
+ if (!csi2->enabled_streams &&
+ csi2->drvdata->wait_for_phy_stopstate) {
+ ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
+ if (ret)
+ goto err_disable_streams;
+ }
+
csi2->enabled_streams |= streams_mask;
return 0;
+err_disable_streams:
+ v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
err_csi_stop:
/* Stop CSI hardware if no streams are enabled */
if (!csi2->enabled_streams)
@@ -871,11 +886,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct dw_mipi_csi2rx_device *csi2)
dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val);
}
+static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
+{
+ struct device *dev = csi2->dev;
+ u32 stopstate_mask;
+ u32 val;
+ int ret;
+
+ stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
+
+ ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
+ (val & stopstate_mask) == stopstate_mask,
+ 10, 1000, true,
+ csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
+ if (ret)
+ dev_err(dev, "lanes are not in stop state: %#x, expected %#x\n",
+ val, stopstate_mask);
+
+ return ret;
+}
+
static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
.regs = imx93_regs,
.dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
.dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
.ipi_enable = imx93_csi2rx_dphy_ipi_enable,
+ .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
};
static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/6] media: synopsys: Add support for multiple streams
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
The current driver only supports single stream operation. Add support
for multiple concurrent streams by tracking enabled streams with a
bitmask and only initializing the hardware once for the first stream.
This enables use cases such as surround view systems where multiple
camera streams need to be processed simultaneously through the same
CSI-2 receiver interface.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v3:
- Call pm_runtime_put() after dw_mipi_csi2rx_stop()
- Balance PM runtime get/put for asymmetric stream enable/disable operations
Changes in v2:
- Simplify error handling by keeping goto labels instead of early returns
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 35 ++++++++++++++++--------
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index f45466ede2bb..92178a3dec5d 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -113,6 +113,7 @@ struct dw_mipi_csi2rx_device {
enum v4l2_mbus_type bus_type;
u32 lanes_num;
+ u64 enabled_streams;
const struct dw_mipi_csi2rx_drvdata *drvdata;
};
@@ -539,26 +540,33 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
DW_MIPI_CSI2RX_PAD_SRC,
&streams_mask);
- ret = pm_runtime_resume_and_get(dev);
- if (ret)
- goto err;
+ if (!csi2->enabled_streams) {
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ goto err;
- ret = dw_mipi_csi2rx_start(csi2);
- if (ret) {
- dev_err(dev, "failed to enable CSI hardware\n");
- goto err_pm_runtime_put;
+ ret = dw_mipi_csi2rx_start(csi2);
+ if (ret) {
+ dev_err(dev, "failed to enable CSI hardware\n");
+ goto err_pm_runtime_put;
+ }
}
ret = v4l2_subdev_enable_streams(remote_sd, remote_pad->index, mask);
if (ret)
goto err_csi_stop;
+ csi2->enabled_streams |= streams_mask;
+
return 0;
err_csi_stop:
- dw_mipi_csi2rx_stop(csi2);
+ /* Stop CSI hardware if no streams are enabled */
+ if (!csi2->enabled_streams)
+ dw_mipi_csi2rx_stop(csi2);
err_pm_runtime_put:
- pm_runtime_put(dev);
+ if (!csi2->enabled_streams)
+ pm_runtime_put(dev);
err:
return ret;
}
@@ -583,10 +591,15 @@ static int dw_mipi_csi2rx_disable_streams(struct v4l2_subdev *sd,
&streams_mask);
ret = v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
+ if (ret)
+ dev_err(dev, "failed to disable streams on remote subdev: %d\n", ret);
- dw_mipi_csi2rx_stop(csi2);
+ csi2->enabled_streams &= ~streams_mask;
- pm_runtime_put(dev);
+ if (!csi2->enabled_streams) {
+ dw_mipi_csi2rx_stop(csi2);
+ pm_runtime_put(dev);
+ }
return ret;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/6] media: synopsys: Add support for RAW16 Bayer formats
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v2:
- Update commit message
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 0b80e84983f9..f45466ede2bb 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -252,6 +252,26 @@ static const struct dw_mipi_csi2rx_format formats[] = {
.depth = 12,
.csi_dt = MIPI_CSI2_DT_RAW12,
},
+ {
+ .code = MEDIA_BUS_FMT_SBGGR16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGBRG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SGRBG16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_SRGGB16_1X16,
+ .depth = 16,
+ .csi_dt = MIPI_CSI2_DT_RAW16,
+ },
};
static inline struct dw_mipi_csi2rx_device *to_csi2(struct v4l2_subdev *sd)
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/6] media: synopsys: Fix IPI using hardcoded datatype
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-0-84ea4bb78a88@oss.nxp.com>
The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype
using csi2->formats->csi_dt, which is initialized during probe but never
updated in set_fmt(). This causes the IPI to always use the probe-time
default datatype, ignoring the actual media bus format negotiated at
runtime. When userspace requests a different format, the IPI hardware is
configured with the wrong datatype, resulting in incorrect image output.
Fix by updating csi2->formats in the set_fmt callback to reflect the
currently negotiated format, ensuring the IPI configuration matches the
runtime datatype.
Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v3:
- Fix formats array out-of-bounds read during enumeration
- Add NULL check for csi2->formats to handle unexpected format lookup failures
Changes in v2:
- New added in v2
---
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
index 02eb4a6cafad..0b80e84983f9 100644
--- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
+++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
@@ -311,7 +311,7 @@ dw_mipi_csi2rx_find_format(struct dw_mipi_csi2rx_device *csi2, u32 mbus_code)
WARN_ON(csi2->formats_num == 0);
for (unsigned int i = 0; i < csi2->formats_num; i++) {
- const struct dw_mipi_csi2rx_format *format = &csi2->formats[i];
+ const struct dw_mipi_csi2rx_format *format = &formats[i];
if (format->code == mbus_code)
return format;
@@ -433,7 +433,7 @@ dw_mipi_csi2rx_enum_mbus_code(struct v4l2_subdev *sd,
if (code->index >= csi2->formats_num)
return -EINVAL;
- code->code = csi2->formats[code->index].code;
+ code->code = formats[code->index].code;
return 0;
default:
return -EINVAL;
@@ -470,6 +470,17 @@ static int dw_mipi_csi2rx_set_fmt(struct v4l2_subdev *sd,
*src = *sink;
+ /* Store the CSIS format descriptor for active formats. */
+ if (format->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ csi2->formats = fmt ? :
+ dw_mipi_csi2rx_find_format(csi2, default_format.code);
+
+ if (!csi2->formats) {
+ dev_err(csi2->dev, "Failed to find valid format\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/6] media: synopsys: enhancements and i.MX95 support
From: Guoniu Zhou @ 2026-05-19 2:07 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou, Krzysztof Kozlowski
This series enhances the Synopsys DesignWare MIPI CSI-2 receiver driver
with multiple stream support and adds i.MX95 platform support.
The i.MX95 variant is similar to i.MX93 but uses IDI instead of IPI. Since
IDI is software transparent, only a different register map is needed.
Tested on i.MX93 and i.MX95 platforms.
Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
---
Changes in v4:
- Rebase to latest media/next(bc1ba628e37c)
- Link to v3: https://lore.kernel.org/r/20260506-csi2_imx95-v3-0-953b6e1a80dd@oss.nxp.com
Changes in v3:
- Added Reviewed-by tag from Frank Li for patches 1-6
- Fix formats array out-of-bounds read during enumeration
- Add NULL check for csi2->formats to handle unexpected format lookup failures
- Call pm_runtime_put() after dw_mipi_csi2rx_stop()
- Balance PM runtime get/put for asymmetric stream enable/disable operations
- Add Reviewed-by tag from Krzysztof Kozlowski
- See each patch's changelog for details.
- Link to v2: https://lore.kernel.org/r/20260423-csi2_imx95-v2-0-934c02f3422a@oss.nxp.com
Changes in v2:
- Add two new patches
- Simplify error handling by keeping goto labels instead of early returns
- Removes redundant register availability check
- Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
readl_poll_timeout() with direct register address
- Fixes stopstate condition logic
- Check PHY stopstate after sensor enable instead of before to ensure
correct timing.
- Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
balance performance and responsiveness.
- Add dedicated constraint block for i.MX95 to reflect different clock
requirements (only per clock needed vs i.MX93 which needs both per and
pixel clocks)
- Update commit message to include more details about interface differences
- Add Reviewed-by tag from Frank Li <Frank.Li@nxp.com>
- Update commit message
- See each patch's changelog for details.
- Link to v1: https://lore.kernel.org/r/20260415-csi2_imx95-v1-0-7d63f3508719@oss.nxp.com
---
Guoniu Zhou (6):
media: synopsys: Fix IPI using hardcoded datatype
media: synopsys: Add support for RAW16 Bayer formats
media: synopsys: Add support for multiple streams
media: synopsys: Add PHY stopstate wait for i.MX93
media: dt-bindings: add NXP i.MX95 compatible string
media: synopsys: Add support for i.MX95
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 16 +++
drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 128 ++++++++++++++++++---
2 files changed, 131 insertions(+), 13 deletions(-)
---
base-commit: bc1ba628e37c93cf2abeb2c79716f49087f8a024
change-id: 20260414-csi2_imx95-65ad0e7f630a
Best regards,
--
Guoniu Zhou <guoniu.zhou@oss.nxp.com>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: anacapa: correct SGPIO names for monitoring
From: Andrew Jeffery @ 2026-05-19 1:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Rex Fu
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260518-anacapa-sgpio-edsff-thermtrip-v2-1-e43b1847b2dc@amd.com>
On Mon, 18 May 2026 18:00:40 +0800, Rex Fu wrote:
> Update several Anacapa SGPIO line names to match the existing platform
> hardware design and the signal names consumed by userspace monitoring.
>
> The previous names did not match the actual Anacapa SGPIO usage. Some
> lines were named as CPU or CPU power-good signals, but they are wired and
> used on Anacapa for EDSFF presence, EDSFF power-good, boot EDSFF
> presence, and thermal-trip assertion monitoring.
>
> [...]
Thanks, I've applied this to the BMC tree.
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Jakub Kicinski @ 2026-05-19 1:45 UTC (permalink / raw)
To: MD Danish Anwar, Felix Maurer, Luka Gejak
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan, Roger Quadros, Andrew Lunn,
Meghana Malladi, Jacob Keller, David Carlier, Vadim Fedorenko,
Kevin Hao, netdev, linux-doc, linux-kernel, linux-arm-kernel,
Vladimir Oltean
In-Reply-To: <20260514075605.850674-3-danishanwar@ti.com>
On Thu, 14 May 2026 13:26:05 +0530 MD Danish Anwar wrote:
> Add new firmware PA statistics counters for HSR and LRE to the ethtool
> statistics exposed by the ICSSG driver.
>
> New statistics added:
> - FW_HSR_FWD_CHECK_FAIL_DROP: Packets dropped on the HSR forwarding path
> - FW_HSR_HE_CHECK_FAIL_DROP: Packets dropped on the HSR host egress path
> - FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES: Frames with duplicate discard
> skipped
> - FW_LRE_CNT_UNIQUE/DUPLICATE/MULTIPLE_RX: LRE duplicate detection
> counters
> - FW_LRE_CNT_RX/TX: LRE per-port frame counters
> - FW_LRE_CNT_OWN_RX: Own HSR tagged frames received
> - FW_LRE_CNT_ERRWRONGLAN: Frames with wrong LAN identifier (PRP)
>
> Document the new HSR/LRE statistics in icssg_prueth.rst.
To an untrained eye these stats look like stuff that could
be standardized across drivers.
Luka, Felix, others on CC, do you think we should expose these
from HSR over netlink as "standard" offload stats different drivers
can plug into or not worth it?
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
From: Shawn Guo @ 2026-05-19 1:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
In-Reply-To: <20260505071453.34000-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, May 05, 2026 at 09:14:54AM +0200, Krzysztof Kozlowski wrote:
> Many of SMMU on Qualcomm SoCs come in two flavors using same front
> compatible but a bit different fallback:
>
> 1. For application processor, usually without any controllable
> clocks,
>
> 2. For the Adreno GPU, with some controllable clock(s) and using
> additionally qcom,adreno-smmu fallback compatible.
>
> Add missing constraints for Glymur SMMU on Adreno GPU and several other
> Qualcomm SMMUs for application processors, to restrict the clocks
> property to a specific value.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt2701: fix snprintf bounds
From: Rosen Penev @ 2026-05-19 1:04 UTC (permalink / raw)
To: linux-sound
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
For whatever reason, GCC is unable to figure out that i2s_num is a
single digit number, with MT2701_BASE_CLK_NUM being the maximum value it
represents. Add a min() call to help it out and fix W=1 errors regarding
snprintf bounds.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index 5a2bcf027b4f..43157f218409 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -25,6 +25,7 @@ static const char *const base_clks[] = {
int mt2701_init_clock(struct mtk_base_afe *afe)
{
struct mt2701_afe_private *afe_priv = afe->platform_priv;
+ int i2s_num;
int i;
for (i = 0; i < MT2701_BASE_CLK_NUM; i++) {
@@ -35,8 +36,9 @@ int mt2701_init_clock(struct mtk_base_afe *afe)
}
}
+ i2s_num = min(MT2701_BASE_CLK_NUM, afe_priv->soc->i2s_num);
/* Get I2S related clocks */
- for (i = 0; i < afe_priv->soc->i2s_num; i++) {
+ for (i = 0; i < i2s_num; i++) {
struct mt2701_i2s_path *i2s_path = &afe_priv->i2s_path[i];
struct clk *i2s_ck;
char name[13];
--
2.54.0
^ permalink raw reply related
* [PATCH] ASoC: mediatek: mt2701: allocate i2s_path with priv
From: Rosen Penev @ 2026-05-19 1:04 UTC (permalink / raw)
To: linux-sound
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use a flexible array member to combine allocations.
Clean up surrounding code and allocate based on afe_priv and not
platform_priv which is a void pointer. struct_size needs a properly
typed pointer to work.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 2 +-
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 21 ++++++++-----------
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 8b6f3a200048..c9477bc24ee9 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -89,7 +89,6 @@ struct mt2701_soc_variants {
};
struct mt2701_afe_private {
- struct mt2701_i2s_path *i2s_path;
struct clk *base_ck[MT2701_BASE_CLK_NUM];
struct clk *mrgif_ck;
struct clk *hadds2pll_ck;
@@ -99,6 +98,7 @@ struct mt2701_afe_private {
bool mrg_enable[MTK_STREAM_NUM];
const struct mt2701_soc_variants *soc;
+ struct mt2701_i2s_path i2s_path[];
};
#endif
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index bb459faa6e05..d56b498e8c0c 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -1593,6 +1593,7 @@ static int mt2701_afe_runtime_resume(struct device *dev)
static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
{
+ const struct mt2701_soc_variants *soc;
struct mtk_base_afe *afe;
struct mt2701_afe_private *afe_priv;
struct device *dev;
@@ -1602,23 +1603,19 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
if (!afe)
return -ENOMEM;
- afe->platform_priv = devm_kzalloc(&pdev->dev, sizeof(*afe_priv),
- GFP_KERNEL);
- if (!afe->platform_priv)
+ soc = of_device_get_match_data(&pdev->dev);
+ afe_priv = devm_kzalloc(&pdev->dev,
+ struct_size(afe_priv, i2s_path, soc->i2s_num),
+ GFP_KERNEL);
+ if (!afe_priv)
return -ENOMEM;
- afe_priv = afe->platform_priv;
- afe_priv->soc = of_device_get_match_data(&pdev->dev);
+ afe_priv->soc = soc;
+
+ afe->platform_priv = afe_priv;
afe->dev = &pdev->dev;
dev = afe->dev;
- afe_priv->i2s_path = devm_kcalloc(dev,
- afe_priv->soc->i2s_num,
- sizeof(struct mt2701_i2s_path),
- GFP_KERNEL);
- if (!afe_priv->i2s_path)
- return -ENOMEM;
-
irq_id = platform_get_irq_byname(pdev, "asys");
if (irq_id < 0)
return irq_id;
--
2.54.0
^ permalink raw reply related
* [PATCH] clk: sunxi-ng: Use of_device_get_match_data()
From: Rosen Penev @ 2026-05-19 0:39 UTC (permalink / raw)
To: linux-clk
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Use of_device_get_match_data() to fetch the RTC CCU match data directly
instead of open-coding an of_match_device() lookup.
This also lets the driver drop the of_device.h include.
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index f6bfeba009e8..a3cf0dde05be 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -9,7 +9,6 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_device.h>
#include <linux/clk/sunxi-ng.h>
@@ -353,14 +352,12 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
{
const struct sun6i_rtc_match_data *data;
struct clk *ext_osc32k_clk = NULL;
- const struct of_device_id *match;
/* This driver is only used for newer variants of the hardware. */
- match = of_match_device(sun6i_rtc_ccu_match, dev);
- if (!match)
+ data = of_device_get_match_data(dev);
+ if (!data)
return 0;
- data = match->data;
have_iosc_calibration = data->have_iosc_calibration;
if (data->have_ext_osc32k) {
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox