* [PATCH v2 1/1] ARM: dts: aspeed: santabarbara: Add system monitoring GPIOs
From: Fred Chen @ 2026-04-21 13:03 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260421130344.2751662-1-fredchen.openbmc@gmail.com>
Add several GPIO expanders to the Santabarbara platform, with ioexp0
(0x20) configured to aggregate interrupt signals from downstream
expanders to optimize sideband pin usage.
The new GPIO nodes provide support for:
- NIC1-4 power good monitoring, reset control, and fault detection
- Switch PEX power good signals and hardware SKU/Revision IDs
- Cable presence detection and selection for four SPI flashes
- System power fault alert via SGPIO and E1S GPIO expander interrupt
Signed-off-by: Fred Chen <fredchen.openbmc@gmail.com>
---
.../aspeed-bmc-facebook-santabarbara.dts | 125 +++++++++++++++++-
1 file changed, 124 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
index 0a3e2e241063..2a822e38f091 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-santabarbara.dts
@@ -616,6 +616,8 @@ gpio@74 {
reg = <0x74>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <146 IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"P12V_E1S_ADC_ALERT","BUFF0_100M_LOSB_PLD",
"E1S_BP_SKU_ID0","E1S_BP_SKU_ID1",
@@ -1335,6 +1337,112 @@ eeprom@50 {
&i2c12 {
status = "okay";
+ ioexp0: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <148 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "IOEXP_21h_INT_N","IOEXP_22h_INT_N",
+ "IOEXP_23h_INT_N","IOEXP_24h_INT_N",
+ "IOEXP_25h_INT_N","IOEXP_26h_INT_N",
+ "IOEXP_27h_INT_N","SWB_PWR_FAULT_N",
+ "","","","",
+ "","","","";
+ };
+
+ gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&ioexp0>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "PDB_PRSNT_J1_N","PDB_PRSNT_J2_N",
+ "PRSNT_NIC1_N","PRSNT_NIC2_N",
+ "PRSNT_NIC3_N","PRSNT_NIC4_N",
+ "","",
+ "CBL_PRSNT_MCIO_0_N","CBL_PRSNT_MCIO_1_N",
+ "CBL_PRSNT_MCIO_2_N","CBL_PRSNT_MCIO_3_N",
+ "","","","";
+ };
+
+ gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&ioexp0>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "SWB_PWRGD_P3V3_AUX","SWB_PWRGD_P1V8_PEX",
+ "SWB_PWRGD_P1V8_AUX","SWB_PWRGD_P5V",
+ "SWB_PWRGD_P1V5_PEX","SWB_PWRGD_P1V2_PEX",
+ "SWB_PWRGD_P0V895_PEX","SWB_PWRGD_P0V81_PEX_0",
+ "SWB_PWRGD_P0V81_PEX_1","SWB_PWRGD_P0V81_REFCLK",
+ "SWB_PWRGD_MODULE","",
+ "","","","";
+ };
+
+ gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&ioexp0>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "RST_PERST_NIC1_N","RST_PERST_NIC2_N",
+ "RST_PERST_NIC3_N","RST_PERST_NIC4_N",
+ "RST_PERST_MCIO_0_N","RST_PERST_MCIO_1_N",
+ "RST_PERST_MCIO_2_N","RST_PERST_MCIO_3_N",
+ "FM_P3V3_NIC1_FAULT_N","FM_P3V3_NIC2_FAULT_N",
+ "FM_P3V3_NIC3_FAULT_N","FM_P3V3_NIC4_FAULT_N",
+ "PWRGD_P12V_NIC1","PWRGD_P12V_NIC2",
+ "PWRGD_P12V_NIC3","PWRGD_P12V_NIC4";
+ };
+
+ gpio@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&ioexp0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "NIC1_MAIN_R_PWR_EN","NIC2_MAIN_R_PWR_EN",
+ "NIC3_MAIN_R_PWR_EN","NIC4_MAIN_R_PWR_EN",
+ "FM_PLD_NIC1_AUX_PWR_EN","FM_PLD_NIC2_AUX_PWR_EN",
+ "FM_PLD_NIC3_AUX_PWR_EN","FM_PLD_NIC4_AUX_PWR_EN",
+ "PWRGD_NIC1","PWRGD_NIC2",
+ "PWRGD_NIC3","PWRGD_NIC4",
+ "PWRGD_P3V3_NIC1","PWRGD_P3V3_NIC2",
+ "PWRGD_P3V3_NIC3","PWRGD_P3V3_NIC4";
+ };
+
+ gpio@26 {
+ compatible = "nxp,pca9555";
+ reg = <0x26>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&ioexp0>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ gpio-line-names =
+ "SWB_SKU_ID_0","SWB_SKU_ID_1",
+ "SWB_SKU_ID_2","SWB_SKU_ID_3",
+ "SWB_REV_ID_0","SWB_REV_ID_1",
+ "SWB_REV_ID_2","",
+ "RST_PLD_PEX_PERST_N","CPLD_MB_PWR_EN",
+ "RST_PERST_SWB_R_N","SWB_LEAK_DETECT",
+ "PEX_SYS_ERR_FPGA","PRSNT_SWB_LEAK_CABLE_N",
+ "","";
+ };
+
gpio@27 {
compatible = "nxp,pca9555";
reg = <0x27>;
@@ -1349,6 +1457,21 @@ gpio@27 {
"SPI_MUX_SEL","","","";
};
+ gpio@28 {
+ compatible = "nxp,pca9555";
+ reg = <0x28>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names =
+ "SCO_UART_MUX_SEL0","SCO_UART_MUX_SEL1",
+ "SPI_PROG_PL12_SEL","SPI_PROG_PL34_SEL",
+ "","","","",
+ "I3C_HUB_3_MUX_SEL_PLD","",
+ "SPI_PROG_PL12_EN_N","SPI_PROG_PL34_EN_N",
+ "SCO1_SPI_SEL","SCO2_SPI_SEL",
+ "SCO3_SPI_SEL","SCO4_SPI_SEL";
+ };
+
// SWB FRU
eeprom@52 {
compatible = "atmel,24c64";
@@ -1776,7 +1899,7 @@ &sgpiom0 {
"MB_SKU_ID_1","PASSWORD_CLEAR",
"MB_SKU_ID_2","",
"MB_SKU_ID_3","",
- "","BIOS_DEBUG_MODE",
+ "SYS_PWR_FAULT_ALERT","BIOS_DEBUG_MODE",
/*H0-H3 line 112-119*/
"FM_IOEXP_U538_INT_N","",
"FM_IOEXP_U539_INT_N","FM_MODULE_PWR_EN_N_1B",
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 02/20] drm/atomic: Drop drm_private_state.obj assignment from create_state
From: Thomas Zimmermann @ 2026-04-21 13:03 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-2-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> The initial intent of the atomic_create_state helper was to simply
> allocate a proper drm_private_state and returning it, without any side
> effect.
>
> However, the __drm_atomic_helper_private_obj_create_state() introduces a
> side effect by setting the drm_private_obj.state to the newly allocated
> state.
>
> This assignment defeats the purpose, but is also redundant since
> the only caller, drm_atomic_private_obj_init(), will also set this
> pointer to the newly allocated state.
Is this paragraph no longer up to date? Grepping for
__drm_atomic_helper_private_obj_create_state returns plenty of callers.
Best regards Thomas
>
> Let's drop the assignment in __drm_atomic_helper_private_obj_create_state().
>
> Fixes: e7be39ed1716 ("drm/atomic-helper: Add private_obj atomic_create_state helper")
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 76746ad4a1bbb7142c067c93dd05fbec5d2f98eb..875149494b00e1eb7481e87d7d7038103b72b7e3 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -729,12 +729,10 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_destroy_state);
> void __drm_atomic_helper_private_obj_create_state(struct drm_private_obj *obj,
> struct drm_private_state *state)
> {
> if (state)
> state->obj = obj;
> -
> - obj->state = state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_private_obj_create_state);
>
> /**
> * __drm_atomic_helper_private_obj_duplicate_state - copy atomic private state
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 03/20] drm/mode-config: Mention drm_mode_config_reset() culprits
From: Thomas Zimmermann @ 2026-04-21 13:08 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-3-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> drm_mode_config_reset() does not reset drm_private_states by design.
>
> This is especially significant for the DP MST and tunneling code that
> expect to be preserved across a suspend/resume cycle, where
> drm_mode_config_reset() is also used.
Do we really? There's drm_mode_config_helper_suspend/resume(). Why would
drivers do a drm_mode_config_reset().
Best regards
Thomas
>
> Let's document this expectation.
>
> Link: https://lore.kernel.org/dri-devel/aOaQLx-7EpsHRwkH@ideak-desk/
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_mode_config.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 66f7dc37b5970c0a08f8dde008aef56376c59f37..cba527571ca66d3aa6dc652c87e03a19815d1d41 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -187,10 +187,14 @@ int drm_mode_getresources(struct drm_device *dev, void *data,
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> * callback. Drivers can use this in e.g. their driver load or resume code to
> * reset hardware and software state.
> + *
> + * Note that @drm_private_obj structures are expected to be stable across
> + * suspend/resume cycles, and @drm_mode_config_reset() does not affect these
> + * structures.
> */
> void drm_mode_config_reset(struct drm_device *dev)
> {
> struct drm_crtc *crtc;
> struct drm_colorop *colorop;
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 04/20] drm/colorop: Rename __drm_colorop_state_reset()
From: Thomas Zimmermann @ 2026-04-21 13:13 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-4-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_colorop_state_reset() is used to initialize a newly allocated
> drm_colorop_state, and is being typically called by drm_colorop_reset().
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_colorop_state instance, we will need to call
> __drm_colorop_state_reset() from both the reset and atomic_create paths.
>
> To avoid any confusion, we can thus rename __drm_colorop_state_reset()
> to __drm_colorop_state_init().
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
This makes sense considering the next patch
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_colorop.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 373cd0ddb8fd4478874509ed12c95451c1f66203..6a26b83b260e8d8e83c703ecde490a7a8740ebfb 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -498,19 +498,19 @@ void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> __drm_atomic_helper_colorop_destroy_state(state);
> kfree(state);
> }
>
> /**
> - * __drm_colorop_state_reset - resets colorop state to default values
> + * __drm_colorop_state_init - Initializes colorop state to default values
> * @colorop_state: atomic colorop state, must not be NULL
> * @colorop: colorop object, must not be NULL
> *
> * Initializes the newly allocated @colorop_state with default
> * values. This is useful for drivers that subclass the colorop state.
> */
> -static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> - struct drm_colorop *colorop)
> +static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> + struct drm_colorop *colorop)
> {
> u64 val;
>
> colorop_state->colorop = colorop;
> colorop_state->bypass = true;
> @@ -537,11 +537,11 @@ static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> */
> static void __drm_colorop_reset(struct drm_colorop *colorop,
> struct drm_colorop_state *colorop_state)
> {
> if (colorop_state)
> - __drm_colorop_state_reset(colorop_state, colorop);
> + __drm_colorop_state_init(colorop_state, colorop);
>
> colorop->state = colorop_state;
> }
>
> void drm_colorop_reset(struct drm_colorop *colorop)
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 05/20] drm/colorop: Create drm_atomic_helper_colorop_create_state()
From: Thomas Zimmermann @ 2026-04-21 13:13 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-5-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> It's also only relevant for some drivers, since all the helpers for
> reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect: atomic_create_state
> to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with drm_colorop.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_colorop.c | 23 +++++++++++++++++++++++
> include/drm/drm_colorop.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 6a26b83b260e8d8e83c703ecde490a7a8740ebfb..7bfaf2617ec315f42d80ac72a5eaaef868e65657 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -521,10 +521,33 @@ static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> &val);
> colorop_state->curve_1d_type = val;
> }
> }
>
> +/**
> + * drm_atomic_helper_colorop_create_state - Allocates and initializes colorop atomic state
> + * @colorop: drm colorop
> + *
> + * Initializes a pristine @drm_colorop_state.
> + *
> + * RETURNS:
> + * Pointer to new colorop state, or ERR_PTR on failure.
> + */
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop)
> +{
> + struct drm_colorop_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_colorop_state_init(state, colorop);
> +
> + return state;
> +}
> +
> /**
> * __drm_colorop_reset - reset state on colorop
> * @colorop: drm colorop
> * @colorop_state: colorop state to assign
> *
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index bd082854ca74cac90b42020b09206a8516687666..874ed693329c0ecf94567c094744fe86fd08e382 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -423,10 +423,12 @@ int drm_plane_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *col
> struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
> uint32_t lut_size,
> enum drm_colorop_lut3d_interpolation_type interpolation,
> uint32_t flags);
>
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop);
> struct drm_colorop_state *
> drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
>
> void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> struct drm_colorop_state *state);
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 06/20] drm/atomic-state-helper: Fix __drm_atomic_helper_plane_reset() doc typo
From: Thomas Zimmermann @ 2026-04-21 13:14 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-6-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> A typo has slipped through in the __drm_atomic_helper_plane_reset()
> documentation, probably due to copy and paste. It will not assign
> drm_crtc state pointer, but rather the drm_plane's.
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 875149494b00e1eb7481e87d7d7038103b72b7e3..e1f3d05ad3470154a6be01423979a4deb8617441 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -303,11 +303,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
> * __drm_atomic_helper_plane_reset - reset state on plane
> * @plane: drm plane
> * @plane_state: plane state to assign
> *
> * Initializes the newly allocated @plane_state and assigns it to
> - * the &drm_crtc->state pointer of @plane, usually required when
> + * the &drm_plane->state pointer of @plane, usually required when
> * initializing the drivers or when called from the &drm_plane_funcs.reset
> * hook.
> *
> * This is useful for drivers that subclass the plane state.
> */
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 03/20] drm/mode-config: Mention drm_mode_config_reset() culprits
From: Maxime Ripard @ 2026-04-21 13:18 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <8f111841-bb88-4cbb-a3ae-b26ac2f252cb@suse.de>
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
Hi Thomas,
On Tue, Apr 21, 2026 at 03:08:03PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > drm_mode_config_reset() does not reset drm_private_states by design.
> >
> > This is especially significant for the DP MST and tunneling code that
> > expect to be preserved across a suspend/resume cycle, where
> > drm_mode_config_reset() is also used.
>
> Do we really? There's drm_mode_config_helper_suspend/resume(). Why would
> drivers do a drm_mode_config_reset().
drm_mode_config_helper_resume() will call drm_atomic_helper_resume()
that call drm_mode_config_reset(). So (most) drivers will not directly
call it, but it is going to be called still.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 07/20] drm/atomic-state-helper: Rename __drm_atomic_helper_plane_state_reset()
From: Thomas Zimmermann @ 2026-04-21 13:20 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-7-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_atomic_helper_plane_state_reset() is used to initialize a newly
> allocated drm_plane_state, and is being typically called by the
> drm_plane_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_plane_state instance, we will need to call
> __drm_atomic_helper_plane_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_plane_state_reset() to
> __drm_atomic_helper_plane_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
I think the renaming makes sense even without the atomic_create_state
callbacks.
> * Initializes the newly allocated @plane_state with default
> * values. This is useful for drivers that subclass the CRTC state.
> */
> -void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> - struct drm_plane *plane)
> +void __drm_atomic_helper_plane_state_init(struct drm_plane_state *plane_state,
> + struct drm_plane *plane)
All such helpers are now just common init functions and you could drop
the double-underscores from the name, I think.
Best regards
Thomas
> {
> u64 val;
>
> plane_state->plane = plane;
> plane_state->rotation = DRM_MODE_ROTATE_0;
> @@ -295,11 +295,11 @@ void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> plane->hotspot_y_property,
> &val))
> plane_state->hotspot_y = val;
> }
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_plane_state_init);
>
> /**
> * __drm_atomic_helper_plane_reset - reset state on plane
> * @plane: drm plane
> * @plane_state: plane state to assign
> @@ -313,11 +313,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
> */
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *plane_state)
> {
> if (plane_state)
> - __drm_atomic_helper_plane_state_reset(plane_state, plane);
> + __drm_atomic_helper_plane_state_init(plane_state, plane);
>
> plane->state = plane_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_reset);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane.c b/drivers/gpu/drm/i915/display/intel_plane.c
> index e06a0618b4c6cd3b4d13752f604006b525118193..705367fef836663e50fe9bbfb1fcc83abf1fb249 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane.c
> @@ -65,11 +65,11 @@
> static void intel_plane_state_reset(struct intel_plane_state *plane_state,
> struct intel_plane *plane)
> {
> memset(plane_state, 0, sizeof(*plane_state));
>
> - __drm_atomic_helper_plane_state_reset(&plane_state->uapi, &plane->base);
> + __drm_atomic_helper_plane_state_init(&plane_state->uapi, &plane->base);
>
> plane_state->scaler_id = -1;
> }
>
> struct intel_plane *intel_plane_alloc(void)
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 900672c6ea90ba9cb87e38a7c84225972aee43c5..44e8850aae7fd6390f4b58188a9c677b8389702f 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -51,11 +51,11 @@ struct drm_crtc_state *
> drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
>
> -void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *state,
> +void __drm_atomic_helper_plane_state_init(struct drm_plane_state *state,
> struct drm_plane *plane);
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *state);
> void drm_atomic_helper_plane_reset(struct drm_plane *plane);
> void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 08/20] drm/plane: Add new atomic_create_state callback
From: Thomas Zimmermann @ 2026-04-21 13:22 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-8-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with planes.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 44 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_plane.h | 13 +++++++++
> 4 files changed, 81 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 2548d6da13675f63304dc92423c5d225de0447a8..f4ce9d3573cbecf216904db54335e0cf84a01c39 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -319,10 +319,29 @@ void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
>
> plane->state = plane_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_reset);
>
> +/**
> + * __drm_atomic_helper_plane_create_state - initializes plane state
> + * @plane: plane object
> + * @state: new state to initialize
> + *
> + * Initializes the newly allocated @state, usually required when
> + * initializing the drivers.
> + *
> + * @state is assumed to be zeroed.
> + *
> + * This is useful for drivers that subclass @drm_plane_state.
> + */
> +void __drm_atomic_helper_plane_create_state(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + __drm_atomic_helper_plane_state_init(state, plane);
> +}
> +EXPORT_SYMBOL(__drm_atomic_helper_plane_create_state);
Will this function have another purpuse? Could we just call
_plane_state_init() directly from anywhere?
Best regards
Thomas
> +
> /**
> * drm_atomic_helper_plane_reset - default &drm_plane_funcs.reset hook for planes
> * @plane: drm plane
> *
> * Resets the atomic state for @plane by freeing the state pointer (which might
> @@ -338,10 +357,35 @@ void drm_atomic_helper_plane_reset(struct drm_plane *plane)
> if (plane->state)
> __drm_atomic_helper_plane_reset(plane, plane->state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
>
> +/**
> + * drm_atomic_helper_plane_create_state - default &drm_plane_funcs.atomic_create_state hook for planes
> + * @plane: plane object
> + *
> + * Initializes a pristine @drm_plane_state.
> + *
> + * This is useful for drivers that don't subclass @drm_plane_state.
> + *
> + * RETURNS:
> + * Pointer to new plane state, or ERR_PTR on failure.
> + */
> +struct drm_plane_state *drm_atomic_helper_plane_create_state(struct drm_plane *plane)
> +{
> + struct drm_plane_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_atomic_helper_plane_create_state(plane, state);
> +
> + return state;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_plane_create_state);
> +
> /**
> * __drm_atomic_helper_plane_duplicate_state - copy atomic plane state
> * @plane: plane object
> * @state: atomic plane state
> *
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index cba527571ca66d3aa6dc652c87e03a19815d1d41..09b8292195ba5eb5d96735aee5506407bd32ade3 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -180,10 +180,26 @@ int drm_mode_getresources(struct drm_device *dev, void *data,
> drm_connector_list_iter_end(&conn_iter);
>
> return ret;
> }
>
> +static int drm_mode_config_plane_create_state(struct drm_plane *plane)
> +{
> + struct drm_plane_state *plane_state;
> +
> + if (!plane->funcs->atomic_create_state)
> + return 0;
> +
> + plane_state = plane->funcs->atomic_create_state(plane);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> + plane->state = plane_state;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_config_reset - call ->reset callbacks
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> @@ -204,13 +220,16 @@ void drm_mode_config_reset(struct drm_device *dev)
> struct drm_connector_list_iter conn_iter;
>
> drm_for_each_colorop(colorop, dev)
> drm_colorop_reset(colorop);
>
> - drm_for_each_plane(plane, dev)
> + drm_for_each_plane(plane, dev) {
> if (plane->funcs->reset)
> plane->funcs->reset(plane);
> + else if (plane->funcs->atomic_create_state)
> + drm_mode_config_plane_create_state(plane);
> + }
>
> drm_for_each_crtc(crtc, dev)
> if (crtc->funcs->reset)
> crtc->funcs->reset(crtc);
>
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 44e8850aae7fd6390f4b58188a9c677b8389702f..6a3a2feb3dff1f2fbdf2a6e63d8d7317c7d6ead6 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -53,10 +53,14 @@ void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
>
> void __drm_atomic_helper_plane_state_init(struct drm_plane_state *state,
> struct drm_plane *plane);
> +void __drm_atomic_helper_plane_create_state(struct drm_plane *plane,
> + struct drm_plane_state *state);
> +struct drm_plane_state *
> +drm_atomic_helper_plane_create_state(struct drm_plane *plane);
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *state);
> void drm_atomic_helper_plane_reset(struct drm_plane *plane);
> void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> struct drm_plane_state *state);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 703ef4d1bbbcf084c43aa5e127d28691878061c4..4d4d511b681d50c17fbc593cce9f706d63e04a52 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -386,10 +386,23 @@ struct drm_plane_funcs {
> * 0 on success or a negative error code on failure.
> */
> int (*set_property)(struct drm_plane *plane,
> struct drm_property *property, uint64_t val);
>
> + /**
> + * @atomic_create_state:
> + *
> + * Allocates a pristine, initialized, state for the plane object
> + * and returns it.
> + *
> + * RETURNS:
> + *
> + * A new, pristine, plane state instance or an error pointer
> + * on failure.
> + */
> + struct drm_plane_state *(*atomic_create_state)(struct drm_plane *plane);
> +
> /**
> * @atomic_duplicate_state:
> *
> * Duplicate the current atomic state for this plane and return it.
> * The core and helpers guarantee that any atomic state duplicated with
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 09/20] drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
From: Thomas Zimmermann @ 2026-04-21 13:23 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-9-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_atomic_helper_crtc_state_reset() is used to initialize a newly
> allocated drm_crtc_state, and is being typically called by the
> drm_crtc_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_crtc_state instance, we will need to call
> __drm_atomic_helper_crtc_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_crtc_state_reset() to
> __drm_atomic_helper_crtc_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
with similar comments as for the other case.
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> include/drm/drm_atomic_state_helper.h | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index f4ce9d3573cbecf216904db54335e0cf84a01c39..b87cc3cd5b0021699ac57a33739d172a5706e2e1 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -61,25 +61,25 @@
> * For other drivers the building blocks are split out, see the documentation
> * for these functions.
> */
>
> /**
> - * __drm_atomic_helper_crtc_state_reset - reset the CRTC state
> + * __drm_atomic_helper_crtc_state_init - Initializes the CRTC state
> * @crtc_state: atomic CRTC state, must not be NULL
> * @crtc: CRTC object, must not be NULL
> *
> * Initializes the newly allocated @crtc_state with default
> * values. This is useful for drivers that subclass the CRTC state.
> */
> void
> -__drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
> - struct drm_crtc *crtc)
> +__drm_atomic_helper_crtc_state_init(struct drm_crtc_state *crtc_state,
> + struct drm_crtc *crtc)
> {
> crtc_state->crtc = crtc;
> crtc_state->background_color = DRM_ARGB64_PREP(0xffff, 0, 0, 0);
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_init);
>
> /**
> * __drm_atomic_helper_crtc_reset - reset state on CRTC
> * @crtc: drm CRTC
> * @crtc_state: CRTC state to assign
> @@ -94,11 +94,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> void
> __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> struct drm_crtc_state *crtc_state)
> {
> if (crtc_state)
> - __drm_atomic_helper_crtc_state_reset(crtc_state, crtc);
> + __drm_atomic_helper_crtc_state_init(crtc_state, crtc);
>
> if (drm_dev_has_vblank(crtc->dev))
> drm_crtc_vblank_reset(crtc);
>
> crtc->state = crtc_state;
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 53378d2dcbec867e7973cb3b874802f2ada01d41..b57a59a5f7786f1029d576b0f3d564e77b7060e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -179,11 +179,11 @@ struct intel_crtc_state *intel_crtc_state_alloc(struct intel_crtc *crtc)
> void intel_crtc_state_reset(struct intel_crtc_state *crtc_state,
> struct intel_crtc *crtc)
> {
> memset(crtc_state, 0, sizeof(*crtc_state));
>
> - __drm_atomic_helper_crtc_state_reset(&crtc_state->uapi, &crtc->base);
> + __drm_atomic_helper_crtc_state_init(&crtc_state->uapi, &crtc->base);
>
> crtc_state->cpu_transcoder = INVALID_TRANSCODER;
> crtc_state->master_transcoder = INVALID_TRANSCODER;
> crtc_state->hsw_workaround_pipe = INVALID_PIPE;
> crtc_state->scaler_state.scaler_id = -1;
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 6a3a2feb3dff1f2fbdf2a6e63d8d7317c7d6ead6..161cd1f6b8266e882eb1fd128b403cba350be3d2 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -38,11 +38,11 @@ struct drm_connector_state;
> struct drm_private_obj;
> struct drm_private_state;
> struct drm_modeset_acquire_ctx;
> struct drm_device;
>
> -void __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *state,
> +void __drm_atomic_helper_crtc_state_init(struct drm_crtc_state *state,
> struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Thomas Zimmermann @ 2026-04-21 13:24 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-11-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index f1fc2edc6e6e35fbac5ef82437f3cb7485afc412..8ed8cb8a9048e8fd89fa22d20985c84af1672135 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -515,24 +515,24 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> kfree(state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
>
> /**
> - * __drm_atomic_helper_connector_state_reset - reset the connector state
> + * __drm_atomic_helper_connector_state_init - Initializes the connector state
> * @conn_state: atomic connector state, must not be NULL
> * @connector: connectotr object, must not be NULL
> *
> * Initializes the newly allocated @conn_state with default
> * values. This is useful for drivers that subclass the connector state.
> */
> void
> -__drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
> - struct drm_connector *connector)
> +__drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
> + struct drm_connector *connector)
> {
> conn_state->connector = connector;
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_state_init);
>
> /**
> * __drm_atomic_helper_connector_reset - reset state on connector
> * @connector: drm connector
> * @conn_state: connector state to assign
> @@ -547,11 +547,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
> void
> __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> struct drm_connector_state *conn_state)
> {
> if (conn_state)
> - __drm_atomic_helper_connector_state_reset(conn_state, connector);
> + __drm_atomic_helper_connector_state_init(conn_state, connector);
>
> connector->state = conn_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_reset);
>
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index bc83094dfb78f0f3699ca7956a8a666ca09b2d1a..259a39a0f41ddb2b7d6c1fe7c1a2b0b51774254c 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -72,11 +72,11 @@ struct drm_plane_state *
> drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane);
> void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state);
> void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
>
> -void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
> +void __drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
> struct drm_connector *connector);
> void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> struct drm_connector_state *conn_state);
> void drm_atomic_helper_connector_reset(struct drm_connector *connector);
> void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [RFC PATCH 1/4] security: ima: move ima_init into late_initcall_sync
From: Mimi Zohar @ 2026-04-21 13:26 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <aedyh61iTnQRyzMv@e129823.arm.com>
On Tue, 2026-04-21 at 13:50 +0100, Yeoreum Yun wrote:
> Hi Mimi,
>
> > On Fri, 2026-04-17 at 18:57 +0100, Yeoreum Yun wrote:
> > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > the TPM driver must be built as built-in and
> > > must be probed before the IMA subsystem is initialized.
> > >
> > > However, when the TPM device operates over the FF-A protocol using
> > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > interface to the tpm_crb driver — has not yet been probed.
> > >
> > > To ensure the TPM device operating over the FF-A protocol with
> > > the CRB interface is probed before IMA initialization,
> > > the following conditions must be met:
> > >
> > > 1. The corresponding ffa_device must be registered,
> > > which is done via ffa_init().
> > >
> > > 2. The tpm_crb_driver must successfully probe this device via
> > > tpm_crb_ffa_init().
> > >
> > > 3. The tpm_crb driver using CRB over FF-A can then
> > > be probed successfully. (See crb_acpi_add() and
> > > tpm_crb_ffa_init() for reference.)
> > >
> > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > >
> > > When this occurs, probing the TPM device is deferred.
> > > However, the deferred probe can happen after the IMA subsystem
> > > has already been initialized, since IMA initialization is performed
> > > during late_initcall, and deferred_probe_initcall() is performed
> > > at the same level.
> > >
> > > To resolve this, move ima_init() into late_inicall_sync level
> > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > log though TPM device presents in the system.
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> >
> > IMA should be initialized as early as possible. I'm really hesitant to defer
> > ima_init() to late_initcall_sync() for systems that the TPM is currently
> > initialized in time. For these systems, continue initializing IMA at
> > late_initcall(). As a compromise for those systems that the TPM isn't properly
> > initialized in time, define and instantiate the late_initcall_sync().
> >
> > ima_init() would need to differentiate between the late_initcall and
> > late_initcall_sync. On late_initcall(), instead of saying "No TPM chip found,
> > activating TPM-bypass!", it should say "No TPM chip found, deferring to
> > late_initcall_sync" or something similar.
>
> But can we really move those initialisations to be called again?
>
> I am referring to functions such as ima_init_crypto(),
> ima_add_boot_aggregate(), and ima_measure_critical_data() in ima_init()—
> first without TPM, and then a second time once TPM becomes available.
> I don’t think that approach would work.
>
> In other words, unless tpm_default_chip() can differentiate between a TPM
> device that is deferred and one that does not exist, we cannot distinguish
> between the “defer” case and “-EEXIST”.
>
> It might be possible if the TPM core tracked the state when a driver returns
> -EPROBE_DEFER, but I am not sure that is the right approach.
> For deferred probe cases, the “device initialised in time” check should
> likely be done at late_initcall_sync, rather than late_initcall.
>
> This implies that any such check performed before late_initcall_sync
> does not reflect a valid state, as it cannot distinguish between “not
> present” and “deferred”.
>
> Therefore, I think the TPM check in IMA should be performed at
> late_initcall_sync.
>
>
> Am I missing something?
In ima_init() you short circuit out, when called by late_initcall(), if the TPM
hasn't been initialized. So the rest of the ima_init() isn't called. Roughly
something like this (needs some cleanup):
int __init ima_init(void)
{
static int first = 1;
int rc;
if (ima_tpm_chip)
return 0;
ima_tpm_chip = tpm_default_chip();
if (!ima_tpm_chip && first) {
pr_info("No TPM chip found, deferring te late_initcall_sync()\n");
first = 0;
return 0;
}
The rest of the code remains the same.
Mimi
^ permalink raw reply
* Re: [PATCH v2 12/20] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Thomas Zimmermann @ 2026-04-21 13:26 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-12-c63f1134e76c@kernel.org>
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> __drm_atomic_helper_connector_hdmi_reset() is typically used to
> initialize a newly allocated drm_connector_state when the connector is
> using the HDMI helpers, and is being called by the
> drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_hdmi_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_hdmi_reset() to
> __drm_atomic_helper_connector_hdmi_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++++++++------
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 ++--
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
> index f686aa5c0ed9b84dbe5e0957df22d08aff2f1945..929f06b290626d2091418a6377a5230e3c264b60 100644
> --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> @@ -270,12 +270,12 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> drm_atomic_helper_connector_reset(connector);
> if (bridge_connector->bridge_hdmi)
> - __drm_atomic_helper_connector_hdmi_reset(connector,
> - connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector,
> + connector->state);
> }
>
> static const struct drm_connector_funcs drm_bridge_connector_funcs = {
> .reset = drm_bridge_connector_reset,
> .detect = drm_bridge_connector_detect,
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index a1d16762ac7a9ebdc48f081c5d2f5e200d406099..cdd6df37c04a4b2073004ea08a3f5283a56692df 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -304,29 +304,31 @@
> * --kunitconfig=drivers/gpu/drm/tests \
> * drm_atomic_helper_connector_hdmi_*
> */
>
> /**
> - * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
> + * __drm_atomic_helper_connector_hdmi_state_init() - Initializes all HDMI @drm_connector_state resources
> * @connector: DRM connector
> * @new_conn_state: connector state to reset
> *
> * Initializes all HDMI resources from a @drm_connector_state without
> * actually allocating it. This is useful for HDMI drivers, in
> - * combination with __drm_atomic_helper_connector_reset() or
> - * drm_atomic_helper_connector_reset().
> + * combination with __drm_atomic_helper_connector_reset(),
> + * drm_atomic_helper_connector_reset(),
> + * __drm_atomic_helper_connector_create_state() or
> + * drm_atomic_helper_connector_create_state() .
> */
> -void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state)
> +void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state)
> {
> unsigned int max_bpc = connector->max_bpc;
>
> new_conn_state->max_bpc = max_bpc;
> new_conn_state->max_requested_bpc = max_bpc;
> new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_state_init);
>
> static const struct drm_display_mode *
> connector_state_get_mode(const struct drm_connector_state *conn_state)
> {
> struct drm_atomic_state *state;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index a50f260c73e41493528e545591aaad0e3f138be2..0ebebb04e68fab5b7938a604f85ad9b756fe33f6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -283,11 +283,11 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
> }
>
> static void sun4i_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> }
>
> static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
> .detect = sun4i_hdmi_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> index 4bdcea3c7435146aebb1716f38d7302ddb7c6296..aaa73b75f3ce5010147f48afc365d074bb2ec7a7 100644
> --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> @@ -166,11 +166,11 @@ static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
> };
>
> static void dummy_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> }
>
> static const struct drm_connector_funcs dummy_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 9898e5451a07a1dca809fb6db3fec59d07485b95..f59d0877a5f48bed6b421775da7ddd008d68f9d9 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -506,11 +506,11 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
> }
>
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> drm_atomic_helper_connector_tv_margins_reset(connector);
> }
>
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> .force = drm_atomic_helper_connector_hdmi_force,
> diff --git a/include/drm/display/drm_hdmi_state_helper.h b/include/drm/display/drm_hdmi_state_helper.h
> index 2349c0d0f00fb468167023d4db2055c70e603bcd..f7600aabdd5f066772a9a82a1fa8a00be7a48396 100644
> --- a/include/drm/display/drm_hdmi_state_helper.h
> +++ b/include/drm/display/drm_hdmi_state_helper.h
> @@ -9,12 +9,12 @@ struct drm_connector_state;
> struct drm_display_mode;
> struct hdmi_audio_infoframe;
>
> enum drm_connector_status;
>
> -void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state);
> +void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state);
>
> int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
> struct drm_atomic_state *state);
>
> int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v5 07/12] coresight: etm4x: fix inconsistencies with sysfs configuration
From: Leo Yan @ 2026-04-21 13:28 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <aedcDEpBAnAieSRX@e129823.arm.com>
On Tue, Apr 21, 2026 at 12:14:20PM +0100, Yeoreum Yun wrote:
[...]
> > > - There is a risk of corrupting drvdata->config if a perf session enables
> > > tracing while cscfg_csdev_disable_active_config() is being handled in
> > > etm4_disable_sysfs().
> >
> > Similiar to above, cscfg_csdev_disable_active_config() is not
> > protected in etm4_disable_sysfs().
>
> This is not true.
> at the time of etm4_disable_sysfs() "mode" is already taken
> (whether sysfs or perf). In this situation, it's enough to
> call cscfg_csdev_disable_active_config() before chaning
> mode to DISABLED.
To be clear, I am trying to understand issue _before_ your patch.
Without this patch, cscfg_csdev_disable_active_config() is not
protected by the mode.
> > > struct etm4_enable_arg {
> > > struct etmv4_drvdata *drvdata;
> > > + struct etmv4_config config;
> >
> > We don't need this. We can defer to get drvdata->config in SMP call.
>
> This is not true ane make a situation more complex.
> If we get config in SMP call, that would be a problem when some user is
> trying to modify config.
>
> IOW, while user modifying config via sysfs, and SMP call happens,
> it makes a dead lock. so for this if we try to grab the lock in SMP call,
> we should change every sysfs raw_spin_lock() into raw_spin_lock_irqsave().
>
> Instead of this it would be much clear and simpler to get config in here
> rather than to add some latencies via sysfs.
Thanks for info. If so, it is fine for me to add "config".
> > > @@ -1386,6 +1401,7 @@ static void etm4_init_arch_data(void *info)
> > > drvdata = dev_get_drvdata(init_arg->dev);
> > > caps = &drvdata->caps;
> > > csa = init_arg->csa;
> > > + config = &drvdata->active_config;
> >
> > Should we init drvdata->config instead so make it has sane values ?
> >
> > In other words, drvdata->active_config are always set at the runtime,
> > so don't need to init it at all, right?
>
> No. at least when the initialise, I think we should fill the its
> contesnt with the "etm4_set_default()".
>
> That's why the consequence call etm4_set_default() called with
> active_config and config is coped with the default configutation.
I'm concerned that some config fields may be reused across sessions.
For example, a sysfs session copies drvdata->config into
drvdata->active_config, and later a perf session may reuse stale
values. The same issue can happen in the reverse direction.
A clean approach would be to treat drvdata->active_config as
per-session state:
1) clear drvdata->active_config at session start
2) apply the session-specific config
2.1) sysfs: use drvdata->config
2.2) perf: use event config
3) then apply configfs configuration
So we should clear drvdata->active_config at the start of each session
and rebuild it with the correct configuration.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Thomas Zimmermann @ 2026-04-21 13:38 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-15-c63f1134e76c@kernel.org>
Hi
Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> Almost all drivers, and our documented skeleton, call
> drm_mode_config_reset() prior to calling drm_dev_register() to
> initialize its DRM object states.
>
> Now that we have drm_mode_config_create_state() to create that initial
> state if it doesn't exist, we can call it directly in
> drm_dev_register(). That way, we know that the initial atomic state will
> always be allocated without any boilerplate.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_drv.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> ret = drm_modeset_register_all(dev);
> if (ret)
> goto err_unload;
> +
> + ret = drm_mode_config_create_state(dev);
> + if (ret)
> + goto err_unload;
Way too late. Lets rather go through drivers and call this where they
currently call drm_mode_config_reset() for initialization. This can be a
single-patch mass conversion IMHO.
Best regards
Thomas
> }
> drm_panic_register(dev);
> drm_client_sysrq_register(dev);
>
> DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 03/20] drm/mode-config: Mention drm_mode_config_reset() culprits
From: Thomas Zimmermann @ 2026-04-21 13:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, David Airlie, Simona Vetter, Jonathan Corbet,
Shuah Khan, Dmitry Baryshkov, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260421-satisfied-teal-serval-640ded@houat>
Hi
Am 21.04.26 um 15:18 schrieb Maxime Ripard:
> Hi Thomas,
>
> On Tue, Apr 21, 2026 at 03:08:03PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
>>> drm_mode_config_reset() does not reset drm_private_states by design.
>>>
>>> This is especially significant for the DP MST and tunneling code that
>>> expect to be preserved across a suspend/resume cycle, where
>>> drm_mode_config_reset() is also used.
>> Do we really? There's drm_mode_config_helper_suspend/resume(). Why would
>> drivers do a drm_mode_config_reset().
> drm_mode_config_helper_resume() will call drm_atomic_helper_resume()
> that call drm_mode_config_reset(). So (most) drivers will not directly
> call it, but it is going to be called still.
I see, thanks. I guess you're right when you say that
drm_mode_config_reset() is overloaded. LOL.
Best regards
Thomas
>
> Maxime
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 2/2] gpio: xilinx: drop bitmap_complement() where feasible
From: Michal Simek @ 2026-04-21 13:44 UTC (permalink / raw)
To: Yury Norov, Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Yury Norov, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260417175955.375275-3-ynorov@nvidia.com>
On 4/17/26 19:59, Yury Norov wrote:
> [Some people who received this message don't often get email from ynorov@nvidia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> The drivers reproduces the following pattern:
The driver reproduce
With that fix
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Rob Herring @ 2026-04-21 13:49 UTC (permalink / raw)
To: Kevin Hilman (TI)
Cc: Ulf Hansson, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <20260420-topic-lpm-pmdomain-child-ids-v3-1-c2c40bef238c@baylibre.com>
On Mon, Apr 20, 2026 at 04:51:17PM -0700, Kevin Hilman (TI) wrote:
> Add binding documentation for the new power-domains-child-ids property,
> which works in conjunction with the existing power-domains property to
> establish parent-child relationships between a multi-domain power domain
> provider and external parent domains.
>
> Each element in the uint32 array identifies the child domain
> ID (index) within the provider that should be made a child domain of
> the corresponding phandle entry in power-domains. The two arrays must
> have the same number of elements.
>
> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
Missing my Reviewed-by.
^ permalink raw reply
* [GIT PULL] amlogic ARM64 DT fixes for v7.1-rc
From: Neil Armstrong @ 2026-04-21 13:52 UTC (permalink / raw)
To: soc, arm; +Cc: linux-amlogic, linux-arm-kernel
Hi,
Here's the Amlogic ARM64 DT fixes for v7.1-rc, including a bunch of fixes
for the Khadas VIM4 and a couple of low priority fixes.
Thanks,
Neil
The following changes since commit 028ef9c96e96197026887c0f092424679298aae8:
Linux 7.0 (2026-04-12 13:48:06 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git tags/amlogic-fixes-v7.1-rc
for you to fetch changes up to 174a0ef3b33434f475c87e66f37980e39b73805a:
arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number (2026-04-21 15:46:29 +0200)
----------------------------------------------------------------
Amlogic DT Fixes for v7.1:
- Fix ethernet PHY interrupt number for P230 reference board
- Add missing cache information to cpu0 for Amlogic AXG
- Fix Khadas VIM4 board model name
- Fix GIC register ranges for Amlogic T7
- Fix Khadas VIM4 memory layout for 8GB RAM
- Drop CPU masks from GICv3 PPI interrupts for Amlogic S6
----------------------------------------------------------------
Anand Moon (1):
arm64: dts: amlogic: meson-axg: Add missing cache information to cpu0
Geert Uytterhoeven (1):
arm64: dts: amlogic: s6: Drop CPU masks from GICv3 PPI interrupts
Jun Yan (1):
arm64: dts: meson-gxl-p230: fix ethernet PHY interrupt number
Nick Xie (2):
arm64: dts: amlogic: t7: khadas-vim4: fix memory layout for 8GB RAM
arm64: dts: amlogic: t7: khadas-vim4: fix board model name
Ronald Claveau (1):
arm64: dts: amlogic: Fix GIC register ranges for Amlogic T7
arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi | 10 +++++-----
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 6 ++++--
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 4 +++-
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 3 ++-
5 files changed, 20 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: gpio: zynq: Sort compatible strings alphabetically
From: Rob Herring @ 2026-04-21 13:52 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260421104358.2496125-2-shubhrajyoti.datta@amd.com>
On Tue, Apr 21, 2026 at 04:13:56PM +0530, Shubhrajyoti Datta wrote:
> Sort the compatible string alphabetically.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Missing Conor's ack.
^ permalink raw reply
* [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Jiahao zheng @ 2026-04-21 13:51 UTC (permalink / raw)
To: steven.price
Cc: alexandru.elisei, alpergun, aneesh.kumar, catalin.marinas,
christoffer.dall, fj0570is, gankulkarni, gshan, james.morse,
joey.gouly, kvm, kvmarm, linux-arm-kernel, linux-coco,
linux-kernel, maz, oliver.upton, sdonthineni, suzuki.poulose,
tabba, vannapurve, will, yuzenghui
In-Reply-To: <20260318155413.793430-1-steven.price@arm.com>
Hi Steven,
I've been testing CCA patch series and noticed Realm VM cannot boot successfully when the host is forced to run in nVHE mode (e.g., via `kvm-arm.mode=nvhe`). The kvmtool debug information will be truncated in set_guest_bank_private_gpa.
Currently, in `kvm_ioctl_vcpu_run()`, running a Realm VM (REC) bypasses the standard nVHE EL2 stub. `kvm_rec_enter()` directly executes the SMC instruction to transition to the RMM. Upon returning to the EL1 host, the code falls back to `kvm_vgic_sync_hwstate()`, where the VGIC save operation is explicitly skipped for nVHE. Since the EL2 stub was bypassed, `__vgic_v3_save_state()` is never executed, and `ICH_*_EL2` states are lost.
To resolve this, I have a couple of thoughts:
1. If Host nVHE mode is not intended to be supported for Realms:
Since RME implies ARMv9 which mandates VHE, running a Realm with an nVHE host might just be an unsupported edge case. If so, we should explicitly reject RME initialization or REC creation when `!is_kernel_in_hyp_mode()`. This would cleanly prevent the undefined behavior.
2. If Host nVHE mode is intended to be supported:
Since RMM should remain agnostic to the Non-Secure VGIC states, the burden of saving these states falls strictly on KVM. However, the EL1 host cannot access `ICH_*_EL2`. Therefore, KVM needs to add specific logic for this scenario. We would likely need to route the REC exit through a dedicated nVHE EL2 stub to invoke `__vgic_v3_save_state()` before dropping back to EL1, rather than jumping straight back to `kvm_ioctl_vcpu_run()`.
I might have missed some documentation or comments regarding nVHE restrictions for CCA. If this is an oversight, it would be great to see a check added in the next iteration of the series.
Thanks,
Zheng
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf, arm64: Add JIT support for stack arguments
From: Alexei Starovoitov @ 2026-04-21 13:53 UTC (permalink / raw)
To: Puranjay Mohan
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Xu Kuohai, Catalin Marinas, Will Deacon,
linux-arm-kernel
In-Reply-To: <CANk7y0gNqm7U_0Kc6ZP9jd19gHKScOaTVDa4yxkxTVDonM0iUA@mail.gmail.com>
On Tue, Apr 21, 2026 at 4:53 AM Puranjay Mohan <puranjay12@gmail.com> wrote:
>
> On Tue, Apr 21, 2026 at 3:58 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Mon, Apr 20, 2026 at 8:36 AM Puranjay Mohan <puranjay@kernel.org> wrote:
> > >
> >
> > nice and clean. I like how it maps to arm64 calling convention.
> >
> > > + if (prog->aux->stack_arg_depth > prog->aux->incoming_stack_arg_depth) {
> > > + u16 outgoing = prog->aux->stack_arg_depth - prog->aux->incoming_stack_arg_depth;
> > > + int nr_on_stack = outgoing / sizeof(u64) - NR_STACK_ARG_REGS;
> > > +
> > > + if (nr_on_stack > 0)
> > > + ctx.stack_arg_size = round_up(nr_on_stack * sizeof(u64), 16);
> > > + }
> >
> > I'm struggling to understand this part.
> > Why do this when this func calls more than what callee passed in?
> > Looks fishy. I'd like to see selftests with more than 6,7,8 args.
> > Because only then this logic will kick in?
>
> Your confusion stems from the naming of "incoming_stack_arg_depth" and
> "stack_arg_depth" (this should be called total_stack_arg_depth in my
> opinion)
>
> So, if you see fixups.c
>
> func[i]->aux->incoming_stack_arg_depth =
> env->subprog_info[i].incoming_stack_arg_depth;
> func[i]->aux->stack_arg_depth =
> env->subprog_info[i].incoming_stack_arg_depth +
>
> env->subprog_info[i].outgoing_stack_arg_depth;
>
> prog->aux->stack_arg_depth doesn't store outgoing stack depth, rather
> it has the sum of both incoming and outgoing, that means if a func
> doesn't call any function with more than 5 arguments but receives more
> than five arguments, incoming_stack_arg_depth will be equal to
> stack_arg_depth.
Ohh. That's indeed all too confusing.
See my response to Yonghong.
I think stack_arg_depth should mean outgoing
and incoming_stack_arg_depth should mean incoming only and
it shouldn't be even used by JIT.
That memory was allocated by caller, so to JIT this callee
the conversion of r11+const is straightforward and no checks necessary.
> if (prog->aux->stack_arg_depth > prog->aux->incoming_stack_arg_depth)
>
> This check is for - "Does this function call any function with more
> than 5 arguments", if yes, is it more than 8? if yes allocate stack
> space, otherwise stack space is not needed because argument 6,7,8 can
> live in arm64 registers.
I think it should really be one check based on stack_arg_depth.
^ permalink raw reply
* Re: [PATCH v5 07/12] coresight: etm4x: fix inconsistencies with sysfs configuration
From: Yeoreum Yun @ 2026-04-21 14:02 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260421132842.GC929984@e132581.arm.com>
Hi Leo,
> On Tue, Apr 21, 2026 at 12:14:20PM +0100, Yeoreum Yun wrote:
>
> [...]
>
> > > > - There is a risk of corrupting drvdata->config if a perf session enables
> > > > tracing while cscfg_csdev_disable_active_config() is being handled in
> > > > etm4_disable_sysfs().
> > >
> > > Similiar to above, cscfg_csdev_disable_active_config() is not
> > > protected in etm4_disable_sysfs().
> >
> > This is not true.
> > at the time of etm4_disable_sysfs() "mode" is already taken
> > (whether sysfs or perf). In this situation, it's enough to
> > call cscfg_csdev_disable_active_config() before chaning
> > mode to DISABLED.
>
> To be clear, I am trying to understand issue _before_ your patch.
> Without this patch, cscfg_csdev_disable_active_config() is not
> protected by the mode.
Right.
[...]
> > > > @@ -1386,6 +1401,7 @@ static void etm4_init_arch_data(void *info)
> > > > drvdata = dev_get_drvdata(init_arg->dev);
> > > > caps = &drvdata->caps;
> > > > csa = init_arg->csa;
> > > > + config = &drvdata->active_config;
> > >
> > > Should we init drvdata->config instead so make it has sane values ?
> > >
> > > In other words, drvdata->active_config are always set at the runtime,
> > > so don't need to init it at all, right?
> >
> > No. at least when the initialise, I think we should fill the its
> > contesnt with the "etm4_set_default()".
> >
> > That's why the consequence call etm4_set_default() called with
> > active_config and config is coped with the default configutation.
>
> I'm concerned that some config fields may be reused across sessions.
> For example, a sysfs session copies drvdata->config into
> drvdata->active_config, and later a perf session may reuse stale
> values. The same issue can happen in the reverse direction.
>
> A clean approach would be to treat drvdata->active_config as
> per-session state:
>
> 1) clear drvdata->active_config at session start
> 2) apply the session-specific config
> 2.1) sysfs: use drvdata->config
> 2.2) perf: use event config
> 3) then apply configfs configuration
This is not true.
In case of "perf", it always clear the "active_config" with 0x00
before enable. so it wouldn't.
In case of sysfs we don't need to worries about since
"config" field saves everything and this is applied into active_config.
So, your issue doesn't exist in this case.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Michal Piekos @ 2026-04-21 14:05 UTC (permalink / raw)
To: Andre Przywara
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <b89c1c8b-2678-4f4f-a63c-03b92cf7617c@arm.com>
On Mon, Apr 20, 2026 at 04:14:44PM +0200, Andre Przywara wrote:
> Hi Michal,
>
> On 4/20/26 13:27, Michal Piekos wrote:
> > On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
> > > On Sun, 19 Apr 2026 14:46:06 +0200
> > > Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> > >
> > > Hi Michal,
> > >
> > > > Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> > > > and describe corresponding nodes in dts for H616 and T113-S3.
> > > >
> > > > H616 uses same model as existing driver except register shift compared
> > > > to older variants.
> > > >
> > > > Added register layout abstraction in the driver, extended the binding
> > > > with new compatibles and wired up dts nodes for H616 and T113-S3 which
> > > > uses H616 as fallback compatible.
> > >
> > > Can you say *why* we need this? IIUC Linux only ever uses one clock
> > > source, and selects the (non-optional) Generic Timer (aka arch timer)
> > > for that? So can you say what this hstimer clock source adds? I guess
> > > higher resolution, but what is your use case, so why would you need the
> > > 200 MHz? And does this offset the higher access cost of an MMIO
> > > access, compared to the arch timer's sysreg based access? Also, IIUC,
> > > people would need to manually select this as the clocksource, why and
> > > when would they do so? (Given they even know about it in the first
> > > place).
> > > Also the hstimer hasn't been used since the A20, so nobody seemed to
> > > have missed it meanwhile?
> > >
> > > Cheers,
> > > Andre
> > >
> > I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
> > a todo list and wanted to help with it. I do not have own use case for
> > this timer. If it is not needed then I will spin v2 to include your
> > comments and abandon it.
>
> Ah, that's good to know, and thanks for picking things from that list! I
> don't think there is a particular need to abandon your work, we could as
> well upstream it. At least the DT changes should be added, so that other DT
> users could make use of the timers - after all it's a Linux implementation
> choice to utilise just one timer. But please go ahead and post a complete
> v2, I don't think it hurts to have HSTIMER support in the kernel.
> And while you are at it: can you figure out what the need is for using two
> timers? One is a clock source, the other is for clock events? And why do we
> limit the counters and timers to 32 bit? Even the A13 manual lists them as
> 56 bits, and a wraparound time of roughly 21 seconds (with 32 bit counters)
> does not sound very long to me.
>
Yes. Channel 0 is clockevent and channel 1 is a clocksource and sync
reference for channel 0 disable timing.
32 bit counters seems like implementation choice rather than limitation
but that would need to be implemented and tested. Would you suggest to
extend it to 56 bit in the following patch?
>
> Not sure what your primary motivation for fixing Allwinner support is, but
> we could probably find more worthwhile targets. Do you have Allwinner boards
> other than the OrangePi Zero 3? There are not many low hanging fruits on the
> H616 left (MBUS and LDOs(?) maybe), but the A523 has quite some missing
> drivers still, some of them probably more on the easy side.
>
I have boards with A733, A527, T113-S3, H616, H6, H3 and I
think some older stuff too. My motivation is mostly fun and learning.
I also use those boards in custom projects.
I will take up GPADC on A527 after finishing this as I worked with ADC's
a lot on MCU's. Unless other suggestions?
Thank you for comments.
Michal
> If you are stuck with the OpiZero3, then you could just look and check the
> existing devices, and verify their operation. For instance I think USB-OTG
> is still broken - across most Allwinner SoCs actually, so it's a sunxi
> driver issue.
>
> Thanks,
> Andre
>
> >
> > Michal
> >
> > > >
> > > > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > > > ---
> > > > Michal Piekos (4):
> > > > dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> > > > clocksource/drivers/sun5i: add H616 hstimer support
> > > > arm64: dts: allwinner: h616: add hstimer node
> > > > arm: dts: allwinner: t113s: add hstimer node
> > > >
> > > > .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
> > > > arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
> > > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
> > > > drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
> > > > 4 files changed, 78 insertions(+), 7 deletions(-)
> > > > ---
> > > > base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> > > > change-id: 20260413-h616-t113s-hstimer-62939948f91c
> > > >
> > > > Best regards,
> > >
> > >
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-04-21 14:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326111803.1248934-2-alexander.stein@ew.tq-group.com>
Hi,
Am Donnerstag, 26. März 2026, 12:03:30 CEST schrieb Alexander Stein:
> From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
>
> This adds support for TQMa95xxLA modules, designed to be soldered
> on a carrier board. MBa95xxCA is a carrier reference board / starter kit
> design.
>
> There is a common device tree for all variants with e.g. reduced
> CPU core / feature count.
>
> Enable the external accessible PCIe controllers as host,
> add clocking and reset GPIO. While at it, add hogs for GPIO
> lines from the M.2 slots until M.2 connector driver is available.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Any feedback on this? Patch 1 is already picked in commit d44627c13049e
("dt-bindings: arm: add bindings for TQMa95xxLA")
Thank and best regards,
Alexander
> ---
> Changes in v2:
> * removed useless regulator
> * added USB PD source configuration
> * Removed unused uart-has-rtscts properties (unused by LPUART)
> * Fixed RTS/CTS pullups in pinctrl
> * Added thermalzone on module
>
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../freescale/imx95-tqma9596la-mba95xxca.dts | 947 ++++++++++++++++++
> .../boot/dts/freescale/imx95-tqma9596la.dtsi | 297 ++++++
> 3 files changed, 1245 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 2879d567dede0..df79e56771319 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -554,6 +554,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> new file mode 100644
> index 0000000000000..f75580bb91e3e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
> @@ -0,0 +1,947 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Alexander Stein
> + * Author: Markus Niebel
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/net/ti-dp83867.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/usb/pd.h>
> +#include "imx95-tqma9596la.dtsi"
> +
> +/ {
> + model = "TQ-Systems i.MX95 TQMa95xxLA on MBa95xxCA";
> + compatible = "tq,imx95-tqma9596la-mba95xxca", "tq,imx95-tqma9596la", "fsl,imx95";
> + chassis-type = "embedded";
> +
> + aliases {
> + ethernet0 = &enetc_port0;
> + ethernet1 = &enetc_port1;
> + ethernet2 = &enetc_port2;
> + gpio0 = &gpio1;
> + gpio1 = &gpio2;
> + gpio2 = &gpio3;
> + gpio3 = &gpio4;
> + i2c0 = &lpi2c1;
> + i2c1 = &lpi2c2;
> + i2c2 = &lpi2c3;
> + i2c3 = &lpi2c4;
> + i2c4 = &lpi2c5;
> + i2c5 = &lpi2c6;
> + i2c6 = &lpi2c7;
> + i2c7 = &lpi2c8;
> + mmc0 = &usdhc1;
> + mmc1 = &usdhc2;
> + rtc0 = &pcf85063;
> + rtc1 = &scmi_bbm;
> + serial0 = &lpuart1;
> + serial1 = &lpuart2;
> + serial2 = &lpuart3;
> + serial3 = &lpuart4;
> + serial4 = &lpuart5;
> + serial5 = &lpuart6;
> + serial6 = &lpuart7;
> + serial7 = &lpuart8;
> + spi0 = &flexspi1;
> + };
> +
> + chosen {
> + stdout-path = &lpuart1;
> + };
> +
> + backlight_lvds: backlight-lvds {
> + compatible = "pwm-backlight";
> + pwms = <&tpm5 2 100000 0>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <7>;
> + enable-gpios = <&expander2 6 GPIO_ACTIVE_HIGH>;
> + power-supply = <®_12v0>;
> + status = "disabled";
> + };
> +
> + clk_eth: clk-eth {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <156250000>;
> + };
> +
> + /*
> + * TODO: gate is disabled for now and GPIO are hogged
> + * ENETC driver switches the clock far too late for ENETC2 + SFP
> + */
> + clk_eth_gate: clk-eth-gate {
> + compatible = "gpio-gate-clock";
> + enable-gpios = <&expander2 0 GPIO_ACTIVE_HIGH>;
> + clocks = <&clk_eth>;
> + #clock-cells = <0>;
> + status = "disabled";
> + };
> +
> + clk_xtal25: clk-xtal25 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + button-b {
> + label = "BUTTON_B#";
> + linux,code = <BTN_1>;
> + gpios = <&expander1 0 GPIO_ACTIVE_LOW>;
> + wakeup-source;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_STATUS;
> + gpios = <&expander2 13 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> +
> + led-2 {
> + color = <LED_COLOR_ID_AMBER>;
> + function = LED_FUNCTION_HEARTBEAT;
> + gpios = <&expander2 14 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
> + <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
> + };
> +
> + reg_v1v8_mb: regulator-v1v8-mb {
> + compatible = "regulator-fixed";
> + regulator-name = "V_1V8_MB";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_v3v3_mb: regulator-v3v3-mb {
> + compatible = "regulator-fixed";
> + regulator-name = "V_3V3_MB";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_3v3a_10g: regulator-3v3a-10g {
> + compatible = "regulator-fixed";
> + regulator-name = "3V3A_10G";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&expander2 15 GPIO_ACTIVE_HIGH>;
> + startup-delay-us = <2000>;
> + enable-active-high;
> + };
> +
> + reg_12v0: regulator-12v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "12V0";
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + gpio = <&expander1 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_pwm_fan: regulator-pwm-fan {
> + compatible = "regulator-fixed";
> + regulator-name = "FAN_PWR";
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + gpio = <&expander3 15 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <®_12v0>;
> + };
> +
> + reg_lvds: regulator-lvds {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_PWR_EN";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&expander2 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + /* USB NC limitations, RM 162.1.2 VBUS limitations */
> + reg_vbus_usb3: regulator-vbus-usb3 {
> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-name = "USB3_VBUS";
> + gpio = <&gpio4 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + sfp_xfi: sfp-xfi {
> + compatible = "sff,sfp";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sfp>;
> + i2c-bus = <&lpi2c7>;
> + maximum-power-milliwatt = <2000>;
> + mod-def0-gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
> + tx-fault-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
> + los-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>;
> + tx-disable-gpios = <&expander2 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + sound {
> + compatible = "fsl,imx-audio-tlv320aic32x4";
> + model = "tqm-tlv320aic32";
> + audio-codec = <&tlv320aic3x04>;
> + audio-cpu = <&sai3>;
> + audio-routing =
> + "IN3_L", "Mic Jack",
> + "Mic Jack", "Mic Bias",
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "IN1_L", "Line In Jack",
> + "IN1_R", "Line In Jack",
> + "Line Out Jack", "LOL",
> + "Line Out Jack", "LOR";
> + };
> +};
> +
> +&adc1 {
> + status = "okay";
> +};
> +
> +&enetc_port0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enetc0>;
> + phy-handle = <ðphy0>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> +};
> +
> +&enetc_port1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enetc1>;
> + phy-handle = <ðphy1>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> +};
> +
> +/* No support for XFI yet */
> +&enetc_port2 {
> + sfp = <&sfp_xfi>;
> + phy-mode = "10gbase-r";
> + clocks = <&clk_eth>;
> + clock-names = "enet_ref_clk";
> + managed = "in-band-status";
> + status = "disabled";
> +};
> +
> +&flexcan1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "okay";
> +};
> +
> +&flexcan2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "okay";
> +};
> +
> +&lpi2c2 {
> + tlv320aic3x04: audio-codec@18 {
> + compatible = "ti,tlv320aic32x4";
> + reg = <0x18>;
> + clocks = <&scmi_clk IMX95_CLK_SAI3>;
> + clock-names = "mclk";
> + reset-gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
> + iov-supply = <®_v3v3_mb>;
> + ldoin-supply = <®_v3v3_mb>;
> + };
> +
> + fan_controller: fan-controller@2f {
> + compatible = "microchip,emc2301", "microchip,emc2305";
> + reg = <0x2f>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #pwm-cells = <3>;
> + status = "okay";
> +
> + fan: fan@0 {
> + reg = <0x0>;
> + pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED 1>;
> + #cooling-cells = <2>;
> + fan-supply = <®_pwm_fan>;
> + };
> + };
> +
> + ptn5110: usb-typec@50 {
> + compatible = "nxp,ptn5110", "tcpci";
> + reg = <0x50>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_typec>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> +
> + typec_con: connector {
> + compatible = "usb-c-connector";
> + label = "X9";
> + power-role = "source";
> + data-role = "dual";
> + source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
> + self-powered;
> +
> + port {
> + typec_con_hs: endpoint {
> + remote-endpoint = <&typec_hs>;
> + };
> + };
> + };
> + };
> +
> + sensor_mb: temperature-sensor@1e {
> + compatible = "nxp,se97b", "jedec,jc-42.4-temp";
> + reg = <0x1e>;
> + };
> +
> + eeprom_mb: eeprom@56 {
> + compatible = "nxp,se97b", "atmel,24c02";
> + reg = <0x56>;
> + pagesize = <16>;
> + vcc-supply = <®_v3v3_mb>;
> + };
> +
> + pcieclk: clock-generator@68 {
> + compatible = "renesas,9fgv0441";
> + reg = <0x68>;
> + clocks = <&clk_xtal25>;
> + #clock-cells = <1>;
> + };
> +
> + /* D39 IN/OUT 3V3 */
> + expander1: gpio@74 {
> + compatible = "ti,tca9539";
> + reg = <0x74>;
> + vcc-supply = <®_v3v3_mb>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_expander1>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
> +
> + gpio-line-names =
> + /* 00 */ "BUTTON_B#", "CAM0_SYNC_3V3",
> + /* 02 */ "CAM1_SYNC_3V3", "SFP_MOD_ABS",
> + /* 04 */ "DIG_IN1", "DIG_IN2",
> + /* 06 */ "DIG_IN3", "DIG_IN4",
> + /* 08 */ "DIG_OUT_1_2_STATE", "DIG_OUT_3_4_STATE",
> + /* 10 */ "DIG_OUT_1_EN", "DIG_OUT_2_EN",
> + /* 12 */ "DIG_OUT_3_EN", "DIG_OUT_4_EN",
> + /* 14 */ "AUDIO_RST#", "12V_EN";
> + };
> +
> + /* D40 OUT 3V3 */
> + expander2: gpio@75 {
> + compatible = "ti,tca9539";
> + reg = <0x75>;
> + vcc-supply = <®_3v3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio-line-names =
> + /* 00 */ "ETH10G_REFCLK_EN", "ETH10G_REFCLK_RST#",
> + /* 02 */ "SFP_TX_DIS", "USB3_RESET#",
> + /* 04 */ "USB2_RESET#", "LCD_RESET#",
> + /* 06 */ "LCD_BLT_EN", "LCD_PWR_EN",
> + /* 08 */ "M2_KEYE_PERST#", "M2_KEYE_WDISABLE1#",
> + /* 10 */ "M2_KEYE_WDISABLE2#", "M2_KEYB_PERST#",
> + /* 12 */ "M2_KEYB_WDISABLE1#", "USER_LED1",
> + /* 14 */ "USER_LED2", "3V3A_10G_EN";
> +
> + eth10g-refclk-en-hog {
> + gpio-hog;
> + gpios = <0 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "ETH10G_REFCLK_EN";
> + };
> +
> + eth10g-refclk-rst-hog {
> + gpio-hog;
> + gpios = <1 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "ETH10G_REFCLK_RST#";
> + };
> +
> + m2_keye_wdisable1_hog: m2-keye-wdisable1-hog {
> + gpio-hog;
> + gpios = <9 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_WDISABLE1#";
> + };
> +
> + m2_keye_wdisable2_hog: m2-keye-wdisable2-hog {
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_WDISABLE2#";
> + };
> +
> + m2-keyb-wdisable1-hog {
> + gpio-hog;
> + gpios = <12 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_WDISABLE1#";
> + };
> + };
> +
> + /* D41 OUT 1V8 */
> + expander3: gpio@76 {
> + compatible = "ti,tca9539";
> + reg = <0x76>;
> + vcc-supply = <®_v1v8_mb>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + gpio-line-names =
> + /* 00 */ "ENET1_RESET#", "ENET2_RESET#",
> + /* 02 */ "M2_KEYE_SDIO_RST#", "M2_KEYE_DEV_WLAN_WAKE#",
> + /* 04 */ "M2_KEYE_DEV_BT_WAKE", "M2_KEYB_W_DISABLE2#",
> + /* 06 */ "M2_KEYB_RST#", "M2_KEYB_FULL_CARD_PWR_OFF#",
> + /* 08 */ "M2_KEYB_DPR", "CAM0_PWR#",
> + /* 10 */ "CAM1_PWR#", "CAM0_RST#",
> + /* 12 */ "CAM1_RST#", "CAM0_TRIGGER",
> + /* 14 */ "CAM1_TRIGGER", "FAN_PWR_EN";
> +
> + m2-keye-sdio-rst-hog {
> + gpio-hog;
> + gpios = <2 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYE_SDIO_RST#";
> + };
> +
> + m2-keye-dev_wlan-wake-hog {
> + gpio-hog;
> + gpios = <3 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "M2_KEYE_DEV_WLAN_WAKE#";
> + };
> +
> + m2-keye-dev_bt-wake-hog {
> + gpio-hog;
> + gpios = <4 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "M2_KEYE_DEV_BT_WAKE#";
> + };
> +
> + m2-keyb-wdisable2-hog {
> + gpio-hog;
> + gpios = <5 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_WDISABLE1#";
> + };
> +
> + m2-keyb-rst-hog {
> + gpio-hog;
> + gpios = <6 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_RST#";
> + };
> +
> + m2-keyb-full-card-pwr-off-hog {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_LOW>;
> + output-low;
> + line-name = "M2_KEYB_FULL_CARD_PWR_OFF#";
> + };
> + };
> +};
> +
> +/* X4 + XFP */
> +&lpi2c7 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "gpio";
> + pinctrl-0 = <&pinctrl_lpi2c7>;
> + pinctrl-1 = <&pinctrl_lpi2c7_recovery>;
> + scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + status = "okay";
> +
> + /* TODO: 0x19: retimer */
> +
> + /* 0x50 / 0x51: SFP EEPROM */
> +};
> +
> +/* X4 */
> +&lpspi4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpspi4>;
> + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, <&gpio5 14 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&lpuart1 {
> + /* console */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart1>;
> + status = "okay";
> +};
> +
> +&lpuart2 {
> + /* SM */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart2>;
> + status = "reserved";
> +};
> +
> +&lpuart5 {
> + /* X16 M.2 KEY E */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart5>;
> + status = "okay";
> +};
> +
> +&lpuart7 {
> + /* X5 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart7>;
> + status = "okay";
> +};
> +
> +&lpuart8 {
> + /* X15 */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpuart8>;
> + linux,rs485-enabled-at-boot-time;
> + status = "okay";
> +};
> +
> +&netc_blk_ctrl {
> + status = "okay";
> +};
> +
> +&netc_emdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_emdio>;
> + status = "okay";
> +
> + /* IRQ pin is AON GPIO, not usable */
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + reset-gpios = <&expander3 0 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <500000>;
> + reset-deassert-us = <50000>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,dp83867-rxctrl-strap-quirk;
> + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> + };
> +
> + ethphy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ethphy1>;
> + reset-gpios = <&expander3 1 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <500000>;
> + reset-deassert-us = <50000>;
> + interrupt-parent = <&gpio4>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
> + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,dp83867-rxctrl-strap-quirk;
> + ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
> + };
> +};
> +
> +&netc_timer {
> + status = "okay";
> +};
> +
> +&netcmix_blk_ctrl {
> + status = "okay";
> +};
> +
> +/* X16 M2 / E-Key mPCIe */
> +&pcie0 {
> + pinctrl-0 = <&pinctrl_pcie0>;
> + pinctrl-names = "default";
> + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> + <&scmi_clk IMX95_CLK_HSIOPLL>,
> + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> + <&pcieclk 1>;
> + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> + reset-gpios = <&expander2 8 GPIO_ACTIVE_LOW>;
> + /* Not supported on REV.0100 */
> + /* supports-clkreq; */
> + status = "okay";
> +};
> +
> +/* X17 M2 / B-Key PCIe */
> +&pcie1 {
> + pinctrl-0 = <&pinctrl_pcie1>;
> + pinctrl-names = "default";
> + clocks = <&scmi_clk IMX95_CLK_HSIO>,
> + <&scmi_clk IMX95_CLK_HSIOPLL>,
> + <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
> + <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
> + <&pcieclk 0>;
> + clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
> + reset-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
> + /* Not supported on REV.0100 */
> + /* supports-clkreq; */
> + status = "okay";
> +};
> +
> +®_sdvmmc {
> + status = "okay";
> +};
> +
> +&sai3 {
> + #sound-dai-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai3>;
> + assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL1>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL2>,
> + <&scmi_clk IMX95_CLK_SAI3>;
> + assigned-clock-parents = <0>, <0>, <0>, <0>,
> + <&scmi_clk IMX95_CLK_AUDIOPLL1>;
> + assigned-clock-rates = <3932160000>,
> + <3612672000>, <393216000>,
> + <361267200>, <12288000>;
> + fsl,sai-mclk-direction-output;
> + status = "okay";
> +};
> +
> +&scmi_bbm {
> + linux,code = <KEY_POWER>;
> +};
> +
> +&thermal_zones {
> + a55-thermal {
> + trips {
> + cpu_active0: trip-active0 {
> + temperature = <40000>;
> + hysteresis = <5000>;
> + type = "active";
> + };
> +
> + cpu_active1: trip-active1 {
> + temperature = <48000>;
> + hysteresis = <3000>;
> + type = "active";
> + };
> +
> + cpu_active2: trip-active2 {
> + temperature = <60000>;
> + hysteresis = <10000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <&cpu_active0>;
> + cooling-device = <&fan 0 2>;
> + };
> +
> + map2 {
> + trip = <&cpu_active1>;
> + cooling-device = <&fan 3 5>;
> + };
> +
> + map3 {
> + trip = <&cpu_active2>;
> + cooling-device = <&fan 6 10>;
> + };
> + };
> + };
> +};
> +
> +&tpm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tpm3>;
> + status = "okay";
> +};
> +
> +&tpm5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tpm5>;
> +};
> +
> +&usb2 {
> + dr_mode = "otg";
> + hnp-disable;
> + srp-disable;
> + adp-disable;
> + usb-role-switch;
> + disable-over-current;
> + samsung,picophy-pre-emp-curr-control = <3>;
> + samsung,picophy-dc-vol-level-adjust = <7>;
> + status = "okay";
> +
> + port {
> + typec_hs: endpoint {
> + remote-endpoint = <&typec_con_hs>;
> + };
> + };
> +};
> +
> +&usb3 {
> + status = "okay";
> +};
> +
> +&usb3_dwc3 {
> + dr_mode = "host";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_2_0: hub@1 {
> + compatible = "usb451,8142";
> + reg = <1>;
> + peer-hub = <&hub_3_0>;
> + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub_2_1: hub@1 {
> + compatible = "usb424,2514";
> + reg = <1>;
> + reset-gpios = <&expander2 4 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + vdda-supply = <®_v3v3_mb>;
> + };
> + };
> +
> + hub_3_0: hub@2 {
> + compatible = "usb451,8140";
> + reg = <2>;
> + peer-hub = <&hub_2_0>;
> + reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_v3v3_mb>;
> + };
> +};
> +
> +&usb3_phy {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb3>;
> + vbus-supply = <®_vbus_usb3>;
> + status = "okay";
> +};
> +
> +/* X7 µSD */
> +&usdhc2 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> + vmmc-supply = <®_sdvmmc>;
> + cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> + no-mmc;
> + no-sdio;
> + disable-wp;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&scmi_iomuxc {
> + pinctrl_enetc0: enetc0grp {
> + fsl,pins = <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x1100>,
> + <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x1100>,
> + <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x1100>,
> + <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x1100>,
> + <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x1100>,
> + <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x1100>,
> + <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x11e>,
> + <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x11e>,
> + <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x11e>,
> + <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x11e>,
> + <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x11e>,
> + <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x11e>;
> + };
> +
> + pinctrl_enetc1: enetc1grp {
> + fsl,pins = <IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x1100>,
> + <IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x1100>,
> + <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x1100>,
> + <IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x1100>,
> + <IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x1100>,
> + <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x1100>,
> + <IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x11e>,
> + <IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x11e>,
> + <IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x11e>,
> + <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x11e>,
> + <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x11e>,
> + <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x11e>;
> + };
> +
> + pinctrl_ethphy0: ethphy0grp {
> + fsl,pins = <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x1100>;
> + };
> +
> + pinctrl_ethphy1: ethphy1grp {
> + fsl,pins = <IMX95_PAD_ENET1_MDC__GPIO4_IO_BIT0 0x1100>;
> + };
> +
> + pinctrl_expander1: expander1grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO14__GPIO2_IO_BIT14 0x1100>;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp {
> + fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x1300>,
> + <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x31e>;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO27__CAN2_RX 0x1300>;
> + };
> +
> + pinctrl_lpi2c7: lpi2c7grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO07__LPI2C7_SCL 0x40001b1e>,
> + <IMX95_PAD_GPIO_IO06__LPI2C7_SDA 0x40001b1e>;
> + };
> +
> + pinctrl_lpi2c7_recovery: lpi2c7recoverygrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x40001b1e>,
> + <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x40001b1e>;
> + };
> +
> + pinctrl_lpspi4: lpspi4grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO37__LPSPI4_SCK 0x91e>,
> + <IMX95_PAD_GPIO_IO19__LPSPI5_SIN 0x191e>,
> + <IMX95_PAD_GPIO_IO36__LPSPI4_SOUT 0x91e>,
> + <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x91e>,
> + <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x91e>;
> + };
> +
> + pinctrl_lpuart1: lpuart1grp {
> + fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>,
> + <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x1300>;
> + };
> +
> + pinctrl_lpuart2: lpuart2grp {
> + fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>,
> + <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x1300>;
> + };
> +
> + pinctrl_lpuart5: lpuart5grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO00__LPUART5_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO01__LPUART5_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO02__LPUART5_CTS_B 0x1300>,
> + <IMX95_PAD_GPIO_IO03__LPUART5_RTS_B 0x31e>;
> + };
> +
> + pinctrl_lpuart7: lpuart7grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO08__LPUART7_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO09__LPUART7_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x1300>,
> + <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>;
> + };
> +
> + pinctrl_lpuart8: lpuart8grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>,
> + <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x1300>,
> + <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>;
> + };
> +
> + pinctrl_emdio: emdiogrp {
> + fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x51e>,
> + <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x51e>;
> + };
> +
> + pinctrl_pcie0: pcie0grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x111e>;
> + };
> +
> + pinctrl_pcie1: pcie1grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x111e>;
> + };
> +
> + pinctrl_sai3: sai3grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO16__SAI3_TX_BCLK 0x51e>,
> + <IMX95_PAD_GPIO_IO17__SAI3_MCLK 0x51e>,
> + <IMX95_PAD_GPIO_IO20__SAI3_RX_DATA_BIT0 0x1300>,
> + <IMX95_PAD_GPIO_IO21__SAI3_TX_DATA_BIT0 0x51e>,
> + <IMX95_PAD_GPIO_IO26__SAI3_TX_SYNC 0x51e>;
> + };
> +
> + pinctrl_retimer: retirmergrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x1100>;
> + };
> +
> + pinctrl_sfp: sfpgrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x1100>,
> + <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x1100>;
> + };
> +
> + pinctrl_tpm3: tpm3grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x51e>;
> + };
> +
> + pinctrl_tpm5: tpm5grp {
> + fsl,pins = <IMX95_PAD_GPIO_IO18__TPM5_CH2 0x51e>;
> + };
> +
> + pinctrl_typec: typcegrp {
> + fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x1100>;
> + };
> +
> + pinctrl_usb3: usb3grp {
> + fsl,pins = <IMX95_PAD_ENET1_MDIO__GPIO4_IO_BIT1 0x31e>;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x51e>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x31e>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x131e>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x131e>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x131e>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x131e>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +
> + pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x58e>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x38e>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +
> + pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
> + fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
> + <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x5fe>,
> + <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x3fe>,
> + <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>,
> + <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>,
> + <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>,
> + <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>,
> + <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> new file mode 100644
> index 0000000000000..cc572171bf253
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
> @@ -0,0 +1,297 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> + * D-82229 Seefeld, Germany.
> + * Author: Alexander Stein
> + * Author: Markus Niebel
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include "imx95.dtsi"
> +
> +/ {
> + memory@80000000 {
> + device_type = "memory";
> + /*
> + * DRAM base addr, size : 2048 MiB DRAM
> + * should be corrected by bootloader
> + */
> + reg = <0 0x80000000 0 0x80000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux_cma: linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0 0x28000000>;
> + alloc-ranges = <0 0x80000000 0 0x80000000>;
> + linux,cma-default;
> + };
> +
> + vpu_boot: vpu_boot@a0000000 {
> + reg = <0 0xa0000000 0 0x100000>;
> + no-map;
> + };
> + };
> +
> + reg_1v8: regulator-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "V_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "V_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + reg_sdvmmc: regulator-sdvmmc {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sdvmmc>;
> + regulator-name = "SD_PWR_EN";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> + off-on-delay-us = <12000>;
> + enable-active-high;
> + /* can be enabled by mainboard with SD-Card support */
> + status = "disabled";
> + };
> +};
> +
> +&adc1 {
> + vref-supply = <®_1v8>;
> +};
> +
> +&flexspi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexspi1>;
> + status = "okay";
> +
> + flash0: flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <66000000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + vcc-supply = <®_1v8>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> +};
> +
> +/* System Manager */
> +&gpio1 {
> + status = "reserved";
> +};
> +
> +/* System Manager */
> +&lpi2c1 {
> + status = "reserved";
> +};
> +
> +&lpi2c2 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lpi2c2>;
> + status = "okay";
> +
> + pcf85063: rtc@51 {
> + compatible = "nxp,pcf85063a";
> + reg = <0x51>;
> + quartz-load-femtofarads = <7000>;
> + };
> +
> + m24c64: eeprom@54 {
> + compatible = "atmel,24c64";
> + reg = <0x54>;
> + pagesize = <32>;
> + vcc-supply = <®_3v3>;
> + };
> +
> + /* protectable identification memory (part of M24C64-D @54) */
> + eeprom@5c {
> + compatible = "atmel,24c64d-wl";
> + reg = <0x5c>;
> + pagesize = <32>;
> + vcc-supply = <®_3v3>;
> + };
> +
> + imu@6b {
> + compatible = "st,ism330dhcx";
> + reg = <0x6b>;
> + vdd-supply = <®_3v3>;
> + vddio-supply = <®_3v3>;
> + };
> +};
> +
> +&thermal_zones {
> + pf09-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 2>;
> +
> + trips {
> + pf09_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf09_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pf53arm-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 4>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&pf5301_alert>;
> + cooling-device =
> + <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + pf5301_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf5301_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pf53soc-thermal {
> + polling-delay = <2000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&scmi_sensor 3>;
> +
> + trips {
> + pf5302_alert: trip0 {
> + hysteresis = <2000>;
> + temperature = <140000>;
> + type = "passive";
> + };
> +
> + pf5302_crit: trip1 {
> + hysteresis = <2000>;
> + temperature = <155000>;
> + type = "critical";
> + };
> + };
> + };
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + bus-width = <8>;
> + non-removable;
> + no-sdio;
> + no-sd;
> + status = "okay";
> +};
> +
> +&wdog3 {
> + status = "okay";
> +};
> +
> +&scmi_iomuxc {
> + pinctrl_flexspi1: flexspi1grp {
> + fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x19e>,
> + <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x19e>,
> + <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x19e>,
> + <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x19e>,
> + <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x19e>,
> + /* SION to allow clock loopback from pad */
> + <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x4000019e>,
> + <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x4000019e>;
> + };
> +
> + pinctrl_lpi2c2: lpi2c2grp {
> + fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x4000191e>,
> + <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x4000191e>;
> + };
> +
> + pinctrl_sdvmmc: sdvmmcgrp {
> + fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
> + fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>,
> + <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>,
> + <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>,
> + <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>,
> + <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>,
> + <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>,
> + <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>,
> + <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>,
> + <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>,
> + <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>,
> + <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>;
> + };
> +};
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ 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