* Re: [PATCH v20 01/10] power: reset: reboot-mode: Remove devres based allocations
From: Shivendra Pratap @ 2026-04-02 6:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla
Cc: Florian Fainelli, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Kathiravan Thirumoorthy, linux-pm, linux-kernel, linux-arm-kernel,
linux-arm-msm, devicetree, Srinivas Kandagatla
In-Reply-To: <be9db30a-ee64-4457-8722-b9f456911ad3@kernel.org>
On 01-04-2026 20:49, Krzysztof Kozlowski wrote:
> On 04/03/2026 19:03, Shivendra Pratap wrote:
>> Devres APIs are intended for use in drivers, where the managed lifetime
>> of resources is tied directly to the driver attach/detach cycle. In
>> shared subsystem code, there is no guarantee that the subsystem
>> functions will only be called after a driver has been attached, nor that
>> they will not be referenced after the managed resources have been
>> released during driver detach.
>>
>> To ensure correct lifetime handling, avoid using devres-based
>> allocations in the reboot-mode and explicitly handle allocation and
>> cleanup of resources.
>>
>> Fixes: 4fcd504edbf7 ("power: reset: add reboot mode driver")
>
> I don't think this is correct tag.
>
> That commit added code which was a driver, not subsystem level things.
> Using devres, as you pointed out, in platform_driver is correct.
sure. thanks. will remove the Fixes tag.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v5 23/27] clk: mediatek: Add MT8196 disp-ao clock support
From: Jason-JH Lin (林睿祥) @ 2026-04-02 6:30 UTC (permalink / raw)
To: sboyd@kernel.org, robh@kernel.org, Laura Nao, krzk+dt@kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
conor+dt@kernel.org, richardcochran@gmail.com,
matthias.bgg@gmail.com, AngeloGioacchino Del Regno
Cc: Guangjie Song (宋光杰), kernel@collabora.com,
Sirius Wang (王皓昱),
Nancy Lin (林欣螢),
linux-kernel@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Paul-pl Chen (陳柏霖),
linux-mediatek@lists.infradead.org,
Jason-JH Lin (林睿祥),
devicetree@vger.kernel.org, Nicolas Prado,
Singo Chang (張興國), wenst@chromium.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20250829091913.131528-24-laura.nao@collabora.com>
On Fri, 2025-08-29 at 11:19 +0200, Laura Nao wrote:
> Add support for the MT8196 disp-ao clock controller, which provides
> clock gate control for the display system. It is integrated with the
> mtk-mmsys driver, which registers the disp-ao clock driver via
> platform_device_register_data().
>
> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Laura Nao <laura.nao@collabora.com>
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-mt8196-vdisp_ao.c | 80
> ++++++++++++++++++++++
> 2 files changed, 81 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
>
> diff --git a/drivers/clk/mediatek/Makefile
> b/drivers/clk/mediatek/Makefile
> index fe5699411d8b..5b8969ff1985 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -157,7 +157,7 @@ obj-$(CONFIG_COMMON_CLK_MT8196_IMP_IIC_WRAP) +=
> clk-mt8196-imp_iic_wrap.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MCUSYS) += clk-mt8196-mcu.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MDPSYS) += clk-mt8196-mdpsys.o
> obj-$(CONFIG_COMMON_CLK_MT8196_MFGCFG) += clk-mt8196-mfg.o
> -obj-$(CONFIG_COMMON_CLK_MT8196_MMSYS) += clk-mt8196-disp0.o clk-
> mt8196-disp1.o
> +obj-$(CONFIG_COMMON_CLK_MT8196_MMSYS) += clk-mt8196-disp0.o clk-
> mt8196-disp1.o clk-mt8196-vdisp_ao.o
> obj-$(CONFIG_COMMON_CLK_MT8196_PEXTPSYS) += clk-mt8196-pextp.o
> obj-$(CONFIG_COMMON_CLK_MT8196_UFSSYS) += clk-mt8196-ufs_ao.o
> obj-$(CONFIG_COMMON_CLK_MT8365) += clk-mt8365-apmixedsys.o clk-
> mt8365.o
> diff --git a/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> b/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> new file mode 100644
> index 000000000000..fddb69d1c3eb
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt8196-vdisp_ao.c
> @@ -0,0 +1,80 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2025 MediaTek Inc.
> + * Guangjie Song <guangjie.song@mediatek.com>
> + * Copyright (c) 2025 Collabora Ltd.
> + * Laura Nao <laura.nao@collabora.com>
> + */
> +#include <dt-bindings/clock/mediatek,mt8196-clock.h>
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +#include "clk-gate.h"
> +#include "clk-mtk.h"
> +
> +static const struct mtk_gate_regs mm_v_cg_regs = {
> + .set_ofs = 0x104,
> + .clr_ofs = 0x108,
> + .sta_ofs = 0x100,
> +};
> +
> +static const struct mtk_gate_regs mm_v_hwv_regs = {
> + .set_ofs = 0x0030,
> + .clr_ofs = 0x0034,
> + .sta_ofs = 0x2c18,
> +};
> +
> +#define GATE_MM_AO_V(_id, _name, _parent, _shift) { \
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm_v_cg_regs, \
> + .shift = _shift, \
> + .ops = &mtk_clk_gate_ops_setclr, \
> + .flags = CLK_OPS_PARENT_ENABLE | \
> + CLK_IS_CRITICAL, \
> + }
> +
> +#define GATE_HWV_MM_V(_id, _name, _parent, _shift) { \
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm_v_cg_regs, \
> + .hwv_regs = &mm_v_hwv_regs, \
> + .shift = _shift, \
> + .ops = &mtk_clk_gate_hwv_ops_setclr, \
> + .flags = CLK_OPS_PARENT_ENABLE, \
> + }
> +
> +static const struct mtk_gate mm_v_clks[] = {
> + GATE_HWV_MM_V(CLK_MM_V_DISP_VDISP_AO_CONFIG,
> "mm_v_disp_vdisp_ao_config", "disp", 0),
> + GATE_HWV_MM_V(CLK_MM_V_DISP_DPC, "mm_v_disp_dpc", "disp",
> 16),
> + GATE_MM_AO_V(CLK_MM_V_SMI_SUB_SOMM0, "mm_v_smi_sub_somm0",
> "disp", 2),
> +};
> +
> +static const struct mtk_clk_desc mm_v_mcd = {
> + .clks = mm_v_clks,
> + .num_clks = ARRAY_SIZE(mm_v_clks),
> +};
> +
> +static const struct of_device_id of_match_clk_mt8196_vdisp_ao[] = {
> + { .compatible = "mediatek,mt8196-vdisp-ao", .data =
> &mm_v_mcd },
Hi Laura,
We are going to send mtk-mmsys driver for MT8196 recently, but we found
the compatible name is used here.
As your commit message, vdisp-ao is integrated with the mtk-mmsys
driver, which registers the vdisp-ao clock driver via
platform_device_register_data().
Shouldn't this compatible name belong to mmsys driver for MT8196?
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, of_match_clk_mt8196_vdisp_ao);
> +
> +static struct platform_driver clk_mt8196_vdisp_ao_drv = {
> + .probe = mtk_clk_pdev_probe,
> + .remove = mtk_clk_pdev_remove,
> + .driver = {
> + .name = "clk-mt8196-vdisp-ao",
> + .of_match_table = of_match_clk_mt8196_vdisp_ao,
In clk-mt8196-ovl0/ovl1/disp0/disp1.c, they use `.id_table` instead of
`.of_match_table` here. Shouldn't this align to them?
Regards,
Jason-JH Lin
> + },
> +};
> +module_platform_driver(clk_mt8196_vdisp_ao_drv);
> +
> +MODULE_DESCRIPTION("MediaTek MT8196 vdisp_ao clocks driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Krzysztof Kozlowski @ 2026-04-02 6:43 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIB5E66SP7A.110YA5R1OOQHS@linaro.org>
On 02/04/2026 04:19, Alexey Klimov wrote:
> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>> Hi all,
>>>
>>> This patch series introduces support for the APM-to-AP mailbox on the
>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>> co-processor using ACPM.
>>>
>>> The Exynos850 mailbox operates similarly to the existing gs101
>>> implementation, but the register offsets and IRQ mask bits differ.
>>> This series abstracts these differences into platform-specific data
>>> structures matched via the device tree.
>>>
>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>
>>> In theory this can be split into two series with correct dependecies:
>>> device tree node requires clock changes to be merged. The suggestion
>>> is to let this go through Samsung SoC tree with corresponding acks
>>> if it is okay.
>>
>> I don't understand why this cannot be split into two seris
>> *practically*. What is exactly the dependency between mailbox and DTS,
>> that it had to be combined here?
>
> Do you suggest to send 3 single patches with proper dependencies
> description? DT bindings change first, then mailbox change that specifically
> depends on dt-bindings change and then dts update (which will depend on both)?
>
> I thought that mbox driver change depends implicitly on bindings update?
Please don't answer to a question with a question. Actually three
questions. If you cannot give argument why there is a dependency, feels
to me like you send something you do not understand.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v12 0/7] i2c: xiic: use generic device property accessors
From: Abdurrahman Hussain @ 2026-04-02 7:01 UTC (permalink / raw)
To: Andi Shyti, abdurrahman
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Shevchenko, linux-arm-kernel, linux-i2c, linux-kernel,
devicetree, Andrew Lunn, Jonathan Cameron
In-Reply-To: <ac2r9m9mSMZxgHwN@zenone.zhora.eu>
On Wed Apr 1, 2026 at 4:41 PM PDT, Andi Shyti wrote:
>> Abdurrahman Hussain (7):
>> i2c: xiic: switch to devres managed APIs
>> i2c: xiic: remove duplicate error message
>> i2c: xiic: switch to generic device property accessors
>> i2c: xiic: cosmetic cleanup
>> i2c: xiic: cosmetic: use resource format specifier in debug log
>> i2c: xiic: use numbered adapter registration
>> i2c: xiic: skip input clock setup on non-OF systems
>
> Good job Abdurrahman, thanks for following up in all the rounds
> of reviews. I finally merged your patch in i2c/i2c-host.
>
> Thanks,
> Andi
Thank you for merging the changes, Andi. I would also like to express my
appreciation to all reviewers for their valuable feedback and patience
throughout the review process.
Best regards,
Abdurrahman
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Ankur Arora @ 2026-04-02 7:01 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf, arnd,
catalin.marinas, will, peterz, akpm, mark.rutland, harisokn, cl,
ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, joao.m.martins, boris.ostrovsky,
konrad.wilk
In-Reply-To: <20260316013651.3225328-1-ankur.a.arora@oracle.com>
Ankur Arora <ankur.a.arora@oracle.com> writes:
> Hi,
>
> This series adds waited variants of the smp_cond_load() primitives:
> smp_cond_load_relaxed_timeout(), and smp_cond_load_acquire_timeout().
>
> With this version, the main remaining things are:
>
> - Review by PeterZ of the new interface tif_need_resched_relaxed_wait()
> (patch 11, "sched: add need-resched timed wait interface").
>
> - Review of the BPF changes. This version simplifies the rqspinlock
> changes by reusing the original error handling path
> (patches 9, 10 "bpf/rqspinlock: switch check_timeout() to a clock
> interface", "bpf/rqspinlock: Use smp_cond_load_acquire_timeout()").
>
> - Review of WFET handling. (patch 4, "arm64: support WFET in
> smp_cond_load_relaxed_timeout()").
Received Acks/R-bys for the two above.
Will send out an updated v11 which adds a testcase and a comment
mentioning that smp_cond_load_*_timeout on MMIO addresses might
break in interesting platform specific ways.
Thanks
Ankur
> The new interfaces are meant for contexts where you want to wait on a
> condition variable for a finite duration. This is easy enough to do with
> a loop around cpu_relax(). There are, however, architectures (ex. arm64)
> that allow waiting on a cacheline instead.
>
> So, these interfaces handle a mixture of spin/wait with a
> smp_cond_load() thrown in. The interfaces are:
>
> smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
>
> The parameters, time_expr, timeout determine when to bail out.
>
> Also add tif_need_resched_relaxed_wait() which wraps the pattern used
> in poll_idle() and abstracts out details of the interface and those
> of the scheduler.
>
> In addition add atomic_cond_read_*_timeout(), atomic64_cond_read_*_timeout(),
> and atomic_long wrappers to the interfaces.
>
> Finally update poll_idle() and resilient queued spinlocks to use them.
>
> Changelog:
> v9 [9]:
> - s/@cond/@cond_expr/ (Randy Dunlap)
> - Clarify that SMP_TIMEOUT_POLL_COUNT is only around memory
> addresses. (David Laight)
> - Add the missing config ARCH_HAS_CPU_RELAX in arch/arm64/Kconfig.
> (Catalin Marinas).
> - Switch to arch_counter_get_cntvct_stable() (via __delay_cycles())
> in the cmpwait path instead of using arch_timer_read_counter().
> (Catalin Marinas)
>
> v8 [0]:
> - Defer evaluation of @time_expr_ns to when we hit the slowpath.
> (comment from Alexei Starovoitov).
>
> - Mention that cpu_poll_relax() is better than raw CPU polling
> only where ARCH_HAS_CPU_RELAX is defined.
> - also define ARCH_HAS_CPU_RELAX for arm64.
> (Came out of a discussion with Will Deacon.)
>
> - Split out WFET and WFE handling. I was doing both of these
> in a common handler.
> (From Will Deacon and in an earlier revision by Catalin Marinas.)
>
> - Add mentions of atomic_cond_read_{relaxed,acquire}(),
> atomic_cond_read_{relaxed,acquire}_timeout() in
> Documentation/atomic_t.txt.
>
> - Use the BIT() macro to do the checking in tif_bitset_relaxed_wait().
>
> - Cleanup unnecessary assignments, casts etc in poll_idle().
> (From Rafael Wysocki.)
>
> - Fixup warnings from kernel build robot
>
>
> v7 [1]:
> - change the interface to separately provide the timeout. This is
> useful for supporting WFET and similar primitives which can do
> timed waiting (suggested by Arnd Bergmann).
>
> - Adapting rqspinlock code to this changed interface also
> necessitated allowing time_expr to fail.
> - rqspinlock changes to adapt to the new smp_cond_load_acquire_timeout().
>
> - add WFET support (suggested by Arnd Bergmann).
> - add support for atomic-long wrappers.
> - add a new scheduler interface tif_need_resched_relaxed_wait() which
> encapsulates the polling logic used by poll_idle().
> - interface suggested by (Rafael J. Wysocki).
>
>
> v6 [2]:
> - fixup missing timeout parameters in atomic64_cond_read_*_timeout()
> - remove a race between setting of TIF_NEED_RESCHED and the call to
> smp_cond_load_relaxed_timeout(). This would mean that dev->poll_time_limit
> would be set even if we hadn't spent any time waiting.
> (The original check compared against local_clock(), which would have been
> fine, but I was instead using a cheaper check against _TIF_NEED_RESCHED.)
> (Both from meta-CI bot)
>
>
> v5 [3]:
> - use cpu_poll_relax() instead of cpu_relax().
> - instead of defining an arm64 specific
> smp_cond_load_relaxed_timeout(), just define the appropriate
> cpu_poll_relax().
> - re-read the target pointer when we exit due to the time-check.
> - s/SMP_TIMEOUT_SPIN_COUNT/SMP_TIMEOUT_POLL_COUNT/
> (Suggested by Will Deacon)
>
> - add atomic_cond_read_*_timeout() and atomic64_cond_read_*_timeout()
> interfaces.
> - rqspinlock: use atomic_cond_read_acquire_timeout().
> - cpuidle: use smp_cond_load_relaxed_tiemout() for polling.
> (Suggested by Catalin Marinas)
>
> - rqspinlock: define SMP_TIMEOUT_POLL_COUNT to be 16k for non arm64
>
>
> v4 [4]:
> - naming change 's/timewait/timeout/'
> - resilient spinlocks: get rid of res_smp_cond_load_acquire_waiting()
> and fixup use of RES_CHECK_TIMEOUT().
> (Both suggested by Catalin Marinas)
>
> v3 [5]:
> - further interface simplifications (suggested by Catalin Marinas)
>
> v2 [6]:
> - simplified the interface (suggested by Catalin Marinas)
> - get rid of wait_policy, and a multitude of constants
> - adds a slack parameter
> This helped remove a fair amount of duplicated code duplication and in
> hindsight unnecessary constants.
>
> v1 [7]:
> - add wait_policy (coarse and fine)
> - derive spin-count etc at runtime instead of using arbitrary
> constants.
>
> Haris Okanovic tested v4 of this series with poll_idle()/haltpoll patches. [8]
>
> Comments appreciated!
>
> Thanks
> Ankur
>
> [0] https://lore.kernel.org/lkml/20251215044919.460086-1-ankur.a.arora@oracle.com/
> [1] https://lore.kernel.org/lkml/20251028053136.692462-1-ankur.a.arora@oracle.com/
> [2] https://lore.kernel.org/lkml/20250911034655.3916002-1-ankur.a.arora@oracle.com/
> [3] https://lore.kernel.org/lkml/20250911034655.3916002-1-ankur.a.arora@oracle.com/
> [4] https://lore.kernel.org/lkml/20250829080735.3598416-1-ankur.a.arora@oracle.com/
> [5] https://lore.kernel.org/lkml/20250627044805.945491-1-ankur.a.arora@oracle.com/
> [6] https://lore.kernel.org/lkml/20250502085223.1316925-1-ankur.a.arora@oracle.com/
> [7] https://lore.kernel.org/lkml/20250203214911.898276-1-ankur.a.arora@oracle.com/
> [8] https://lore.kernel.org/lkml/2cecbf7fb23ee83a4ce027e1be3f46f97efd585c.camel@amazon.com/
> [9] https://lore.kernel.org/lkml/20260209023153.2661784-1-ankur.a.arora@oracle.com/
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: bpf@vger.kernel.org
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-pm@vger.kernel.org
>
> Ankur Arora (12):
> asm-generic: barrier: Add smp_cond_load_relaxed_timeout()
> arm64: barrier: Support smp_cond_load_relaxed_timeout()
> arm64/delay: move some constants out to a separate header
> arm64: support WFET in smp_cond_load_relaxed_timeout()
> arm64: rqspinlock: Remove private copy of
> smp_cond_load_acquire_timewait()
> asm-generic: barrier: Add smp_cond_load_acquire_timeout()
> atomic: Add atomic_cond_read_*_timeout()
> locking/atomic: scripts: build atomic_long_cond_read_*_timeout()
> bpf/rqspinlock: switch check_timeout() to a clock interface
> bpf/rqspinlock: Use smp_cond_load_acquire_timeout()
> sched: add need-resched timed wait interface
> cpuidle/poll_state: Wait for need-resched via
> tif_need_resched_relaxed_wait()
>
> Documentation/atomic_t.txt | 14 +++--
> arch/arm64/Kconfig | 3 +
> arch/arm64/include/asm/barrier.h | 23 +++++++
> arch/arm64/include/asm/cmpxchg.h | 62 +++++++++++++++----
> arch/arm64/include/asm/delay-const.h | 27 +++++++++
> arch/arm64/include/asm/rqspinlock.h | 85 --------------------------
> arch/arm64/lib/delay.c | 15 ++---
> drivers/cpuidle/poll_state.c | 21 +------
> drivers/soc/qcom/rpmh-rsc.c | 8 +--
> include/asm-generic/barrier.h | 90 ++++++++++++++++++++++++++++
> include/linux/atomic.h | 10 ++++
> include/linux/atomic/atomic-long.h | 18 +++---
> include/linux/sched/idle.h | 29 +++++++++
> kernel/bpf/rqspinlock.c | 77 +++++++++++++++---------
> scripts/atomic/gen-atomic-long.sh | 16 +++--
> 15 files changed, 320 insertions(+), 178 deletions(-)
> create mode 100644 arch/arm64/include/asm/delay-const.h
--
ankur
^ permalink raw reply
* Re: [PATCH 15/33] rust: rust_is_available: remove warning for 0.66.[01] buggy versions
From: Miguel Ojeda @ 2026-04-02 7:12 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, moderated for non-subscribers,
Alexandre Ghiti, linux-riscv, nouveau, dri-devel, Rae Moar,
linux-kselftest, kunit-dev, Nick Desaulniers, Bill Wendling,
Justin Stitt, llvm, linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <DHHWO582XLXH.1DU3CO41F1PV7@garyguo.net>
On Wed, Apr 1, 2026 at 4:58 PM Gary Guo <gary@garyguo.net> wrote:
>
> The scripts/rust_is_available.sh change looks correct to me, although I couldn't
> get scripts/rust_is_available_test.py to run on NixOS.
>
> Looks like it filtered out PATH but uses /usr/bin/env to find python binary? For
> obvious reasons that will only work if python is located /usr/bin/python.
Yeah, the script has some assumptions on it (e.g. it also assumes
`dash` behavior vs. `bash` in a couple tests which I should relax
too). Happy to change that.
Thanks for testing it :)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
From: Maulik Shah (mkshah) @ 2026-04-02 7:15 UTC (permalink / raw)
To: Bjorn Andersson, Manivannan Sadhasivam
Cc: mark.rutland, lpieralisi, bjorn.andersson, konrad.dybcio, mani,
linux-arm-kernel, linux-kernel, Konrad Dybcio, Konrad Dybcio,
Sudeep Holla, linux-arm-msm
In-Reply-To: <acrdFfk8al80dynq@baldur>
On 3/31/2026 2:18 AM, Bjorn Andersson wrote:
> On Wed, Dec 31, 2025 at 09:51:26PM +0530, Manivannan Sadhasivam wrote:
>> From: Konrad Dybcio <konradybcio@kernel.org>
>>
>> PSCI specification defines the SYSTEM_SUSPEND feature which enables the
>> firmware to implement the suspend to RAM (S2RAM) functionality by
>> transitioning the system to a deeper low power state. When the system
>> enters such state, the power to the peripheral devices might be removed.
>
> What is the actual extent of "peripheral devices" in this definition?
>
>> So
>> the respective device drivers must prepare for the possible removal of the
>> power by performing actions such as shutting down or resetting the device
>> in their system suspend callbacks.
>>
>
> Our typical interpretation of this state is that IP-blocks might be
> non-functional during this time, but typically some state is retained.
>
> Will the acceptance of this patch result in that we in the Qualcomm case
> should start accepting/writing patches that implement save/restore of
> state that is generally retained throughout the drivers - in the name of
> "power might be removed"?
>
>> The Linux PM framework allows the platform drivers to convey this info to
>> device drivers by calling the pm_set_suspend_via_firmware() and
>> pm_set_resume_via_firmware() APIs.
>>
>> Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
>> mentioned APIs in the psci_system_suspend_begin() and
>> psci_system_suspend_enter() callbacks.
>>
>
> With the right interpretation of what this means for us, I think this
> patch looks good - but as we've discussed, I'm a bit worried about how
> to deal with the alternative interpretations.
>
> Specifically, if we fully adopt "power might be removed", we should to
> take actions which will prevent a typical Qualcomm system from waking up
> from sleep again.
The "power might be removed" not necessarily indicate that devices/ peripherals
should remove the wake up capability of interrupts in order to prevent waking up
from sleep.
The hibernation + suspend-to-ram is one such example, where "power might
be removed" but devices may still leave the wake up interrupts enabled.
Pasting from commit 62c552ccc3ed ("PM / Hibernate: Enable suspend to both for in-kernel hibernation.")
| It is often useful to suspend to memory after hibernation image has been
| written to disk. If the battery runs out or power is otherwise lost, the
| computer will resume from the hibernated image. If not, it will resume
| from memory
Which can be interpreted as wake up interrupt should be able to wake from suspend-to-ram state
"to the point until the power is cut off or battery runs out".
And in order to do so, wake up capable interrupts should be left enabled in HW,
for interrupt controllers like GIC (and PDC in Qualcomm SoC cases) to support wake up.
Adding Cc: linux-arm-msm for better visibility.
Thanks,
Maulik
>
> Regards,
> Bjorn
>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>> [mani: reworded the description to be more elaborative]
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>> ---
>>
>> This patch was part of an old series that didn't make it to mainline due to
>> objections in the binding and exposing CPU_SUSPEND as S2RAM patches:
>> https://lore.kernel.org/all/20241028-topic-cpu_suspend_s2ram-v1-0-9fdd9a04b75c@oss.qualcomm.com/
>>
>> But this patch on its own is useful for platforms implementing the S2RAM
>> feature in PSCI firmware. So I picked it up, tested on Qcom X1E T14s and
>> resending it.
>>
>> drivers/firmware/psci/psci.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
>> index 38ca190d4a22..e73bae6cb23a 100644
>> --- a/drivers/firmware/psci/psci.c
>> +++ b/drivers/firmware/psci/psci.c
>> @@ -539,12 +539,22 @@ static int psci_system_suspend(unsigned long unused)
>>
>> static int psci_system_suspend_enter(suspend_state_t state)
>> {
>> + pm_set_resume_via_firmware();
>> +
>> return cpu_suspend(0, psci_system_suspend);
>> }
>>
>> +static int psci_system_suspend_begin(suspend_state_t state)
>> +{
>> + pm_set_suspend_via_firmware();
>> +
>> + return 0;
>> +}
>> +
>> static const struct platform_suspend_ops psci_suspend_ops = {
>> .valid = suspend_valid_only_mem,
>> .enter = psci_system_suspend_enter,
>> + .begin = psci_system_suspend_begin,
>> };
>>
>> static void __init psci_init_system_reset2(void)
>> --
>> 2.48.1
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:16 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
You just repeated the diff. No need, we can read the diff, but what we
cannot read is the hardware you are here describing.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
So you did not test v1. You did not test v2.
Did you finally test this one before sending?
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
>
> diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> new file mode 100644
> index 000000000000..fa757017d66e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell CN20K DDR performance monitor
> +
> +description:
> + Performance Monitoring Unit (PMU) for the DDR controller
> + in Marvell CN20K SoCs.
> +
> +maintainers:
> + - Geetha sowjanya <gakula@marvell.com>
> +
> +properties:
> + compatible:
> + const: marvell,cn20k-ddr-pmu
There is no such thing as marvell,cn20k in upstream. What's that?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:17 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
I forgot:
Filename must match compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:26 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux
In-Reply-To: <e7ec1b928357d1240a962a88dc6ac67fd2c92357.1774958552.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:05:42PM +0200, Nora Schiffer wrote:
> The J722S CPSW3G is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
>
> v2: keep ti,am642-cpsw-nuss as a fallback
> v3: resubmission for net-next, no changes
>
> .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> index a959c1d7e643a..70d25f5ff1cfe 100644
> --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
> @@ -53,13 +53,19 @@ properties:
> "#size-cells": true
>
> compatible:
> - enum:
> - - ti,am642-cpsw-nuss
> - - ti,am654-cpsw-nuss
> - - ti,j7200-cpswxg-nuss
> - - ti,j721e-cpsw-nuss
> - - ti,j721e-cpswxg-nuss
> - - ti,j784s4-cpswxg-nuss
> + oneOf:
> + - items:
s/items/enum/. No need to make it a list, wasn't list before. It is not
making code more readable.
> + - enum:
> + - ti,am642-cpsw-nuss
> + - ti,am654-cpsw-nuss
> + - ti,j7200-cpswxg-nuss
> + - ti,j721e-cpsw-nuss
> + - ti,j721e-cpswxg-nuss
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:27 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <5ac1c52827a1a246584dddb62335f9ce4715eceb.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:22PM +0200, Nora Schiffer wrote:
> The J722S gmii-sel is mostly identical to the AM64's, but additionally
> supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
> fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> index be41b4547ec6d..6e12a75100eb8 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> @@ -47,15 +47,21 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - ti,am3352-phy-gmii-sel
> - - ti,dra7xx-phy-gmii-sel
> - - ti,am43xx-phy-gmii-sel
> - - ti,dm814-phy-gmii-sel
> - - ti,am654-phy-gmii-sel
> - - ti,j7200-cpsw5g-phy-gmii-sel
> - - ti,j721e-cpsw9g-phy-gmii-sel
> - - ti,j784s4-cpsw9g-phy-gmii-sel
> + oneOf:
> + - items:
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:28 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Siddharth Vadapalli, Roger Quadros,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, netdev,
devicetree, linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <b9d6a9322ce4f7dc3363dc00d93ab0256e12a8af.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:21PM +0200, Nora Schiffer wrote:
> The J722S WIZ is mostly identical to the AM64's, but additionally supports
> SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
>
> Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> ---
> .../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> index 3f16ff14484d2..283e3eedc0f31 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> @@ -12,13 +12,19 @@ maintainers:
>
> properties:
> compatible:
> - enum:
> - - ti,j721e-wiz-16g
> - - ti,j721e-wiz-10g
> - - ti,j721s2-wiz-10g
> - - ti,am64-wiz-10g
> - - ti,j7200-wiz-10g
> - - ti,j784s4-wiz-10g
> + oneOf:
> + - items:
Same comments as for netdev patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-02 7:38 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, dri-devel, devicetree,
linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260401-master-v2-1-20d3fbcd19d6@nxp.com>
On Wed, Apr 01, 2026 at 06:19:12PM +0800, Guangliu Ding wrote:
> The GPU instance used on NXP i.MX952 is the Mali‑G310,
> document support for this variant.
>
> A hardware GPU auto clock‑gating mechanism has been introduced,
> enabling GPUMIX to automatically manage the GPU clock. This improves
> overall response time.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> 1 file changed, 1 insertion(+)
Why are you sending next version when the discussion is happening?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/6] dt-bindings: opp: ti-cpu: Add ti,soc-info property
From: Krzysztof Kozlowski @ 2026-04-02 7:39 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole, vishalm, sebin.francis, k-willis
In-Reply-To: <20260401105404.1194717-3-a-kaur@ti.com>
On Wed, Apr 01, 2026 at 04:24:00PM +0530, Akashdeep Kaur wrote:
> Add ti,soc-info property to allow OPP tables to reference the SoC info
> device (chipid) for establishing device link dependencies.
>
> This is used on K3 SoCs (AM625, AM62A7, AM62L3, AM62P5) to ensure proper
> probe ordering between ti-cpufreq and k3-socinfo drivers. The ti-cpufreq
Nope, sorry, DT purpose is not to perform probe ordering.
If I change Linux to load k3-socinfo before ti-cpufreq, then the binding
becomes invalid?
Not a DT property, drop.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 2/2] dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta
In-Reply-To: <20260402-fix-atomic-poll-timeout-regression-v4-0-f30d6a6c13cb@bereza.email>
Rename XILINX_DMA_LOOP_COUNT to XILINX_DMA_POLL_TIMEOUT_US because it is
a timeout value, not a loop count for polling register in microseconds.
No functional changes.
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Signed-off-by: Alex Bereza <alex@bereza.email>
---
drivers/dma/xilinx/xilinx_dma.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 345a738bab2c..253c27fd1a0e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -165,8 +165,8 @@
#define XILINX_DMA_FLUSH_MM2S 2
#define XILINX_DMA_FLUSH_BOTH 1
-/* Delay loop counter to prevent hardware failure */
-#define XILINX_DMA_LOOP_COUNT 1000000
+/* Timeout for polling various registers */
+#define XILINX_DMA_POLL_TIMEOUT_US 1000000
/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
#define XILINX_DMA_POLL_DELAY_US 10
@@ -1336,7 +1336,7 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
val & XILINX_DMA_DMASR_HALTED,
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
}
/**
@@ -1352,7 +1352,7 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
val & XILINX_DMA_DMASR_IDLE,
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
}
/**
@@ -1370,7 +1370,7 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
!(val & XILINX_DMA_DMASR_HALTED),
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
if (err) {
dev_err(chan->dev, "Cannot start channel %p: %x\n",
@@ -1787,7 +1787,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
!(tmp & XILINX_DMA_DMACR_RESET),
XILINX_DMA_POLL_DELAY_US,
- XILINX_DMA_LOOP_COUNT);
+ XILINX_DMA_POLL_TIMEOUT_US);
if (err) {
dev_err(chan->dev, "reset timeout, cr %x, sr %x\n",
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta, Frank Li
Signed-off-by: Alex Bereza <alex@bereza.email>
---
Changes in v4:
- patch 1/2: nothing
- patch 2/2:
- Fix commit message: reword as suggested by Frank Li
<Frank.Li@nxp.com> - thanks!
- Link to v3: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-regression-v3-0-85508f0aedde@bereza.email
Changes in v3:
- patch 1/2:
- Fix commit message: remove blank line between tags
- patch 2/2: nothing
- Link to v2: https://patch.msgid.link/20260401-fix-atomic-poll-timeout-regression-v2-0-68a265e3770f@bereza.email
Changes in v2:
- Fixed the Fixes: tags as suggested by Geert Uytterhoeven
<geert+renesas@glider.be> - thanks!
- Split the renaming of XILINX_DMA_LOOP_COUNT into separate commit
- Link to v1: https://patch.msgid.link/20260331-fix-atomic-poll-timeout-regression-v1-1-5b7bd96eaca0@bereza.email
---
Alex Bereza (2):
dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
dmaengine: xilinx_dma: Rename XILINX_DMA_LOOP_COUNT
drivers/dma/xilinx/xilinx_dma.c | 26 ++++++++++++++++----------
1 file changed, 16 insertions(+), 10 deletions(-)
---
base-commit: b7560798466a07d9c3fb011698e92c335ab28baf
change-id: 20260330-fix-atomic-poll-timeout-regression-4f4e3baf3fd7
Best regards,
--
Alex Bereza <alex@bereza.email>
^ permalink raw reply
* RE: Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-02 7:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260402-axiomatic-ludicrous-panther-7a96d2@quoll>
> On Wed, Apr 01, 2026 at 06:19:12PM +0800, Guangliu Ding wrote:
> > The GPU instance used on NXP i.MX952 is the Mali‑G310, document
> > support for this variant.
> >
> > A hardware GPU auto clock‑gating mechanism has been introduced,
> > enabling GPUMIX to automatically manage the GPU clock. This improves
> > overall response time.
> >
> > Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > ---
> > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> Why are you sending next version when the discussion is happening?
>
I will drop this thread and raise v3 version with final fix. Sorry for inconvenience.
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v4 1/2] dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
From: Alex Bereza @ 2026-04-02 7:46 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Michal Simek, Geert Uytterhoeven,
Ulf Hansson, Arnd Bergmann, Tony Lindgren, Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Alex Bereza,
Suraj Gupta, Frank Li
In-Reply-To: <20260402-fix-atomic-poll-timeout-regression-v4-0-f30d6a6c13cb@bereza.email>
Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
condition that is never fulfilled, the CPU busy-waits for prolonged time
and the timeout triggers only with a massive delay causing a CPU stall.
This happens due to a huge underestimation of wall clock time in
poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
timekeeping in read_poll_timeout_atomic()") changed the behavior to no
longer use ktime_get at the expense of underestimation of wall clock
time which appears to be very large for delay_us=0. Instead of timing
out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
loop in poll_timeout_us_atomic takes) which is in the range of several
minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
value for delay_us. Use delay_us=10 to keep the delay in the hot path of
starting DMA transfers minimal but still avoid CPU stalls in case of
unexpected hardware failures.
One-off measurement with delay_us=0 causes the cpu to busy wait around 7
minutes in the timeout case. After applying this patch with delay_us=10
the measured timeout was 1053428 microseconds which is roughly
equivalent to the expected 1000000 microseconds specified in
XILINX_DMA_LOOP_COUNT.
Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
Fixes: 9495f2648287 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's")
Fixes: 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()")
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Alex Bereza <alex@bereza.email>
---
drivers/dma/xilinx/xilinx_dma.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 02a05f215614..345a738bab2c 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -167,6 +167,8 @@
/* Delay loop counter to prevent hardware failure */
#define XILINX_DMA_LOOP_COUNT 1000000
+/* Delay between polls (avoid a delay of 0 to prevent CPU stalls) */
+#define XILINX_DMA_POLL_DELAY_US 10
/* AXI DMA Specific Registers/Offsets */
#define XILINX_DMA_REG_SRCDSTADDR 0x18
@@ -1332,7 +1334,8 @@ static int xilinx_dma_stop_transfer(struct xilinx_dma_chan *chan)
/* Wait for the hardware to halt */
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- val & XILINX_DMA_DMASR_HALTED, 0,
+ val & XILINX_DMA_DMASR_HALTED,
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
}
@@ -1347,7 +1350,8 @@ static int xilinx_cdma_stop_transfer(struct xilinx_dma_chan *chan)
u32 val;
return xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- val & XILINX_DMA_DMASR_IDLE, 0,
+ val & XILINX_DMA_DMASR_IDLE,
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
}
@@ -1364,7 +1368,8 @@ static void xilinx_dma_start(struct xilinx_dma_chan *chan)
/* Wait for the hardware to start */
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMASR, val,
- !(val & XILINX_DMA_DMASR_HALTED), 0,
+ !(val & XILINX_DMA_DMASR_HALTED),
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
if (err) {
@@ -1780,7 +1785,8 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
/* Wait for the hardware to finish reset */
err = xilinx_dma_poll_timeout(chan, XILINX_DMA_REG_DMACR, tmp,
- !(tmp & XILINX_DMA_DMACR_RESET), 0,
+ !(tmp & XILINX_DMA_DMACR_RESET),
+ XILINX_DMA_POLL_DELAY_US,
XILINX_DMA_LOOP_COUNT);
if (err) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-02 7:57 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <0a951e34b7030e514091d6c0922c5982ae349221.1775090165.git.daniel@makrotopia.org>
On Thu, Apr 02, 2026 at 01:37:02AM +0100, Daniel Golle wrote:
> Add compatible strings for MediaTek SoCs where the hardware random number
> generator is accessed via a vendor-defined Secure Monitor Call (SMC)
> rather than direct MMIO register access:
>
> - mediatek,mt7981-rng
> - mediatek,mt7987-rng
> - mediatek,mt7988-rng
>
> These variants require no reg, clocks, or clock-names properties since
> the RNG hardware is managed by ARM Trusted Firmware-A.
>
> Relax the $nodename pattern to also allow 'rng' in addition to the
> existing 'rng@...' pattern.
>
> Add a second example showing the minimal SMC variant binding.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v2: express compatibilities with fallback
>
> .../devicetree/bindings/rng/mtk-rng.yaml | 28 ++++++++++++++++---
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> index 7e8dc62e5d3a6..34648b53d14c6 100644
> --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> @@ -11,12 +11,13 @@ maintainers:
>
> properties:
> $nodename:
> - pattern: "^rng@[0-9a-f]+$"
> + pattern: "^rng(@[0-9a-f]+)?$"
>
> compatible:
> oneOf:
> - enum:
> - mediatek,mt7623-rng
> + - mediatek,mt7981-rng
> - items:
> - enum:
> - mediatek,mt7622-rng
> @@ -25,6 +26,11 @@ properties:
> - mediatek,mt8365-rng
> - mediatek,mt8516-rng
> - const: mediatek,mt7623-rng
> + - items:
> + - enum:
> + - mediatek,mt7987-rng
> + - mediatek,mt7988-rng
> + - const: mediatek,mt7981-rng
>
> reg:
> maxItems: 1
> @@ -38,9 +44,19 @@ properties:
>
> required:
> - compatible
> - - reg
> - - clocks
> - - clock-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + not:
As requested last time - drop
> + contains:
> + const: mediatek,mt7981-rng
> + then:
missing constraints for mediatek,mt7981-rng. So does it have IO space
and clocks or not?
> + required:
> + - reg
> + - clocks
> + - clock-names
>
> additionalProperties: false
>
> @@ -53,3 +69,7 @@ examples:
> clocks = <&infracfg CLK_INFRA_TRNG>;
> clock-names = "rng";
> };
> + - |
> + rng {
> + compatible = "mediatek,mt7981-rng";
No improvements.
Also, make the example complete since binding claims you have clocks and
reg.
I am not sure it should be even same file, but if you are making it same
file, then make it correct.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Krzysztof Kozlowski @ 2026-04-02 8:01 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-3-ca5ffdff99d4@linaro.org>
On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
> Add mailbox node that describes AP-to-APM mailbox, that can be
> used for communicating with APM co-processor on Exynos850 SoCs.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
What DTS is doing in the middle of the patchset? If there is going to be
resend, then fix the order. If the order is intended, then most likely
NAK but I need somewhere explanation (but I really do not see the need
for it).
Please read submitting patches (both documents).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Florijan Plohl @ 2026-04-02 7:08 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, upstream
Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
---
arch/arm64/boot/dts/freescale/Makefile | 4 +
.../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
.../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
3 files changed, 288 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index bae24b53bce6..8f5b3996b678 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -437,17 +437,21 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-kontron-bl-osm-s.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin.dtb
+imx91-phyboard-segin-peb-av-18-dtbs += imx91-phyboard-segin.dtb imx91-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-nash-jtag-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-jtag.dtbo
imx93-phyboard-nash-peb-wlbt-07-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-peb-wlbt-07.dtbo
imx93-phyboard-nash-pwm-fan-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-pwm-fan.dtbo
imx93-phyboard-segin-peb-av-02-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-av-18-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-segin-peb-eval-01-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-eval-01.dtbo
imx93-phyboard-segin-peb-wlbt-05-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-wlbt-05.dtbo
imx93-phycore-rpmsg-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-segin.dtb imx93-phycore-rpmsg.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-jtag.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-peb-wlbt-07.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-pwm-fan.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-02.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-eval-01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-wlbt-05.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phycore-rpmsg.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..ec6ef2e5a11a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "imx91-pinfunc.h"
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
+ MX91_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
+ MX91_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
+ MX91_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
+ MX91_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA0 0x50e
+ MX91_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA1 0x50e
+ MX91_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA2 0x50e
+ MX91_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA3 0x50e
+ MX91_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA4 0x50e
+ MX91_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA5 0x51e
+ MX91_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA6 0x50e
+ MX91_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA7 0x50e
+ MX91_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA8 0x50e
+ MX91_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA9 0x50e
+ MX91_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
+ MX91_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
+ MX91_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
+ MX91_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
+ MX91_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
+ MX91_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
+ MX91_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
+ MX91_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x11e
+ MX91_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..189b0f0472d2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "imx93-pinfunc.h"
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x50e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x50e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x50e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x50e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x50e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x50e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x50e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x50e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x50e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x51e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x50e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x50e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x50e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x50e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x50e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x50e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x506
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x506
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x506
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x506
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x506
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x506
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x11e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Krzysztof Kozlowski @ 2026-04-02 8:11 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-exynos850-ap2apm-mailbox-v2-2-ca5ffdff99d4@linaro.org>
On Thu, Apr 02, 2026 at 03:20:15AM +0100, Alexey Klimov wrote:
> Exynos850-based platforms support ACPM and has similar workflow
> of communicating with ACPM via mailbox, however mailbox controller
> registers are located at different offsets and writes/reads could be
> different. To distinguish between such different behaviours,
> the registers offsets for Exynos850 and the platform-specific data
> structs are introduced and configuration is described in such structs
> for gs101 and exynos850 based SoCs. Probe routine now selects the
> corresponding platform-specific data via device_get_match_data().
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 10/10] arm64: dts: realtek: Add clock support for RTD1625
From: Yu-Chun Lin @ 2026-04-02 7:39 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260402073957.2742459-1-eleanor.lin@realtek.com>
Add the clock controller nodes and osc27m fixed clock for the
Realtek RTD1625 SoC.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
arch/arm64/boot/dts/realtek/kent.dtsi | 33 +++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index ae006ce24420..4722337a143d 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -26,6 +26,15 @@ timer {
<GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ clocks {
+ osc27m: osc {
+ compatible = "fixed-clock";
+ clock-frequency = <27000000>;
+ clock-output-names = "osc27m";
+ #clock-cells = <0>;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -141,6 +150,14 @@ rbus: bus@98000000 {
#address-cells = <1>;
#size-cells = <1>;
+ cc: clock-controller@0 {
+ compatible = "realtek,rtd1625-crt-clk";
+ reg = <0x0 0x900>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
uart0: serial@7800 {
compatible = "snps,dw-apb-uart";
reg = <0x7800 0x100>;
@@ -150,6 +167,22 @@ uart0: serial@7800 {
reg-shift = <2>;
status = "disabled";
};
+
+ ic: clock-controller@7088 {
+ compatible = "realtek,rtd1625-iso-clk";
+ reg = <0x7088 0x8>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ iso_s_cc: clock-controller@146310 {
+ compatible = "realtek,rtd1625-iso-s-clk";
+ reg = <0x146310 0x8>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
};
gic: interrupt-controller@ff100000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v6 06/10] clk: realtek: Add support for mux clock
From: Yu-Chun Lin @ 2026-04-02 7:39 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin
In-Reply-To: <20260402073957.2742459-1-eleanor.lin@realtek.com>
From: Cheng-Yu Lee <cylee12@realtek.com>
Add a simple regmap-based clk_ops implementation for Realtek mux clocks.
The implementation supports parent selection and rate determination through
regmap-backed register access.
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:
- Add the headers used in c file to follow the "Include What You Use" principle.
---
drivers/clk/realtek/Makefile | 1 +
drivers/clk/realtek/clk-regmap-mux.c | 48 ++++++++++++++++++++++++++++
drivers/clk/realtek/clk-regmap-mux.h | 43 +++++++++++++++++++++++++
3 files changed, 92 insertions(+)
create mode 100644 drivers/clk/realtek/clk-regmap-mux.c
create mode 100644 drivers/clk/realtek/clk-regmap-mux.h
diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
index 74375f8127ac..f90dc57fcfdb 100644
--- a/drivers/clk/realtek/Makefile
+++ b/drivers/clk/realtek/Makefile
@@ -5,4 +5,5 @@ clk-rtk-y += common.o
clk-rtk-y += clk-pll.o
clk-rtk-y += clk-regmap-gate.o
+clk-rtk-y += clk-regmap-mux.o
clk-rtk-y += freq_table.o
diff --git a/drivers/clk/realtek/clk-regmap-mux.c b/drivers/clk/realtek/clk-regmap-mux.c
new file mode 100644
index 000000000000..068b056d61f0
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-mux.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2017 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#include <linux/regmap.h>
+#include <linux/clk-provider.h>
+#include "clk-regmap-mux.h"
+
+static u8 clk_regmap_mux_get_parent(struct clk_hw *hw)
+{
+ struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
+ int num_parents = clk_hw_get_num_parents(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(clkm->clkr.regmap, clkm->mux_ofs, &val);
+ if (ret)
+ return 0;
+
+ val = val >> clkm->shift & clkm->mask;
+
+ if (val >= num_parents)
+ return 0;
+
+ return val;
+}
+
+static int clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
+
+ return regmap_update_bits(clkm->clkr.regmap, clkm->mux_ofs,
+ clkm->mask << clkm->shift, index << clkm->shift);
+}
+
+const struct clk_ops rtk_clk_regmap_mux_ops = {
+ .set_parent = clk_regmap_mux_set_parent,
+ .get_parent = clk_regmap_mux_get_parent,
+ .determine_rate = __clk_mux_determine_rate,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ops, "REALTEK_CLK");
+
+const struct clk_ops rtk_clk_regmap_mux_ro_ops = {
+ .get_parent = clk_regmap_mux_get_parent,
+};
+EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ro_ops, "REALTEK_CLK");
diff --git a/drivers/clk/realtek/clk-regmap-mux.h b/drivers/clk/realtek/clk-regmap-mux.h
new file mode 100644
index 000000000000..cf7ab6a0604c
--- /dev/null
+++ b/drivers/clk/realtek/clk-regmap-mux.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2017 Realtek Semiconductor Corporation
+ * Author: Cheng-Yu Lee <cylee12@realtek.com>
+ */
+
+#ifndef __CLK_REALTEK_CLK_REGMAP_MUX_H
+#define __CLK_REALTEK_CLK_REGMAP_MUX_H
+
+#include "common.h"
+
+struct clk_regmap_mux {
+ struct clk_regmap clkr;
+ int mux_ofs;
+ unsigned int mask;
+ unsigned int shift;
+};
+
+#define __clk_regmap_mux_hw(_p) __clk_regmap_hw(&(_p)->clkr)
+
+#define __CLK_REGMAP_MUX(_name, _parents, _ops, _flags, _ofs, _sft, _mask) \
+ struct clk_regmap_mux _name = { \
+ .clkr.hw.init = \
+ CLK_HW_INIT_PARENTS(#_name, _parents, _ops, _flags), \
+ .mux_ofs = _ofs, \
+ .shift = _sft, \
+ .mask = _mask, \
+ }
+
+#define CLK_REGMAP_MUX(_name, _parents, _flags, _ofs, _sft, _mask) \
+ __CLK_REGMAP_MUX(_name, _parents, &rtk_clk_regmap_mux_ops, _flags, _ofs, \
+ _sft, _mask)
+
+static inline struct clk_regmap_mux *to_clk_regmap_mux(struct clk_hw *hw)
+{
+ struct clk_regmap *clkr = to_clk_regmap(hw);
+
+ return container_of(clkr, struct clk_regmap_mux, clkr);
+}
+
+extern const struct clk_ops rtk_clk_regmap_mux_ops;
+
+#endif /* __CLK_REALTEK_CLK_REGMAP_MUX_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v6 01/10] dt-bindings: clock: Add Realtek RTD1625 Clock & Reset Controller
From: Yu-Chun Lin @ 2026-04-02 7:39 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel, cylee12,
afaerber, jyanchou
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang,
eleanor.lin, Krzysztof Kozlowski
In-Reply-To: <20260402073957.2742459-1-eleanor.lin@realtek.com>
Add DT binding schema for Realtek RTD1625 clock and reset controller
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Co-developed-by: Cheng-Yu Lee <cylee12@realtek.com>
Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v6:
- Add reviewed-by tag from Krzysztof.
- Add Cheng-Yu Lee as maintainer in the binding file.
- Add 'clocks' property.
- Add include/dt-bindings/reset/realtek,rtd1625.h to the MAINTAINERS file.
---
.../bindings/clock/realtek,rtd1625-clk.yaml | 58 ++++++
MAINTAINERS | 10 +
.../dt-bindings/clock/realtek,rtd1625-clk.h | 164 +++++++++++++++++
include/dt-bindings/reset/realtek,rtd1625.h | 171 ++++++++++++++++++
4 files changed, 403 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
create mode 100644 include/dt-bindings/clock/realtek,rtd1625-clk.h
create mode 100644 include/dt-bindings/reset/realtek,rtd1625.h
diff --git a/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
new file mode 100644
index 000000000000..1aceef31e148
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/realtek,rtd1625-clk.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/realtek,rtd1625-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek RTD1625 Clock & Reset Controller
+
+maintainers:
+ - Cheng-Yu Lee <cylee12@realtek.com>
+ - Yu-Chun Lin <eleanor.lin@realtek.com>
+
+description: |
+ The Realtek RTD1625 Clock Controller manages and distributes clock
+ signals to various controllers and implements a Reset Controller for the
+ SoC peripherals.
+
+ Clocks and resets are referenced by unique identifiers, which are defined as
+ preprocessor macros in include/dt-bindings/clock/realtek,rtd1625-clk.h and
+ include/dt-bindings/reset/realtek,rtd1625.h.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-crt-clk
+ - realtek,rtd1625-iso-clk
+ - realtek,rtd1625-iso-s-clk
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#clock-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@98000000 {
+ compatible = "realtek,rtd1625-crt-clk";
+ reg = <0x98000000 0x1000>;
+ clocks = <&osc27m>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index c3fe46d7c4bc..07e73bf621b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22233,6 +22233,16 @@ S: Maintained
F: Documentation/devicetree/bindings/net/dsa/realtek.yaml
F: drivers/net/dsa/realtek/*
+REALTEK SOC CLOCK AND RESET DRIVERS
+M: Cheng-Yu Lee <cylee12@realtek.com>
+M: Yu-Chun Lin <eleanor.lin@realtek.com>
+L: devicetree@vger.kernel.org
+L: linux-clk@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/clock/realtek*
+F: include/dt-bindings/clock/realtek*
+F: include/dt-bindings/reset/realtek*
+
REALTEK SPI-NAND
M: Chris Packham <chris.packham@alliedtelesis.co.nz>
S: Maintained
diff --git a/include/dt-bindings/clock/realtek,rtd1625-clk.h b/include/dt-bindings/clock/realtek,rtd1625-clk.h
new file mode 100644
index 000000000000..61ca652d6880
--- /dev/null
+++ b/include/dt-bindings/clock/realtek,rtd1625-clk.h
@@ -0,0 +1,164 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2025 Realtek Semiconductor Corp.
+ */
+#ifndef __DT_BINDINGS_RTK_CLOCK_RTD1625_H
+#define __DT_BINDINGS_RTK_CLOCK_RTD1625_H
+
+#define RTD1625_CRT_CLK_EN_MISC 0
+#define RTD1625_CRT_CLK_EN_PCIE0 1
+#define RTD1625_CRT_CLK_EN_DIP 2
+#define RTD1625_CRT_CLK_EN_GSPI 3
+#define RTD1625_CRT_CLK_EN_ISO_MISC 5
+#define RTD1625_CRT_CLK_EN_SDS 6
+#define RTD1625_CRT_CLK_EN_HDMI 7
+#define RTD1625_CRT_CLK_EN_GPU 9
+#define RTD1625_CRT_CLK_EN_VE1 10
+#define RTD1625_CRT_CLK_EN_VE2 11
+#define RTD1625_CRT_CLK_EN_MD 18
+#define RTD1625_CRT_CLK_EN_TP 19
+#define RTD1625_CRT_CLK_EN_RCIC 20
+#define RTD1625_CRT_CLK_EN_NF 21
+#define RTD1625_CRT_CLK_EN_EMMC 22
+#define RTD1625_CRT_CLK_EN_SD 23
+#define RTD1625_CRT_CLK_EN_SDIO_IP 24
+#define RTD1625_CRT_CLK_EN_MIPI_CSI 25
+#define RTD1625_CRT_CLK_EN_EMMC_IP 26
+#define RTD1625_CRT_CLK_EN_SDIO 27
+#define RTD1625_CRT_CLK_EN_SD_IP 28
+#define RTD1625_CRT_CLK_EN_TPB 30
+#define RTD1625_CRT_CLK_EN_MISC_SC1 31
+#define RTD1625_CRT_CLK_EN_MISC_I2C_3 32
+#define RTD1625_CRT_CLK_EN_ACPU 33
+#define RTD1625_CRT_CLK_EN_JPEG 34
+#define RTD1625_CRT_CLK_EN_MISC_SC0 37
+#define RTD1625_CRT_CLK_EN_HDMIRX 45
+#define RTD1625_CRT_CLK_EN_HSE 46
+#define RTD1625_CRT_CLK_EN_FAN 49
+#define RTD1625_CRT_CLK_EN_SATA_WRAP_SYS 52
+#define RTD1625_CRT_CLK_EN_SATA_WRAP_SYSH 53
+#define RTD1625_CRT_CLK_EN_SATA_MAC_SYSH 54
+#define RTD1625_CRT_CLK_EN_R2RDSC 55
+#define RTD1625_CRT_CLK_EN_TPC 56
+#define RTD1625_CRT_CLK_EN_PCIE1 57
+#define RTD1625_CRT_CLK_EN_MISC_I2C_4 58
+#define RTD1625_CRT_CLK_EN_MISC_I2C_5 59
+#define RTD1625_CRT_CLK_EN_TSIO 60
+#define RTD1625_CRT_CLK_EN_VE4 61
+#define RTD1625_CRT_CLK_EN_EDP 62
+#define RTD1625_CRT_CLK_EN_TSIO_TRX 63
+#define RTD1625_CRT_CLK_EN_PCIE2 64
+#define RTD1625_CRT_CLK_EN_EARC 66
+#define RTD1625_CRT_CLK_EN_LITE 67
+#define RTD1625_CRT_CLK_EN_MIPI_DSI 68
+#define RTD1625_CRT_CLK_EN_NPUPP 69
+#define RTD1625_CRT_CLK_EN_NPU 70
+#define RTD1625_CRT_CLK_EN_AUCPU0 71
+#define RTD1625_CRT_CLK_EN_AUCPU1 72
+#define RTD1625_CRT_CLK_EN_NSRAM 73
+#define RTD1625_CRT_CLK_EN_HDMITOP 74
+#define RTD1625_CRT_CLK_EN_AUCPU_ISO_NPU 76
+#define RTD1625_CRT_CLK_EN_KEYLADDER 77
+#define RTD1625_CRT_CLK_EN_IFCP_KLM 78
+#define RTD1625_CRT_CLK_EN_IFCP 79
+#define RTD1625_CRT_CLK_EN_MDL_GENPW 80
+#define RTD1625_CRT_CLK_EN_MDL_CHIP 81
+#define RTD1625_CRT_CLK_EN_MDL_IP 82
+#define RTD1625_CRT_CLK_EN_MDLM2M 83
+#define RTD1625_CRT_CLK_EN_MDL_XTAL 84
+#define RTD1625_CRT_CLK_EN_TEST_MUX 85
+#define RTD1625_CRT_CLK_EN_DLA 86
+#define RTD1625_CRT_CLK_EN_TPCW 88
+#define RTD1625_CRT_CLK_EN_GPU_TS_SRC 89
+#define RTD1625_CRT_CLK_EN_VI 91
+#define RTD1625_CRT_CLK_EN_LVDS1 92
+#define RTD1625_CRT_CLK_EN_LVDS2 93
+#define RTD1625_CRT_CLK_EN_AUCPU 94
+#define RTD1625_CRT_CLK_EN_UR1 96
+#define RTD1625_CRT_CLK_EN_UR2 97
+#define RTD1625_CRT_CLK_EN_UR3 98
+#define RTD1625_CRT_CLK_EN_UR4 99
+#define RTD1625_CRT_CLK_EN_UR5 100
+#define RTD1625_CRT_CLK_EN_UR6 101
+#define RTD1625_CRT_CLK_EN_UR7 102
+#define RTD1625_CRT_CLK_EN_UR8 103
+#define RTD1625_CRT_CLK_EN_UR9 104
+#define RTD1625_CRT_CLK_EN_UR_TOP 105
+#define RTD1625_CRT_CLK_EN_MISC_I2C_7 110
+#define RTD1625_CRT_CLK_EN_MISC_I2C_6 111
+#define RTD1625_CRT_CLK_EN_SPI0 112
+#define RTD1625_CRT_CLK_EN_SPI1 113
+#define RTD1625_CRT_CLK_EN_SPI2 114
+#define RTD1625_CRT_CLK_EN_LSADC0 120
+#define RTD1625_CRT_CLK_EN_LSADC1 121
+#define RTD1625_CRT_CLK_EN_ISOMIS_DMA 122
+#define RTD1625_CRT_CLK_EN_DPTX 124
+#define RTD1625_CRT_CLK_EN_NPU_MIPI_CSI 125
+#define RTD1625_CRT_CLK_EN_EDPTX 126
+#define RTD1625_CRT_CLK_HIFI 128
+#define RTD1625_CRT_CLK_NPU_MIPI_CSI 129
+#define RTD1625_CRT_CLK_NPU 130
+#define RTD1625_CRT_CLK_NPU_SYSH 132
+#define RTD1625_CRT_CLK_HIFI_SCPU 133
+#define RTD1625_CRT_CLK_GPU 134
+#define RTD1625_CRT_CLK_GPU2D 135
+#define RTD1625_CRT_CLK_MIPI_DSI_PCLK 136
+#define RTD1625_CRT_CLK_VE1 137
+#define RTD1625_CRT_CLK_VE2 138
+#define RTD1625_CRT_CLK_VE4 139
+#define RTD1625_CRT_CLK_SYS 141
+#define RTD1625_CRT_CLK_SYSH 142
+#define RTD1625_CRT_PLL_SDIO_REF 145
+#define RTD1625_CRT_PLL_CR_REF 146
+#define RTD1625_CRT_PLL_EMMC_REF 147
+#define RTD1625_CRT_CLK_MIS_SC0 148
+#define RTD1625_CRT_CLK_MIS_SC1 149
+#define RTD1625_CRT_PLL_SCPU 150
+#define RTD1625_CRT_PLL_VE1 151
+#define RTD1625_CRT_PLL_DDSA 152
+#define RTD1625_CRT_PLL_PSAUDA1 153
+#define RTD1625_CRT_PLL_PSAUDA2 154
+#define RTD1625_CRT_PLL_BUS 155
+#define RTD1625_CRT_PLL_SDIO 156
+#define RTD1625_CRT_PLL_SDIO_VP0 157
+#define RTD1625_CRT_PLL_SDIO_VP1 158
+#define RTD1625_CRT_PLL_DCSB 159
+#define RTD1625_CRT_PLL_GPU 160
+#define RTD1625_CRT_PLL_NPU 161
+#define RTD1625_CRT_PLL_VE2 162
+#define RTD1625_CRT_PLL_HIFI 163
+#define RTD1625_CRT_PLL_SD 164
+#define RTD1625_CRT_PLL_SD_VP0 165
+#define RTD1625_CRT_PLL_SD_VP1 166
+#define RTD1625_CRT_PLL_EMMC 167
+#define RTD1625_CRT_PLL_EMMC_VP0 168
+#define RTD1625_CRT_PLL_EMMC_VP1 169
+#define RTD1625_CRT_PLL_ACPU 170
+#define RTD1625_CRT_CLK_DET 171
+
+#define RTD1625_ISO_CLK_EN_USB_P4 0
+#define RTD1625_ISO_CLK_EN_USB_P3 1
+#define RTD1625_ISO_CLK_EN_MISC_CEC0 2
+#define RTD1625_ISO_CLK_EN_CBUSRX_SYS 3
+#define RTD1625_ISO_CLK_EN_CBUSTX_SYS 4
+#define RTD1625_ISO_CLK_EN_CBUS_SYS 5
+#define RTD1625_ISO_CLK_EN_CBUS_OSC 6
+#define RTD1625_ISO_CLK_EN_MISC_UR0 8
+#define RTD1625_ISO_CLK_EN_I2C0 9
+#define RTD1625_ISO_CLK_EN_I2C1 10
+#define RTD1625_ISO_CLK_EN_ETN_250M 11
+#define RTD1625_ISO_CLK_EN_ETN_SYS 12
+#define RTD1625_ISO_CLK_EN_USB_DRD 13
+#define RTD1625_ISO_CLK_EN_USB_HOST 14
+#define RTD1625_ISO_CLK_EN_USB_U3_HOST 15
+#define RTD1625_ISO_CLK_EN_USB 16
+#define RTD1625_ISO_CLK_EN_VTC 17
+#define RTD1625_ISO_CLK_EN_MISC_VFD 18
+
+#define RTD1625_ISO_S_CLK_EN_ISOM_MIS 0
+#define RTD1625_ISO_S_CLK_EN_ISOM_GPIOM 1
+#define RTD1625_ISO_S_CLK_EN_TIMER7 2
+#define RTD1625_ISO_S_CLK_EN_IRDA 3
+#define RTD1625_ISO_S_CLK_EN_UR10 4
+
+#endif /* __DT_BINDINGS_RTK_CLOCK_RTD1625_H */
diff --git a/include/dt-bindings/reset/realtek,rtd1625.h b/include/dt-bindings/reset/realtek,rtd1625.h
new file mode 100644
index 000000000000..31e7fa66ef31
--- /dev/null
+++ b/include/dt-bindings/reset/realtek,rtd1625.h
@@ -0,0 +1,171 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2025 Realtek Semiconductor Corp.
+ */
+
+#ifndef __DT_BINDINGS_RTK_RESET_RTD1625_H
+#define __DT_BINDINGS_RTK_RESET_RTD1625_H
+
+#define RTD1625_CRT_RSTN_MISC 0
+#define RTD1625_CRT_RSTN_DIP 1
+#define RTD1625_CRT_RSTN_GSPI 2
+#define RTD1625_CRT_RSTN_SDS 3
+#define RTD1625_CRT_RSTN_SDS_REG 4
+#define RTD1625_CRT_RSTN_SDS_PHY 5
+#define RTD1625_CRT_RSTN_GPU2D 6
+#define RTD1625_CRT_RSTN_DC_PHY 7
+#define RTD1625_CRT_RSTN_DCPHY_CRT 8
+#define RTD1625_CRT_RSTN_LSADC 9
+#define RTD1625_CRT_RSTN_SE 10
+#define RTD1625_CRT_RSTN_DLA 11
+#define RTD1625_CRT_RSTN_JPEG 12
+#define RTD1625_CRT_RSTN_SD 13
+#define RTD1625_CRT_RSTN_SDIO 14
+#define RTD1625_CRT_RSTN_PCR_CNT 15
+#define RTD1625_CRT_RSTN_PCIE0_STITCH 16
+#define RTD1625_CRT_RSTN_PCIE0_PHY 17
+#define RTD1625_CRT_RSTN_PCIE0 18
+#define RTD1625_CRT_RSTN_PCIE0_CORE 19
+#define RTD1625_CRT_RSTN_PCIE0_POWER 20
+#define RTD1625_CRT_RSTN_PCIE0_NONSTICH 21
+#define RTD1625_CRT_RSTN_PCIE0_PHY_MDIO 22
+#define RTD1625_CRT_RSTN_PCIE0_SGMII_MDIO 23
+#define RTD1625_CRT_RSTN_VO2 24
+#define RTD1625_CRT_RSTN_MISC_SC0 25
+#define RTD1625_CRT_RSTN_MD 26
+#define RTD1625_CRT_RSTN_LVDS1 27
+#define RTD1625_CRT_RSTN_LVDS2 28
+#define RTD1625_CRT_RSTN_MISC_SC1 29
+#define RTD1625_CRT_RSTN_I2C_3 30
+#define RTD1625_CRT_RSTN_FAN 31
+#define RTD1625_CRT_RSTN_TVE 32
+#define RTD1625_CRT_RSTN_AIO 33
+#define RTD1625_CRT_RSTN_VO 34
+#define RTD1625_CRT_RSTN_MIPI_CSI 35
+#define RTD1625_CRT_RSTN_HDMIRX 36
+#define RTD1625_CRT_RSTN_HDMIRX_WRAP 37
+#define RTD1625_CRT_RSTN_HDMI 38
+#define RTD1625_CRT_RSTN_DISP 39
+#define RTD1625_CRT_RSTN_SATA_PHY_POW1 40
+#define RTD1625_CRT_RSTN_SATA_PHY_POW0 41
+#define RTD1625_CRT_RSTN_SATA_MDIO1 42
+#define RTD1625_CRT_RSTN_SATA_MDIO0 43
+#define RTD1625_CRT_RSTN_SATA_WRAP 44
+#define RTD1625_CRT_RSTN_SATA_MAC_P1 45
+#define RTD1625_CRT_RSTN_SATA_MAC_P0 46
+#define RTD1625_CRT_RSTN_SATA_MAC_COM 47
+#define RTD1625_CRT_RSTN_PCIE1_STITCH 48
+#define RTD1625_CRT_RSTN_PCIE1_PHY 49
+#define RTD1625_CRT_RSTN_PCIE1 50
+#define RTD1625_CRT_RSTN_PCIE1_CORE 51
+#define RTD1625_CRT_RSTN_PCIE1_POWER 52
+#define RTD1625_CRT_RSTN_PCIE1_NONSTICH 53
+#define RTD1625_CRT_RSTN_PCIE1_PHY_MDIO 54
+#define RTD1625_CRT_RSTN_HDMITOP 55
+#define RTD1625_CRT_RSTN_I2C_4 56
+#define RTD1625_CRT_RSTN_I2C_5 57
+#define RTD1625_CRT_RSTN_TSIO 58
+#define RTD1625_CRT_RSTN_VI 59
+#define RTD1625_CRT_RSTN_EDP 60
+#define RTD1625_CRT_RSTN_VE1_MMU 61
+#define RTD1625_CRT_RSTN_VE1_MMU_FUNC 62
+#define RTD1625_CRT_RSTN_HSE_MMU 63
+#define RTD1625_CRT_RSTN_HSE_MMU_FUNC 64
+#define RTD1625_CRT_RSTN_MDLM2M 65
+#define RTD1625_CRT_RSTN_ISO_GSPI 66
+#define RTD1625_CRT_RSTN_SOFT_NPU 67
+#define RTD1625_CRT_RSTN_SPI2EMMC 68
+#define RTD1625_CRT_RSTN_EARC 69
+#define RTD1625_CRT_RSTN_VE1 70
+#define RTD1625_CRT_RSTN_PCIE2_STITCH 71
+#define RTD1625_CRT_RSTN_PCIE2_PHY 72
+#define RTD1625_CRT_RSTN_PCIE2 73
+#define RTD1625_CRT_RSTN_PCIE2_CORE 74
+#define RTD1625_CRT_RSTN_PCIE2_POWER 75
+#define RTD1625_CRT_RSTN_PCIE2_NONSTICH 76
+#define RTD1625_CRT_RSTN_PCIE2_PHY_MDIO 77
+#define RTD1625_CRT_RSTN_DCPHY_UMCTL2 78
+#define RTD1625_CRT_RSTN_MIPI_DSI 79
+#define RTD1625_CRT_RSTN_HIFM 80
+#define RTD1625_CRT_RSTN_NSRAM 81
+#define RTD1625_CRT_RSTN_AUCPU0_REG 82
+#define RTD1625_CRT_RSTN_MDL_GENPW 83
+#define RTD1625_CRT_RSTN_MDL_CHIP 84
+#define RTD1625_CRT_RSTN_MDL_IP 85
+#define RTD1625_CRT_RSTN_TEST_MUX 86
+#define RTD1625_CRT_RSTN_ISO_BIST 87
+#define RTD1625_CRT_RSTN_MAIN_BIST 88
+#define RTD1625_CRT_RSTN_MAIN2_BIST 89
+#define RTD1625_CRT_RSTN_VE1_BIST 90
+#define RTD1625_CRT_RSTN_VE2_BIST 91
+#define RTD1625_CRT_RSTN_DCPHY_BIST 92
+#define RTD1625_CRT_RSTN_GPU_BIST 93
+#define RTD1625_CRT_RSTN_DISP_BIST 94
+#define RTD1625_CRT_RSTN_NPU_BIST 95
+#define RTD1625_CRT_RSTN_CAS_BIST 96
+#define RTD1625_CRT_RSTN_VE4_BIST 97
+#define RTD1625_CRT_RSTN_EMMC 98
+#define RTD1625_CRT_RSTN_GPU 99
+#define RTD1625_CRT_RSTN_VE2 100
+#define RTD1625_CRT_RSTN_UR1 101
+#define RTD1625_CRT_RSTN_UR2 102
+#define RTD1625_CRT_RSTN_UR3 103
+#define RTD1625_CRT_RSTN_UR4 104
+#define RTD1625_CRT_RSTN_UR5 105
+#define RTD1625_CRT_RSTN_UR6 106
+#define RTD1625_CRT_RSTN_UR7 107
+#define RTD1625_CRT_RSTN_UR8 108
+#define RTD1625_CRT_RSTN_UR9 109
+#define RTD1625_CRT_RSTN_UR_TOP 110
+#define RTD1625_CRT_RSTN_I2C_7 111
+#define RTD1625_CRT_RSTN_I2C_6 112
+#define RTD1625_CRT_RSTN_SPI0 113
+#define RTD1625_CRT_RSTN_SPI1 114
+#define RTD1625_CRT_RSTN_SPI2 115
+#define RTD1625_CRT_RSTN_LSADC0 116
+#define RTD1625_CRT_RSTN_LSADC1 117
+#define RTD1625_CRT_RSTN_ISOMIS_DMA 118
+#define RTD1625_CRT_RSTN_AUDIO_ADC 119
+#define RTD1625_CRT_RSTN_DPTX 120
+#define RTD1625_CRT_RSTN_AUCPU1_REG 121
+#define RTD1625_CRT_RSTN_EDPTX 122
+
+/* ISO reset */
+#define RTD1625_ISO_RSTN_VFD 0
+#define RTD1625_ISO_RSTN_CEC0 1
+#define RTD1625_ISO_RSTN_CEC1 2
+#define RTD1625_ISO_RSTN_CBUSTX 3
+#define RTD1625_ISO_RSTN_CBUSRX 4
+#define RTD1625_ISO_RSTN_USB3_PHY2_XTAL_POW 5
+#define RTD1625_ISO_RSTN_UR0 6
+#define RTD1625_ISO_RSTN_GMAC 7
+#define RTD1625_ISO_RSTN_GPHY 8
+#define RTD1625_ISO_RSTN_I2C_0 9
+#define RTD1625_ISO_RSTN_I2C_1 10
+#define RTD1625_ISO_RSTN_CBUS 11
+#define RTD1625_ISO_RSTN_USB_DRD 12
+#define RTD1625_ISO_RSTN_USB_HOST 13
+#define RTD1625_ISO_RSTN_USB_PHY_0 14
+#define RTD1625_ISO_RSTN_USB_PHY_1 15
+#define RTD1625_ISO_RSTN_USB_PHY_2 16
+#define RTD1625_ISO_RSTN_USB 17
+#define RTD1625_ISO_RSTN_TYPE_C 18
+#define RTD1625_ISO_RSTN_USB_U3_HOST 19
+#define RTD1625_ISO_RSTN_USB3_PHY0_POW 20
+#define RTD1625_ISO_RSTN_USB3_P0_MDIO 21
+#define RTD1625_ISO_RSTN_USB3_PHY1_POW 22
+#define RTD1625_ISO_RSTN_USB3_P1_MDIO 23
+#define RTD1625_ISO_RSTN_VTC 24
+#define RTD1625_ISO_RSTN_USB3_PHY2_POW 25
+#define RTD1625_ISO_RSTN_USB3_P2_MDIO 26
+#define RTD1625_ISO_RSTN_USB_PHY_3 27
+#define RTD1625_ISO_RSTN_USB_PHY_4 28
+
+/* ISO_S reset */
+#define RTD1625_ISO_S_RSTN_ISOM_MIS 0
+#define RTD1625_ISO_S_RSTN_GPIOM 1
+#define RTD1625_ISO_S_RSTN_TIMER7 2
+#define RTD1625_ISO_S_RSTN_IRDA 3
+#define RTD1625_ISO_S_RSTN_UR10 4
+
+#endif /* __DT_BINDINGS_RTK_RESET_RTD1625_H */
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox