* [PATCH v6 00/19] drm/atomic: Rework initial state allocation
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
Hi,
This series started from my work on the hardware state readout[1], and
more specifically a discussion with Thomas[2].
This series expands the work that has been merged recently to make
drm_private_obj and drm_private_state allocation a bit more consistent
and ended up creating a new atomic_create_state callback to allocate a
new state with no side effect.
The first patches document the existing behaviour and fix a few
cleanups and typos.
Then, __drm_*_state_reset() helpers are renamed to
__drm_*_state_init() to clarify that they initialize rather than
reset state, and we add the new atomic_create_state callback to
every other DRM object (planes, CRTCs, connectors, colorops).
Next, we leverage those new callbacks to create a new helper,
drm_mode_config_create_initial_state(), to create the initial state
for all the objects of a driver, and update the driver skeleton to
recommend it.
Finally, we convert the tidss driver and the bridge_connector to the
new pattern.
This was tested on a TI SK-AM62, with the tidss driver.
Let me know what you think,
Maxime
1: https://lore.kernel.org/dri-devel/20250902-drm-state-readout-v1-0-14ad5315da3f@kernel.org/
2: https://lore.kernel.org/dri-devel/5920ffe5-b6b1-484b-b320-332b9eb9db82@suse.de/
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Changes in v6:
- Reword the docs according to Thomas review
- Link to v5: https://lore.kernel.org/r/20260519-drm-mode-config-init-v5-0-388b03321e38@kernel.org
Changes in v5:
- Address sashiko reviews
- Improve the docs
- Fix drmm_connector_hdmi_init
- Drop drm/tidss: Switch to drm_mode_config_create_initial_state since
not all possible bridges would have been converted to create_state
- Link to v4: https://lore.kernel.org/r/20260512-drm-mode-config-init-v4-0-591dfdcc1bf9@kernel.org
Changes in v4:
- Rebased on current drm-misc-next
- Update drm_atomic_state to drm_atomic_commit
- Various doc impromvements
- Don't call drm_crtc_vblank_reset in create_state
- Prevent mem leak if states already have a state when
drm_mode_config_reset or _create_initial_state are called
- Link to v3: https://lore.kernel.org/r/20260424-drm-mode-config-init-v3-0-8b68d9db0d8b@kernel.org
Changes in v3:
- Reintroduce state documentation that was dropped by accident
- Change name to drm_mode_config_create_initial_state()
- Don't call drm_mode_config_create_initial_state() in drm_dev_register
anymore
- Drop __drm_atomic_helper_*_create_state
- Improve documentation and commit messages where necessary
- Collected tags
- Link to v2: https://lore.kernel.org/r/20260320-drm-mode-config-init-v2-0-c63f1134e76c@kernel.org
Changes in v2:
- Change the _state_reset function names to _state_init
- Change the colorop too
- Various doc improvements
- Link to v1: https://lore.kernel.org/r/20260310-drm-mode-config-init-v1-0-de7397c8e1cf@kernel.org
---
Maxime Ripard (19):
drm/atomic: Document atomic commit lifetime
drm/colorop: Fix typos in the doc
drm/atomic: Drop drm_private_obj.state assignment from create_state
drm/atomic: Expand atomic_create_state expectations for drm_private_obj
drm/mode-config: Document drm_private_obj exclusion from drm_mode_config_reset()
drm/colorop: Rename __drm_colorop_state_reset()
drm/colorop: Create drm_atomic_helper_colorop_create_state()
drm/atomic-state-helper: Fix __drm_atomic_helper_plane_reset() doc typo
drm/atomic-state-helper: Rename __drm_atomic_helper_plane_state_reset()
drm/plane: Add new atomic_create_state callback
drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
drm/crtc: Add new atomic_create_state callback
drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
drm/connector: Add new atomic_create_state callback
drm/mode-config: Create drm_mode_config_create_initial_state()
drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
drm/tidss: Convert to atomic_create_state
drm/bridge_connector: Convert to atomic_create_state
Documentation/gpu/drm-kms.rst | 6 +
drivers/gpu/drm/display/drm_bridge_connector.c | 17 +-
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 15 +-
drivers/gpu/drm/drm_atomic.c | 80 +++++++++
drivers/gpu/drm/drm_atomic_state_helper.c | 114 ++++++++++---
drivers/gpu/drm/drm_colorop.c | 41 ++++-
drivers/gpu/drm/drm_connector.c | 10 +-
drivers/gpu/drm/drm_drv.c | 4 +-
drivers/gpu/drm/drm_mode_config.c | 189 ++++++++++++++++++++-
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
drivers/gpu/drm/i915/display/intel_plane.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
drivers/gpu/drm/tidss/tidss_crtc.c | 17 +-
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
include/drm/display/drm_hdmi_state_helper.h | 4 +-
include/drm/drm_atomic.h | 5 +-
include/drm/drm_atomic_state_helper.h | 12 +-
include/drm/drm_colorop.h | 2 +
include/drm/drm_connector.h | 16 ++
include/drm/drm_crtc.h | 16 ++
include/drm/drm_mode_config.h | 1 +
include/drm/drm_plane.h | 16 ++
24 files changed, 509 insertions(+), 68 deletions(-)
---
base-commit: 69c95e4c529297c25503e60acba757fba24fdc95
change-id: 20260310-drm-mode-config-init-1e1f52b745d0
Best regards,
--
Maxime Ripard <mripard@kernel.org>
^ permalink raw reply
* Re: [PATCH 12/18] arm64: fpsimd: Move fpsimd save/restore inline
From: Mark Brown @ 2026-05-26 16:44 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-13-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
On Thu, May 21, 2026 at 02:25:50PM +0100, Mark Rutland wrote:
> Note that I've used the SVE sequence for restoring FPCR, which uses an
> unconditional write to FPCR. The plain FPSIMD assembly sequence used a
> conditional write to FPCR since 2014 in commit:
> 5959e25729a5 ("arm64: fpsimd: avoid restoring fpcr if the contents haven't change")
> ... but this was not followed for the SVE assembly implemented in 2017
> in commit:
> 1fc5dce78ad1 ("arm64/sve: Low-level SVE architectural state manipulation functions")
> ... so I've assumed that this doesn't actually matter in practice, and
> I've erred in favour of the simpler sequence.
As I said on the earlier patch I'm a bit nervous about assuming this
doesn't matter for anyone without verifying (though I wouldn't be
surprised if that turned out to be the case) but that's internal to that
patch and this is obviously a great improvement so:
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v6 2/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-05-26 16:43 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260526164330.23878-1-gakula@marvell.com>
The CN20K DRAM Subsystem exposes eight programmable
performance counters and two fixed counters for DDR
read and write traffic. Software selects events for
the programmable counters from traffic at the DDR PHY
interface, the CHI interconnect, or inside the DDR controller.
Add CN20K register offsets, event maps, and sysfs attributes;
match the device via OF (marvell,cn20k-ddr-pmu) and ACPI (MRVL000B).
Represent the SoC variant in platform data with bit flags so
CN20K can reuse the CN10K PMU code path where appropriate.
Changes in v6:
- perf: Route CN20K ZQ via sysfs IDs 62/63 and CFG1; bitmap uses
(eventid - 42) for CFG1 bits; reject those IDs on non-CN20K silicon.
- perf: Disambiguate CN20K events 58-61 from Odyssey DFI; shared numeric
IDs use CN20K branch plus fallthrough to DFI path.
- perf: Extend counter enable so CN20K gets Odyssey manual-mode and
start (IS_CN20K OR IS_ODY in cn10k_ddr_perf_counter_enable).
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
drivers/perf/marvell_cn10k_ddr_pmu.c | 196 +++++++++++++++++++++++++--
1 file changed, 182 insertions(+), 14 deletions(-)
diff --git a/drivers/perf/marvell_cn10k_ddr_pmu.c b/drivers/perf/marvell_cn10k_ddr_pmu.c
index 72ac17efd846..4d8bdd9233bd 100644
--- a/drivers/perf/marvell_cn10k_ddr_pmu.c
+++ b/drivers/perf/marvell_cn10k_ddr_pmu.c
@@ -13,31 +13,43 @@
#include <linux/hrtimer.h>
#include <linux/acpi.h>
#include <linux/platform_device.h>
+#include <linux/bits.h>
+
+/* SoC variant flags for struct ddr_pmu_platform_data (mutually exclusive in pdata) */
+#define IS_CN10K BIT(0)
+#define IS_ODY BIT(1)
+#define IS_CN20K BIT(2)
/* Performance Counters Operating Mode Control Registers */
#define CN10K_DDRC_PERF_CNT_OP_MODE_CTRL 0x8020
#define ODY_DDRC_PERF_CNT_OP_MODE_CTRL 0x20020
+#define CN20K_DDRC_PERF_CNT_OP_MODE_CTRL 0x20000
#define OP_MODE_CTRL_VAL_MANUAL 0x1
/* Performance Counters Start Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_START_OP_CTRL 0x8028
#define ODY_DDRC_PERF_CNT_START_OP_CTRL 0x200A0
+#define CN20K_DDRC_PERF_CNT_START_OP_CTRL 0x20080
#define START_OP_CTRL_VAL_START 0x1ULL
#define START_OP_CTRL_VAL_ACTIVE 0x2
/* Performance Counters End Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_END_OP_CTRL 0x8030
#define ODY_DDRC_PERF_CNT_END_OP_CTRL 0x200E0
+#define CN20K_DDRC_PERF_CNT_END_OP_CTRL 0x200C0
#define END_OP_CTRL_VAL_END 0x1ULL
/* Performance Counters End Status Registers */
#define CN10K_DDRC_PERF_CNT_END_STATUS 0x8038
#define ODY_DDRC_PERF_CNT_END_STATUS 0x20120
+#define CN20K_DDRC_PERF_CNT_END_STATUS 0x20100
#define END_STATUS_VAL_END_TIMER_MODE_END 0x1
/* Performance Counters Configuration Registers */
#define CN10K_DDRC_PERF_CFG_BASE 0x8040
#define ODY_DDRC_PERF_CFG_BASE 0x20160
+#define CN20K_DDRC_PERF_CFG_BASE 0x20140
+#define CN20K_DDRC_PERF_CFG1_BASE 0x20180
/* 8 Generic event counter + 2 fixed event counters */
#define DDRC_PERF_NUM_GEN_COUNTERS 8
@@ -61,6 +73,24 @@
* DO NOT change these event-id numbers, they are used to
* program event bitmap in h/w.
*/
+
+/* CN20K specific events */
+#define EVENT_PERF_OP_IS_RD16 61
+#define EVENT_PERF_OP_IS_RD32 60
+#define EVENT_PERF_OP_IS_WR16 59
+#define EVENT_PERF_OP_IS_WR32 58
+#define EVENT_OP_IS_ENTER_DSM 44
+#define EVENT_OP_IS_RFM 43
+
+
+#define EVENT_CN20K_OP_IS_ZQLATCH 62
+#define EVENT_CN20K_OP_IS_ZQSTART 63
+#define EVENT_CN20K_OP_IS_TCR_MRR 50
+#define EVENT_CN20K_OP_IS_DQSOSC_MRR 49
+#define EVENT_CN20K_OP_IS_DQSOSC_MPC 48
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR 47
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD 46
+
#define EVENT_DFI_CMD_IS_RETRY 61
#define EVENT_RD_UC_ECC_ERROR 60
#define EVENT_RD_CRC_ERROR 59
@@ -87,6 +117,9 @@
#define EVENT_OP_IS_SPEC_REF 41
#define EVENT_OP_IS_CRIT_REF 40
#define EVENT_OP_IS_REFRESH 39
+#define EVENT_OP_IS_CAS_WCK_SUS 38
+#define EVENT_OP_IS_CAS_WS_OFF 37
+#define EVENT_OP_IS_CAS_WS 36
#define EVENT_OP_IS_ENTER_MPSM 35
#define EVENT_OP_IS_ENTER_POWERDOWN 31
#define EVENT_OP_IS_ENTER_SELFREF 27
@@ -183,8 +216,8 @@ struct ddr_pmu_platform_data {
u64 cnt_freerun_clr;
u64 cnt_value_wr_op;
u64 cnt_value_rd_op;
- bool is_cn10k;
- bool is_ody;
+ u64 cfg1_base;
+ unsigned int silicon_flags; /* IS_CN10K, IS_ODY, or IS_CN20K */
};
static ssize_t cn10k_ddr_pmu_event_show(struct device *dev,
@@ -336,6 +369,80 @@ static struct attribute *odyssey_ddr_perf_events_attrs[] = {
NULL
};
+static struct attribute *cn20k_ddr_perf_events_attrs[] = {
+ /* Programmable */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_or_wr_access, EVENT_HIF_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_wr_access, EVENT_HIF_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_access, EVENT_HIF_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rmw_access, EVENT_HIF_RMW),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_pri_rdaccess, EVENT_HIF_HI_PRI_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rd_bypass_access, EVENT_READ_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_act_bypass_access, EVENT_ACT_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_wr_data_access,
+ EVENT_DFI_WR_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_rd_data_access,
+ EVENT_DFI_RD_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hpri_sched_rd_crit_access,
+ EVENT_HPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_lpri_sched_rd_crit_access,
+ EVENT_LPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_wr_trxn_crit_access,
+ EVENT_WR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_active_access, EVENT_OP_IS_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_or_wr_access,
+ EVENT_OP_IS_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_active_access,
+ EVENT_OP_IS_RD_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_read, EVENT_OP_IS_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_write, EVENT_OP_IS_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_mwr, EVENT_OP_IS_MWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge, EVENT_OP_IS_PRECHARGE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_rdwr,
+ EVENT_PRECHARGE_FOR_RDWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_other,
+ EVENT_PRECHARGE_FOR_OTHER),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rdwr_transitions, EVENT_RDWR_TRANSITIONS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write_combine, EVENT_WRITE_COMBINE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_war_hazard, EVENT_WAR_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_raw_hazard, EVENT_RAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_waw_hazard, EVENT_WAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_selfref, EVENT_OP_IS_ENTER_SELFREF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_powerdown,
+ EVENT_OP_IS_ENTER_POWERDOWN),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws, EVENT_OP_IS_CAS_WS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws_off, EVENT_OP_IS_CAS_WS_OFF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_wck_sus, EVENT_OP_IS_CAS_WCK_SUS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_refresh, EVENT_OP_IS_REFRESH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_crit_ref, EVENT_OP_IS_CRIT_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_spec_ref, EVENT_OP_IS_SPEC_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_load_mode, EVENT_OP_IS_LOAD_MODE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rfm, EVENT_OP_IS_RFM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_dsm, EVENT_OP_IS_ENTER_DSM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_cycles, EVENT_DFI_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_rd,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_wr,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mpc, EVENT_CN20K_OP_IS_DQSOSC_MPC),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mrr, EVENT_CN20K_OP_IS_DQSOSC_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_tcr_mrr, EVENT_CN20K_OP_IS_TCR_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqstart, EVENT_CN20K_OP_IS_ZQSTART),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqlatch, EVENT_CN20K_OP_IS_ZQLATCH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read16, EVENT_PERF_OP_IS_RD16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read32, EVENT_PERF_OP_IS_RD32),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write16, EVENT_PERF_OP_IS_WR16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write32, EVENT_PERF_OP_IS_WR32),
+ /* Free run event counters */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_reads, EVENT_DDR_READS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_writes, EVENT_DDR_WRITES),
+ NULL
+};
+
+static struct attribute_group cn20k_ddr_perf_events_attr_group = {
+ .name = "events",
+ .attrs = cn20k_ddr_perf_events_attrs,
+};
+
static struct attribute_group odyssey_ddr_perf_events_attr_group = {
.name = "events",
.attrs = odyssey_ddr_perf_events_attrs,
@@ -393,6 +500,13 @@ static const struct attribute_group *odyssey_attr_groups[] = {
NULL
};
+static const struct attribute_group *cn20k_attr_groups[] = {
+ &cn20k_ddr_perf_events_attr_group,
+ &cn10k_ddr_perf_format_attr_group,
+ &cn10k_ddr_perf_cpumask_attr_group,
+ NULL
+};
+
/* Default poll timeout is 100 sec, which is very sufficient for
* 48 bit counter incremented max at 5.6 GT/s, which may take many
* hours to overflow.
@@ -411,8 +525,22 @@ static int ddr_perf_get_event_bitmap(int eventid, u64 *event_bitmap,
int err = 0;
switch (eventid) {
+ case EVENT_PERF_OP_IS_WR32 ... EVENT_PERF_OP_IS_RD16:
+ if (ddr_pmu->p_data->silicon_flags & IS_CN20K) {
+ *event_bitmap = (1ULL << (eventid - 1));
+ break;
+ }
+ /* Same numeric IDs as Odyssey DFI events 58..61 */
+ fallthrough;
+ case EVENT_CN20K_OP_IS_ZQLATCH ... EVENT_CN20K_OP_IS_ZQSTART:
+ if (ddr_pmu->p_data->silicon_flags & IS_CN20K) {
+ *event_bitmap = (1ULL << (eventid - 42));
+ break;
+ }
+ err = -EINVAL;
+ break;
case EVENT_DFI_PARITY_POISON ...EVENT_DFI_CMD_IS_RETRY:
- if (!ddr_pmu->p_data->is_ody) {
+ if (!(ddr_pmu->p_data->silicon_flags & IS_ODY)) {
err = -EINVAL;
break;
}
@@ -524,9 +652,9 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
int counter, bool enable)
{
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
u64 ctrl_reg = pmu->p_data->cnt_op_mode_ctrl;
const struct ddr_pmu_ops *ops = pmu->ops;
- bool is_ody = pmu->p_data->is_ody;
u32 reg;
u64 val;
@@ -546,7 +674,7 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
writeq_relaxed(val, pmu->base + reg);
- if (is_ody) {
+ if ((silicon_flags & IS_ODY) || (silicon_flags & IS_CN20K)) {
if (enable) {
/*
* Setup the PMU counter to work in
@@ -621,6 +749,7 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
{
struct cn10k_ddr_pmu *pmu = to_cn10k_ddr_pmu(event->pmu);
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
const struct ddr_pmu_ops *ops = pmu->ops;
struct hw_perf_event *hwc = &event->hw;
u8 config = event->attr.config;
@@ -642,10 +771,15 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
if (counter < DDRC_PERF_NUM_GEN_COUNTERS) {
/* Generic counters, configure event id */
reg_offset = DDRC_PERF_CFG(p_data->cfg_base, counter);
+
ret = ddr_perf_get_event_bitmap(config, &val, pmu);
if (ret)
return ret;
-
+ if (silicon_flags & IS_CN20K) {
+ if (config == EVENT_CN20K_OP_IS_ZQSTART ||
+ config == EVENT_CN20K_OP_IS_ZQLATCH)
+ reg_offset = DDRC_PERF_CFG(p_data->cfg1_base, counter);
+ }
writeq_relaxed(val, pmu->base + reg_offset);
} else {
/* fixed event counter, clear counter value */
@@ -952,7 +1086,25 @@ static const struct ddr_pmu_platform_data cn10k_ddr_pmu_pdata = {
.cnt_freerun_clr = 0,
.cnt_value_wr_op = CN10K_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = CN10K_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_cn10k = TRUE,
+ .silicon_flags = IS_CN10K,
+};
+
+static const struct ddr_pmu_platform_data cn20k_ddr_pmu_pdata = {
+ .counter_overflow_val = 0,
+ .counter_max_val = GENMASK_ULL(63, 0),
+ .cnt_base = ODY_DDRC_PERF_CNT_VALUE_BASE,
+ .cfg_base = CN20K_DDRC_PERF_CFG_BASE,
+ .cfg1_base = CN20K_DDRC_PERF_CFG1_BASE,
+ .cnt_op_mode_ctrl = CN20K_DDRC_PERF_CNT_OP_MODE_CTRL,
+ .cnt_start_op_ctrl = CN20K_DDRC_PERF_CNT_START_OP_CTRL,
+ .cnt_end_op_ctrl = CN20K_DDRC_PERF_CNT_END_OP_CTRL,
+ .cnt_end_status = CN20K_DDRC_PERF_CNT_END_STATUS,
+ .cnt_freerun_en = 0,
+ .cnt_freerun_ctrl = ODY_DDRC_PERF_CNT_FREERUN_CTRL,
+ .cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
+ .cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
+ .cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
+ .silicon_flags = IS_CN20K,
};
#endif
@@ -979,7 +1131,7 @@ static const struct ddr_pmu_platform_data odyssey_ddr_pmu_pdata = {
.cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
.cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_ody = TRUE,
+ .silicon_flags = IS_ODY,
};
#endif
@@ -989,8 +1141,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
struct cn10k_ddr_pmu *ddr_pmu;
struct resource *res;
void __iomem *base;
- bool is_cn10k;
- bool is_ody;
+ unsigned int silicon_flags;
char *name;
int ret;
@@ -1014,10 +1165,9 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
ddr_pmu->base = base;
ddr_pmu->p_data = dev_data;
- is_cn10k = ddr_pmu->p_data->is_cn10k;
- is_ody = ddr_pmu->p_data->is_ody;
+ silicon_flags = ddr_pmu->p_data->silicon_flags;
- if (is_cn10k) {
+ if (silicon_flags & IS_CN10K) {
ddr_pmu->ops = &ddr_pmu_ops;
/* Setup the PMU counter to work in manual mode */
writeq_relaxed(OP_MODE_CTRL_VAL_MANUAL, ddr_pmu->base +
@@ -1039,7 +1189,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
ddr_pmu->ops = &ddr_pmu_ody_ops;
ddr_pmu->pmu = (struct pmu) {
@@ -1056,6 +1206,22 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
+ if (silicon_flags & IS_CN20K) {
+ ddr_pmu->ops = &ddr_pmu_ody_ops;
+
+ ddr_pmu->pmu = (struct pmu) {
+ .module = THIS_MODULE,
+ .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = cn20k_attr_groups,
+ .event_init = cn10k_ddr_perf_event_init,
+ .add = cn10k_ddr_perf_event_add,
+ .del = cn10k_ddr_perf_event_del,
+ .start = cn10k_ddr_perf_event_start,
+ .stop = cn10k_ddr_perf_event_stop,
+ .read = cn10k_ddr_perf_event_update,
+ };
+ }
/* Choose this cpu to collect perf data */
ddr_pmu->cpu = raw_smp_processor_id();
@@ -1098,6 +1264,7 @@ static void cn10k_ddr_perf_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id cn10k_ddr_pmu_of_match[] = {
{ .compatible = "marvell,cn10k-ddr-pmu", .data = &cn10k_ddr_pmu_pdata },
+ { .compatible = "marvell,cn20k-ddr-pmu", .data = &cn20k_ddr_pmu_pdata },
{ },
};
MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
@@ -1107,6 +1274,7 @@ MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
static const struct acpi_device_id cn10k_ddr_pmu_acpi_match[] = {
{"MRVL000A", (kernel_ulong_t)&cn10k_ddr_pmu_pdata },
{"MRVL000C", (kernel_ulong_t)&odyssey_ddr_pmu_pdata},
+ {"MRVL000B", (kernel_ulong_t)&cn20k_ddr_pmu_pdata},
{},
};
MODULE_DEVICE_TABLE(acpi, cn10k_ddr_pmu_acpi_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: perf: marvell: Extend CN10K DDR PMU binding for CN20K
From: Geetha sowjanya @ 2026-05-26 16:43 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260526164330.23878-1-gakula@marvell.com>
Marvell CN20K SoCs integrate a DDR Performance Monitoring Unit (PMU)
associated with the DDR controller. The block provides hardware counters
to monitor DDR traffic and performance events and is accessed via a
dedicated MMIO region.
The CN20K DDR PMU is functionally equivalent to the CN10K DDR PMU, with
minor register offset differences.
Changes in v6:
- dt-bindings: Document CN20K in the existing marvell-cn10k-ddr.yaml;
add maintainer, description, compatible enum entry, and a CN20K example
with unit-address aligned to reg.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
.../bindings/perf/marvell-cn10k-ddr.yaml | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml
index a18dd0a8c43a..79fae9fdb6f1 100644
--- a/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml
@@ -4,16 +4,22 @@
$id: http://devicetree.org/schemas/perf/marvell-cn10k-ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Marvell CN10K DDR performance monitor
+title: Marvell CN10K / CN20K DDR performance monitor
+
+description:
+ Performance Monitoring Unit (PMU) for the DDR controller on Marvell
+ CN10K and CN20K SoCs. The block is accessed via a dedicated MMIO region.
maintainers:
- Bharat Bhushan <bbhushan2@marvell.com>
+ - Geetha sowjanya <gakula@marvell.com>
properties:
compatible:
items:
- enum:
- marvell,cn10k-ddr-pmu
+ - marvell,cn20k-ddr-pmu
reg:
maxItems: 1
@@ -35,3 +41,13 @@ examples:
reg = <0x87e1 0xc0000000 0x0 0x10000>;
};
};
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pmu@c20000000000 {
+ compatible = "marvell,cn20k-ddr-pmu";
+ reg = <0xc200 0x00000000 0x0 0x100000>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v6 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-05-26 16:43 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the DDR Performance Monitoring Unit (PMU)
present in Marvell CN20K SoCs.
The DDR PMU is part of the DRAM Subsystem (DSS) and provides hardware
counters to monitor DDR traffic and performance events. The block
implements eight programmable counters and two fixed-function counters
tracking DDR read and write activity, and is accessed via a dedicated
MMIO region.
CN20K is the successor to CN10K, and the DDR PMU hardware is functionally
equivalent to the CN10K implementation, with only minor differences in
register offsets and event mappings. To allow software to distinguish
between the two silicon variants, this series introduces a specific
"marvell,cn20k-ddr-pmu" compatible and extends the existing
marvell_cn10k_ddr_pmu driver to handle CN20K via variant-specific data.
Changes in v6:
- dt-bindings: Document CN20K in the existing marvell-cn10k-ddr.yaml;
add maintainer, description, compatible enum entry, and a CN20K example
with unit-address aligned to reg.
- perf: Route CN20K ZQ events via dedicated sysfs IDs (62/63) and CFG1
programming; use (eventid - 42) for CFG1 bit positions and reject those IDs
on non-CN20K silicon.
- perf: Disambiguate CN20K perf width events (58-61) from Odyssey DFI events
at the same numeric IDs using an early CN20K branch and fallthrough into the
existing DFI + programmable-event path on Odyssey.
- perf: Run CN20K programmable counters through the same manual-mode / start
sequence as Odyssey.
Changes in v4:
- Fixed document file name.
Changes in v3:
- Expanded cover letter and commit message to better describe the DDR PMU
hardware and its relationship to CN10K
- Fixed the file name.
Changes in v2:
- Fixed YAML syntax error triggered by a tab character in the examples
section, which caused dt_binding_check to fail.
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Geetha sowjanya (2):
dt-bindings: perf: marvell: Extend CN10K DDR PMU binding for CN20K
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn10k-ddr.yaml | 18 +-
drivers/perf/marvell_cn10k_ddr_pmu.c | 197 ++++++++++++++++--
2 files changed, 200 insertions(+), 15 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Conor Dooley @ 2026-05-26 16:39 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <0c6299ce-29a6-4443-9877-498d65c8881b@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 7293 bytes --]
On Tue, May 26, 2026 at 07:27:55PM +0800, Damon Ding wrote:
> Hi Conor,
>
> On 5/26/2026 8:54 AM, Damon Ding wrote:
> > Hi Conor,
> >
> > On 5/26/2026 12:54 AM, Conor Dooley wrote:
> > > On Mon, May 25, 2026 at 08:53:22PM +0800, Damon Ding wrote:
> > > > RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> > > > registers and enable the video datapath.
> > > >
> > > > Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> > > > phandle reference, which allowed the eDP to work without explicitly
> > > > managing the hclk_vo1 clock. However, this is not safe or explicit.
> > > >
> > > > To make the clock dependency explicit, enforce per-SoC clock-names
> > > > requirements:
> > > > - RK3288: 2 clocks (dp, pclk)
> > > > - RK3399: 3 clocks (dp, pclk, grf)
> > > > - RK3588: 3 clocks (dp, pclk, hclk)
> > > >
> > > > Do not reuse the 'grf' clock name for RK3588 because it represents
> > > > a different clock with distinct control logic:
> > > > - The 'grf' clock is only for GRF register access and is toggled
> > > > dynamically during register access.
> > > > - The 'hclk' clock controls both GRF access and video datapath
> > > > gating, and must remain enabled during probe.
> > > >
> > > > Fixes: f855146263b1 ("dt-bindings: display: rockchip:
> > > > analogix-dp: Add support for RK3588")
> > > > Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> > > >
> > > > ---
> > > >
> > > > Changes in v4:
> > > > - Modify the commit msg.
> > > >
> > > > Changes in v5:
> > > > - Enforce the correct third clock name on a per-compatible basis.
> > > > - Modify the commit msg simultaneously.
> > > >
> > > > Changes in v6:
> > > > - Expand more detail commit msg about using hclk instead of grf clock.
> > > >
> > > > Changes in v7:
> > > > - List all valid clock names at the top level, and constrain the clock
> > > > count for each platform with minItems/maxItems in allOf.
> > > >
> > > > Changes in v8:
> > > > - Fix indentation to 10 for enum in clock-names property.
> > > > ---
> > > > .../rockchip/rockchip,analogix-dp.yaml | 34 ++++++++++++++++++-
> > > > 1 file changed, 33 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/rockchip/
> > > > rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/
> > > > display/rockchip/rockchip,analogix-dp.yaml
> > > > index d99b23b88cc5..a1ab7a77bdd3 100644
> > > > --- a/Documentation/devicetree/bindings/display/rockchip/
> > > > rockchip,analogix-dp.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/rockchip/
> > > > rockchip,analogix-dp.yaml
> > > > @@ -26,7 +26,9 @@ properties:
> > > > items:
> > > > - const: dp
> > > > - const: pclk
> > > > - - const: grf
> > > > + - enum:
> > > > + - grf
> > > > + - hclk
> > > > power-domains:
> > > > maxItems: 1
> > > > @@ -60,6 +62,32 @@ required:
> > > > allOf:
> > > > - $ref: /schemas/display/bridge/analogix,dp.yaml#
> > > > + - if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + enum:
> > > > + - rockchip,rk3288-dp
> > > > + then:
> > > > + properties:
> > > > + clocks:
> > > > + maxItems: 2
> > > > + clock-names:
> > > > + maxItems: 2
> > > > +
> > > > + - if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + enum:
> > > > + - rockchip,rk3399-edp
> > > > + then:
> > > > + properties:
> > > > + clocks:
> > > > + minItems: 3
> > > > + clock-names:
> > > > + minItems: 3
> > >
> > > If you go back to v6, you'll see that I never asked you to remove the
> > > explict clock-names from here or below. Only the one from the 3288
> > > section. The minItems was an addition, not a replacement.
> > >
> > > pw-bot: changes-requested
> > >
> >
> > Sorry for the misunderstanding. I will restore the explicit clock-names
> > definitions and fix this in next version.
> >
>
> Sorry to bother you. I attempted to place the explicit clock-names under
> minItems:
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index a1ab7a77bdd3..ef03edf52de8 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -87,6 +87,10 @@ allOf:
> minItems: 3
> clock-names:
> minItems: 3
> + items:
> + - const: dp
> + - const: pclk
> + - const: grf
>
> - if:
> properties:
> @@ -100,6 +104,10 @@ allOf:
> minItems: 3
> clock-names:
> minItems: 3
> + items:
> + - const: dp
> + - const: pclk
> + - const: hclk
> resets:
> minItems: 2
> reset-names:
>
> make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
>
> Then the following errors occurred:
>
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> CHKDT ./Documentation/devicetree/bindings
> /home/ding/drm-misc/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:
> allOf:2:then:properties:clock-names: 'oneOf' conditional failed, one must be
> fixed:
> False schema does not allow 3
> [{'const': 'dp'}, {'const': 'pclk'}, {'const': 'grf'}] is too long
> [{'const': 'dp'}, {'const': 'pclk'}, {'const': 'grf'}] is too short
> 1 was expected
> 3 is greater than the maximum of 2
> hint: "minItems" is only needed if less than the "items" list length
> from schema $id: http://devicetree.org/meta-schemas/items.yaml
> /home/ding/drm-misc/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml:
> allOf:3:then:properties:clock-names: 'oneOf' conditional failed, one must be
> fixed:
> False schema does not allow 3
> [{'const': 'dp'}, {'const': 'pclk'}, {'const': 'hclk'}] is too long
> [{'const': 'dp'}, {'const': 'pclk'}, {'const': 'hclk'}] is too short
> 1 was expected
> 3 is greater than the maximum of 2
> hint: "minItems" is only needed if less than the "items" list length
> from schema $id: http://devicetree.org/meta-schemas/items.yaml
> LINT ./Documentation/devicetree/bindings
> DTEX Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.example.dts
> DTC [C] Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.example.dtb
>
> Neither keeping only minItems nor only the explicit clock-names causes any
> errors. Would it be a better idea to keep just the explicit clock-names
> here?
Sure.
This feels like a bug because I have no idea where the "maximum of 2" is
coming from. I'll ask Rob about it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 17/18] arm64: fpsimd: Move SME save/restore inline
From: Mark Rutland @ 2026-05-26 16:38 UTC (permalink / raw)
To: Vladimir Murzin
Cc: linux-arm-kernel, kvmarm, broonie, catalin.marinas, james.morse,
maz, oupton, tabba, will
In-Reply-To: <ahW8Eba3SNqfVDdk@J2N7QTR9R3>
On Tue, May 26, 2026 at 04:28:17PM +0100, Mark Rutland wrote:
> On Tue, May 26, 2026 at 03:39:56PM +0100, Vladimir Murzin wrote:
> > Hi Mark,
> >
> > On 5/26/26 15:08, Mark Rutland wrote:
> > > On Thu, May 21, 2026 at 02:25:55PM +0100, Mark Rutland wrote:
> > >> +static inline void __sme_save_za(struct sme_state *state, unsigned long svl)
> > >> +{
> > >> + /* The <Wv> argument to STR (array vector) can only encode W12-W15 */
> > >> + register unsigned long v asm ("12");
> > > Sorry, I had meant to put "x12" here, but evidently GCC and LLVM accept
> > > "12" on its own.
> > >
> > > For clarity (e.g. to match the comment) I'll change that to "w12" and
> > > make the type unsigned int. Likewise in __sme_load_za().
> >
> > I suspect you are intentionally not using "Ucj" constrain to limit register allocator,
> > if so I'm wondering why?
>
> Thanks for the suggestion; that was ignorance rather than intent.
>
> I was not aware of "Ucj" as it doesn't appear on the public GCC
> documentation:
>
> https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
>
> Looking at the machine description file, that's marked with '@internal',
> so IIUC GCC folk don't seem to expect/want people to use it. That said,
> LLVM seems to support it.
>
> I'll go check that all relevant toolchains support this, and poke GCC
> folk to see if they're happy to promote that to a public constraint.
GCC folk seem happy to make this public, which is great! I'll cross-link
a thread here if/when patches appear.
In the short term, using "Ucj" would require bumping our minimum
supported toolchain necessary for SME:
* GCC gained "Ucj" in 14.1.0, tagged on 7 May 2024.
* LLVM gained "Ucj" in 18.1.0, tagged on 27 Feb 2024.
... so using that would require adding a dependency on a newer
toolchain, e.g. via a CC_HAS_UCJ_CONSTRAINT to match the existing
CC_HAS_K_CONSTRAINT.
Aligned with the rationale on patch 8, v6.16 (tagged 27 July 2025) was
contemporary with GCC 15.1.0 (tagged 25 April 2025) and LLVM 20.1.0
(tagged 4 March 2025), both of which supported "Ucj".
> If that's all good, I'll move over to "Ucj". If not, I'll update the
> commit message and/or comments to explain why.
If Will and Catalin are happy to depend on a toolchain as above, I'll go
add the necessary CC_HAS_UCJ_CONSTRAINT Kconfig logic.
Otherwise I'll go note the above in a comment, and stick with the
register variable for now.
Mark.
^ permalink raw reply
* Re: [PATCH v1] block: switch numa_node to int in blk_mq_hw_ctx and init_request
From: Jens Axboe @ 2026-05-26 16:37 UTC (permalink / raw)
To: Mateusz Nowicki
Cc: Caleb Sander Mateos, Sung-woo Kim, Josef Bacik, Alasdair Kergon,
Mike Snitzer, Mikulas Patocka, Benjamin Marzinski, Ulf Hansson,
Richard Weinberger, Zhihao Cheng, Miquel Raynal,
Vignesh Raghavendra, Sven Peter, Janne Grunau, Neal Gompa,
Keith Busch, Christoph Hellwig, Sagi Grimberg, Justin Tee,
Naresh Gottumukkala, Paul Ely, Chaitanya Kulkarni,
James E.J. Bottomley, Martin K. Petersen, Thomas Fourier, Al Viro,
Luke Wang, Kees Cook, linux-block, linux-kernel, nbd, dm-devel,
linux-mmc, linux-mtd, asahi, linux-arm-kernel, linux-nvme,
linux-scsi
In-Reply-To: <20260523125210.272274-1-mateusz.nowicki@posteo.net>
On Sat, 23 May 2026 12:52:35 +0000, Mateusz Nowicki wrote:
> numa_node in blk_mq_hw_ctx and the matching argument of
> blk_mq_ops::init_request can be NUMA_NO_NODE (-1). Declared as
> unsigned int, NUMA_NO_NODE becomes UINT_MAX and walks off
> nvme_dev::descriptor_pools[] on CONFIG_NUMA=n [1].
>
> Switch the field and the callback prototype to int and update all
> in-tree init_request implementations. No functional change:
> cpu_to_node(), kmalloc_node() and blk_alloc_flush_queue() already
> take int.
>
> [...]
Applied, thanks!
[1/1] block: switch numa_node to int in blk_mq_hw_ctx and init_request
commit: 65e1c8f96ad1a1f3b72e8a91d1341d570f91d985
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Remove redundant clock enables in setup
From: Mark Brown @ 2026-05-26 16:30 UTC (permalink / raw)
To: Gaetan Florio; +Cc: michal.simek, linux-spi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260525174614.1052191-1-gaetansjo@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
On Mon, May 25, 2026 at 01:46:14PM -0400, Gaetan Florio wrote:
> The QSPI clocks are already enabled in probe() with clk_prepare_enable().
> zynq_qspi_setup_op() enables them again with clk_enable(), but the extra
> enable is never balanced. This leaves the clock enable count elevated and
> can trigger warnings when unbinding the driver.
This doesn't apply against current code, please check and resend - there
was a recent fix here so I think the issue is already fixed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 11/18] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore
From: Mark Brown @ 2026-05-26 16:28 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-12-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]
On Thu, May 21, 2026 at 02:25:49PM +0100, Mark Rutland wrote:
> Regardless of whether the vector registers are saved in FPSIMD or SVE
> format, we store FPSR and FPCR in user_fpsimd_state::{fpsr,fpcr}.
...
> Note that the SVE assembly sequence for restoring FPCR uses an
> unconditional write to FPCR. The plain FPSIMD assembly sequence has used
> a conditional write to FPCR since 2014 in commit:
> 5959e25729a5 ("arm64: fpsimd: avoid restoring fpcr if the contents haven't change")
> ... but this was not followed for the SVE restore assembly implemented
> in 2017 in commit:
> 1fc5dce78ad1 ("arm64/sve: Low-level SVE architectural state manipulation functions")
> ... so I've assumed that this doesn't actually matter in practice, and
> implemented the C version matching the existing SVE assembly.
> For the moment, fpsimd_save_state() and fpsimd_load_state() are left
> as-is with their own logic to save/restore FPSR and FPCR. This will be
> unified in subsequent patches.
There is a possibility that it only matters for older, FPSIMD only CPUs
or just that nobody got round to benchmarking this on physical CPUs with
SVE and in fact a similar optimisation is also useful there. I'm a bit
wary of dropping the optimisation without any verification of the
performance impact, but equally I'm not aware of a specific benchmark
that showed the impact or even if there was one in the first place. The
changelog sounds like the optimisation might've been written based on
inspection alone, I don't know if anyone will remember more than a
decade later.
Having said all that given that a conditional update is simple to
implement in C it seems safer to add one in the SVE path than to drop
it from the FPSIMD path.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v12 1/2] media: dt-bindings: nxp,imx8-isi: Drop fsl,blk-ctrl requirement for i.MX8ULP
From: Laurent Pinchart @ 2026-05-26 16:17 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Philipp Zabel, Mauro Carvalho Chehab, Hans Verkuil, devicetree,
imx, linux-arm-kernel, linux-kernel, linux-media, stable
In-Reply-To: <20260424-csi2_imx8ulp-v12-1-da148eabc035@oss.nxp.com>
Hi Guoniu,
Thank you for the patch.
On Fri, Apr 24, 2026 at 02:49:50PM +0800, Guoniu Zhou wrote:
> The i.MX8ULP variant does not require the fsl,blk-ctrl property. Add
> fsl,imx8ulp-isi to the exception list alongside fsl,imx91-isi.
>
> Fixes: 288517a3c6c9 ("dt-bindings: media: nxp,imx8-isi: Add i.MX8ULP ISI compatible string")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes in v12:
> - New added in v12
> ---
> Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
> index b59c4ce30b8b..279c9cd3034a 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
> @@ -117,7 +117,9 @@ allOf:
> compatible:
> not:
> contains:
> - const: fsl,imx91-isi
> + enum:
> + - fsl,imx8ulp-isi
> + - fsl,imx91-isi
> then:
> required:
> - fsl,blk-ctrl
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH RFC net-next v2] net: airoha: Add TCP LRO support
From: Alexander Lobakin @ 2026-05-26 16:01 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <20260526-airoha-eth-lro-v2-1-24e2a9e7a397@kernel.org>
From: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Tue, 26 May 2026 08:58:05 +0200
> Add hardware TCP Large Receive Offload (LRO) support to the airoha_eth
> driver, leveraging the EN7581/AN7583 SoC's 8 dedicated LRO hardware queues
> mapped to RX queues 24–31. LRO hw offloading does not support
> Scatter-Gather (SG) so it is required to increase the page_pool allocation
> order to 2 for RX queues 24–31 (LRO queues).
>
> Performance comparison between GRO and hw LRO has been carried out using
> a 10Gbps NIC:
>
> GRO: ~2.7 Gbps
> LRO: ~8.1 Gbps
>
> Please note with respect to the previous implementation, page_pool
> allocation order has been reduced from 5 to 2.
>
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
[...]
> @@ -587,6 +630,85 @@ static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
> return port >= ARRAY_SIZE(eth->ports) ? -EINVAL : port;
> }
>
> +static int airoha_qdma_lro_rx_process(struct airoha_queue *q,
> + struct airoha_qdma_desc *desc)
> +{
> + u32 desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
> + u32 msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
> + u32 msg2 = le32_to_cpu(READ_ONCE(desc->msg2));
> + u32 msg3 = le32_to_cpu(READ_ONCE(desc->msg3));
Why are these READ_ONCE()s needed? Does desc come from the HW (sorry I
didn't follow the whole code flow) or...?
> + struct sk_buff *skb = q->skb;
> + u32 len, th_off, tcp_ack_seq;
> + u16 tcp_win, l2_len;
> + struct tcphdr *th;
> + bool ipv4, ipv6;
> +
> + if (FIELD_GET(QDMA_ETH_RXMSG_AGG_COUNT_MASK, msg2) <= 1)
> + return 0;
> +
> + ipv4 = FIELD_GET(QDMA_ETH_RXMSG_IP4_MASK, msg1);
> + ipv6 = FIELD_GET(QDMA_ETH_RXMSG_IP6_MASK, msg1);
> + if (!ipv4 && !ipv6)
> + return -EOPNOTSUPP;
> +
> + l2_len = FIELD_GET(QDMA_ETH_RXMSG_L2_LEN_MASK, msg2);
> + len = FIELD_GET(QDMA_DESC_LEN_MASK, desc_ctrl);
> + if (ipv4) {
> + struct iphdr *iph;
> +
> + if (!pskb_may_pull(skb, l2_len + sizeof(*iph)))
> + return -EINVAL;
> +
> + iph = (struct iphdr *)(skb->data + l2_len);
> + if (iph->protocol != IPPROTO_TCP)
> + return -EOPNOTSUPP;
> +
> + iph->tot_len = cpu_to_be16(len - l2_len);
> + iph->check = 0;
> + iph->check = ip_fast_csum((void *)iph, iph->ihl);
> + th_off = l2_len + (iph->ihl << 2);
> + } else {
> + struct ipv6hdr *ip6h;
> +
> + if (!pskb_may_pull(skb, l2_len + sizeof(*ip6h)))
> + return -EINVAL;
> +
> + ip6h = (struct ipv6hdr *)(skb->data + l2_len);
> + if (ip6h->nexthdr != NEXTHDR_TCP)
> + return -EOPNOTSUPP;
> +
> + ip6h->payload_len = cpu_to_be16(len - l2_len - sizeof(*ip6h));
> + th_off = l2_len + sizeof(*ip6h);
> + }
> +
> + tcp_win = FIELD_GET(QDMA_ETH_RXMSG_TCP_WIN_MASK, msg3);
> + tcp_ack_seq = le32_to_cpu(READ_ONCE(desc->data));
> +
> + if (!pskb_may_pull(skb, th_off + sizeof(*th)))
> + return -EINVAL;
> +
> + th = (struct tcphdr *)(skb->data + th_off);
> + th->ack_seq = cpu_to_be32(tcp_ack_seq);
> + th->window = cpu_to_be16(tcp_win);
> +
> + /* Check tcp timestamp option */
> + if (th->doff == (sizeof(*th) + TCPOLEN_TSTAMP_ALIGNED) / 4) {
> + __be32 *topt = (__be32 *)(th + 1);
Make sure you checked the code with sparse (sometimes it's needed to
mark casts as __force, not this one tho)
> +
> + if (*topt == cpu_to_be32((TCPOPT_NOP << 24) |
Shouldn't this be `((u32)TCPOPT_NOP) << 24` to avoid sign issues?
> + (TCPOPT_NOP << 16) |
> + (TCPOPT_TIMESTAMP << 8) |
> + TCPOLEN_TIMESTAMP)) {
> + __le32 tcp_ts_reply = READ_ONCE(desc->tcp_ts_reply);
> +
> + put_unaligned_be32(le32_to_cpu(tcp_ts_reply),
> + topt + 2);
> + }
> + }
> +
> + return 0;
> +}
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH 10/18] arm64: sysreg: Add FPCR and FPSR
From: Mark Brown @ 2026-05-26 15:55 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-11-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
On Thu, May 21, 2026 at 02:25:48PM +0100, Mark Rutland wrote:
> Add sysreg definitions for FPCR and FPSR.
> +Sysreg FPCR 3 3 4 4 0
This looks good.
> +Sysreg FPSR 3 3 4 4 1
> +Res0 63:32
> +Field 31 N
> +Field 30 Q
DDI0487 M.b and DDI0601 2026-03 both call this field Z.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 09/18] arm64: fpsimd: Move sve_get_vl() and sme_get_vl() inline
From: Mark Brown @ 2026-05-26 15:47 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-10-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
On Thu, May 21, 2026 at 02:25:47PM +0100, Mark Rutland wrote:
> The sve_get_vl() and sme_get_vl() functions are wrappers for the RDVL
> and RDSVL instructions respectively. There's no need for those to be
> out-of-line.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 08/18] arm64: fpsimd: Use assembler for baseline SME instructions
From: Mark Brown @ 2026-05-26 15:45 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-9-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Thu, May 21, 2026 at 02:25:46PM +0100, Mark Rutland wrote:
> We currently support assemblers which do not support SME instructions,
> and have macros to manually encode SME instructions. This was
> necessary historically as SME support was developed before assembler
> support was widely available, but things have changed:
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 07/18] arm64: fpsimd: Use assembler for SVE instructions
From: Mark Brown @ 2026-05-26 15:43 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-8-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Thu, May 21, 2026 at 02:25:45PM +0100, Mark Rutland wrote:
> Historically we supported assemblers which could not assemble SVE
> instructions. We dropped support for such assemblers in commit:
>
> 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30")
>
> Since that commit, all supported assemblers (binutils and LLVM) are
> capable of assembling SVE instructions, and there's no need for us to
> manually encode SVE instructions.
Oh, finally. I hadn't checked in a while:
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 06/18] arm64: fpsimd: Remove sve_set_vq() and sme_set_vq()
From: Mark Brown @ 2026-05-26 15:42 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-7-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
On Thu, May 21, 2026 at 02:25:44PM +0100, Mark Rutland wrote:
> The sve_set_vq() and sme_set_vq() assembly functions (and the
> sve_load_vq and sme_load_vq macros they use) are open-coded forms of
> sysreg_clear_set*(). There's no need for these to be implemented
> out-of-line in assembly, and the 'vq_minus_1' argument is unusual and
> confusing.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 10/20] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-26 15:39 UTC (permalink / raw)
To: Michael Kelley
Cc: Aneesh Kumar K.V (Arm), iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <SN6PR02MB41574064D14D4A2734222C51D40B2@SN6PR02MB4157.namprd02.prod.outlook.com>
On Tue, May 26, 2026 at 02:56:57AM +0000, Michael Kelley wrote:
> With this patch removing SWIOTLB_FORCE from four places in
> kernel code, there are no remaining places where it is set.
> The test of SWIOTLB_FORCE could be removed from
> swiotlb_init_remap(), and its definition could be deleted
> from include/linux/swiotlb.h.
That's great! I think it shows this is the right approach!
Jason
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: imx-rpmsg: Support headphone jack detection
From: Mark Brown @ 2026-05-26 15:34 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, robh, krzk+dt, conor+dt, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, perex, tiwai, Frank.Li, s.hauer,
linux-sound, devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20260526053815.140008-3-chancel.liu@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Tue, May 26, 2026 at 02:38:14PM +0900, Chancel Liu wrote:
> Add headphone jack detection support for i.MX RPMSG audio cards.
> When the "hp-det-gpios" property is present in the device tree node,
> use simple_util_init_jack() from the ASoC simple card utilities to
> register a headphone jack with GPIO-based insertion detection.
> +#include <sound/simple_card_utils.h>
We need to ensure that SND_SIMPLE_CARD_UTILS is selected.
> + if (of_property_present(np, "hp-det-gpios")) {
> + ret = simple_util_init_jack(&data->card, &data->hp_jack,
> + 1, NULL, "Headphone Jack");
> + if (ret)
> + goto fail;
> + }
> fail:
The interaction with deferred probe is a bit fun here, we're doing this
after registering the card which might defer via unbind_card_list now.
late_probe() might be safer, everything should be mostly up by then.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 17/18] arm64: fpsimd: Move SME save/restore inline
From: Mark Rutland @ 2026-05-26 15:28 UTC (permalink / raw)
To: Vladimir Murzin
Cc: linux-arm-kernel, kvmarm, broonie, catalin.marinas, james.morse,
maz, oupton, tabba, will
In-Reply-To: <08e5ce52-be74-4fc5-a0b2-8f405a5eff99@arm.com>
On Tue, May 26, 2026 at 03:39:56PM +0100, Vladimir Murzin wrote:
> Hi Mark,
>
> On 5/26/26 15:08, Mark Rutland wrote:
> > On Thu, May 21, 2026 at 02:25:55PM +0100, Mark Rutland wrote:
> >> +static inline void __sme_save_za(struct sme_state *state, unsigned long svl)
> >> +{
> >> + /* The <Wv> argument to STR (array vector) can only encode W12-W15 */
> >> + register unsigned long v asm ("12");
> > Sorry, I had meant to put "x12" here, but evidently GCC and LLVM accept
> > "12" on its own.
> >
> > For clarity (e.g. to match the comment) I'll change that to "w12" and
> > make the type unsigned int. Likewise in __sme_load_za().
>
> I suspect you are intentionally not using "Ucj" constrain to limit register allocator,
> if so I'm wondering why?
Thanks for the suggestion; that was ignorance rather than intent.
I was not aware of "Ucj" as it doesn't appear on the public GCC
documentation:
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
Looking at the machine description file, that's marked with '@internal',
so IIUC GCC folk don't seem to expect/want people to use it. That said,
LLVM seems to support it.
I'll go check that all relevant toolchains support this, and poke GCC
folk to see if they're happy to promote that to a public constraint.
If that's all good, I'll move over to "Ucj". If not, I'll update the
commit message and/or comments to explain why.
Mark.
^ permalink raw reply
* Re: [PATCH 05/18] arm64: fpsimd: Fold sve_init_regs() into do_sve_acc()
From: Mark Brown @ 2026-05-26 15:28 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, kvmarm, catalin.marinas, james.morse, maz,
oupton, tabba, will
In-Reply-To: <20260521132556.584676-6-mark.rutland@arm.com>
[-- Attachment #1: Type: text/plain, Size: 393 bytes --]
On Thu, May 21, 2026 at 02:25:43PM +0100, Mark Rutland wrote:
> For historical reasons, do_sve_acc() is structurally different from
> do_sme_acc(), and the logic to convert the task from FPSIMD to SVE is
> out-of-line in sve_init_regs(). We only use sve_init_regs() within
> do_sme_acc(), so it's not necessary for this to be a separate function.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [GIT PULL] Qualcomm driver updates for v7.2
From: Bjorn Andersson @ 2026-05-26 15:26 UTC (permalink / raw)
To: arm, soc
Cc: linux-arm-msm, linux-arm-kernel, Arnd Bergmann, Praveen Talari,
Abel Vesa, Alexander Koskovich, Deepti Jaggi, Dmitry Baryshkov,
Francisco Munoz Ruiz, Komal Bajaj, Mukesh Ojha,
Kathiravan Thirumoorthy, Shawn Guo, Dan Carpenter, Fenglin Wu,
Harrison Vanderbyl, Konrad Dybcio, Raj Aryan, Rosen Penev,
Tony Truong
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-7.2
for you to fetch changes up to 23cee0d07a412f1fadb236358e0d834fabf0efcc:
Merge branch '20260227061544.1785978-1-praveen.talari@oss.qualcomm.com' into drivers-for-7.2 (2026-05-21 22:00:31 -0500)
----------------------------------------------------------------
Qualcomm driver updates for v7.2
Enable QSEECOM and with that access to UEFI variables on the Surface Pro
12in laptop.
Refactor the Geni Serial-Engine helper code to allow the serial engine
drivers (such as I2C) to operate on targets where power and performance
is controlled through an SCMI server instead of individual resources in
Linux.
Extend the LLCC driver to support reading its data from a System Cache
Table (SCT) in memory instead of being hard coded per platform in the
driver. Also add support for the Eliza platform.
Add support for the Hawi platform to pd-mapper.
Switch the SMEM driver to track partitions using xarray to handle the
ever growing number of hosts better.
Extend the socinfo driver with knowledge about the Nord, SM7750,
IPQ9650, and Shikra SoCs, as well as PMAU0102, PMC1020H, PMIV0102, and
PMIV0104 PMICs.
Define UBWC 3.1 and add a couple of convenient helpers in the UBWC
library for MDSS and Adreno.
Fix a memory leak in the WCNSS firmware download mechanism.
----------------------------------------------------------------
Abel Vesa (4):
dt-bindings: soc: qcom: qcom,pmic-glink: Document Eliza compatible
dt-bindings: soc: qcom,aoss-qmp: Document the Eliza Always-On Subsystem side channel
dt-bindings: cache: qcom,llcc: Document Eliza LLCC block
soc: qcom: llcc-qcom: Add support for Eliza
Alexander Koskovich (3):
soc: qcom: socinfo: Add PMIV0102 & PMIV0104 PMICs
dt-bindings: arm: qcom,ids: Add SoC ID for SM7750
soc: qcom: socinfo: Add SoC ID for SM7750
Bjorn Andersson (2):
Merge branch '20260507-ubwc-rework-v4-4-c19593d20c1d@oss.qualcomm.com' into drivers-for-7.2
Merge branch '20260227061544.1785978-1-praveen.talari@oss.qualcomm.com' into drivers-for-7.2
Dan Carpenter (1):
soc: qcom: llcc-qcom: Fix NULL vs IS_ERR() bug in qcom_llcc_get_fw_config()
Deepti Jaggi (3):
dt-bindings: qcom: geni-se-qup: Add compatible for SA8797P SoC
dt-bindings: arm: qcom,ids: Add SoC ID for Nord SA8797P
soc: qcom: socinfo: Add SoC ID for Nord SA8797P
Dmitry Baryshkov (3):
soc: qcom: ubwc: define UBWC 3.1
soc: qcom: ubwc: define helper for MDSS and Adreno drivers
soc: qcom: ubwc: add helper controlling AMSBC enablement
Fenglin Wu (1):
dt-bindings: soc: qcom: qcom,pmic-glink: Add Hawi compatible string
Francisco Munoz Ruiz (3):
dt-bindings: cache: qcom,llcc: Document Hawi SoC
soc: qcom: llcc-qcom: get SCT descriptors from fw-populated memory
soc: qcom: llcc-qcom: Capitalize LLCC/EDAC in comments and diagnostics
Harrison Vanderbyl (1):
firmware: qcom: scm: Allow QSEECOM on Surface Pro 12in
Kathiravan Thirumoorthy (2):
dt-bindings: arm: qcom,ids: add SOC IDs for IPQ9650 family
soc: qcom: socinfo: add SoC ID for IPQ9650 family
Komal Bajaj (3):
dt-bindings: cache: qcom,llcc: Document Shikra LLCC
dt-bindings: arm: qcom,ids: Add SoC ID for Shikra IoT variants
soc: qcom: socinfo: Add SoC ID for Shikra IoT variants
Konrad Dybcio (1):
soc: qcom: socinfo: Add PMICs that ship with Glymur
Mukesh Ojha (3):
dt-bindings: firmware: qcom,scm: Document SCM on Hawi SoC
dt-bindings: soc: qcom,aoss-qmp: Document the Hawi AOSS side channel
soc: qcom: pd-mapper: Add support for Hawi SoC
Praveen Talari (7):
soc: qcom: geni-se: Refactor geni_icc_get() and make qup-memory ICC path optional
soc: qcom: geni-se: Add geni_icc_set_bw_ab() function
soc: qcom: geni-se: Introduce helper API for resource initialization
soc: qcom: geni-se: Handle core clk in geni_se_clks_off() and geni_se_clks_on()
soc: qcom: geni-se: Add resources activation/deactivation helpers
soc: qcom: geni-se: Introduce helper API for attaching power domains
soc: qcom: geni-se: Introduce helper APIs for performance control
Raj Aryan (1):
soc: qcom: spmi-pmic: add SUBTYPEs for Glymur/Kaanapali/SM8750 PMICs
Rosen Penev (1):
soc: qcom: wcnss: fix leak of fw
Shawn Guo (2):
dt-bindings: firmware: qcom,scm: Document SCM for Nord SoC
soc: qcom: socinfo: Add PMIC PMAU0102
Tony Truong (1):
soc: qcom: smem: Switch partitions to xarray
.../devicetree/bindings/cache/qcom,llcc.yaml | 43 ++
.../devicetree/bindings/firmware/qcom,scm.yaml | 3 +
.../bindings/soc/qcom/qcom,aoss-qmp.yaml | 2 +
.../bindings/soc/qcom/qcom,pmic-glink.yaml | 6 +
.../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 31 +-
drivers/firmware/qcom/qcom_scm.c | 1 +
drivers/soc/qcom/llcc-qcom.c | 481 ++++++++++++++++++---
drivers/soc/qcom/qcom-geni-se.c | 270 +++++++++++-
drivers/soc/qcom/qcom_pd_mapper.c | 8 +
drivers/soc/qcom/smem.c | 56 +--
drivers/soc/qcom/socinfo.c | 23 +
drivers/soc/qcom/wcnss_ctrl.c | 11 +-
include/dt-bindings/arm/qcom,ids.h | 11 +
include/linux/soc/qcom/geni-se.h | 19 +
include/linux/soc/qcom/llcc-qcom.h | 44 +-
include/linux/soc/qcom/ubwc.h | 22 +
include/soc/qcom/qcom-spmi-pmic.h | 15 +-
17 files changed, 920 insertions(+), 126 deletions(-)
^ permalink raw reply
* RE: [PATCH RFT] tty: serial: fsl_lpuart: Add register dump
From: Sherry Sun @ 2026-05-26 15:21 UTC (permalink / raw)
To: Stefan Wahren, Greg Kroah-Hartman, Jiri Slaby
Cc: Christophe JAILLET, Ingo Molnar, Frank Li,
linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260526140113.50372-1-wahrenst@gmx.net>
> Subject: [PATCH RFT] tty: serial: fsl_lpuart: Add register dump
>
> Dumping the registers from userspace for debug purposes isn't trivial,
> because runtime PM can gate the required clocks and any read access to
> these registers would result in a lockup.
>
> So implement a register dump via debugfs, which deals with the runtime PM.
No need, you can disable runtime pm from user space before dump the registers.
For example: echo on > /sys/bus/platform/devices/29860000.serial/power/control
Best Regards
Sherry
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
>
> Hi, I only have access to a board (i.MX93) with 32 bit registers, so it would be
> great if someone could test it for 8 bit registers.
>
> Thanks
>
> drivers/tty/serial/fsl_lpuart.c | 69 +++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c index
> 1bd7ec9c81ea..7e4b3e59414a 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -10,6 +10,7 @@
> #include <linux/circ_buf.h>
> #include <linux/clk.h>
> #include <linux/console.h>
> +#include <linux/debugfs.h>
> #include <linux/delay.h>
> #include <linux/dma-mapping.h>
> #include <linux/dmaengine.h>
> @@ -23,6 +24,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/seq_file.h>
> #include <linux/serial_core.h>
> #include <linux/slab.h>
> #include <linux/tty_flip.h>
> @@ -291,6 +293,8 @@ struct lpuart_port {
> bool is_cs7; /* Set to true when character size is 7
> */
> /* and the parity is enabled
> */
> bool dma_idle_int;
> +
> + struct dentry *debugfs_dir;
> };
>
> struct lpuart_soc_data {
> @@ -1031,6 +1035,7 @@ static void lpuart32_rxint(struct lpuart_port *sport)
> }
>
> out:
> +
> uart_unlock_and_check_sysrq(&sport->port);
>
> tty_flip_buffer_push(port);
> @@ -2860,6 +2865,67 @@ static int lpuart_global_reset(struct lpuart_port
> *sport)
> return 0;
> }
>
> +#ifdef CONFIG_DEBUG_FS
> +
> +#define dump_register_hex(_seq, _reg, _sport) \ seq_printf((_seq),
> +"%-12s: 0x%02x\n", #_reg, readb((_sport)->port.membase + (_reg)))
> +
> +#define dump_register32_hex(_seq, _reg, _sport) \ seq_printf((_seq),
> +"%-12s: 0x%08x\n", #_reg, lpuart32_read(&(_sport)->port, _reg))
> +
> +static int regs_show(struct seq_file *s, void *p) {
> + struct lpuart_port *sport = s->private;
> +
> + pm_runtime_get_sync(sport->port.dev);
> +
> + if (lpuart_is_32(sport)) {
> + dump_register32_hex(s, UARTBAUD, sport);
> + dump_register32_hex(s, UARTSTAT, sport);
> + dump_register32_hex(s, UARTCTRL, sport);
> + dump_register32_hex(s, UARTMATCH, sport);
> + dump_register32_hex(s, UARTMODIR, sport);
> + dump_register32_hex(s, UARTFIFO, sport);
> + dump_register32_hex(s, UARTWATER, sport);
> + } else {
> + dump_register_hex(s, UARTBDH, sport);
> + dump_register_hex(s, UARTBDL, sport);
> + dump_register_hex(s, UARTCR1, sport);
> + dump_register_hex(s, UARTCR2, sport);
> + dump_register_hex(s, UARTSR1, sport);
> + dump_register_hex(s, UARTCR3, sport);
> + dump_register_hex(s, UARTDR, sport);
> + dump_register_hex(s, UARTCR4, sport);
> + dump_register_hex(s, UARTCR5, sport);
> + dump_register_hex(s, UARTMODEM, sport);
> + dump_register_hex(s, UARTPFIFO, sport);
> + dump_register_hex(s, UARTCFIFO, sport);
> + dump_register_hex(s, UARTSFIFO, sport);
> + dump_register_hex(s, UARTTWFIFO, sport);
> + dump_register_hex(s, UARTTCFIFO, sport);
> + dump_register_hex(s, UARTRWFIFO, sport);
> + }
> +
> + pm_runtime_mark_last_busy(sport->port.dev);
> + pm_runtime_put_autosuspend(sport->port.dev);
> +
> + return 0;
> +}
> +
> +DEFINE_SHOW_ATTRIBUTE(regs);
> +
> +static void lpuart_init_debugfs(struct lpuart_port *sport) {
> + sport->debugfs_dir = debugfs_create_dir(dev_name(sport-
> >port.dev),
> + NULL);
> +
> + debugfs_create_file("regs", 0400, sport->debugfs_dir, sport,
> +®s_fops); }
> +
> +#else
> +static inline void lpuart_init_debugfs(struct lpuart_port *sport) {}
> +#endif
> +
> static int lpuart_probe(struct platform_device *pdev) {
> const struct lpuart_soc_data *sdata =
> of_device_get_match_data(&pdev->dev);
> @@ -2969,6 +3035,8 @@ static int lpuart_probe(struct platform_device
> *pdev)
> if (ret)
> goto failed_irq_request;
>
> + lpuart_init_debugfs(sport);
> +
> return 0;
>
> failed_irq_request:
> @@ -2987,6 +3055,7 @@ static void lpuart_remove(struct platform_device
> *pdev) {
> struct lpuart_port *sport = platform_get_drvdata(pdev);
>
> + debugfs_remove_recursive(sport->debugfs_dir);
> uart_remove_one_port(&lpuart_reg, &sport->port);
>
> lpuart_disable_clks(sport);
> --
> 2.43.0
^ permalink raw reply
* [PATCH v5 5/6] KVM: arm64: Validate the offset to the mem access descriptor
From: Mostafa Saleh @ 2026-05-26 15:19 UTC (permalink / raw)
To: op-tee, linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
jens.wiklander, sumit.garg, sebastianene, vdonnefort,
sudeep.holla, Mostafa Saleh
In-Reply-To: <20260526151934.3783707-1-smostafa@google.com>
From: Sebastian Ene <sebastianene@google.com>
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this from 1.1 onward:
Type | Field name | Offset
[ Header | ffa_mem_region | 0
EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
]
Verify that the offset to the first endpoint memory access descriptor
is within the mailbox buffer bounds.
Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that
should be replaced ffa_emad_size_get() for compatibility with FFA v1.0.
[@Mostafa, Add missing call to ffa_rx_release() and use fraglen
as the max buffer size as it is the only intialised part]
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index b6cf9ad82e12..79de358333e4 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -479,7 +479,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
struct ffa_mem_region *buf;
- u32 offset, nr_ranges, checked_offset;
+ u32 offset, nr_ranges, checked_offset, em_mem_access_off;
int ret = 0;
if (addr_mbz || npages_mbz || fraglen > len ||
@@ -489,7 +489,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
}
if (fraglen < sizeof(struct ffa_mem_region) +
- sizeof(struct ffa_mem_region_attributes)) {
+ ffa_emad_size_get(hyp_ffa_version)) {
ret = FFA_RET_INVALID_PARAMETERS;
goto out;
}
@@ -508,8 +508,13 @@ static void __do_ffa_mem_xfer(const u64 func_id,
buf = hyp_buffers.tx;
memcpy(buf, host_buffers.tx, fraglen);
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
if (!offset || buf->ep_count != 1 || buf->sender_id != HOST_FFA_ID) {
ret = FFA_RET_INVALID_PARAMETERS;
@@ -576,7 +581,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
DECLARE_REG(u32, flags, ctxt, 3);
struct ffa_mem_region_attributes *ep_mem_access;
struct ffa_composite_mem_region *reg;
- u32 offset, len, fraglen, fragoff;
+ u32 offset, len, fraglen, fragoff, em_mem_access_off;
struct ffa_mem_region *buf;
int ret = 0;
u64 handle;
@@ -599,8 +604,14 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
len = res->a1;
fraglen = res->a2;
- ep_mem_access = (void *)buf +
- ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ em_mem_access_off = ffa_mem_desc_offset(buf, 0, hyp_ffa_version);
+ if ((u64)em_mem_access_off + ffa_emad_size_get(hyp_ffa_version) > fraglen) {
+ ret = FFA_RET_INVALID_PARAMETERS;
+ ffa_rx_release(res);
+ goto out_unlock;
+ }
+
+ ep_mem_access = (void *)buf + em_mem_access_off;
offset = ep_mem_access->composite_off;
/*
* We can trust the SPMD to get this right, but let's at least
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v5 3/6] firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation
From: Mostafa Saleh @ 2026-05-26 15:19 UTC (permalink / raw)
To: op-tee, linux-kernel, kvmarm, linux-arm-kernel
Cc: maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
jens.wiklander, sumit.garg, sebastianene, vdonnefort,
sudeep.holla, Mostafa Saleh
In-Reply-To: <20260526151934.3783707-1-smostafa@google.com>
From: Sebastian Ene <sebastianene@google.com>
Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint
memory access array and to comply with the FF-A spec instead of defaulting
to `sizeof(struct ffa_mem_region)`.
This requires moving `ffa_mem_region_additional_setup()` earlier in the setup
flow.
Also, add sanity checks to ensure the calculated descriptor offsets do not
exceed `max_fragsize`.
[@Mostafa Harden error checking]
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
drivers/firmware/arm_ffa/driver.c | 16 +++++++++++-----
include/linux/arm_ffa.h | 2 +-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 059e2aae7ca0..bed4bd48963f 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -703,19 +703,26 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
struct ffa_composite_mem_region *composite;
struct ffa_mem_region_addr_range *constituents;
struct ffa_mem_region_attributes *ep_mem_access;
- u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg);
+ u32 idx, frag_len, length, buf_sz = 0, num_entries = sg_nents(args->sg), ep_offset;
+ u32 emad_size = ffa_emad_size_get(drv_info->version);
mem_region->tag = args->tag;
mem_region->flags = args->flags;
mem_region->sender_id = drv_info->vm_id;
mem_region->attributes = ffa_memory_attributes_get(func_id);
+
+ ffa_mem_region_additional_setup(drv_info->version, mem_region);
composite_offset = ffa_mem_desc_offset(buffer, args->nattrs,
drv_info->version);
+ if (composite_offset + sizeof(*composite) > max_fragsize)
+ return -ENXIO;
for (idx = 0; idx < args->nattrs; idx++) {
- ep_mem_access = buffer +
- ffa_mem_desc_offset(buffer, idx, drv_info->version);
- memset(ep_mem_access, 0, ffa_emad_size_get(drv_info->version));
+ ep_offset = ffa_mem_desc_offset(buffer, idx, drv_info->version);
+ if (ep_offset + emad_size > max_fragsize)
+ return -ENXIO;
+ ep_mem_access = buffer + ep_offset;
+ memset(ep_mem_access, 0, emad_size);
ep_mem_access->receiver = args->attrs[idx].receiver;
ep_mem_access->attrs = args->attrs[idx].attrs;
ep_mem_access->composite_off = composite_offset;
@@ -725,7 +732,6 @@ ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
}
mem_region->handle = 0;
mem_region->ep_count = args->nattrs;
- ffa_mem_region_additional_setup(drv_info->version, mem_region);
composite = buffer + composite_offset;
composite->total_pg_cnt = ffa_get_num_pages_sg(args->sg);
diff --git a/include/linux/arm_ffa.h b/include/linux/arm_ffa.h
index 81e603839c4a..62d67dae8b70 100644
--- a/include/linux/arm_ffa.h
+++ b/include/linux/arm_ffa.h
@@ -445,7 +445,7 @@ ffa_mem_desc_offset(struct ffa_mem_region *buf, int count, u32 ffa_version)
if (!FFA_MEM_REGION_HAS_EP_MEM_OFFSET(ffa_version))
offset += offsetof(struct ffa_mem_region, ep_mem_offset);
else
- offset += sizeof(struct ffa_mem_region);
+ offset += buf->ep_mem_offset;
return offset;
}
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox