* Re: [PATCH v13 11/17] drm/bridge: analogix_dp: Apply drm_bridge_connector helper
From: Luca Ceresoli @ 2026-04-10 7:41 UTC (permalink / raw)
To: Damon Ding, andrzej.hajda, neil.armstrong, rfoss,
maarten.lankhorst, mripard, tzimmermann, airlied, simona,
victor.liu, Frank.Li, shawnguo, s.hauer, inki.dae, sw0312.kim,
kyungmin.park, krzk, jingoohan1, p.zabel, hjc, heiko, andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, kernel, festevam,
alim.akhtar, dmitry.baryshkov, nicolas.frattaroli, dianders,
m.szyprowski, linux-kernel, dri-devel, imx, linux-arm-kernel,
linux-samsung-soc, linux-rockchip
In-Reply-To: <20260409065301.446670-12-damon.ding@rock-chips.com>
Hello Damon,
On Thu Apr 9, 2026 at 8:52 AM CEST, Damon Ding wrote:
> Initialize bridge_connector for both Rockchip and Exynos encoder sides.
> Then, make DRM_BRIDGE_ATTACH_NO_CONNECTOR mandatory for Analogix bridge
> side, as the private &drm_connector is no longer created.
>
> The previous &drm_connector_funcs and &drm_connector_helper_funcs APIs
> are replaced by the corresponding &drm_bridge_funcs APIs:
>
> analogix_dp_atomic_check() -> analogix_dp_bridge_atomic_check()
> analogix_dp_detect() -> analogix_dp_bridge_detect()
> analogix_dp_get_modes() -> analogix_dp_bridge_get_modes()
> analogix_dp_bridge_edid_read()
>
> Additionally, the compatibilities of Analogix DP bridge based on whether
> the next bridge is a 'panel'. If it is, OP_MODES and OP_DETECT are
> supported; If not (the next bridge is a 'monitor' or a bridge chip),
> OP_EDID and OP_DETECT are supported.
>
> The devm_drm_bridge_add() is placed in analogix_dp_bind() instead of
> analogix_dp_probe(), because the type of next bridge (the panel, monitor
> or bridge chip) can only be determined after the probe process has fully
> completed.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
I noticed two issues, sorry I haven't catched them before...
> @@ -1580,7 +1533,8 @@ EXPORT_SYMBOL_GPL(analogix_dp_unbind);
>
> int analogix_dp_start_crc(struct drm_connector *connector)
> {
> - struct analogix_dp_device *dp = to_dp(connector);
> + struct analogix_dp_device *dp;
> + struct drm_bridge *bridge;
>
> if (!connector->state->crtc) {
> DRM_ERROR("Connector %s doesn't currently have a CRTC.\n",
> @@ -1588,13 +1542,26 @@ int analogix_dp_start_crc(struct drm_connector *connector)
> return -EINVAL;
> }
>
> + bridge = drm_bridge_chain_get_first_bridge(connector->encoder);
> + if (bridge->type != DRM_MODE_CONNECTOR_eDP)
> + return -EINVAL;
> +
> + dp = to_dp(bridge);
> +
> return drm_dp_start_crc(&dp->aux, connector->state->crtc);
> }
drm_bridge_chain_get_first_bridge() takes a reference, you must call
drm_bridge_put(bridge) before returning. Given there are two return paths I
suggest:
- struct drm_bridge *bridge;
- bridge = drm_bridge_chain_get_first_bridge(connector->encoder);
+ struct drm_bridge *bridge __free(drm_bridge_put) =
+ drm_bridge_chain_get_first_bridge(connector->encoder);
> EXPORT_SYMBOL_GPL(analogix_dp_start_crc);
>
> int analogix_dp_stop_crc(struct drm_connector *connector)
> {
> - struct analogix_dp_device *dp = to_dp(connector);
> + struct analogix_dp_device *dp;
> + struct drm_bridge *bridge;
> +
> + bridge = drm_bridge_chain_get_first_bridge(connector->encoder);
> + if (bridge->type != DRM_MODE_CONNECTOR_eDP)
> + return -EINVAL;
> +
> + dp = to_dp(bridge);
>
> return drm_dp_stop_crc(&dp->aux);
> }
Same here:
- struct drm_bridge *bridge;
- bridge = drm_bridge_chain_get_first_bridge(connector->encoder);
+ struct drm_bridge *bridge __free(drm-bridge_put) =
+ drm_bridge_chain_get_first_bridge(connector->encoder);
With the above two changes you can add to v14:
+Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* RE: [PATCH v2 4/7] iommu/arm-smmu-v3: Mark ATC invalidate timeouts via lockless bitmap
From: Tian, Kevin @ 2026-04-10 7:39 UTC (permalink / raw)
To: Jason Gunthorpe, Nicolin Chen
Cc: Samiullah Khawaja, will@kernel.org, robin.murphy@arm.com,
joro@8bytes.org, bhelgaas@google.com, rafael@kernel.org,
lenb@kernel.org, praan@google.com, baolu.lu@linux.intel.com,
xueshuai@linux.alibaba.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
Vikram Sethi
In-Reply-To: <20260323235105.GV7340@nvidia.com>
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, March 24, 2026 7:51 AM
>
> On Wed, Mar 18, 2026 at 08:12:04PM -0700, Nicolin Chen wrote:
> > > > VT-d is able to find out the SID of the device for which the device TLB
> > > > invalidation timed-out occured by using the SID reported in the
> > > > "Invalidation Queue Error Record Register" (VT-d Specs 11.4.9.9).
> > >
> > > yes. but when there are multiple submissions (each with a wait descriptor)
> > > fetched/handled by the hw and then an invalidation timeout comes, all
> > > pending wait descriptors will be aborted (not just the one corresponding
> > > to the timeout). In this case all affected submitters need to re-try.
> >
> > This sounds similar to SMMU then.
>
> Not entirely.. smmu HW stops processing at a SYNC and waits for
> everything pending to complete, then goes on forward. If there is a HW
> reported ATC timeout then it is contained to the SYNC that followed
> the ATC invalidation. The errored sync is skipped and whatever follows
> continues forward, so it doesn't contaminate future work.
>
> VT-d's wait descriptor with fence FN=1 sounds identical???
yes
>
> I guess if FN=0 then things start to become indeterminate what the
> wait actually waits for..
>
Currently we use FN=0, so all pending works before head pointer will be
re-submitted. It has a larger impact compared to FN=1 when a timeout
happens, but allows more parallel work in hardware at other times.
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Linus Walleij @ 2026-04-10 7:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Frank Wunderlich, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Bartosz Golaszewski, linux-mediatek,
linux-gpio, linux-kernel, linux-arm-kernel
In-Reply-To: <20260410070935.9540-1-bartosz.golaszewski@oss.qualcomm.com>
On Fri, Apr 10, 2026 at 9:09 AM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> If the gpio_chip::get_direction() callback is not implemented by the GPIO
> controller driver, GPIOLIB emits a warning.
>
> Implement get_direction() for the GPIO part of pinctrl-moore.
>
> Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
> Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
> Reported-by: Frank Wunderlich <linux@fw-web.de>
> Closes: https://lore.kernel.org/all/20260409132724.126258-1-linux@fw-web.de/
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
LGTM, but it would have to go into v7.1-rc1 right now due to timing,
then from there to stable.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-10 7:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260409195950.74e4bc97@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
> On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> > EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> > Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> > manages the traffic in a TDM manner. As a result multiple net_devices can
> > connect to the same GDM{3,4} port and there is a theoretical "1:n"
> > relation between GDM ports and net_devices.
>
> Looks like this driver uses page pool.
> If you're sharing the same page pool across multiple netdevs
> it must not be linked to a netdev.
are you referring to slow.netdev pointer? If so, this is not set in airoha_eth
driver.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v6 3/4] perf report: Update document for SIMD flags
From: Leo Yan @ 2026-04-10 7:37 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Namhyung Kim, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Mark Rutland
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-arm-kernel,
Leo Yan
In-Reply-To: <20260410-perf_support_arm_spev1-3-v6-0-3c6f2dfe2cd3@arm.com>
Update SIMD architecture and predicate flags.
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
tools/perf/Documentation/perf-report.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
index 52f316628e43ac9851ecaa85f706e22c26294649..22f87eaa3279653836eaaa07a358c14f2e0afa75 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -136,7 +136,10 @@ OPTIONS
- addr: (Full) virtual address of the sampled instruction
- retire_lat: On X86, this reports pipeline stall of this instruction compared
to the previous instruction in cycles. And currently supported only on X86
- - simd: Flags describing a SIMD operation. "e" for empty Arm SVE predicate. "p" for partial Arm SVE predicate
+ - simd: Flags describing a SIMD operation. The architecture type can be Arm's
+ ASE (Advanced SIMD extension), SVE, SME. It provides an extra tag for
+ predicate: "e" for empty predicate, "p" for partial predicate, "d" for
+ predicate disabled, and "f" for full predicate.
- type: Data type of sample memory access.
- typeoff: Offset in the data type of sample memory access.
- symoff: Offset in the symbol.
--
2.34.1
^ permalink raw reply related
* [PATCH v6 4/4] perf arm_spe: Improve SIMD flags setting
From: Leo Yan @ 2026-04-10 7:37 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Namhyung Kim, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Mark Rutland
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-arm-kernel,
Leo Yan
In-Reply-To: <20260410-perf_support_arm_spev1-3-v6-0-3c6f2dfe2cd3@arm.com>
Fill in ASE and SME operations for the SIMD arch field.
Also set the predicate flags for SVE and SME, but differences between
them: SME does not have a predicate flag, so the setting is based on
events. SVE provides a predicate flag to indicate whether the predicate
is disabled, which allows it to be distinguished into four cases: full
predicates, empty predicates, fully predicated, and disabled predicates.
After:
perf report -s +simd
...
0.06% 0.06% sve-test sve-test [.] setz [p] SVE
0.06% 0.06% sve-test [kernel.kallsyms] [k] do_raw_spin_lock
0.06% 0.06% sve-test sve-test [.] getz [p] SVE
0.06% 0.06% sve-test [kernel.kallsyms] [k] timekeeping_advance
0.06% 0.06% sve-test sve-test [.] getz [d] SVE
0.06% 0.06% sve-test [kernel.kallsyms] [k] update_load_avg
0.06% 0.06% sve-test sve-test [.] getz [e] SVE
0.05% 0.05% sve-test sve-test [.] setz [e] SVE
0.05% 0.05% sve-test [kernel.kallsyms] [k] update_curr
0.05% 0.05% sve-test sve-test [.] setz [d] SVE
0.05% 0.05% sve-test [kernel.kallsyms] [k] do_raw_spin_unlock
0.05% 0.05% sve-test [kernel.kallsyms] [k] timekeeping_update_from_shadow.constprop.0
0.05% 0.05% sve-test sve-test [.] getz [f] SVE
0.05% 0.05% sve-test sve-test [.] setz [f] SVE
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
tools/perf/util/arm-spe.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 70dd9bee47c755f19a51b80c6df3499180de9540..e5835042acdf7685f95e19665cd45f97ed868275 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -353,12 +353,26 @@ static struct simd_flags arm_spe__synth_simd_flags(const struct arm_spe_record *
if (record->op & ARM_SPE_OP_SVE)
simd_flags.arch |= SIMD_OP_FLAGS_ARCH_SVE;
-
- if (record->type & ARM_SPE_SVE_PARTIAL_PRED)
- simd_flags.pred |= SIMD_OP_FLAGS_PRED_PARTIAL;
-
- if (record->type & ARM_SPE_SVE_EMPTY_PRED)
- simd_flags.pred |= SIMD_OP_FLAGS_PRED_EMPTY;
+ else if (record->op & ARM_SPE_OP_SME)
+ simd_flags.arch |= SIMD_OP_FLAGS_ARCH_SME;
+ else if (record->op & (ARM_SPE_OP_ASE | ARM_SPE_OP_SIMD_FP))
+ simd_flags.arch |= SIMD_OP_FLAGS_ARCH_ASE;
+
+ if (record->op & ARM_SPE_OP_SVE) {
+ if (!(record->op & ARM_SPE_OP_PRED))
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_DISABLED;
+ else if (record->type & ARM_SPE_SVE_PARTIAL_PRED)
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_PARTIAL;
+ else if (record->type & ARM_SPE_SVE_EMPTY_PRED)
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_EMPTY;
+ else
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_FULL;
+ } else {
+ if (record->type & ARM_SPE_SVE_PARTIAL_PRED)
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_PARTIAL;
+ else if (record->type & ARM_SPE_SVE_EMPTY_PRED)
+ simd_flags.pred = SIMD_OP_FLAGS_PRED_EMPTY;
+ }
return simd_flags;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v6 2/4] perf sort: Sort disabled and full predicated flags
From: Leo Yan @ 2026-04-10 7:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Namhyung Kim, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Mark Rutland
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-arm-kernel,
Leo Yan
In-Reply-To: <20260410-perf_support_arm_spev1-3-v6-0-3c6f2dfe2cd3@arm.com>
According to the Arm ARM (ARM DDI 0487, L.a), section D18.2.6
"Events packet", apart from the empty predicate and partial
predicates, an SVE or SME operation can be predicate-disabled
or full predicated.
To provide complete results, introduce two predicate types for
these cases.
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
tools/perf/util/sample.h | 13 +++++++++----
tools/perf/util/sort.c | 15 ++++++++++-----
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/sample.h b/tools/perf/util/sample.h
index 0e5ee7e0fb94f2d36c35df15de7c4ea00547a6c2..ca0c407c4423a4bc0b8098c657238b50ff5a3a17 100644
--- a/tools/perf/util/sample.h
+++ b/tools/perf/util/sample.h
@@ -72,8 +72,8 @@ struct aux_sample {
struct simd_flags {
u8 arch: 2, /* architecture (isa) */
- pred: 2, /* predication */
- resv: 4; /* reserved */
+ pred: 3, /* predication */
+ resv: 3; /* reserved */
};
/* simd architecture flags */
@@ -85,8 +85,13 @@ enum simd_op_flags {
};
/* simd predicate flags */
-#define SIMD_OP_FLAGS_PRED_PARTIAL 0x01 /* partial predicate */
-#define SIMD_OP_FLAGS_PRED_EMPTY 0x02 /* empty predicate */
+enum simd_pred_flags {
+ SIMD_OP_FLAGS_PRED_NONE = 0x0, /* Not available */
+ SIMD_OP_FLAGS_PRED_PARTIAL, /* partial predicate */
+ SIMD_OP_FLAGS_PRED_EMPTY, /* empty predicate */
+ SIMD_OP_FLAGS_PRED_FULL, /* full predicate */
+ SIMD_OP_FLAGS_PRED_DISABLED, /* disabled predicate */
+};
/**
* struct perf_sample
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 7198eb3ae560cdac762a7d233d19bd6c70903d39..0020089cb13c7858ba04579568b1bdbc32909c63 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -209,18 +209,23 @@ static int hist_entry__simd_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width __maybe_unused)
{
const char *name;
+ const char *pred_str = ".";
if (!he->simd_flags.arch)
return repsep_snprintf(bf, size, "");
name = hist_entry__get_simd_name(&he->simd_flags);
- if (he->simd_flags.pred & SIMD_OP_FLAGS_PRED_EMPTY)
- return repsep_snprintf(bf, size, "[e] %s", name);
- else if (he->simd_flags.pred & SIMD_OP_FLAGS_PRED_PARTIAL)
- return repsep_snprintf(bf, size, "[p] %s", name);
+ if (he->simd_flags.pred == SIMD_OP_FLAGS_PRED_EMPTY)
+ pred_str = "e";
+ else if (he->simd_flags.pred == SIMD_OP_FLAGS_PRED_PARTIAL)
+ pred_str = "p";
+ else if (he->simd_flags.pred == SIMD_OP_FLAGS_PRED_DISABLED)
+ pred_str = "d";
+ else if (he->simd_flags.pred == SIMD_OP_FLAGS_PRED_FULL)
+ pred_str = "f";
- return repsep_snprintf(bf, size, "[.] %s", name);
+ return repsep_snprintf(bf, size, "[%s] %s", pred_str, name);
}
static struct sort_entry sort_simd = {
--
2.34.1
^ permalink raw reply related
* [PATCH v6 1/4] perf sort: Support sort ASE and SME
From: Leo Yan @ 2026-04-10 7:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Namhyung Kim, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Mark Rutland
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-arm-kernel,
Leo Yan
In-Reply-To: <20260410-perf_support_arm_spev1-3-v6-0-3c6f2dfe2cd3@arm.com>
Support sort Advance SIMD extension (ASE) and SME.
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
tools/perf/util/sample.h | 12 +++++++++---
tools/perf/util/sort.c | 6 +++++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/sample.h b/tools/perf/util/sample.h
index 3d27a0daef8fb2d72ffa8510923857e73130dd40..0e5ee7e0fb94f2d36c35df15de7c4ea00547a6c2 100644
--- a/tools/perf/util/sample.h
+++ b/tools/perf/util/sample.h
@@ -71,12 +71,18 @@ struct aux_sample {
};
struct simd_flags {
- u8 arch:1, /* architecture (isa) */
- pred:2; /* predication */
+ u8 arch: 2, /* architecture (isa) */
+ pred: 2, /* predication */
+ resv: 4; /* reserved */
};
/* simd architecture flags */
-#define SIMD_OP_FLAGS_ARCH_SVE 0x01 /* ARM SVE */
+enum simd_op_flags {
+ SIMD_OP_FLAGS_ARCH_NONE = 0x0, /* No SIMD operation */
+ SIMD_OP_FLAGS_ARCH_SVE, /* Arm SVE */
+ SIMD_OP_FLAGS_ARCH_SME, /* Arm SME */
+ SIMD_OP_FLAGS_ARCH_ASE, /* Arm Advanced SIMD */
+};
/* simd predicate flags */
#define SIMD_OP_FLAGS_PRED_PARTIAL 0x01 /* partial predicate */
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 6ce684d68bd61edba2df16806d8a8f18132617db..7198eb3ae560cdac762a7d233d19bd6c70903d39 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -195,8 +195,12 @@ static const char *hist_entry__get_simd_name(struct simd_flags *simd_flags)
{
u64 arch = simd_flags->arch;
- if (arch & SIMD_OP_FLAGS_ARCH_SVE)
+ if (arch == SIMD_OP_FLAGS_ARCH_SVE)
return "SVE";
+ else if (arch == SIMD_OP_FLAGS_ARCH_SME)
+ return "SME";
+ else if (arch == SIMD_OP_FLAGS_ARCH_ASE)
+ return "ASE";
else
return "n/a";
}
--
2.34.1
^ permalink raw reply related
* [PATCH v6 0/4] perf arm_spe: Extend SIMD operations
From: Leo Yan @ 2026-04-10 7:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Namhyung Kim, Jiri Olsa, Ian Rogers,
Adrian Hunter, James Clark, Mark Rutland
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-arm-kernel,
Leo Yan
This series extends SIMD flag for Arm SPE and updated the document.
This version is rebased onto the latest perf-tools-next branch.
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes in v6:
- Rebased on perf-tools-next branch (Namhyung)
- Link to v5: https://lore.kernel.org/r/20260408-perf_support_arm_spev1-3-v5-0-b5bcea6217bb@arm.com
Changes in v5:
- Dropped uAPI header changes for data source fields updating.
- Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-b887bb999f6e@arm.com
Changes in v4 (resend):
- Updated for Ian and James' review tags.
- Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-bb2d143b3860@arm.com
Changes in v4:
- Updated for Ian and James' review tags.
- Rebased on the latest perf-tools-next branch.
- Link to v3: https://lore.kernel.org/r/20251112-perf_support_arm_spev1-3-v3-0-e63c9829f9d9@arm.com
Changes in v3:
- Rebased on the latest perf-tools-next branch.
- Link to v2: https://lore.kernel.org/r/20251017-perf_support_arm_spev1-3-v2-0-2d41e4746e1b@arm.com
Changes in v2:
- Refined to use enums for 2nd operation types. (James)
- Avoided adjustment bit positions for operations. (James)
- Used enum for extended operation type in uapi header and defined
individual bit field for operation details in uaip header. (James)
- Refined SIMD flag definitions. (James)
- Extracted a separate commit for updating tool's header. (James/Arnaldo)
- Minor improvement for printing memory events.
- Rebased on the latest perf-tools-next branch.
- Link to v1: https://lore.kernel.org/r/20250929-perf_support_arm_spev1-3-v1-0-1150b3c83857@arm.com
---
Leo Yan (4):
perf sort: Support sort ASE and SME
perf sort: Sort disabled and full predicated flags
perf report: Update document for SIMD flags
perf arm_spe: Improve SIMD flags setting
tools/perf/Documentation/perf-report.txt | 5 ++++-
tools/perf/util/arm-spe.c | 26 ++++++++++++++++++++------
tools/perf/util/sample.h | 21 ++++++++++++++++-----
tools/perf/util/sort.c | 21 +++++++++++++++------
4 files changed, 55 insertions(+), 18 deletions(-)
---
base-commit: 4cf1f549bbcdfea9c20df52994bb342677472dcd
change-id: 20250820-perf_support_arm_spev1-3-b6efd6fc77b2
Best regards,
--
Leo Yan <leo.yan@arm.com>
^ permalink raw reply
* Re: [PATCH v5 0/4] perf arm_spe: Extend SIMD operations
From: Leo Yan @ 2026-04-10 7:34 UTC (permalink / raw)
To: Namhyung Kim
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Mark Rutland, Arnaldo Carvalho de Melo,
linux-perf-users, linux-arm-kernel
In-Reply-To: <adiGR-A-N1tMzxTE@google.com>
On Thu, Apr 09, 2026 at 10:10:31PM -0700, Namhyung Kim wrote:
> On Wed, Apr 08, 2026 at 10:42:30AM +0100, Leo Yan wrote:
> > This series extends SIMD flag for Arm SPE and updated the document.
> >
> > Since I failed to get perf core maintainer's review for uAPI header
> > updating for data source fields (since last year's Sepetember), this
> > series I dropped uAPI changes and sent only SIMD flag changes, hope
> > it is easier for perf tool maintainer's picking up.
> >
> > Anyway, uAPI patches will be sent out separately.
> >
> > This version is rebased onto the latest perf-tools-next branch.
>
> Unfortunately it doesn't apply due to a recent change. Can you please
> rebase it once again?
Sure, I will send out a new version. Thanks for taking care of this!
^ permalink raw reply
* Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-04-10 7:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: H. Peter Anvin, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Thomas Bogendoerfer,
Vincenzo Frascino, linux-kernel, linux-arm-kernel, linuxppc-dev,
linux-mips
In-Reply-To: <2b1ac7b9-fcc8-4aa3-a0ad-eb37e4bce030@app.fastmail.com>
On Tue, Mar 03, 2026 at 09:50:33PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
> > On 2026-02-27 01:34, Thomas Weißschuh wrote:
> >>>>
> >>> The thing about gettimeofday() and time() is that they don't have
> >>> a 64-bit version and libc implementations are expected to call
> >>> clock_gettime() instead. The result was that there was never a
> >>> patch to turn the off either.
> >>
> >> gettimeofday() is currently the only way to get the timezone of the kernel.
> >> But I guess this is a legacy thing anyways. If you say we should drop it,
> >> let's drop it.
> >>
> >
> > The time zone in the kernel has never worked anyway, as it would require the
> > kernel to contain at least the forward portion of the zoneinfo/tzdata table in
> > order to actually work correctly. The only plausible use of it would be for
> > local time-based filesystems like FAT, but I don't think we bother.
> >
> > A bigger question is whether or not we should omit these from the vDSO
> > completely (potentially causing link failures) or replace them with stubs
> > returning -ENOSYS.
>
> I see no harm in keeping gettimeofday() in the vdso when
> COMPAT_32BIT_TIME is turned on, as existing code will call it
> no matter whether it's in the vdso or the syscall.
We would still always keep them for 64-bit ABIs, right?
> Equally, I see no point in having either version of
> gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
> disabled, as clearly anything calling it would pass incorrect
> data for times past 2038.
Should we also drop the syscalls in these cases?
We will need to keep settimeofday() in some form to support the
timewarping call done by init.
Recap/Proposal:
* Keep the gettimeofday()/time() syscalls when they are y2038 safe or
CONFIG_COMPAT_32BIT_TIME is set.
* Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
set, reject passing any 'tv' argument where it may not be y2038 safe.
* The vDSO functions always mirror the systemcall availability.
Thomas
^ permalink raw reply
* RE: [PATCH v6 03/10] clk: realtek: Introduce a common probe()
From: Yu-Chun Lin [林祐君] @ 2026-04-10 7:22 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_NB8y414PtbtqM@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:50PM +0800, Cheng-Yu Lee wrote:
> > Add rtk_clk_probe() to set up the shared regmap, register clock
> > hardware, and add the clock provider.
> >
> > Additionally, if the "#reset-cells" property is present in the device
> > tree, it creates and registers an auxiliary device using the provided
> aux_name.
> > This allows the dedicated reset driver to bind to this device,
> > enabling both clock and reset drivers to share the same regmap.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Replace direct reset controller initialization with auxiliary device creation.
> > - Add aux_name parameter to rtk_clk_probe() to register the reset auxiliary
> device.
> > - Simplify rtk_clk_desc because reset data is handled entirely by the auxiliary
> reset driver.
> > - In Kconfig, change "depends on RESET_CONTROLLER" to "select
> RESET_CONTROLLER"
> > - Remove unused includes headers and added <linux/auxiliary_bus.h>.
> > ---
> > MAINTAINERS | 1 +
> > drivers/clk/Kconfig | 1 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/realtek/Kconfig | 28 +++++++++++++++
> > drivers/clk/realtek/Makefile | 4 +++ drivers/clk/realtek/common.c |
> > 67 ++++++++++++++++++++++++++++++++++++
> > drivers/clk/realtek/common.h | 37 ++++++++++++++++++++
> > 7 files changed, 139 insertions(+)
> > create mode 100644 drivers/clk/realtek/Kconfig create mode 100644
> > drivers/clk/realtek/Makefile create mode 100644
> > drivers/clk/realtek/common.c create mode 100644
> > drivers/clk/realtek/common.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 8f355896583b..8318156a02b5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22240,6 +22240,7 @@ L: devicetree@vger.kernel.org
> > L: linux-clk@vger.kernel.org
> > S: Supported
> > F: Documentation/devicetree/bindings/clock/realtek*
> > +F: drivers/clk/realtek/*
> > F: drivers/reset/realtek/*
> > F: include/dt-bindings/clock/realtek*
> > F: include/dt-bindings/reset/realtek*
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
> > 3d803b4cf5c1..d60f6415b0a3 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -519,6 +519,7 @@ source "drivers/clk/nuvoton/Kconfig"
> > source "drivers/clk/pistachio/Kconfig"
> > source "drivers/clk/qcom/Kconfig"
> > source "drivers/clk/ralink/Kconfig"
> > +source "drivers/clk/realtek/Kconfig"
> > source "drivers/clk/renesas/Kconfig"
> > source "drivers/clk/rockchip/Kconfig"
> > source "drivers/clk/samsung/Kconfig"
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
> > f7bce3951a30..69b84d1e7bcc 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -140,6 +140,7 @@ obj-$(CONFIG_COMMON_CLK_PISTACHIO)
> += pistachio/
> > obj-$(CONFIG_COMMON_CLK_PXA) += pxa/
> > obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
> > obj-y += ralink/
> > +obj-$(CONFIG_COMMON_CLK_REALTEK) += realtek/
> > obj-y += renesas/
> > obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> > obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/
> > diff --git a/drivers/clk/realtek/Kconfig b/drivers/clk/realtek/Kconfig
> > new file mode 100644 index 000000000000..bc47d3f1c452
> > --- /dev/null
> > +++ b/drivers/clk/realtek/Kconfig
> > @@ -0,0 +1,28 @@
> > +# SPDX-License-Identifier: GPL-2.0-only config COMMON_CLK_REALTEK
> > + bool "Clock driver for Realtek SoCs"
> > + depends on ARCH_REALTEK || COMPILE_TEST
> > + default ARCH_REALTEK
> > + help
> > + Enable the common clock framework infrastructure for Realtek
> > + system-on-chip platforms.
> > +
> > + This provides the base support required by individual Realtek
> > + clock controller drivers to expose clocks to peripheral devices.
> > +
> > + If you have a Realtek-based platform, say Y.
> > +
> > +if COMMON_CLK_REALTEK
> > +
> > +config RTK_CLK_COMMON
> > + tristate "Realtek Clock Common"
> > + select RESET_CONTROLLER
> > + select RESET_RTK_COMMON
>
> select AUXILIARY_BUS ?
>
Ack.
> > + help
> > + Common helper code shared by Realtek clock controller drivers.
> > +
> > + This provides utility functions and data structures used by
> > + multiple Realtek clock implementations, and include integration
> > + with reset controllers where required.
> > +
> > +endif
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile new file mode 100644 index
> > 000000000000..377ec776ee47
> > --- /dev/null
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> > +
> > +clk-rtk-y += common.o
> > diff --git a/drivers/clk/realtek/common.c
> > b/drivers/clk/realtek/common.c new file mode 100644 index
> > 000000000000..c5aea15a3714
> > --- /dev/null
> > +++ b/drivers/clk/realtek/common.c
> > @@ -0,0 +1,67 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2019 Realtek Semiconductor Corporation
>
> If you are making changes here, should the copyrights be updated to include
> 2026?
>
Agreed. Will include 2026.
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include "common.h"
> > +
> > +static int rtk_reset_controller_register(struct device *dev, const
> > +char *aux_name) {
> > + struct auxiliary_device *adev;
> > +
> > + if (!of_property_present(dev->of_node, "#reset-cells"))
> > + return 0;
> > +
> > + adev = devm_auxiliary_device_create(dev, aux_name, NULL);
> > +
> > + if (IS_ERR(adev))
> > + return PTR_ERR(adev);
> > + return 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
> > +int rtk_clk_probe(struct platform_device *pdev, const struct rtk_clk_desc
> *desc,
> > + const char *aux_name)
> > +{
> > + int i, ret;
> > + struct regmap *regmap;
> > + struct device *dev = &pdev->dev;
>
> Put variables in reverse Christmas tree order.
>
Ack.
> > +
> > + regmap = device_node_to_regmap(pdev->dev.of_node);
> > + if (IS_ERR(regmap))
> > + return dev_err_probe(dev, PTR_ERR(regmap), "failed to
> > + get regmap\n");
> > +
> > + for (i = 0; i < desc->num_clks; i++)
> > + desc->clks[i]->regmap = regmap;
> > +
> > + for (i = 0; i < desc->clk_data->num; i++) {
> > + struct clk_hw *hw = desc->clk_data->hws[i];
> > +
> > + if (!hw)
> > + continue;
> > +
> > + ret = devm_clk_hw_register(dev, hw);
> > +
> > + if (ret) {
>
> Remove newline before if.
>
Ack.
> > + dev_warn(dev, "failed to register hw of clk%d:
> %d\n", i,
> > + ret);
> > + desc->clk_data->hws[i] = NULL;
>
> This chunk doesn't take into account probe deferrals.
Will return error here.
Best Regards,
Yu-Chun
>
> Brian
^ permalink raw reply
* [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Bartosz Golaszewski @ 2026-04-10 7:09 UTC (permalink / raw)
To: Frank Wunderlich, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Bartosz Golaszewski
Cc: linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
If the gpio_chip::get_direction() callback is not implemented by the GPIO
controller driver, GPIOLIB emits a warning.
Implement get_direction() for the GPIO part of pinctrl-moore.
Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
Reported-by: Frank Wunderlich <linux@fw-web.de>
Closes: https://lore.kernel.org/all/20260409132724.126258-1-linux@fw-web.de/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/pinctrl/mediatek/pinctrl-moore.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index 70f608347a5f6..071ba849e5322 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -520,6 +520,23 @@ static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio,
return pinctrl_gpio_direction_output(chip, gpio);
}
+static int mtk_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+ const struct mtk_pin_desc *desc;
+ int ret, dir;
+
+ desc = (const struct mtk_pin_desc *)&hw->soc->pins[offset];
+ if (!desc->name)
+ return -ENOTSUPP;
+
+ ret = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, &dir);
+ if (ret)
+ return ret;
+
+ return dir ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
+}
+
static int mtk_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
{
struct mtk_pinctrl *hw = gpiochip_get_data(chip);
@@ -566,6 +583,7 @@ static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
chip->parent = hw->dev;
chip->request = gpiochip_generic_request;
chip->free = gpiochip_generic_free;
+ chip->get_direction = mtk_gpio_get_direction;
chip->direction_input = pinctrl_gpio_direction_input;
chip->direction_output = mtk_gpio_direction_output;
chip->get = mtk_gpio_get;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v9 05/11] drm/fourcc: Add DRM_FORMAT_X403
From: Tomi Valkeinen @ 2026-04-10 6:54 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen
In-Reply-To: <94283390-29cb-4640-b5b4-6a332dd7f2a4@ideasonboard.com>
On 10/04/2026 09:07, Tomi Valkeinen wrote:
> Hi,
>
> On 26/03/2026 16:43, Simon Ser wrote:
>> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com> wrote:
>>
>>> +/*
>>> + * 3 plane non-subsampled (444) YCbCr
>>> + * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
>>> + * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
>>> + * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
>>> + * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
>>> + */
>>> +#define DRM_FORMAT_X403 fourcc_code('X', '4', '0', '3')
>>
>> So, this one is different from the Q family, because Q has padding in
>
> Any idea where the letters (P, Q, S) come from?
>
>> LSB rather than MSB. Speaking of, maybe we should add "LSB aligned" to
>> the doc comment to make that clear?
>
> Yes, I can add that.
>
>> Re-reading the sibling thread about DRM_FORMAT_XV20, sounds like the
>> first digit matches my expectations for sub-sampling. How did you pick
>
> I just used the name in Xilinx's BSP kernel.
>
>> the last two digits? I think I would've expected "30" here rather than
>> "03", since the last two planes are Cb Cr rather than Cr Cb.
>
> Hmm, but X403 is Cb:Cr, and P030 is Cr:Cb, so doesn't 03 make sense
> here? Oh, but Q401 is Cr:Cb, and it's 01...
>
> Now that I look at this... I think I have to go back and do more
> testing. From the Xilinx docs, it looks to me that the XV15/XV20 should
> have the same CrCb order than X403. But the comments in these patches
> say otherwise. I'm pretty sure my tests conformed to the comments here,
> but now I don't feel so sure anymore. It's been more than a year since I
> wrote the tests and properly tested these, so I have to spend a bit time
> to get everything up again.
I think the comments are correct. I guess it depends on which way you
look at this: for P030 etc, starting from the lowest bit, the order is
Cb:Cr. For X403, starting from the lowest plane, the order is Cb:Cr. And
that's probably how Xilinx HW "sees" it and thus they use the same Cb:Cr
order.
But in the comments we describe P030's components starting from the
highest bit, and thus it's Cr:Cb.
>> Has the first "X" letter been picked arbitrarily? It's already used to
>> denote padding in other formats so I wonder if we should pick that
>> instead of, say, "T".
> I didn't invent the name, I just took the naming Xilinx used. I don't
> know the history behind it. I assume the "X" is for Xilinx, but I could
> be wrong here. What would "T" be for? "Tomi"? =)
So... While the Cb:Cr order can be seen both ways, perhaps the Q formats
are a good reference here to follow, and thus it should be "430", not
"403", as you suggest. As for the letter... Anything that's not
currently in use is fine for me =).
Tomi
^ permalink raw reply
* RE: [PATCH v6 02/10] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-04-10 6:49 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安]
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <5dd7ddb50b71de737aae6ad4d11bd28fa52443a9.camel@pengutronix.de>
> On Do, 2026-04-02 at 15:39 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Define the reset operations backed by a regmap-based register
> > interface and prepare the reset controller to be registered through
> > the reset framework.
> >
> > Since the reset controllers on Realtek SoCs often share the same
> > register space with the clock controllers, this common framework is
> > designed to extract the regmap and device tree node from the parent
> > device (e.g., an auxiliary device parent).
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Remove the global header include/linux/reset/realtek.h and use a
> > local common.h instead.
> > - Extract regmap and of_node directly from the parent device.
> > - Remove struct rtk_reset_initdata. Now, pass struct rtk_reset_data
> > directly when calling rtk_reset_controller_add().
> > ---
> > MAINTAINERS | 1 +
> > drivers/reset/Kconfig | 1 +
> > drivers/reset/Makefile | 1 +
> > drivers/reset/realtek/Kconfig | 3 ++
> > drivers/reset/realtek/Makefile | 2 + drivers/reset/realtek/common.c
> > | 85 ++++++++++++++++++++++++++++++++++
> > drivers/reset/realtek/common.h | 29 ++++++++++++
> > 7 files changed, 122 insertions(+)
> > create mode 100644 drivers/reset/realtek/Kconfig create mode 100644
> > drivers/reset/realtek/Makefile create mode 100644
> > drivers/reset/realtek/common.c create mode 100644
> > drivers/reset/realtek/common.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 07e73bf621b0..8f355896583b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22240,6 +22240,7 @@ L: devicetree@vger.kernel.org
> > L: linux-clk@vger.kernel.org
> > S: Supported
> > F: Documentation/devicetree/bindings/clock/realtek*
> > +F: drivers/reset/realtek/*
> > F: include/dt-bindings/clock/realtek*
> > F: include/dt-bindings/reset/realtek*
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > 7ce151f6a7e4..03be1931f264 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -398,6 +398,7 @@ config RESET_ZYNQMP
> >
> > source "drivers/reset/amlogic/Kconfig"
> > source "drivers/reset/hisilicon/Kconfig"
> > +source "drivers/reset/realtek/Kconfig"
> > source "drivers/reset/spacemit/Kconfig"
> > source "drivers/reset/starfive/Kconfig"
> > source "drivers/reset/sti/Kconfig"
> > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > fc0cc99f8514..4407d1630070 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -2,6 +2,7 @@
> > obj-y += core.o
> > obj-y += amlogic/
> > obj-y += hisilicon/
> > +obj-y += realtek/
> > obj-y += spacemit/
> > obj-y += starfive/
> > obj-y += sti/
> > diff --git a/drivers/reset/realtek/Kconfig
> > b/drivers/reset/realtek/Kconfig new file mode 100644 index
> > 000000000000..99a14d355803
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Kconfig
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0-only config RESET_RTK_COMMON
> > + bool
>
> Please make this build-testable with COMPILE_TEST.
>
I will change Kconfig to
config RESET_RTK_COMMON
tristate "Realtek common reset driver" if COMPILE_TEST
help
Common helper code shared by Realtek reset controller drivers.
config COMMON_RESET_RTD1625
tristate "RTD1625 Reset Controller"
depends on ARCH_REALTEK || COMPILE_TEST
select RESET_RTK_COMMON
select AUXILIARY_BUS
help
This enables the reset controller driver for Realtek RTD1625 SoC.
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile new file mode 100644 index
> > 000000000000..b59a3f7f2453
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_RESET_RTK_COMMON) += common.o
> > diff --git a/drivers/reset/realtek/common.c
> > b/drivers/reset/realtek/common.c new file mode 100644 index
> > 000000000000..ea7ff27117e7
> > --- /dev/null
> > +++ b/drivers/reset/realtek/common.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2019 Realtek Semiconductor Corporation */
> > +
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/regmap.h>
> > +#include "common.h"
> > +
> > +static inline struct rtk_reset_data *to_rtk_reset_controller(struct
> > +reset_controller_dev *r) {
> > + return container_of(r, struct rtk_reset_data, rcdev); }
> > +
> > +static inline struct rtk_reset_desc *rtk_reset_get_desc(struct rtk_reset_data
> *data,
> > + unsigned
> long
> > +idx) {
> > + return &data->descs[idx];
> > +}
> > +
> > +static int rtk_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = desc->write_en ? (0x2 << desc->bit) : 0;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->rcdev.nr_resets and data->descs
> > +before
> > + * calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + struct device *parent = dev->parent;
> > +
> > + data->regmap = dev_get_regmap(parent, NULL);
> > + if (!data->regmap)
> > + return -ENODEV;
> > +
> > + data->rcdev.owner = THIS_MODULE;
>
> The rtk_reset_desc arrays used by this code live in the calling module, so it
> would be better to let the caller initialize .owner as well.
>
> It doesn't make a difference in practice, since CONFIG_RESET_RTK_COMMON
> isn't tristate (right now).
>
I will move 'data->rcdev.owner = THIS_MODULE' to the caller.
Best Regards,
Yu-Chun
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 6:27 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adfQ6Tvst3Vd1Mxe@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hello Andrea,
On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > +{
> > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > + u32 value;
> > > +
> > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > + value &= ~PWM_MODE_MASK;
> > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > +
> > > + rp1_pwm_apply_config(chip, pwm);
> >
> > What is the purpose of this call?
>
> To update the configuration on the next PWM strobe in order to avoid
> glitches. I'll add a short comment in the code.
.pwm_free() should not touch the hardware configuration. Changing the
pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
somewhat a grey area. If that saves energy, that's okish. Otherwise
not interfering with the operation of the PWM (e.g. to keep a display on
during kexec or so) is preferred.
> > > +static int rp1_pwm_resume(struct device *dev)
> > > +{
> > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > +
> > > + return clk_prepare_enable(rp1->clk);
> >
> > Hmm, if this fails and then the driver is unbound, the clk operations
> > are not balanced.
>
> I'll add some flags to check if the clock is really enabled or not.
To be honest, I guess that is a problem of several drivers, not only in
drivers/pwm. If this complicates the driver, I guess addressing this
isn't very critical.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Anand Moon @ 2026-04-10 6:26 UTC (permalink / raw)
To: Shawn Lin
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list, Niklas Cassel
In-Reply-To: <0ee54525-928e-a1ce-ec2d-1f85cf15abbc@rock-chips.com>
Hi Shawn,
Thanks for your review comments
On Fri, 10 Apr 2026 at 06:16, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>
> Hi Anand
>
> 在 2026/04/09 星期四 12:49, Anand Moon 写道:
> > During the rk3588_p3phy_init sequence, the driver now explicitly
> > configures each lane's CON0 register to ensure
> > - PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
> > sideband signal requirements.
>
> clkreq_n is now force asserted via controller driver if supports_clkreq
> is not set.
>
> > - Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
> > (Normal Operational State) to ensure the PHY is fully powered and ready
> > for link training.
> >
>
> P0 is the nature state when linking up. I don't know why it should be P0
> before we even don't know whether the device is present.
>
Ok understood. This step resets the lanes to their default state for
initialization.
I’ll collect additional input and verify if any configurations are
still missing.
Thanks
-Anand
^ permalink raw reply
* RE: [PATCH rc v1 4/4] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP in arm_smmu_device_hw_probe()
From: Tian, Kevin @ 2026-04-10 6:22 UTC (permalink / raw)
To: Nicolin Chen, jgg@nvidia.com, will@kernel.org,
robin.murphy@arm.com
Cc: jamien@nvidia.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, smostafa@google.com,
miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <2572aa7fdd3b32eefe48693668c146f4a68ce50c.1775763475.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Friday, April 10, 2026 3:47 AM
> +
> + /*
> + * If SMMU is already active in kdump case, there could be in-flight
> DMA
> + * from devices initiated by the crashed kernel. Mark
> ARM_SMMU_OPT_KDUMP
> + * to let the init functions adopt the crashed kernel's stream table.
> + *
> + * Note that arm_smmu_adopt_strtab() uses memremap that can
> only work on
> + * a coherent SMMU. A non-coherent SMMU has no choice but to
> continue to
> + * abort any in-flight DMA.
> + */
> + if (is_kdump_kernel() && coherent &&
> + (readl_relaxed(smmu->base + ARM_SMMU_CR0) &
> CR0_SMMUEN))
> + smmu->options |= ARM_SMMU_OPT_KDUMP;
> +
> return 0;
A warning message for the non-coherent case?
^ permalink raw reply
* RE: [PATCH rc v1 3/4] iommu/arm-smmu-v3: Retain SMMUEN during kdump device reset
From: Tian, Kevin @ 2026-04-10 6:21 UTC (permalink / raw)
To: Nicolin Chen, jgg@nvidia.com, will@kernel.org,
robin.murphy@arm.com
Cc: jamien@nvidia.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, smostafa@google.com,
miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <c116eba01bcd88ba3b8ba47dc08132c4546e91f5.1775763475.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Friday, April 10, 2026 3:47 AM
>
> /* Clear CR0 and sync (disables SMMU and queue processing) */
> reg = readl_relaxed(smmu->base + ARM_SMMU_CR0);
> if (reg & CR0_SMMUEN) {
> dev_warn(smmu->dev, "SMMU currently enabled!
> Resetting...\n");
move to after the check of kdump kernel
> @@ -5038,6 +5064,11 @@ static int arm_smmu_device_reset(struct
> arm_smmu_device *smmu)
> return ret;
> }
>
> + /*
> + * Disable EVTQ and PRIQ in kdump kernel. The old kernel's CDs and
> page
> + * tables may be corrupted, which could trigger event spamming.
> PRIQ is
> + * also useless since we cannot service page requests during kdump.
> + */
> if (is_kdump_kernel())
> enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
>
then just don't enable them in earlier lines?
^ permalink raw reply
* Re: [PATCH v9 05/11] drm/fourcc: Add DRM_FORMAT_X403
From: Tomi Valkeinen @ 2026-04-10 6:07 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen
In-Reply-To: <jCbIrZ5-fvx73de8DmjQ7xpuEw63kTCQ5p88cdF7yRcUk7uNbE9y0YU7uZbPXNotQAB9y6c0u5n3TrnXckvQ8Oje_J3QGxEwBSr_liQVDK0=@emersion.fr>
Hi,
On 26/03/2026 16:43, Simon Ser wrote:
> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
>
>> +/*
>> + * 3 plane non-subsampled (444) YCbCr
>> + * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
>> + * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
>> + * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
>> + * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
>> + */
>> +#define DRM_FORMAT_X403 fourcc_code('X', '4', '0', '3')
>
> So, this one is different from the Q family, because Q has padding in
Any idea where the letters (P, Q, S) come from?
> LSB rather than MSB. Speaking of, maybe we should add "LSB aligned" to
> the doc comment to make that clear?
Yes, I can add that.
> Re-reading the sibling thread about DRM_FORMAT_XV20, sounds like the
> first digit matches my expectations for sub-sampling. How did you pick
I just used the name in Xilinx's BSP kernel.
> the last two digits? I think I would've expected "30" here rather than
> "03", since the last two planes are Cb Cr rather than Cr Cb.
Hmm, but X403 is Cb:Cr, and P030 is Cr:Cb, so doesn't 03 make sense
here? Oh, but Q401 is Cr:Cb, and it's 01...
Now that I look at this... I think I have to go back and do more
testing. From the Xilinx docs, it looks to me that the XV15/XV20 should
have the same CrCb order than X403. But the comments in these patches
say otherwise. I'm pretty sure my tests conformed to the comments here,
but now I don't feel so sure anymore. It's been more than a year since I
wrote the tests and properly tested these, so I have to spend a bit time
to get everything up again.
> Has the first "X" letter been picked arbitrarily? It's already used to
> denote padding in other formats so I wonder if we should pick that
> instead of, say, "T".
I didn't invent the name, I just took the naming Xilinx used. I don't
know the history behind it. I assume the "X" is for Xilinx, but I could
be wrong here. What would "T" be for? "Tomi"? =)
Tomi
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Anushka Badhe @ 2026-04-10 5:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Anushka Badhe
Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
format.
Update rockchip,cpu from a single I2S controller phandle to a
phandle-array. Add an optional second entry for the SPDIF controller,
as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
---
Changes in v2:
- Fix subject and body: "YAML Schema" -> "DT Schema"
- Fix title: "ROCKCHIP" -> "Rockchip"
- List items for rockchip,cpu with I2S and SPDIF descriptions
- List items for rockchip,codec
- Update descriptions for rockchip,cpu, rockchip,codec and
dmic-wakeup-delay-ms
.../sound/rockchip,rk3399-gru-sound.txt | 22 -------
.../sound/rockchip,rk3399-gru-sound.yaml | 60 +++++++++++++++++++
2 files changed, 60 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
deleted file mode 100644
index 72d3cf4c2606..000000000000
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
-
-Required properties:
-- compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
- connected to the codecs
-- rockchip,codec: The phandle of the audio codecs
-
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified, which means it's required dmic need
- delay for DMIC to ready so that rt5514 can avoid recording before
- DMIC send valid data
-
-Example:
-
-sound {
- compatible = "rockchip,rk3399-gru-sound";
- rockchip,cpu = <&i2s0>;
- rockchip,codec = <&max98357a &rt5514 &da7219>;
- dmic-wakeup-delay-ms = <20>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
new file mode 100644
index 000000000000..e9d13695cc77
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip with MAX98357A/RT5514/DA7219 codecs on GRU boards
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-gru-sound
+
+ rockchip,cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandles to the Rockchip CPU DAI controllers connected to codecs
+ minItems: 1
+ items:
+ - items:
+ - description: Phandle to the Rockchip I2S controllers
+ - items:
+ - description: |
+ Phandle to the Rockchip SPDIF controller. Required when a
+ DisplayPort audio codec is referenced in rockchip,codec
+
+ rockchip,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The phandles of the audio codecs connected to the Rockchip CPU DAI
+ controllers
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ dmic-wakeup-delay-ms:
+ description: |
+ specify delay time (ms) for DMIC ready.
+ If this option is specified, a delay is required for DMIC to get ready
+ so that rt5514 can avoid recording before DMIC sends valid data
+
+required:
+ - compatible
+ - rockchip,cpu
+ - rockchip,codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "rockchip,rk3399-gru-sound";
+ rockchip,cpu = <&i2s0 &spdif>;
+ rockchip,codec = <&max98357a &rt5514 &da7219 &cdn_dp>;
+ dmic-wakeup-delay-ms = <20>;
+ };
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Taniya Das @ 2026-04-10 5:46 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <c7706c41-d855-4ed4-92c4-dca43c8f6d2a@oss.qualcomm.com>
On 4/10/2026 10:18 AM, Jie Gan wrote:
>> + depends on ARM64 || COMPILE_TEST
>> + select CLK_GLYMUR_GCC
>
> Hi,
>
> My bot found a [BUG] here, please ignore it if it's a false positive issue.
>
> CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
>
> - select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
> - On an Eliza system, gcc-glymur.c will never probe (no matching DTS
> node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
> to videocc
> - The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
> resolve at runtime
> - The correct fix is select CLK_ELIZA_GCC, consistent with all other
> Eliza clock controllers
>
Thanks, Jie for pointing out, will fix this.
GCC of ELIZA is already 'y' and Video driver probes as this
GCC_VIDEO_AHB_CLK is kept enabled/critical.
Please find the 'clk_summary' from device.
bi-tcxo-div2-clk 1 1 0 19200000
0 0 50000 Y deviceless
no_connection_id
video_cc_xo_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0c_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_pll0 0 0 0 576000000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0c_div2_div_clk_src 0 0 0
9600000 0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0c_clk 0 0 0 9600000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_div_clk_src 0 0 0 6400000
0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0_clk 0 0 0 6400000
0 0 50000 N deviceless
no_connection_id
video_cc_ahb_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v9 02/11] drm/fourcc: Add DRM_FORMAT_XV20
From: Tomi Valkeinen @ 2026-04-10 5:32 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen,
Dmitry Baryshkov
In-Reply-To: <aocdbgbLe5WhUEOGeLg3P7fRDM8i72H9zBuUnoAjjsuvBLfMPofrPtaUEjII_43KXf1wCbv1G9UutJKMkWLaEcBSnrlUV78Wrhu6l_Z0xi8=@emersion.fr>
Hi,
On 26/03/2026 16:26, Simon Ser wrote:
> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
>
>> XV20 is 2 plane 10 bit per component YCbCr 2x1 subsampled format. XV20
>> is similar to the already existing P030 format, which is 2x2 subsampled.
>
> I don't know for sure the multi-planar YCbCr format name scheme we're
> using, but here are my observations looking at P, Q and S formats:
>
> - The first digit indicates sub-sampling. 0 for 2x2, 2 for 2x1, 4 for none.
> - The two other digits indicate bits for the Y channel, one of 10, 12, 16.
> One exception: Q401 indicates reverse order for Cb and Cr planes when compared
> to Q410.
>
> P030 is a bit of an outlier here since it's the only one with multiple
> Y samples. NV formats are also multi-planar but seem to use a completely
> separate scheme.
>
> Given the above I'd say what would make most sense to me is to use P230:
> keep the last two digits and change the first one to indicate that the
> only difference is the sub-sampling. Does that make sense to you?
I'm fine with that.
Tomi
^ permalink raw reply
* Re: [RFC V1 08/16] arm64/mm: Convert READ_ONCE() as pgdp_get() while accessing PGD
From: Anshuman Khandual @ 2026-04-10 5:30 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm, kasan-dev
In-Reply-To: <e294a87b-392b-4b12-bd12-70c66c793fcd@kernel.org>
On 08/04/26 5:49 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PGD accesses as pgdp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>
> Please mention here why you move p4d_offset_phys/p4d_offset. (same
> applies to other patches)
Will do that.
>
> Do we get additional function calls that might degrade some page table
> walkers?
Sorry did not get it. Are you asking if D128 adds new page table
function paths thus increasing memory access latency etc ?
>
> Same comment regarding BUG_ON.
>
As mentioned earlier it might be better to have a separate change
converting similar BUG_ON() in various arm64 page table helpers.
^ permalink raw reply
* Re: [PATCH v5 0/4] perf arm_spe: Extend SIMD operations
From: Namhyung Kim @ 2026-04-10 5:10 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Mark Rutland, Arnaldo Carvalho de Melo,
linux-perf-users, linux-arm-kernel
In-Reply-To: <20260408-perf_support_arm_spev1-3-v5-0-b5bcea6217bb@arm.com>
On Wed, Apr 08, 2026 at 10:42:30AM +0100, Leo Yan wrote:
> This series extends SIMD flag for Arm SPE and updated the document.
>
> Since I failed to get perf core maintainer's review for uAPI header
> updating for data source fields (since last year's Sepetember), this
> series I dropped uAPI changes and sent only SIMD flag changes, hope
> it is easier for perf tool maintainer's picking up.
>
> Anyway, uAPI patches will be sent out separately.
>
> This version is rebased onto the latest perf-tools-next branch.
Unfortunately it doesn't apply due to a recent change. Can you please
rebase it once again?
Thanks,
Namhyung
>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> Changes in v5:
> - Dropped uAPI header changes for data source fields updating.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-b887bb999f6e@arm.com
>
> Changes in v4 (resend):
> - Updated for Ian and James' review tags.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-bb2d143b3860@arm.com
>
> Changes in v4:
> - Updated for Ian and James' review tags.
> - Rebased on the latest perf-tools-next branch.
> - Link to v3: https://lore.kernel.org/r/20251112-perf_support_arm_spev1-3-v3-0-e63c9829f9d9@arm.com
>
> Changes in v3:
> - Rebased on the latest perf-tools-next branch.
> - Link to v2: https://lore.kernel.org/r/20251017-perf_support_arm_spev1-3-v2-0-2d41e4746e1b@arm.com
>
> Changes in v2:
> - Refined to use enums for 2nd operation types. (James)
> - Avoided adjustment bit positions for operations. (James)
> - Used enum for extended operation type in uapi header and defined
> individual bit field for operation details in uaip header. (James)
> - Refined SIMD flag definitions. (James)
> - Extracted a separate commit for updating tool's header. (James/Arnaldo)
> - Minor improvement for printing memory events.
> - Rebased on the latest perf-tools-next branch.
> - Link to v1: https://lore.kernel.org/r/20250929-perf_support_arm_spev1-3-v1-0-1150b3c83857@arm.com
>
> ---
> Leo Yan (4):
> perf sort: Support sort ASE and SME
> perf sort: Sort disabled and full predicated flags
> perf report: Update document for SIMD flags
> perf arm_spe: Improve SIMD flags setting
>
> tools/perf/Documentation/perf-report.txt | 5 ++++-
> tools/perf/util/arm-spe.c | 26 ++++++++++++++++++++------
> tools/perf/util/sample.h | 21 ++++++++++++++++-----
> tools/perf/util/sort.c | 21 +++++++++++++++------
> 4 files changed, 55 insertions(+), 18 deletions(-)
> ---
> base-commit: dc647eb00969cd213c84d6caee90c480317e857d
> change-id: 20250820-perf_support_arm_spev1-3-b6efd6fc77b2
>
> Best regards,
> --
> Leo Yan <leo.yan@arm.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