* [PATCH v13 08/27] drm/display: hdmi-state-helper: Act on color format DRM property
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
With the introduction of the "color format" DRM property, which allows
userspace to request a specific color format, the HDMI state helper
should implement this.
Implement it by translating the requested drm_connector_color_format to
a drm_output_color_format enum value as per the logic HDMI should use
for this: Auto is translated to RGB, and a fallback to YUV420 is only
performed if the original color format was auto.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 31 +++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index a0d88701d236..954f8b2973fc 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -670,8 +670,39 @@ hdmi_compute_config(const struct drm_connector *connector,
unsigned int max_bpc = clamp_t(unsigned int,
conn_state->max_bpc,
8, connector->max_bpc);
+ enum drm_output_color_format fmt;
int ret;
+ if (conn_state->color_format != DRM_CONNECTOR_COLOR_FORMAT_AUTO) {
+ switch (conn_state->color_format) {
+ case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
+ drm_warn(connector->dev, "AUTO format in non-AUTO path.\n");
+ fallthrough;
+ case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
+ fmt = DRM_OUTPUT_COLOR_FORMAT_RGB444;
+ break;
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
+ fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR444;
+ break;
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
+ fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR422;
+ break;
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
+ fmt = DRM_OUTPUT_COLOR_FORMAT_YCBCR420;
+ break;
+ default:
+ drm_dbg_kms(connector->dev, "HDMI does not support color format '%d'.\n",
+ conn_state->color_format);
+ return -EINVAL;
+ }
+
+ return hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc, fmt);
+ }
+
+ /*
+ * For %DRM_CONNECTOR_COLOR_FORMAT_AUTO, try RGB first, and fall back
+ * to the less bandwidth-intensive YCBCR420 if RGB fails.
+ */
ret = hdmi_compute_format_bpc(connector, conn_state, mode, max_bpc,
DRM_OUTPUT_COLOR_FORMAT_RGB444);
if (ret) {
--
2.53.0
^ permalink raw reply related
* [PATCH v13 07/27] drm/atomic-helper: Add HDMI bridge output bus formats helper
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
The drm_bridge_funcs atomic_get_output_bus_fmts operation should be the
same for likely every HDMI connector bridge, unless such an HDMI
connector bridge has some special hardware restrictions that I cannot
envision yet.
To avoid code duplication and standardize on a set of media bus formats
that the HDMI output color formats translate to, add a common helper
function that implements this operation to the drm bridge helpers.
The function returns a list of output bus formats based on the HDMI
bridge's current output bits-per-component, and its bitmask of supported
color formats.
To guard against future expansion of DRM_OUTPUT_COLOR_FORMAT outgrowing
the hweight8 call, add a BUILD_BUG_ON statement where it's used that
checks for DRM_OUTPUT_COLOR_FORMAT_COUNT. The justification for not
using hweight32 in all cases is that not all ISAs have a popcount
instruction, and will benefit from a smaller/faster software
implementation that doesn't have to operate across all bits.
The justification for not defining an hweight_color depending on the
value of DRM_OUTPUT_COLOR_FORMAT_COUNT is that this count enum value is
only known at compile time, not at preprocessor time.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 81 +++++++++++++++++++++++++++++++++++++
include/drm/drm_atomic_helper.h | 7 ++++
2 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 0de9748a82c6..9e62a24ab4b4 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -28,6 +28,7 @@
#include <linux/export.h>
#include <linux/dma-fence.h>
#include <linux/ktime.h>
+#include <linux/media-bus-format.h>
#include <drm/drm_atomic.h>
#include <drm/drm_atomic_helper.h>
@@ -4095,3 +4096,83 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
return input_fmts;
}
EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
+
+/**
+ * drm_atomic_helper_bridge_get_hdmi_output_bus_fmts - helper implementing
+ * atomic_get_output_bus_fmts for HDMI
+ * @bridge: pointer to &struct drm_bridge
+ * @bridge_state: pointer to the current bridge state
+ * @crtc_state: pointer to the current CRTC state
+ * @conn_state: pointer to the current connector state
+ * @num_output_fmts: pointer to where the number of entries in the returned array
+ * will be stored. Set to 0 if unsuccessful.
+ *
+ * Common implementation for the &drm_bridge_funcs.atomic_get_output_bus_fmts
+ * operation that's applicable to HDMI connectors.
+ *
+ * Returns: a newly allocated array of u32 values of length \*@num_output_fmts,
+ * representing all the MEDIA_BUS_FMTS\_ for the current connector state's
+ * chosen HDMI output bits per compoennt, or %NULL if it fails to allocate one.
+ */
+u32 *
+drm_atomic_helper_bridge_get_hdmi_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts)
+{
+ unsigned int num_fmts = 0;
+ u32 *out_fmts;
+
+ /*
+ * bridge->supported_formats is a bit field of BIT(enum drm_output_color_format)
+ * values. The smallest hweight that is smaller than or equal to
+ * %DRM_OUTPUT_COLOR_FORMAT_COUNT will do for counting set bits here.
+ */
+ BUILD_BUG_ON(const_true(DRM_OUTPUT_COLOR_FORMAT_COUNT > 8));
+ out_fmts = kmalloc_array(hweight8(bridge->supported_formats),
+ sizeof(u32), GFP_KERNEL);
+ if (!out_fmts) {
+ *num_output_fmts = 0;
+ return NULL;
+ }
+
+ switch (conn_state->hdmi.output_bpc) {
+ case 12:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB121212_1X36;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV12_1X36;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY12_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY12_0_5X36;
+ break;
+ case 10:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB101010_1X30;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV10_1X30;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY10_1X20;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY10_0_5X30;
+ break;
+ default:
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_RGB888_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_YUV8_1X24;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYVY8_1X16;
+ if (bridge->supported_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420))
+ out_fmts[num_fmts++] = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
+ break;
+ }
+
+ *num_output_fmts = num_fmts;
+
+ return out_fmts;
+}
+EXPORT_SYMBOL(drm_atomic_helper_bridge_get_hdmi_output_bus_fmts);
+
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index e154ee4f0696..7256eaca109b 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -295,4 +295,11 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
u32 output_fmt,
unsigned int *num_input_fmts);
+u32 *
+drm_atomic_helper_bridge_get_hdmi_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts);
+
#endif /* DRM_ATOMIC_HELPER_H_ */
--
2.53.0
^ permalink raw reply related
* [PATCH v13 06/27] drm/bridge: Act on the DRM color format property
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
The new DRM color format property allows userspace to request a specific
color format on a connector. In turn, this fills the connector state's
color_format member to switch color formats.
Make drm_bridges consider the color_format set in the connector state
during the atomic bridge check. Call into the connector function to get
the connector state's connector color format. For bridge connectors
including an HDMI bridge, this will make use of whatever the HDMI
implementation set as output formats, and AUTO will never be part of the
rejection logic.
Reject any output bus formats that do not correspond to the requested
color format. DRM_CONNECTOR_COLOR_FORMAT_AUTO is always accepted as a
matching color format for a bus format, meaning that non-HDMI bridge
chains will end up picking the first bus format choice that works, as
has already been the case previously.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_bridge.c | 64 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index ba80bebb5685..5acd6bf84ae2 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1150,6 +1150,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
return ret;
}
+static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_connector_color_format fmt)
+{
+ if (fmt == DRM_CONNECTOR_COLOR_FORMAT_AUTO)
+ return true;
+
+ switch (bus_fmt) {
+ case MEDIA_BUS_FMT_FIXED:
+ return true;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ case MEDIA_BUS_FMT_RGB101010_1X30:
+ case MEDIA_BUS_FMT_RGB121212_1X36:
+ case MEDIA_BUS_FMT_RGB161616_1X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ case MEDIA_BUS_FMT_YUV8_1X24:
+ case MEDIA_BUS_FMT_YUV10_1X30:
+ case MEDIA_BUS_FMT_YUV12_1X36:
+ case MEDIA_BUS_FMT_YUV16_1X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ case MEDIA_BUS_FMT_UYVY8_1X16:
+ case MEDIA_BUS_FMT_VYUY8_1X16:
+ case MEDIA_BUS_FMT_YUYV8_1X16:
+ case MEDIA_BUS_FMT_YVYU8_1X16:
+ case MEDIA_BUS_FMT_UYVY10_1X20:
+ case MEDIA_BUS_FMT_YUYV10_1X20:
+ case MEDIA_BUS_FMT_VYUY10_1X20:
+ case MEDIA_BUS_FMT_YVYU10_1X20:
+ case MEDIA_BUS_FMT_UYVY12_1X24:
+ case MEDIA_BUS_FMT_VYUY12_1X24:
+ case MEDIA_BUS_FMT_YUYV12_1X24:
+ case MEDIA_BUS_FMT_YVYU12_1X24:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
+ case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
+ case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
+ case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
+ return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ default:
+ return false;
+ }
+}
+
/*
* This function is called by &drm_atomic_bridge_chain_check() just before
* calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
@@ -1193,6 +1234,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
struct drm_encoder *encoder = bridge->encoder;
struct drm_bridge_state *last_bridge_state;
unsigned int i, num_out_bus_fmts = 0;
+ enum drm_connector_color_format fmt;
u32 *out_bus_fmts;
int ret = 0;
@@ -1234,11 +1276,31 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
}
+ /*
+ * Instead of directly accessing conn_state.color_format, call into a
+ * connector function that allows connector implementations (e.g. for
+ * bridge connectors including HDMI bridges, where the HDMI helpers will
+ * have already chosen an appropriate output format) to override the
+ * selected format.
+ */
+ fmt = drm_connector_get_color_format(conn_state);
+
for (i = 0; i < num_out_bus_fmts; i++) {
+ if (!bus_format_is_color_fmt(out_bus_fmts[i], fmt)) {
+ drm_dbg_kms(last_bridge->dev,
+ "Skipping bus format 0x%04x as it doesn't match format %d\n",
+ out_bus_fmts[i], fmt);
+ ret = -ENOTSUPP;
+ continue;
+ }
ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
conn_state, out_bus_fmts[i]);
- if (ret != -ENOTSUPP)
+ if (ret != -ENOTSUPP) {
+ drm_dbg_kms(last_bridge->dev,
+ "Found bridge chain ending with bus format 0x%04x\n",
+ out_bus_fmts[i]);
break;
+ }
}
kfree(out_bus_fmts);
--
2.53.0
^ permalink raw reply related
* [PATCH v13 05/27] drm/display: bridge_connector: Use HDMI color format for HDMI conns
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
For bridge connectors which contain an HDMI bridge at some stage, the
HDMI state helpers' format selection logic should be involved.
Add an implementation for the drm_bridge_funcs color_format function,
which translates from the HDMI state's output format to a connector
format for bridge connectors involving an HDMI bridge, but return the
connector state's color_format member unchanged otherwise.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 39cc18f78eda..bcfa4f2ca3e4 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -276,6 +276,29 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
connector->state);
}
+static enum drm_connector_color_format
+drm_bridge_connector_color_format(const struct drm_connector_state *conn_state)
+{
+ struct drm_bridge_connector *bridge_connector =
+ to_drm_bridge_connector(conn_state->connector);
+
+ if (bridge_connector->bridge_hdmi) {
+ switch (conn_state->hdmi.output_format) {
+ default:
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ return DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ return DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ }
+ }
+
+ return conn_state->color_format;
+}
+
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
@@ -285,6 +308,7 @@ static const struct drm_connector_funcs drm_bridge_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
.oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
+ .color_format = drm_bridge_connector_color_format,
};
/* -----------------------------------------------------------------------------
--
2.53.0
^ permalink raw reply related
* [PATCH v13 04/27] drm/connector: Let connectors have a say in their color format
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
Add a function to get the connector color format from a connector state,
and a new function pointer in drm_connector_funcs to allow connectors to
override what connector color format it returns.
This is useful for the bridge chain recursive bus format selection code,
which does not wish to implement connector implementation specific
checks like whether it involves HDMI.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/drm_connector.c | 16 ++++++++++++++++
include/drm/drm_connector.h | 12 ++++++++++++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1c4f3ff7d84f..d354ab77d3b8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3690,6 +3690,22 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
}
EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+/**
+ * drm_connector_get_color_format - Return connector color format of @conn_state
+ * @conn_state: pointer to the &struct drm_connector_state to go check
+ *
+ */
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state)
+{
+ struct drm_connector *connector = conn_state->connector;
+
+ if (connector->funcs->color_format)
+ return connector->funcs->color_format(conn_state);
+
+ return conn_state->color_format;
+}
+EXPORT_SYMBOL(drm_connector_get_color_format);
/**
* DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 620f700fbe76..21767fffcba4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1811,6 +1811,16 @@ struct drm_connector_funcs {
* Allows connectors to create connector-specific debugfs files.
*/
void (*debugfs_init)(struct drm_connector *connector, struct dentry *root);
+
+ /**
+ * @color_format:
+ *
+ * Allows connectors to return a connector color format other than
+ * @conn_state.color_format for purposes of e.g. display protocol
+ * specific helper logic having already mapped it to an output format.
+ */
+ enum drm_connector_color_format (*color_format)(
+ const struct drm_connector_state *conn_state);
};
/**
@@ -2627,6 +2637,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
enum drm_connector_status status);
+enum drm_connector_color_format
+drm_connector_get_color_format(const struct drm_connector_state *conn_state);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.53.0
^ permalink raw reply related
* [PATCH v13 03/27] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
Add a new general DRM property named "color format" which can be used by
userspace to request the display driver to output a particular color
format.
Possible string values for the new enum property are:
- "AUTO" (setup by default, driver internally picks the color format)
- "RGB"
- "YUV 4:4:4"
- "YUV 4:2:2"
- "YUV 4:2:0"
Drivers should advertise from this list the formats they support in an
optimistic best-case scenario. EDID data from the sink can then be used
in the kernel's atomic check phase to restrict this set of formats, as
well as by userspace to make a correct choice in the first place.
Co-developed-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Co-developed-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic_helper.c | 5 ++
drivers/gpu/drm/drm_atomic_uapi.c | 11 +++
drivers/gpu/drm/drm_connector.c | 155 ++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 108 +++++++++++++++++++++++++
5 files changed, 285 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2292e65f044c..da5133b672d3 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -599,6 +599,12 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:doc: overview
+Color Format Property
+---------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :doc: Color format
+
Tile Group Property
-------------------
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 2e7e8ed8ad7f..0de9748a82c6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -737,6 +737,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->color_format !=
+ new_connector_state->color_format)
+ new_crtc_state->connectors_changed = true;
+
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 5bd5bf6661df..dee510c85e59 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -935,6 +935,15 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
state->privacy_screen_sw_state = val;
} else if (property == connector->broadcast_rgb_property) {
state->hdmi.broadcast_rgb = val;
+ } else if (property == connector->color_format_property) {
+ if (val > INT_MAX || !drm_connector_color_format_valid(val)) {
+ drm_dbg_atomic(connector->dev,
+ "[CONNECTOR:%d:%s] unknown color format %llu\n",
+ connector->base.id, connector->name, val);
+ return -EINVAL;
+ }
+
+ state->color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1020,6 +1029,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
*val = state->privacy_screen_sw_state;
} else if (property == connector->broadcast_rgb_property) {
*val = state->hdmi.broadcast_rgb;
+ } else if (property == connector->color_format_property) {
+ *val = state->color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 47dc53c4a738..1c4f3ff7d84f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1388,6 +1388,18 @@ static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+static const u32 hdmi_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
+static const u32 dp_colorformats =
+ BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422) |
+ BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
+
/*
* As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel Encoding/Colorimetry
* Format Table 2-120
@@ -2940,6 +2952,149 @@ int drm_connector_attach_colorspace_property(struct drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_colorspace_property);
+/**
+ * DOC: Color format
+ *
+ * The connector "color format" property allows userspace to request a specific
+ * color model on the output of the connector. Not all values listed by the
+ * property are guaranteed to work for every sink; rather, it is an optimistic
+ * listing of color formats that the source could output depending on
+ * circumstances.
+ *
+ * Whether it actually can output a certain color format is determined during
+ * the atomic check phase. Consequently, a userspace application that sets the
+ * color format to a value other than "AUTO" should check whether its atomic
+ * commit succeeded.
+ *
+ * Possible values for "color format":
+ *
+ * "AUTO":
+ * The driver or display protocol helpers should pick a suitable color
+ * format. All implementations of a specific display protocol will behave
+ * the same way with "AUTO", but different display protocols do not
+ * necessarily have the same "AUTO" semantics.
+ *
+ * For HDMI connectors, "AUTO" picks RGB, but falls back to YUV 4:2:0 if
+ * the bandwidth required for full-scale RGB is not available, or the mode
+ * is YUV 4:2:0-only, as long as the mode, source, and sink all support
+ * YUV 4:2:0.
+ * "RGB":
+ * RGB output format. The quantization range (limited/full) depends on the
+ * value of the "Broadcast RGB" property if it is present on the connector.
+ * "YUV 4:4:4":
+ * YUV 4:4:4 (a.k.a. YCbCr 4:4:4) output format. Chroma is not subsampled.
+ * The quantization range defaults to limited.
+ * "YUV 4:2:2":
+ * YUV 4:2:2 (a.k.a. YCbCr 4:2:2) output format. Chroma has half the
+ * horizontal resolution of Luma. The quantization range defaults to
+ * limited.
+ * "YUV 4:2:0":
+ * YUV 4:2:0 (a.k.a. YCbCr 4:2:0) output format. Chroma has half the
+ * horizontal and vertical resolution of Luma. The quantization range
+ * defaults to limited.
+ *
+ * A sink may only support some color formats in specific modes and at specific
+ * bit depths. The atomic modesetting API should be used to set a working
+ * configuration in one go, as an unsupported combination of parameters is
+ * rejected.
+ */
+
+/**
+ * drm_connector_attach_color_format_property - create and attach color format property
+ * @connector: connector to create the color format property on
+ * @supported_color_formats: bitmask of bit-shifted &enum drm_output_color_format
+ * values the connector supports
+ *
+ * Called by a driver to create a color format property. The property is
+ * attached to the connector automatically on success.
+ *
+ * @supported_color_formats should only include color formats the connector
+ * type can actually support.
+ *
+ * Returns:
+ * 0 on success, negative errno on error
+ */
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_prop_enum_list enum_list[DRM_CONNECTOR_COLOR_FORMAT_COUNT];
+ unsigned int i = 0;
+ unsigned long fmt;
+
+ if (connector->color_format_property)
+ return 0;
+
+ if (!supported_color_formats) {
+ drm_err(dev, "No supported color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ if (supported_color_formats & ~GENMASK(DRM_OUTPUT_COLOR_FORMAT_COUNT - 1, 0)) {
+ drm_err(dev, "Unknown color formats provided on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ if (supported_color_formats & ~hdmi_colorformats) {
+ drm_err(dev, "Color formats not allowed for HDMI on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ case DRM_MODE_CONNECTOR_eDP:
+ if (supported_color_formats & ~dp_colorformats) {
+ drm_err(dev, "Color formats not allowed for DP on [CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+ break;
+ }
+
+ enum_list[0].name = "AUTO";
+ enum_list[0].type = DRM_CONNECTOR_COLOR_FORMAT_AUTO;
+
+ for_each_set_bit(fmt, &supported_color_formats, DRM_OUTPUT_COLOR_FORMAT_COUNT) {
+ switch (fmt) {
+ case DRM_OUTPUT_COLOR_FORMAT_RGB444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
+ break;
+ case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
+ enum_list[++i].type = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
+ break;
+ default:
+ drm_warn(dev, "Unknown supported format %ld on [CONNECTOR:%d:%s]\n",
+ fmt, connector->base.id, connector->name);
+ continue;
+ }
+ enum_list[i].name = drm_hdmi_connector_get_output_format_name(fmt);
+ }
+
+ connector->color_format_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "color format",
+ enum_list, i + 1);
+
+ if (!connector->color_format_property)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, connector->color_format_property,
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_color_format_property);
+
/**
* drm_connector_atomic_hdr_metadata_equal - checks if the hdr metadata changed
* @old_state: old connector state to compare
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f83f28cae207..620f700fbe76 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,14 +571,106 @@ enum drm_colorspace {
* YCbCr 4:2:2 output format (ie. with horizontal subsampling)
* @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
* YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
+ * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
+ * Number of valid output color format values in this enum
*/
enum drm_output_color_format {
DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
+ DRM_OUTPUT_COLOR_FORMAT_COUNT,
};
+/**
+ * enum drm_connector_color_format - Connector Color Format Request
+ *
+ * This enum, unlike &enum drm_output_color_format, is used to specify requests
+ * for a specific color format on a connector through the DRM "color format"
+ * property. The difference is that it has an "AUTO" value to specify that
+ * no specific choice has been made.
+ */
+enum drm_connector_color_format {
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
+ * helpers should pick a suitable color format. All implementations of a
+ * specific display protocol must behave the same way with "AUTO", but
+ * different display protocols do not necessarily have the same "AUTO"
+ * semantics.
+ *
+ * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
+ * bandwidth required for full-scale RGB is not available, or the mode
+ * is YCbCr 4:2:0-only, as long as the mode and output both support
+ * YCbCr 4:2:0.
+ *
+ * For display protocols other than HDMI, the recursive bridge chain
+ * format selection picks the first chain of bridge formats that works,
+ * as has already been the case before the introduction of the "color
+ * format" property. Non-HDMI bridges should therefore either sort their
+ * bus output formats by preference, or agree on a unified auto format
+ * selection logic that's implemented in a common state helper (like
+ * how HDMI does it).
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format. The
+ * quantization range depends on the value of the "Broadcast RGB"
+ * property if it is present on the connector.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_RGB444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
+ * not subsampled). Quantization range is "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
+ * with horizontal subsampling). Quantization range is "Limited" by
+ * default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
+ * with horizontal and vertical subsampling). Quantization range is
+ * "Limited" by default.
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
+
+ /**
+ * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
+ * format values in this enum
+ */
+ DRM_CONNECTOR_COLOR_FORMAT_COUNT,
+};
+
+/**
+ * drm_connector_color_format_valid - Validate drm_connector_color_format value
+ * @fmt: value to check against all values of &enum drm_connector_color_format
+ *
+ * Checks whether the passed in value of @fmt is one of the allowable values in
+ * &enum drm_connector_color_format.
+ *
+ * Returns: %true if it's a valid value for the enum, %false otherwise.
+ */
+static inline bool __pure
+drm_connector_color_format_valid(enum drm_connector_color_format fmt)
+{
+ switch (fmt) {
+ case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
+ case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
+ case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
+ return true;
+ default:
+ return false;
+ }
+}
+
const char *
drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
@@ -1167,6 +1259,13 @@ struct drm_connector_state {
*/
enum drm_colorspace colorspace;
+ /**
+ * @color_format: State variable for Connector property to request
+ * color format change on Sink. This is most commonly used to switch
+ * between RGB to YUV and vice-versa.
+ */
+ enum drm_connector_color_format color_format;
+
/**
* @writeback_job: Writeback job for writeback connectors
*
@@ -2165,6 +2264,12 @@ struct drm_connector {
*/
struct drm_property *colorspace_property;
+ /**
+ * @color_format_property: Connector property to set the suitable
+ * color format supported by the sink.
+ */
+ struct drm_property *color_format_property;
+
/**
* @path_blob_ptr:
*
@@ -2648,6 +2753,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
+int drm_connector_attach_color_format_property(struct drm_connector *connector,
+ unsigned long supported_color_formats);
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: &struct drm_connector pointer used as cursor
--
2.53.0
^ permalink raw reply related
* [PATCH v13 00/27] Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason,
Cristian Ciocaltea, Marius Vlad, Dmitry Baryshkov, Andy Yan
Hello,
this is a follow-up to
https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
which in of itself is a follow-up to
https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
a new DRM connector property has been added allowing users to
force a particular color format.
That in turn was actually also a follow-up from Werner Sembach's posted at
https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
As the number of cooks have reached critical mass, I'm hoping I'll be
the last person to touch this particular series.
We have an implementation in Weston at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1825 that
adds support for this property. This patch series has been tested
against that MR on i915 (HDMI, DP), amdgpu (HDMI, DP) and on rockchip
(HDMI).
You can also manually test this with modetest like so, but beware that
this is a non-atomic invocation, so testing YUV420 like this will result
in weird outcomes if only some of the modes support YUV420:
$ modetest -s 115:1920x1080-60@NV12 -w 115:'color format':4
where 115 is the connector ID and '4' is the enum value for a particular
color format.
General notes on the approach taken by me: instead of silently switching
to a different format than was explicitly requested, or even worse,
outputting something to the sink the sink doesn't support, bubble up an
error to userspace instead. "color format" is a "I want this" type
property, not a "force this" type property, i.e. the kernel will respect
the limits imposed by the hardware.
Things I've tested:
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3588
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3576
- HDMI + DP (YCbCr 4:4:4, YCbCr 4:2:0, RGB, Auto) on Intel N97 (i915).
- HDMI (YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0, RGB, Auto) + DP (YCbCr
4:4:4, RGB, Auto) on an AMD Radeon RX 550 (amdgpu).
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v13:
- Introduce a new drm_connector_funcs member that returns the
connector state's color format with additional bells and whistles.
- Implement this new func in drm_bridge_connector to return whatever the
HDMI implementation did if an HDMI bridge is present.
- Call into the drm_connector.h function wrapping this new func in the
recursive bridge chain bus format selection code.
- Link to v12: https://patch.msgid.link/20260409-color-format-v12-0-ce84e1817a27@collabora.com
Changes in v12:
- Rebase on top of Ville's i915 format selection cleanup series
- i915: Reimplement based on new format selection code. Drop the DP-MST
implementation, as sinks with different sets of supported formats
complicate the matter.
- Adjust documentation on drm_connector_color_format enum values to
mention quantization ranges.
- Add documentation to drm-kms page to document the string values for
the property. Mostly the same documentation as the enum values, but
from a more userspace-centric perspective. This is done in the patch
that introduces the property, but I didn't drop the existing R-b as
it isn't a functional change.
- Update documentation of "colorspace" property to mention that "color
format" property controls the output format.
- amdgpu: Remove property from DP-MST, as it's unclear whether it'd work
properly with sinks that have different sets of supported formats
- Link to v11: https://patch.msgid.link/20260324-color-format-v11-0-605559af4fb4@collabora.com
Changes in v11:
- amdgpu: fix property registration on DP-MST
- i915: fix property registration on DP-MST
- rebase on drm-tip, which includes Maxime's refactor series that was
previously declared a dependency of this series
- Link to v10: https://lore.kernel.org/r/20260305-color-format-v10-0-a58c68a11868@collabora.com
Changes in v10:
- Make DRM_OUTPUT_COLOR_FORMAT_COUNT and
DRM_CONNECTOR_COLOR_FORMAT_COUNT part of the enum definition (thanks
to Maxime)
- Preemptively avoid the warning that would be generated by the
enumification of DRM_OUTPUT_COLOR_FORMAT_COUNT by modifying the
problematic switch statement in drm_hdmi_state_helper's
sink_supports_format_bpc.
- drm/bridge: Change HDMI check from checking for the last bridge having
a DRM_BRIDGE_OP_HDMI in ops to checking if last_bridge->type is HDMIA.
This is not quite the suggestion Dmitry had, but according to the
documentation of the drm_bridge.type member, and the
display-connector.c code, it should be correct.
- Combine drm_mode_create_color_format_property and
drm_connector_attach_color_format_property into one function named the
latter. (thanks to Dmitry Baryshkov)
- Change author of 'drm: Add new general DRM property "color format"'
to myself as it has by now changed quite a bit, and add Andri and
Werner as Co-developed-by, as per Andri's suggestion.
- hdmi-state-helper: Rework hdmi_compute_config to make code flow more
obvious, and drop Dmitry's R-b as a consequence (thanks to Maxime)
- Move dw-hdmi-qp's atomic_get_output_bus_fmts into
drm_bridge_helper.c, along with kernel doc string (thanks to Dmitry)
- Future-proof the aforementioned get_output_bus_fmts use of hweight8 on
the supported_formats bitmask with a BUILD_BUG_ON.
- Add a KUnit test for the HDMI output bus formats helper
- Link to v9: https://lore.kernel.org/r/20260227-color-format-v9-0-658c3b9db7ef@collabora.com
Changes in v9:
- Document what the "AUTO" behaviour is in the color format enum (thanks
to Maxime)
- drm/bridge: dw-hdmi-qp: Fix a rebase oopsie that reintroduced some
functions that were dropped. (thanks to Cristian)
- drm/bridge: Shuffle "1:1" in the bridge fmt selection docs to earlier
in the sentence. (thanks to Randy Dunlap)
- i915: Check chosen output format against requested format for dp-mst
- All color format driver implementations: rebase and rework on top of
Maxime's series
- As part of this rework, rename drm_color_format_enum to
drm_connector_color_format
- drm kunit tests: rework for the new enums. Changes were trivial, so
trailers were kept
- Link to v8: https://lore.kernel.org/r/20260216-color-format-v8-0-5722ce175dd5@collabora.com
Changes in v8:
- Drop "drm/rockchip: vop2: Fix YUV444 output", as the original problem
could not be reproduced anymore, and the justification did not make
sense.
- Remove the 12-bit format from "drm/rockchip: vop2: Recognise 10/12-bit
YUV422 as YUV formats".
- Refactor to keep the original DRM_COLOR_FORMAT bitshifted defines
as-is, but introduce a new drm_color_format_enum enum.
- Adjust conversion functions for the newly refactored enum, ensuring
they only return valid enum values, and only convert in directions
that open up no error value cans of worms.
- Rework the property uapi code for the newly refactored enum, since
it no longer needs to do any bitshifting or ffs().
- Rework all the device drivers for the new enum.
- Rework all the tests for the refactored enum.
- Rework the hdmi state helper for the new enum, and also make it more
explicit about the auto behaviour by not relying on a conversion
function to map AUTO to RGB, but do this in the framework itself.
- rockchip dw_hdmi_qp: Fix the GRF value to check for color >= 0 instead
of color > 0, as the latter broke switching back to RGB.
- Rebase onto a recent drm-tip. This necessitated blindly reworking some
of the i915 dp-mst code.
- Drop the __maybe_unused edid test patch, as I could no longer
reproduce the build warnings I added it for. I blame ghosts.
- drm_bridge tests: remove "destroyed" member from struct
drm_bridge_chain_priv and all associated code, as it was not used in
any test.
- Link to v7: https://lore.kernel.org/r/20260121-color-format-v7-0-ef790dae780c@collabora.com
Changes in v7:
- Fix drm_bridge kunit test build failure caused by rebasing across an
API change.
- Make compilers shut up about unused EDID definitions in the test
suites.
- Empty line checkpatch fixes that b4 prep --check didn't catch.
- Link to v6: https://lore.kernel.org/r/20260121-color-format-v6-0-7b81a771cd0b@collabora.com
Changes in v6:
- Checkpatch fixes
- Add drm_bridge.c kerneldoc fix patch to b4 deps so the kernel docs
required for every contribution to the subsystem can be built
- dw-hdmi-qp core has gained the atomic_get_output_bus_fmts bridge func,
which allows it to participate in the drm_bridge chain recursive format
selection code properly.
- The Rockchip dw-hdmi-qp integration now no longer reimplements the
color format logic (improperly), but reads the bus format of the first
bridge as set by the recursive bridge format selection. If the input
format is FIXED, it'll use the output format. Otherwise, the input
format is used.
- In the synopsys drivers, YUV422 uses the same bus format as the non-qp
hdmi encoder driver. Probably correcter this way. The Rockchip vop2
is_yuv function has been extended to recognise this format as well.
- KUnit tests for drm_bridge chains are now included, which exercise the
chain's recursive bus format selection.
- On HDMI connectors, the drm_bridge bus format selection will try to target
the color format that the HDMI layer came up with. This means the AUTO
logic is not duplicated for HDMI connectors.
- The enum conversion function commit gained a function for converting
from hdmi_colorspace to drm_color_format, and its author changed as no
original code remains anyway. Marius is still included as a
Co-developer.
- Some tests for the HDMI state helper's mode_valid have been written.
They are incomplete as we lack a test EDID for a 420-also mode that
would violate the clock constraints on RGB. I hacked one together with
a hex editor, but it reports a too high of a clock rate, and there's
no EDID editor I could find which supports these extension blocks.
- The color_format KUnit tests have been more heavily parameterised, the
auto case absorbed into other tests, and the comments around them
rewritten.
- Add a few paragraphs of documentation that explain the bridge format
selection, and how to make use of it in a display driver.
- Link to v5: https://lore.kernel.org/r/20251128-color-format-v5-0-63e82f1db1e1@collabora.com
Changes in v5:
- Rebase onto drm-tip
- Drop DRM_MODE_COLOR_FORMAT_* as an enum
- Unify DRM_COLOR_FORMAT_NONE and DRM_COLOR_FORMAT_AUTO, with AUTO being
0. This makes conversion and general logic much easier.
- Adjust the drm_color_format enum to not needlessly renumber the
existing defines, as it doesn't need to correspond to how HDMI numbers
them.
- Make the DRM-to-HDMI conversion function static inline __pure, because
the assembly it generates is tiny, and the function is pure.
- Don't accept nothing as the list of supported color formats for
registration of the property.
- Drop the per-connector variants of the color format registration
function, as it's not needed.
- drm_hdmi_state_helper: Fix mode_valid rejecting 420-only modes.
- drm_hdmi_state_helper: Only fall back to YUV420 with
DRM_COLOR_FORMAT_AUTO.
- drm_hdmi_state_helper: Remove redundant AUTO->RGB condition, as the
conversion already does this.
- Add KUnit tests for hdmi_compute_config.
- drm/bridge: Refactor bus_format_is_color_fmt and add a few more YUV422
formats.
- Register the color format property in drmm_connector_hdmi_init based
on the supported HDMI formats passed to it. This means rockchip
dw_hdmi_qp no longer needs to register it.
- amdgpu: Simplify YUV420 logic
- amdgpu: Don't try to pick YUV444 on YUV420-only modes
- i915: Try to make behaviour more or less the same as that of the drm
hdmi state helper.
- rockchip dw_hdmi_qp: Set supported HDMI formats
- rockchip dw_hdmi_qp: Set the right VO GRF values depending on color
format.
- rockchip dw_hdmi_qp: Act on the color format property in this driver,
rather than in VOP2, by setting the bus_format appropriately.
- rockchip VOP2: Can the BCSH-based implementation. BCSH isn't available
on all video ports of the hardware, and the code was extremely
suspect. Instead, plug into the existing YUV-to-RGB/RGB-to-YUV code,
which can be done now that the HDMI driver sets the bus format.
- A whole bunch of Rockchip VOP2 fixes.
- Link to v4: https://lore.kernel.org/r/20251117-color-format-v4-0-0ded72bd1b00@collabora.com
Changes in v4:
- Rebase onto next-20251117
- Get rid of HDMI_COLORSPACE_AUTO
- Split hdmi_compute_config change into separate patch
- Add missing symbol export for color_format_to_hdmi_colorspace to fix
builds in certain configurations
- Drop "drm: Pass supported color formats straight onto drm_bridge"
- Make dw-hdmi-qp set the platform data's supported color formats as
the bridge's supported HDMI color formats
- drm_hdmi_state_helper: pass requested color format to
hdmi_compute_format_bpc if set.
- drm_bridge: limit the bus formats to those explicitly requested with
the color format property during the atomic bridge check call,
specifically in drm_atomic_bridge_chain_select_bus_fmts.
- i915: Remove INTEL_OUTPUT_FORMAT_AUTO, as automatic format selection
does not need to involve the hardware state
- i915: Deduplicate ntel_output_format_to_drm_color_format code by
moving it as a static inline __pure function into a shared header
- i915: rework logic in HDMI, DP and DP-MST output config functions to
remove redundant locals, simplify execution flow, and return an error
to userspace if an explicit color_format request can't be satisfied.
- i915: assign myself as the author and make the others Co-developers,
so that they don't get the blame for any of my bugs.
- amdgpu: refactor fill_stream_properties_from_drm_display_mode to
improve readability and ensure that impossible color format requests
get bubbled up to userspace as errors
- amdgpu: don't pick YUV444 over RGB.
- amdgpu: assign authorship to myself, with others as Co-developers, as
logic was modified and the blame should fall on me
- dw_hdmi_qp-rockchip: set the supported color formats platform data
member
- rockchip: remove drm property registration for rk3066_hdmi and
inno_hdmi. None of the platforms that use these use vop2 as the
video output processor.
- Link to v3: https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
Changes in v3 by mvlad compared to Andri's v2 series:
- renamed the property to just 'color format'
- the property is added dynamically similar to the Colorspace property
- a key point from previous comments was that drivers should advertise
the color formats they support and userspace would query EDID and
perform an intersection from those color formats which users can
further use. With this patch set each driver that adds this property
has such list of hard-coded color formats, but fundamentally the idea
is that driver can query the HW and do that on its own. The
infrastructure is now in place to allow to do that
- by default the 'AUTO' color format is set. With this patch series that
has been introduced as a fallback to RGB. Drivers could further
customize this behavour and could perform additional checks on the sink
to pick another suitable color format they'd like for AUTO
- drm_bridge bridge code has been improved to allow initialization with
the same color formats list as the DRM connector property. Similarly, bpc
pick-up now takes the color format into consideration when deciding
which bpc to choose from
- The new DRM color format re-uses HDMI_COLORPSACE enum and provides an
enum translations between the two to avoid touching all other drivers that
use HDMI_COLORPSACE enum. I believe at this point that this allows the
least amount of disruption and avoids a massive bike shedding around
that part
- a rockchip implementation has been by my colleague Derek Foreman
- YUV444 color format has been added in i915
- address comment about "Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A
check" where aconnector might be invalid
- Link to v2: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/
---
Nicolas Frattaroli (26):
drm/display: hdmi-state-helper: Use default case for unsupported formats
drm: Add new general DRM property "color format"
drm/connector: Let connectors have a say in their color format
drm/display: bridge_connector: Use HDMI color format for HDMI conns
drm/bridge: Act on the DRM color format property
drm/atomic-helper: Add HDMI bridge output bus formats helper
drm/display: hdmi-state-helper: Act on color format DRM property
drm/display: hdmi-state-helper: Try subsampling in mode_valid
drm/amdgpu: Implement "color format" DRM property
drm/i915/hdmi: Add YCBCR444 handling for sink formats
drm/i915/dp: Add YCBCR444 handling for sink formats
drm/i915: Implement the "color format" DRM property
drm/rockchip: Add YUV422 output mode constants for VOP2
drm/rockchip: vop2: Add RK3576 to the RG swap special case
drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format
drm/rockchip: vop2: Set correct output format for RK3576 YUV422
drm/bridge: dw-hdmi-qp: Use common HDMI output bus fmts helper
drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property
drm/rockchip: dw_hdmi_qp: Set supported_formats platdata
drm/connector: Register color format property on HDMI connectors
drm/tests: hdmi: Add tests for the color_format property
drm/tests: hdmi: Add tests for HDMI helper's mode_valid
drm/tests: bridge: Add KUnit tests for bridge chain format selection
drm/tests: bridge: Add test for HDMI output bus formats helper
drm/bridge: Document bridge chain format selection
drm/connector: Update docs of "colorspace" for color format prop
Werner Sembach (1):
drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
Documentation/gpu/drm-kms-helpers.rst | 6 +
Documentation/gpu/drm-kms.rst | 6 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 91 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
drivers/gpu/drm/display/drm_bridge_connector.c | 24 +
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 53 +-
drivers/gpu/drm/drm_atomic_helper.c | 86 ++
drivers/gpu/drm/drm_atomic_uapi.c | 11 +
drivers/gpu/drm/drm_bridge.c | 104 ++-
drivers/gpu/drm/drm_connector.c | 178 +++-
drivers/gpu/drm/i915/display/intel_connector.c | 10 +
drivers/gpu/drm/i915/display/intel_connector.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 43 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 47 +-
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 111 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 4 +
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 21 +-
drivers/gpu/drm/tests/drm_bridge_test.c | 971 +++++++++++++++++++++
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 345 ++++++++
include/drm/drm_atomic_helper.h | 7 +
include/drm/drm_connector.h | 120 +++
21 files changed, 2203 insertions(+), 37 deletions(-)
---
base-commit: e3dc6072028a594d5e9bfc6476165842602d5307
change-id: 20251028-color-format-49fd202b7183
prerequisite-message-id: <20260409101539.22032-1-ville.syrjala@linux.intel.com>
prerequisite-patch-id: f382aeb5da5f2b8f6e2cb22b88eb47f490f2c724
prerequisite-patch-id: 20570aeb28e3c31353e6f697b193b23d8b47c47c
prerequisite-patch-id: 1b7e24034883b22cd82be025a1cf82ae77170fd0
prerequisite-patch-id: 6ec2dc2c05a75391b67cb12d93168f5e8da8ec55
prerequisite-patch-id: 32e84581998ef4eef05e1681c7ec36b90f2a6bb7
prerequisite-patch-id: 99c2187a846b0c9ac2ea1a892c17483120cb7da1
prerequisite-patch-id: fb41b4668a3b7c8c375c67ffd6b178fa3273e86a
prerequisite-patch-id: 4c115a36eea0d5f80643dc34310690894ac80e0e
prerequisite-patch-id: 6fdec0832cd6062de3cc5c2f363c5d624d8a00f9
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* [PATCH v13 02/27] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
Switch statements that do not handle all possible values of an
enumeration will generate a warning during compilation. In preparation
for adding a COUNT value to the end of the enum, this needs to be dealt
with.
Add a default case to sink_supports_format_bpc's DRM_OUTPUT_COLOR_FORMAT
switch statement, and move the log-and-return unknown pixel format
handling into it.
No functional change.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 9f3b696aceeb..a0d88701d236 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -541,10 +541,11 @@ sink_supports_format_bpc(const struct drm_connector *connector,
drm_dbg_kms(dev, "YUV444 format supported in that configuration.\n");
return true;
- }
- drm_dbg_kms(dev, "Unsupported pixel format.\n");
- return false;
+ default:
+ drm_dbg_kms(dev, "Unsupported pixel format.\n");
+ return false;
+ }
}
static enum drm_mode_status
--
2.53.0
^ permalink raw reply related
* [PATCH v13 01/27] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
From: Werner Sembach <wse@tuxedocomputers.com>
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.
This patch also moves both checks in the same if-case. This eliminates an
extra else-if-case.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Tested-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c2066319772b..ad9714382d5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6780,12 +6780,9 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
- timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if (drm_mode_is_420_also(info, mode_in)
- && aconnector
- && aconnector->force_yuv420_output)
+ if (drm_mode_is_420_only(info, mode_in) ||
+ (aconnector && aconnector->force_yuv420_output &&
+ drm_mode_is_420_also(info, mode_in)))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
&& aconnector
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 2/5] coresight: etm4x: exclude ss_status from drvdata->config
From: Yeoreum Yun @ 2026-04-13 10:04 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, leo.yan
In-Reply-To: <f426ea8a-58ac-4d0f-b56c-c21f88eb863d@oss.qualcomm.com>
Hi Jie,
>
>
> On 4/13/2026 1:55 AM, Yeoreum Yun wrote:
> > The purpose of TRCSSCSRn register is to show status of
> > the corresponding Single-shot Comparator Control and input supports.
> > That means writable field's purpose for reset or restore from idle status
> > not for configuration.
> >
> > Therefore, exclude ss_status from drvdata->config, move it to etm4x_caps.
> > This includes remove TRCSSCRn from configurable item and
> > remove saving in etm4_disable_hw().
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > .../hwtracing/coresight/coresight-etm4x-cfg.c | 1 -
> > .../hwtracing/coresight/coresight-etm4x-core.c | 18 +++++-------------
> > .../coresight/coresight-etm4x-sysfs.c | 7 ++-----
> > drivers/hwtracing/coresight/coresight-etm4x.h | 3 ++-
> > 4 files changed, 9 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > index c302072b293a..d14d7c8a23e5 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > @@ -86,7 +86,6 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> > off_mask = (offset & GENMASK(11, 5));
> > do {
> > CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> > - CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> > CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> > } while (0);
> > } else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > index 6443f3717b37..8ebfd3924143 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > @@ -91,7 +91,7 @@ static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
> > const struct etmv4_caps *caps = &drvdata->caps;
> > return (n < caps->nr_ss_cmp) && caps->nr_pe &&
> > - (drvdata->config.ss_status[n] & TRCSSCSRn_PC);
> > + (caps->ss_status[n] & TRCSSCSRn_PC);
> > }
> > u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
> > @@ -571,11 +571,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> > etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i));
> > for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - /* always clear status bit on restart if using single-shot */
> > - if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> > - config->ss_status[i] &= ~TRCSSCSRn_STATUS;
> > etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i));
> > - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i));
> > + /* always clear status and pending bits on restart if using single-shot */
> > + etm4x_relaxed_write32(csa, caps->ss_status[i], TRCSSCSRn(i));
> > if (etm4x_sspcicrn_present(drvdata, i))
> > etm4x_relaxed_write32(csa, config->ss_pe_cmp[i], TRCSSPCICRn(i));
> > }
> > @@ -1053,12 +1051,6 @@ static void etm4_disable_hw(struct etmv4_drvdata *drvdata)
> > etm4_disable_trace_unit(drvdata);
> > - /* read the status of the single shot comparators */
> > - for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - config->ss_status[i] =
> > - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > - }
> > -
> > /* read back the current counter values */
> > for (i = 0; i < caps->nr_cntr; i++) {
> > config->cntr_val[i] =
> > @@ -1501,8 +1493,8 @@ static void etm4_init_arch_data(void *info)
> > */
> > caps->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4);
> > for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - drvdata->config.ss_status[i] =
> > - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > + caps->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > + caps->ss_status[i] &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING);
> > }
> > /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> > caps->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4);
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index 50408215d1ac..dd62f01674cf 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1827,8 +1827,6 @@ static ssize_t sshot_ctrl_store(struct device *dev,
> > raw_spin_lock(&drvdata->spinlock);
> > idx = config->ss_idx;
> > config->ss_ctrl[idx] = FIELD_PREP(TRCSSCCRn_SAC_ARC_RST_MASK, val);
> > - /* must clear bit 31 in related status register on programming */
> > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS;
> > raw_spin_unlock(&drvdata->spinlock);
> > return size;
> > }
> > @@ -1839,10 +1837,11 @@ static ssize_t sshot_status_show(struct device *dev,
> > {
> > unsigned long val;
> > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + const struct etmv4_caps *caps = &drvdata->caps;
> > struct etmv4_config *config = &drvdata->config;
> > raw_spin_lock(&drvdata->spinlock);
> > - val = config->ss_status[config->ss_idx];
> > + val = caps->ss_status[config->ss_idx];
> > raw_spin_unlock(&drvdata->spinlock);
> > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > }
> > @@ -1877,8 +1876,6 @@ static ssize_t sshot_pe_ctrl_store(struct device *dev,
> > raw_spin_lock(&drvdata->spinlock);
> > idx = config->ss_idx;
> > config->ss_pe_cmp[idx] = FIELD_PREP(TRCSSPCICRn_PC_MASK, val);
> > - /* must clear bit 31 in related status register on programming */
> > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS;
> > raw_spin_unlock(&drvdata->spinlock);
> > return size;
> > }
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 8eebb83fcaeb..3cc1ca76c933 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -213,6 +213,7 @@
> > #define TRCACATRn_EXLEVEL_MASK GENMASK(14, 8)
> > #define TRCSSCSRn_STATUS BIT(31)
> > +#define TRCSSCSRn_PENDING BIT(30)
> > #define TRCSSCCRn_SAC_ARC_RST_MASK GENMASK(24, 0)
> > #define TRCSSPCICRn_PC_MASK GENMASK(7, 0)
> > @@ -898,6 +899,7 @@ struct etmv4_caps {
> > bool atbtrig : 1;
> > bool lpoverride : 1;
> > bool skip_power_up : 1;
> > + u32 ss_status[ETM_MAX_SS_CMP];
>
> Needs kernel_doc also.
Thanks .I'll add comment for ss_status
>
> Thanks,
> Jie
>
>
> > };
> > /**
> > @@ -976,7 +978,6 @@ struct etmv4_config {
> > u32 res_ctrl[ETM_MAX_RES_SEL]; /* TRCRSCTLRn */
> > u8 ss_idx;
> > u32 ss_ctrl[ETM_MAX_SS_CMP];
> > - u32 ss_status[ETM_MAX_SS_CMP];
> > u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> > u8 addr_idx;
> > u64 addr_val[ETM_MAX_SINGLE_ADDR_CMP];
>
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v3 1/5] coresight: etm4x: introduce struct etm4_caps
From: Yeoreum Yun @ 2026-04-13 10:03 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, leo.yan
In-Reply-To: <6ed0ee60-caa2-4a76-9e01-5d2b8c9af701@oss.qualcomm.com>
Hi Jie,
>
> Hi Yeoreum,
>
> On 4/13/2026 1:55 AM, Yeoreum Yun wrote:
> > introduce struct etm4_caps to describe ETMv4 capabilities
> > and move capabilities information into it.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > .../coresight/coresight-etm4x-core.c | 234 +++++++++---------
> > .../coresight/coresight-etm4x-sysfs.c | 190 ++++++++------
> > drivers/hwtracing/coresight/coresight-etm4x.h | 175 ++++++-------
> > 3 files changed, 327 insertions(+), 272 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > index d565a73f0042..6443f3717b37 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>
> <...>
>
> > +/**
> > + * struct etmv4_caps - specifics ETM capabilities
> > + * @nr_pe: The number of processing entity available for tracing.
> > + * @nr_pe_cmp: The number of processing entity comparator inputs that are
> > + * available for tracing.
> > + * @nr_addr_cmp:Number of pairs of address comparators available
> > + * as found in ETMIDR4 0-3.
> > + * @nr_cntr: Number of counters as found in ETMIDR5 bit 28-30.
> > + * @nr_ext_inp: Number of external input.
> > + * @numcidc: Number of contextID comparators.
>
> @numextinsel:
>
> > + * @numvmidc: Number of VMID comparators.
> > + * @nrseqstate: The number of sequencer states that are implemented.
> > + * @nr_event: Indicates how many events the trace unit support.
> > + * @nr_resource:The number of resource selection pairs available for tracing.
> > + * @nr_ss_cmp: Number of single-shot comparator controls that are available.
> > + * @trcid_size: Indicates the trace ID width.
> > + * @ts_size: Global timestamp size field.
> > + * @ctxid_size: Size of the context ID field to consider.
> > + * @vmid_size: Size of the VM ID comparator to consider.
> > + * @ccsize: Indicates the size of the cycle counter in bits.
> > + * @ccitmin: minimum value that can be programmed in
> > + * @s_ex_level: In secure state, indicates whether instruction tracing is
> > + * supported for the corresponding Exception level.
> > + * @ns_ex_level:In non-secure state, indicates whether instruction tracing is
> > + * supported for the corresponding Exception level.
> > + * @q_support: Q element support characteristics.
> > + * @os_lock_model: OSLock model.
> > + * @instrp0: Tracing of load and store instructions
> > + * as P0 elements is supported.
> > + * @q_filt: Q element filtering support, if Q elements are supported.
> > + * @trcbb: Indicates if the trace unit supports branch broadcast tracing.
> > + * @trccond: If the trace unit supports conditional
> > + * instruction tracing.
> > + * @retstack: Indicates if the implementation supports a return stack.
> > + * @trccci: Indicates if the trace unit supports cycle counting
> > + * for instruction.
> > + * @trc_error: Whether a trace unit can trace a system
> > + * error exception.
> > + * @syncpr: Indicates if an implementation has a fixed
> > + * synchronization period.
> > + * @stallctl: If functionality that prevents trace unit buffer overflows
> > + * is available.
> > + * @sysstall: Does the system support stall control of the PE?
> > + * @nooverflow: Indicate if overflow prevention is supported.
> > + * @atbtrig: If the implementation can support ATB triggers
> > + * @lpoverride: If the implementation can support low-power state over.
> > + * @skip_power_up: Indicates if an implementation can skip powering up
> > + * the trace unit.
> > + */
> > +struct etmv4_caps {
> > + u8 nr_pe;
> > + u8 nr_pe_cmp;
> > + u8 nr_addr_cmp;
> > + u8 nr_cntr;
> > + u8 nr_ext_inp;
> > + u8 numcidc;
> > + u8 numextinsel;
>
> missed kernel_doc.
>
> Thanks,
> Jie
Thanks. I'll add comment for numextinsel.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH RFC] arm64/scs: Fix potential sign extension issue of advance_loc4
From: Wentao Guan @ 2026-04-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: catalin.marinas, will, hello, linux-kernel, Wentao Guan
The expression (*opcode++ << 24) and exp * code_alignment_factor
may overflow signed int and becomes negative.
Fix this by casting each byte to u64 before shifting. Also fix
the misaligned break statement while we are here.
Example of the result can be seen here:
Link: https://godbolt.org/z/zhY8d3595
It maybe not a real problem, but could be a issue in future.
Fixes: d499e9627d70 ("arm64/scs: Fix handling of advance_loc4")
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
arch/arm64/kernel/pi/patch-scs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/pi/patch-scs.c b/arch/arm64/kernel/pi/patch-scs.c
index dac568e4a54f2..3944ad899021c 100644
--- a/arch/arm64/kernel/pi/patch-scs.c
+++ b/arch/arm64/kernel/pi/patch-scs.c
@@ -196,9 +196,9 @@ static int scs_handle_fde_frame(const struct eh_frame *frame,
loc += *opcode++ * code_alignment_factor;
loc += (*opcode++ << 8) * code_alignment_factor;
loc += (*opcode++ << 16) * code_alignment_factor;
- loc += (*opcode++ << 24) * code_alignment_factor;
+ loc += ((u64)*opcode++ << 24) * code_alignment_factor;
size -= 4;
- break;
+ break;
case DW_CFA_def_cfa:
case DW_CFA_offset_extended:
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v2 6/6] perf arm_spe: Print remaining IMPDEF event numbers
From: Leo Yan @ 2026-04-13 9:52 UTC (permalink / raw)
To: Jie Gan
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,
Ian Rogers, Adrian Hunter, Al Grant, linux-arm-kernel,
linux-perf-users, linux-kernel
In-Reply-To: <3e7645cf-28cb-4021-89e6-e467e9555ff4@oss.qualcomm.com>
Hi Jie,
On Sat, Apr 11, 2026 at 09:08:18AM +0800, Jie Gan wrote:
[...]
> > + /*
> > + * Print remaining IMPDEF bits that weren't printed above as raw
> > + * "IMPDEF:1,2,3,4" etc.
> > + */
> > + if (payload) {
> > + int i;
> > +
> > + arm_spe_pkt_out_string(&err, &buf, &buf_len, " IMPDEF:");
> > + for_each_set_bit(i, &payload, 64) {
>
> for_each_set_bit(i, &payload, 64) passes &payload where payload is u64. The
> macro expands to find_next_bit(const unsigned long *addr, ...). On a 32-bit
> host unsigned long is 32 bits wide, so only the low 32 bits of payload would
> be scanned; bits 32–63 would be silently ignored.
I think this is incorrect.
Even though unsigned long / long is 32 bits on 32-bit CPU, this should
be handled by the BITS_PER_LONG macro. The FIND_NEXT_BIT() macro can
fetch consecutive long values when the size > BITS_PER_LONG.
> While perf is almost
> always built on a 64-bit host today, the tools/ tree is explicitly portable
> and the compiler will emit a -Wpointer-arith / -Wincompatible-pointer-types
> warning on a 32-bit build.
I agree we should fix building issue on 32-bit target.
Thanks,
Leo
^ permalink raw reply
* RE: [PATCH 1/4] pinctrl: realtek: Enable compile testing
From: Yu-Chun Lin [林祐君] @ 2026-04-13 9:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Linus Walleij, Andreas Färber
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Jeffery, linux-aspeed@lists.ozlabs.org,
openbmc@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org,
Joel Stanley, linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰]
In-Reply-To: <20260410-pinctrl-testing-v1-1-6f708c855867@oss.qualcomm.com>
> Enable compile testing for Realtek pin controller drivers for increased build
> and static checkers coverage. PINCTRL_RTD uses
> pinconf_generic_dt_node_to_map(), thus needs OF.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/pinctrl/Makefile | 2 +-
> drivers/pinctrl/realtek/Kconfig | 12 ++++++------
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index
> 9d33fa28a096..b054cfb99348 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -82,7 +82,7 @@ obj-y += nuvoton/
> obj-y += nxp/
> obj-$(CONFIG_PINCTRL_PXA) += pxa/
> obj-y += qcom/
> -obj-$(CONFIG_ARCH_REALTEK) += realtek/
> +obj-$(CONFIG_PINCTRL_RTD) += realtek/
> obj-$(CONFIG_PINCTRL_RENESAS) += renesas/
> obj-$(CONFIG_PINCTRL_SAMSUNG) += samsung/
> obj-y += sophgo/
> diff --git a/drivers/pinctrl/realtek/Kconfig b/drivers/pinctrl/realtek/Kconfig
> index 054e85db99e7..a156c4ef556e 100644
> --- a/drivers/pinctrl/realtek/Kconfig
> +++ b/drivers/pinctrl/realtek/Kconfig
> @@ -2,8 +2,8 @@
>
> config PINCTRL_RTD
> tristate "Realtek DHC core pin controller driver"
> - depends on ARCH_REALTEK
> - default y
> + depends on ARCH_REALTEK || (COMPILE_TEST && OF)
> + default ARCH_REALTEK
> select PINMUX
> select GENERIC_PINCONF
> select REGMAP_MMIO
> @@ -11,22 +11,22 @@ config PINCTRL_RTD
> config PINCTRL_RTD1619B
> tristate "Realtek DHC 1619B pin controller driver"
> depends on PINCTRL_RTD
> - default y
> + default ARCH_REALTEK
>
> config PINCTRL_RTD1319D
> tristate "Realtek DHC 1319D pin controller driver"
> depends on PINCTRL_RTD
> - default y
> + default ARCH_REALTEK
>
> config PINCTRL_RTD1315E
> tristate "Realtek DHC 1315E pin controller driver"
> depends on PINCTRL_RTD
> - default y
> + default ARCH_REALTEK
>
> config PINCTRL_RTD1625
> tristate "Realtek DHC 1625 pin controller driver"
> depends on PINCTRL_RTD
> - default y
> + default ARCH_REALTEK
> help
> This driver enables support for the pin controller on the Realtek
> RTD1625 SoCs.
>
> --
> 2.51.0
Reviewed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 updates for 7.1
From: Paolo Bonzini @ 2026-04-13 9:48 UTC (permalink / raw)
To: Marc Zyngier
Cc: Alexandru Elisei, Arnd Bergmann, Catalin Marinas, Fuad Tabba,
James Clark, Joey Gouly, John Stultz, Jonathan Cameron,
Kalesh Singh, Leo Yan, Mark Brown, Mostafa Saleh,
Nathan Chancellor, Oliver Upton, Quentin Perret, Sascha Bischoff,
Sebastian Ene, Steven Rostedt, Suzuki K Poulose,
Vincent Donnefort, Wei-Lin Chang, Will Deacon, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
In-Reply-To: <20260408155509.548103-1-maz@kernel.org>
On Wed, Apr 8, 2026 at 5:55 PM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> 7.1 should be a pretty large milestone for KVM/arm64. Of note, we have:
>
> - the hypervisor tracing infrastructure, which is pretty large on its
> own, but also comes with an equally large set of tracing specific
> patches (we share a branch with the tracing tree).
>
> - the first set of patches for native GICv5 support, limited to PPIs
> for the time being. I expect this to take a few kernel revisions
> to reach the feature-complete state.
>
> - some movement on the pKVM front, in the form of protected guest and
> protected memory support.
>
> The rest is a large set of fixes, cleanups and rework in order to make
> some of the most hairy code more maintainable (user_mem_abort() being
> the most significant example).
Pulled, thanks. Since I usually send my PR around Thursday, by that
time the tracing changes should be in.
Paolo
> Please pull,
>
> M.
>
> The following changes since commit f338e77383789c0cae23ca3d48adcc5e9e137e3c:
>
> Linux 7.0-rc4 (2026-03-15 13:52:05 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-7.1
>
> for you to fetch changes up to 94b4ae79ebb42a8a6f2124b4d4b033b15a98e4f9:
>
> Merge branch kvm-arm64/misc-7.1 into kvmarm-master/next (2026-04-08 12:26:11 +0100)
>
> ----------------------------------------------------------------
> KVM/arm64 updates for 7.1
>
> * New features:
>
> - Add support for tracing in the standalone EL2 hypervisor code,
> which should help both debugging and performance analysis.
> This comes with a full infrastructure for 'remote' trace buffers
> that can be exposed by non-kernel entities such as firmware.
>
> - Add support for GICv5 Per Processor Interrupts (PPIs), as the
> starting point for supporting the new GIC architecture in KVM.
>
> - Finally add support for pKVM protected guests, with anonymous
> memory being used as a backing store. About time!
>
> * Improvements and bug fixes:
>
> - Rework the dreaded user_mem_abort() function to make it more
> maintainable, reducing the amount of state being exposed to
> the various helpers and rendering a substantial amount of
> state immutable.
>
> - Expand the Stage-2 page table dumper to support NV shadow
> page tables on a per-VM basis.
>
> - Tidy up the pKVM PSCI proxy code to be slightly less hard
> to follow.
>
> - Fix both SPE and TRBE in non-VHE configurations so that they
> do not generate spurious, out of context table walks that
> ultimately lead to very bad HW lockups.
>
> - A small set of patches fixing the Stage-2 MMU freeing in error
> cases.
>
> - Tighten-up accepted SMC immediate value to be only #0 for host
> SMCCC calls.
>
> - The usual cleanups and other selftest churn.
>
> ----------------------------------------------------------------
> Arnd Bergmann (3):
> tracing: add more symbols to whitelist
> KVM: arm64: tracing: add ftrace dependency
> KVM: arm64: avoid unused-variable warning
>
> Fuad Tabba (14):
> KVM: arm64: Extract VMA size resolution in user_mem_abort()
> KVM: arm64: Introduce struct kvm_s2_fault to user_mem_abort()
> KVM: arm64: Extract PFN resolution in user_mem_abort()
> KVM: arm64: Isolate mmap_read_lock inside new kvm_s2_fault_get_vma_info() helper
> KVM: arm64: Extract stage-2 permission logic in user_mem_abort()
> KVM: arm64: Extract page table mapping in user_mem_abort()
> KVM: arm64: Simplify nested VMA shift calculation
> KVM: arm64: Remove redundant state variables from struct kvm_s2_fault
> KVM: arm64: Simplify return logic in user_mem_abort()
> KVM: arm64: Initialize struct kvm_s2_fault completely at declaration
> KVM: arm64: Optimize early exit checks in kvm_s2_fault_pin_pfn()
> KVM: arm64: Hoist MTE validation check out of MMU lock path
> KVM: arm64: Clean up control flow in kvm_s2_fault_map()
> KVM: arm64: Expose self-hosted debug regs as RAZ/WI for protected guests
>
> Marc Zyngier (49):
> tracing: Restore accidentally removed SPDX tag
> KVM: arm64: pkvm: Move error handling to the end of kvm_hyp_cpu_entry
> KVM: arm64: pkvm: Simplify BTI handling on CPU boot
> KVM: arm64: pkvm: Turn __kvm_hyp_init_cpu into an inner label
> KVM: arm64: pkvm: Use direct function pointers for cpu_{on,resume}
> KVM: arm64: Remove extra ISBs when using msr_hcr_el2
> KVM: arm64: Kill fault->ipa
> KVM: arm64: Make fault_ipa immutable
> KVM: arm64: Move fault context to const structure
> KVM: arm64: Replace fault_is_perm with a helper
> KVM: arm64: Constrain fault_granule to kvm_s2_fault_map()
> KVM: arm64: Kill write_fault from kvm_s2_fault
> KVM: arm64: Kill exec_fault from kvm_s2_fault
> KVM: arm64: Kill topup_memcache from kvm_s2_fault
> KVM: arm64: Move VMA-related information to kvm_s2_fault_vma_info
> KVM: arm64: Kill logging_active from kvm_s2_fault
> KVM: arm64: Restrict the scope of the 'writable' attribute
> KVM: arm64: Move kvm_s2_fault.{pfn,page} to kvm_s2_vma_info
> KVM: arm64: Replace force_pte with a max_map_size attribute
> KVM: arm64: Move device mapping management into kvm_s2_fault_pin_pfn()
> KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
> KVM: arm64: Simplify integration of adjust_nested_*_perms()
> KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_desc
> KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
> KVM: arm64: Don't skip per-vcpu NV initialisation
> arm64: Fix field references for ICH_PPI_DVIR[01]_EL2
> KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1
> KVM: arm64: Account for RESx bits in __compute_fgt()
> KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs
> KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2
> KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behaviours
> KVM: arm64: vgic-v5: Make the effective priority mask a strict limit
> KVM: arm64: vgic-v5: Correctly set dist->ready once initialised
> KVM: arm64: Kill arch_timer_context::direct field
> KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer()
> KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid()
> KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
> KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supported
> KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
> KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
> Merge branch kvm-arm64/hyp-tracing into kvmarm-master/next
> Merge branch kvm-arm64/vgic-v5-ppi into kvmarm-master/next
> Merge branch kvm-arm64/nv-s2-debugfs into kvmarm-master/next
> Merge branch kvm-arm64/pkvm-psci into kvmarm-master/next
> Merge branch kvm-arm64/user_mem_abort-rework into kvmarm-master/next
> Merge branch kvm-arm64/spe-trbe-nvhe into kvmarm-master/next
> Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/next
> Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
> Merge branch kvm-arm64/misc-7.1 into kvmarm-master/next
>
> Nathan Chancellor (1):
> tracing: Adjust cmd_check_undefined to show unexpected undefined symbols
>
> Quentin Perret (1):
> KVM: arm64: Inject SIGSEGV on illegal accesses
>
> Sascha Bischoff (41):
> KVM: arm64: vgic-v3: Drop userspace write sanitization for ID_AA64PFR0.GIC on GICv5
> KVM: arm64: vgic: Rework vgic_is_v3() and add vgic_host_has_gicvX()
> KVM: arm64: Return early from kvm_finalize_sys_regs() if guest has run
> KVM: arm64: vgic: Split out mapping IRQs and setting irq_ops
> arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support
> arm64/sysreg: Add GICR CDNMIA encoding
> KVM: arm64: gic-v5: Add ARM_VGIC_V5 device to KVM headers
> KVM: arm64: gic: Introduce interrupt type helpers
> KVM: arm64: gic-v5: Add Arm copyright header
> KVM: arm64: gic-v5: Detect implemented PPIs on boot
> KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE
> KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs
> KVM: arm64: gic-v5: Add emulation for ICC_IAFFIDR_EL1 accesses
> KVM: arm64: gic-v5: Trap and emulate ICC_IDR0_EL1 accesses
> KVM: arm64: gic-v5: Add vgic-v5 save/restore hyp interface
> KVM: arm64: gic-v5: Implement GICv5 load/put and save/restore
> KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask
> KVM: arm64: gic: Introduce queue_irq_unlock to irq_ops
> KVM: arm64: gic-v5: Implement PPI interrupt injection
> KVM: arm64: gic-v5: Init Private IRQs (PPIs) for GICv5
> KVM: arm64: gic-v5: Clear TWI if single task running
> KVM: arm64: gic-v5: Check for pending PPIs
> KVM: arm64: gic-v5: Trap and mask guest ICC_PPI_ENABLERx_EL1 writes
> KVM: arm64: Introduce set_direct_injection irq_op
> KVM: arm64: gic-v5: Implement direct injection of PPIs
> KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE
> KVM: arm64: gic-v5: Create and initialise vgic_v5
> KVM: arm64: gic-v5: Initialise ID and priority bits when resetting vcpu
> irqchip/gic-v5: Introduce minimal irq_set_type() for PPIs
> KVM: arm64: gic-v5: Enlighten arch timer for GICv5
> KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5
> KVM: arm64: gic: Hide GICv5 for protected guests
> KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests
> KVM: arm64: gic-v5: Introduce kvm_arm_vgic_v5_ops and register them
> KVM: arm64: gic-v5: Set ICH_VCTLR_EL2.En on boot
> KVM: arm64: gic-v5: Probe for GICv5 device
> Documentation: KVM: Introduce documentation for VGICv5
> KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI
> KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest
> KVM: arm64: selftests: Add no-vgic-v5 selftest
> KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIs
>
> Sebastian Ene (1):
> KVM: arm64: Prevent the host from using an smc with imm16 != 0
>
> Vincent Donnefort (35):
> ring-buffer: Add page statistics to the meta-page
> ring-buffer: Store bpage pointers into subbuf_ids
> ring-buffer: Introduce ring-buffer remotes
> ring-buffer: Add non-consuming read for ring-buffer remotes
> tracing: Introduce trace remotes
> tracing: Add reset to trace remotes
> tracing: Add non-consuming read to trace remotes
> tracing: Add init callback to trace remotes
> tracing: Add events to trace remotes
> tracing: Add events/ root files to trace remotes
> tracing: Add helpers to create trace remote events
> ring-buffer: Export buffer_data_page and macros
> tracing: Introduce simple_ring_buffer
> tracing: Add a trace remote module for testing
> tracing: selftests: Add trace remote tests
> Documentation: tracing: Add tracing remotes
> tracing: load/unload page callbacks for simple_ring_buffer
> tracing: Check for undefined symbols in simple_ring_buffer
> KVM: arm64: Add PKVM_DISABLE_STAGE2_ON_PANIC
> KVM: arm64: Add clock support to nVHE/pKVM hyp
> KVM: arm64: Initialise hyp_nr_cpus for nVHE hyp
> KVM: arm64: Support unaligned fixmap in the pKVM hyp
> KVM: arm64: Add tracing capability for the nVHE/pKVM hyp
> KVM: arm64: Add trace remote for the nVHE/pKVM hyp
> KVM: arm64: Sync boot clock with the nVHE/pKVM hyp
> KVM: arm64: Add trace reset to the nVHE/pKVM hyp
> KVM: arm64: Add event support to the nVHE/pKVM hyp and trace remote
> KVM: arm64: Add hyp_enter/hyp_exit events to nVHE/pKVM hyp
> KVM: arm64: Add selftest event support to nVHE/pKVM hyp
> tracing: selftests: Add hypervisor trace remote tests
> KVM: arm64: Fix out-of-tree build for nVHE/pKVM tracing
> tracing: Update undefined symbols allow list for simple_ring_buffer
> tracing: Generate undef symbols allowlist for simple_ring_buffer
> tracing: Non-consuming read for trace remotes with an offline CPU
> tracing: selftests: Extend hotplug testing for trace remotes
>
> Wei-Lin Chang (2):
> KVM: arm64: ptdump: Make KVM ptdump code s2 mmu aware
> KVM: arm64: nv: Expose shadow page tables in debugfs
>
> Will Deacon (44):
> KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
> KVM: arm64: Disable SPE Profiling Buffer when running in guest context
> KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
> KVM: arm64: Remove unused PKVM_ID_FFA definition
> KVM: arm64: Don't leak stage-2 page-table if VM fails to init under pKVM
> KVM: arm64: Move handle check into pkvm_pgtable_stage2_destroy_range()
> KVM: arm64: Rename __pkvm_pgtable_stage2_unmap()
> KVM: arm64: Don't advertise unsupported features for protected guests
> KVM: arm64: Remove is_protected_kvm_enabled() checks from hypercalls
> KVM: arm64: Ignore MMU notifier callbacks for protected VMs
> KVM: arm64: Prevent unsupported memslot operations on protected VMs
> KVM: arm64: Ignore -EAGAIN when mapping in pages for the pKVM host
> KVM: arm64: Split teardown hypercall into two phases
> KVM: arm64: Introduce __pkvm_host_donate_guest()
> KVM: arm64: Hook up donation hypercall to pkvm_pgtable_stage2_map()
> KVM: arm64: Handle aborts from protected VMs
> KVM: arm64: Introduce __pkvm_reclaim_dying_guest_page()
> KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()
> KVM: arm64: Factor out pKVM host exception injection logic
> KVM: arm64: Support translation faults in inject_host_exception()
> KVM: arm64: Avoid pointless annotation when mapping host-owned pages
> KVM: arm64: Generalise kvm_pgtable_stage2_set_owner()
> KVM: arm64: Introduce host_stage2_set_owner_metadata_locked()
> KVM: arm64: Change 'pkvm_handle_t' to u16
> KVM: arm64: Annotate guest donations with handle and gfn in host stage-2
> KVM: arm64: Introduce hypercall to force reclaim of a protected page
> KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler
> KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte
> KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs
> KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs
> KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs
> KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled
> KVM: arm64: Add some initial documentation for pKVM
> KVM: arm64: Extend pKVM page ownership selftests to cover guest donation
> KVM: arm64: Register 'selftest_vm' in the VM table
> KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim
> KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs
> KVM: arm64: Rename PKVM_PAGE_STATE_MASK
> drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL
> KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm'
> KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM
> KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
> KVM: arm64: Don't leave mmu->pgt dangling on kvm_init_stage2_mmu() error
> KVM: arm64: Destroy stage-2 page-table in kvm_arch_destroy_vm()
>
> Zenghui Yu (Huawei) (2):
> KVM: arm64: ptdump: Initialize parser_state before pgtable walk
> KVM: arm64: selftests: Avoid testing the IMPDEF behavior
>
> Documentation/admin-guide/kernel-parameters.txt | 4 +-
> Documentation/trace/index.rst | 11 +
> Documentation/trace/remotes.rst | 66 +
> Documentation/virt/kvm/api.rst | 6 +-
> Documentation/virt/kvm/arm/index.rst | 1 +
> Documentation/virt/kvm/arm/pkvm.rst | 106 ++
> Documentation/virt/kvm/devices/arm-vgic-v5.rst | 50 +
> Documentation/virt/kvm/devices/index.rst | 1 +
> Documentation/virt/kvm/devices/vcpu.rst | 5 +-
> arch/arm64/include/asm/el2_setup.h | 4 +-
> arch/arm64/include/asm/kvm_asm.h | 44 +-
> arch/arm64/include/asm/kvm_define_hypevents.h | 16 +
> arch/arm64/include/asm/kvm_host.h | 50 +-
> arch/arm64/include/asm/kvm_hyp.h | 14 +-
> arch/arm64/include/asm/kvm_hypevents.h | 60 +
> arch/arm64/include/asm/kvm_hyptrace.h | 26 +
> arch/arm64/include/asm/kvm_mmu.h | 4 +
> arch/arm64/include/asm/kvm_pgtable.h | 45 +-
> arch/arm64/include/asm/kvm_pkvm.h | 4 +-
> arch/arm64/include/asm/sysreg.h | 13 +-
> arch/arm64/include/asm/virt.h | 9 +
> arch/arm64/include/asm/vncr_mapping.h | 3 +
> arch/arm64/include/uapi/asm/kvm.h | 1 +
> arch/arm64/kernel/cpufeature.c | 1 +
> arch/arm64/kernel/hyp-stub.S | 1 -
> arch/arm64/kernel/image-vars.h | 4 +
> arch/arm64/kernel/vmlinux.lds.S | 18 +
> arch/arm64/kvm/Kconfig | 64 +-
> arch/arm64/kvm/Makefile | 2 +
> arch/arm64/kvm/arch_timer.c | 102 +-
> arch/arm64/kvm/arm.c | 69 +-
> arch/arm64/kvm/config.c | 127 +-
> arch/arm64/kvm/emulate-nested.c | 68 +
> arch/arm64/kvm/handle_exit.c | 2 +-
> arch/arm64/kvm/hyp/include/hyp/switch.h | 27 +
> arch/arm64/kvm/hyp/include/nvhe/arm-smccc.h | 23 +
> arch/arm64/kvm/hyp/include/nvhe/clock.h | 16 +
> arch/arm64/kvm/hyp/include/nvhe/define_events.h | 14 +
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 12 +-
> arch/arm64/kvm/hyp/include/nvhe/memory.h | 12 +-
> arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 7 +-
> arch/arm64/kvm/hyp/include/nvhe/trace.h | 70 +
> arch/arm64/kvm/hyp/include/nvhe/trap_handler.h | 2 +
> arch/arm64/kvm/hyp/nvhe/Makefile | 8 +-
> arch/arm64/kvm/hyp/nvhe/clock.c | 65 +
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 116 +-
> arch/arm64/kvm/hyp/nvhe/events.c | 25 +
> arch/arm64/kvm/hyp/nvhe/ffa.c | 28 +-
> arch/arm64/kvm/hyp/nvhe/host.S | 13 +-
> arch/arm64/kvm/hyp/nvhe/hyp-init.S | 41 +-
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 294 +++--
> arch/arm64/kvm/hyp/nvhe/hyp.lds.S | 6 +
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 587 ++++++++-
> arch/arm64/kvm/hyp/nvhe/mm.c | 4 +-
> arch/arm64/kvm/hyp/nvhe/pkvm.c | 239 +++-
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 45 +-
> arch/arm64/kvm/hyp/nvhe/setup.c | 4 +-
> arch/arm64/kvm/hyp/nvhe/stacktrace.c | 6 +-
> arch/arm64/kvm/hyp/nvhe/switch.c | 23 +-
> arch/arm64/kvm/hyp/nvhe/sys_regs.c | 18 +-
> arch/arm64/kvm/hyp/nvhe/trace.c | 306 +++++
> arch/arm64/kvm/hyp/pgtable.c | 33 +-
> arch/arm64/kvm/hyp/vgic-v5-sr.c | 166 +++
> arch/arm64/kvm/hyp/vhe/Makefile | 2 +-
> arch/arm64/kvm/hyp_trace.c | 442 +++++++
> arch/arm64/kvm/hyp_trace.h | 11 +
> arch/arm64/kvm/mmu.c | 624 +++++----
> arch/arm64/kvm/nested.c | 11 +-
> arch/arm64/kvm/pkvm.c | 159 ++-
> arch/arm64/kvm/pmu-emul.c | 20 +-
> arch/arm64/kvm/ptdump.c | 79 +-
> arch/arm64/kvm/stacktrace.c | 8 +-
> arch/arm64/kvm/sys_regs.c | 188 ++-
> arch/arm64/kvm/vgic/vgic-init.c | 228 +++-
> arch/arm64/kvm/vgic/vgic-kvm-device.c | 107 +-
> arch/arm64/kvm/vgic/vgic-mmio.c | 40 +-
> arch/arm64/kvm/vgic/vgic-v3.c | 2 +-
> arch/arm64/kvm/vgic/vgic-v5.c | 499 ++++++-
> arch/arm64/kvm/vgic/vgic.c | 173 ++-
> arch/arm64/kvm/vgic/vgic.h | 53 +-
> arch/arm64/mm/fault.c | 33 +-
> arch/arm64/tools/sysreg | 480 +++++++
> drivers/irqchip/irq-gic-v5.c | 18 +
> drivers/virt/coco/pkvm-guest/Kconfig | 2 +-
> fs/tracefs/inode.c | 1 +
> include/kvm/arm_arch_timer.h | 8 +-
> include/kvm/arm_pmu.h | 5 +-
> include/kvm/arm_vgic.h | 191 ++-
> include/linux/irqchip/arm-gic-v5.h | 27 +
> include/linux/kvm_host.h | 1 +
> include/linux/ring_buffer.h | 58 +
> include/linux/ring_buffer_types.h | 41 +
> include/linux/simple_ring_buffer.h | 65 +
> include/linux/trace_remote.h | 48 +
> include/linux/trace_remote_event.h | 33 +
> include/trace/define_remote_events.h | 73 ++
> include/uapi/linux/kvm.h | 7 +
> include/uapi/linux/trace_mmap.h | 8 +-
> kernel/trace/Kconfig | 14 +
> kernel/trace/Makefile | 59 +
> kernel/trace/remote_test.c | 261 ++++
> kernel/trace/remote_test_events.h | 10 +
> kernel/trace/ring_buffer.c | 354 ++++-
> kernel/trace/simple_ring_buffer.c | 517 ++++++++
> kernel/trace/trace.c | 4 +-
> kernel/trace/trace.h | 7 +
> kernel/trace/trace_remote.c | 1384 ++++++++++++++++++++
> tools/arch/arm64/include/uapi/asm/kvm.h | 1 +
> tools/include/uapi/linux/kvm.h | 2 +
> .../selftests/ftrace/test.d/remotes/buffer_size.tc | 25 +
> .../selftests/ftrace/test.d/remotes/functions | 99 ++
> .../selftests/ftrace/test.d/remotes/hotplug.tc | 88 ++
> .../test.d/remotes/hypervisor/buffer_size.tc | 11 +
> .../ftrace/test.d/remotes/hypervisor/hotplug.tc | 11 +
> .../ftrace/test.d/remotes/hypervisor/reset.tc | 11 +
> .../ftrace/test.d/remotes/hypervisor/trace.tc | 11 +
> .../ftrace/test.d/remotes/hypervisor/trace_pipe.tc | 11 +
> .../ftrace/test.d/remotes/hypervisor/unloading.tc | 11 +
> .../selftests/ftrace/test.d/remotes/reset.tc | 90 ++
> .../selftests/ftrace/test.d/remotes/trace.tc | 102 ++
> .../selftests/ftrace/test.d/remotes/trace_pipe.tc | 102 ++
> .../selftests/ftrace/test.d/remotes/unloading.tc | 41 +
> tools/testing/selftests/kvm/Makefile.kvm | 3 +-
> tools/testing/selftests/kvm/arm64/at.c | 14 +-
> tools/testing/selftests/kvm/arm64/no-vgic-v3.c | 177 ---
> tools/testing/selftests/kvm/arm64/no-vgic.c | 297 +++++
> tools/testing/selftests/kvm/arm64/set_id_regs.c | 52 +-
> tools/testing/selftests/kvm/arm64/vgic_v5.c | 228 ++++
> tools/testing/selftests/kvm/include/arm64/gic_v5.h | 150 +++
> 129 files changed, 10017 insertions(+), 1086 deletions(-)
> create mode 100644 Documentation/trace/remotes.rst
> create mode 100644 Documentation/virt/kvm/arm/pkvm.rst
> create mode 100644 Documentation/virt/kvm/devices/arm-vgic-v5.rst
> create mode 100644 arch/arm64/include/asm/kvm_define_hypevents.h
> create mode 100644 arch/arm64/include/asm/kvm_hypevents.h
> create mode 100644 arch/arm64/include/asm/kvm_hyptrace.h
> create mode 100644 arch/arm64/kvm/hyp/include/nvhe/arm-smccc.h
> create mode 100644 arch/arm64/kvm/hyp/include/nvhe/clock.h
> create mode 100644 arch/arm64/kvm/hyp/include/nvhe/define_events.h
> create mode 100644 arch/arm64/kvm/hyp/include/nvhe/trace.h
> create mode 100644 arch/arm64/kvm/hyp/nvhe/clock.c
> create mode 100644 arch/arm64/kvm/hyp/nvhe/events.c
> create mode 100644 arch/arm64/kvm/hyp/nvhe/trace.c
> create mode 100644 arch/arm64/kvm/hyp/vgic-v5-sr.c
> create mode 100644 arch/arm64/kvm/hyp_trace.c
> create mode 100644 arch/arm64/kvm/hyp_trace.h
> create mode 100644 include/linux/ring_buffer_types.h
> create mode 100644 include/linux/simple_ring_buffer.h
> create mode 100644 include/linux/trace_remote.h
> create mode 100644 include/linux/trace_remote_event.h
> create mode 100644 include/trace/define_remote_events.h
> create mode 100644 kernel/trace/remote_test.c
> create mode 100644 kernel/trace/remote_test_events.h
> create mode 100644 kernel/trace/simple_ring_buffer.c
> create mode 100644 kernel/trace/trace_remote.c
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/buffer_size.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/functions
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hotplug.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/buffer_size.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/hotplug.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/reset.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/trace.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/trace_pipe.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/hypervisor/unloading.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/reset.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/trace.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/trace_pipe.tc
> create mode 100644 tools/testing/selftests/ftrace/test.d/remotes/unloading.tc
> delete mode 100644 tools/testing/selftests/kvm/arm64/no-vgic-v3.c
> create mode 100644 tools/testing/selftests/kvm/arm64/no-vgic.c
> create mode 100644 tools/testing/selftests/kvm/arm64/vgic_v5.c
> create mode 100644 tools/testing/selftests/kvm/include/arm64/gic_v5.h
>
^ permalink raw reply
* Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device
From: Jie Gan @ 2026-04-13 9:27 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Yeoreum Yun,
Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz, Thomas Gleixner, Peter Zijlstra, coresight,
linux-arm-kernel
In-Reply-To: <20260413084833.GA356832@e132581.arm.com>
Hi Leo,
On 4/13/2026 4:48 PM, Leo Yan wrote:
> On Mon, Apr 13, 2026 at 01:45:50PM +0800, Jie Gan wrote:
>
> [...]
>
>>> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct coresight_path *path)
>>> to = list_prev_entry(coresight_path_last_node(path), link);
>>> coresight_disable_path_from_to(path, from, to);
>>> + ret = coresight_pm_device_save(coresight_get_sink(path));
>>> + if (ret)
>>> + goto sink_failed;
>>> +
>>> return 0;
>>> +
>>> +sink_failed:
>>> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
>>> + from, to))
>>> + coresight_pm_device_restore(source);
>>
>> I have go through the history messages. I have a question about this point
>> here:
>>
>> how can we handle the scenario if coresight_enable_path_from_to failed? It
>> means we are never calling coresight_pm_device_restore for the ETM and
>> leaving the ETM with OS lock state until CPU reset?
>
> From a design perspective, if any failure occurs in the idle flow, the
> priority is to avoid further mess, especially partial enable/disable
> sequences that could lead to lockups.
>
> The case you mentioned is a typical risk - if a path after source to
> sink fails to be enabled, it is unsafe to arbitrarily enable the source
> further. We rely on the per-CPU flag "percpu_pm_failed" to disable idle
> states, if ETE/TRBE fails to be disabled, if CPU is turned off, this
> also might cause lockup.
understood.
>
>> Consider we are calling etm4_disable_hw with OS lock:
>> etm4_disable_hw -> etm4_disable_trace_unit -> etm4x_wait_status (may timeout
>> here?)
>
> This is expected. I don't want to introduce a _recovery_ mechanism for
> CPU PM failures, which is complex and over-engineering. CPU PM notifier
> is low level code, and in my experience, PM issues can be easily
> observed once CPU idle is enabled and should be resolved during the
> development phase.
>
> In many cases PM issues are often not caused by CoreSight drivers but by
> other modules (e.g., clock or regulator drivers). The log "Failed in
> coresight PM save ..." reminds developers the bugs. As said,
> percpu_pm_failed is used as a last resort to prevent the platform from
> locking up if there is a PM bug.
Thanks for the explanation.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* RE: [PATCH 4/4] ARM: realtek: MAINTAINERS: Include pin controller drivers
From: Yu-Chun Lin [林祐君] @ 2026-04-13 9:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, Linus Walleij, Andreas Färber
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Jeffery, linux-aspeed@lists.ozlabs.org,
openbmc@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org,
Joel Stanley, linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰]
In-Reply-To: <20260410-pinctrl-testing-v1-4-6f708c855867@oss.qualcomm.com>
> No dedicated maintainers are shown for Realtek SoC pin controllers, except
> pinctrl subsystem maintainer, which means reduced review and impression of
> abandoned drivers. Pin controller drivers are essential part of an SoC, so in
> case of lack of dedicated entry at least cover it by the SoC platform
> maintainers.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> This patch should go via Realtek SoC maintainers, not pinctrl.
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10d12b51b1f6..374ce55e4fb6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3373,6 +3373,7 @@ F:
> Documentation/devicetree/bindings/arm/realtek.yaml
> F: arch/arm/boot/dts/realtek/
> F: arch/arm/mach-realtek/
> F: arch/arm64/boot/dts/realtek/
> +F: drivers/pinctrl/realtek/
>
> ARM/RISC-V/RENESAS ARCHITECTURE
> M: Geert Uytterhoeven <geert+renesas@glider.be>
>
> --
> 2.51.0
Acked-by: Yu-Chun Lin <eleanor.lin@realtek.com>
^ permalink raw reply
* Re: [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Neil Armstrong @ 2026-04-13 9:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jian Hu, Jerome Brunet, Kevin Hilman,
Michael Turquette, Martin Blumenstingl, robh+dt, Rob Herring
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <b0d81181-d4a4-4c03-8c26-c7f6e8cde70f@kernel.org>
On 4/13/26 11:10, Krzysztof Kozlowski wrote:
> On 13/04/2026 10:21, Jian Hu wrote:
>>
>> On 4/12/2026 5:55 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On 10/04/2026 12:03, Jian Hu wrote:
>>>> Add support for the A1 and T7 SoC family in amlogic clk measure.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
>>>> 1 file changed, 272 insertions(+)
>>>>
>>>> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
>>>> index d862e30a244e..083524671b76 100644
>>>> --- a/drivers/soc/amlogic/meson-clk-measure.c
>>>> +++ b/drivers/soc/amlogic/meson-clk-measure.c
>>>> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>>>>
>>>> };
>>>>
>>>> +static struct meson_msr_id clk_msr_a1[] = {
>>> And existing code uses what sort of array? Seems you send us obsolete or
>>> downstream code.
>>
>>
>> Thanks for your review.
>>
>>
>> I have checked the previous Amlogic SoC's commits. Such as Amlogic AXG,
>> G12A, C3, S4.
>>
>> The clk_msr_xx entry is added after last SoC's array, sorted by
>> submissin date rather than alphabetical order.
>>
>> So I place A1 and T7 after S4 accordingly.
>>
>>
>> The A1 clock controller driver was already supported in
>> https://lore.kernel.org/all/20230523135351.19133-7-ddrokosov@sberdevices.ru/
>>
>> It is also present in the mainline kernel:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/Kconfig#n113
>>
>>
>> This clock measure IP is used to measure the internal clock paths
>> frequencies, and A1 clock controller driver was supported.
>>
>> Since the corresponding clock measure driver does not support A1 yet, So
>> add A1 clk msr here.
>
> No, what qualifiers or keywords are used for existing arrays? IOW,
> please investigate and understand why you are doing this very different
> than existing code. Maybe because you sent us downstream, so you
> replicated all other downstream issues.
I see, the existing uses "static const struct".
Jian, could to switch to that please ?
Neil
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: bcm4709: fix bus range assignment
From: Arnd Bergmann @ 2026-04-13 9:21 UTC (permalink / raw)
To: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rosen Penev
Cc: soc, Arnd Bergmann, Broadcom internal kernel review list,
linux-arm-kernel, devicetree, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
The netgear r8000 dts file limits the bus range for the first host
bridge to exclude bus 0, but the two devices on the first bus are
explicitly assigned to bus 0, causing a build time warning:
/home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@1,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
/home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@2,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
I could not find any reason why this is done in the first place, but
this can be easily addressed by reassigning the two devices to
bus 1, or by dropping the bus-range property in order to allow
secondary bus 0 to be assigned.
Assuming the bus-range is intentional, fix this by moving the
devices to the first valid secondary bus number.
Fixes: 893faf67438c ("ARM: dts: BCM5301X: add root pcie bridges")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
index d170c71cbd76..355be5014943 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
@@ -147,7 +147,7 @@ pcie@0,0 {
pcie@1,0 {
device_type = "pci";
- reg = <0x800 0 0 0 0>;
+ reg = <0x10800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -162,7 +162,7 @@ wifi@0,0 {
pcie@2,0 {
device_type = "pci";
- reg = <0x1000 0 0 0 0>;
+ reg = <0x11000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 3/4] KVM: arm64: sefltests: Add basic NV selftest
From: Wei-Lin Chang @ 2026-04-13 9:18 UTC (permalink / raw)
To: Itaru Kitayama
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan
In-Reply-To: <adwofV7yf71OdMFk@sm-arm-grace07>
Hi Itaru,
On Mon, Apr 13, 2026 at 08:19:25AM +0900, Itaru Kitayama wrote:
> On Sun, Apr 12, 2026 at 03:22:15PM +0100, Wei-Lin Chang wrote:
> > This selftest simply starts an L1, which starts its own guest (L2). L2
> > runs without stage-1 and 2 translations, it calls an HVC to jump back
> > to L1.
>
> How do you disable both the nested guest (L2)'s MMU and stage 2
> translations?
Guest stage-2 is disabled by not setting HCR_EL2.VM in prepare_hyp(),
and stage-1 is disabled by not writing to SCTLR_EL12 in init_vcpu(),
effectively using the default value set by L0. However since SCTLR_EL1
has many architecturally UNKNOWN bits (including SCTLR_EL1.M), it should
be better to write a value before running L2 I suppose...
Thanks,
Wei-Lin Chang
>
> Itaru.
>
> >
> > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > ---
> > tools/testing/selftests/kvm/Makefile.kvm | 1 +
> > .../selftests/kvm/arm64/hello_nested.c | 103 ++++++++++++++++++
> > 2 files changed, 104 insertions(+)
> > create mode 100644 tools/testing/selftests/kvm/arm64/hello_nested.c
> >
> > diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> > index 3dc3e39f7025..e8c108e0c487 100644
> > --- a/tools/testing/selftests/kvm/Makefile.kvm
> > +++ b/tools/testing/selftests/kvm/Makefile.kvm
> > @@ -168,6 +168,7 @@ TEST_GEN_PROGS_arm64 += arm64/arch_timer_edge_cases
> > TEST_GEN_PROGS_arm64 += arm64/at
> > TEST_GEN_PROGS_arm64 += arm64/debug-exceptions
> > TEST_GEN_PROGS_arm64 += arm64/hello_el2
> > +TEST_GEN_PROGS_arm64 += arm64/hello_nested
> > TEST_GEN_PROGS_arm64 += arm64/host_sve
> > TEST_GEN_PROGS_arm64 += arm64/hypercalls
> > TEST_GEN_PROGS_arm64 += arm64/external_aborts
> > diff --git a/tools/testing/selftests/kvm/arm64/hello_nested.c b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > new file mode 100644
> > index 000000000000..97387e4697b3
> > --- /dev/null
> > +++ b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > @@ -0,0 +1,103 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * hello_nested - Go from vEL2 to EL1 then back
> > + */
> > +
> > +#include "nested.h"
> > +#include "processor.h"
> > +#include "test_util.h"
> > +#include "ucall.h"
> > +
> > +#define XLATE2GPA (0xABCD)
> > +#define L2STACKSZ (0x100)
> > +
> > +/*
> > + * TPIDR_EL2 is used to store vcpu id, so save and restore it.
> > + */
> > +static vm_paddr_t ucall_translate_to_gpa(void *gva)
> > +{
> > + vm_paddr_t gpa;
> > + u64 vcpu_id = read_sysreg(tpidr_el2);
> > +
> > + GUEST_SYNC2(XLATE2GPA, gva);
> > +
> > + /* get the result from userspace */
> > + gpa = read_sysreg(tpidr_el2);
> > +
> > + write_sysreg(vcpu_id, tpidr_el2);
> > +
> > + return gpa;
> > +}
> > +
> > +static void l2_guest_code(void)
> > +{
> > + do_hvc();
> > +}
> > +
> > +static void guest_code(void)
> > +{
> > + struct vcpu vcpu;
> > + struct hyp_data hyp_data;
> > + int ret;
> > + vm_paddr_t l2_pc, l2_stack_top;
> > + /* force 16-byte alignment for the stack pointer */
> > + u8 l2_stack[L2STACKSZ] __attribute__((aligned(16)));
> > +
> > + GUEST_ASSERT_EQ(get_current_el(), 2);
> > + GUEST_PRINTF("vEL2 entry\n");
> > +
> > + l2_pc = ucall_translate_to_gpa(l2_guest_code);
> > + l2_stack_top = ucall_translate_to_gpa(&l2_stack[L2STACKSZ]);
> > +
> > + init_vcpu(&vcpu, l2_pc, l2_stack_top);
> > + prepare_hyp();
> > +
> > + ret = run_l2(&vcpu, &hyp_data);
> > + GUEST_ASSERT_EQ(ret, ARM_EXCEPTION_TRAP);
> > + GUEST_DONE();
> > +}
> > +
> > +int main(void)
> > +{
> > + struct kvm_vcpu_init init;
> > + struct kvm_vcpu *vcpu;
> > + struct kvm_vm *vm;
> > + struct ucall uc;
> > + vm_paddr_t gpa;
> > +
> > + TEST_REQUIRE(kvm_check_cap(KVM_CAP_ARM_EL2));
> > + vm = vm_create(1);
> > +
> > + kvm_get_default_vcpu_target(vm, &init);
> > + init.features[0] |= BIT(KVM_ARM_VCPU_HAS_EL2);
> > + vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
> > + kvm_arch_vm_finalize_vcpus(vm);
> > +
> > + while (true) {
> > + vcpu_run(vcpu);
> > +
> > + switch (get_ucall(vcpu, &uc)) {
> > + case UCALL_SYNC:
> > + if (uc.args[0] == XLATE2GPA) {
> > + gpa = addr_gva2gpa(vm, (vm_vaddr_t)uc.args[1]);
> > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), gpa);
> > + }
> > + break;
> > + case UCALL_PRINTF:
> > + pr_info("%s", uc.buffer);
> > + break;
> > + case UCALL_DONE:
> > + pr_info("DONE!\n");
> > + goto end;
> > + case UCALL_ABORT:
> > + REPORT_GUEST_ASSERT(uc);
> > + fallthrough;
> > + default:
> > + TEST_FAIL("Unhandled ucall: %ld\n", uc.cmd);
> > + }
> > + }
> > +
> > +end:
> > + kvm_vm_free(vm);
> > + return 0;
> > +}
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [patch 07/38] treewide: Consolidate cycles_t
From: Ojaswin Mujoo @ 2026-04-13 9:15 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120318.045532623@kernel.org>
On Fri, Apr 10, 2026 at 02:19:03PM +0200, Thomas Gleixner wrote:
> Most architectures define cycles_t as unsigned long execpt:
>
> - x86 requires it to be 64-bit independent of the 32-bit/64-bit build.
>
> - parisc and mips define it as unsigned int
>
> parisc has no real reason to do so as there are only a few usage sites
> which either expand it to a 64-bit value or utilize only the lower
> 32bits.
>
> mips has no real requirement either.
>
> Move the typedef to types.h and provide a config switch to enforce the
> 64-bit type for x86.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> arch/Kconfig | 4 ++++
> arch/alpha/include/asm/timex.h | 3 ---
> arch/arm/include/asm/timex.h | 1 -
> arch/loongarch/include/asm/timex.h | 2 --
> arch/m68k/include/asm/timex.h | 2 --
> arch/mips/include/asm/timex.h | 2 --
> arch/nios2/include/asm/timex.h | 2 --
> arch/parisc/include/asm/timex.h | 2 --
> arch/powerpc/include/asm/timex.h | 4 +---
> arch/riscv/include/asm/timex.h | 2 --
> arch/s390/include/asm/timex.h | 2 --
> arch/sparc/include/asm/timex_64.h | 1 -
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/tsc.h | 2 --
> include/asm-generic/timex.h | 1 -
> include/linux/types.h | 6 ++++++
> 16 files changed, 12 insertions(+), 25 deletions(-)
>
<...>
> --- a/arch/powerpc/include/asm/timex.h
> +++ b/arch/powerpc/include/asm/timex.h
> @@ -11,9 +11,7 @@
> #include <asm/cputable.h>
> #include <asm/vdso/timebase.h>
>
> -typedef unsigned long cycles_t;
> -
> -static inline cycles_t get_cycles(void)
> +ostatic inline cycles_t get_cycles(void)
Hi Thomas, I'm in middle of testing this series on powerpc. In the meantime I
noticed that there's probably a small typo here (althrough this is fixed
later)
Regards,
ojaswin
> {
> return mftb();
> }
^ permalink raw reply
* Re: [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Krzysztof Kozlowski @ 2026-04-13 9:10 UTC (permalink / raw)
To: Jian Hu, Neil Armstrong, Jerome Brunet, Kevin Hilman,
Michael Turquette, Martin Blumenstingl, robh+dt, Rob Herring
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <274d2abd-05b9-4dbd-b962-ff70044b8d07@amlogic.com>
On 13/04/2026 10:21, Jian Hu wrote:
>
> On 4/12/2026 5:55 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 10/04/2026 12:03, Jian Hu wrote:
>>> Add support for the A1 and T7 SoC family in amlogic clk measure.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> ---
>>> drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
>>> 1 file changed, 272 insertions(+)
>>>
>>> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
>>> index d862e30a244e..083524671b76 100644
>>> --- a/drivers/soc/amlogic/meson-clk-measure.c
>>> +++ b/drivers/soc/amlogic/meson-clk-measure.c
>>> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>>>
>>> };
>>>
>>> +static struct meson_msr_id clk_msr_a1[] = {
>> And existing code uses what sort of array? Seems you send us obsolete or
>> downstream code.
>
>
> Thanks for your review.
>
>
> I have checked the previous Amlogic SoC's commits. Such as Amlogic AXG,
> G12A, C3, S4.
>
> The clk_msr_xx entry is added after last SoC's array, sorted by
> submissin date rather than alphabetical order.
>
> So I place A1 and T7 after S4 accordingly.
>
>
> The A1 clock controller driver was already supported in
> https://lore.kernel.org/all/20230523135351.19133-7-ddrokosov@sberdevices.ru/
>
> It is also present in the mainline kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/meson/Kconfig#n113
>
>
> This clock measure IP is used to measure the internal clock paths
> frequencies, and A1 clock controller driver was supported.
>
> Since the corresponding clock measure driver does not support A1 yet, So
> add A1 clk msr here.
No, what qualifiers or keywords are used for existing arrays? IOW,
please investigate and understand why you are doing this very different
than existing code. Maybe because you sent us downstream, so you
replicated all other downstream issues.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PING] Re: [PATCH v7 0/2] arm64: dts/defconfig: enable BST C1200 eMMC
From: Krzysztof Kozlowski @ 2026-04-13 9:09 UTC (permalink / raw)
To: Albert Yang, arnd
Cc: krzk+dt, robh, conor+dt, gordon.ge, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413083441.1758438-1-yangzh0906@thundersoft.com>
On 13/04/2026 10:34, Albert Yang wrote:
> Hi Krzysztof, Arnd, Rob, and Conor,
>
> Gentle ping for this v7 series posted on 2026-03-10:
> https://lore.kernel.org/lkml/20260310091211.4171307-1-yangzh0906@thundersoft.com/
That's a BST patch, so pinging SoC and DT maintainers won't help you.
You need to work with BST maintainers.
Additionally, don't ping during merge window.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: imx8ulp-evk: Correct Type-C int GPIO flags
From: Krzysztof Kozlowski @ 2026-04-13 9:07 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Xu Yang, devicetree, imx, linux-arm-kernel, linux-kernel
Cc: Krzysztof Kozlowski, stable
IRQ_TYPE_xxx flags are not correct in the context of GPIO flags.
These are simple defines so they could be used in DTS but they will not
have the same meaning: IRQ_TYPE_EDGE_FALLING = 2 = GPIO_SINGLE_ENDED.
Correct the Type-C int-gpios to use proper flags, assuming the author of
the code wanted similar logical behavior:
IRQ_TYPE_EDGE_FALLING => GPIO_ACTIVE_LOW
Fixes: c4b4593ecb0b ("arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 290a49bea2f7..5dea66c1e7aa 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -166,7 +166,7 @@ &lpi2c7 {
ptn5150_1: typec@1d {
compatible = "nxp,ptn5150";
reg = <0x1d>;
- int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+ int-gpios = <&gpiof 3 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec1>;
status = "disabled";
@@ -182,7 +182,7 @@ pcal6408: gpio@21 {
ptn5150_2: typec@3d {
compatible = "nxp,ptn5150";
reg = <0x3d>;
- int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+ int-gpios = <&gpiof 5 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_typec2>;
status = "disabled";
--
2.51.0
^ permalink raw reply related
* [PATCH v8 next 02/10] arm_mpam: Add intPARTID and reqPARTID support for Narrow-PARTID feature
From: Zeng Heng @ 2026-04-13 8:53 UTC (permalink / raw)
To: ben.horgan, Dave.Martin, james.morse, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <20260413085405.1166412-1-zengheng4@huawei.com>
Introduce Narrow-PARTID (partid_nrw) feature support, which enables
many-to-one mapping of request PARTIDs (reqPARTID) to internal PARTIDs
(intPARTID). This expands monitoring capability by allowing a single
control group to track more task types through multiple reqPARTIDs
per intPARTID, bypassing the PMG limit in some extent.
intPARTID: Internal PARTID used for control group configuration.
Configurations are synchronized to all reqPARTIDs mapped to the same
intPARTID. Count is indicated by MPAMF_PARTID_NRW_IDR.INTPARTID_MAX, or
defaults to PARTID count if Narrow-PARTID is unsupported.
reqPARTID: Request PARTID used to expand monitoring groups. Enables
a single control group to monitor more task types by multiple reqPARTIDs
within one intPARTID, overcoming the PMG count limitation.
For systems with homogeneous MSCs (all supporting Narrow-PARTID), the
driver exposes the full reqPARTID range directly. For heterogeneous
systems where some MSCs lack Narrow-PARTID support, the driver utilizes
PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring
capacity.
So, the numbers of control group and monitoring group are calculated as:
n = min(intPARTID, PARTID) /* the number of control groups */
l = min(reqPARTID, PARTID) /* the number of monitoring groups */
m = l // n /* monitoring groups per control group */
Where:
intPARTID: intPARTIDs on Narrow-PARTID-capable MSCs
reqPARTID: reqPARTIDs on Narrow-PARTID-capable MSCs
PARTID: PARTIDs on non-Narrow-PARTID-capable MSCs
Example: L3 cache (256 PARTIDs, without Narrow-PARTID feature) +
MATA (32 intPARTIDs, 256 reqPARTIDs):
n = min( 32, 256) = 32 intPARTIDs
l = min(256, 256) = 256 reqPARTIDs
m = 256 / 32 = 8 reqPARTIDs per intPARTID
Implementation notes:
* Handle mixed MSC systems (some support Narrow-PARTID, some don't) by
taking minimum number of intPARTIDs across all MSCs.
* resctrl_arch_get_num_closid() now returns the number of intPARTIDs
(was PARTID).
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
drivers/resctrl/mpam_devices.c | 30 ++++++++++++++++++++----------
drivers/resctrl/mpam_internal.h | 2 ++
drivers/resctrl/mpam_resctrl.c | 4 ++--
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index 41b14344b16f..cf067bf5092e 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c
@@ -63,6 +63,7 @@ static DEFINE_MUTEX(mpam_cpuhp_state_lock);
* Generating traffic outside this range will result in screaming interrupts.
*/
u16 mpam_partid_max;
+u16 mpam_intpartid_max;
u8 mpam_pmg_max;
static bool partid_max_init, partid_max_published;
static DEFINE_SPINLOCK(partid_max_lock);
@@ -288,10 +289,12 @@ int mpam_register_requestor(u16 partid_max, u8 pmg_max)
{
guard(spinlock)(&partid_max_lock);
if (!partid_max_init) {
+ mpam_intpartid_max = partid_max;
mpam_partid_max = partid_max;
mpam_pmg_max = pmg_max;
partid_max_init = true;
} else if (!partid_max_published) {
+ mpam_intpartid_max = min(mpam_intpartid_max, partid_max);
mpam_partid_max = min(mpam_partid_max, partid_max);
mpam_pmg_max = min(mpam_pmg_max, pmg_max);
} else {
@@ -931,7 +934,9 @@ static void mpam_ris_hw_probe(struct mpam_msc_ris *ris)
u16 partid_max = FIELD_GET(MPAMF_PARTID_NRW_IDR_INTPARTID_MAX, nrwidr);
mpam_set_feature(mpam_feat_partid_nrw, props);
- msc->partid_max = min(msc->partid_max, partid_max);
+ msc->intpartid_max = min(msc->partid_max, partid_max);
+ } else {
+ msc->intpartid_max = msc->partid_max;
}
}
@@ -995,6 +1000,7 @@ static int mpam_msc_hw_probe(struct mpam_msc *msc)
spin_lock(&partid_max_lock);
mpam_partid_max = min(mpam_partid_max, msc->partid_max);
+ mpam_intpartid_max = min(mpam_intpartid_max, msc->intpartid_max);
mpam_pmg_max = min(mpam_pmg_max, msc->pmg_max);
spin_unlock(&partid_max_lock);
@@ -1711,7 +1717,7 @@ static int mpam_reset_ris(void *arg)
return 0;
spin_lock(&partid_max_lock);
- partid_max = mpam_partid_max;
+ partid_max = mpam_intpartid_max;
spin_unlock(&partid_max_lock);
for (partid = 0; partid <= partid_max; partid++)
mpam_reprogram_ris_partid(ris, partid, &reset_cfg);
@@ -1767,7 +1773,7 @@ static void mpam_reprogram_msc(struct mpam_msc *msc)
struct mpam_write_config_arg arg;
/*
- * No lock for mpam_partid_max as partid_max_published has been
+ * No lock for mpam_intpartid_max as partid_max_published has been
* set by mpam_enabled(), so the values can no longer change.
*/
mpam_assert_partid_sizes_fixed();
@@ -1784,7 +1790,7 @@ static void mpam_reprogram_msc(struct mpam_msc *msc)
arg.comp = ris->vmsc->comp;
arg.ris = ris;
reset = true;
- for (partid = 0; partid <= mpam_partid_max; partid++) {
+ for (partid = 0; partid <= mpam_intpartid_max; partid++) {
cfg = &ris->vmsc->comp->cfg[partid];
if (!bitmap_empty(cfg->features, MPAM_FEATURE_LAST))
reset = false;
@@ -2607,7 +2613,7 @@ static void mpam_reset_component_cfg(struct mpam_component *comp)
if (!comp->cfg)
return;
- for (i = 0; i <= mpam_partid_max; i++) {
+ for (i = 0; i <= mpam_intpartid_max; i++) {
comp->cfg[i] = (struct mpam_config) {};
if (cprops->cpbm_wd)
comp->cfg[i].cpbm = GENMASK(cprops->cpbm_wd - 1, 0);
@@ -2627,7 +2633,7 @@ static int __allocate_component_cfg(struct mpam_component *comp)
if (comp->cfg)
return 0;
- comp->cfg = kzalloc_objs(*comp->cfg, mpam_partid_max + 1);
+ comp->cfg = kzalloc_objs(*comp->cfg, mpam_intpartid_max + 1);
if (!comp->cfg)
return -ENOMEM;
@@ -2694,7 +2700,7 @@ static void mpam_enable_once(void)
int err;
/*
- * Once the cpuhp callbacks have been changed, mpam_partid_max can no
+ * Once the cpuhp callbacks have been changed, mpam_intpartid_max can no
* longer change.
*/
spin_lock(&partid_max_lock);
@@ -2743,9 +2749,13 @@ static void mpam_enable_once(void)
mpam_register_cpuhp_callbacks(mpam_cpu_online, mpam_cpu_offline,
"mpam:online");
- /* Use printk() to avoid the pr_fmt adding the function name. */
- printk(KERN_INFO "MPAM enabled with %u PARTIDs and %u PMGs\n",
- mpam_partid_max + 1, mpam_pmg_max + 1);
+ if (mpam_partid_max == mpam_intpartid_max)
+ /* Use printk() to avoid the pr_fmt adding the function name. */
+ printk(KERN_INFO "MPAM enabled with %u PARTIDs and %u PMGs\n",
+ mpam_partid_max + 1, mpam_pmg_max + 1);
+ else
+ printk(KERN_INFO "MPAM enabled with %u reqPARTIDs, %u intPARTIDs and %u PMGs\n",
+ mpam_partid_max + 1, mpam_intpartid_max + 1, mpam_pmg_max + 1);
}
static void mpam_reset_component_locked(struct mpam_component *comp)
diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
index 1914aefdcba9..790a90a5ccd9 100644
--- a/drivers/resctrl/mpam_internal.h
+++ b/drivers/resctrl/mpam_internal.h
@@ -81,6 +81,7 @@ struct mpam_msc {
*/
struct mutex probe_lock;
bool probed;
+ u16 intpartid_max;
u16 partid_max;
u8 pmg_max;
unsigned long ris_idxs;
@@ -452,6 +453,7 @@ extern struct list_head mpam_classes;
/* System wide partid/pmg values */
extern u16 mpam_partid_max;
+extern u16 mpam_intpartid_max;
extern u8 mpam_pmg_max;
/* Scheduled work callback to enable mpam once all MSC have been probed */
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 161fb8905e28..5f4364c8101a 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -223,7 +223,7 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level rid, bool enable)
mpam_resctrl_controls[RDT_RESOURCE_MBA].resctrl_res.alloc_capable = false;
if (enable) {
- if (mpam_partid_max < 1)
+ if (mpam_intpartid_max < 1)
return -EINVAL;
partid_d = resctrl_get_config_index(RESCTRL_RESERVED_CLOSID, CDP_DATA);
@@ -254,7 +254,7 @@ static bool mpam_resctrl_hide_cdp(enum resctrl_res_level rid)
*/
u32 resctrl_arch_get_num_closid(struct rdt_resource *ignored)
{
- return mpam_partid_max + 1;
+ return mpam_intpartid_max + 1;
}
u32 resctrl_arch_system_num_rmid_idx(void)
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox