* [PATCH v2 13/16] drm/tidss: Add support for AM62P display subsystem
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
From: Swamil Jain <s-jain1@ti.com>
The DSS controller on TI's AM62P SoC features two instances of the TI
DSS. Each DSS instance supports two video ports, similar to the DSS
controller found on the TI AM62X SoC. This allows three independent
video streams to be supported: OLDI, DPI, and DSI.
Since the DSS instances on AM62P are architecturally similar to those
on the AM62X DSS controller, the existing dispc_am625_feats
configuration can be reused for the AM62P DSS support.
This commit adds the necessary device tree compatibility entry for
"ti,am62p-dss" in the tidss driver, pointing to dispc_am625_feats,
thereby enabling DSS support on AM62P devices.
Signed-off-by: Swamil Jain <s-jain1@ti.com>
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index aef945101be4..2d056dc1c5ff 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -246,6 +246,7 @@ static const struct of_device_id tidss_of_table[] = {
{ .compatible = "ti,am625-dss", .data = &dispc_am625_feats, },
{ .compatible = "ti,am62a7-dss", .data = &dispc_am62a7_feats, },
{ .compatible = "ti,am62l-dss", .data = &dispc_am62l_feats, },
+ { .compatible = "ti,am62p-dss", .data = &dispc_am625_feats, },
{ .compatible = "ti,am65x-dss", .data = &dispc_am65x_feats, },
{ .compatible = "ti,j721e-dss", .data = &dispc_j721e_feats, },
{ }
--
2.43.0
^ permalink raw reply related
* [PATCH v2 09/16] drm/tidss: Add external data and sync signal edge configuration
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
The DPI output pipeline in K3 SoCs contains the display subsystem (DSS)
which produces the in-SoC parallel video signal, and a DPI block which
adjusts the signal to the external MIPI DPI output.
The DSS IP has registers to configure whether the data and sync signals
are driven on rising or falling clock edge, and on some SoCs these are
automatically conveyed to the DPI block which needs that configuration
to properly output the MIPI DPI signal.
However, on some SoCs the DPI block configuration has to be done
manually, using an extra register outside the DSS, DPI0_CLK_CTRL from
MAIN_CTRL_MMR_CFG0 block, which controls the DPI block's behavior.
Add the support to get the regmap to the register via syscon, and
configure the bits before enabling the video output.
Original patch from Louis Chauvet <louis.chauvet@bootlin.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_dispc.c | 21 +++++++++++++++++++++
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 4 ++++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
index c21ac3f51720..92cba069ed6c 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -467,6 +467,8 @@ struct dispc_device {
const struct dispc_features *feat;
struct clk *fclk;
+ struct regmap *syscon_dpi_io_ctrl;
+ unsigned int syscon_dpi_io_ctrl_offset;
bool is_enabled;
@@ -1201,6 +1203,13 @@ void dispc_vp_prepare(struct dispc_device *dispc, u32 hw_videoport,
mode->crtc_hdisplay - 1) |
FIELD_PREP(DISPC_VP_SIZE_SCREEN_VDISPLAY_MASK,
mode->crtc_vdisplay - 1));
+
+ if (dispc->vp_data[hw_videoport].dpi_output && dispc->syscon_dpi_io_ctrl) {
+ regmap_write(dispc->syscon_dpi_io_ctrl,
+ dispc->syscon_dpi_io_ctrl_offset + 0x0,
+ (!ipc ? DPI0_CLK_CTRL_DATA_CLK_INVDIS : 0) |
+ (rf ? DPI0_CLK_CTRL_SYNC_CLK_INVDIS : 0));
+ }
}
void dispc_vp_enable(struct dispc_device *dispc, u32 hw_videoport)
@@ -2989,6 +2998,18 @@ int dispc_init(struct tidss_device *tidss)
dispc_init_errata(dispc);
+ dispc->syscon_dpi_io_ctrl =
+ syscon_regmap_lookup_by_phandle_args(tidss->dev->of_node,
+ "ti,dpi-io-ctrl", 1,
+ &dispc->syscon_dpi_io_ctrl_offset);
+
+ if (PTR_ERR(dispc->syscon_dpi_io_ctrl) == -ENODEV)
+ dispc->syscon_dpi_io_ctrl = NULL;
+ else if (IS_ERR(dispc->syscon_dpi_io_ctrl))
+ return dev_err_probe(dispc->dev,
+ PTR_ERR(dispc->syscon_dpi_io_ctrl),
+ "DISPC: syscon_regmap_lookup_by_phandle failed.\n");
+
dispc->fourccs = devm_kcalloc(dev, ARRAY_SIZE(dispc_color_formats),
sizeof(*dispc->fourccs), GFP_KERNEL);
if (!dispc->fourccs)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
index 382027dddce8..4cdde24d8372 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -333,4 +333,8 @@ enum oldi_mode_reg_val { SPWG_18 = 0, JEIDA_24 = 1, SPWG_24 = 2 };
#define AM65X_OLDI_PWRDN_TX BIT(8)
+/* Bits in the MAIN_CTRL_MMR_CFG0_DPI0_CLK_CTRL register */
+#define DPI0_CLK_CTRL_DATA_CLK_INVDIS BIT(8)
+#define DPI0_CLK_CTRL_SYNC_CLK_INVDIS BIT(9)
+
#endif /* __TIDSS_DISPC_REGS_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 10/16] drm/tidss: Add support for DPIENABLE bit
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
Many (or even all?) K3 SoCs have DSS VP_CONTROL.DPIENABLE bit described
in their documentation. This bit controls whether the DPI block is
enabled, and is set to 1 by default (i.e. DPI is enabled at HW reset).
However, in almost all SoCs the setting does not actually do anything,
and at the moment the bit is not managed by the driver.
The exception is AM62L, which does have DPIENABLE connected, and
disabling the DPI block when it is not in use provides power savings.
Let's add a new feature flag for this, 'has_vp_control_dpienable', and
implement the support. Disable DPIENABLE for all videoports at resume
time, so that it is 0 by default. Specifically enable and disable it in
dispc_vp_enable() and dispc_vp_disable() for DPI output.
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_dispc.c | 23 +++++++++++++++++++++--
drivers/gpu/drm/tidss/tidss_dispc.h | 2 ++
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 1 +
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c
index 92cba069ed6c..82e0b3184cc4 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -442,6 +442,8 @@ const struct dispc_features dispc_am62l_feats = {
},
.vid_order = {0},
+
+ .has_vp_control_dpienable = true,
};
static const u16 *dispc_common_regmap;
@@ -1214,6 +1216,11 @@ void dispc_vp_prepare(struct dispc_device *dispc, u32 hw_videoport,
void dispc_vp_enable(struct dispc_device *dispc, u32 hw_videoport)
{
+ if (dispc->feat->has_vp_control_dpienable &&
+ dispc->vp_data[hw_videoport].dpi_output)
+ VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 1,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
+
VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 1,
DISPC_VP_CONTROL_ENABLE_MASK);
}
@@ -1222,6 +1229,11 @@ void dispc_vp_disable(struct dispc_device *dispc, u32 hw_videoport)
{
VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 0,
DISPC_VP_CONTROL_ENABLE_MASK);
+
+ if (dispc->feat->has_vp_control_dpienable &&
+ dispc->vp_data[hw_videoport].dpi_output)
+ VP_REG_FLD_MOD(dispc, hw_videoport, DISPC_VP_CONTROL, 0,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
}
void dispc_vp_unprepare(struct dispc_device *dispc, u32 hw_videoport)
@@ -2445,10 +2457,17 @@ static void dispc_vp_init(struct dispc_device *dispc)
dev_dbg(dispc->dev, "%s()\n", __func__);
- /* Enable the gamma Shadow bit-field for all VPs*/
- for (i = 0; i < dispc->feat->num_vps; i++)
+ for (i = 0; i < dispc->feat->num_vps; i++) {
+ /* Enable the gamma Shadow bit-field for all VPs*/
VP_REG_FLD_MOD(dispc, i, DISPC_VP_CONFIG, 1,
DISPC_VP_CONFIG_GAMMAENABLE_MASK);
+
+ if (dispc->feat->has_vp_control_dpienable) {
+ /* Disable DPIENABLE for all VPs */
+ VP_REG_FLD_MOD(dispc, i, DISPC_VP_CONTROL, 0,
+ DISPC_VP_CONTROL_DPIENABLE_MASK);
+ }
+ }
}
static void dispc_initial_config(struct dispc_device *dispc)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.h b/drivers/gpu/drm/tidss/tidss_dispc.h
index 6f53d554259c..0fbfb86adfbf 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc.h
@@ -92,6 +92,8 @@ struct dispc_features {
u32 num_vids;
struct dispc_vid_info vid_info[TIDSS_MAX_PLANES];
u32 vid_order[TIDSS_MAX_PLANES];
+ /* The DSS has VP_CONTROL.DPIENABLE bit */
+ bool has_vp_control_dpienable;
};
extern const struct dispc_features dispc_k2g_feats;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
index 4cdde24d8372..4246c72efdd5 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -230,6 +230,7 @@ enum dispc_common_regs {
#define DISPC_VP_CONTROL 0x4
#define DISPC_VP_CONTROL_DATALINES_MASK GENMASK(10, 8)
+#define DISPC_VP_CONTROL_DPIENABLE_MASK GENMASK(6, 6)
#define DISPC_VP_CONTROL_GOBIT_MASK GENMASK(5, 5)
#define DISPC_VP_CONTROL_ENABLE_MASK GENMASK(0, 0)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 01/16] dt-bindings: display: ti: Move ti,am62l-dss binding to a new binding file
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
We currently have two binding files for different TI K3 DSS versions:
ti,j721e-dss.yaml which contains bindings for the "full" DSS version,
with four planes and outputs, and ti,am65x-dss.yaml which used to
contain bindings for the "lite" DSS version, with two planes and
outputs.
ti,am62l-dss binding was added recently to the ti,am65x-dss.yaml file,
which only has a single plane and a single output. To keep with the
above "binding file per DSS model" style, and to simplify the
ti,am65x-dss.yaml file, let's move the ti,am62l-dss to a separate, new
file.
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
.../bindings/display/ti/ti,am62l-dss.yaml | 136 +++++++++++++++++++++
.../bindings/display/ti/ti,am65x-dss.yaml | 94 +++-----------
MAINTAINERS | 1 +
3 files changed, 156 insertions(+), 75 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am62l-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am62l-dss.yaml
new file mode 100644
index 000000000000..ce6185dca18d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am62l-dss.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2026 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/ti/ti,am62l-dss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM62L Display Subsystem
+
+maintainers:
+ - Tomi Valkeinen <tomi.valkeinen@ti.com>
+
+description: |
+ The AM62L display subsystem is a cut-down version of the TI Keystone
+ Display SubSystem. It has a single output port which supports DPI
+ format and a single video "lite plane" which does not support scaling.
+ The output port is routed to the SoC boundary via the DPI interface,
+ and the same DPI signals are also routed internally to the DSI Tx
+ controller present within the SoC. Due to clocking limitations only
+ one of the interfaces (DSI or DPI) can be used at a time.
+
+properties:
+ compatible:
+ const: ti,am62l-dss
+
+ reg:
+ description:
+ Addresses to each DSS memory region described in the SoC's TRM.
+ items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: OVR1 overlay manager for vp1
+ - description: VP1 video port 1
+ - description: common1 DSS register area
+
+ reg-names:
+ items:
+ - const: common
+ - const: vidl1
+ - const: ovr1
+ - const: vp1
+ - const: common1
+
+ clocks:
+ items:
+ - description: fck DSS functional clock
+ - description: vp1 Video Port 1 pixel clock
+
+ clock-names:
+ items:
+ - const: fck
+ - const: vp1
+
+ assigned-clocks:
+ minItems: 1
+ maxItems: 2
+
+ assigned-clock-parents:
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+ description: phandle to the associated power domain
+
+ dma-coherent: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ The DSS DPI output port node from video port 1, which may be
+ connected to the external DPI pins or to the internal DSI Tx
+ controller.
+
+ required:
+ - port@0
+
+ max-memory-bandwidth:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Input memory (from main memory to dispc) bandwidth limit in
+ bytes per second
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ dss: dss@30200000 {
+ compatible = "ti,am62l-dss";
+ reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1 */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "ovr1", "vp1", "common1";
+ power-domains = <&scmi_pds 39>;
+ clocks = <&scmi_clk 162>,
+ <&scmi_clk 161>;
+ clock-names = "fck", "vp1";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ dpi0_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 49a007cbcd3a..75d9640398f0 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -18,68 +18,45 @@ description: |
internally routed to 2 OLDI TXes. The second video port supports DPI
format. The first plane is full video plane with all features and the
second is a "lite plane" without scaling support.
- The AM62L display subsystem has a single output port which supports DPI
- format but it only supports single video "lite plane" which does not support
- scaling. The output port is routed to SoC boundary via DPI interface and same
- DPI signals are also routed internally to DSI Tx controller present within the
- SoC. Due to clocking limitations only one of the interface i.e. either DSI or
- DPI can be used at once.
properties:
compatible:
enum:
- ti,am625-dss
- ti,am62a7-dss
- - ti,am62l-dss
- ti,am65x-dss
reg:
description:
Addresses to each DSS memory region described in the SoC's TRM.
- oneOf:
- - items:
- - description: common DSS register area
- - description: VIDL1 light video plane
- - description: VID video plane
- - description: OVR1 overlay manager for vp1
- - description: OVR2 overlay manager for vp2
- - description: VP1 video port 1
- - description: VP2 video port 2
- - description: common1 DSS register area
- - items:
- - description: common DSS register area
- - description: VIDL1 light video plane
- - description: OVR1 overlay manager for vp1
- - description: VP1 video port 1
- - description: common1 DSS register area
+ items:
+ - description: common DSS register area
+ - description: VIDL1 light video plane
+ - description: VID video plane
+ - description: OVR1 overlay manager for vp1
+ - description: OVR2 overlay manager for vp2
+ - description: VP1 video port 1
+ - description: VP2 video port 2
+ - description: common1 DSS register area
reg-names:
- oneOf:
- - items:
- - const: common
- - const: vidl1
- - const: vid
- - const: ovr1
- - const: ovr2
- - const: vp1
- - const: vp2
- - const: common1
- - items:
- - const: common
- - const: vidl1
- - const: ovr1
- - const: vp1
- - const: common1
+ items:
+ - const: common
+ - const: vidl1
+ - const: vid
+ - const: ovr1
+ - const: ovr2
+ - const: vp1
+ - const: vp2
+ - const: common1
clocks:
- minItems: 2
items:
- description: fck DSS functional clock
- description: vp1 Video Port 1 pixel clock
- description: vp2 Video Port 2 pixel clock
clock-names:
- minItems: 2
items:
- const: fck
- const: vp1
@@ -113,8 +90,6 @@ properties:
For AM625 DSS, the internal DPI output port node from video
port 1.
For AM62A7 DSS, the port is tied off inside the SoC.
- For AM62L DSS, the DSS DPI output port node from video port 1
- or DSI Tx controller node connected to video port 1.
properties:
endpoint@0:
$ref: /schemas/graph.yaml#/properties/endpoint
@@ -189,38 +164,7 @@ allOf:
properties:
compatible:
contains:
- const: ti,am62l-dss
- then:
- properties:
- ports:
- properties:
- port@1: false
- reg:
- maxItems: 5
- reg-names:
- maxItems: 5
- clocks:
- maxItems: 2
- clock-names:
- maxItems: 2
- else:
- properties:
- reg:
- minItems: 8
- reg-names:
- minItems: 8
- clocks:
- minItems: 3
- clock-names:
- minItems: 3
-
- - if:
- properties:
- compatible:
- contains:
- enum:
- - ti,am62l-dss
- - ti,am65x-dss
+ const: ti,am65x-dss
then:
properties:
oldi-transmitters: false
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..902502e1d63c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8756,6 +8756,7 @@ L: dri-devel@lists.freedesktop.org
S: Maintained
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
F: Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
+F: Documentation/devicetree/bindings/display/ti/ti,am62l-dss.yaml
F: Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
F: Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/16] drm/tidss: Remove extra pm_runtime_mark_last_busy
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
pm_runtime_put_autosuspend() calls pm_runtime_mark_last_busy(), so no
need to call pm_runtime_mark_last_busy() explicitly in the driver.
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index 1c8cc18bc53c..5cb3e746aeb3 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -42,8 +42,6 @@ void tidss_runtime_put(struct tidss_device *tidss)
{
int r;
- pm_runtime_mark_last_busy(tidss->dev);
-
r = pm_runtime_put_autosuspend(tidss->dev);
WARN_ON(r < 0);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 07/16] drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
OLDI_LB_CTRL define is not used, and doesn't seem to exist at least on
some SoCs. Let's remove the define.
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/tidss/tidss_oldi.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_oldi.h b/drivers/gpu/drm/tidss/tidss_oldi.h
index 8cd535c5ee65..a361e6dbfce3 100644
--- a/drivers/gpu/drm/tidss/tidss_oldi.h
+++ b/drivers/gpu/drm/tidss/tidss_oldi.h
@@ -20,7 +20,6 @@ struct tidss_oldi;
/* Register offsets */
#define OLDI_PD_CTRL 0x100
-#define OLDI_LB_CTRL 0x104
/* Power control bits */
#define OLDI_PWRDOWN_TX(n) BIT(n)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/16] dt-bindings: display: ti,am65x-dss: Add ti,dpi-io-ctrl
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
The DPI output pipeline in K3 SoCs contains the display subsystem (DSS)
which produces the in-SoC parallel video signal, and a DPI block which
adjusts the signal to the external MIPI DPI output.
The DSS IP has registers to configure whether the data and sync signals
are driven on rising or falling clock edge, and on some SoCs these are
automatically conveyed to the DPI block which needs that configuration
to properly output the MIPI DPI signal.
However, on some SoCs the DPI block configuration has to be done
manually, using an extra register outside the DSS, DPI0_CLK_CTRL in
MAIN_CTRL_MMR_CFG0 block, which controls the DPI block's behavior.
Currently the DPI0_CLK_CTRL is never written, so it's always 0, meaning
the data and sync are always driven on a rising clock edge regardless of
the DSS configuration.
Add 'ti,dpi-io-ctrl' property, which contains phandle to the
MAIN_CTRL_MMR_CFG0 block and the offset to the DPI0_CLK_CTRL register,
so that the DSS driver can configure the data and sync signals
correctly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 588d72d4ec0d..902ae2122d86 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -113,6 +113,17 @@ properties:
and OLDI_CLK_IO_CTRL registers. This property is needed for OLDI
interface to work.
+ ti,dpi-io-ctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ phandle to a syscon device node containing the DPI0_CLK_CTRL register,
+ with the offset to DPI0_CLK_CTRL as an argument.
+ maxItems: 1
+ items:
+ items:
+ - description: phandle to the syscon node
+ - description: DPI0_CLK_CTRL register offset
+
max-memory-bandwidth:
$ref: /schemas/types.yaml#/definitions/uint32
description:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 03/16] dt-bindings: display: ti,am625-oldi: Add optional power-domain for OLDI
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen
In-Reply-To: <20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com>
On some SoCs the OLDI blocks belong to the same power-domain as the main
DSS block, but on some more recent SoCs the OLDI blocks have a
controllable power-domain.
Add the power-domain to the DT binding.
Tested-by: Swamil Jain <s-jain1@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
index 8203ec5e5bb3..5dbf1f76dd3f 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
@@ -29,6 +29,9 @@ properties:
clock-names:
const: serial
+ power-domains:
+ maxItems: 1
+
ti,companion-oldi:
$ref: /schemas/types.yaml#/definitions/phandle
description:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/16] drm/tidss: Add BeagleY-AI display support (and some more)
From: Tomi Valkeinen @ 2026-05-13 13:17 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Jayesh Choudhary, Aradhya Bhatia, Andrew Davis,
Robert Nelson
This series aims to add display support for all display interfaces on
BeagleY-AI board. More generally, it adds display support for TI AM62P,
J722S, and related SoCs, and, as a bit extra, improves AM62L's DPI
handling.
The main topics to highlight:
- The data and sync signal polarities require accessing a register
(DPI0_CLK_CTRL) in the CTRL_MMR block. This has already been discussed
e.g. in
https://lore.kernel.org/all/20250730-fix-edge-handling-v1-0-1bdfb3fe7922%40bootlin.com/.
In this series the whole CTRL_MMR ("main_conf") block is changed to a
syscon, which allows simpler access to the DPI0_CLK_CTRL register.
- The tidss OLDI support will now use auxiliary device/driver. This seems
to solve quite neatly the requirement to have a power-domain for each
OLDI. The main issue that remains is that on AM62P (and similar) we
will have three OLDI TX DT nodes, even if there are only two in the
hardware.
With this series one can use the HDMI output on BeagleY-AI. I have also
tested the DSI output with Raspberry Pi's 7" DSI display, and OLDI
output with an oscilloscope (I don't have a suitable OLDI panel).
Tomi
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Changes in v2:
- Add Rb and Tb tags
- Drop "dt-bindings: mfd: syscon: Add ti,am625-dss-dpi0-clk-ctrl
compatible", which is now implemented with the below changes.
- New patch "dt-bindings: display: ti,am65x-dss: Add ti,dpi-io-ctrl"
- Modify "drm/tidss: Add external data and sync signal edge
configuration" to use the 'ti,dpi-io-ctrl' with offset.
- New patch "arm64: dts: ti: k3-am62p-j722s-common-main: Make main_conf
a syscon".
- Modify "arm64: dts: ti: k3-am62p-j722s-common-main: Add support for
DSS" to set 'ti,dpi-io-ctrl' properties
- Drop generic desc in DT bindings for power-domains property
- Fix pm_runtime_get_sync() return value check
- Link to v1: https://lore.kernel.org/r/20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com
---
Andrew Davis (1):
arm64: dts: ti: beagley-ai: Enable HDMI display and audio
Jayesh Choudhary (1):
arm64: dts: ti: k3-am62p-j722s-common-main: Add support for DSS
Swamil Jain (1):
drm/tidss: Add support for AM62P display subsystem
Tomi Valkeinen (13):
dt-bindings: display: ti: Move ti,am62l-dss binding to a new binding file
dt-bindings: display: ti,am65x-dss: Simplify binding
dt-bindings: display: ti,am625-oldi: Add optional power-domain for OLDI
dt-bindings: display: ti,am65x-dss: Add ti,dpi-io-ctrl
dt-bindings: display: ti,am65x-dss: Add AM62P DSS
drm/tidss: Remove extra pm_runtime_mark_last_busy
drm/tidss: oldi: Remove define for unused register OLDI_LB_CTRL
drm/tidss: Add mechanism to detect DPI output
drm/tidss: Add external data and sync signal edge configuration
drm/tidss: Add support for DPIENABLE bit
drm/tidss: oldi: Fix OLDI signal polarities
drm/tidss: oldi: Convert OLDI to an aux driver
arm64: dts: ti: k3-am62p-j722s-common-main: Make main_conf a syscon
.../bindings/display/ti/ti,am625-oldi.yaml | 3 +
.../bindings/display/ti/ti,am62l-dss.yaml | 136 ++++++
.../bindings/display/ti/ti,am65x-dss.yaml | 187 +++-----
MAINTAINERS | 1 +
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 111 ++++-
arch/arm64/boot/dts/ti/k3-am62p.dtsi | 16 +
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 197 ++++++++
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 16 +
drivers/gpu/drm/tidss/tidss_crtc.c | 10 +-
drivers/gpu/drm/tidss/tidss_crtc.h | 4 +-
drivers/gpu/drm/tidss/tidss_dispc.c | 49 +-
drivers/gpu/drm/tidss/tidss_dispc.h | 5 +-
drivers/gpu/drm/tidss/tidss_dispc_regs.h | 5 +
drivers/gpu/drm/tidss/tidss_drv.c | 54 ++-
drivers/gpu/drm/tidss/tidss_drv.h | 5 +-
drivers/gpu/drm/tidss/tidss_kms.c | 55 ++-
drivers/gpu/drm/tidss/tidss_oldi.c | 531 +++++++++++++++------
drivers/gpu/drm/tidss/tidss_oldi.h | 8 +-
18 files changed, 1104 insertions(+), 289 deletions(-)
---
base-commit: 3131ff5a117498bb4b9db3a238bb311cbf8383ce
change-id: 20260420-beagley-ai-display-d7f634cde5f4
prerequisite-message-id: <20260415110409.2577633-1-s-jain1@ti.com>
prerequisite-patch-id: 654d90f9cddec8b41e6fb1b3776a632606fef88c
Best regards,
--
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
^ permalink raw reply
* Re: [PATCH 2/4] clk: renesas: r8a73a4: Implement ZT/ZTR trace clock on R-Mobile APE6
From: Geert Uytterhoeven @ 2026-05-13 13:15 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260502185557.93061-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sat, 2 May 2026 at 20:56, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Implement ZT trace bus and ZTR trace clock on the R-Mobile APE6.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
/sys/kernel/debug/clk/clk_summary looks a bit off to me:
zt 0 0 0 208000000
ztr 0 0 0 277333334
> --- a/drivers/clk/renesas/clk-r8a73a4.c
> +++ b/drivers/clk/renesas/clk-r8a73a4.c
> @@ -43,6 +43,8 @@ static struct div4_clk div4_clks[] = {
> { "m1", CPG_FRQCRA, 4 },
> { "m2", CPG_FRQCRA, 0 },
> { "zx", CPG_FRQCRB, 12 },
> + { "ztr", CPG_FRQCRB, 16 },
20?
> + { "zt", CPG_FRQCRB, 12 },
16? (12 is zx, cfr. above).
I.e. the same shifts as on R-Mobile A1.
> { "zs", CPG_FRQCRB, 8 },
> { "hp", CPG_FRQCRB, 4 },
> { NULL, 0, 0 },
After fixing the shifts, I get:
zt 0 0 0 277333334
ztr 0 0 0 277333334
which looks much better. If you agree, I can fix this while applying.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: renesas: r8a73a4: Describe coresight on R-Mobile APE6
From: Geert Uytterhoeven @ 2026-05-13 13:13 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette, Rob Herring,
Stephen Boyd, devicetree, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260502185557.93061-5-marek.vasut+renesas@mailbox.org>
On Sat, 2 May 2026 at 20:56, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Describe coresight topology on R-Mobile APE6. Extend the current PTM node
> with connection funnel, TPIU, ETB and replicator. The coresight on this
> hardware is clocked from the ZT/ZTR trace clock.
>
> Note that only core 0 part of the topology is described, because the
> other cores are still not present in the DT.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/4] ARM: dts: renesas: r8a73a4: Add ZT/ZTR trace clock on R-Mobile APE6
From: Geert Uytterhoeven @ 2026-05-13 13:12 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260502185557.93061-4-marek.vasut+renesas@mailbox.org>
On Sat, 2 May 2026 at 20:56, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add ZT trace bus and ZTR trace clock on the R-Mobile APE6.
> These clock supply the coresight tracing modules, PTM, TPIU,
> ETB and replicator. Without these clock, the coresight tracing
> can not be operated.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6
From: Geert Uytterhoeven @ 2026-05-13 13:12 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Michael Turquette, Rob Herring, Stephen Boyd, devicetree,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260502185557.93061-2-marek.vasut+renesas@mailbox.org>
On Sat, 2 May 2026 at 20:56, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Document ZT trace bus and ZTR trace clock on the R-Mobile APE6.
> These clock supply the coresight tracing modules, PTM, TPIU,
> ETB and replicator. Without these clock, the coresight tracing
> can not be operated. While this does change the ABI, it does so
> by extending the existing clock-output-names, therefore if an
> old software is used with new DT, the coresight tracing parts
> will likely fail to probe, otherwise if new software is used
> with an old DT, there is no impact.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue for v7.2 in a branch shared by clock and DTS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Eric Auger @ 2026-05-13 13:03 UTC (permalink / raw)
To: Paolo Bonzini, David Woodhouse, Marc Zyngier
Cc: Jonathan Corbet, Shuah Khan, kvm, linux-doc, linux-kernel,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Raghavendra Rao Ananta, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <ba08dfe9-932b-40c3-9fdf-fc891d52e1d8@redhat.com>
Hi,
On 5/13/26 2:43 PM, Paolo Bonzini wrote:
> On 5/13/26 11:24, David Woodhouse wrote:
>> On Wed, 2026-05-13 at 09:42 +0100, Marc Zyngier wrote:
>>> If userspace is not a total joke, it will read all the ID registers,
>>> and configure what it wants to see, assuming it is a feature that can
>>> be configured (not everything can, because the architecture itself is
>>> not fully backward compatible).
>>>
>>> Yes, this is buggy at times, because the combinatorial explosion of
>>> CPU capabilities and supported features makes it pretty hard to test
>>> (and really nobody actually does). But overall, it works, and QEMU is
>>> growing an infrastructure to manage it in a "user friendly" way.
>>
>> Yes, that is precisely what I'm asking for. I'm prepared to deal with
>> the fact that KVM/Arm64 is not a stable and mature platform like x86
>> is, and that userspace has to find all the random changes from one
>> version to the next, and explicitly pin things down to be compatible.
>>
>> All I'm asking for is that KVM makes it *possible* to pin things down
>> to the behaviour of previously released Linux/KVM kernels.
>>
>>> But really, this isn't what David is asking. He's demanding "bug for
>>> bug" compatibility. For that, we have two possible cases:
>>
>> No, I am not asking you to meet that bar. I merely observed that x86
>> does and that it would be nice. But we are a *long* way from that.
>
> x86 doesn't do bug-for-bug compatibility, thankfully - we have quirks
> but only 11 of them, or about one per year since we started adding
> them. We only add quirks, generally speaking, when 1) we change the
> way file descriptors are initialized, 2) guests in the wild were
> relying on it, or 3) it prevends restoring state saved from an old
> kernel. Is there anything else?
>
> So you're asking something not really far from this:
>
>>> - this is a behaviour that is not allowed by the architecture: we fix
>>> it for good. We do that on every release. Some minor, some much more
>>> visible. And there is no way we will add this sort of "bring the
>>> bugs back" type of behaviours. Specially when it is really obvious
>>> that no SW can make any reasonable use of the defect. We allow
>>> userspace to keep behaving as before, but the guest will not see a
>>> non-compliant behaviour.
>
> ... where for example
> https://lore.kernel.org/kvm/e03f092dfbb7d391a6bf2797ba01e122ba080bcd.camel@infradead.org/
> is an example of a bug that "no SW can make any reasonable use of".
>
>> Marc, this is complete nonsense and you should know better.
>> Once a behaviour is present in a released version of Linux/KVM, we
>> can't just declare it "wrong" and unilaterally impose a change in
>> guest-visible behaviour on *running* guests as a side-effect of a
>> kernel upgrade.
>>
>> The criterion for *KVM* to remain compatible is "once it has been in a
>> released version of the kernel". Not "once it is in the architecture".
>
> That is *also* obviously nonsense though, isn't it (see example
> above)? The truth is in the middle, "once it is in the architecture"
> is likely too narrow but "once it is in a Linux release" is way too
> broad. And besides, both miss the point of *configurability* which is
> the basis of it all.
>
> The main difference between x86 and Arm is the default state at
> creation; x86 defaults to a blank slate, mostly; and when we didn't do
> that, we regretted it later (cue the STUFF_FEATURE_MSRS quirk). It's
> too late to change the behavior for Arm, but I think we can agree that
> patches such as
> https://lore.kernel.org/kvm/20260511113558.3325004-2-dwmw2@infradead.org/
> ("KVM: arm64: vgic: Allow userspace to set IIDR revision 1") are what
> the letter and spirit of this proposal is about.
>
> Marc did not mention having to deal with guests in the wild. Let's
> ignore it for now because even defining "guests in the wild" is hard;
> and anyway it's not related to the patch that triggered the discussion.
>
> So we have the third case, "restoring state saved from an old kernel".
> If this case arises, I do believe that Arm will have to deal with it
> and introduce quirks or KVM_GET/SET_REG hacks. Maybe it hasn't
> happened yet, lucky you.
for info, this qemu series was merged laterly.
[PATCH v10 0/7] Mitigation of "failed to load
cpu:cpreg_vmstate_array_len" migration failures <https://lore.kernel.org/all/20260420140552.104369-1-eric.auger@redhat.com/#r>
https://lore.kernel.org/all/20260420140552.104369-1-eric.auger@redhat.com/#r
It brings an infrastructure to mitigate some migration failures accross different kernel versions.
Also there is [PATCH v4 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model, under review
https://lore.kernel.org/all/20260503073541.790215-1-eric.auger@redhat.com/
This series aims at beeing able to offer the capacity to set writable ID regs on the host passthrough vcpu model.
Thanks
Eric
>
> Overall, even if we may disagree about the details, are we really on
> terribly distant grounds, or are we not?
>
> Paolo
>
^ permalink raw reply
* Re: [PATCH RFC] printk: remove BOOT_PRINTK_DELAY
From: Petr Mladek @ 2026-05-13 13:04 UTC (permalink / raw)
To: Andrew Murray
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Randy Dunlap, Clark Williams,
linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Linus Torvalds
In-Reply-To: <CALqELGxhXO=kzh9bpztd9=Ug9ykPL2NALo9Apq3=Oj6aeiEcKg@mail.gmail.com>
On Wed 2026-05-06 23:37:01, Andrew Murray wrote:
> On Tue, 5 May 2026 at 15:26, Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Tue 2026-05-05 14:45:00, Andrew Murray wrote:
> > > The CONFIG_BOOT_PRINTK_DELAY option enables support for the boot_delay
> > > kernel parameter, this allows for a configurable delay to be added before
> > > each and every printk is emitted. This is DEBUG_KERNEL option that is
> > > helpful for debugging as kernel output can be slowed down during boot
> > > allowing messages to be seen before scrolling off the screen, or to
> > > correlate timing between some physical event and console output.
> > >
> > > However, since the introduction of nbcon and the legacy printer thread for
> > > PREEMPT_RT kernels, printk records are now emited to the console
> > > asynchronously to the caller of printk and its boot_delay. The delay added
> > > by boot_delay continues to slow down the calling process, but may not have
> > > any impact to the rate in which records are emited to the console. For
> > > example, if delay_use is set to 100ms, and the printer thread has a
> > > backlog of more than 100ms, perhaps due to a slow serial console, then the
> > > records will appear to be printed without any delay between them.
> > >
> > > It would be unhelpful to add a delay to the printer thread, and it would
> > > not be possible to disallow selection of CONFIG_BOOT_PRINTK_DELAY at build
> > > time as it's not possible to detect which consoles are nbcon enabled at
> > > build time. Therefore, let's remove this feature.
> >
> > Heh, Randy proposed to remove "boot_delay" few days ago.
> > This RFC goes even further and remove both "boot_delay" and
> > "printk_delay".
>
> Apologies, I didn't see this. I'll co-ordinate with Randy.
No need to apologize.
> > Honestly, I do not feel comfortable by this. The delay seems to
> > be handy when there is only graphical console. I would suggest
> > to do:
> >
> > 1. Obsolete "boot_delay" with "printk_delay" as
> > proposed in Randy's thread, see
> > https://lore.kernel.org/all/afn2sYKKsqG4QBVX@pathway.suse.cz/
>
> Your suggestion was:
>
> " 1. Add "printk_delay" early_param() which would allow
> to set "printk_delay_msec" via command line."
>
> And I assume the intent is to replicate the functionality of
> boot_delay, by allowing printk_delay to be used to introduce delays
> from early_param time? Thus deprecating delay_use.
Exactly.
>
> " 2. Modify boot_delay_setup() to set "printk_delay_msec" as well.
> In addition, it might print a message that it has been
> obsoleted by "printk_delay" and will be removed."
>
> Given the intent may be to deprecate boot_delay, I'm not sure that
> setting printk_delay_msec as well would be beneficial, as this would
> extend its functionality to add delays beyond SYSTEM_RUNNING which is
> where boot_delay stops. Unless you mean to use boot_delay as an alias
> to an early_param hook for printk_delay?
I do not think that this is a big problem. As you write below, it is
a debug feature. IMHO, people debugging boot problems won't mind when
the delay continues beyond SYSTEM_RUNNING. And if anyone complains
than we would at least know that there are people using this feature ;-)
> It seems that there are also differences in behavior between
> printk_delay and boot_use, with printk_delay unconditionally adding
> delays to all printks, and delay_use which considers the loglevel.
The unconditional delay does not make much sense. I consider it a bug.
> >
> > 2. Move printk_delay() from vprintk_emit() to
> > console_emit_next_record() and nbcon_emit_next_record().
> >
> > For nbcon console, even better would be to use a sleeping
> > wait in nbcon_kthread_func(). But it would need some
> > changes to call it only when a record was really emitted.
> > Also we would need to use the busy wait in
> > __nbcon_atomic_flush_pending_con().
>
> This makes sense.
>
> If the use case (in a post kthread printk thread world), is only
> relevant for graphical consoles, then I do wonder if printk_delay and
> boot_delay can be replaced with a more specific solution? Now that we
> have printk threads, the time in which a printk is presented to the
> user may not relate to when it was created, and I fear people may
> continue to debug issues that rely on that assumption.
>
> I think the most pragmatic solution for now is:
> - Move the printk delay to the point where the printk is actually
> printed (e.g. console_flush_one_record and descendants)
> - Add an early_param to allow for printk_delay_msec to be set
> - Deprecate boot_delay, by using it as an alias for setting
> printk_delay_msec, and include a user mesage that it is being
> deprecated and that it now extends to beyond boot (which could impact
> performance on non PREEMPT_RT and non nbcon systems)
Sounds good.
> - Update printk_delay function to use the appropiate mechanism to
> delay based on stage of boot and using printk_delay_msec instead of
> boot_delay.
Good point! I thought that mdelay() can be used even for the early
messages because parse_early_param() is called right before
parse_args() in start_kernel() in init/main.c.
But parse_early_param() might be called even earlier, for example,
by setup_arch in arch/x86/kernel/setup.c. And it is called before
+ tsc_early_init()
+ tsc_enable_sched_clock()
+ loops_per_jiffy = get_loops_per_jiffy()
which seems to be used by
+ mdelay()
+ udelay()
+ __const_udelay()
Anyway, it has to be done before printk_delay_msec() can be set
via an early parameter.
> If that makes sense I can fashion a patchset.
That would be great.
Best Regards,
Petr
PS: Note that I am traveling the following week so my review might
get delayed.
^ permalink raw reply
* Re: [PATCH v7 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Andreas Kemnade @ 2026-05-13 12:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andy Shevchenko, Daniel Scally, Heikki Krogerus,
Sakari Ailus, Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren,
Russell King, Dmitry Torokhov, Kevin Hilman, Arnd Bergmann,
driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap
In-Reply-To: <CAMRc=MdN9EpQVW=1Sb-9hRdt56Y5NNbskujjq2RiXhu90t0QyA@mail.gmail.com>
Hi,
On Mon, 11 May 2026 15:34:39 +0200
Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Thu, Apr 30, 2026 at 9:31 AM Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
> >
> > This converts Nokia 770 to using real firmware node lookup for GPIOs by
> > attaching the software nodes describing GPIO controllers to their target
> > devices.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > ---
>
> Hi!
>
> Gentle ping, can this be queued now for v7.2?
>
So any objections from your side, Aaro?
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH] perf arm-spe: Don't warn about the discard bit if it doesn't exist
From: Ian Rogers @ 2026-05-13 12:55 UTC (permalink / raw)
To: Leo Yan
Cc: James Clark, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Adrian Hunter, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <20260513102024.GE34802@e132581.arm.com>
On Wed, May 13, 2026 at 3:20 AM Leo Yan <leo.yan@arm.com> wrote:
>
> On Fri, Apr 10, 2026 at 12:05:12PM +0100, James Clark wrote:
> > Opening an SPE event shows a warning that doesn't concern the user:
> >
> > $ perf record -e arm_spe
> > Unknown/empty format name: discard
> >
> > Perf only wants to know if the discard bit is set for configuring the
> > event, not in response to anything the user has done. Fix it by adding
> > another helper that returns if a config bit exists without warning.
> >
> > We should probably keep the warning in evsel__get_config_val() to avoid
> > having every caller having to do it, and most format bits should never
> > be missing.
> >
> > Add a test for the new helper. Rename the parent test function to be
> > more generic rather than adding a new one as it requires a lot of
> > boilerplate.
> >
> > Signed-off-by: James Clark <james.clark@linaro.org>
>
> Reviewed-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Thanks,
Ian
^ permalink raw reply
* Re: [PATCH 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
From: Marc Zyngier @ 2026-05-13 12:49 UTC (permalink / raw)
To: Mark Rutland
Cc: kvmarm, linux-arm-kernel, kvm, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu, Will Deacon,
Fuad Tabba
In-Reply-To: <agRuiKHWWn_88YzT@J2N7QTR9R3>
Hi Mark,
Thanks for looking into this.
On Wed, 13 May 2026 13:28:56 +0100,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, May 12, 2026 at 03:07:55PM +0100, Marc Zyngier wrote:
> > When switching between L1 and L2, we diligently use a non-preemptible
> > put/load sequence in order to make sure that the old state is saved,
> > while the new state is brought in. Crucially, this includes the FP
> > registers.
> >
> > However, this is a bit silly. The FP registers are completely shared
> > between the various ELs (just like the GPRs, really), and eagerly
> > save/restoring those in a non-preemptible section is just overhead.
> > Not to mention that the next access will end-up trapping, something
> > that becomes exponentially expensive as we nest deeper.
> >
> > The temptation is therefore to completely drop this save/restore thing.
> > Why is it valid to do so? By analogy, the hypervisor doesn't try to
> > poloce things between EL1 and EL0, or between EL2 and EL0. Why should
> > it do so between EL2 and EL1 (or EL2 and L2 EL0)?
> >
> > Once you admit that the FP (and by extension SVE) registers are EL-agnostic,
> > the things that matter are:
>
> s/poloce/police/ ?
That.
>
> The above is a bit flowery; it would be nice to remove the rhetorical
> questions and just state that (aside from some control registers) the
> FPSIMD/SVE/SME state is shared between exception levels and doesn't need
> to be saved/restored.
>
> How about:
>
> When switching between L1 and L2, we save the old state using
> kvm_arch_vcpu_put(), mutate the state in memory, then load the new
> state using kvm_arch_vcpu_load(). Any live FPSIMD/SVE state is saved
> and unbound, such that it can be lazily restored on a subsequent trap.
>
> The FPSIMD/SVE state is shared by exception levels, and only a handful
> of related control registers need to be changed when transitioning
> between L1 and L2. The save/restore of the common state is needless
> overhead, especially as trapping becomes exponentially more expensive
> with nesting.
>
> Avoid this overhead by leaving the common FPSIMD/SVE state live on the
> CPU, and only switching the state that is distinct for L1 and L2:
>
Sold. Do you offer a CMAAS (Commit Message As A Service)? Asking for a
friend... ;-)
> > - the trap controls: the effective values are recomputed on each entry
> > into the guest to take the EL into account and merge the L0 and L1
> > configuration if in a nested context, or directly use the L0 configuration
> > in non-nested context (see __activate_traps()).
> >
> > - the VL settings: the effective values are are also recomputed on each
> > entry into the guest (see fpsimd_lazy_switch_to_guest()).
>
> This is true for FPSIMD+SVE today. For SME, SMCR_ELx also contains other
> controls, and will need to be dealt with similarly. It might be worth
> noting that (and that ZCR_ELx could gain new controls in future).
>
Yeah. I tried not to worry too much about SME, but given that it is on
people's radar, I'll drop a comment here.
> > Since we appear to cover all bases, use the vcpu flags indicating the
> > handling of a nested ERET or exception delivery to avoid the whole FP
> > save/restore shenanigans.
> >
> > For an EL1 L3 guest where L1 and L2 have this optimisation, this
> > results in at least a 10% wall clock reduction when running an I/O
> > heavy workload, generating a high rate of nested exceptions.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/fpsimd.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> > index 15e17aca1dec0..73eda0f46b127 100644
> > --- a/arch/arm64/kvm/fpsimd.c
> > +++ b/arch/arm64/kvm/fpsimd.c
> > @@ -28,6 +28,10 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > if (!system_supports_fpsimd())
> > return;
> >
> > + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> > + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION))
> > + return;
> > +
>
> I think we need a comment as to why this is safe, with some other detail
> from the commit message. It would also be good to have asserts here to
> catch if something goes wrong.
>
> How about:
>
> /*
> * Avoid needless save/restore of the guest's common
> * FPSIMD/SVE/SME regs during transitions between L1/L2.
> *
> * These transitions only happens in a non-preemptible context
> * where the host regs have already been saved and unbound. The
> * live registers are either free or owned by the guest.
> */
> if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION) {
> WARN_ON_ONCE(host_owns_fp_regs());
> return;
> }
>
> ... ?
>
> Note: I didn't add WARN_ON_ONCE(preemptible()), since
> kvm_arch_vcpu_load_fp() should *never* be called in a preemptible
> context.
>
> > /*
> > * Ensure that any host FPSIMD/SVE/SME state is saved and unbound such
> > * that the host kernel is responsible for restoring this state upon
> > @@ -102,6 +106,10 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> > {
> > unsigned long flags;
> >
> > + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> > + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION))
> > + return;
>
> Likewise here, but we can reduce the comment, e.g.
>
> /*
> * See comment in kvm_arch_vcpu_load_fp().
> */
> if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION) {
> WARN_ON_ONCE(host_owns_fp_regs());
> return;
> }
Yup, that all looks good to me. I'll repost that next week with these
changes.
Thanks again,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 2/8] media: dt-bindings: add rockchip rk3588 vicap
From: Rob Herring @ 2026-05-13 12:48 UTC (permalink / raw)
To: Michael Riesch
Cc: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Conor Dooley
In-Reply-To: <20260508-rk3588-vicap-v4-2-6a6cd6f7c90b@collabora.com>
On Fri, May 08, 2026 at 09:31:45PM +0200, Michael Riesch wrote:
> Add documentation for the Rockchip RK3588 Video Capture (VICAP) unit. To
> that end, make the existing rockchip,rk3568-vicap documentation more
> general and introduce variant specific constraints.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
> ---
> .../bindings/media/rockchip,rk3568-vicap.yaml | 187 ++++++++++++++++++---
> 1 file changed, 163 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
> index 18cd0a5a5318174910e04f6ef7558c92cbfec899..897ed00c239bdfe33777a8f8474fb27fa6265e49 100644
> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
> @@ -15,9 +15,15 @@ description:
> the data from camera sensors, video decoders, or other companion ICs and
> transfers it into system main memory by AXI bus.
>
> + The Rockchip RK3588 Video Capture (VICAP) is similar to its RK3568
> + counterpart, but features six MIPI CSI-2 ports and additional connections
> + to the image signal processor (ISP) blocks.
> +
> properties:
> compatible:
> - const: rockchip,rk3568-vicap
> + enum:
> + - rockchip,rk3568-vicap
> + - rockchip,rk3588-vicap
>
> reg:
> maxItems: 1
> @@ -26,37 +32,23 @@ properties:
> maxItems: 1
>
> clocks:
> - items:
> - - description: ACLK
> - - description: HCLK
> - - description: DCLK
> - - description: ICLK
> + minItems: 4
> + maxItems: 5
>
> clock-names:
> - items:
> - - const: aclk
> - - const: hclk
> - - const: dclk
> - - const: iclk
Just keep this here and add iclk1 on the end along with 'minItems: 4'.
> + minItems: 4
> + maxItems: 5
^ permalink raw reply
* [PATCH v8 3/4] clk: keystone: sci-clk: add restore_context() operation
From: Thomas Richard (TI) @ 2026-05-13 12:46 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
In-Reply-To: <20260513-ti-sci-jacinto-s2r-restore-irq-v8-0-195b27f91519@bootlin.com>
Implement the restore_context() operation to restore the clock rate and the
clock parent state. The clock rate is saved in sci_clk struct during
set_rate() and recalc_rate() operations. The parent index is saved in
sci_clk struct during set_parent() operation. During clock registration,
the core retrieves each clock’s parent using get_parent() operation to
ensure the internal clock tree reflects the actual hardware state,
including any configurations made by the bootloader. So we also save the
parent index in get_parent().
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/clk/keystone/sci-clk.c | 45 ++++++++++++++++++++++++++++++++++--------
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
index 9d5071223f4c..7c0f7b3e89e0 100644
--- a/drivers/clk/keystone/sci-clk.c
+++ b/drivers/clk/keystone/sci-clk.c
@@ -47,6 +47,8 @@ struct sci_clk_provider {
* @node: Link for handling clocks probed via DT
* @cached_req: Cached requested freq for determine rate calls
* @cached_res: Cached result freq for determine rate calls
+ * @parent_id: Parent index for this clock
+ * @rate: Clock rate
*/
struct sci_clk {
struct clk_hw hw;
@@ -58,6 +60,8 @@ struct sci_clk {
struct list_head node;
unsigned long cached_req;
unsigned long cached_res;
+ int parent_id;
+ unsigned long rate;
};
#define to_sci_clk(_hw) container_of(_hw, struct sci_clk, hw)
@@ -150,6 +154,8 @@ static unsigned long sci_clk_recalc_rate(struct clk_hw *hw,
return 0;
}
+ clk->rate = freq;
+
return freq;
}
@@ -210,10 +216,15 @@ static int sci_clk_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
struct sci_clk *clk = to_sci_clk(hw);
+ int ret;
- return clk->provider->ops->set_freq(clk->provider->sci, clk->dev_id,
- clk->clk_id, rate / 10 * 9, rate,
- rate / 10 * 11);
+ ret = clk->provider->ops->set_freq(clk->provider->sci, clk->dev_id,
+ clk->clk_id, rate / 10 * 9, rate,
+ rate / 10 * 11);
+ if (!ret)
+ clk->rate = rate;
+
+ return ret;
}
/**
@@ -234,12 +245,13 @@ static u8 sci_clk_get_parent(struct clk_hw *hw)
dev_err(clk->provider->dev,
"get-parent failed for dev=%d, clk=%d, ret=%d\n",
clk->dev_id, clk->clk_id, ret);
+ clk->parent_id = ret;
return 0;
}
- parent_id = parent_id - clk->clk_id - 1;
+ clk->parent_id = parent_id - clk->clk_id - 1;
- return (u8)parent_id;
+ return (u8)clk->parent_id;
}
/**
@@ -252,12 +264,28 @@ static u8 sci_clk_get_parent(struct clk_hw *hw)
static int sci_clk_set_parent(struct clk_hw *hw, u8 index)
{
struct sci_clk *clk = to_sci_clk(hw);
+ int ret;
clk->cached_req = 0;
- return clk->provider->ops->set_parent(clk->provider->sci, clk->dev_id,
- clk->clk_id,
- index + 1 + clk->clk_id);
+ ret = clk->provider->ops->set_parent(clk->provider->sci, clk->dev_id,
+ clk->clk_id,
+ index + 1 + clk->clk_id);
+ if (!ret)
+ clk->parent_id = index;
+
+ return ret;
+}
+
+static void sci_clk_restore_context(struct clk_hw *hw)
+{
+ struct sci_clk *clk = to_sci_clk(hw);
+
+ if (clk->num_parents > 1 && clk->parent_id >= 0)
+ sci_clk_set_parent(hw, (u8)clk->parent_id);
+
+ if (clk->rate)
+ sci_clk_set_rate(hw, clk->rate, 0);
}
static const struct clk_ops sci_clk_ops = {
@@ -269,6 +297,7 @@ static const struct clk_ops sci_clk_ops = {
.set_rate = sci_clk_set_rate,
.get_parent = sci_clk_get_parent,
.set_parent = sci_clk_set_parent,
+ .restore_context = sci_clk_restore_context,
};
/**
--
2.53.0
^ permalink raw reply related
* [PATCH v8 4/4] firmware: ti_sci: add support for restoring clock context during resume
From: Thomas Richard (TI) @ 2026-05-13 12:46 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
In-Reply-To: <20260513-ti-sci-jacinto-s2r-restore-irq-v8-0-195b27f91519@bootlin.com>
Some DM-Firmware are not able to restore the clock rates and the clock
parents after a suspend-resume. The CLK_CONTEXT_LOST firmware capability
has been introduced to identify this characteristic. In this case the
responsibility is therefore delegated to the ti_sci driver, which uses
clk_restore_context() to trigger the context_restore() operation for all
registered clocks, including those managed by the sci-clk. The sci-clk
driver implements the context_restore() operation to ensure rates and clock
parents are correctly restored.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/firmware/ti_sci.c | 9 +++++++--
drivers/firmware/ti_sci.h | 3 +++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 35ee8cc830c8..1e58560b1dd6 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -9,6 +9,7 @@
#define pr_fmt(fmt) "%s: " fmt, __func__
#include <linux/bitmap.h>
+#include <linux/clk.h>
#include <linux/cpu.h>
#include <linux/debugfs.h>
#include <linux/export.h>
@@ -4022,6 +4023,9 @@ static int ti_sci_resume_noirq(struct device *dev)
}
}
}
+
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST)
+ clk_restore_context();
break;
default:
break;
@@ -4182,14 +4186,15 @@ static int ti_sci_probe(struct platform_device *pdev)
}
ti_sci_msg_cmd_query_fw_caps(&info->handle, &info->fw_caps);
- dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s%s%s\n",
+ dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s%s%s%s\n",
info->fw_caps & MSG_FLAG_CAPS_GENERIC ? "Generic" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_PARTIAL_IO ? " Partial-IO" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_DM_MANAGED ? " DM-Managed" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_ABORT ? " LPM-Abort" : "",
info->fw_caps & MSG_FLAG_CAPS_IO_ISOLATION ? " IO-Isolation" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED ? " BoardConfig-Managed" : "",
- info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST ? " IRQ-Context-Lost" : ""
+ info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST ? " IRQ-Context-Lost" : "",
+ info->fw_caps & MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST ? " Clk-Context-Lost" : ""
);
ti_sci_setup_ops(info);
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index ad69c765d614..8fccbcd1c9a2 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -154,6 +154,8 @@ struct ti_sci_msg_req_reboot {
* for the DM via boardcfg
* MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST: DM is not able to restore IRQ
* context
+ * MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST: DM is not able to restore
+ * Clock context
*
* Response to a generic message with message type TI_SCI_MSG_QUERY_FW_CAPS
* providing currently available SOC/firmware capabilities. SoC that don't
@@ -168,6 +170,7 @@ struct ti_sci_msg_resp_query_fw_caps {
#define MSG_FLAG_CAPS_IO_ISOLATION TI_SCI_MSG_FLAG(7)
#define MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED TI_SCI_MSG_FLAG(12)
#define MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST TI_SCI_MSG_FLAG(14)
+#define MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST TI_SCI_MSG_FLAG(15)
#define MSG_MASK_CAPS_LPM GENMASK_ULL(4, 1)
u64 fw_caps;
} __packed;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 2/4] firmware: ti_sci: add support for restoring IRQs during resume
From: Thomas Richard (TI) @ 2026-05-13 12:46 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
In-Reply-To: <20260513-ti-sci-jacinto-s2r-restore-irq-v8-0-195b27f91519@bootlin.com>
Some DM-Firmware are not able to restore the IRQ context after a
suspend-resume. The IRQ_CONTEXT_LOST firmware capability has been
introduced to identify this characteristic. In this case the
responsibility is delegated to the ti_sci driver, which maintains an
internal list of all requested IRQs. This list is updated on each
set()/free() operation, and all IRQs are restored during the resume_noirq()
phase.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/firmware/ti_sci.c | 201 +++++++++++++++++++++++++++++++++++++++++++---
drivers/firmware/ti_sci.h | 3 +
2 files changed, 192 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index eaeaaae94142..35ee8cc830c8 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -12,11 +12,13 @@
#include <linux/cpu.h>
#include <linux/debugfs.h>
#include <linux/export.h>
+#include <linux/hashtable.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/kernel.h>
#include <linux/mailbox_client.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
@@ -87,6 +89,16 @@ struct ti_sci_desc {
int max_msg_size;
};
+/**
+ * struct ti_sci_irq - Description of allocated irqs
+ * @node: Link to hash table
+ * @desc: Description of the irq
+ */
+struct ti_sci_irq {
+ struct hlist_node node;
+ struct ti_sci_msg_req_manage_irq desc;
+};
+
/**
* struct ti_sci_info - Structure representing a TI SCI instance
* @dev: Device pointer
@@ -101,6 +113,8 @@ struct ti_sci_desc {
* @chan_rx: Receive mailbox channel
* @minfo: Message info
* @node: list head
+ * @irqs: List of allocated irqs
+ * @irq_lock: Protection for irq hash list
* @host_id: Host ID
* @fw_caps: FW/SoC low power capabilities
* @users: Number of users of this instance
@@ -118,6 +132,8 @@ struct ti_sci_info {
struct mbox_chan *chan_rx;
struct ti_sci_xfers_info minfo;
struct list_head node;
+ DECLARE_HASHTABLE(irqs, 8);
+ struct mutex irq_lock;
u8 host_id;
u64 fw_caps;
/* protected by ti_sci_list_mutex */
@@ -2301,6 +2317,32 @@ static int ti_sci_manage_irq(const struct ti_sci_handle *handle,
return ret;
}
+/**
+ * ti_sci_irq_hash() - Helper API to compute irq hash for the hash table.
+ * @irq: irq to hash
+ *
+ * Return: the computed hash value.
+ */
+static int ti_sci_irq_hash(struct ti_sci_msg_req_manage_irq *irq)
+{
+ return irq->src_id ^ irq->src_index;
+}
+
+/**
+ * ti_sci_irq_equal() - Helper API to compare two irqs (generic headers are not
+ * compared)
+ * @irq_a: irq_a to compare
+ * @irq_b: irq_b to compare
+ *
+ * Return: true if the two irqs are equal, else false.
+ */
+static bool ti_sci_irq_equal(struct ti_sci_msg_req_manage_irq *irq_a,
+ struct ti_sci_msg_req_manage_irq *irq_b)
+{
+ return !memcmp(&irq_a->valid_params, &irq_b->valid_params,
+ sizeof(*irq_a) - sizeof(irq_a->hdr));
+}
+
/**
* ti_sci_set_irq() - Helper api to configure the irq route between the
* requested source and destination
@@ -2324,15 +2366,60 @@ static int ti_sci_set_irq(const struct ti_sci_handle *handle, u32 valid_params,
u16 dst_host_irq, u16 ia_id, u16 vint,
u16 global_event, u8 vint_status_bit, u8 s_host)
{
+ struct ti_sci_info *info = handle_to_ti_sci_info(handle);
+ struct ti_sci_msg_req_manage_irq *desc;
+ struct ti_sci_irq *irq;
+ int ret;
+
+ /*
+ * Lock for set_irq() and free_irq() to keep the IRQ hash list
+ * consistent only if MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST is set. Else
+ * IRQ hash list is not used.
+ */
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST)
+ mutex_lock(&info->irq_lock);
+
pr_debug("%s: IRQ set with valid_params = 0x%x from src = %d, index = %d, to dst = %d, irq = %d,via ia_id = %d, vint = %d, global event = %d,status_bit = %d\n",
__func__, valid_params, src_id, src_index,
dst_id, dst_host_irq, ia_id, vint, global_event,
vint_status_bit);
- return ti_sci_manage_irq(handle, valid_params, src_id, src_index,
- dst_id, dst_host_irq, ia_id, vint,
- global_event, vint_status_bit, s_host,
- TI_SCI_MSG_SET_IRQ);
+ ret = ti_sci_manage_irq(handle, valid_params, src_id, src_index,
+ dst_id, dst_host_irq, ia_id, vint,
+ global_event, vint_status_bit, s_host,
+ TI_SCI_MSG_SET_IRQ);
+
+ if (ret || !(info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST))
+ goto end;
+
+ irq = kzalloc_obj(*irq, GFP_KERNEL);
+ if (!irq) {
+ ti_sci_manage_irq(handle, valid_params, src_id, src_index,
+ dst_id, dst_host_irq, ia_id, vint,
+ global_event, vint_status_bit, s_host,
+ TI_SCI_MSG_FREE_IRQ);
+ ret = -ENOMEM;
+ goto end;
+ }
+
+ desc = &irq->desc;
+ desc->valid_params = valid_params;
+ desc->src_id = src_id;
+ desc->src_index = src_index;
+ desc->dst_id = dst_id;
+ desc->dst_host_irq = dst_host_irq;
+ desc->ia_id = ia_id;
+ desc->vint = vint;
+ desc->global_event = global_event;
+ desc->vint_status_bit = vint_status_bit;
+ desc->secondary_host = s_host;
+
+ hash_add(info->irqs, &irq->node, ti_sci_irq_hash(desc));
+
+end:
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST)
+ mutex_unlock(&info->irq_lock);
+ return ret;
}
/**
@@ -2358,15 +2445,56 @@ static int ti_sci_free_irq(const struct ti_sci_handle *handle, u32 valid_params,
u16 dst_host_irq, u16 ia_id, u16 vint,
u16 global_event, u8 vint_status_bit, u8 s_host)
{
+ struct ti_sci_info *info = handle_to_ti_sci_info(handle);
+ struct ti_sci_msg_req_manage_irq irq_desc;
+ struct device *dev = info->dev;
+ struct ti_sci_irq *this_irq;
+ struct hlist_node *tmp_node;
+ int ret;
+
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST)
+ mutex_lock(&info->irq_lock);
+
pr_debug("%s: IRQ release with valid_params = 0x%x from src = %d, index = %d, to dst = %d, irq = %d,via ia_id = %d, vint = %d, global event = %d,status_bit = %d\n",
__func__, valid_params, src_id, src_index,
dst_id, dst_host_irq, ia_id, vint, global_event,
vint_status_bit);
- return ti_sci_manage_irq(handle, valid_params, src_id, src_index,
- dst_id, dst_host_irq, ia_id, vint,
- global_event, vint_status_bit, s_host,
- TI_SCI_MSG_FREE_IRQ);
+ ret = ti_sci_manage_irq(handle, valid_params, src_id, src_index,
+ dst_id, dst_host_irq, ia_id, vint,
+ global_event, vint_status_bit, s_host,
+ TI_SCI_MSG_FREE_IRQ);
+
+ if (ret || !(info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST))
+ goto end;
+
+ irq_desc.valid_params = valid_params;
+ irq_desc.src_id = src_id;
+ irq_desc.src_index = src_index;
+ irq_desc.dst_id = dst_id;
+ irq_desc.dst_host_irq = dst_host_irq;
+ irq_desc.ia_id = ia_id;
+ irq_desc.vint = vint;
+ irq_desc.global_event = global_event;
+ irq_desc.vint_status_bit = vint_status_bit;
+ irq_desc.secondary_host = s_host;
+
+ hash_for_each_possible_safe(info->irqs, this_irq, tmp_node, node,
+ ti_sci_irq_hash(&irq_desc)) {
+ if (ti_sci_irq_equal(&irq_desc, &this_irq->desc)) {
+ hlist_del(&this_irq->node);
+ kfree(this_irq);
+ goto end;
+ }
+ }
+
+ dev_warn(dev, "%s: should not be here, IRQ was not found in hash list\n",
+ __func__);
+
+end:
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST)
+ mutex_unlock(&info->irq_lock);
+ return ret;
}
/**
@@ -3847,7 +3975,10 @@ static int ti_sci_suspend_noirq(struct device *dev)
static int ti_sci_resume_noirq(struct device *dev)
{
struct ti_sci_info *info = dev_get_drvdata(dev);
- int ret = 0;
+ struct ti_sci_msg_req_manage_irq *irq_desc;
+ struct ti_sci_irq *irq;
+ struct hlist_node *tmp_node;
+ int ret = 0, err = 0, i;
u32 source;
u64 time;
u8 pin;
@@ -3859,13 +3990,50 @@ static int ti_sci_resume_noirq(struct device *dev)
return ret;
}
+ switch (pm_suspend_target_state) {
+ case PM_SUSPEND_MEM:
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST) {
+ hash_for_each_safe(info->irqs, i, tmp_node, irq, node) {
+ irq_desc = &irq->desc;
+ ret = ti_sci_manage_irq(&info->handle,
+ irq_desc->valid_params,
+ irq_desc->src_id,
+ irq_desc->src_index,
+ irq_desc->dst_id,
+ irq_desc->dst_host_irq,
+ irq_desc->ia_id,
+ irq_desc->vint,
+ irq_desc->global_event,
+ irq_desc->vint_status_bit,
+ irq_desc->secondary_host,
+ TI_SCI_MSG_SET_IRQ);
+ if (ret) {
+ dev_err(dev, "failed to restore IRQ with valid_params = 0x%x from src = %d, index = %d, to dst = %d, irq = %d, via ia_id = %d, vint = %d, global event = %d,status_bit = %d\n",
+ irq_desc->valid_params,
+ irq_desc->src_id,
+ irq_desc->src_index,
+ irq_desc->dst_id,
+ irq_desc->dst_host_irq,
+ irq_desc->ia_id,
+ irq_desc->vint,
+ irq_desc->global_event,
+ irq_desc->vint_status_bit);
+ err = ret;
+ }
+ }
+ }
+ break;
+ default:
+ break;
+ }
+
ret = ti_sci_msg_cmd_lpm_wake_reason(&info->handle, &source, &time, &pin, &mode);
/* Do not fail to resume on error as the wake reason is not critical */
if (!ret)
dev_info(dev, "ti_sci: wakeup source:0x%x, pin:0x%x, mode:0x%x\n",
source, pin, mode);
- return 0;
+ return err;
}
static void ti_sci_pm_complete(struct device *dev)
@@ -4014,13 +4182,14 @@ static int ti_sci_probe(struct platform_device *pdev)
}
ti_sci_msg_cmd_query_fw_caps(&info->handle, &info->fw_caps);
- dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s%s\n",
+ dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s%s%s\n",
info->fw_caps & MSG_FLAG_CAPS_GENERIC ? "Generic" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_PARTIAL_IO ? " Partial-IO" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_DM_MANAGED ? " DM-Managed" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_ABORT ? " LPM-Abort" : "",
info->fw_caps & MSG_FLAG_CAPS_IO_ISOLATION ? " IO-Isolation" : "",
- info->fw_caps & MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED ? " BoardConfig-Managed" : ""
+ info->fw_caps & MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED ? " BoardConfig-Managed" : "",
+ info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST ? " IRQ-Context-Lost" : ""
);
ti_sci_setup_ops(info);
@@ -4053,6 +4222,14 @@ static int ti_sci_probe(struct platform_device *pdev)
list_add_tail(&info->node, &ti_sci_list);
mutex_unlock(&ti_sci_list_mutex);
+ if (info->fw_caps & MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST) {
+ ret = devm_mutex_init(dev, &info->irq_lock);
+ if (ret)
+ goto out;
+
+ hash_init(info->irqs);
+ }
+
ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "platform_populate failed %pe\n", ERR_PTR(ret));
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index d5e06769b01c..ad69c765d614 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -152,6 +152,8 @@ struct ti_sci_msg_req_reboot {
* MSG_FLAG_CAPS_IO_ISOLATION: IO Isolation support
* MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED: LPM config done statically
* for the DM via boardcfg
+ * MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST: DM is not able to restore IRQ
+ * context
*
* Response to a generic message with message type TI_SCI_MSG_QUERY_FW_CAPS
* providing currently available SOC/firmware capabilities. SoC that don't
@@ -165,6 +167,7 @@ struct ti_sci_msg_resp_query_fw_caps {
#define MSG_FLAG_CAPS_LPM_ABORT TI_SCI_MSG_FLAG(9)
#define MSG_FLAG_CAPS_IO_ISOLATION TI_SCI_MSG_FLAG(7)
#define MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED TI_SCI_MSG_FLAG(12)
+#define MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST TI_SCI_MSG_FLAG(14)
#define MSG_MASK_CAPS_LPM GENMASK_ULL(4, 1)
u64 fw_caps;
} __packed;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 1/4] firmware: ti_sci: add BOARDCFG_MANAGED mode support
From: Thomas Richard (TI) @ 2026-05-13 12:46 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
In-Reply-To: <20260513-ti-sci-jacinto-s2r-restore-irq-v8-0-195b27f91519@bootlin.com>
In BOARDCFG_MANAGED mode, the low power mode configuration is done
statically for the DM via the boardcfg. Constraints are not supported, and
prepare_sleep() is not needed.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/firmware/ti_sci.c | 10 +++++++---
drivers/firmware/ti_sci.h | 3 +++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index dd9911b1cc11..eaeaaae94142 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -3772,8 +3772,11 @@ static int ti_sci_prepare_system_suspend(struct ti_sci_info *info)
return ti_sci_cmd_prepare_sleep(&info->handle,
TISCI_MSG_VALUE_SLEEP_MODE_DM_MANAGED,
0, 0, 0);
+ } else if (info->fw_caps & MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED) {
+ /* Nothing to do in the BOARDCFG_MANAGED mode */
+ return 0;
} else {
- /* DM Managed is not supported by the firmware. */
+ /* DM Managed and BoardCfg Managed are not supported by the firmware. */
dev_err(info->dev, "Suspend to memory is not supported by the firmware\n");
return -EOPNOTSUPP;
}
@@ -4011,12 +4014,13 @@ static int ti_sci_probe(struct platform_device *pdev)
}
ti_sci_msg_cmd_query_fw_caps(&info->handle, &info->fw_caps);
- dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s\n",
+ dev_dbg(dev, "Detected firmware capabilities: %s%s%s%s%s%s\n",
info->fw_caps & MSG_FLAG_CAPS_GENERIC ? "Generic" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_PARTIAL_IO ? " Partial-IO" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_DM_MANAGED ? " DM-Managed" : "",
info->fw_caps & MSG_FLAG_CAPS_LPM_ABORT ? " LPM-Abort" : "",
- info->fw_caps & MSG_FLAG_CAPS_IO_ISOLATION ? " IO-Isolation" : ""
+ info->fw_caps & MSG_FLAG_CAPS_IO_ISOLATION ? " IO-Isolation" : "",
+ info->fw_caps & MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED ? " BoardConfig-Managed" : ""
);
ti_sci_setup_ops(info);
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index 4616127e33ff..d5e06769b01c 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -150,6 +150,8 @@ struct ti_sci_msg_req_reboot {
* MSG_FLAG_CAPS_LPM_DM_MANAGED: LPM can be managed by DM
* MSG_FLAG_CAPS_LPM_ABORT: Abort entry to LPM
* MSG_FLAG_CAPS_IO_ISOLATION: IO Isolation support
+ * MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED: LPM config done statically
+ * for the DM via boardcfg
*
* Response to a generic message with message type TI_SCI_MSG_QUERY_FW_CAPS
* providing currently available SOC/firmware capabilities. SoC that don't
@@ -162,6 +164,7 @@ struct ti_sci_msg_resp_query_fw_caps {
#define MSG_FLAG_CAPS_LPM_DM_MANAGED TI_SCI_MSG_FLAG(5)
#define MSG_FLAG_CAPS_LPM_ABORT TI_SCI_MSG_FLAG(9)
#define MSG_FLAG_CAPS_IO_ISOLATION TI_SCI_MSG_FLAG(7)
+#define MSG_FLAG_CAPS_LPM_BOARDCFG_MANAGED TI_SCI_MSG_FLAG(12)
#define MSG_MASK_CAPS_LPM GENMASK_ULL(4, 1)
u64 fw_caps;
} __packed;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/4] firmware: ti_sci: Introduce BOARDCFG_MANAGED mode for Jacinto family
From: Thomas Richard (TI) @ 2026-05-13 12:46 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Brian Masney
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Abhash Kumar,
Thomas Petazzoni, linux-arm-kernel, linux-kernel, linux-clk,
Thomas Richard (TI), Dhruva Gole, Kendall Willis
This is the 8th iteration of this series. I fixed the error path in ti_sci
driver if devm_mutex_init() fails. Other changes are nitpicks.
Best Regards,
Thomas
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
Changes in v8:
- ti_sci: fix error path if devm_mutex_init() fails.
- ti_sci: fix error message in ti_sci_resume_noirq().
- ti_sci: keep some lines under 100 chars in ti_sci header file.
- Link to v7: https://lore.kernel.org/r/20260506-ti-sci-jacinto-s2r-restore-irq-v7-0-037098a35215@bootlin.com
Changes in v7:
- ti_sci: add a lock around set_irq() and free_irq() to keep hash list
consistent.
- ti_sci: in free_irq() add warning in case we are in a path that shall not
be run.
- ti_sci: free an IRQ if we failed to add it in the hash list.
- ti_sci: during resume in case of error, try to restore remaining IRQs and
logs all errors, then return the latest one.
- sci-clk: add Stephen's AB tag and Brian's RB tag.
- sci-clk: handle get_parent() error, in restore_context() do not call
set_parent() with parent_id=0 if get_parent() failed.
- Link to v6: https://lore.kernel.org/r/20260427-ti-sci-jacinto-s2r-restore-irq-v6-0-72c6468cb2ab@bootlin.com
Changes in v6:
- rebase on v7.1-rc1.
- add Kendall's RB tag.
- sci-clk: call set_parent() during restore_context() only for clocks which
have more than one parent.
- sci-clk: save also rate returned by recalc_rate().
- Link to v5: https://lore.kernel.org/r/20260407-ti-sci-jacinto-s2r-restore-irq-v5-0-97b28f2d93f9@bootlin.com
Changes in v5:
- rebase on v7.0-rc7.
- add Dhruva's RB tag.
- use kzalloc_obj() in ti_sci driver.
- Link to v4: https://lore.kernel.org/r/20260204-ti-sci-jacinto-s2r-restore-irq-v4-0-67820af39eac@bootlin.com
Changes in v4:
- rebase on linux-next next-20260202.
- fix BOARDCFG_MANAGED value.
- add MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST firmware capability.
- add MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST firmware capability.
- Link to v3: https://lore.kernel.org/r/20251205-ti-sci-jacinto-s2r-restore-irq-v3-0-d06963974ad4@bootlin.com
Changes in v3:
- rebased on linux-next
- sci-clk: context_restore() operation restores also rate.
- Link to v2: https://lore.kernel.org/r/20251127-ti-sci-jacinto-s2r-restore-irq-v2-0-a487fa3ff221@bootlin.com
Changes in v2:
- ti_sci: use hlist to store IRQs.
- sci-clk: add context_restore operation
- ti_sci: restore clock parents during resume
- Link to v1: https://lore.kernel.org/r/20251017-ti-sci-jacinto-s2r-restore-irq-v1-0-34d4339d247a@bootlin.com
---
Thomas Richard (TI) (4):
firmware: ti_sci: add BOARDCFG_MANAGED mode support
firmware: ti_sci: add support for restoring IRQs during resume
clk: keystone: sci-clk: add restore_context() operation
firmware: ti_sci: add support for restoring clock context during resume
drivers/clk/keystone/sci-clk.c | 45 +++++++--
drivers/firmware/ti_sci.c | 212 ++++++++++++++++++++++++++++++++++++++---
drivers/firmware/ti_sci.h | 9 ++
3 files changed, 245 insertions(+), 21 deletions(-)
---
base-commit: 3d7e5414e6ab597dd3ea33fff6ae202d376539fa
change-id: 20251010-ti-sci-jacinto-s2r-restore-irq-428e008fd10c
Best regards,
--
Thomas Richard (TI) <thomas.richard@bootlin.com>
^ permalink raw reply
* [PATCH v4 0/6] Exynos-pmu: Generalise cpu{hotplug,idle},PMU intr gen and add Exynos850 CPU hotplug
From: Alexey Klimov @ 2026-05-13 12:37 UTC (permalink / raw)
To: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, Conor Dooley, Alim Akhtar
Cc: André Draszik, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, Henrik Grimler, linux-arm-kernel, devicetree,
linux-kernel
Series generalises the GS101-specific cpuhotplug, cpuidle and PMU interrupt
generation block support, which is currently implemented specifically for
the google GS101 SoC, to make it reusable by other Samsung Exynos SoCs.
The PMU interrupt generation IP block introduced for google GS101 is a
standard Samsung Exynos block found in other SoCs, including Exynos850,
and it is not strictly exclusive to google Exynos-based platforms.
Access to this block is required to implement and enable cpuhotplug
on Exynos850-based boards.
As a next steps it will be possible to enable idle states on top of it.
First patches work on DT bindings to reflect that Exynos850 SoC predates
gs101 one and adding mandatory property 'google,pmu-intr-gen-syscon'
for exynos850-pmu.
Then series generalises ("Exynosizes") cpuhotplug/cpuidle routines by
deferring platform-specific PMU and PMU-intr-gen updates to platform-
specific callbacks and then finally introduces new file exynos850-pmu.c
where such callbacks are implemented for Exynos850. Last commit adds
pmu_intr_gen DT node to exynos850.dtsi.
This series was tested on Exynos850 WinLink E850-96 board:
-- by spinning "chcpu -d 1-7; chcpu -e 1-7" in a loop for a few hours;
-- by running script [1] that randomly offlines or onlines random cpus
for a few hours.
I tried to implement it in way to not break anything for gs101, thanks to
Peter for testing.
Thanks,
Alexey
[1]: https://github.com/laklimov/xlam/blob/main/e850_cpuhotplug_random.sh
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
Changes in v4:
- remove blank line in file exynos850-pmu.c, commit (as suggested by Krzysztof);
- only update trailers/tags in commit messages;
- Link to v3: https://lore.kernel.org/r/20260430-exynos850-cpuhotplug-v3-0-fd6251d02a17@linaro.org
Changes in v3:
- dropped two commits where samsung,pmu-intr-gen phandle is introduced and
where google,pmu-intr-gen-syscon is deprecated (as suggested by Rob Herring);
- addtion to maintainers file was moved to separate entry, change commit message;
- commit message in "generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs"
was updated since it no longer touches samsung,pmu-intr-gen-syscon;
- added missing asm/cputype.h header to exynos850-pmu.h
(reported by Henrik Grimler);
- new commit "dt-bindings: soc: samsung: exynos-pmu: Require
pmu-intr-gen-syscon for Exynos850";
- Link to v2: https://lore.kernel.org/r/20260401-exynos850-cpuhotplug-v2-0-c5a760a3e259@linaro.org
Changes in v2:
- moved gs101 cpu {offline,online} callbacks to gs101-pmu.c, updated MAINTAINERS;
- added new file exynos850-pmu.c with cpu {offline,online} callbacks and
exynos850 pmu data;
- new patch that adds exynos850-pmu.c to MAINTAINERS;
- moved pmu_intr_gen to right after pmu_system_controller@11860000;
- merged two patches that update google,gs101-pmu-intr-gen.yaml together,
now rename and adding exynos850 entry goes in a single patch;
- commits 5 and 6 from RFC series are merged together and reworked,
cpu_pmu_{offline,online} callbacks are moved into pmu_data struct, and
callbacks now need pmu_context as an argument, exynos_pmu_context and
CPU_INFORM defines are moved to exynos-pmu.h, gs101 callbacks
renamed. It is really better to check commit description.
- Link to RFC (v1 from b4 point of view):
https://lore.kernel.org/r/20260226-exynos850-cpuhotplug-v1-0-71d7c4063382@linaro.org
---
Alexey Klimov (6):
dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
dt-bindings: soc: samsung: exynos-pmu: Require pmu-intr-gen-syscon for Exynos850
soc: samsung: exynos-pmu: generalise gs101-specific cpu{idle,hotplug} for Exynos SoCs
soc: samsung: exynos-pmu: add Exynos850 CPU hotplug support
MAINTAINERS: add Exynos850 PMU entry
arm64: dts: exynos850: add PMU interrupt generation node
.../bindings/soc/samsung/exynos-pmu.yaml | 1 +
.../samsung,exynos850-pmu-intr-gen.yaml} | 8 +-
MAINTAINERS | 9 +-
arch/arm64/boot/dts/exynos/exynos850.dtsi | 6 ++
drivers/soc/samsung/Makefile | 2 +-
drivers/soc/samsung/exynos-pmu.c | 119 ++++-----------------
drivers/soc/samsung/exynos-pmu.h | 32 ++++++
drivers/soc/samsung/exynos850-pmu.c | 78 ++++++++++++++
drivers/soc/samsung/gs101-pmu.c | 57 ++++++++++
include/linux/soc/samsung/exynos-regs-pmu.h | 15 ++-
10 files changed, 221 insertions(+), 106 deletions(-)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260226-exynos850-cpuhotplug-69f1976eefa8
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ 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