* [PATCH v2 73/78] drm/xlnx: zynqmp_dp: Switch to atomic_create_state
From: Maxime Ripard @ 2026-06-08 14:36 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter
Cc: Dmitry Baryshkov, dri-devel, Maxime Ripard, Laurent Pinchart,
Laurent Pinchart, Tomi Valkeinen, Michal Simek, linux-arm-kernel
In-Reply-To: <20260608-drm-no-more-bridge-reset-v2-0-0a91018bf886@kernel.org>
The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.
Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Michal Simek <michal.simek@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 7fb11b0a44f0..b209582bc130 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -2278,11 +2278,11 @@ static const struct drm_bridge_funcs zynqmp_dp_bridge_funcs = {
.mode_valid = zynqmp_dp_bridge_mode_valid,
.atomic_enable = zynqmp_dp_bridge_atomic_enable,
.atomic_disable = zynqmp_dp_bridge_atomic_disable,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
- .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_create_state = drm_atomic_helper_bridge_create_state,
.atomic_check = zynqmp_dp_bridge_atomic_check,
.detect = zynqmp_dp_bridge_detect,
.edid_read = zynqmp_dp_bridge_edid_read,
.atomic_get_input_bus_fmts = zynqmp_dp_bridge_get_input_bus_fmts,
.debugfs_init = zynqmp_dp_bridge_debugfs_init,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Will Deacon @ 2026-06-08 14:40 UTC (permalink / raw)
To: Sebastian Ene
Cc: Marc Zyngier, catalin.marinas, oupton, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui, Sudeep Holla
In-Reply-To: <aibQHiYimPP1ylk3@google.com>
Hey Seb,
On Mon, Jun 08, 2026 at 02:22:22PM +0000, Sebastian Ene wrote:
> On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote:
> > I'd probably structure it as a separate patch per call, tbh. That way,
> > the commit message can talk about the specific fields that are reserved
> > for a given call. See below.
> >
> > > Refactor the handling logic in pKVM FF-A proxy to support checking for
> > > SBZ/MBZ values. While at it, drop the do_ffa_mem_xfer macro and replace
> > > it with two functions that make it clear that we re-write the
> > > function-id with a 64-bit variant, to keep the same behavior as before.
> > > Keep each handler in an array of structures together with a mask that
> > > corresponds to the SBZ registers the spec expects.
> >
> > Although I agree that we should be enforcing SBZ/MBZ paramaters (because
> > we have no idea what they might do in future versions of the spec), I
> > also think that doing this at the register level is too coarse.
> >
> > For example, the VM ID parameter to FFA_NOTIFICATION_BITMAP_CREATE has bits
> > 31:16 as MBZ. So I think we probably need to do the checking on a
> > per-function basis, like Per is doing in his series:
> >
> > https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com
> >
>
> For the newly added calls like FFA_NOTIFICATION_* we can do that in a
> separate functions, but what about the other existing calls that have
> MBZ registers ? that was the reason for the inline proposal in :
> https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
> (to avoid duplicate checks).
For unused parameter registers that are SBZ, I think you could just add
a helper, e.g.:
ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int reg);
which takes the index of the first unused register and then checks that
all the registers from there to the last unused parameter register are
zero. You can then just call that directly before you start parsing the
SBZ/MBZ fields on the used parameter registers and there's no need for
the table-based indirection in [1].
Will
[1] https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-08 14:41 UTC (permalink / raw)
To: Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <CAMRc=MdA24z-tB_D8CTw68Di8e4OVQJ1QH4+rDskFzq=xjJ5BQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4853 bytes --]
Hi,
On Mon Jun 8, 2026 at 4:10 PM CEST, Bartosz Golaszewski wrote:
> On Wed, 3 Jun 2026 02:34:40 +0200, Andy Shevchenko
> <andriy.shevchenko@intel.com> said:
>> On Mon, May 25, 2026 at 12:04:09PM +0000, Yu-Chun Lin [林祐君] wrote:
>>> > On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
>>> > > Expose an accessor function to retrieve the gpio_chip pointer from a
>>> > > gpio_regmap instance.
>>> > >
>>> > > This is needed by drivers that use gpio_regmap but also manage their
>>> > > own irq_chip, where gpiochip_enable_irq()/gpiochip_disable_irq() must
>>> > > be called with the gpio_chip pointer.
>>> > >
>>> > > Add gpio_regmap_get_gpiochip() to allow drivers with complex custom
>>> > > IRQ implementations.
>>> >
>>> > Hmm... Can't we rather add
>>> > gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
>>> > that take regmap or GPIO regmap (whatever suits better for the purpose) and
>>> > do the magic inside GPIO regmap library code?
>>
>>> Thanks for the review! I apologize for the misleading commit message.
>>> The real reason I need the struct gpio_chip pointer is to properly set up a custom
>>> IRQ domain. Our SoC GPIO controller is quite complex. It routes different trigger
>>> types to multiple parent IRQs, which doesn't fit the generic regmap_irq framework.
>>> Therefore, we have to create our own irq_domain and pass it to
>>> gpio_regmap_config.irq_domain.
>>>
>>> The core problem occurs inside our custom irq_domain_ops.map() callback:
>>>
>>> static int rtd1625_gpio_irq_map(struct irq_domain *domain, unsigned int irq,
>>> irq_hw_number_t hwirq)
>>> {
>>> struct rtd1625_gpio *data = domain->host_data;
>>> struct gpio_chip *gc = data->gpio_chip;
>>>
>>> /*
>>> * The second argument MUST be struct gpio_chip *.
>>> * If we pass our custom data structure here, the kernel will panic later
>>> * in gpiochip_irq_reqres() when it calls irq_data_get_irq_chip_data()
>>> * and strictly expects it to be a gpio_chip.
>>> */
>>> irq_set_chip_data(irq, gc);
>>>
>>> irq_set_lockdep_class(irq, &rtd1625_gpio_irq_lock_class,
>>> &rtd1625_gpio_irq_request_class);
>>>
>>> irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
>>> irq_set_noprobe(irq);
>>>
>>> return 0;
>>> }
>>>
>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
>>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
>>> map() function.
Why is gpiochip_irq_reqres() called in the first place? Isn't that
only called if the irq handling is set up via gc->irq.chip and not
via gpiochip_irqchip_add_domain() like in gpio-regmap?
>> This is all good and needs to be depicted in the cover-letter and/or commit message.
>>
>>> Before I send a v4, I see 3 possible paths:
>>>
>>> Option 1: Keep the accessor (Current v3 approach)
>>> We keep gpio_regmap_get_gpiochip() but I will completely rewrite the commit message
>>> to explain the custom irq_domain_ops.map and lockdep requirements.
>>>
>>> Option 2: Let gpiolib create the irq_domain via gpio_regmap_config
>>> Instead of creating the irq_domain in our driver, we add all necessary IRQ fields
>>> (irq_chip, irq_handler, irq_parents, etc.) into struct gpio_regmap_config. Then
>>> gpio-regmap.c populates the gpio_irq_chip structure before calling
>>> gpiochip_add_data(). This prevents an early return and allows the core gpiolib
>>> (gpiochip_add_irqchip()) to automatically create the irq_domain for us.
>>> Drawback: This adds a lot of fields to gpio_regmap_config and might violate the
>>> original design philosophy of gpio-regmap.c (commit ebe363197e52), which explicitly
>>> states that it does not implement its own IRQ chip and delegates it to the parent
>>> driver.
>>>
>>> Option 3: Drop gpio-regmap entirely (Revert to v2 approach)
>>> Currently, all drivers using gpio-regmap (mostly simple CPLDs and external I/O cards)
>>> use regmap-irq to get their domain. Since our SoC has a complex IRQ routing scheme
>>> with multiple parents, maybe gpio-regmap is simply not the right tool for this
>>> hardware, and we should just implement a standard GPIO driver directly using gpiolib.
>>>
>>> Which approach would you prefer upstream?
>>
>> This question to Bart, Linus, and poissibly gpio-regmap stakeholders. I'm not sure
>> that my personal opinion will be the best fit here.
>>
>
> My preference would be for #2 but I understand that this could risk getting
> stuck in endless bikeshedding so I'm fine with going #3 with potential for
> future refactoring if we have more similar users.
Yeah, I'd like to keep that stuff out of gpio-regmap. But I'm on the
same boat regarding the refactoring if we have more data and
potential users.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* [PATCH v5 00/14] arm64: dts: imx8mp-var-som-symphony: align DTS with hardware revision
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
This series updates the i.MX8MP VAR-SOM and Symphony device trees to
better align them with the current hardware configuration.
It adds the missing board peripherals and completes the related pinctrl,
GPIO and bus configuration.
v4->v5:
- Add the SION (Software Input On) bit for the I2C recovery pins
- Remove regulator-always-on and duplicated vddio node
v3->v4:
- Fixed USB irq edge type
- Add HDMI HPD support
- Add pcie reset-gpios instead of deprecated one
- Fixed eth regulator
v2->v3:
- Add FlexCAN2 controller support
- Add FEC controller and MaxLinear MXL86110 PHY support
- Describe PCIe PERST# reset GPIO
v1->v2:
- Add missing HDMI pinctrl configuration
- Enable LCDIF3 for the HDMI display pipeline
- Adjust PCIe controller configuration
- Update PTN5150 interrupt trigger type
Stefano Radaelli (14):
arm64: dts: imx8mp-var-som-symphony: add input keys
arm64: dts: imx8mp-var-som-symphony: enable USB support
arm64: dts: imx8mp-var-som-symphony: add TPM support
arm64: dts: imx8mp-var-som-symphony: add external RTC
arm64: dts: imx8mp-var-som-symphony: enable header UARTs
arm64: dts: imx8mp-var-som-symphony: enable PCIe
arm64: dts: imx8mp-var-som-symphony: add HDMI support
arm64: dts: imx8mp-var-som-symphony: add capacitive touchscreen
arm64: dts: imx8mp-var-som-symphony: enable ECSPI2
arm64: dts: imx8mp-var-som-symphony: keep RGB_SEL low
arm64: dts: imx8mp-var-som-symphony: enable PWM1
arm64: dts: imx8mp-var-som-symphony: enable CAN
arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
arm64: dts: freescale: imx8mp-var-som: add I2C1 bus recovery GPIOs
.../dts/freescale/imx8mp-var-som-symphony.dts | 389 +++++++++++++++++-
.../boot/dts/freescale/imx8mp-var-som.dtsi | 12 +-
2 files changed, 399 insertions(+), 2 deletions(-)
base-commit: b3c1d1631f097619f8091f0293e027c4301285d6
--
2.47.3
^ permalink raw reply
* [PATCH v5 01/14] arm64: dts: imx8mp-var-som-symphony: add input keys
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
Add the Back, Home and Menu keys connected through the GPIO expander on
the Symphony carrier board.
Also enable the SNVS power key.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../dts/freescale/imx8mp-var-som-symphony.dts | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 291f65e36865..25f707012f62 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -13,6 +13,31 @@ chosen {
stdout-path = &uart2;
};
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca9534 1 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca9534 2 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-menu {
+ label = "Menu";
+ linux,code = <KEY_MENU>;
+ gpios = <&pca9534 3 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
gpio-leds {
compatible = "gpio-leds";
@@ -72,6 +97,10 @@ usb3-sata-sel-hog {
};
};
+&snvs_pwrkey {
+ status = "okay";
+};
+
/* Console */
&uart2 {
pinctrl-names = "default";
--
2.47.3
^ permalink raw reply related
* [PATCH v5 02/14] arm64: dts: imx8mp-var-som-symphony: enable USB support
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable the USB controllers on the Symphony carrier board.
Add the PTN5150 Type-C controller for USB role switching, enable the USB3
PHYs and controllers, configure the I2C bus used by the Type-C
controller, and set the first USB port in OTG mode and the second port
in host mode.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
- Add the SION (Software Input On) bit for the I2C recovery pins
v3->v4:
- Fixed USB irq edge type
v2->v3:
-
v1->v2:
- Update PTN5150 interrupt trigger type
.../dts/freescale/imx8mp-var-som-symphony.dts | 80 ++++++++++++++++++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 25f707012f62..cb27853ba281 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -72,8 +72,11 @@ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
&i2c3 {
clock-frequency = <400000>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
/* GPIO expander */
@@ -95,6 +98,22 @@ usb3-sata-sel-hog {
line-name = "usb3_sata_sel";
};
};
+
+ /* USB Type-C Controller */
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ptn5150>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ port {
+ typec_dr_sw: endpoint {
+ remote-endpoint = <&usb3_drd_sw>;
+ };
+ };
+ };
};
&snvs_pwrkey {
@@ -108,6 +127,52 @@ &uart2 {
status = "okay";
};
+&usb3_0 {
+ status = "okay";
+};
+
+&usb3_1 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ adp-disable;
+ dr_mode = "otg";
+ hnp-disable;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ srp-disable;
+ usb-role-switch;
+ status = "okay";
+
+ port {
+ usb3_drd_sw: endpoint {
+ remote-endpoint = <&typec_dr_sw>;
+ };
+ };
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usb3_phy0 {
+ fsl,phy-comp-dis-tune-percent = <115>;
+ fsl,phy-pcs-tx-deemph-3p5db-attenuation-db = <33>;
+ fsl,phy-pcs-tx-swing-full-percent = <100>;
+ fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
+ fsl,phy-tx-vboost-level-microvolt = <1156>;
+ fsl,phy-tx-vref-tune-percent = <122>;
+ status = "okay";
+};
+
+&usb3_phy1 {
+ fsl,phy-tx-preemp-amp-tune-microamp = <1800>;
+ fsl,phy-tx-vref-tune-percent = <116>;
+ status = "okay";
+};
+
/* SD-card */
&usdhc2 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
@@ -129,12 +194,25 @@ MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001c2
>;
};
+ pinctrl_i2c3_gpio: i2c3gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x400001c2
+ MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x400001c2
+ >;
+ };
+
pinctrl_pca9534: pca9534grp {
fsl,pins = <
MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15 0xc0
>;
};
+ pinctrl_ptn5150: ptn5150grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x40
--
2.47.3
^ permalink raw reply related
* [PATCH v5 03/14] arm64: dts: imx8mp-var-som-symphony: add TPM support
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the ST33KTPM2XI2C TPM device on the Symphony carrier board.
Enable the I2C4 bus, add the PCAL6408 GPIO expander used by the TPM and
describe the TPM reset line.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
- Add the SION (Software Input On) bit for the I2C recovery pins
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../dts/freescale/imx8mp-var-som-symphony.dts | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index cb27853ba281..7cf58198ef14 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -116,6 +116,31 @@ typec_dr_sw: endpoint {
};
};
+&i2c4 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio", "sleep";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ pinctrl-2 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pcal6408: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ label = "tpm";
+ reset-gpios = <&pcal6408 4 GPIO_ACTIVE_LOW>;
+ };
+};
+
&snvs_pwrkey {
status = "okay";
};
@@ -201,6 +226,20 @@ MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x400001c2
>;
};
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__I2C4_SCL 0x400001c2
+ MX8MP_IOMUXC_I2C4_SDA__I2C4_SDA 0x400001c2
+ >;
+ };
+
+ pinctrl_i2c4_gpio: i2c4gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_I2C4_SCL__GPIO5_IO20 0x400001c2
+ MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x400001c2
+ >;
+ };
+
pinctrl_pca9534: pca9534grp {
fsl,pins = <
MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15 0xc0
--
2.47.3
^ permalink raw reply related
* [PATCH v5 04/14] arm64: dts: imx8mp-var-som-symphony: add external RTC
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the DS1337 RTC on the Symphony carrier board and disable the internal
SNVS RTC.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 7cf58198ef14..cb3348aafa07 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -139,12 +139,21 @@ st33ktpm2xi2c: tpm@2e {
label = "tpm";
reset-gpios = <&pcal6408 4 GPIO_ACTIVE_LOW>;
};
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ };
};
&snvs_pwrkey {
status = "okay";
};
+&snvs_rtc {
+ status = "disabled";
+};
+
/* Console */
&uart2 {
pinctrl-names = "default";
--
2.47.3
^ permalink raw reply related
* [PATCH v5 08/14] arm64: dts: imx8mp-var-som-symphony: add capacitive touchscreen
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the FT5206 capacitive touchscreen controller on the Symphony carrier
board.
Describe the interrupt pin and touchscreen geometry.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../dts/freescale/imx8mp-var-som-symphony.dts | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 0beaee5f81c9..f8a4b5b2e9fb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -195,6 +195,21 @@ st33ktpm2xi2c: tpm@2e {
reset-gpios = <&pcal6408 4 GPIO_ACTIVE_LOW>;
};
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
rtc@68 {
compatible = "dallas,ds1337";
reg = <0x68>;
@@ -306,6 +321,12 @@ &usdhc2 {
};
&iomuxc {
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO03 0x16
+ >;
+ };
+
pinctrl_hdmi: hdmigrp {
fsl,pins = <
MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
--
2.47.3
^ permalink raw reply related
* [PATCH v5 07/14] arm64: dts: imx8mp-var-som-symphony: add HDMI support
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable the HDMI display pipeline and HDMI audio support on the Symphony
carrier board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
- Add HDMI HPD support
v2->v3:
-
v1->v2:
- Add missing HDMI pinctrl configuration
- Enable LCDIF3 for the HDMI display pipeline
.../dts/freescale/imx8mp-var-som-symphony.dts | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 698f02fc39a5..0beaee5f81c9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -48,6 +48,18 @@ led-0 {
};
};
+ native-hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "HDMI OUT";
+ type = "a";
+
+ port {
+ hdmi_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
pcie0_refclk: pcie0-refclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -74,6 +86,43 @@ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
states = <3300000 0x0 1800000 0x1>;
vin-supply = <&ldo5>;
};
+
+ sound-hdmi {
+ compatible = "fsl,imx-audio-hdmi";
+ model = "audio-hdmi";
+ audio-cpu = <&aud2htx>;
+ hdmi-out;
+ };
+};
+
+&aud2htx {
+ status = "okay";
+};
+
+&hdmi_pai {
+ status = "okay";
+};
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
};
&i2c3 {
@@ -152,6 +201,10 @@ rtc@68 {
};
};
+&lcdif3 {
+ status = "okay";
+};
+
&pcie {
reset-gpios = <&pcal6408 1 GPIO_ACTIVE_LOW>;
status = "okay";
@@ -253,6 +306,15 @@ &usdhc2 {
};
&iomuxc {
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
+ MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x1c2
+ MX8MP_IOMUXC_HDMI_CEC__HDMIMIX_HDMI_CEC 0x10
+ MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x10
+ >;
+ };
+
pinctrl_i2c3: i2c3grp {
fsl,pins = <
MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001c2
--
2.47.3
^ permalink raw reply related
* [PATCH v5 09/14] arm64: dts: imx8mp-var-som-symphony: enable ECSPI2
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable the ECSPI2 bus on the Symphony carrier board and add the pinctrl
configuration for the SPI signals and chip select GPIO.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../dts/freescale/imx8mp-var-som-symphony.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index f8a4b5b2e9fb..387bbe3454c3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -99,6 +99,13 @@ &aud2htx {
status = "okay";
};
+&ecspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&hdmi_pai {
status = "okay";
};
@@ -327,6 +334,15 @@ MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO03 0x16
>;
};
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_ECSPI2_SCLK__ECSPI2_SCLK 0x12
+ MX8MP_IOMUXC_ECSPI2_MOSI__ECSPI2_MOSI 0x12
+ MX8MP_IOMUXC_ECSPI2_MISO__ECSPI2_MISO 0x12
+ MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x12
+ >;
+ };
+
pinctrl_hdmi: hdmigrp {
fsl,pins = <
MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
--
2.47.3
^ permalink raw reply related
* [PATCH v5 13/14] arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add support for the second Ethernet interface available on the Symphony
carrier board.
Enable the FEC controller, add the MaxLinear MXL86110 Gigabit Ethernet
PHY on the MDIO bus, describe its reset and power configuration, and add
the required RGMII pinctrl settings.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
- Remove regulator-always-on and duplicated vddio node
v3->v4:
- Fixed eth regulator
v2->v3:
- Add FEC controller and MaxLinear MXL86110 PHY support
.../dts/freescale/imx8mp-var-som-symphony.dts | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 93dee9ec0b9b..e928a3d44b1d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -66,6 +66,16 @@ pcie0_refclk: pcie0-refclk {
clock-frequency = <100000000>;
};
+ reg_fec_phy: regulator-fec-phy {
+ compatible = "regulator-fixed";
+ regulator-name = "fec-phy";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <20000>;
+ gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
compatible = "regulator-fixed";
regulator-name = "VSD_3V3";
@@ -106,6 +116,33 @@ &ecspi2 {
status = "okay";
};
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@5 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <5>;
+ reset-gpios = <&pca9534 5 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <20000>;
+ vddio-supply = <®_phy_vddio>;
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ phy-supply = <®_fec_phy>;
+ status = "okay";
+};
+
&flexcan2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan2>;
@@ -363,6 +400,23 @@ MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x12
>;
};
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90
+ MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90
+ MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90
+ MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x90
+ MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90
+ MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90
+ MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x00
+ MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x00
+ MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x00
+ MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x00
+ MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x00
+ MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x00
+ >;
+ };
+
pinctrl_flexcan2: flexcan2grp {
fsl,pins = <
MX8MP_IOMUXC_UART3_RXD__CAN2_TX 0x154
--
2.47.3
^ permalink raw reply related
* [PATCH v5 10/14] arm64: dts: imx8mp-var-som-symphony: keep RGB_SEL low
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Keep the RGB_SEL line driven low on the Symphony carrier board.
This avoids leaving the line floating and ensures the board remains in
the expected display configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 387bbe3454c3..7f5109bb4182 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -193,6 +193,14 @@ pcal6408: gpio@21 {
reg = <0x21>;
#gpio-cells = <2>;
gpio-controller;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
};
st33ktpm2xi2c: tpm@2e {
--
2.47.3
^ permalink raw reply related
* [PATCH v5 11/14] arm64: dts: imx8mp-var-som-symphony: enable PWM1
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable PWM1 on the Symphony carrier board and add the corresponding
pinctrl configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
v1->v2:
-
.../boot/dts/freescale/imx8mp-var-som-symphony.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 7f5109bb4182..54cb5725c4bf 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -247,6 +247,12 @@ &pcie_phy {
status = "okay";
};
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
&snvs_pwrkey {
status = "okay";
};
@@ -400,6 +406,12 @@ MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10
>;
};
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SPDIF_EXT_CLK__PWM1_OUT 0x116
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x40
--
2.47.3
^ permalink raw reply related
* [PATCH v5 12/14] arm64: dts: imx8mp-var-som-symphony: enable CAN
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Enable the FlexCAN2 controller on the Symphony carrier board and add the
corresponding pinctrl configuration.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
- Add FlexCAN2 controller support
v1->v2:
-
.../boot/dts/freescale/imx8mp-var-som-symphony.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
index 54cb5725c4bf..93dee9ec0b9b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som-symphony.dts
@@ -106,6 +106,12 @@ &ecspi2 {
status = "okay";
};
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
&hdmi_pai {
status = "okay";
};
@@ -357,6 +363,13 @@ MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x12
>;
};
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART3_RXD__CAN2_TX 0x154
+ MX8MP_IOMUXC_UART3_TXD__CAN2_RX 0x154
+ >;
+ };
+
pinctrl_hdmi: hdmigrp {
fsl,pins = <
MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x1c2
--
2.47.3
^ permalink raw reply related
* [PATCH v5 14/14] arm64: dts: freescale: imx8mp-var-som: add I2C1 bus recovery GPIOs
From: Stefano Radaelli @ 2026-06-08 14:41 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
In-Reply-To: <cover.1780929317.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add the GPIO pinctrl state and GPIO descriptors required for I2C1 bus
recovery on the VAR-SOM-MX8M-PLUS.
This allows the I2C controller to recover the bus if SDA or SCL are held
low by a device.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v4->v5:
-
v3->v4:
-
v2->v3:
-
arch/arm64/boot/dts/freescale/imx8mp-var-som.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-var-som.dtsi
index 49467b48d0b0..61786eee0e82 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-var-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-var-som.dtsi
@@ -180,8 +180,11 @@ led@1 {
&i2c1 {
clock-frequency = <400000>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
status = "okay";
pmic@25 {
@@ -415,6 +418,13 @@ MX8MP_IOMUXC_SD1_DATA5__I2C1_SDA 0x400001c2
>;
};
+ pinctrl_i2c1_gpio: i2c1gpiogrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 0x1c2
+ MX8MP_IOMUXC_SD1_DATA5__GPIO2_IO07 0x1c2
+ >;
+ };
+
pinctrl_pmic: pmicgrp {
fsl,pins = <
MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO04 0x1c0
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-08 14:43 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <bkve3vmokuyrn4agsqyzxlqr5wuy5y6urnliqypac3h6lb32hy@tfkjstevqv2y>
On 6/8/2026 7:20 PM, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 06:59:34PM +0530, Bibek Kumar Patro wrote:
>>
>> ...
>>
>>> ---
>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>> @@ -53,6 +53,11 @@
>>> #define MSI_IOVA_BASE 0x8000000
>>> #define MSI_IOVA_LENGTH 0x100000
>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>>> +
>>> static int force_stage;
>>> module_param(force_stage, int, S_IRUGO);
>>> MODULE_PARM_DESC(force_stage,
>>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>>> }
>>> }
>>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>>> +{
>>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>>> + if (IS_ERR(smmu->icc_path)) {
>>> + int err = PTR_ERR(smmu->icc_path);
>>> +
>>> + if (err == -ENODEV) {
>>> + smmu->icc_path = NULL;
>>> + return 0;
>>> + }
>>> + return dev_err_probe(smmu->dev, err,
>>> + "failed to get interconnect path\n");
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static void arm_smmu_icc_enable(struct arm_smmu_device *smmu)
>>> +{
>>> + if (smmu->icc_path)
>>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>>> + ARM_SMMU_ICC_PEAK_BW_HIGH));
>>> +}
>>> +
>>> +static void arm_smmu_icc_disable(struct arm_smmu_device *smmu)
>>> +{
>>> + if (smmu->icc_path)
>>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>>> + ARM_SMMU_ICC_PEAK_BW_LOW));
>>> +}
>>> +
>>> static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
>>> {
>>> /*
>>> @@ -2189,6 +2224,17 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>>> if (err)
>>> return err;
>>> + /*
>>> + * Acquire and vote the interconnect path before accessing any SMMU
>>> + * registers (including ARM_SMMU_GR0_ID0 in arm_smmu_device_cfg_probe).
>>> + */
>>> + err = arm_smmu_icc_get(smmu);
>>> + if (err) {
>>> + clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
>>> + return err;
>>> + }
>>> + arm_smmu_icc_enable(smmu);
>>> +
>>> err = arm_smmu_device_cfg_probe(smmu);
>>> if (err)
>>> return err;
>>> @@ -2273,8 +2319,10 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
>>> if (pm_runtime_enabled(smmu->dev))
>>> pm_runtime_force_suspend(smmu->dev);
>>> - else
>>> + else {
>>> clk_bulk_disable(smmu->num_clks, smmu->clks);
>>> + arm_smmu_icc_disable(smmu);
>>> + }
>>> clk_bulk_unprepare(smmu->num_clks, smmu->clks);
>>> }
>>> @@ -2294,9 +2342,13 @@ static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
>>> struct arm_smmu_device *smmu = dev_get_drvdata(dev);
>>> int ret;
>>> + arm_smmu_icc_enable(smmu);
>>> +
>>> ret = clk_bulk_enable(smmu->num_clks, smmu->clks);
>>> - if (ret)
>>> + if (ret) {
>>> + arm_smmu_icc_disable(smmu);
>>> return ret;
>>> + }
>>> arm_smmu_device_reset(smmu);
>>> @@ -2308,6 +2360,7 @@ static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
>>> struct arm_smmu_device *smmu = dev_get_drvdata(dev);
>>> clk_bulk_disable(smmu->num_clks, smmu->clks);
>>> + arm_smmu_icc_disable(smmu);
>>> return 0;
>>> }
>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
>>> index 26d2e33cd328b8278888585fc07a31485d9397e2..c00606a416b2f4bb44a35e5d67f6ef801df68e1c 100644
>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
>>> @@ -15,6 +15,7 @@
>>> #include <linux/bits.h>
>>> #include <linux/clk.h>
>>> #include <linux/device.h>
>>> +#include <linux/interconnect.h>
>>> #include <linux/io-64-nonatomic-hi-lo.h>
>>> #include <linux/io-pgtable.h>
>>> #include <linux/iommu.h>
>>> @@ -335,6 +336,7 @@ struct arm_smmu_device {
>>> int num_clks;
>>> unsigned int *irqs;
>>> struct clk_bulk_data *clks;
>>> + struct icc_path *icc_path;
>>> spinlock_t global_sync_lock;
>>>
>>
>> Any feedback or concerns on the interconnect voting approach proposed here?
>>
>> This helps to address the kernel panic issue [1] reported for one of
>> Qualcomm platforms.
>
> Please respond or tend the issues, pointed out by Sashiko.
>
Sure, I have addressed and replied to the Sashiko warnings on v1,
I'll check on the fresh warnings on V2 along with your suggestions on
this patch.
< I was wondering if it's needed to respond to Sashiko comments earlier
or silently address the relevant ones,
so thanks for confirming this as well :) >
Thanks,
Bibek
>>
>> [1]: https://github.com/qualcomm-linux/kernel/issues/297
>>
>> Thanks,
>> Bibek
>
^ permalink raw reply
* Re: [PATCH 01/18] pinctrl: airoha: an7581: add missed gpio32 pin group
From: Bartosz Golaszewski @ 2026-06-08 14:48 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-2-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:37 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> gpio32 pin group is missed for an7581 SoC. This patch add it.
>
> Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 02/18] pinctrl: airoha: an7583: add missed gpio32 pin group
From: Bartosz Golaszewski @ 2026-06-08 14:48 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-3-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:38 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> gpio32 pin group is missed for an7583 SoC. This patch add it.
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 03/18] pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-4-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:39 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
I think the term we typically use is "typo" but I won't die on that hill.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 04/18] pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
From: Bartosz Golaszewski @ 2026-06-08 14:50 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-5-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:40 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
> a proper bit number in the configuration register.
>
> Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [RFC PATCH 2/2] firmware: arm_scmi: Add bus support for autoloading
From: Daniel Lezcano @ 2026-06-08 14:51 UTC (permalink / raw)
To: Cristian Marussi
Cc: arm-scmi, guomin_chen, linux-arm-kernel, peng.fan, quic_xinqzhan,
sudeep.holla
In-Reply-To: <20250203100154.140877-2-cristian.marussi@arm.com>
On Mon, Feb 03, 2025 at 10:01:54AM +0000, Cristian Marussi wrote:
> Emit proper MODALIAS uevents when SCMI devices are created and make sure
> all the standard protocol devices are requested when the bus is
> initialized.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
Hi Cristian,
what is the status of this patch ?
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Sebastian Ene @ 2026-06-08 14:51 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Zyngier, catalin.marinas, oupton, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui, Sudeep Holla
In-Reply-To: <aibUXmzfDsVWcZjY@willie-the-truck>
On Mon, Jun 08, 2026 at 03:40:30PM +0100, Will Deacon wrote:
> Hey Seb,
>
> On Mon, Jun 08, 2026 at 02:22:22PM +0000, Sebastian Ene wrote:
> > On Fri, May 29, 2026 at 04:32:24PM +0100, Will Deacon wrote:
> > > I'd probably structure it as a separate patch per call, tbh. That way,
> > > the commit message can talk about the specific fields that are reserved
> > > for a given call. See below.
> > >
> > > > Refactor the handling logic in pKVM FF-A proxy to support checking for
> > > > SBZ/MBZ values. While at it, drop the do_ffa_mem_xfer macro and replace
> > > > it with two functions that make it clear that we re-write the
> > > > function-id with a 64-bit variant, to keep the same behavior as before.
> > > > Keep each handler in an array of structures together with a mask that
> > > > corresponds to the SBZ registers the spec expects.
> > >
> > > Although I agree that we should be enforcing SBZ/MBZ paramaters (because
> > > we have no idea what they might do in future versions of the spec), I
> > > also think that doing this at the register level is too coarse.
> > >
> > > For example, the VM ID parameter to FFA_NOTIFICATION_BITMAP_CREATE has bits
> > > 31:16 as MBZ. So I think we probably need to do the checking on a
> > > per-function basis, like Per is doing in his series:
> > >
> > > https://lore.kernel.org/r/20260501-host-direct-messages-v6-0-3f4af727ed85@google.com
> > >
> >
> > For the newly added calls like FFA_NOTIFICATION_* we can do that in a
> > separate functions, but what about the other existing calls that have
> > MBZ registers ? that was the reason for the inline proposal in :
> > https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
> > (to avoid duplicate checks).
>
> For unused parameter registers that are SBZ, I think you could just add
> a helper, e.g.:
>
> ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int reg);
>
> which takes the index of the first unused register and then checks that
> all the registers from there to the last unused parameter register are
> zero. You can then just call that directly before you start parsing the
> SBZ/MBZ fields on the used parameter registers and there's no need for
> the table-based indirection in [1].
I see, will do that, thanks.
Sebastian
>
> Will
>
> [1] https://lore.kernel.org/all/af3fW468-f1KXCrC@google.com/
^ permalink raw reply
* Re: [PATCH 05/18] pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
From: Bartosz Golaszewski @ 2026-06-08 14:52 UTC (permalink / raw)
To: Mikhail Kshevetskiy
Cc: Linus Walleij, Sean Wang, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi,
Bartosz Golaszewski, Benjamin Larsson, linux-kernel, linux-gpio,
linux-mediatek, linux-arm-kernel, Matheus Sampaio Queiroga,
Markus Gothe
In-Reply-To: <20260607001654.1439480-6-mikhail.kshevetskiy@iopsys.eu>
On Sun, 7 Jun 2026 02:16:41 +0200, Mikhail Kshevetskiy
<mikhail.kshevetskiy@iopsys.eu> said:
> phy4_led1 pin function maps led incorrectly. It uses the same map as
> phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
>
> Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 0/2] soc: aspeed: Add BMC and host driver for PCIe BMC device
From: Grégoire Layet @ 2026-06-08 14:51 UTC (permalink / raw)
To: joel, andrew
Cc: andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1780409151.git.gregoire.layet@9elements.com>
This is a v2 for upstreaming the VUART over PCIe BMC device driver from the ASPEED kernel SDK (branch master-v6.18) [1].
There are two drivers: a BMC-side driver and a host-side driver.
Together they enable host<->BMC VUART communication via PCIe.
This v2 narrows down the scope to VUART support only, to address review feedback on v1 [2]
that the additional subsystems (shared memory, doorbell and mailbox) were software-defined
IPC channels better used with rpmsg or virtio.
Those subsystems are deferred to a separate future series.
VUART data flow and MSI interrupts have been verified working on the test hardware.
Tested on:
BMC:
- Asus IPMI Kommando Card R1.01, AST2600 A3.
- OpenBMC
Host:
- Linux kernel v7.0.0
This v2 only supports AST2600; the AST2700 is untested and not supported by this patch.
Changes since v1 [2]:
- BMC driver: trimmed down to only SCU and PCIe initialization
- Host driver: removed shared memory misc device, sysfs doorbell, mailbox setup and message queue handler.
Driver now only supports VUART registration.
- Host driver: Fixed cleanup path: removed pci_release_regions() call as there was no matching pci_request_regions call
[1]: https://github.com/AspeedTech-BMC/linux/tree/aspeed-master-v6.18/drivers/soc/aspeed
[2]: https://lore.kernel.org/linux-aspeed/cover.1780409151.git.gregoire.layet@9elements.com/
Grégoire Layet (2):
soc: aspeed: add BMC-side PCIe BMC device driver
soc: aspeed: add host-side PCIe BMC device driver
drivers/soc/aspeed/Kconfig | 15 ++
drivers/soc/aspeed/Makefile | 2 +
drivers/soc/aspeed/aspeed-bmc-dev.c | 187 +++++++++++++++++
drivers/soc/aspeed/aspeed-host-bmc-dev.c | 249 +++++++++++++++++++++++
4 files changed, 453 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-bmc-dev.c
create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
--
2.51.2
^ permalink raw reply
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