* [PATCH v16 07/28] drm/atomic-helper: Add HDMI bridge output bus formats helper
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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 3547f797a850..285aac3554df 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>
@@ -4107,3 +4108,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 b84152810abb..4cfeec70d648 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.54.0
^ permalink raw reply related
* [PATCH v16 06/28] drm/bridge: Act on the DRM color format property
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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 687b36eea0c7..6ec8c23b36b5 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1149,6 +1149,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.
@@ -1192,6 +1233,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;
@@ -1233,11 +1275,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.54.0
^ permalink raw reply related
* [PATCH v16 05/28] drm/display: bridge_connector: Use HDMI color format for HDMI conns
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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 649969fca141..19da5f668942 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.54.0
^ permalink raw reply related
* [PATCH v16 04/28] drm/connector: Let connectors have a say in their color format
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Dmitry Baryshkov
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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 a0fca522f18f..41a5ab1e563e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3685,6 +3685,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 03e42c36175d..c9aad2bc8227 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1787,6 +1787,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);
};
/**
@@ -2603,6 +2613,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.54.0
^ permalink raw reply related
* [PATCH v16 03/28] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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>
Reviewed-by: Daniel Stone <daniel@fooishbar.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 | 4 +
drivers/gpu/drm/drm_connector.c | 155 ++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 84 +++++++++++++++++++
5 files changed, 254 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index fa69a5450f96..2b6a96211cfc 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -604,6 +604,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 51f39edc31ed..3547f797a850 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 6441b55cc274..c7f80d90794c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -935,6 +935,8 @@ 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) {
+ state->color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1020,6 +1022,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 3fa4d2082cd7..a0fca522f18f 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
@@ -2935,6 +2947,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 5ad62c207d00..03e42c36175d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -571,12 +571,80 @@ 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,
};
const char *
@@ -1167,6 +1235,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 +2240,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 +2729,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.54.0
^ permalink raw reply related
* [PATCH v16 00/28] Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
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 (YCbCr 4:4:4, YCbCr 4:2:0, RGB, Auto) + DP (YCbCr 4:4:4, 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 v16:
- drm/i915/dp: Don't check for dfp conversion to determine ycbcr444
output capability
- drm/i915/dp: Replicate intel_dp_has_hdmi_sink check for YCBCR444 as well
- drm/i915/dp: Reorder formats and checks in sink_format_valid
- drm/i915/hdmi: Fix inverted HAS_GMCH check for YCBCR444 capability
- drm/i915/hdmi: Add has_hdmi_sink check to YCBCR444 sink_format_valid
- drm/i915/hdmi: Reorder formats in sink_format_valid
- drm/i915/hdmi: Drop documentation for internal function
- Link to v15: https://patch.msgid.link/20260522-color-format-v15-0-21fb136c9df2@collabora.com
Changes in v15:
- Drop redundant drm_connector_color_format_valid() function
- dw-hdmi-qp-rockchip: make dw_hdmi_qp_rockchip_get_vop_format()'s
return type int, check bstate for IS_ERR rather than NULL, and pass up
error codes to caller
- rebase onto recent drm-tip, necessitating
s/drm_atomic_state/drm_atomic_commit/ in the KUnit tests
- Link to v14: https://patch.msgid.link/20260423-color-format-v14-0-449a419ccbd4@collabora.com
Changes in v14:
- i915: Check for source support of YCbCr444 in both the sink format
validation and when registering the properites on the connectors.
- i915: Split HDMI and DP implementations into separate patches, with
their own supported color formats masks.
- Link to v13: https://patch.msgid.link/20260413-color-format-v13-0-ab37d4dfba48@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 (27):
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/hdmi: Implement "color format" DRM property
drm/i915/dp: Implement "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 | 4 +
drivers/gpu/drm/drm_bridge.c | 104 ++-
drivers/gpu/drm/drm_connector.c | 178 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 81 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 76 +-
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 | 96 ++
19 files changed, 2228 insertions(+), 37 deletions(-)
---
base-commit: 8345929e243a7114bc17c48d0ff01923d2daae76
change-id: 20251028-color-format-49fd202b7183
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* [PATCH v16 02/28] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-05-23 19:43 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260523-color-format-v16-0-24340c5e4732@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>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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 4867edbf2622..3ba47564caad 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.54.0
^ permalink raw reply related
* [PATCH] dt-bindings: clock: renesas: div6: Use ZT/ZTR trace clock in R-Mobile APE6 example
From: Marek Vasut @ 2026-05-23 19:25 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Brian Masney, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Michael Turquette, Rob Herring, Stephen Boyd,
devicetree, linux-clk, linux-kernel, linux-renesas-soc
Since commit 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks:
Document ZT/ZTR trace clock on R-Mobile APE6"), the APE6 clock node
expects two additional "clock-output-names" entries, "zt" and "ztr".
Update the example accordingly.
Fixes: 2abdc3dcf978 ("dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Brian Masney <bmasney@redhat.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../devicetree/bindings/clock/renesas,cpg-div6-clock.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml
index 2197c952e21df..b6ee8c8efd46d 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml
@@ -60,7 +60,7 @@ examples:
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll2s", "pll2h", "z", "z2",
"i", "m3", "b", "m1", "m2",
- "zx", "zs", "hp";
+ "zx", "zs", "hp", "ztr", "zt";
};
sdhi2_clk: sdhi2_clk@e615007c {
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] devicetree: Mark QCE bindings as deprecated
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:03 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King
Cc: linux-kernel, linux-crypto, linux-arm-msm, Eric Biggers,
Ard Biesheuvel, devicetree, linux-arm-kernel, Demi Marie Obenour
In-Reply-To: <20260523-delete-qce-v1-0-86105cd7f406@gmail.com>
From: Demi Marie Obenour <demiobenour@gmail.com>
They are no longer used by the kernel. Keep them to avoid unnecessary
churn and because I know next to nothing about devicetree.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 08febd66c22ba8220860f1a59403782d12f8531f..0f378073ddf550ff5954fbe169d5d262a4e46dcf 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -14,6 +14,9 @@ description:
This document defines the binding for the QCE crypto
controller found on Qualcomm parts.
+ This driver is no longer used and so this binding only exists
+ for backwards compatibility.
+
properties:
compatible:
oneOf:
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] Delete the Qualcomm crypto engine
From: Demi Marie Obenour via B4 Relay @ 2026-05-23 19:03 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King
Cc: linux-kernel, linux-crypto, linux-arm-msm, Eric Biggers,
Ard Biesheuvel, devicetree, linux-arm-kernel, Demi Marie Obenour
The only realistic uses I can think of are:
1. Very weak devices where QCE is actually faster.
2. Devices without bitsliced NEON.
Do any such devices exist in the wild? I have no idea.
Not even compile-tested, but should be trivial as it just deletes code.
I didn't change the device tree beyond marking the bindings as
deprecated.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Demi Marie Obenour (2):
crypto: Delete Qualcomm crypto engine driver
devicetree: Mark QCE bindings as deprecated
.../devicetree/bindings/crypto/qcom-qce.yaml | 3 +
MAINTAINERS | 8 -
arch/arm/configs/multi_v7_defconfig | 1 -
arch/arm64/configs/defconfig | 1 -
drivers/crypto/Kconfig | 111 ---
drivers/crypto/Makefile | 1 -
drivers/crypto/qce/Makefile | 9 -
drivers/crypto/qce/aead.c | 841 ---------------------
drivers/crypto/qce/aead.h | 56 --
drivers/crypto/qce/cipher.h | 56 --
drivers/crypto/qce/common.c | 595 ---------------
drivers/crypto/qce/common.h | 104 ---
drivers/crypto/qce/core.c | 271 -------
drivers/crypto/qce/core.h | 64 --
drivers/crypto/qce/dma.c | 135 ----
drivers/crypto/qce/dma.h | 47 --
drivers/crypto/qce/regs-v5.h | 326 --------
drivers/crypto/qce/sha.c | 545 -------------
drivers/crypto/qce/sha.h | 72 --
drivers/crypto/qce/skcipher.c | 529 -------------
20 files changed, 3 insertions(+), 3772 deletions(-)
---
base-commit: 49e05bb00f2e8168695f7af4d694c39e1423e8a2
change-id: 20260523-delete-qce-0363d22a8596
Best regards,
--
Demi Marie Obenour <demiobenour@gmail.com>
^ permalink raw reply
* [PATCH v2] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Karthikeyan KS @ 2026-05-23 17:35 UTC (permalink / raw)
To: joel, andrew
Cc: andrew, jdelvare, linux-arm-kernel, linux-aspeed, linux-kernel,
Karthikeyan KS
In-Reply-To: <c3d474a1ec807e686c0b7ac70cc75f86898aee99.camel@codeconstruct.com.au>
put_fifo_with_discard() violates kfifo's single-producer/single-consumer
lock-free contract by calling both kfifo_skip() (consumer op: out++) and
kfifo_put() (producer op: in++) from the IRQ handler context.
kfifo_skip() increments 'out' without a memory barrier, while
kfifo_put() increments 'in' with smp_wmb(). On ARM (weakly ordered), a
concurrent reader on another CPU can observe the new 'in' but a stale
'out', causing (in - out) to exceed the buffer size.
__kfifo_to_user() clamps the copy length to (in - out), but since that
value is already corrupted by the race, the clamp is ineffective. The
subsequent kfifo_copy_to_user() ring-buffer split produces a second
chunk exceeding the 2048-byte kmalloc-2k slab object, triggering:
Backtrace:
[ 2.972611] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-2k' (offset 0, size 2049)!
[ 2.974191] ------------[ cut here ]------------
[ 2.974677] kernel BUG at mm/usercopy.c:99!
[ 2.975068] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 2.975755] Modules linked in: post_injector(O)
[ 2.976668] CPU: 0 PID: 1 Comm: init Tainted: G O 5.15.178 #4
[ 2.977316] Hardware name: Generic DT based system
[ 2.977848] PC is at usercopy_abort+0x80/0xa8
[ 2.978931] LR is at vprintk_emit+0xf0/0x230
[ 2.979296] pc : [<8095c3a0>] lr : [<8017cb2c>] psr: 60000153
[ 2.979781] sp : 810e3dc8 ip : 810e3d38 fp : 810e3dec
[ 2.980192] r10: 00000003 r9 : 811ea801 r8 : 811ea800
[ 2.980616] r7 : 00000001 r6 : 00000801 r5 : 00000801 r4 : 00000000
[ 2.981104] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000066
[ 2.981712] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[ 2.982363] Control: 00c5387d Table: 81a64008 DAC: 00000051
[ 2.982881] Register r0 information: non-paged memory
[ 2.983662] Register r1 information: NULL pointer
[ 2.984074] Register r2 information: NULL pointer
[ 2.984474] Register r3 information: NULL pointer
[ 2.984879] Register r4 information: NULL pointer
[ 2.985279] Register r5 information: non-paged memory
[ 2.985704] Register r6 information: non-paged memory
[ 2.986118] Register r7 information: non-paged memory
[ 2.986553] Register r8 information: slab kmalloc-2k start 811ea800 pointer offset 0 size 2048
[ 2.987789] Register r9 information: slab kmalloc-2k start 811ea800 pointer offset 1 size 2048
[ 2.988541] Register r10 information: non-paged memory
[ 2.988971] Register r11 information: non-slab/vmalloc memory
[ 2.989511] Register r12 information: non-slab/vmalloc memory
[ 2.990064] Process init (pid: 1, stack limit = 0x041252af)
[ 2.990631] Stack: (0x810e3dc8 to 0x810e4000)
[ 2.991119] 3dc0: 80c2ceb4 80c29fd4 80c1f6d4 00000000 00000801 811ea801
[ 2.992044] 3de0: 810e3e1c 810e3df0 802e3a94 8095c32c 00000801 801168b0 811ea800 811ea800
[ 2.992707] 3e00: 00000801 00000001 811eb001 00000001 810e3e44 810e3e20 802e8774 802e3978
[ 2.993336] 3e20: 810e3e44 810e3e30 00000801 00001000 7edc2593 811ea800 810e3e6c 810e3e48
[ 2.993971] 3e40: 804dedf0 802e8604 811d584c 00001000 810e3e98 7edc1d94 00001000 810e2000
[ 2.994734] 3e60: 810e3e94 810e3e70 804def50 804ded54 810e3e98 804d3f28 00000000 811d586c
[ 2.995377] 3e80: 810e3e98 00000001 810e3ed4 810e3e98 80579a58 804def0c 810e3f34 810e3ea8
[ 2.996024] 3ea0: 80282c74 80282744 00000000 37f2b80b ffffe000 819a2cc0 810e3f68 00000001
[ 2.996684] 3ec0: 805799a8 00001000 810e3f64 810e3ed8 802ee040 805799b4 00000003 1cd5b000
[ 2.997310] 3ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 2.997987] 3f00: 801002c4 37f2b80b 810e2000 810e2000 810e3fb0 00000000 801002c4 80314ce0
[ 2.998678] 3f20: 00000000 00000003 014fc580 00001000 7edc1d94 37f2b80b 810e2000 819a2cc0
[ 2.999268] 3f40: 819a2cc0 00000000 00000000 801002c4 810e2000 00000003 810e3f94 810e3f68
[ 3.000024] 3f60: 802ee740 802edf90 00000000 00000000 00000800 37f2b80b 00000003 014fc580
[ 3.000688] 3f80: 00006f2c 00000003 810e3fa4 810e3f98 802ee7e4 802ee6dc 00000000 810e3fa8
[ 3.001364] 3fa0: 80100080 802ee7d8 00000003 014fc580 00000003 7edc1d94 00001000 00000000
[ 3.002389] 3fc0: 00000003 014fc580 00006f2c 00000003 7edc2f10 00000000 00000001 00000000
[ 3.003042] 3fe0: 000000ac 7edc1d18 0002c174 0002c190 60000150 00000003 00000000 00000000
[ 3.003773] Backtrace:
[ 3.004236] [<8095c320>] (usercopy_abort) from [<802e3a94>] (__check_heap_object+0x128/0x150)
[ 3.005187] [<802e396c>] (__check_heap_object) from [<802e8774>] (__check_object_size+0x17c/0x1e0)
[ 3.005996] r8:00000001 r7:811eb001 r6:00000001 r5:00000801 r4:811ea800
[ 3.006555] [<802e85f8>] (__check_object_size) from [<804dedf0>] (kfifo_copy_to_user+0xa8/0x1b8)
[ 3.007290] r7:811ea800 r6:7edc2593 r5:00001000 r4:00000801
[ 3.007766] [<804ded48>] (kfifo_copy_to_user) from [<804def50>] (__kfifo_to_user+0x50/0x70)
[ 3.008418] r9:810e2000 r8:00001000 r7:7edc1d94 r6:810e3e98 r5:00001000 r4:811d584c
[ 3.009031] [<804def00>] (__kfifo_to_user) from [<80579a58>] (snoop_file_read+0xb0/0xf8)
[ 3.009683] r6:00000001 r5:810e3e98 r4:811d586c
[ 3.010055] [<805799a8>] (snoop_file_read) from [<802ee040>] (vfs_read+0xbc/0x328)
[ 3.010686] r8:00001000 r7:805799a8 r6:00000001 r5:810e3f68 r4:819a2cc0
[ 3.011182] [<802edf84>] (vfs_read) from [<802ee740>] (ksys_read+0x70/0xfc)
[ 3.011762] r10:00000003 r9:810e2000 r8:801002c4 r7:00000000 r6:00000000 r5:819a2cc0
[ 3.012451] r4:819a2cc0
[ 3.012677] [<802ee6d0>] (ksys_read) from [<802ee7e4>] (sys_read+0x18/0x1c)
[ 3.013261] r7:00000003 r6:00006f2c r5:014fc580 r4:00000003
[ 3.013724] [<802ee7cc>] (sys_read) from [<80100080>] (ret_fast_syscall+0x0/0x48)
[ 3.014330] Exception stack(0x810e3fa8 to 0x810e3ff0)
[ 3.014767] 3fa0: 00000003 014fc580 00000003 7edc1d94 00001000 00000000
[ 3.015379] 3fc0: 00000003 014fc580 00006f2c 00000003 7edc2f10 00000000 00000001 00000000
[ 3.016030] 3fe0: 000000ac 7edc1d18 0002c174 0002c190
[ 3.016641] Code: e1cd40fc e58dc000 e59f0024 ebfff741 (e7f001f2)
[ 3.017733] ---[ end trace d9f7e472f48076c9 ]---
[ 3.018380] Kernel panic - not syncing: Fatal exception
[ 3.019190] ---[ end Kernel panic - not syncing: Fatal exception ]---
This is reproducible on AST2500 BMC (dual-core ARM Cortex-A7) when
BIOS floods POST codes while userspace concurrently reads
/dev/aspeed-lpc-snoop0.
Fix by:
1. Clamping 'count' to SNOOP_FIFO_SIZE in snoop_file_read() so that
copy_to_user() can never exceed the slab object boundary regardless
of kfifo pointer state.
2. Protecting the kfifo_skip() + kfifo_put() sequence in
put_fifo_with_discard() and the kfifo_to_user() call in
snoop_file_read() with a spinlock, ensuring pointer updates are
atomic with respect to concurrent access and restoring the
single-writer invariant for each pointer.
put_fifo_with_discard() is only called from hardirq context where
interrupts are already disabled, so plain spin_lock/spin_unlock is
used. snoop_file_read() runs in process context and must use
spin_lock_irqsave to prevent deadlock with the IRQ handler.
Signed-off-by: Karthikeyan KS <karthiproffesional@gmail.com>
---
Andrew,
You're right — __kfifo_to_user() clamps to (in - out). The issue is
that (in - out) itself is corrupted by a race in put_fifo_with_discard().
The function calls kfifo_skip() (out++) then kfifo_put() (in++) without
synchronization. On SMP ARM, the reader observes fresh 'in' (barrier in
kfifo_put) but stale 'out' (no barrier in kfifo_skip), making (in - out)
exceed the buffer size. The clamp then passes through the corrupted value.
Reproduced on QEMU ast2500-evb by injecting POST codes and simulating
the race outcome. Also observed intermittently on physical dual-core
AST2600 under heavy POST code traffic.
Changes since v1:
- Root cause identified as SMP race, not missing read-side clamp
- Added spinlock to put_fifo_with_discard() and snoop_file_read()
- spin_lock() in IRQ context, spin_lock_irqsave() in process context
- Retained count clamp as defense in depth
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index eceeaf8..d084492 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -60,6 +60,7 @@ struct aspeed_lpc_snoop_model_data {
struct aspeed_lpc_snoop_channel {
struct kfifo fifo;
+ spinlock_t lock;
wait_queue_head_t wq;
struct miscdevice miscdev;
};
@@ -83,8 +84,11 @@ static ssize_t snoop_file_read(struct file *file, char __user *buffer,
{
struct aspeed_lpc_snoop_channel *chan = snoop_file_to_chan(file);
unsigned int copied;
+ unsigned long flags;
int ret = 0;
+ count = min_t(size_t, count, SNOOP_FIFO_SIZE);
+
if (kfifo_is_empty(&chan->fifo)) {
if (file->f_flags & O_NONBLOCK)
return -EAGAIN;
@@ -93,7 +97,11 @@ static ssize_t snoop_file_read(struct file *file, char __user *buffer,
if (ret == -ERESTARTSYS)
return -EINTR;
}
+
+ spin_lock_irqsave(&chan->lock, flags);
ret = kfifo_to_user(&chan->fifo, buffer, count, &copied);
+ spin_unlock_irqrestore(&chan->lock, flags);
+
if (ret)
return ret;
@@ -121,9 +129,11 @@ static void put_fifo_with_discard(struct aspeed_lpc_snoop_channel *chan, u8 val)
{
if (!kfifo_initialized(&chan->fifo))
return;
+ spin_lock(&chan->lock);
if (kfifo_is_full(&chan->fifo))
kfifo_skip(&chan->fifo);
kfifo_put(&chan->fifo, val);
+ spin_unlock(&chan->lock);
wake_up_interruptible(&chan->wq);
}
@@ -192,6 +202,7 @@ static int aspeed_lpc_enable_snoop(struct aspeed_lpc_snoop *lpc_snoop,
of_device_get_match_data(dev);
init_waitqueue_head(&lpc_snoop->chan[channel].wq);
+ spin_lock_init(&lpc_snoop->chan[channel].lock);
/* Create FIFO datastructure */
rc = kfifo_alloc(&lpc_snoop->chan[channel].fifo,
SNOOP_FIFO_SIZE, GFP_KERNEL);
^ permalink raw reply related
* [PATCH v4 2/2] dt-bindings: pwm: stmpe: drop legacy binding
From: Manish Baing @ 2026-05-23 17:32 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, manishbaing2789, Conor Dooley
In-Reply-To: <20260523173251.72540-1-manishbaing2789@gmail.com>
The st,stmpe-pwm binding is already covered by the MFD schema
Documentation/devicetree/bindings/mfd/st,stmpe.yaml. Remove the
obsolete and redundant text binding file.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Uwe Kleine-König <ukleinek@kernel.org>
---
.../devicetree/bindings/pwm/st,stmpe-pwm.txt | 18 ------------------
1 file changed, 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/st,stmpe-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/st,stmpe-pwm.txt b/Documentation/devicetree/bindings/pwm/st,stmpe-pwm.txt
deleted file mode 100644
index f401316e0248..000000000000
--- a/Documentation/devicetree/bindings/pwm/st,stmpe-pwm.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-== ST STMPE PWM controller ==
-
-This is a PWM block embedded in the ST Microelectronics STMPE
-(ST Multi-Purpose Expander) chips. The PWM is registered as a
-subdevices of the STMPE MFD device.
-
-Required properties:
-- compatible: should be:
- - "st,stmpe-pwm"
-- #pwm-cells: should be 2. See pwm.yaml in this directory for a description of
- the cells format.
-
-Example:
-
-pwm0: pwm {
- compatible = "st,stmpe-pwm";
- #pwm-cells = <2>;
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
From: Manish Baing @ 2026-05-23 17:32 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, manishbaing2789, Conor Dooley
In-Reply-To: <20260523173251.72540-1-manishbaing2789@gmail.com>
The st,stmpe-pwm binding is already covered by the MFD schema in
Documentation/devicetree/bindings/mfd/st,stmpe.yaml. However, the
PWM subnode was missing a 'required' properties block. This allowed
Device Tree nodes to pass validation even if the 'compatible'
string was omitted. This omission could lead to probe failures
at runtime.
Fix the schema by adding the missing 'required' block.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
---
Documentation/devicetree/bindings/mfd/st,stmpe.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
index df43878fbe18..4bb05d544901 100644
--- a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -127,6 +127,10 @@ properties:
"#pwm-cells":
const: 2
+ required:
+ - compatible
+ - "#pwm-cells"
+
touchscreen:
type: object
$ref: /schemas/input/touchscreen/touchscreen.yaml#
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] dt-bindings: mfd/pwm: Split st,stmpe cleanup into separate patches
From: Manish Baing @ 2026-05-23 17:32 UTC (permalink / raw)
To: lee, ukleinek, robh, krzk+dt, conor+dt, mcoquelin.stm32,
alexandre.torgue, linusw
Cc: linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, manishbaing2789
Hello,
This series splits the previous single patch into two distinct changes
to avoid cross-subsystem merge coordination, as requested by Uwe.
The first patch addresses a validation gap in the MFD YAML schema,
and the second patch drops the redundant legacy PWM text binding.
Changes in v4:
- Split single patch into a 2-patch series based on feedback from Uwe
Kleine-König to prevent cross-subsystem merge conflicts.
Changes in v3:
- Added 'required' properties to the pwm subnode in st,stmpe.yaml
to close a validation gap identified by the Sashiko.
- Updated commit message and description to reflect MFD subsystem changes
Changes in v2:
- Drop the TXT file instead of converting to YAML, as the
functionality is already covered by st,stmpe.yaml.
- Update the commit subject and description to reflect the drop.
Manish Baing (2):
dt-bindings: mfd: st,stmpe: Add missing properties for PWM subnode
dt-bindings: pwm: stmpe: drop legacy binding
.../devicetree/bindings/mfd/st,stmpe.yaml | 4 ++++
.../devicetree/bindings/pwm/st,stmpe-pwm.txt | 18 ------------------
2 files changed, 4 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pwm/st,stmpe-pwm.txt
--
2.43.0
^ permalink raw reply
* Re: [PATCH] pwm: atmel-tcb: Remove unneeded semicolon
From: Uwe Kleine-König @ 2026-05-23 17:09 UTC (permalink / raw)
To: Chen Ni
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-pwm,
linux-arm-kernel
In-Reply-To: <20260518022251.1625520-1-nichen@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Mon, May 18, 2026 at 10:21:25AM +0800, Chen Ni wrote:
> On Sun, May 17, 2026 at 06:52:48PM +0200, Uwe Kleine-König wrote:
>
> > I'd like to pick up this commit, but don't want to modify the commit log
>
> > without your consent. For now this is blocked because of that.
>
> Hi Uwe,
>
> That is fine with me. Please go ahead and add the note to the commit log.
I did that and the patch is now part of
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/fixes
. Thanks for cleaning up after me :-)
(Actually I applied it already a while ago and failed to announce that.)
There are four patches now in pwm/fixes. I don't know yet if I send them
to Linus before v7.1. I'll wait for sure a few days to have them exposed
in next for a while at least.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] arm64: arch_timer: reuse arch_timer_read_cnt{p,v}ct_el0() helpers
From: Breno Leitao @ 2026-05-23 16:59 UTC (permalink / raw)
To: Mark Rutland, Marc Zyngier, Catalin Marinas, Will Deacon
Cc: linux-arm-kernel, linux-kernel, kernel-team, Breno Leitao
__arch_counter_get_cntpct() and __arch_counter_get_cntvct() open-code
the same ECV-aware ALTERNATIVE block that arch_timer_read_cntpct_el0()
and arch_timer_read_cntvct_el0() already provide in the same header.
The two pairs are byte-for-byte identical except for the trailing
arch_counter_enforce_ordering() the __arch_counter_get_* variants add.
Replace the duplicated inline assembly in __arch_counter_get_cntpct()
and __arch_counter_get_cntvct() with calls to the corresponding helpers.
This mirrors commit 00b39d150986 ("arm64: vdso: Use
__arch_counter_get_cntvct()"), which removed similar duplication from
the vDSO, and keeps the system-counter read sequence in a single place,
reducing assembly code in the kernell
No functional change: the resulting inline assembly, alternatives, and
clobbers are unchanged; only the source-level expression of the read
moves into the existing helper.
Verified by rebuilding the consumers of these helpers before and after
the change and comparing the resulting disassembly:
- arch/arm64/kernel/vdso/vdso.so (final linked vDSO):
bit-identical (same sha256 across rebuilds)
- arch/arm64/kernel/vdso/vgettimeofday.o: identical disassembly
- arch/arm64/lib/delay.o: identical disassembly
- drivers/clocksource/arm_arch_timer.o: same 50 functions with
byte-identical instruction streams; only difference is function
ordering inside .text and NOP padding, with no opcodes added or
removed.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/arm64/include/asm/arch_timer.h | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
index f5794d50f51d..6717209df05b 100644
--- a/arch/arm64/include/asm/arch_timer.h
+++ b/arch/arm64/include/asm/arch_timer.h
@@ -178,12 +178,8 @@ static __always_inline u64 __arch_counter_get_cntpct_stable(void)
static __always_inline u64 __arch_counter_get_cntpct(void)
{
- u64 cnt;
+ u64 cnt = arch_timer_read_cntpct_el0();
- asm volatile(ALTERNATIVE("isb\n mrs %0, cntpct_el0",
- "nop\n" __mrs_s("%0", SYS_CNTPCTSS_EL0),
- ARM64_HAS_ECV)
- : "=r" (cnt));
arch_counter_enforce_ordering(cnt);
return cnt;
}
@@ -199,12 +195,8 @@ static __always_inline u64 __arch_counter_get_cntvct_stable(void)
static __always_inline u64 __arch_counter_get_cntvct(void)
{
- u64 cnt;
+ u64 cnt = arch_timer_read_cntvct_el0();
- asm volatile(ALTERNATIVE("isb\n mrs %0, cntvct_el0",
- "nop\n" __mrs_s("%0", SYS_CNTVCTSS_EL0),
- ARM64_HAS_ECV)
- : "=r" (cnt));
arch_counter_enforce_ordering(cnt);
return cnt;
}
---
base-commit: 9f84f9898cf191aa251268547ceef03abb8d1edd
change-id: 20260523-arch64_fix-6416179b7173
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH 0/2] pwm: mediatek: fix mt7628 register offset and clock source
From: Uwe Kleine-König @ 2026-05-23 16:57 UTC (permalink / raw)
To: Shiji Yang, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-pwm, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <ac6OYRkiDt_OJVcp@monoceros>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
hello,
On Thu, Apr 02, 2026 at 05:44:32PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Feb 24, 2026 at 04:51:00PM +0800, Shiji Yang wrote:
> > This patch series fixes support for mt7628.
>
> The series looks reasonable to me. It would be great to get some
> feedback from the Mediatek maintainers, though?!
I applied the two patches now without further feedback to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/fixes
. Not sure yet if I send this branch to Linus before 7.1, but it will be
part of 7.2-rc1 for sure.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] pwm: imx27: Fix variable truncation in .apply()
From: Uwe Kleine-König @ 2026-05-23 16:55 UTC (permalink / raw)
To: Ronaldo Nunez
Cc: linux-pwm, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260522191348.6227-1-rnunez@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
Hello Ronaldo,
On Fri, May 22, 2026 at 04:13:48PM -0300, Ronaldo Nunez wrote:
> Fix a variable truncation when calculating period in microseconds as
> part of the solution for the ERR051198 in .apply() callback.
>
> Example scenario:
> - Period of 3us (PWMPR = 196 and prescaler = 1)
> - Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
> - Actual value is 431504384 (truncation to u32)
>
> Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
Thanks for your patch. I added
Fixes: a25351e4c774 ("pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle")
to the trailers and applied it to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/fixes
. I haven't made up my mind if I create another pull request to get the
patches from the pwm/fixes branch into 7.1. If not, it will go into
7.2-rc1.
Sashiko found a few more issues in the imx27 driver, would you like to
address these, too?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Marc Zyngier @ 2026-05-23 15:24 UTC (permalink / raw)
To: Mark Brown
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <ahG75BY6yvaePj-B@sirena.org.uk>
On Sat, 23 May 2026 15:38:28 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> On Sat, May 23, 2026 at 09:47:38AM +0100, Marc Zyngier wrote:
> > Mark Brown <broonie@kernel.org> wrote:
>
> > > Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> > > written are sanitised based on this.
>
> > Only for the direct writes to ZCR_EL2, as they are trapping. I don't
> > see any sanitisation for writes using the ZCR_EL1 accessor, which is
> > the common case. This needs fixing at the same time.
>
> OK, I'll convert ZCR_EL2 to a sanitised register. As I mentioned I was
> a bit confused about why the existing code is the way it is and so
> followed it in only managing the direct writes. I figured it was
> considered OK to rely on the hardware for the RES0 and WI behaviour for
> untrapped access.
In general, that's OK. But given that you need sanitisation in the
trapping case, it is way better to have a uniform behaviour and keep
sanitisation at the accessor level. It is also more sustainable in the
long run, should ZCR_ELx get new significant bits.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH v3 06/17] arm64: dts: amlogic: Add EL2 virtual timer interrupt
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
The ARMv8.2 based CPUs used in a number of Amlogic SoCs are missing
the EL2 virtual timer interrupt. Add it.
This requires some surgery in the "common" files to move the timer
node to locations that makes it possible to add the interrupt only
where it is actually implemented.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/amlogic/amlogic-a4-common.dtsi | 8 --------
arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi | 8 ++++++++
arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi | 9 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi | 3 ++-
arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi | 3 ++-
arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi | 3 ++-
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 13 -------------
arch/arm64/boot/dts/amlogic/meson-g12.dtsi | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 10 ++++++++++
9 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a4-common.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-a4-common.dtsi
index 54d7a2d56ef64..6f559e4dd9ee9 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-a4-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-a4-common.dtsi
@@ -7,14 +7,6 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
/ {
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
psci {
compatible = "arm,psci-1.0";
method = "smc";
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi
index fce45933fa28b..c28fc7fcbae7f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-a4.dtsi
@@ -86,6 +86,14 @@ pwrc: power-controller {
#power-domain-cells = <1>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
};
&apb {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi
index 2b12d8284594f..c22c0acb4807e 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-a5.dtsi
@@ -49,6 +49,15 @@ pwrc: power-controller {
#power-domain-cells = <1>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ };
};
&apb {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
index ab3acef2b147e..853d32929ff46 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-s6.dtsi
@@ -56,7 +56,8 @@ timer {
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
- <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW>;
};
psci {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi
index a3faf4d188e11..bfaac5f3e22da 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-s7.dtsi
@@ -94,7 +94,8 @@ timer {
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
};
psci {
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi
index 0c4417bcd6827..32d8683059964 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-s7d.dtsi
@@ -58,7 +58,8 @@ timer {
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 12 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
};
psci {
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 00609d2da6743..a911a5181a88d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2579,19 +2579,6 @@ map {
};
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
- arm,no-tick-in-suspend;
- };
-
xtal: xtal-clk {
compatible = "fixed-clock";
clock-frequency = <24000000>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12.dtsi
index 664912d1beaab..866fc07d1b0ae 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12.dtsi
@@ -43,6 +43,15 @@ tdmif_c: audio-controller-2 {
clock-names = "sclk", "lrclk", "mclk";
status = "disabled";
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
+ arm,no-tick-in-suspend;
+ };
};
&apb {
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index 8f5b850b1774f..77c72936ffdd3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -128,6 +128,16 @@ l2: l2-cache0 {
};
};
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 12 (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
+ arm,no-tick-in-suspend;
+ };
+
cpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-shared;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 04/17] dt-bindings: timer: arm,arch_timer: Fix requirements for interrupt description
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
The arm,arch_timer DT binding is extremely imprecise in describing
the requirements for interrupts.
Follow the architecture by making it explicit that:
- the EL1 secure timer irq is required if EL3 is implemented
- the EL1 physical timer irq is always required
- the EL1 virtual timer irq is always required
- the EL2 physical timer irq is required if EL2 is implemented
- the EL2 virtual timer irq is required if FEAT_VHE is implemented
The consequence of the above is that the minimum number of interrupts
to be described is 2, and not 1.
Finally, clean up the description which made the assumption that
the timers are plugged into a GIC (unfortunately, that's not always
true), drop the MMIO nonsense that has long be moved to a separate
binding, and use the architectural terminology to describe the various
interrupts.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
.../bindings/timer/arm,arch_timer.yaml | 21 +++++++------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index c5fc3b6c8bd0b..c65e48a155ab6 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -10,13 +10,8 @@ maintainers:
- Marc Zyngier <marc.zyngier@arm.com>
- Mark Rutland <mark.rutland@arm.com>
description: |+
- ARM cores may have a per-core architected timer, which provides per-cpu timers,
- or a memory mapped architected timer, which provides up to 8 frames with a
- physical and optional virtual timer per frame.
-
- The per-core architected timer is attached to a GIC to deliver its
- per-processor interrupts via PPIs. The memory mapped timer is attached to a GIC
- to deliver its interrupts via SPIs.
+ The per-core architected timer is expected to deliver per-CPU interrupts
+ (commonly to a GIC to deliver its per-processor interrupts as PPIs).
properties:
compatible:
@@ -33,13 +28,13 @@ properties:
- const: arm,armv7-timer
interrupts:
- minItems: 1
+ minItems: 2
items:
- - description: secure timer irq
- - description: non-secure timer irq
- - description: virtual timer irq
- - description: hypervisor timer irq
- - description: hypervisor virtual timer irq
+ - description: EL1 secure physical timer irq, if EL3 is implemented
+ - description: EL1 non-secure physical timer irq
+ - description: EL1 virtual timer irq
+ - description: EL2 physical timer irq, if EL2 is implemented
+ - description: EL2 virtual timer irq, if FEAT_VHE is implemented
interrupt-names:
oneOf:
--
2.47.3
^ permalink raw reply related
* [PATCH v3 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
When running with at EL2 with VHE enabled, the architecture provides
two EL2 timer/counters, dubbed physical and virtual. Apart from their
names, they are strictly identical.
However, they don't get virtualised the same way, specially when
it comes to adding arbitrary offsets to the timers. When running as
a guest, the host CNTVOFF_EL2 does apply to the guest's view of
CNTHV*_El2. This is not true for CNTPOFF_EL2 and CNTHP*_EL2, as
the architecture is broken past the first level of virtualisation
(it lacks some essential mechanisms to be usable, despite what
the ARM ARM pretends).
This means that when running as a L2 guest hypervisor, using the
physical timer results in traps to L0, which are then forwarded to
L1 in order to emulate the offset, leading to even worse performance
due to massive trap amplification (the combination of register and
ERET trapping is absolutely lethal).
Switch the arch timer code to using the virtual timer when running
in VHE by default, only using the physical timer if the interrupt
is not correctly described in the firmware tables (which seems
to be an unfortunately common case). This comes as no impact on
bare-metal, and slightly improves the situation in the virtualised
case.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
drivers/clocksource/arm_arch_timer.c | 55 +++++++++++++++++-----------
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 90aeff44a2764..4adf756423de9 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -688,6 +688,7 @@ static void __arch_timer_setup(struct clock_event_device *clk)
clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
switch (arch_timer_uses_ppi) {
case ARCH_TIMER_VIRT_PPI:
+ case ARCH_TIMER_HYP_VIRT_PPI:
clk->set_state_shutdown = arch_timer_shutdown_virt;
clk->set_state_oneshot_stopped = arch_timer_shutdown_virt;
sne = erratum_handler(set_next_event_virt);
@@ -879,7 +880,7 @@ static void __init arch_timer_banner(void)
pr_info("cp15 timer running at %lu.%02luMHz (%s).\n",
(unsigned long)arch_timer_rate / 1000000,
(unsigned long)(arch_timer_rate / 10000) % 100,
- (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) ? "virt" : "phys");
+ arch_timer_ppi_names[arch_timer_uses_ppi]);
}
u32 arch_timer_get_rate(void)
@@ -912,7 +913,8 @@ static void __init arch_counter_register(void)
int width;
if ((IS_ENABLED(CONFIG_ARM64) && !is_hyp_mode_available()) ||
- arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) {
+ arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI ||
+ arch_timer_uses_ppi == ARCH_TIMER_HYP_VIRT_PPI) {
if (arch_timer_counter_has_wa()) {
rd = arch_counter_get_cntvct_stable;
scr = raw_counter_get_cntvct_stable;
@@ -1023,6 +1025,7 @@ static int __init arch_timer_register(void)
ppi = arch_timer_ppi[arch_timer_uses_ppi];
switch (arch_timer_uses_ppi) {
case ARCH_TIMER_VIRT_PPI:
+ case ARCH_TIMER_HYP_VIRT_PPI:
err = request_percpu_irq(ppi, arch_timer_handler_virt,
"arch_timer", arch_timer_evt);
break;
@@ -1090,25 +1093,34 @@ static int __init arch_timer_common_init(void)
/**
* arch_timer_select_ppi() - Select suitable PPI for the current system.
*
- * If HYP mode is available, we know that the physical timer
- * has been configured to be accessible from PL1. Use it, so
- * that a guest can use the virtual timer instead.
+ * On AArch32, if HYP mode is available, we know that the physical
+ * timer has been configured to be accessible from PL1. Use it, so
+ * that a guest can use the virtual timer instead (though KVM host
+ * support has long been removed).
*
- * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
- * accesses to CNTP_*_EL1 registers are silently redirected to
- * their CNTHP_*_EL2 counterparts, and use a different PPI
- * number.
+ * On ARMv8.1 with FEAT_VHE, the kernel runs in EL2. Accesses to
+ * CNTV_*_EL1 registers are silently redirected to their CNTHV_*_EL2
+ * counterparts, and the timer uses a different PPI number. Similar
+ * thing happen when using the EL2 physical timer. Note that a bunch
+ * of DTs out there omit the virtual EL2 timer, so fallback gracefully
+ * on the physical timer.
+ *
+ * Without VHE, if no interrupt provided for virtual timer, we'll have
+ * to stick to the physical timer. It'd better be accessible...
*
- * If no interrupt provided for virtual timer, we'll have to
- * stick to the physical timer. It'd better be accessible...
* For arm64 we never use the secure interrupt.
*
* Return: a suitable PPI type for the current system.
*/
static enum arch_timer_ppi_nr __init arch_timer_select_ppi(void)
{
- if (is_kernel_in_hyp_mode())
+ if (is_kernel_in_hyp_mode()) {
+ if (arch_timer_ppi[ARCH_TIMER_HYP_VIRT_PPI])
+ return ARCH_TIMER_HYP_VIRT_PPI;
+
+ pr_warn_once(FW_BUG "VHE-capable CPU without EL2 virtual timer interrupt\n");
return ARCH_TIMER_HYP_PPI;
+ }
if (!is_hyp_mode_available() && arch_timer_ppi[ARCH_TIMER_VIRT_PPI])
return ARCH_TIMER_VIRT_PPI;
@@ -1200,14 +1212,9 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
if (ret)
return ret;
- arch_timer_ppi[ARCH_TIMER_PHYS_NONSECURE_PPI] =
- acpi_gtdt_map_ppi(ARCH_TIMER_PHYS_NONSECURE_PPI);
-
- arch_timer_ppi[ARCH_TIMER_VIRT_PPI] =
- acpi_gtdt_map_ppi(ARCH_TIMER_VIRT_PPI);
-
- arch_timer_ppi[ARCH_TIMER_HYP_PPI] =
- acpi_gtdt_map_ppi(ARCH_TIMER_HYP_PPI);
+ /* The GTDT parser can't be bothered with the secure timer */
+ for (int i = ARCH_TIMER_PHYS_NONSECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++)
+ arch_timer_ppi[i] = acpi_gtdt_map_ppi(i);
arch_timer_populate_kvm_info();
@@ -1253,10 +1260,14 @@ int kvm_arch_ptp_get_crosststamp(u64 *cycle, struct timespec64 *ts,
if (!IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY))
return -EOPNOTSUPP;
- if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI)
+ switch (arch_timer_uses_ppi) {
+ case ARCH_TIMER_VIRT_PPI:
+ case ARCH_TIMER_HYP_VIRT_PPI:
ptp_counter = KVM_PTP_VIRT_COUNTER;
- else
+ break;
+ default:
ptp_counter = KVM_PTP_PHYS_COUNTER;
+ }
arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID,
ptp_counter, &hvc_res);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Mark Brown @ 2026-05-23 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <87h5nya4wl.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Sat, May 23, 2026 at 09:47:38AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > The reasoning for the current behaviour is not specifically articulated, my
> > best guess is that it is intended to ensure that the guest can not see an
> > effective VL greater than the maximum that has been configured. This can
> > instead be achieved by configuring ZCR_EL2 when loading guest state:
> > - When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
> > guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
> This is not EL0 or EL1. This is when in a nested context (i.e. running
> a L2 guest), as EL0 exists for L1 as well.
Sorry, this was intended to be specifically for a L2 guest but didn't
actually say that. I originally had more verbosity in the commit log
that I cleaned up too much, making things unclear. I will clarify.
> > Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> > written are sanitised based on this.
> Only for the direct writes to ZCR_EL2, as they are trapping. I don't
> see any sanitisation for writes using the ZCR_EL1 accessor, which is
> the common case. This needs fixing at the same time.
OK, I'll convert ZCR_EL2 to a sanitised register. As I mentioned I was
a bit confused about why the existing code is the way it is and so
followed it in only managing the direct writes. I figured it was
considered OK to rely on the hardware for the RES0 and WI behaviour for
untrapped access.
> > - if (is_nested_ctxt(vcpu)) - zcr_el2
> > = __vcpu_sys_reg(vcpu, ZCR_EL2); - else -
> > zcr_el2 = vcpu_sve_max_vq(vcpu) - 1; + if
> > (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu)) +
> > zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
> Why the change in the condition guarding this? Given the definition of
> is_nested_ctxt(), this seems unnecessary.
You're right, this change is not needed. I had misremembered what
is_nested_ctxt() was checking.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 05/17] arm64: dts: allwinner: Add EL2 virtual timer interrupt
From: Marc Zyngier @ 2026-05-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel, linux-acpi, linux-kernel, devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek,
Andre Przywara
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
The ARMv8.2 based CPUs used in the A523 SoC (and derivatives)
are missing the EL2 virtual timer interrupt. Add it.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index 5afa8d92acbfb..d3c47966e8fc8 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -101,7 +101,8 @@ timer {
interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
<GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
<GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 12 IRQ_TYPE_LEVEL_HIGH>;
};
soc {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] pinctrl: imx1: fix device_node leak in dt_is_flat_functions()
From: Frank Li @ 2026-05-23 14:34 UTC (permalink / raw)
To: Felix Gu
Cc: Dong Aisheng, Fabio Estevam, Jacky Bai, Pengutronix Kernel Team,
NXP S32 Linux Team, Linus Walleij, Sascha Hauer, linux-gpio, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260523-pinctrl-imx-v1-1-73b7cb731351@gmail.com>
On Sat, May 23, 2026 at 06:27:05PM +0800, Felix Gu wrote:
> for_each_child_of_node() holds a reference on the iterator node that
> must be released on early return. imx1_pinctrl_dt_is_flat_functions()
> has two early return paths inside the loop that skip this cleanup.
>
> Replace both loops with the scoped variant so that the reference is
> automatically dropped when the iterator goes out of scope.
>
> Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
Thank you for fix it.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pinctrl/freescale/pinctrl-imx1-core.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
> index b7bd4ef9c0db..4a6bdaefa42f 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
> @@ -547,14 +547,11 @@ static int imx1_pinctrl_parse_functions(struct device_node *np,
> */
> static bool imx1_pinctrl_dt_is_flat_functions(struct device_node *np)
> {
> - struct device_node *function_np;
> - struct device_node *pinctrl_np;
> -
> - for_each_child_of_node(np, function_np) {
> + for_each_child_of_node_scoped(np, function_np) {
> if (of_property_present(function_np, "fsl,pins"))
> return true;
>
> - for_each_child_of_node(function_np, pinctrl_np) {
> + for_each_child_of_node_scoped(function_np, pinctrl_np) {
> if (of_property_present(pinctrl_np, "fsl,pins"))
> return false;
> }
>
> ---
> base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
> change-id: 20260523-pinctrl-imx-b198f8391abf
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox