* Re: [PATCH 0/4] module: force sh_addr=0 for arch-specific sections
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Petr Pavlu
Cc: linux-riscv, linux, catalin.marinas, will, geert, pjw, palmer,
aou, samitolvanen, alex, mcgrof, da.gomez, atomlin, joe.lawrence,
linux-arm-kernel, linux-m68k, linux-modules, linux-kernel
In-Reply-To: <20260327080023.861105-1-petr.pavlu@suse.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Sami Tolvanen <samitolvanen@google.com>:
On Fri, 27 Mar 2026 08:58:59 +0100 you wrote:
> When linking modules with 'ld.bfd -r', sections defined without an address
> inherit the location counter, resulting in non-zero sh_addr values in the
> resulting .ko files. Relocatable objects are expected to have sh_addr=0 for
> all sections. Non-zero addresses are confusing in this context, typically
> worse compressible, and may cause tools to misbehave [1].
>
> Joe Lawrence previously addressed the same issue in the main
> scripts/module.lds.S file [2] and we discussed that the same fix should be
> also applied to architecture-specific module sections. This series
> implements these changes.
>
> [...]
Here is the summary with links:
- [1/4] module, arm: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/ffe1545ce8a0
- [2/4] module, arm64: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/c5553deb577f
- [3/4] module, m68k: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/9cb4d4dc8227
- [4/4] module, riscv: force sh_addr=0 for arch-specific sections
https://git.kernel.org/riscv/c/04e17ca3f77e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 0/5] mm/sparse-vmemmap: Provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, akpm, david, catalin.marinas, will, palmer, pjw,
chenhuacai, andreas, davem, muchun.song, linux-mm, linux-kernel,
linux-arm-kernel, loongarch, sparclinux, alex, aou, kernel, ljs,
liam, vbabka, rppt, surenb, mhocko
In-Reply-To: <20260601084845.3792171-1-songmuchun@bytedance.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 1 Jun 2026 16:48:39 +0800 you wrote:
> The weak vmemmap_set_pmd() and vmemmap_check_pmd() hooks are
> currently no-ops in the generic code, which leaves architectures that
> need PMD-level handling to open-code the same logic locally.
>
> This series provides generic implementations for both helpers in
> mm/sparse-vmemmap.c. vmemmap_set_pmd() installs a huge PMD with
> PAGE_KERNEL protection, and vmemmap_check_pmd() verifies a present
> leaf PMD before reusing the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [v3,1/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
https://git.kernel.org/riscv/c/0b6073ff1574
- [v3,2/5] arm64/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/f521f198b50a
- [v3,3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
- [v3,4/5] loongarch/mm: drop vmemmap_check_pmd helper and use generic code
https://git.kernel.org/riscv/c/ecca7da924b1
- [v3,5/5] sparc/mm: drop vmemmap_check_pmd helper and use generic code
https://git.kernel.org/riscv/c/d3d58e946900
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, catalin.marinas, will, chenhuacai, pjw, palmer, aou,
davem, andreas, akpm, david, linux-mm, muchun.song, kernel, alex,
ljs, Liam.Howlett, vbabka, rppt, surenb, mhocko, ryan.roberts,
kevin.brodsky, dev.jain, anshuman.khandual, yang,
chaitanyas.prakash, ptesarik, vishal.moola, junhui.liu,
austin.kim, chengkaitao, willy, alexs, linux-arm-kernel,
linux-kernel, loongarch, sparclinux
In-Reply-To: <20260404122105.3989557-1-songmuchun@bytedance.com>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Sat, 4 Apr 2026 20:20:53 +0800 you wrote:
> The two weak functions vmemmap_set_pmd() and vmemmap_check_pmd() are
> currently no-ops on every architecture, forcing each platform that needs
> them to duplicate the same handful of lines. Provide a generic implementation:
>
> - vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
>
> - vmemmap_check_pmd() verifies that the PMD is present and leaf,
> then calls the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [v2,3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 0/5] mm/sparse-vmemmap: provide generic vmemmap_set_pmd() and vmemmap_check_pmd()
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Muchun Song
Cc: linux-riscv, catalin.marinas, will, chenhuacai, pjw, palmer, aou,
davem, andreas, akpm, david, muchun.song, kernel, alex, ljs,
Liam.Howlett, vbabka, rppt, surenb, mhocko, ryan.roberts,
kevin.brodsky, dev.jain, anshuman.khandual, yang,
chaitanyas.prakash, wangyuquan1236, ptesarik, austin.kim,
vishal.moola, junhui.liu, willy, alexs, chengkaitao,
linux-arm-kernel, linux-kernel, loongarch, sparclinux, linux-mm
In-Reply-To: <20260404071720.3577290-1-songmuchun@bytedance.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Sat, 4 Apr 2026 15:17:04 +0800 you wrote:
> The two weak functions vmemmap_set_pmd() and vmemmap_check_pmd() are
> currently no-ops on every architecture, forcing each platform that needs
> them to duplicate the same handful of lines. Provide a generic implementation:
>
> - vmemmap_set_pmd() simply sets a huge PMD with PAGE_KERNEL protection.
>
> - vmemmap_check_pmd() verifies that the PMD is present and leaf,
> then calls the existing vmemmap_verify() helper.
>
> [...]
Here is the summary with links:
- [2/4] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
- [3/5] riscv/mm: drop vmemmap_pmd helpers and use generic code
https://git.kernel.org/riscv/c/abff0ecf7602
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Wandun
Cc: linux-riscv, linux-arm-kernel, linux-kernel, loongarch,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, robh, saravanak, akpm,
bhe, rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-1-chenwandun1@gmail.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Rob Herring (Arm) <robh@kernel.org>:
On Wed, 27 May 2026 11:29:06 +0800 you wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> On SoCs that carve out large firmware-owned reserved memory (GPU
> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> those carveouts as part of system RAM even though their contents are
> firmware state that is not useful for kernel crash analysis.
>
> [...]
Here is the summary with links:
- [v3,01/11] of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
https://git.kernel.org/riscv/c/cfba13a18672
- [v3,02/11] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n
(no matching commit)
- [v3,03/11] of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails
(no matching commit)
- [v3,04/11] of: reserved_mem: zero total_reserved_mem_cnt if no valid /reserved-memory entry
https://git.kernel.org/riscv/c/50a488de5fcc
- [v3,05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late()
(no matching commit)
- [v3,06/11] of: reserved_mem: add dumpable flag to opt-in vmcore
(no matching commit)
- [v3,07/11] of: reserved_mem: save /memreserve/ entries into the reserved_mem array
(no matching commit)
- [v3,08/11] of: reserved_mem: add kdump helpers to exclude non-dumpable regions
(no matching commit)
- [v3,09/11] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
- [v3,10/11] riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
- [v3,11/11] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-riscv, akpm, catalin.marinas, will, ardb, chenhuacai,
kernel, maddy, mpe, npiggin, chleroy, pjw, palmer, aou, alex, hca,
gor, agordeev, borntraeger, svens, tglx, mingo, bp, dave.hansen,
x86, hpa, herbert, dan.j.williams, clm, dsterba, arnd, song,
yukuai, linan122, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260512052230.2947683-2-hch@lst.de>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Tue, 12 May 2026 07:20:41 +0200 you wrote:
> While the RAID6 algorithm could in theory support 3 devices by just
> copying the data disk to the two parity disks, this version is not only
> useless because it is a suboptimal version of 3-way mirroring, but also
> broken with various crashes and incorrect parity generation in various
> architecture-optimized implementations. Disallow it similar to mdraid
> which requires at least 4 devices for RAID 6.
>
> [...]
Here is the summary with links:
- [01/19] btrfs: require at least 4 devices for RAID 6
(no matching commit)
- [02/19] raid6: turn the userspace test harness into a kunit test
(no matching commit)
- [03/19] raid6: remove __KERNEL__ ifdefs
https://git.kernel.org/riscv/c/3d6beb659ddf
- [04/19] raid6: move to lib/raid/
(no matching commit)
- [05/19] raid6: remove unused defines in pq.h
https://git.kernel.org/riscv/c/06d2a66fb7c0
- [06/19] raid6: remove raid6_get_zero_page
https://git.kernel.org/riscv/c/885d31423183
- [07/19] raid6: use named initializers for struct raid6_calls
https://git.kernel.org/riscv/c/7e91f76a9668
- [08/19] raid6: improve the public interface
(no matching commit)
- [09/19] raid6: hide internals
(no matching commit)
- [10/19] raid6: rework the init helpers
(no matching commit)
- [11/19] raid6: use static_call for gen_syndrom and xor_syndrom
https://git.kernel.org/riscv/c/10f4b8e2a164
- [12/19] raid6: use static_call for raid6_recov_2data and raid6_recov_datap
(no matching commit)
- [13/19] raid6: update top of file comments
https://git.kernel.org/riscv/c/30bf04bd13a5
- [14/19] raid6_kunit: use KUNIT_CASE_PARAM
https://git.kernel.org/riscv/c/2175395f76c3
- [15/19] raid6_kunit: dynamically allocate data buffers using vmalloc
https://git.kernel.org/riscv/c/d67c25712fe3
- [16/19] raid6_kunit: cleanup dataptr handling
https://git.kernel.org/riscv/c/562bcbfcb99b
- [17/19] raid6_kunit: randomize parameters and increase limits
(no matching commit)
- [18/19] raid6_kunit: randomize parameters and increase limits
(no matching commit)
- [19/19] raid6_kunit: randomize buffer alignment
https://git.kernel.org/riscv/c/8cf0a6c4bb9e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v9 0/4] Introduce ASPEED AST27xx BMC SoC
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Ryan Chen
Cc: linux-riscv, robh, krzk+dt, conor+dt, joel, andrew,
catalin.marinas, will, arnd, krzk, alexandre.belloni, linusw,
fustini, pjw, palmer, aou, alex, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel, soc, conor.dooley
In-Reply-To: <20260609-upstream_ast2700-v9-0-f631752f0cb1@aspeedtech.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Arnd Bergmann <arnd@arndb.de>:
On Tue, 9 Jun 2026 10:47:17 +0800 you wrote:
> This introduces initial support for the Aspeed AST27xx SoC and the AST2700
> Evaluation Board (EVB) to the Linux kernel. The AST27xx is the 8th
> generation Baseboard Management Controller (BMC) SoC from Aspeed,
> featuring improved performance, enhanced security, and expanded I/O
> capabilities compared to previous generations.
>
> AST27xx SOC Family
> - https://www.aspeedtech.com/server_ast2700/
> - https://www.aspeedtech.com/server_ast2720/
> - https://www.aspeedtech.com/server_ast2750/
>
> [...]
Here is the summary with links:
- [v9,1/4] dt-bindings: arm: aspeed: Add AST2700 board compatible
https://git.kernel.org/riscv/c/34efd73379ff
- [v9,2/4] arm64: Kconfig: Add ASPEED SoC family Kconfig support
https://git.kernel.org/riscv/c/df6f379eb4ac
- [v9,3/4] arm64: dts: aspeed: Add initial AST27xx SoC device tree
https://git.kernel.org/riscv/c/e77bb5dc5759
- [v9,4/4] arm64: configs: Update defconfig for AST2700 platform support
https://git.kernel.org/riscv/c/512cef2af615
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 01/18] raid6: turn the userspace test harness into a kunit test
From: patchwork-bot+linux-riscv @ 2026-06-26 8:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-riscv, akpm, catalin.marinas, will, ardb, chenhuacai,
kernel, maddy, mpe, npiggin, chleroy, pjw, palmer, aou, alex, hca,
gor, agordeev, borntraeger, svens, tglx, mingo, bp, dave.hansen,
x86, hpa, herbert, dan.j.williams, clm, dsterba, arnd, song,
yukuai, linan122, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260518051804.462141-2-hch@lst.de>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 18 May 2026 07:17:44 +0200 you wrote:
> Currently the raid6 code can be compiled as userspace code to run the
> test suite. Convert that to be a kunit case with minimal changes to
> avoid mutating global state so that we can drop this requirement.
>
> Note that this is not a good kunit test case yet and will need a lot more
> work, but that is deferred until the raid6 code is moved to it's new
> place, which is easier if the userspace makefile doesn't need adjustments
> for the new location first.
>
> [...]
Here is the summary with links:
- [01/18] raid6: turn the userspace test harness into a kunit test
https://git.kernel.org/riscv/c/c4697486fc23
- [02/18] raid6: remove __KERNEL__ ifdefs
https://git.kernel.org/riscv/c/3d6beb659ddf
- [03/18] raid6: move to lib/raid/
https://git.kernel.org/riscv/c/3626738bc714
- [04/18] raid6: remove unused defines in pq.h
https://git.kernel.org/riscv/c/06d2a66fb7c0
- [05/18] raid6: remove raid6_get_zero_page
https://git.kernel.org/riscv/c/885d31423183
- [06/18] raid6: use named initializers for struct raid6_calls
https://git.kernel.org/riscv/c/7e91f76a9668
- [07/18] raid6: improve the public interface
https://git.kernel.org/riscv/c/35472bc6f31b
- [08/18] raid6: warn when using less than four devices
https://git.kernel.org/riscv/c/2790045a62eb
- [09/18] raid6: hide internals
(no matching commit)
- [10/18] raid6: rework registration of optimized algorithms
(no matching commit)
- [11/18] raid6: use static_call for gen_syndrom and xor_syndrom
https://git.kernel.org/riscv/c/10f4b8e2a164
- [12/18] raid6: use static_call for raid6_recov_2data and raid6_recov_datap
https://git.kernel.org/riscv/c/dd83de0341da
- [13/18] raid6: update top of file comments
https://git.kernel.org/riscv/c/30bf04bd13a5
- [14/18] raid6_kunit: use KUNIT_CASE_PARAM
https://git.kernel.org/riscv/c/2175395f76c3
- [15/18] raid6_kunit: dynamically allocate data buffers using vmalloc
https://git.kernel.org/riscv/c/d67c25712fe3
- [16/18] raid6_kunit: cleanup dataptr handling
https://git.kernel.org/riscv/c/562bcbfcb99b
- [17/18] raid6_kunit: randomize parameters and increase limits
https://git.kernel.org/riscv/c/fa0c812c0aa5
- [18/18] raid6_kunit: randomize buffer alignment
https://git.kernel.org/riscv/c/8cf0a6c4bb9e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 1/7] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
From: patchwork-bot+linux-riscv @ 2026-06-26 8:21 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-riscv, acme, adrian.hunter, dapeng1.mi, james.clark,
namhyung, florian.fainelli, guanli.oerv, 9erthalion6, alex,
alexander.shishkin, andrew.jones, aou, atrajeev, howardchu95,
john.g.garry, jolsa, leo.yan, libunwind-devel, linux-arm-kernel,
linux-kernel, linux-perf-users, mingo, palmer, peterz, pjw,
shimin.guo, tglozar, tmricht, will
In-Reply-To: <20260513233151.572332-2-irogers@google.com>
Hello:
This series was applied to riscv/linux.git (fixes)
by Arnaldo Carvalho de Melo <acme@redhat.com>:
On Wed, 13 May 2026 16:31:45 -0700 you wrote:
> Currently, both libdw and libunwind define 'unwind__get_entries'. This
> causes a duplicate symbol build failure when both are compiled into
> perf.
>
> This commit refactors the DWARF unwind post-processing to be
> configurable at runtime via the .perfconfig file option
> 'unwind.style', or using the argument '--unwind-style' in the commands
> 'perf report', 'perf script' and 'perf inject', in a similar manner to
> the addr2line or the disassembler style.
>
> [...]
Here is the summary with links:
- [v5,1/7] perf unwind: Refactor get_entries to allow dynamic libdw/libunwind selection
(no matching commit)
- [v5,2/7] tools build: Deduplicate test-libunwind for different architectures
https://git.kernel.org/riscv/c/6d13d53be9dd
- [v5,3/7] perf build: Be more programmatic when setting up libunwind variables
https://git.kernel.org/riscv/c/444508cd7c7b
- [v5,4/7] perf unwind-libunwind: Make libunwind register reading cross platform
(no matching commit)
- [v5,5/7] perf unwind-libunwind: Move flush/finish access out of local
https://git.kernel.org/riscv/c/2723e9f8b5cf
- [v5,6/7] perf unwind-libunwind: Remove libunwind-local
(no matching commit)
- [v5,7/7] perf unwind-libunwind: Add RISC-V libunwind support
https://git.kernel.org/riscv/c/834c557167a9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: patchwork-bot+linux-riscv @ 2026-06-26 8:20 UTC (permalink / raw)
To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig_=28The_Capable_Hub=29_=3Cu=2Ekleine-koenig?=,
=?utf-8?q?=40baylibre=2Ecom=3E?=
Cc: linux-riscv, sre, visitorckw, bleung, groeck, linux, krzk,
matthias.bgg, angelogioacchino.delregno, linux-pm, linux-kernel,
chrome-platform, linux-arm-kernel, linux-mediatek, hansg,
m.szyprowski, sebastian.krzyszkowiak, kernel, dlan, andreas,
mazziesaccount, sven, j, neal, amitsd, samkay014, spacemit, asahi,
imx, wens
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Sebastian Reichel <sebastian.reichel@collabora.com>:
On Fri, 29 May 2026 12:18:15 +0200 you wrote:
> Hello,
>
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> [...]
Here is the summary with links:
- [v1,4/6] power: Use named initializers for platform_device_id arrays
https://git.kernel.org/riscv/c/e28f7498dd81
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-26 8:23 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260624074409.5jwpWs61@linutronix.de>
On Wed, Jun 24, 2026 at 09:44:09AM +0200, Sebastian Andrzej Siewior wrote:
>On 2026-06-22 19:24:00 [+0800], Peng Fan wrote:
>> We may need to use atomic API for TXDB_V2. For the patchset itself, it
>> looks good to me.
>>
>> Reviewed-by: Peng Fan <peng.fan@nxp.com>
>
>Thank you. Is there anything you want me to do or is this series good
>as-is?
If you would like to address the AI reported issue further, you may
update readl_poll_timeout to readl_poll_timeout_atomic.
From the fix on error return, this patch is ok to me, and the series is good.
Thanks,
Peng
>
>Sebastian
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-26 8:18 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 12249 bytes --]
> Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> during hardware initialization instead of updating it according to the
> configured MTU. This avoids dropping incoming frames that exceed the
> current MTU but could still be processed by the networking stack, which
> is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> Move the per-port MTU configuration to the PPE egress path where it
> belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> to dynamically track the maximum MTU across running interfaces sharing
> the same PPE instance.
> Fix the PPE MTU register addressing to pack two port entries per
> register word and add WAN_MTU0 configuration for non-LAN GDM devices.
commenting on sashiko's report:
https://sashiko.dev/#/patchset/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d%40kernel.org
>
> Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 68 ++++++++++---------------------
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +
> drivers/net/ethernet/airoha/airoha_ppe.c | 39 +++++++++++++-----
> drivers/net/ethernet/airoha/airoha_regs.h | 9 ++--
> 4 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 932b3a3df2e5..3f451c2d4c24 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -178,10 +178,15 @@ static void airoha_fe_maccr_init(struct airoha_eth *eth)
> {
> int p;
>
> - for (p = 1; p <= ARRAY_SIZE(eth->ports); p++)
> + for (p = 1; p <= ARRAY_SIZE(eth->ports); p++) {
> airoha_fe_set(eth, REG_GDM_FWD_CFG(p),
> GDM_TCP_CKSUM_MASK | GDM_UDP_CKSUM_MASK |
> GDM_IP4_CKSUM_MASK | GDM_DROP_CRC_ERR_MASK);
> + airoha_fe_rmw(eth, REG_GDM_LEN_CFG(p),
> + GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> + FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> + FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_RX_SIZE));
> + }
>
> airoha_fe_rmw(eth, REG_CDM_VLAN_CTRL(1), CDM_VLAN_MASK,
> FIELD_PREP(CDM_VLAN_MASK, 0x8100));
> @@ -1831,13 +1836,24 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
> spin_unlock(&port->stats_lock);
- This is a pre-existing issue, but can the spin_lock() used in
airoha_update_hw_stats() cause a deadlock?
If a process context holds port->stats_lock via spin_lock() and is preempted
by a networking softirq on the same CPU that calls dev_get_stats()
(which invokes ndo_get_stats64 -> airoha_update_hw_stats()), will the softirq
spin forever trying to acquire the same lock? Should this use spin_lock_bh()
instead?
- The reported issue has not been introduced by this patch. Moreover, I do
not think this is a real problem since in the current codebase
airoha_update_hw_stats() is always run in process context and not in-irq
context.
> }
>
> +static void airoha_dev_set_xmit_frame_size(struct net_device *netdev)
> +{
> + struct airoha_gdm_dev *dev = netdev_priv(netdev);
> +
> + airoha_ppe_set_xmit_frame_size(dev);
> + if (!airoha_is_lan_gdm_dev(dev))
> + airoha_fe_rmw(dev->eth, REG_WAN_MTU0, WAN_MTU0_MASK,
> + FIELD_PREP(WAN_MTU0_MASK,
> + VLAN_ETH_HLEN + netdev->mtu));
> +}
- Does this unconditional write to REG_WAN_MTU0 break sibling network devices
sharing the same WAN port?
If multiple interfaces share the same hardware port, this appears to overwrite
the shared register using only the current interface's MTU, ignoring the
maximum MTU of any active sibling interfaces. Could this cause the hardware to
drop frames for sibling interfaces if their MTU is larger than the most
recently configured interface?
- This is not a real issue since we can have at most a single WAN port in the
system
> +
> static int airoha_dev_open(struct net_device *netdev)
> {
> - int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> struct airoha_gdm_port *port = dev->port;
> - u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
> + u32 pse_port = FE_PSE_PORT_PPE1;
> + int err;
>
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
[...]
> static int airoha_dev_stop(struct net_device *netdev)
> {
> struct airoha_gdm_dev *dev = netdev_priv(netdev);
> @@ -1909,7 +1889,7 @@ static int airoha_dev_stop(struct net_device *netdev)
> airoha_set_vip_for_gdm_port(dev, false);
>
> if (--port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_ppe_set_xmit_frame_size(dev);
- Does this stop path fail to update the WAN MTU limit?
When an interface is stopped, airoha_ppe_set_xmit_frame_size() recalculates
the PPE MTU, but it looks like the global REG_WAN_MTU0 register is not updated
here. Will this prevent the MTU limit from correctly shrinking when an
interface is brought down?
- This is not a real issue since, as pointed out above, we can have at most a
single WAN port in the system, so there is no point to reconfigure
REG_WAN_MTU0 if this interface is stopped.
> else
> airoha_set_gdm_port_fwd_cfg(qdma->eth,
> REG_GDM_FWD_CFG(port->id),
> @@ -1962,10 +1942,6 @@ static int airoha_enable_gdm2_loopback(struct airoha_gdm_dev *dev)
> FIELD_PREP(LPBK_CHAN_MASK, chan) |
> LBK_GAP_MODE_MASK | LBK_LEN_MODE_MASK |
> LBK_CHAN_MODE_MASK | LPBK_EN_MASK);
> - airoha_fe_rmw(eth, REG_GDM_LEN_CFG(AIROHA_GDM2_IDX),
> - GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
> - FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
> - FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_MTU));
> /* Forward the traffic to the proper GDM port */
> pse_port = port->id == AIROHA_GDM3_IDX ? FE_PSE_PORT_GDM3
> : FE_PSE_PORT_GDM4;
> @@ -2098,7 +2074,7 @@ static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
>
> WRITE_ONCE(netdev->mtu, mtu);
> if (port->users)
> - airoha_set_port_mtu(dev->eth, port);
> + airoha_dev_set_xmit_frame_size(netdev);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index d7ff8c5200e2..0c3fb6e5d7f1 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -23,6 +23,7 @@
> #define AIROHA_MAX_DSA_PORTS 7
> #define AIROHA_MAX_NUM_RSTS 3
> #define AIROHA_MAX_MTU 9220
> +#define AIROHA_MAX_RX_SIZE 16128
> #define AIROHA_MAX_PACKET_SIZE 2048
> #define AIROHA_NUM_QOS_CHANNELS 4
> #define AIROHA_NUM_QOS_QUEUES 8
> @@ -676,6 +677,7 @@ int airoha_get_fe_port(struct airoha_gdm_dev *dev);
> bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> struct airoha_gdm_dev *dev);
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev);
> void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport);
> bool airoha_ppe_is_enabled(struct airoha_eth *eth, int index);
> void airoha_ppe_check_skb(struct airoha_ppe_dev *dev, struct sk_buff *skb,
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 42f4b0f21d17..e7c78293002a 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -97,6 +97,33 @@ void airoha_ppe_set_cpu_port(struct airoha_gdm_dev *dev, u8 ppe_id, u8 fport)
> __field_prep(DFT_CPORT_MASK(fport), fe_cpu_port));
> }
>
> +void airoha_ppe_set_xmit_frame_size(struct airoha_gdm_dev *dev)
> +{
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + int i, ppe_id, index;
> + u32 len = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(port->devs); i++) {
> + struct airoha_gdm_dev *d = port->devs[i];
> + struct net_device *netdev;
> +
> + if (!d)
> + continue;
> +
> + netdev = netdev_from_priv(d);
> + if (netif_running(netdev))
> + len = max_t(u32, len, netdev->mtu);
> + }
> + len += VLAN_ETH_HLEN;
> +
> + ppe_id = !airoha_is_lan_gdm_dev(dev) && airoha_ppe_is_enabled(eth, 1);
> + index = port->id == AIROHA_GDM4_IDX ? 7 : port->id;
> + airoha_fe_rmw(eth, REG_PPE_MTU(ppe_id, index),
> + FP_EGRESS_MTU_MASK(index),
> + __field_prep(FP_EGRESS_MTU_MASK(index), len));
- Does this leave the egress MTU limit uninitialized for other PPE engines?
The patch removes the loop in airoha_ppe_hw_init() that previously initialized
REG_PPE_MTU for all ports on all available PPEs. This function now only
configures it for a single ppe_id.
During cross-PPE routing (such as WAN-to-LAN), if PPE1 (WAN) forwards a packet
to a LAN port, it will check REG_PPE_MTU(1, LAN_port). Since this register was
only configured for PPE0, will the uninitialized limit (0) cause the packet to
be dropped?
- This is not a real issue since every airoha_gdm_dev/net_device is
associated to a PPE engine/QDMA according to the logic in
airoha_dev_open()/airoha_dev_set_qdma(). The other PPE engine's MTU will be
updated according to the assigned net_device.
Regards,
Lorenzo
> +}
> +
> static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> {
> u32 sram_ppe_num_data_entries = PPE_SRAM_NUM_ENTRIES, sram_num_entries;
> @@ -115,8 +142,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> PPE_RAM_NUM_ENTRIES_SHIFT(sram_ppe_num_data_entries);
>
> for (i = 0; i < eth->soc->num_ppe; i++) {
> - int p;
> -
> airoha_fe_wr(eth, REG_PPE_TB_BASE(i),
> ppe->foe_dma + sram_tb_size);
>
> @@ -166,15 +191,6 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_fe_wr(eth, REG_PPE_HASH_SEED(i), PPE_HASH_SEED);
> airoha_fe_clear(eth, REG_PPE_PPE_FLOW_CFG(i),
> PPE_FLOW_CFG_IP6_6RD_MASK);
> -
> - for (p = 0; p < ARRAY_SIZE(eth->ports); p++)
> - airoha_fe_rmw(eth, REG_PPE_MTU(i, p),
> - FP0_EGRESS_MTU_MASK |
> - FP1_EGRESS_MTU_MASK,
> - FIELD_PREP(FP0_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU) |
> - FIELD_PREP(FP1_EGRESS_MTU_MASK,
> - AIROHA_MAX_MTU));
> }
>
> for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> @@ -196,6 +212,7 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
> airoha_ppe_is_enabled(eth, 1);
> fport = airoha_get_fe_port(dev);
> airoha_ppe_set_cpu_port(dev, ppe_id, fport);
> + airoha_ppe_set_xmit_frame_size(dev);
> }
> }
> }
> diff --git a/drivers/net/ethernet/airoha/airoha_regs.h b/drivers/net/ethernet/airoha/airoha_regs.h
> index 436f3c8779c1..6fed63d013b4 100644
> --- a/drivers/net/ethernet/airoha/airoha_regs.h
> +++ b/drivers/net/ethernet/airoha/airoha_regs.h
> @@ -327,9 +327,8 @@
> #define PPE_SRAM_TABLE_EN_MASK BIT(0)
>
> #define REG_PPE_MTU_BASE(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x304)
> -#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + ((_n) << 2))
> -#define FP1_EGRESS_MTU_MASK GENMASK(29, 16)
> -#define FP0_EGRESS_MTU_MASK GENMASK(13, 0)
> +#define REG_PPE_MTU(_m, _n) (REG_PPE_MTU_BASE(_m) + (((_n) / 2) << 2))
> +#define FP_EGRESS_MTU_MASK(_n) GENMASK(13 + (((_n) % 2) << 4), ((_n) % 2) << 4)
>
> #define REG_PPE_RAM_CTRL(_n) (((_n) ? PPE2_BASE : PPE1_BASE) + 0x31c)
> #define PPE_SRAM_CTRL_ACK_MASK BIT(31)
> @@ -377,6 +376,10 @@
> #define REG_SRC_PORT_FC_MAP6 0x2298
> #define FC_ID_OF_SRC_PORT_MASK(_n) GENMASK(4 + ((_n) << 3), ((_n) << 3))
>
> +#define REG_WAN_MTU0 0x2300
> +#define WAN_MTU1_MASK GENMASK(29, 16)
> +#define WAN_MTU0_MASK GENMASK(13, 0)
> +
> #define REG_CDM5_RX_OQ1_DROP_CNT 0x29d4
>
> /* QDMA */
>
> ---
> base-commit: fd1269e454089abda0e4f9e5e25ecd02a90ab009
> change-id: 20260618-airoha-fix-rx-max-len-57654b661646
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/2] Fix CPU stall in xilinx_dma_poll_timeout caused by passing delay_us=0
From: Pandey, Radhey Shyam @ 2026-06-26 8:10 UTC (permalink / raw)
To: Alex Bereza, Vinod Koul, Frank Li, Michal Simek,
Geert Uytterhoeven, Ulf Hansson, Arnd Bergmann, Tony Lindgren,
Kedareswara rao Appana
Cc: dmaengine, linux-arm-kernel, linux-kernel, Suraj Gupta, Frank Li
In-Reply-To: <DJITDJYQEOPN.I0S9T54IS104@bereza.email>
On 6/26/2026 1:18 PM, Alex Bereza wrote:
> Hi, could it be that this patch was forgotten? I still can't find it in
> dmaengine tree. Is there anything I should do? It still applies cleanly
> to dmaengine/fixes.
>
I see both the patches are reviewed. So let's wait for Vinod.
Thanks,
Radhey
^ permalink raw reply
* Re: [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-26 8:09 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260626080422.4191435-1-christianshewitt@gmail.com>
> On 26 Jun 2026, at 12:04 pm, Christian Hewitt <christianshewitt@gmail.com> wrote:
>
> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
> producing the "machine gun noise" buffer underrun - on start when switching
> outputs, and on stop when playback ends. The latter is audible on devices
> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>
> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
> both enable and disable (audio_hw_958_enable), and when reconfiguring
> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
> reset before enabling the DCU on start, and after disabling it on stop.
Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support”)
^ I can send a v2 with it done properly if needed?
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
> ---
> sound/soc/meson/aiu-fifo-spdif.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/sound/soc/meson/aiu-fifo-spdif.c b/sound/soc/meson/aiu-fifo-spdif.c
> index e0e00ec026dc..826055a71421 100644
> --- a/sound/soc/meson/aiu-fifo-spdif.c
> +++ b/sound/soc/meson/aiu-fifo-spdif.c
> @@ -24,6 +24,7 @@
> #define AIU_MEM_IEC958_CONTROL_MODE_16BIT BIT(7)
> #define AIU_MEM_IEC958_CONTROL_MODE_LINEAR BIT(8)
> #define AIU_MEM_IEC958_BUF_CNTL_INIT BIT(0)
> +#define AIU_RST_SOFT_958_FAST BIT(2)
>
> #define AIU_FIFO_SPDIF_BLOCK 8
>
> @@ -68,12 +69,16 @@ static int fifo_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
> case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + snd_soc_component_write(component, AIU_RST_SOFT,
> + AIU_RST_SOFT_958_FAST);
> fifo_spdif_dcu_enable(component, true);
> break;
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> case SNDRV_PCM_TRIGGER_STOP:
> fifo_spdif_dcu_enable(component, false);
> + snd_soc_component_write(component, AIU_RST_SOFT,
> + AIU_RST_SOFT_958_FAST);
> break;
> default:
> return -EINVAL;
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support
From: Icenowy Zheng @ 2026-06-26 8:05 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> This series adds support for the Verisilicon DCUltraLite display
> controller as integrated in the Nuvoton MA35D1 SoC.
>
> The Verisilicon DC driver and its DT binding were originally written
> by
> Icenowy Zheng <zhengxingda@iscas.ac.cn> for the T-Head TH1520 SoC,
> which
> carries a DC8200 IP block. The present series builds on that
> foundation
> with gratitude to Icenowy for the original work.
>
> The DCUltraLite is a different variant in the DC IP family. While
> the two
> IPs share a broadly similar register layout, a number of differences
> prevent the existing driver from working on the MA35D1 without
> modification:
>
> - No CONFIG_EX commit path: the DC8200 staging registers
> (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
> PANEL_CONFIG_EX) are absent. The DCUltraLite uses enable (bit 0)
> and
> reset (bit 4) bits in FB_CONFIG for direct framebuffer updates,
> and
> requires a per-frame VALID bit toggle (FB_CONFIG bit 3) to latch
> configuration changes.
>
> - No PANEL_START register: panel output begins when
> PANEL_CONFIG.RUNNING is set; the DC8200 multi-display sync start
> register at 0x1CCC does not exist.
>
> - Different IRQ registers: DISP_IRQ_STA at 0x147C / DISP_IRQ_EN at
> 0x1480, versus the DC8200's TOP_IRQ_ACK at 0x0010 / TOP_IRQ_EN at
> 0x0014.
>
> - Simpler clock topology: two clocks ("core" bus gate and "pix0"
> pixel
> divider); no axi or ahb clocks required.
>
> - Single display output: no per-output indexing beyond index 0 is
> needed.
>
> - Hardware-discoverable identity: the DCUltraLite exposes chip
> identity
> registers whose model field reads 0x0 (revision 0x5560,
> customer_id 0x305), allowing the existing vs_fill_chip_identity()
> path to identify the variant purely through register reads.
>
> Patch 1 generalises the verisilicon,dc DT binding to accommodate the
> Nuvoton MA35D1 SoC-specific compatible and the variant's two-clock,
> one-reset, single-port topology.
>
> Patch 2 adds the register-level macros needed by the DC8000 ops.
>
> Patches 3-5 introduce the driver changes in three logical steps: the
> vs_dc_funcs hardware ops vtable with DC8200 ops extracted into
> vs_dc8200.c; making axi/ahb clocks optional as a separate atomic
> change;
> and the DC8000 ops in vs_dc8000.c. Patch 6 adds the DCUltraLite HWDB
> entry that gates hardware recognition once all support is in place.
>
> Patch 7 adds the Kconfig dependency on ARCH_MA35, placed last because
> it
> is only meaningful after the HWDB entry is added.
>
> All patches have been tested on Nuvoton MA35D1 hardware.
I also tested these patches on TH1520, and it seems to show no
regression.
Thanks,
Icenowy
>
> Changes from v4:
> - [dt-bindings] Kept clock and reset item descriptions in the
> global
> clocks:/resets: properties; per-compatible sections only
> constrain
> minItems/maxItems and override clock-names items for
> nuvoton,ma35d1-dcu.
> - [dt-bindings] Dropped redundant global minItems/maxItems on
> clocks:
> and clock-names:.
> - [dt-bindings] Dropped the extra-space typo fix in port@0
> description
> to keep the patch atomic; left for a separate patch later.
> - [ops] Renamed crtc_enable/crtc_disable hooks to crtc_enable_ex/
> crtc_disable_ex.
> - [ops] Added unified IRQ bit definitions; each irq_ack()
> implementation
> now translates hardware-specific bits before returning.
> - [clocks] Split the axi/ahb optional-clock change into its own
> patch
> for atomicity.
> - [hwdb] Simplified the commit message for patch 6.
> - [kconfig] Simplified the commit message for patch 7.
>
> Joey Lu (7):
> dt-bindings: display: verisilicon,dc: generalize for single-output
> variants
> drm/verisilicon: add register-level macros for DC8000
> drm/verisilicon: introduce per-variant hardware ops table
> drm/verisilicon: make axi and ahb clocks optional
> drm/verisilicon: add DC8000 (DCUltraLite) display controller
> support
> drm/verisilicon: add DCUltraLite chip identity to HWDB
> drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
>
> .../bindings/display/verisilicon,dc.yaml | 57 +++++++++
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
> drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
> drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc.c | 13 +-
> drivers/gpu/drm/verisilicon/vs_dc.h | 33 +++++
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++
> drivers/gpu/drm/verisilicon/vs_dc8200.c | 115
> ++++++++++++++++++
> drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
> drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 14 +++
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
> .../drm/verisilicon/vs_primary_plane_regs.h | 3 +
> 16 files changed, 378 insertions(+), 57 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
^ permalink raw reply
* Re: [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Icenowy Zheng @ 2026-06-26 8:04 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-7-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> The Nuvoton MA35D1 chip contains a DCUltraLite display controller
> with
> model number 0x0 (sic, the model name contains no number either),
> revision 0x5560 and customer ID 0x305. It has a similar register map
> with DC8000, only one display output and only 32x32 cursor supported.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 91524d16f778..7d630a667a3f 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -129,6 +129,16 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = 0x0, /* DCUltraLite */
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .generation = VSDC_GEN_DC8000,
> + .display_count = 1,
> + .max_cursor_size = 32,
> + .formats = &vs_formats_no_yuv444,
> + },
Checked against the MA35D1 manual, and it looks okay.
```
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
```
Thanks,
Icenowy
> };
>
> int vs_fill_chip_identity(struct regmap *regs,
^ permalink raw reply
* [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-26 8:04 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel
The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
producing the "machine gun noise" buffer underrun - on start when switching
outputs, and on stop when playback ends. The latter is audible on devices
with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
both enable and disable (audio_hw_958_enable), and when reconfiguring
(audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
reset before enabling the DCU on start, and after disabling it on stop.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
sound/soc/meson/aiu-fifo-spdif.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/soc/meson/aiu-fifo-spdif.c b/sound/soc/meson/aiu-fifo-spdif.c
index e0e00ec026dc..826055a71421 100644
--- a/sound/soc/meson/aiu-fifo-spdif.c
+++ b/sound/soc/meson/aiu-fifo-spdif.c
@@ -24,6 +24,7 @@
#define AIU_MEM_IEC958_CONTROL_MODE_16BIT BIT(7)
#define AIU_MEM_IEC958_CONTROL_MODE_LINEAR BIT(8)
#define AIU_MEM_IEC958_BUF_CNTL_INIT BIT(0)
+#define AIU_RST_SOFT_958_FAST BIT(2)
#define AIU_FIFO_SPDIF_BLOCK 8
@@ -68,12 +69,16 @@ static int fifo_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ snd_soc_component_write(component, AIU_RST_SOFT,
+ AIU_RST_SOFT_958_FAST);
fifo_spdif_dcu_enable(component, true);
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
case SNDRV_PCM_TRIGGER_STOP:
fifo_spdif_dcu_enable(component, false);
+ snd_soc_component_write(component, AIU_RST_SOFT,
+ AIU_RST_SOFT_958_FAST);
break;
default:
return -EINVAL;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Icenowy Zheng @ 2026-06-26 8:03 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-6-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
> controller (DC8000 generation) whose register layout differs from
> the DC8200 in several important ways:
>
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit
> 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
>
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 5 +-
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 86
> +++++++++++++++++++++++++
> 4 files changed, 92 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa..d2fd8e4dff24 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_dc8000.o vs_drm.o vs_hwdb.o \
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index fd1f5fe67a68..9499fffbca58 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW
> capability\n");
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index 825f5dd6bf17..ac96ad701199 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -66,5 +66,6 @@ struct vs_dc {
> };
>
> extern const struct vs_dc_funcs vs_dc8200_funcs;
> +extern const struct vs_dc_funcs vs_dc8000_funcs;
>
> #endif /* _VS_DC_H_ */
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c
> b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 000000000000..fbe0fa516cac
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
> + */
> +
> +#include <linux/regmap.h>
> +
> +#include "vs_crtc_regs.h"
> +#include "vs_dc.h"
> +#include "vs_drm.h"
> +#include "vs_primary_plane_regs.h"
> +
> +static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dc8000_crtc_enable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_crtc_disable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
Maybe a warning for unknown IRQ bits should be added here.
Thanks,
Icenowy
> +
> + return unified;
> +}
> +
> +const struct vs_dc_funcs vs_dc8000_funcs = {
> + .panel_enable_ex = vs_dc8000_panel_enable_ex,
> + .panel_disable_ex = vs_dc8000_panel_disable_ex,
> + .crtc_begin = vs_dc8000_crtc_begin,
> + .crtc_flush = vs_dc8000_crtc_flush,
> + .crtc_enable_ex = vs_dc8000_crtc_enable_ex,
> + .crtc_disable_ex = vs_dc8000_crtc_disable_ex,
> + .enable_vblank = vs_dc8000_enable_vblank,
> + .disable_vblank = vs_dc8000_disable_vblank,
> + .irq_ack = vs_dc8000_irq_ack,
> +};
^ permalink raw reply
* Re: [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: Icenowy Zheng @ 2026-06-26 8:03 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-5-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
> whose
> AXI and AHB bus clocks share a single gate enable bit with the
> display
> core clock, so the clock driver does not expose them separately. This
> patch makes the axi and ahb clocks optional in the probe.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
```
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
```
Thanks,
Icenowy
> ---
> drivers/gpu/drm/verisilicon/vs_dc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index 9729b693d360..fd1f5fe67a68 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
> dev_err(dev, "can't get axi clock\n");
> return PTR_ERR(dc->axi_clk);
> }
>
> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
> if (IS_ERR(dc->ahb_clk)) {
> dev_err(dev, "can't get ahb clock\n");
> return PTR_ERR(dc->ahb_clk);
^ permalink raw reply
* Re: [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: Icenowy Zheng @ 2026-06-26 8:02 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625094449.708386-4-a0987203069@gmail.com>
在 2026-06-25四的 17:44 +0800，Joey Lu写道：
> The DC8200 and DCUltraLite share a broadly similar register layout
> but
> differ in how the bridge, CRTC, primary plane and IRQ paths are
> driven.
> Introduce a vs_dc_funcs vtable so each variant can supply its own
> implementation without scattering conditionals across multiple files.
>
> Add a generation field to struct vs_chip_identity to distinguish
> variants.
> Extract the DC8200-specific hardware ops into vs_dc8200.c and add
> unified
> IRQ bit definitions so implementations can translate hardware-
> specific
> bits to a common set. Update the shared code to dispatch through
> dc->funcs.
>
> No behaviour change for existing DC8200 platforms.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
> drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
> drivers/gpu/drm/verisilicon/vs_dc.c | 6 +-
> drivers/gpu/drm/verisilicon/vs_dc.h | 32 +++++
> drivers/gpu/drm/verisilicon/vs_dc8200.c | 115
> ++++++++++++++++++
> drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
> drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
> 11 files changed, 214 insertions(+), 54 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> index 426f4bcaa834..9d4cd16452fa 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o
> vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_drm.o vs_hwdb.o \
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
> b/drivers/gpu/drm/verisilicon/vs_bridge.c
> index dc7c85b07fe3..3fbc8d57f8a1 100644
> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> @@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct
> vs_crtc *crtc,
> VSDC_DISP_PANEL_CONFIG_DE_EN |
> VSDC_DISP_PANEL_CONFIG_DAT_EN |
> VSDC_DISP_PANEL_CONFIG_CLK_EN);
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> - VSDC_DISP_PANEL_CONFIG_RUNNING);
> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_RUNNING(output));
> -
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
> >id),
> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> +
> + dc->funcs->panel_enable_ex(dc, output);
> }
>
> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
> @@ -228,14 +221,7 @@ static void vs_bridge_atomic_disable(struct
> drm_bridge *bridge,
> struct vs_dc *dc = crtc->dc;
> unsigned int output = crtc->id;
>
> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
> - VSDC_DISP_PANEL_START_RUNNING(output));
> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> - VSDC_DISP_PANEL_CONFIG_RUNNING);
> -
> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
> >id),
> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> + dc->funcs->panel_disable_ex(dc, output);
> }
>
> static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
> b/drivers/gpu/drm/verisilicon/vs_crtc.c
> index 0b8a35d09cd2..1c4aac708669 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> @@ -16,10 +16,33 @@
> #include "vs_crtc_regs.h"
> #include "vs_crtc.h"
> #include "vs_dc.h"
> -#include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> #include "vs_plane.h"
>
> +static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
> + struct drm_atomic_commit *state)
> +{
> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> + struct vs_dc *dc = vcrtc->dc;
> + unsigned int output = vcrtc->id;
> +
> + if (dc->funcs->crtc_begin)
> + dc->funcs->crtc_begin(dc, output);
> +}
> +
> +static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
> + struct drm_atomic_commit *state)
> +{
> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> + struct vs_dc *dc = vcrtc->dc;
> + unsigned int output = vcrtc->id;
> +
> + if (dc->funcs->crtc_flush)
> + dc->funcs->crtc_flush(dc, output);
> +
> + drm_crtc_vblank_atomic_flush(crtc, state);
> +}
> +
> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
> struct drm_atomic_commit *state)
> {
> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc
> *crtc,
> drm_crtc_vblank_off(crtc);
>
> clk_disable_unprepare(dc->pix_clk[output]);
> +
> + if (dc->funcs->crtc_disable_ex)
> + dc->funcs->crtc_disable_ex(dc, output);
> }
>
> static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
> @@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc
> *crtc,
> drm_WARN_ON(&dc->drm_dev->base,
> clk_prepare_enable(dc->pix_clk[output]));
>
> + if (dc->funcs->crtc_enable_ex)
> + dc->funcs->crtc_enable_ex(dc, output);
> +
> drm_crtc_vblank_on(crtc);
> }
>
> @@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc
> *crtc,
> }
>
> static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
> - .atomic_flush = drm_crtc_vblank_atomic_flush,
> + .atomic_begin = vs_crtc_atomic_begin,
> + .atomic_flush = vs_crtc_atomic_flush,
> .atomic_enable = vs_crtc_atomic_enable,
> .atomic_disable = vs_crtc_atomic_disable,
> .mode_set_nofb = vs_crtc_mode_set_nofb,
> @@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc
> *crtc)
> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
> + dc->funcs->enable_vblank(dc, vcrtc->id);
>
> return 0;
> }
> @@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct
> drm_crtc *crtc)
> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
> + dc->funcs->disable_vblank(dc, vcrtc->id);
> }
>
> static const struct drm_crtc_funcs vs_crtc_funcs = {
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index dad9967bc10b..9729b693d360 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -8,9 +8,7 @@
> #include <linux/of.h>
> #include <linux/of_graph.h>
>
> -#include "vs_crtc.h"
> #include "vs_dc.h"
> -#include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> #include "vs_hwdb.h"
>
> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
> *private)
> struct vs_dc *dc = private;
> u32 irqs;
>
> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
> + irqs = dc->funcs->irq_ack(dc);
>
> vs_drm_handle_irq(dc, irqs);
>
> @@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> + dc->funcs = &vs_dc8200_funcs;
> +
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW
> capability\n");
> ret = -EINVAL;
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index ed1016f18758..825f5dd6bf17 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -14,6 +14,7 @@
> #include <linux/reset.h>
>
> #include <drm/drm_device.h>
> +#include <drm/drm_plane.h>
>
> #include "vs_hwdb.h"
>
> @@ -22,6 +23,34 @@
>
> struct vs_drm_dev;
> struct vs_crtc;
> +struct vs_dc;
> +
> +struct vs_dc_funcs {
> + /* Bridge: atomic_enable, atomic_disable */
> + void (*panel_enable_ex)(struct vs_dc *dc, unsigned int
> output);
> + void (*panel_disable_ex)(struct vs_dc *dc, unsigned int
> output);
> +
> + /* CRTC: atomic_begin, atomic_flush */
> + void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
> + void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
> +
> + /* CRTC: atomic_enable, atomic_disable */
> + void (*crtc_enable_ex)(struct vs_dc *dc, unsigned int
> output);
> + void (*crtc_disable_ex)(struct vs_dc *dc, unsigned int
> output);
> +
> + /* CRTC: enable_vblank, disable_vblank */
> + void (*enable_vblank)(struct vs_dc *dc, unsigned int
> output);
> + void (*disable_vblank)(struct vs_dc *dc, unsigned int
> output);
> +
> + /* Primary plane: atomic_enable, atomic_disable,
> atomic_update */
> + void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned
> int output);
> + void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned
> int output);
> + void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned
> int output,
> + struct drm_plane_state
> *state);
> +
> + /* IRQ acknowledge */
> + u32 (*irq_ack)(struct vs_dc *dc);
> +};
>
> struct vs_dc {
> struct regmap *regs;
> @@ -33,6 +62,9 @@ struct vs_dc {
>
> struct vs_drm_dev *drm_dev;
> struct vs_chip_identity identity;
> + const struct vs_dc_funcs *funcs;
> };
>
> +extern const struct vs_dc_funcs vs_dc8200_funcs;
> +
> #endif /* _VS_DC_H_ */
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c
> b/drivers/gpu/drm/verisilicon/vs_dc8200.c
> new file mode 100644
> index 000000000000..17378f4ef96d
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
> + */
> +
> +#include <linux/regmap.h>
> +
> +#include "vs_bridge_regs.h"
> +#include "vs_dc.h"
> +#include "vs_dc_top_regs.h"
> +#include "vs_drm.h"
> +#include "vs_plane.h"
> +#include "vs_primary_plane_regs.h"
> +
> +static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> + VSDC_DISP_PANEL_CONFIG_RUNNING);
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
> + VSDC_DISP_PANEL_START_RUNNING(output));
> +
> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> +}
> +
> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> + VSDC_DISP_PANEL_CONFIG_RUNNING);
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
> + VSDC_DISP_PANEL_START_RUNNING(output));
> +
> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> +}
> +
> +static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_COMMIT);
> +}
> +
> +static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc,
> unsigned int output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
> + regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
> + VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
> +
> + vs_dc8200_plane_commit(dc, output);
> +}
> +
> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc,
> unsigned int output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
> +
> + vs_dc8200_plane_commit(dc, output);
> +}
> +
> +static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc,
> unsigned int output,
> + struct drm_plane_state
> *state)
> +{
> + regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
> + VSDC_MAKE_PLANE_POS(state->crtc_x, state-
> >crtc_y));
> + regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
> + VSDC_MAKE_PLANE_POS(state->crtc_x + state-
> >crtc_w,
> + state->crtc_y + state-
> >crtc_h));
> + regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
> + VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
> +
> + vs_dc8200_plane_commit(dc, output);
> +}
> +
> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
Maybe add a drm_WARN_ONCE for unknown hardware IRQ bit?
Well, with this addressed,
```
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
```
Thanks,
Icenowy
> +
> + return unified;
> +}
> +
> +const struct vs_dc_funcs vs_dc8200_funcs = {
> + .panel_enable_ex = vs_dc8200_panel_enable_ex,
> + .panel_disable_ex =
> vs_dc8200_panel_disable_ex,
> + .enable_vblank = vs_dc8200_enable_vblank,
> + .disable_vblank =
> vs_dc8200_disable_vblank,
> + .primary_plane_enable_ex =
> vs_dc8200_primary_plane_enable_ex,
> + .primary_plane_disable_ex =
> vs_dc8200_primary_plane_disable_ex,
> + .primary_plane_update_ex =
> vs_dc8200_primary_plane_update_ex,
> + .irq_ack = vs_dc8200_irq_ack,
> +};
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c
> b/drivers/gpu/drm/verisilicon/vs_drm.c
> index fd259d53f49f..24e9d0b008f3 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.c
> @@ -25,7 +25,6 @@
> #include "vs_bridge.h"
> #include "vs_crtc.h"
> #include "vs_dc.h"
> -#include "vs_dc_top_regs.h"
> #include "vs_drm.h"
>
> #define DRIVER_NAME "verisilicon"
> @@ -168,8 +167,8 @@ void vs_drm_handle_irq(struct vs_dc *dc, u32
> irqs)
> unsigned int i;
>
> for (i = 0; i < dc->identity.display_count; i++) {
> - if (irqs & VSDC_TOP_IRQ_VSYNC(i)) {
> - irqs &= ~VSDC_TOP_IRQ_VSYNC(i);
> + if (irqs & VSDC_IRQ_VSYNC(i)) {
> + irqs &= ~VSDC_IRQ_VSYNC(i);
> if (dc->drm_dev->crtcs[i])
> drm_crtc_handle_vblank(&dc->drm_dev-
> >crtcs[i]->base);
> }
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.h
> b/drivers/gpu/drm/verisilicon/vs_drm.h
> index 606338206a42..6a89c20879df 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.h
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.h
> @@ -6,6 +6,7 @@
> #ifndef _VS_DRM_H_
> #define _VS_DRM_H_
>
> +#include <linux/bits.h>
> #include <linux/platform_device.h>
> #include <linux/types.h>
>
> @@ -13,6 +14,13 @@
>
> struct vs_dc;
>
> +/*
> + * DC variants use different interrupt registers with diverging bit
> + * assignments; each irq_ack() implementation must translate its
> + * hardware-specific bits into these definitions.
> + */
> +#define VSDC_IRQ_VSYNC(n) BIT(n)
> +
> struct vs_drm_dev {
> struct drm_device base;
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 2a0f7c59afa3..91524d16f778 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -94,6 +94,7 @@ static struct vs_chip_identity vs_chip_identities[]
> = {
> .revision = 0x5720,
> .customer_id = ~0U,
>
> + .generation = VSDC_GEN_DC8200,
> .display_count = 2,
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> @@ -103,6 +104,7 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .revision = 0x5721,
> .customer_id = 0x30B,
>
> + .generation = VSDC_GEN_DC8200,
> .display_count = 2,
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> @@ -112,6 +114,7 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .revision = 0x5720,
> .customer_id = 0x310,
>
> + .generation = VSDC_GEN_DC8200,
> .display_count = 2,
> .max_cursor_size = 64,
> .formats = &vs_formats_with_yuv444,
> @@ -121,6 +124,7 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .revision = 0x5720,
> .customer_id = 0x311,
>
> + .generation = VSDC_GEN_DC8200,
> .display_count = 2,
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> index 2065ecb73043..a15c8b565604 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> @@ -9,6 +9,11 @@
> #include <linux/regmap.h>
> #include <linux/types.h>
>
> +enum vs_dc_generation {
> + VSDC_GEN_DC8000,
> + VSDC_GEN_DC8200,
> +};
> +
> struct vs_formats {
> const u32 *array;
> unsigned int num;
> @@ -19,6 +24,7 @@ struct vs_chip_identity {
> u32 revision;
> u32 customer_id;
>
> + enum vs_dc_generation generation;
> u32 display_count;
> /*
> * The hardware only supports square cursor planes, so this
> field
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> index 1f2be41ae496..f992cb277f61 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> @@ -53,12 +53,6 @@ static int vs_primary_plane_atomic_check(struct
> drm_plane *plane,
> return 0;
> }
>
> -static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int
> output)
> -{
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_COMMIT);
> -}
> -
> static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
> struct drm_atomic_commit
> *atomic_state)
> {
> @@ -69,13 +63,8 @@ static void vs_primary_plane_atomic_enable(struct
> drm_plane *plane,
> unsigned int output = vcrtc->id;
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_FB_EN);
> - regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
> - VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
> -
> - vs_primary_plane_commit(dc, output);
> + if (dc->funcs->primary_plane_enable_ex)
> + dc->funcs->primary_plane_enable_ex(dc, output);
> }
>
> static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
> @@ -88,10 +77,8 @@ static void vs_primary_plane_atomic_disable(struct
> drm_plane *plane,
> unsigned int output = vcrtc->id;
> struct vs_dc *dc = vcrtc->dc;
>
> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> - VSDC_FB_CONFIG_EX_FB_EN);
> -
> - vs_primary_plane_commit(dc, output);
> + if (dc->funcs->primary_plane_disable_ex)
> + dc->funcs->primary_plane_disable_ex(dc, output);
> }
>
> static void vs_primary_plane_atomic_update(struct drm_plane *plane,
> @@ -133,18 +120,11 @@ static void
> vs_primary_plane_atomic_update(struct drm_plane *plane,
> regmap_write(dc->regs, VSDC_FB_STRIDE(output),
> fb->pitches[0]);
>
> - regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
> - VSDC_MAKE_PLANE_POS(state->crtc_x, state-
> >crtc_y));
> - regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
> - VSDC_MAKE_PLANE_POS(state->crtc_x + state-
> >crtc_w,
> - state->crtc_y + state-
> >crtc_h));
> regmap_write(dc->regs, VSDC_FB_SIZE(output),
> VSDC_MAKE_PLANE_SIZE(state->crtc_w, state-
> >crtc_h));
>
> - regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
> - VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
> -
> - vs_primary_plane_commit(dc, output);
> + if (dc->funcs->primary_plane_update_ex)
> + dc->funcs->primary_plane_update_ex(dc, output,
> state);
> }
>
> static const struct drm_plane_helper_funcs
> vs_primary_plane_helper_funcs = {
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Bartosz Golaszewski @ 2026-06-26 7:59 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang, Yu-Chun Lin
Cc: Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, linux-realtek-soc, cy.huang, stanley_chang,
james.tai
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
On Mon, 22 Jun 2026 17:23:31 +0800, Yu-Chun Lin wrote:
> This series adds GPIO support for the Realtek DHC RTD1625 SoC.
>
> Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
> the RTD1625 features a per-pin register architecture where each GPIO line
> is managed by its own dedicated 32-bit control register. This distinct
> hardware design requires a new, separate driver.
>
> [...]
Applied, thanks!
[1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
https://git.kernel.org/brgl/c/8f32808e1530b2229e07695fb39c54fee910bd4a
[2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
https://git.kernel.org/brgl/c/b5d23fcdb12972c522e96f90ab48be8a0d971b0e
[3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
https://git.kernel.org/brgl/c/a57e27c43b0315ee86c6896510d69be5257e093e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-06-26 7:58 UTC (permalink / raw)
To: Conor Dooley, Conor Dooley
Cc: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, ychuang3, schung, yclu4, dri-devel,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626-zit-amuck-e743e58d2e15@wendy>
在 2026-06-26五的 08:22 +0100，Conor Dooley写道：
> On Thu, Jun 25, 2026 at 05:33:37PM +0100, Conor Dooley wrote:
> > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > The verisilicon,dc binding was originally written for the T-Head
> > > TH1520
> > > SoC carrying a DC8200, and hard-codes five clocks, three resets
> > > and two
> > > output ports.
> > >
> > > Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the
> > > binding.
> > > The DCUltraLite uses only two clocks (core, pix0) and one reset
> > > (core),
> > > with a single output port.
> > >
> > > Use allOf/if blocks to express per-variant constraints rather
> > > than
> > > hard-coding the DC8200 topology at the top level. Each
> > > compatible's
> > > block constrains the clock and reset item counts; the nuvoton
> > > block
> > > additionally overrides clock-names to the two names it actually
> > > uses.
> > >
> > > Signed-off-by: Joey Lu <a0987203069@gmail.com>
> > > ---
> > > .../bindings/display/verisilicon,dc.yaml | 57
> > > +++++++++++++++++++
> > > 1 file changed, 57 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > index 9dc35ab973f2..1e751f3c7ce8 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > +++
> > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > @@ -17,6 +17,7 @@ properties:
> > > items:
> > > - enum:
> > > - thead,th1520-dc8200
> > > + - nuvoton,ma35d1-dcu
> > > - const: verisilicon,dc # DC IPs have discoverable
> > > ID/revision registers
> > >
> > > reg:
> > > @@ -77,6 +78,62 @@ required:
> > > - clock-names
> > > - ports
> > >
> > > +allOf:
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: thead,th1520-dc8200
> > > + then:
> > > + properties:
> > > + clocks:
> > > + minItems: 5
> > > + maxItems: 5
> > > +
> > > + clock-names:
> > > + minItems: 5
> > > + maxItems: 5
> >
> > All the maxItems here repeat the maximum constraint and do nothing.
> >
> > Since you didn't change the minimum constraint at the top level,
> > your
> > minItems also do nothing.
> >
> > > +
> > > + resets:
> > > + minItems: 3
> > > + maxItems: 3
> > > +
> > > + reset-names:
> > > + minItems: 3
> > > + maxItems: 3
> > > +
> > > + required:
> > > + - resets
> > > + - reset-names
> >
> > Both conditional sections have this, but the original binding
> > doesn't
> > require these for the thead device. This is a functional change
> > therefore and shouldn't be in a patch calling itself "generalise
> > for
> > single ended variants".
> >
> > FWIW, adding your new compatible shouldn't really be in a patch
> > with
> > that subject either, it really should say "add support for nuvoton
> > ma35d1" or something.
> >
> > > +
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: nuvoton,ma35d1-dcu
> > > + then:
> > > + properties:
> > > + clocks:
> > > + minItems: 2
> >
> > Anything that updates the minimum constraint should be done at the
> > top
> > level of this schema. The conditional section should then tighten
> > the
> > constraint, in this case that means only having maxItems.
> >
> > > + maxItems: 2
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: core
> > > + - const: pix0
> >
> > Does this even work when the top level schema thinks clock 2 should
> > be
> > called axi?
>
> Additionally here, only have core and pix0 seems like it might be an
> oversimplification. I doubt removing the second output port means
> that
> the axi and ahb clocks are no longer needed.
> Is it the case that your device supplies the same clock to core, ahb
> and
> axi? If so, then you should fill those clocks in in your devicetree
> and
> this can just constrain the number of clocks/clock-names to 4.
The clock controller of that SoC is quite weird -- it has only a single
gate bit, but controlling 3 clock gates. All core, ahb and axi clocks
have gates controlled by this single bit, so it's why currently it's
modelled as only core clock supplied.
Well it might be worthful to supply the bus clock before the gate as
ahb/axi, especially axi, because both the AXI clock and the core clock
constraints the maximum pixel clock.
Thanks,
Icenowy
>
> >
> > > +
> > > + resets:
> > > + minItems: 1
> > > + maxItems: 1
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: core
> >
> > This is just maxItems: 1.
> >
> > pw-bot: changes-requested
> >
> > Thanks,
> > Conor.
> >
> > > +
> > > + required:
> > > + - resets
> > > + - reset-names
> > > +
> > > additionalProperties: false
> > >
> > > examples:
> > > --
> > > 2.43.0
> > >
>
^ permalink raw reply
* Re: (subset) [PATCH 0/3] gpio: rockchip: Fix generic IRQ chip leak and modernize resource mapping
From: Bartosz Golaszewski @ 2026-06-26 7:54 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Marco Scardovi
Cc: Bartosz Golaszewski, Heiko Stuebner, Jianqun Xu, linux-gpio,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260607230504.35392-1-scardracs@disroot.org>
On Mon, 08 Jun 2026 01:05:01 +0200, Marco Scardovi wrote:
> This series fixes a generic IRQ chip leak in the gpio-rockchip driver
> and performs two small cleanups to use standard platform device helper APIs.
>
> Patch 1 fixes a leak caused by generic IRQ chips not being removed before
> IRQ domain teardown.
>
> Patch 2 converts register mapping to use devm_platform_ioremap_resource().
>
> [...]
Applied, thanks!
[2/3] gpio: rockchip: use devm_platform_ioremap_resource() to map registers
https://git.kernel.org/brgl/c/c03c6a086d188dc5b52e7db2b2991ecead9bb669
[3/3] gpio: rockchip: use platform_get_irq() to retrieve interrupt
https://git.kernel.org/brgl/c/c2e26f2408226de7464ba4cdcd86827e0a000db9
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* RE: [PATCH] mailbox: imx: return TXDB_V2 timeout errors
From: Peng Fan @ 2026-06-26 7:50 UTC (permalink / raw)
To: Pengpeng Hou, Jassi Brar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260624143707.49344-1-pengpeng@iscas.ac.cn>
> Subject: [PATCH] mailbox: imx: return TXDB_V2 timeout errors
Same issue:
https://lore.kernel.org/all/20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de/
Regards
Peng.
>
> imx_mu_generic_tx() retries TXDB_V2 doorbell sends until the GIR bit
> clears, but falls through to the common success return even when
> every
> readl_poll_timeout() attempt failed.
>
> Return the final timeout error after the retry loop so mailbox clients
> can observe a failed doorbell send instead of treating it as successful.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/mailbox/imx-mailbox.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-
> mailbox.c index 246a9a9e3..86a8a590b 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -253,6 +253,8 @@ static int imx_mu_generic_tx(struct
> imx_mu_priv *priv,
> cp->type,
> ++count);
> }
> }
> + if (ret)
> + return ret;
> break;
> default:
> dev_warn_ratelimited(priv->dev, "Send data on wrong
> channel type: %d\n", cp->type);
> --
> 2.50.1 (Apple Git-155)
>
^ permalink raw reply
* Re: [PATCH v5 1/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Sebastian Ene @ 2026-06-26 7:48 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, maz, oupton, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <aj0qOFO3pRA-U_mL@willie-the-truck>
On Thu, Jun 25, 2026 at 02:16:40PM +0100, Will Deacon wrote:
> Hi all,
>
> On Tue, Jun 23, 2026 at 11:53:48AM +0000, Sebastian Ene wrote:
> > Introduce a helper method ffa_check_unused_args_sbz to enforce strict
> > arguments checking when the hypervisor acts as a relayer between the
> > host and Trustzone.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 54 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 1af722771178..78bb043b33ee 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -71,6 +71,20 @@ static u32 hyp_ffa_version;
> > static bool has_version_negotiated;
> > static hyp_spinlock_t version_lock;
> >
> > +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> > +{
> > + DECLARE_REG(u32, func_id, ctxt, 0);
> > + int reg, end_reg;
> > +
> > + end_reg = ARM_SMCCC_IS_64(func_id) ? 17 : 7;
> > + for (reg = first_reg; reg <= end_reg; reg++) {
> > + if (cpu_reg(ctxt, reg))
> > + return true;
> > + }
> > +
> > + return false;
> > +}
Hello Will,
>
> Seb and I tried taking this for a spin on some Android devices and, sadly,
> it leads to fireworks. The reason is that the FF-A spec quietly changed
> the list of unused parameter registers for 64-bit SMCs from v1.1 to v1.2
> of the spec so that pre-existing calls were affected.
>
> For example, in v1.1 a 64-bit RXTX_MAP only has x4-x7 as MBZ, whereas in
> v1.2 the same call has x4-x17 as SBZ.
>
> We can follow the spec by predicating the additional check on the FF-A
> version being >= 1.2, but I'm not hopeful that existing drivers are
> compliant. I also suggest moving this patch to the end of the series in
> case we need to revert it.
I spinned up a new series (v6) which moves the check at the end of the
series and I made it so that it takes the ff-a version into account.
https://lore.kernel.org/all/20260626074545.433234-1-sebastianene@google.com/
>
> Cheers,
>
> Will
Thanks
Sebastian
^ 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