* [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
* Re: [PATCH v5 0/4] perf arm_spe: Extend SIMD operations
From: Namhyung Kim @ 2026-04-10 5:06 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>
Hi Leo,
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.
Sure, I believe these SIMD flags are independent from the kernel and
uAPI changes as they are from ARM SPE formats directly.
>
> Anyway, uAPI patches will be sent out separately.
>
> This version is rebased onto the latest perf-tools-next branch.
Thanks for your work,
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
* Re: [RFC V1 07/16] arm64/mm: Convert READ_ONCE() as p4dp_get() while accessing P4D
From: Anshuman Khandual @ 2026-04-10 5:05 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: <238ab437-06b1-43ef-86bb-9341c02040b1@kernel.org>
On 08/04/26 5:47 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based P4D accesses as p4dp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: kasan-dev@googlegroups.com
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>
>
> [...]
>
>> static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a80d06db4de6..16ae11b29f66 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -354,7 +354,7 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
>> {
>> int ret = 0;
>> unsigned long next;
>> - p4d_t p4d = READ_ONCE(*p4dp);
>> + p4d_t p4d = p4dp_get(p4dp);
>> pud_t *pudp;
>>
>> if (p4d_none(p4d)) {
>> @@ -443,7 +443,7 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
>> }
>>
>> do {
>> - p4d_t old_p4d = READ_ONCE(*p4dp);
>> + p4d_t old_p4d = p4dp_get(p4dp);
>>
>> next = p4d_addr_end(addr, end);
>>
>> @@ -453,7 +453,7 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
>> goto out;
>>
>> BUG_ON(p4d_val(old_p4d) != 0 &&
>> - p4d_val(old_p4d) != READ_ONCE(p4d_val(*p4dp)));
>> + p4d_val(old_p4d) != (p4d_val(p4dp_get(p4dp))));
>
> Same here, while at it remove the BUG_ON. (see below)
>
>>
>> phys += next - addr;
>> } while (p4dp++, addr = next, addr != end);
>> @@ -1541,7 +1541,7 @@ static void unmap_hotplug_p4d_range(pgd_t *pgdp, unsigned long addr,
>> do {
>> next = p4d_addr_end(addr, end);
>> p4dp = p4d_offset(pgdp, addr);
>> - p4d = READ_ONCE(*p4dp);
>> + p4d = p4dp_get(p4dp);
>> if (p4d_none(p4d))
>> continue;
>>
>> @@ -1703,7 +1703,7 @@ static void free_empty_p4d_table(pgd_t *pgdp, unsigned long addr,
>> do {
>> next = p4d_addr_end(addr, end);
>> p4dp = p4d_offset(pgdp, addr);
>> - p4d = READ_ONCE(*p4dp);
>> + p4d = p4dp_get(p4dp);
>> if (p4d_none(p4d))
>> continue;
>>
>> @@ -1724,7 +1724,7 @@ static void free_empty_p4d_table(pgd_t *pgdp, unsigned long addr,
>> */
>> p4dp = p4d_offset(pgdp, 0UL);
>> for (i = 0; i < PTRS_PER_P4D; i++) {
>> - if (!p4d_none(READ_ONCE(p4dp[i])))
>> + if (!p4d_none(p4dp_get(p4dp + i)))
>> return;
>> }
>>
>> @@ -2258,4 +2258,21 @@ int pmdp_test_and_clear_young(struct vm_area_struct *vma,
>> }
>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG */
>>
>> +#if CONFIG_PGTABLE_LEVELS > 3
>> +phys_addr_t pud_offset_phys(p4d_t *p4dp, unsigned long addr)
>> +{
>> + p4d_t p4d = p4dp_get(p4dp);
>> +
>> + BUG_ON(!pgtable_l4_enabled());
>
> Heh, while at it, convert that to a VM_WARN_ON_ONCE() or anything else
> that is not a BUG.
>
> I strongly assume CONFIG_DEBUG_VM checks are sufficient.
There are multiple similar BUG_ON() instances
arch/arm64/include/asm/pgtable.h: BUG_ON(!pgtable_l4_enabled());
arch/arm64/include/asm/pgtable.h: BUG_ON(!pgtable_l5_enabled());
arch/arm64/mm/mmu.c: BUG_ON(pmd_val(old_pmd) != 0 &&
arch/arm64/mm/mmu.c: BUG_ON(pud_val(old_pud) != 0 &&
arch/arm64/mm/mmu.c: BUG_ON(p4d_val(old_p4d) != 0 &&
Shall we convert all of them as VM_WARN_ON_ONCE() in a separate patch
as a pre-requisite ?
>
>> +
>> + return p4d_page_paddr(p4d) + pud_index(addr) * sizeof(pud_t);
>> +}
>> +
>
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: Namhyung Kim @ 2026-04-10 4:51 UTC (permalink / raw)
To: James Clark
Cc: Ian Rogers, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <1b40ec9a-a003-4acc-9399-1a8d96fc4e42@linaro.org>
On Wed, Apr 08, 2026 at 09:47:41AM +0100, James Clark wrote:
>
>
> On 07/04/2026 7:26 pm, Ian Rogers wrote:
> > On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
> > >
> > >
> > >
> > > On 02/04/2026 4:26 pm, Ian Rogers wrote:
> > > > On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
> > > > >
> > > > > From the TRM [1], N1 has one IMPDEF event which isn't covered by the
> > > > > common list. Add a framework so that more cores can be added in the
> > > > > future and that the N1 IMPDEF event can be decoded. Also increase the
> > > > > size of the buffer because we're adding more strings and if it gets
> > > > > truncated it falls back to a hex dump only.
> > > > >
> > > > > [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> > > > > Suggested-by: Al Grant <al.grant@arm.com>
> > > > > Signed-off-by: James Clark <james.clark@linaro.org>
> > > > > ---
> > > > > tools/perf/util/arm-spe-decoder/Build | 2 +
> > > > > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
> > > > > .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
> > > > > tools/perf/util/arm-spe.c | 13 ++++---
> > > > > 4 files changed, 54 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
> > > > > index ab500e0efe24..97a298d1e279 100644
> > > > > --- a/tools/perf/util/arm-spe-decoder/Build
> > > > > +++ b/tools/perf/util/arm-spe-decoder/Build
> > > > > @@ -1 +1,3 @@
> > > > > perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
> > > > > +
> > > > > +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
> > > > > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > index c880b0dec3a1..42a7501d4dfe 100644
> > > > > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > @@ -15,6 +15,8 @@
> > > > >
> > > > > #include "arm-spe-pkt-decoder.h"
> > > > >
> > > > > +#include "../../arm64/include/asm/cputype.h"
> > > >
> > > > Sashiko spotted:
> > > > https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
> > > > """
> > > > This isn't a bug, but does this include directive rely on accidental
> > > > path normalization?
> > > >
> > > > The relative path ../../arm64/include/asm/cputype.h does not exist relative
> > > > to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
> > > > -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
> > > >
> > > > Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
> > > > the include path?
> > > > [ ... ]
> > > > """
> > > > I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
> > > > instead just add the extra "../" into the include path.
> > > >
> > >
> > > Do you mean change the #include to this?
> > >
> > > #include "../../../arm64/include/asm/cputype.h"
> > >
> > > I still need to add:
> > >
> > > CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
> > >
> > > To make the this include in cputype.h work:
> > >
> > > #include <asm/sysreg.h>
> > >
> > > Which probably only works because there isn't a sysreg.h on other
> > > architectures. But I'm not sure what the significance of ../../ vs
> > > ../../../ is if either compile? arm-spe.c already does it with ../../
> > > which is what I copied.
> >
> > Hmm.. maybe the path should be
> > "../../../arch/arm64/include/asm/cputype.h". The include preference is
> > for a path relative to the source file and
> > ../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
>
> Up 3 dirs from arm-spe-pkt-decoder.c would be
> "tools/arm64/include/asm/cputype.h" which doesn't exist either unless I'm
> missing something?
>
> If get the compiler to print the path it uses with 3 then it would use the
> x86 uapi include path which doesn't seem any less weird to me:
>
> ...
> In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.c:19:
>
> linux/tools/arch/x86/include/uapi/../../../arm64/include/asm/cputype.h:254:10:
>
>
> > to add an include path and then use a relative path to escape into a
> > higher-level directory. arm-spe.c is a little different as it is one
> > directory higher in the directory layout.
> >
>
> It is one folder higher, but arm-spe.c still relies on adding a special
> include path to CFLAGS_arm-spe.o to make it work. It's not including a real
> path relative to the source either.
>
> Yeah it's a bit horrible but I don't think the asm/ thing combined with
> copying headers from the kernel to tools expected to handle the case where
> we would want to use asm/ stuff for a different arch than the compile one.
> It might not be normal to use relative include paths to escape to higher
> directories, but it's not a normal situation either. I think it's a special
> case for a special scenario. I'm not sure of a better way, but this is
> working for now.
I hope we can cleanup the header inclusion path someday. My idea is
that it always starts from the root of the perf directory. So it'd
include "util/xxx.h" even if the source file is already in util/.
Thanks,
Namhyung
^ permalink raw reply
* Re: [RFC V1 06/16] arm64/mm: Convert READ_ONCE() as pudp_get() while accessing PUD
From: Anshuman Khandual @ 2026-04-10 4:50 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: <b1e1783c-3621-41e4-b65d-38cf66a1124c@kernel.org>
On 08/04/26 5:45 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PUD accesses as pudp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: kasan-dev@googlegroups.com
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>
> I was wondering for a second whether it would be better to structure
> this as "convert READ_ONCE to use pxxxp_get() in fault.c" instead,
> essentially, to touch each file only once.
But will not that create too many patches ?
>
> Anyhow
>
> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
>
Thanks !
^ permalink raw reply
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Jie Gan @ 2026-04-10 4:48 UTC (permalink / raw)
To: Taniya Das, 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: <20260409-eliza_mm_cc_v2-v2-4-bc0c6dd77bc5@oss.qualcomm.com>
On 4/10/2026 2:10 AM, Taniya Das wrote:
> Add support for the video clock controller for video clients to be able
> to request for videocc clocks on Eliza platform.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/videocc-eliza.c | 403 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 413 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 22eb80be60ad3bde897f2c507ac9897951fbb8fe..4b0d40a38a6328fe9c41ebb15ae6821012223920 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -45,6 +45,15 @@ config CLK_ELIZA_TCSRCC
> Support for the TCSR clock controller on Eliza devices.
> Say Y if you want to use peripheral devices such as USB/PCIe/UFS.
>
> +config CLK_ELIZA_VIDEOCC
> + tristate "Eliza Video Clock Controller"
> + 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
> + help
> + Support for the video clock controller on Eliza devices.
> + Say Y if you want to support video devices and functionality such as
> + video encode and decode.
> +
> config CLK_GLYMUR_DISPCC
> tristate "Glymur Display Clock Controller"
> depends on ARM64 || COMPILE_TEST
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index b818fd5af8bfb85a51ee90fdc3baa93af30dc39a..e7e239c5a0d088b2e78354bf421d871a4e4e6d9d 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
> obj-$(CONFIG_CLK_ELIZA_DISPCC) += dispcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_GCC) += gcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_TCSRCC) += tcsrcc-eliza.o
> +obj-$(CONFIG_CLK_ELIZA_VIDEOCC) += videocc-eliza.o
> obj-$(CONFIG_CLK_GFM_LPASS_SM8250) += lpass-gfm-sm8250.o
> obj-$(CONFIG_CLK_GLYMUR_DISPCC) += dispcc-glymur.o
> obj-$(CONFIG_CLK_GLYMUR_GCC) += gcc-glymur.o
> diff --git a/drivers/clk/qcom/videocc-eliza.c b/drivers/clk/qcom/videocc-eliza.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..cb541cfec50c12761251a822e32094e763922cdb
> --- /dev/null
> +++ b/drivers/clk/qcom/videocc-eliza.c
> @@ -0,0 +1,403 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/clock/qcom,eliza-videocc.h>
> +
> +#include "clk-alpha-pll.h"
> +#include "clk-branch.h"
> +#include "clk-pll.h"
> +#include "clk-rcg.h"
> +#include "clk-regmap.h"
> +#include "clk-regmap-divider.h"
> +#include "clk-regmap-mux.h"
> +#include "common.h"
> +#include "gdsc.h"
> +#include "reset.h"
> +
> +enum {
> + DT_BI_TCXO,
> + DT_SLEEP_CLK,
> + DT_AHB_CLK,
> +};
> +
> +enum {
> + P_BI_TCXO,
> + P_SLEEP_CLK,
> + P_VIDEO_CC_PLL0_OUT_MAIN,
> +};
> +
> +static const struct pll_vco lucid_ole_vco[] = {
> + { 249600000, 2300000000, 0 },
> +};
> +
> +/* 576.0 MHz Configuration */
> +static const struct alpha_pll_config video_cc_pll0_config = {
> + .l = 0x1e,
> + .alpha = 0x0,
> + .config_ctl_val = 0x20485699,
> + .config_ctl_hi_val = 0x00182261,
> + .config_ctl_hi1_val = 0x82aa299c,
> + .test_ctl_val = 0x00000000,
> + .test_ctl_hi_val = 0x00000003,
> + .test_ctl_hi1_val = 0x00009000,
> + .test_ctl_hi2_val = 0x00000034,
> + .user_ctl_val = 0x00000000,
> + .user_ctl_hi_val = 0x00000005,
> +};
> +
> +static struct clk_alpha_pll video_cc_pll0 = {
> + .offset = 0x0,
> + .config = &video_cc_pll0_config,
> + .vco_table = lucid_ole_vco,
> + .num_vco = ARRAY_SIZE(lucid_ole_vco),
> + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE],
> + .clkr = {
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_pll0",
> + .parent_data = &(const struct clk_parent_data) {
> + .index = DT_BI_TCXO,
> + },
> + .num_parents = 1,
> + .ops = &clk_alpha_pll_lucid_evo_ops,
> + },
> + },
> +};
> +
> +static const struct parent_map video_cc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_0[] = {
> + { .index = DT_BI_TCXO },
> +};
> +
> +static const struct parent_map video_cc_parent_map_1[] = {
> + { P_BI_TCXO, 0 },
> + { P_VIDEO_CC_PLL0_OUT_MAIN, 1 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_1[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &video_cc_pll0.clkr.hw },
> +};
> +
> +static const struct parent_map video_cc_parent_map_2[] = {
> + { P_SLEEP_CLK, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_2[] = {
> + { .index = DT_SLEEP_CLK },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_ahb_clk_src[] = {
> + F(19200000, P_BI_TCXO, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_ahb_clk_src = {
> + .cmd_rcgr = 0x8018,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_ahb_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_mvs0_clk_src[] = {
> + F(576000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(633000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(720000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1014000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1098000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1113000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1332000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1600000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_mvs0_clk_src = {
> + .cmd_rcgr = 0x8000,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_1,
> + .freq_tbl = ftbl_video_cc_mvs0_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk_src",
> + .parent_data = video_cc_parent_data_1,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_1),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_sleep_clk_src[] = {
> + F(32000, P_SLEEP_CLK, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_sleep_clk_src = {
> + .cmd_rcgr = 0x8110,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_2,
> + .freq_tbl = ftbl_video_cc_sleep_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_sleep_clk_src",
> + .parent_data = video_cc_parent_data_2,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_2),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_rcg2 video_cc_xo_clk_src = {
> + .cmd_rcgr = 0x80f4,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_xo_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0_div_clk_src = {
> + .reg = 0x80ac,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0c_div2_div_clk_src = {
> + .reg = 0x8058,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_div2_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_clk = {
> + .halt_reg = 0x80a0,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x80a0,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x80a0,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_shift_clk = {
> + .halt_reg = 0x8144,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8144,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8144,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_clk = {
> + .halt_reg = 0x804c,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x804c,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0c_div2_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_shift_clk = {
> + .halt_reg = 0x8148,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8148,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8148,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct gdsc video_cc_mvs0c_gdsc = {
> + .gdscr = 0x8034,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0c_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE,
> +};
> +
> +static struct gdsc video_cc_mvs0_gdsc = {
> + .gdscr = 0x808c,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .parent = &video_cc_mvs0c_gdsc.pd,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
> +};
> +
> +static struct clk_regmap *video_cc_eliza_clocks[] = {
> + [VIDEO_CC_AHB_CLK_SRC] = &video_cc_ahb_clk_src.clkr,
> + [VIDEO_CC_MVS0_CLK] = &video_cc_mvs0_clk.clkr,
> + [VIDEO_CC_MVS0_CLK_SRC] = &video_cc_mvs0_clk_src.clkr,
> + [VIDEO_CC_MVS0_DIV_CLK_SRC] = &video_cc_mvs0_div_clk_src.clkr,
> + [VIDEO_CC_MVS0_SHIFT_CLK] = &video_cc_mvs0_shift_clk.clkr,
> + [VIDEO_CC_MVS0C_CLK] = &video_cc_mvs0c_clk.clkr,
> + [VIDEO_CC_MVS0C_DIV2_DIV_CLK_SRC] = &video_cc_mvs0c_div2_div_clk_src.clkr,
> + [VIDEO_CC_MVS0C_SHIFT_CLK] = &video_cc_mvs0c_shift_clk.clkr,
> + [VIDEO_CC_PLL0] = &video_cc_pll0.clkr,
> + [VIDEO_CC_SLEEP_CLK_SRC] = &video_cc_sleep_clk_src.clkr,
> + [VIDEO_CC_XO_CLK_SRC] = &video_cc_xo_clk_src.clkr,
> +};
> +
> +static struct gdsc *video_cc_eliza_gdscs[] = {
> + [VIDEO_CC_MVS0_GDSC] = &video_cc_mvs0_gdsc,
> + [VIDEO_CC_MVS0C_GDSC] = &video_cc_mvs0c_gdsc,
> +};
> +
> +static const struct qcom_reset_map video_cc_eliza_resets[] = {
> + [VIDEO_CC_INTERFACE_BCR] = { 0x80d8 },
> + [VIDEO_CC_MVS0_CLK_ARES] = { 0x80a0, 2 },
> + [VIDEO_CC_MVS0_BCR] = { 0x8088 },
> + [VIDEO_CC_MVS0C_CLK_ARES] = { 0x804c, 2 },
> + [VIDEO_CC_MVS0C_BCR] = { 0x8030 },
> + [VIDEO_CC_XO_CLK_ARES] = { 0x810c, 2 },
> +};
> +
> +static struct clk_alpha_pll *video_cc_eliza_plls[] = {
> + &video_cc_pll0,
> +};
> +
> +static u32 video_cc_eliza_critical_cbcrs[] = {
> + 0x80dc, /* VIDEO_CC_AHB_CLK */
> + 0x8128, /* VIDEO_CC_SLEEP_CLK */
> + 0x810c, /* VIDEO_CC_XO_CLK */
> +};
> +
> +static const struct regmap_config video_cc_eliza_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = 0x9f50,
> + .fast_io = true,
> +};
> +
> +static struct qcom_cc_driver_data video_cc_eliza_driver_data = {
> + .alpha_plls = video_cc_eliza_plls,
> + .num_alpha_plls = ARRAY_SIZE(video_cc_eliza_plls),
> + .clk_cbcrs = video_cc_eliza_critical_cbcrs,
> + .num_clk_cbcrs = ARRAY_SIZE(video_cc_eliza_critical_cbcrs),
> +};
> +
> +static const struct qcom_cc_desc video_cc_eliza_desc = {
> + .config = &video_cc_eliza_regmap_config,
> + .clks = video_cc_eliza_clocks,
> + .num_clks = ARRAY_SIZE(video_cc_eliza_clocks),
> + .resets = video_cc_eliza_resets,
> + .num_resets = ARRAY_SIZE(video_cc_eliza_resets),
> + .gdscs = video_cc_eliza_gdscs,
> + .num_gdscs = ARRAY_SIZE(video_cc_eliza_gdscs),
> + .driver_data = &video_cc_eliza_driver_data,
> +};
> +
> +static const struct of_device_id video_cc_eliza_match_table[] = {
> + { .compatible = "qcom,eliza-videocc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, video_cc_eliza_match_table);
> +
> +static int video_cc_eliza_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, &video_cc_eliza_desc);
> +}
> +
> +static struct platform_driver video_cc_eliza_driver = {
> + .probe = video_cc_eliza_probe,
> + .driver = {
> + .name = "videocc-eliza",
> + .of_match_table = video_cc_eliza_match_table,
> + },
> +};
> +
> +module_platform_driver(video_cc_eliza_driver);
> +
> +MODULE_DESCRIPTION("QTI VIDEOCC Eliza Driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [RFC V1 05/16] arm64/mm: Convert READ_ONCE() as pmdp_get() while accessing PMD
From: Anshuman Khandual @ 2026-04-10 4:48 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: <628a1d9b-cc16-4cf6-8c19-b6ed49af8492@kernel.org>
On 08/04/26 5:41 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PMD accesses as pmdp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>
> You should mention the move from pmdp_test_and_clear_young(), and why it
> is performed.
Sure will do that. Actually there as a build problem while accessing
pmdp_get() from pmdp_test_and_clear_young() while being inside the
header which necessitated this move.
>
> Nothing else jumped at me :)
>
^ permalink raw reply
* RE: [PATCH v1] clk: imx95-blk-ctl: Add func_out_en clock for i.MX9x PCIe
From: Peng Fan @ 2026-04-10 4:35 UTC (permalink / raw)
To: Hongxing Zhu, abelvesa@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com
Cc: linux-clk@vger.kernel.org, imx@nxp.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <20260410031656.2578632-1-hongxing.zhu@nxp.com>
> Subject: [PATCH v1] clk: imx95-blk-ctl: Add func_out_en clock for
> i.MX9x PCIe
>
> When internal PLL clock is used as PCIe REF clock, the BIT6(CREF_EN)
> and
> BIT2(FUNC_OUTPUT_EN) control the PCIE_REF_OUT_CLK.
>
> If the default value of BIT6(CREF_EN)&BIT2(FUNC_OUTPUT_EN) is 1b'1.
> With the typical 100-ohm termination on the board, this results in
> approximately 6mA of power consumption.
>
> When PCIe internal PLL clock is not enabled, these two bits should be
> cleared to 1b'0 to eliminate this power consumption.
>
> Add a func_out_en clock for i.MX9x PCIe to serve as the parent gate
> clock of the CREF_EN (BIT6) gate clock. Both of these two gate clocks
> enable the output of the internal 100MHz differential reference clock.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.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