* Re: [PATCH 4/6] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Marc Zyngier @ 2026-06-15 9:01 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-5-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:08 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> We have a lot of logs containing ITS address info which is helpful to
> distiguish which ITS occurs error. Just add ITS address info into more
> exsiting error logs.
That's only useful on buggy HW, for people debugging it. I don't think
that's useful outside of these scenarios, and this hack can live out
of tree.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v1 0/4] trace_hyp_printk() for pKVM/nVHE hypervisor
From: Fuad Tabba @ 2026-06-15 8:57 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <CA+EHjTxG8dK8o7GmoH9hg1p0h5W7H8EnNt1ZwRRXQcNad7R1pw@mail.gmail.com>
On Mon, 15 Jun 2026 at 09:30, Fuad Tabba <tabba@google.com> wrote:
>
> On Mon, 15 Jun 2026 at 09:28, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > On Sun, Jun 14, 2026 at 01:57:56PM +0100, Fuad Tabba wrote:
> > > Hi Vincent,
> > >
> > > On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > This series adds a hypervisor event "hyp_printk" which enables
> > > > developers to log pretty much anything into the hypervisor tracing
> > > > buffer, just like the kernel function trace_printk().
> > > >
> > > > This enables rich logging from the hypervisor, while leaving all the
> > > > string parsing burden to the kernel. This has been the main way of
> > > > debugging pKVM in Android.
> > >
> > > I tested the series on v7.1-rc7 under QEMU (cortex-a53 CPU, pKVM nVHE):
> > > - Booted a host under pKVM with a non-protected kvmtool guest (npVM)
> > > and a protected kvmtool guest (pVM).
> > > - Functional test: added a temporary trace_hyp_printk() call site in
> > > handle___kvm_vcpu_run() with 0-arg, 1-arg, and 2-arg calls. Mounted
> > > tracefs, enabled the hyp_printk event, ran a kvmtool guest to trigger
> > > vcpu_run, read the trace buffer. All expected entries appeared with
> > > correctly formatted output.
> >
> > Thanks for the testing!
> >
> > >
> > > One question: kvm_hyp_trace_init() returns early when
> > > is_kernel_in_hyp_mode() is true. On VHE-capable hardware, pKVM uses
> > > hVHE. So it seams that the entire hyp tracing subsystem (not just
> > > hyp_printk) is non-functional in hVHE mode. Is hVHE support
> > > intentionally deferred?
> >
> > You got me scared for a moment but I did try hVHE and it seems alright:
> >
> > [ 5.369985] kvm [1]: Protected hVHE mode initialized successfully
> >
> > $ ls /sys/kernel/tracing/remotes/hypervisor/
> >
> > is_kernel_in_hyp_mode() just checks if the kernel is running at EL2 which it
> > shouldn't in the hVHE case?
>
> I'll try again and report back, must be user error.
Confirmed, user error. I must have messed something up with the hVHE test.
My Tested-by for the series covers that now too.
Sorry for the noise.
/fuad
>
> /fuad
>
> >
> > >
> > > Cheers,
> > > /fuad
> > >
> > > >
> > > > Even though not strictly related to trace_hyp_printk, I have added the
> > > > following two patches:
> > > >
> > > > * KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > > >
> > > > This one mainly intends to support one of the new features I have
> > > > posted here [1], which allows to enable tracing as early as
> > > > possible. I have added it here to limit cross-posting.
> > > >
> > > > * KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > > >
> > > > This one is just a cleanup.
> > > >
> > > > [1] https://lore.kernel.org/all/20260605163825.1762953-1-vdonnefort@google.com/
> > > >
> > > > Vincent Donnefort (4):
> > > > KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > > > KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > > > tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
> > > > KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
> > > >
> > > > arch/arm64/include/asm/kvm_asm.h | 4 +-
> > > > arch/arm64/include/asm/kvm_hypevents.h | 14 ++++
> > > > arch/arm64/include/asm/kvm_hyptrace.h | 8 +++
> > > > arch/arm64/kernel/image-vars.h | 1 +
> > > > arch/arm64/kernel/vmlinux.lds.S | 4 ++
> > > > .../define_hypevents.h} | 0
> > > > .../kvm/hyp/include/nvhe/define_events.h | 2 -
> > > > arch/arm64/kvm/hyp/include/nvhe/trace.h | 65 +++++++++++++++++++
> > > > arch/arm64/kvm/hyp/nvhe/events.c | 6 ++
> > > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> > > > arch/arm64/kvm/hyp_trace.c | 60 ++++++++++++++++-
> > > > include/trace/define_remote_events.h | 19 +++++-
> > > > 12 files changed, 176 insertions(+), 9 deletions(-)
> > > > rename arch/arm64/{include/asm/kvm_define_hypevents.h => kvm/define_hypevents.h} (100%)
> > > >
> > > >
> > > > base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> > > > --
> > > > 2.54.0.1136.gdb2ca164c4-goog
> > > >
^ permalink raw reply
* Re: [PATCH v4 5/6] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Icenowy Zheng @ 2026-06-15 8:57 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: <20260615065003.76661-6-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> Register the Nuvoton MA35D1 DCUltraLite chip identity in
> vs_chip_identities[]:
> model = 0x0 (DCUltraLite; Verisilicon uses 0 for this IP)
> revision = 0x5560
> customer_id = 0x305
> generation = VSDC_GEN_DC8000
> display_count = 1
> max_cursor_size = 32
I suggest make this more human-readable instead of replicating the
machine-readable data of HWDB.
My proposal here:
```
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.
```
>
> Placing this entry last makes it the gate that enables MA35D1
> hardware
> recognition only after all the supporting ops and DT binding changes
> are
> in place.
It's a little ambiguous that "last" here means whether the last in the
patchset or the last in the HWDB array, although I think it's not so
needed to explain the reason of the place in the patchset.
I propose just say `Adding it to the HWDB to enable it to be usable
with the verisilicon driver.` .
>
> 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,
> + },
> };
>
> int vs_fill_chip_identity(struct regmap *regs,
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: David Laight @ 2026-06-15 8:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, stable, Russell King,
Russell King (Oracle), Arnd Bergmann, Linus Walleij, Kees Cook,
Nathan Chancellor, Thomas Weissschuh, Peter Zijlstra,
Shubham Bansal, David S. Miller
In-Reply-To: <CADkSEUizT2dxUni185QDEkmVA+_r9bEQgbuEbZ8b-Sg3JZWrFA@mail.gmail.com>
On Sun, 14 Jun 2026 14:44:38 -0700
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> Hi, David,
>
> On Sun, Jun 14, 2026 at 4:58 AM David Laight
> <david.laight.linux@gmail.com> wrote:
> > Isn't it more the case that the ldrh/strh instructions were added for armv4.
> > Whether the bus supports 16bit accesses is entirely different.
>
> No, it is in fact the bus. While the Risc PC initially shipped with
> ARMv3 CPUs, which the kernel no longer supports, it was later upgraded
> to an ARMv4 StrongARM CPU. However, its bus was designed for ARMv3
> CPUs and has no way to represent a half-word access to memory. This
> means that ldrh/strh will execute (because the CPU supports them) but
> do not function as intended.
Ok, so they work fine for cached accesses.
The only issue will be with uncached ones?
(Or do I remember the strongarm having a write-through cache?)
It just seems odd because byte writes are usually handled with four
byte-enable lines; so the targets support all 16 combinations even
though a cpu will (normally) only be able to generate 8 of them.
David
>
> Ethan
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Marc Zyngier @ 2026-06-15 8:59 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-3-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:06 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Fix collection leak when its_init_domain() failed in its_probe_one().
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 2b7b546c43c8..df26ddc97ae2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
> return 0;
> }
>
> +static void its_free_collections(struct its_node *its)
> +{
> + kfree(its->collections);
> + its->collections = NULL;
> +}
Why do we need an extra helper for something that has a single calling
spot? Why is it important to set collections to NULL, given that we're
about to free the structure without even looking further?
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Jinjie Ruan @ 2026-06-15 8:51 UTC (permalink / raw)
To: Michael Kelley, catalin.marinas@arm.com, will@kernel.org,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <SN6PR02MB41575306521E6223561F476FD4182@SN6PR02MB4157.namprd02.prod.outlook.com>
On 6/12/2026 11:45 PM, Michael Kelley wrote:
> From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
>>
>> Support for parallel secondary CPU bringup is already utilized by x86,
>> MIPS, and RISC-V. This patch brings this capability to the arm64
>> architecture.
>>
>> Rework the global `secondary_data` accessed during early boot into
>> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
>> enabling the early boot code in head.S to resolve each secondary CPU's
>> logical ID concurrently.
>>
>> To fully enable HOTPLUG_PARALLEL, this patch implements:
>> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
>> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
>>
>> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
>>
>> | test kernel | secondary CPUs boot time |
>> | --------------------- | -------------------- |
>> | Without this patch | 155.672 |
>> | cpuhp.parallel=0 | 62.897 |
>> | cpuhp.parallel=1 | 166.703 |
>
> The last two rows seem mixed up. I would expect parallel=0 to
> result in a longer boot time.
Hi, Michael,
The results are correct and not mixed up.
Compared to the original non‑HOTPLUG_PARALLEL approach, the advantage of
cpuhp.parallel=0 lies in its use of cpu_relax(`yield` on arm64) instead
of the wait_for_completion_timeout() mechanism (which may cause sleep
and context switching). This significantly reduces the overhead of VM
exits and context switches in a KVM guest, thereby cutting the secondary
CPU boot time by more than half.
Regarding cpuhp.parallel=1, I believe the reason it fails to optimize
boot time is that when a large number of CPUs issue the KICK_AP call
simultaneously, it results in severe lock contention within KVM, which
paradoxically slows down secondary CPU bringup. However, this needs
further investigation into the PSCI_CPU_ON code in KVM.
I'm testing these performance aspects on physical hardware, so the
results might be somewhat different because secondary CPU bringup
requires trapping into the ATF firmware.
Best regards,
Jinjie
>
> Michael
>
>>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/smp.h | 8 ++++++++
>> arch/arm64/kernel/head.S | 23 +++++++++++++++++++++++
>> arch/arm64/kernel/smp.c | 27 +++++++++++++++++++++++++++
>> 4 files changed, 59 insertions(+)
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 4/6] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Icenowy Zheng @ 2026-06-15 8:51 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: <20260615065003.76661-5-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
> controller 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. Per-frame commit cycle: DCUltraLite requires the VALID bit in
> FB_CONFIG to be set at the start of each atomic commit
> (crtc_begin)
> and cleared after (crtc_flush).
>
> 5. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required. Make axi_clk and
> ahb_clk optional (devm_clk_get_optional_enabled) so DC8000 nodes
> without those clocks are handled gracefully.
>
> Add vs_dc8000.c implementing the vs_dc_funcs vtable for the above
> differences. The probe now selects vs_dc8000_funcs when the
> identified
> generation is VSDC_GEN_DC8000 (DCUltraLite reads model 0x0,
> revision 0x5560, customer_id 0x305).
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dc8000.c | 78
> +++++++++++++++++++++++++
> 4 files changed, 86 insertions(+), 4 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 9729b693d360..9499fffbca58 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");
Please make the clock change a separated patch for atomicity.
BTW the MA35D1 manual's clock tree shows that DCUltra appears on AXI2
ACLK, AHB_HCLK2, behind a mux of SYS-PLL/EPLL-DIV2 (which seems to be
the core clock), and behind a divider (which seems to be the pixel
clock).
However it's weird that only one DCUltra Clock Enable Bit exists
despite both bus clocks have "ICG" (I think it means "Integrated Clock
Gating"). In addition the linux clk-ma35d1 driver assigns "dcu_gate" as
a downstream of "dcu_mux", although the Figure 6.5-2 in the TRM shows
no ICG after the "Display core CLK" mux.
Is the two bus clocks controlled by a single gate bit, and is the bit
also gating DC core clock?
Thanks,
Icenowy
> if (IS_ERR(dc->ahb_clk)) {
> dev_err(dev, "can't get ahb clock\n");
> return PTR_ERR(dc->ahb_clk);
> @@ -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 544e1a37065b..5218e8cf63e2 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..be0c0d7baf52
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,78 @@
> +// 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_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(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(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 irqs;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
> + return irqs;
> +}
> +
> +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 = vs_dc8000_crtc_enable,
> + .crtc_disable = vs_dc8000_crtc_disable,
> + .enable_vblank = vs_dc8000_enable_vblank,
> + .disable_vblank = vs_dc8000_disable_vblank,
> + .irq_ack = vs_dc8000_irq_ack,
> +};
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Marc Zyngier @ 2026-06-15 8:52 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260615032910.54735-2-shikemeng@huaweicloud.com>
On Mon, 15 Jun 2026 04:29:05 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
Typo.
> error handling code to make it a little simpler.
No. Please don't mix fixes and (totally pointless) refactoring.
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8d..2b7b546c43c8 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> {
> unsigned long *bitmap = NULL;
> - int err = 0;
>
> do {
> - err = alloc_lpi_range(nr_irqs, base);
> + int err = alloc_lpi_range(nr_irqs, base);
> if (!err)
> break;
>
> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> } while (nr_irqs > 0);
>
> if (!nr_irqs)
> - err = -ENOSPC;
> -
> - if (err)
> - goto out;
> + goto err_out;
>
> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
> if (!bitmap)
> - goto out;
> + goto err_free_lpi;
>
> *nr_ids = nr_irqs;
> -
> -out:
> - if (!bitmap)
> - *base = *nr_ids = 0;
> -
> return bitmap;
> +
> +err_free_lpi:
> + free_lpi_range(*base, nr_irqs);
> +err_out:
> + *base = *nr_ids = 0;
> + return NULL;
> }
>
> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
Honestly, I question the validity of handling errors this way. You are
already unable to allocate a per-device bitmap. And yet you are
calling free_lpi_range(), which has the interesting property of
*allocating* memory. Which you don't have. Oh wait...
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v3 3/3] ufs: core: Remove max_num_rtt field from ufs_hba_variant_ops
From: Peter Wang (王信友) @ 2026-06-15 8:44 UTC (permalink / raw)
To: avri.altman@wdc.com, linux-scsi@vger.kernel.org,
Ed Tsai (蔡宗軒), bvanassche@acm.org,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
AngeloGioacchino Del Regno
Cc: linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Chun-Hung Wu (巫駿宏),
Naomi Chu (朱詠田),
linux-kernel@vger.kernel.org, wsd_upstream,
Alice Chao (趙珮均)
In-Reply-To: <20260615055802.105479-4-ed.tsai@mediatek.com>
On Mon, 2026-06-15 at 13:57 +0800, ed.tsai@mediatek.com wrote:
> From: Ed Tsai <ed.tsai@mediatek.com>
>
> Remove the max_num_rtt field from ufs_hba_variant_ops as it has been
> replaced by the get_hba_nortt() callback which provides more flexible
> platform-specific RTT capability handling.
>
> Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
> ---
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
^ permalink raw reply
* Re: [PATCH v3 1/3] ufs: core: Add get_hba_nortt callback for vendor-specific RTT capability
From: Peter Wang (王信友) @ 2026-06-15 8:44 UTC (permalink / raw)
To: avri.altman@wdc.com, linux-scsi@vger.kernel.org,
Ed Tsai (蔡宗軒), bvanassche@acm.org,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
AngeloGioacchino Del Regno
Cc: linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
Chun-Hung Wu (巫駿宏),
Naomi Chu (朱詠田),
linux-kernel@vger.kernel.org, wsd_upstream,
Alice Chao (趙珮均)
In-Reply-To: <20260615055802.105479-2-ed.tsai@mediatek.com>
On Mon, 2026-06-15 at 13:57 +0800, ed.tsai@mediatek.com wrote:
> From: Ed Tsai <ed.tsai@mediatek.com>
>
> The number of outstanding RTTs read from host controller capability
> register is problematic on some platforms. Add a new vendor callback
> get_hba_nortt() to allow platform vendors to override the default RTT
> capability value with platform-specific handling.
>
> This patch keeps max_num_rtt field for bisectability and will be
> removed
> in a later patch once all platforms are migrated.
>
> Signed-off-by: Ed Tsai <ed.tsai@mediatek.com>
> ---
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
^ permalink raw reply
* Re: [PATCH v4 3/6] drm/verisilicon: introduce per-variant hardware ops table
From: Icenowy Zheng @ 2026-06-15 8:37 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: <20260615065003.76661-4-a0987203069@gmail.com>
在 2026-06-15一的 14:50 +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 enum vs_dc_generation (VSDC_GEN_DC8000 / VSDC_GEN_DC8200) to
> vs_hwdb.h and a generation field to struct vs_chip_identity.
> Annotate
> all four existing DC8200 HWDB entries with VSDC_GEN_DC8200.
>
> Extract the DC8200-specific hardware ops into a new vs_dc8200.c:
> panel_enable_ex / panel_disable_ex - PANEL_CONFIG/START + CONFIG_EX
> commit
> enable_vblank / disable_vblank - TOP_IRQ_EN VSYNC bit
> primary_plane_enable_ex / disable_ex / update_ex - FB_CONFIG_EX
> path
> irq_ack - reads TOP_IRQ_ACK
>
> Update vs_bridge.c, vs_crtc.c, vs_primary_plane.c and vs_dc.c to
> dispatch through dc->funcs instead of directly touching registers.
> vs_crtc.c gains atomic_begin and atomic_flush hooks to allow variants
> to gate per-frame commit cycles.
>
> 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 | 107
> ++++++++++++++++++
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +-----
> 9 files changed, 196 insertions(+), 51 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 7a93049368db..6ff2ac745b15 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..679d6541ba1b 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)
> + dc->funcs->crtc_disable(dc, output);
Should this be `crtc_disable_ex` ? Because the clock-related operation
is shared.
> }
>
> 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)
> + dc->funcs->crtc_enable(dc, output);
Ditto for appending `_ex` .
> +
> 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);
The definition of bits in 0x0010 seems to be different to ones in
0x147C, although the first 2 bits are the same. (e.g. `BIT(2)` is
"cursor interrupt" in DC8000 0x147C but "secure reset done" in DC8200
0x0010).
Should some kind of translation be done in `irq_ack` ? (and add a
unified interrupt definition that aims to be the translation target).
Thanks,
Icenowy
>
> 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..544e1a37065b 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)(struct vs_dc *dc, unsigned int output);
> + void (*crtc_disable)(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..800df9279e9b
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
> @@ -0,0 +1,107 @@
> +// 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_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 irqs;
> +
> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
> + return irqs;
> +}
> +
> +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_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
* [PATCH v4 6/6] arm64: dts: qcom: shikra-iqs-evk-imx577-camera: Add DT overlay
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Shikra IQS is an industrial-grade variant using PM8150 PMIC, requiring
different CSIPHY and sensor supply rails compared to the retail boards
(CQM and CQS) which use PM4125.
Add a dedicated overlay for optional IMX577 integration via CSIPHY1.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 2 +
.../dts/qcom/shikra-iqs-evk-imx577-camera.dtso | 79 ++++++++++++++++++++++
2 files changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 76b8f144983827f4905a72935e8d5291a227dc97..09f2318d1c12c4239a6a7bac4ecbca38eb65ffa2 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -340,9 +340,11 @@ dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
+shikra-iqs-evk-imx577-camera-dtbs := shikra-iqs-evk.dtb shikra-iqs-evk-imx577-camera.dtbo
dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
+dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk-imx577-camera.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..d8c968a918c67cdebc0e7c6fc14ef820c97ecb75
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/qcom,shikra-gcc.h>
+#include <dt-bindings/gpio/gpio.h>
+
+&camss {
+ vdd-csiphy-1p2-supply = <&pm8150_l11>;
+ vdd-csiphy-1p8-supply = <&pm8150_l12>;
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&imx577_ep1>;
+ };
+ };
+ };
+};
+
+&cci {
+ status = "okay";
+};
+
+&cci_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@1a {
+ compatible = "sony,imx577";
+ reg = <0x1a>;
+
+ reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
+ pinctrl-names = "default";
+
+ clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
+ assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ /*
+ * avdd and dvdd are supplied by on-board regulators on the
+ * IMX577 module from the connector's 3.3 V rail; they are
+ * not SoC-controlled. dovdd (1.8 V) powers the carrier board
+ * level-shifter that translates CCI I2C and reset lines
+ * between the SoC and the connector.
+ */
+ dovdd-supply = <&pm8150_l15>;
+
+ port {
+ imx577_ep1: endpoint {
+ link-frequencies = /bits/ 64 <600000000>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy1_ep>;
+ };
+ };
+ };
+};
+
+&tlmm {
+ cam1_reset_default: cam1-reset-default-state {
+ pins = "gpio33";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/6] arm64: dts: qcom: shikra-cqm-cqs-evk-imx577-camera: Add DT overlay
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Shikra CQM and CQS are retail variants sharing the same PM4125 PMIC
and identical camera supply rails. The only difference between them
is the integrated modem on CQM, which does not affect camera hardware.
Add a shared overlay for optional IMX577 integration via CSIPHY1,
used by both CQM and CQS EVK boards.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 6 ++
.../dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso | 79 ++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index a9e9d829fb962386b3975f345ec006504607130a..76b8f144983827f4905a72935e8d5291a227dc97 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -337,6 +337,12 @@ dtb-$(CONFIG_ARCH_QCOM) += sdx75-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
+
+shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
+shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
+
+dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
+dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
new file mode 100644
index 0000000000000000000000000000000000000000..3a481d972cd27a2a324d96d8f47c161e11ea54f3
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/qcom,shikra-gcc.h>
+#include <dt-bindings/gpio/gpio.h>
+
+&camss {
+ vdd-csiphy-1p2-supply = <&pm4125_l5>;
+ vdd-csiphy-1p8-supply = <&pm4125_l13>;
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csiphy1_ep: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&imx577_ep1>;
+ };
+ };
+ };
+};
+
+&cci {
+ status = "okay";
+};
+
+&cci_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@1a {
+ compatible = "sony,imx577";
+ reg = <0x1a>;
+
+ reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
+ pinctrl-names = "default";
+
+ clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
+ assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ /*
+ * avdd and dvdd are supplied by on-board regulators on the
+ * IMX577 module from the connector's 3.3 V rail; they are
+ * not SoC-controlled. dovdd (1.8 V) powers the carrier board
+ * level-shifter that translates CCI I2C and reset lines
+ * between the SoC and the connector.
+ */
+ dovdd-supply = <&pm4125_l15>;
+
+ port {
+ imx577_ep1: endpoint {
+ link-frequencies = /bits/ 64 <600000000>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csiphy1_ep>;
+ };
+ };
+ };
+};
+
+&tlmm {
+ cam1_reset_default: cam1-reset-default-state {
+ pins = "gpio33";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 4/6] arm64: dts: qcom: shikra: Add pin configuration for mclks
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Add pinctrl configuration for the four available camera master clocks.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 57732804a6c6a114a407a4a541a1cc7af7635ea2..16b547131e8b14541abc68ff7cda126ba777ad80 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -380,6 +380,34 @@ cci_i2c1_sleep: cci-i2c1-sleep-state {
bias-pull-down;
};
+ cam_mclk0_default: cam-mclk0-default-state {
+ pins = "gpio34";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk1_default: cam-mclk1-default-state {
+ pins = "gpio35";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk2_default: cam-mclk2-default-state {
+ pins = "gpio96";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk3_default: cam-mclk3-default-state {
+ pins = "gpio98";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
qup_uart0_default: qup-uart0-default-state {
pins = "gpio0", "gpio1";
function = "qup0_se0";
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/6] arm64: dts: qcom: shikra: Add CCI definitions
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Qualcomm Shikra SoC has one Camera Control Interface (CCI)
containing two I2C hosts.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 70 ++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index f0e827996609dab2c09834857a1bffd9560155a6..57732804a6c6a114a407a4a541a1cc7af7635ea2 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -348,6 +348,38 @@ tlmm: pinctrl@500000 {
gpio-ranges = <&tlmm 0 0 165>;
wakeup-parent = <&mpm>;
+ cci_i2c0_default: cci-i2c0-default-state {
+ /* SDA, SCL */
+ pins = "gpio36", "gpio37";
+ function = "cci_i2c0";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ cci_i2c0_sleep: cci-i2c0-sleep-state {
+ /* SDA, SCL */
+ pins = "gpio36", "gpio37";
+ function = "cci_i2c0";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ cci_i2c1_default: cci-i2c1-default-state {
+ /* SDA, SCL */
+ pins = "gpio41", "gpio42";
+ function = "cci_i2c1";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ cci_i2c1_sleep: cci-i2c1-sleep-state {
+ /* SDA, SCL */
+ pins = "gpio41", "gpio42";
+ function = "cci_i2c1";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
qup_uart0_default: qup-uart0-default-state {
pins = "gpio0", "gpio1";
function = "qup0_se0";
@@ -702,6 +734,44 @@ port@1 {
reg = <1>;
};
};
+
+ };
+
+ cci: cci@5c1b000 {
+ compatible = "qcom,shikra-cci", "qcom,msm8996-cci";
+ reg = <0x0 0x05c1b000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 206 IRQ_TYPE_EDGE_RISING 0>;
+
+ clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_CCI_0_CLK>;
+ clock-names = "ahb",
+ "cci";
+
+ power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
+
+ pinctrl-0 = <&cci_i2c0_default &cci_i2c1_default>;
+ pinctrl-1 = <&cci_i2c0_sleep &cci_i2c1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
qupv3_0: geniqup@4ac0000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/6] arm64: dts: qcom: shikra: Add CAMSS node
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Add the Camera Subsystem node. Shikra shares the same IP as QCM2290
with two CSIPHYs, two CSIDs and two VFEs, but does not include CDM
and OPE blocks, so only a single IOMMU context bank is needed.
Co-developed-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
Signed-off-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 100 +++++++++++++++++++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..f0e827996609dab2c09834857a1bffd9560155a6 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -604,6 +604,106 @@ opp-384000000 {
};
};
+ camss: camss@5c11000 {
+ compatible = "qcom,shikra-camss", "qcom,qcm2290-camss";
+
+ reg = <0x0 0x05c11000 0x0 0x1000>,
+ <0x0 0x05c6e000 0x0 0x1000>,
+ <0x0 0x05c75000 0x0 0x1000>,
+ <0x0 0x05c52000 0x0 0x1000>,
+ <0x0 0x05c53000 0x0 0x1000>,
+ <0x0 0x05c66000 0x0 0x400>,
+ <0x0 0x05c68000 0x0 0x400>,
+ <0x0 0x05c6f000 0x0 0x4000>,
+ <0x0 0x05c76000 0x0 0x4000>;
+ reg-names = "top",
+ "csid0",
+ "csid1",
+ "csiphy0",
+ "csiphy1",
+ "csitpg0",
+ "csitpg1",
+ "vfe0",
+ "vfe1";
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMSS_AXI_CLK>,
+ <&gcc GCC_CAMSS_NRT_AXI_CLK>,
+ <&gcc GCC_CAMSS_RT_AXI_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CSID_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CSID_CLK>,
+ <&gcc GCC_CAMSS_CPHY_0_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CPHY_1_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CLK>,
+ <&gcc GCC_CAMSS_TFE_0_CPHY_RX_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CLK>,
+ <&gcc GCC_CAMSS_TFE_1_CPHY_RX_CLK>;
+ clock-names = "ahb",
+ "axi",
+ "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "csi0",
+ "csi1",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "top_ahb",
+ "vfe0",
+ "vfe0_cphy_rx",
+ "vfe1",
+ "vfe1_cphy_rx";
+
+ interrupts = <GIC_SPI 210 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 72 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 73 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 309 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 310 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 211 IRQ_TYPE_EDGE_RISING 0>,
+ <GIC_SPI 213 IRQ_TYPE_EDGE_RISING 0>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csiphy0",
+ "csiphy1",
+ "csitpg0",
+ "csitpg1",
+ "vfe0",
+ "vfe1";
+
+ interconnects = <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
+ &config_noc SLAVE_CAMERA_CFG RPM_ACTIVE_TAG>,
+ <&mmrt_virt MASTER_CAMNOC_HF RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
+ <&mmnrt_virt MASTER_CAMNOC_SF RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc";
+
+ iommus = <&apps_smmu 0x400 0x0>;
+
+ power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
qupv3_0: geniqup@4ac0000 {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x04ac0000 0x0 0x2000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/6] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta, Krzysztof Kozlowski
In-Reply-To: <20260615-shikra-camss-review-v4-0-bcb51081735b@oss.qualcomm.com>
Shikra contains the same Camera Subsystem IP as QCM2290. Document the
platform-specific compatible string, using qcom,qcm2290-camss as
fallback.
Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
single IOMMU context bank instead of four.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
.../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
index 391d0f6f67ef5fdfea31dd3683477561516b1556..490a7f3a8c5ff9c624f46150ee651793811823de 100644
--- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
@@ -14,7 +14,11 @@ description:
properties:
compatible:
- const: qcom,qcm2290-camss
+ oneOf:
+ - items:
+ - const: qcom,shikra-camss
+ - const: qcom,qcm2290-camss
+ - const: qcom,qcm2290-camss
reg:
maxItems: 9
@@ -76,7 +80,14 @@ properties:
- const: sf_mnoc
iommus:
- maxItems: 4
+ oneOf:
+ - items:
+ - description: S1 HLOS VFE non-protected (VFE only)
+ - items:
+ - description: S1 HLOS VFE non-protected
+ - description: S1 HLOS CDM non-protected
+ - description: S1 HLOS OPE read non-protected
+ - description: S1 HLOS OPE write non-protected
power-domains:
items:
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/6] Add CAMSS and IMX577 sensor support for Shikra EVK
From: Nihal Kumar Gupta @ 2026-06-15 8:33 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Nihal Kumar Gupta, Krzysztof Kozlowski
Shikra EVK is based on the Qualcomm Shikra SoC.
It lacks a camera sensor in its default configuration.
This series adds CAMSS driver support, CCI definitions and enables
the 22-pin IMX577 sensor via CSIPHY1 through device tree overlays.
We have tested IMX577 Sensor on CCI1 with following commands:
- media-ctl --reset
- media-ctl -d /dev/media0 -V '"imx577 1-001a":0[fmt:SRGGB10/4056x3040 field:none]'
- media-ctl -d /dev/media0 -V '"msm_csiphy1":0[fmt:SRGGB10/4056x3040]'
- media-ctl -d /dev/media0 -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]'
- media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]'
- media-ctl -d /dev/media0 -l '"msm_csiphy1":1->"msm_csid0":0[1]'
- media-ctl -d /dev/media0 -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
- yavta -B capture-mplane -c -I -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video0
Used following tools for the sanity check of these changes.
- make -j32 W=1
- checkpatch.pl
- make DT_CHECKER_FLAGS=-m W=1 DT_SCHEMA_FILES=i2c/qcom,i2c-cci.yaml dt_binding_check
- make DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=media/qcom,qcm2290-camss.yaml dt_binding_check W=1
- make CHECK_DTBS=y W=1 qcom/qrb2210-rb1-vision-mezzanine.dtb
- make CHECK_DTBS=1 W=1 qcom/shikra-cqm-cqs-evk-imx577-camera.dtb
- make CHECK_DTBS=1 W=1 qcom/shikra-iqs-evk-imx577-camera.dtb
- make CHECK_DTBS=y W=1 dtbs
The Shikra CAMSS binding patch does not depend on the rest of the series
and can go through the media tree on its own.
This patch series depends on patch series:
https://lore.kernel.org/all/20260527-shikra-dt-v4-0-b5ca1fa0b392@oss.qualcomm.com/
https://lore.kernel.org/all/20260608-shikra-gcc-rpmcc-clks-v5-0-94cefe092ee3@oss.qualcomm.com/
Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
---
Changes in v4:
- Fix data-lanes numbering to start from 1 in all endpoints (Vladimir)
Missed in last rev.
- Link to v3: https://lore.kernel.org/r/20260615-shikra-camss-review-v3-0-8183481f48d0@oss.qualcomm.com
Changes in v3:
- Drop dt-bindings: i2c: qcom-cci: Document Shikra compatible; already
picked by Andi Shyti into her i2c tree (now in linux-next as e3a8f8329397)
- Preserve blank line after compatible const in qcom,qcm2290-camss.yaml (Krzysztof)
- Add blank line between iommus and power-domains in CAMSS node (Vladimir)
- Move cam1_reset_default pinctrl state from board .dts files into the
mezzanine .dtso overlay files (Vladimir)
- Collect Reviewed-by tags
- Link to v2: https://lore.kernel.org/r/20260608-shikra-camss-review-v2-0-ca1936bf1219@oss.qualcomm.com
Changes in v2:
- Drop qcm2390_resources struct and CAMSS_2390 enum; use qcom,qcm2290-camss
as fallback compatible string since Shikra CAMSS is register-compatible
with QCM2290 (Loic, Bryan)
- Use oneOf in iommus to describe all valid SID combinations: VFE-only
(Shikra) and VFE+CDM+OPE read+OPE write (QCM2290/Agatti); add
per-entry descriptions naming each SID (Krzysztof, Bryan)
- Rename shikra-cqm-evk-imx577-camera overlay to
shikra-cqm-cqs-evk-imx577-camera, shared by both CQM and CQS EVK
boards which use the same PM4125 PMIC and camera supply rails (Bryan)
- Add reset-gpios pinctrl state for IMX577 sensor (gpio33, cam1-reset-default-state)
- Add comment in overlay DTS explaining absent regulators are powered
by the daughter board (Bryan)
- Collect Reviewed-by tags
- Add reset-gpios pinctrl state for IMX577 sensor.
- Link to v1: https://lore.kernel.org/r/20260526-shikra-camss-review-v1-0-645d2c8c75a7@qti.qualcomm.com
---
Nihal Kumar Gupta (6):
dt-bindings: media: qcom: Add Shikra CAMSS compatible
arm64: dts: qcom: shikra: Add CAMSS node
arm64: dts: qcom: shikra: Add CCI definitions
arm64: dts: qcom: shikra: Add pin configuration for mclks
arm64: dts: qcom: shikra-cqm-cqs-evk-imx577-camera: Add DT overlay
arm64: dts: qcom: shikra-iqs-evk-imx577-camera: Add DT overlay
.../bindings/media/qcom,qcm2290-camss.yaml | 15 +-
arch/arm64/boot/dts/qcom/Makefile | 8 +
.../dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso | 79 ++++++++
.../dts/qcom/shikra-iqs-evk-imx577-camera.dtso | 79 ++++++++
arch/arm64/boot/dts/qcom/shikra.dtsi | 198 +++++++++++++++++++++
5 files changed, 377 insertions(+), 2 deletions(-)
---
base-commit: abe651837cb394f76d738a7a747322fca3bf17ba
change-id: 20260526-shikra-camss-review-cf6f66ac566b
prerequisite-change-id: 20260511-shikra-dt-d75d97454646:v4
prerequisite-patch-id: 3a689e8dda5fd2755b689d94d095806b3f2e6eed
prerequisite-patch-id: 2acc300a68ed8c5364fb5f2f7d28fc0d56ab07bf
prerequisite-patch-id: 2357cac636e019eaf14d6a493a1c72bca56fe405
prerequisite-patch-id: 2885f299e711582da312ca9d13983d296a3dd5dc
prerequisite-patch-id: 91af5f3c01e766a53ce8de69aa21847a2d6bbbf8
prerequisite-change-id: 20260429-shikra-gcc-rpmcc-clks-2094edfff3b0:v5
prerequisite-patch-id: 59bb0a7828e41f546f734f127d81da83c0adcda9
prerequisite-patch-id: 197da6bcb15cadc47869dba88c8020987b25c335
prerequisite-patch-id: 8ec9c1eb03f052ae232ed54117abed38672c23f6
prerequisite-patch-id: 350db4f4bcdfc0fad9ed57cd5b1723f85ad44f5d
Best regards,
--
Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand
From: Simon Horman @ 2026-06-15 8:32 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal, Alexander Lobakin
In-Reply-To: <20260611-airoha-ethtool-priv_flags-v5-0-c11de08486d1@kernel.org>
On Thu, Jun 11, 2026 at 11:55:50PM +0200, Lorenzo Bianconi wrote:
> Add the capability to configure GDM3/GDM4 as WAN/LAN on demand when QoS
> offload is created or destroyed.
> Make dev->qdma an RCU pointer so the TX path can safely dereference it
> without holding RTNL.
> Introduce airoha_qdma_start() and airoha_qdma_stop() helpers.
For the series:
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v2 3/7] net: wwan: t9xx: Add control DMA interface
From: Wu. JackBB (GSM) @ 2026-06-15 8:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org,
wojackbb@gmail.com
In-Reply-To: <20260613173018.7a0581f1@kernel.org>
Hi Jakub,
Thank you for your comment.
On Wed, 10 Jun 2026 18:41:06 +0800 Jack Wu via B4 Relay wrote:
> Transient build warnings:
>
> +../drivers/net/wwan/t9xx/pcie/mtk_pci_drv_m9xx.c:52:30: warning: symbol 'mtk_dev_cfg_0900' was not declared. Should it be static?
> +../drivers/net/wwan/t9xx/pcie/mtk_ctrl_cfg_m9xx.c:19:22: warning: symbol 'mtk_ctrl_info_m9xx' was not declared. Should it be static?
> +../drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c:33:22: warning: symbol 'mtk_cldma_regs_m9xx' was not declared. Should it be static?
> +../drivers/net/wwan/t9xx/pcie/mtk_cldma_drv_m9xx.c:166:22: warning: symbol 'cldma_drv_ops_m9xx' was not declared. Should it be static?
Will fix in v3. Moved extern declarations into shared headers so each
defining .c file includes its own declaration.
> please also see all the AI code comments at:
> https://sashiko.dev/#/patchset/20260610-t9xx_driver_v1-v2-3-c65addf23b3f@compal.com
Thank you. We have reviewed the AI comments. Below are our
responses for the items under this patch (patch 3):
Q1: Is the reference count for the skb incremented correctly here? If the port
is non-blocking, the caller might immediately drop the reference. Without an
extra reference taken before queueing, the skb could be freed while it still
resides in the queue, resulting in a use-after-free when the worker thread
later accesses the list.
No use-after-free here. The skb is allocated by the port layer
(mtk_port_send_data / mtk_port_common_write) and ownership is
transferred to submit_skb — the caller does not free the skb after
a successful submission. On error returns (-EINVAL, -EIO, -EAGAIN),
the skb is NOT queued and the caller handles cleanup. The skb_queue
operations (skb_queue_head/skb_queue_tail) do not require an extra
reference because the queue becomes the sole owner. This is the
standard kernel pattern — skb ownership transfers to the queue, not
shared between caller and queue.
Q2: Could there be a race condition between setting the virtual address and the
hardware ownership flag? If the worker checks the condition between these two
writes, it might erroneously detect completion and free the buffer before the
transfer even starts.
No race. The tx_done_work checks:
if (!req->data_vm_addr || (gpd_flags & CLDMA_GPD_FLAG_HWO))
break;
It only proceeds when data_vm_addr is set AND HWO is cleared.
In submit_tx, the write order is:
1. req->data_vm_addr = skb->data; (set non-NULL)
2. wmb();
3. gpd_flags |= CLDMA_GPD_FLAG_HWO; (set HWO)
After step 1, data_vm_addr is non-NULL but HWO is set (step 3), so
tx_done_work sees HWO=1 and breaks. It will only process this req
after the hardware clears HWO upon DMA completion. The wmb() ensures
the metadata writes are visible before HWO is set, and the rmb() in
tx_done_work ensures HWO is read before the metadata.
Q3: Does this permanently halt the receive queue if a memory allocation fails
during refill? If the skb allocation fails earlier, the worker exits here
without advancing the free index, which seems to leave the queue stuck
indefinitely on all subsequent executions.
The concern is partially valid. If mtk_cldma_reload_rx_skb() fails
(skb alloc failure), the code jumps to "out" which unmasks the
interrupt. On the next hardware interrupt, rx_done_work runs again
and retries from the same free_idx. If req->skb is NULL (because
reload failed and rx_done set req->skb = NULL after dispatch), the
code hits the "!req->skb" error check and goes to "out" — but "out"
now correctly unmasks the interrupt (fixed in v2), so the next
interrupt will retry. This creates a retry loop that depends on
memory becoming available. Under sustained memory pressure, the RX
queue stalls but recovers once memory is freed. This is acceptable
behavior for a control plane interface with small, infrequent
messages.
Q4: Does this loop safely handle fatal errors from the submission function? It
appears that on errors other than EAGAIN, the loop breaks without unlinking
the skb. The worker loop would then peek the exact same skb on the next
iteration, causing an infinite busy loop that locks up the processor.
The code shown (with kref_put) is from patch 4, not patch 3.
We will fix the issue in patch 4 v3.
Q5: Is a read memory barrier needed after checking the hardware ownership flag?
Without a barrier, the processor might speculatively read the payload length
and data in mtk_cldma_rx_skb_adjust before confirming ownership, leading to
potential data corruption.
The GPD descriptors are allocated from a coherent DMA pool
(dma_pool_zalloc), so CPU cache coherency is guaranteed by the DMA
mapping. A dma_rmb() is not needed here as coherent memory ensures
the CPU always observes the latest values written by the device
without reordering.
Q6: Should the return value of the queue stop function be checked before tearing
down DMA memory? If the hardware fails to stop within the timeout, proceeding
to unmap the memory might result in the active hardware writing to freed
kernel memory.
The concern is valid in theory but not actionable in practice.
cldma_stop_queue() polls the hardware for up to 10 iterations with
usleep. If it times out, the hardware is in a broken state (link
error or device hang). At this point the teardown is part of
device removal or error recovery — there is no safe alternative to
proceeding with cleanup. Skipping the teardown would leak DMA
memory permanently. The synchronize_irq() + flush_work() after
stop_queue ensures no software handlers are in-flight. If the
hardware is truly stuck, the PCIe link is likely already down
(LINK_ERROR_VAL check), making further MMIO access no-ops.
Q7: Does this leak the radix tree nodes and their contents if the array
allocation fails? Performing memory allocations in a teardown path might
permanently leak memory during system memory pressure.
We will fix in v3 by replacing kcalloc +
radix_tree_gang_lookup with radix_tree_for_each_slot() iteration,
eliminating the allocation in the teardown path.
Regarding AI comments for other patches in the series — should we
respond to those under each respective patch thread?
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH v1 0/4] trace_hyp_printk() for pKVM/nVHE hypervisor
From: Fuad Tabba @ 2026-06-15 8:30 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <ai-3ii1BtOPP25zZ@google.com>
On Mon, 15 Jun 2026 at 09:28, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> On Sun, Jun 14, 2026 at 01:57:56PM +0100, Fuad Tabba wrote:
> > Hi Vincent,
> >
> > On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> > >
> > > Hi all,
> > >
> > > This series adds a hypervisor event "hyp_printk" which enables
> > > developers to log pretty much anything into the hypervisor tracing
> > > buffer, just like the kernel function trace_printk().
> > >
> > > This enables rich logging from the hypervisor, while leaving all the
> > > string parsing burden to the kernel. This has been the main way of
> > > debugging pKVM in Android.
> >
> > I tested the series on v7.1-rc7 under QEMU (cortex-a53 CPU, pKVM nVHE):
> > - Booted a host under pKVM with a non-protected kvmtool guest (npVM)
> > and a protected kvmtool guest (pVM).
> > - Functional test: added a temporary trace_hyp_printk() call site in
> > handle___kvm_vcpu_run() with 0-arg, 1-arg, and 2-arg calls. Mounted
> > tracefs, enabled the hyp_printk event, ran a kvmtool guest to trigger
> > vcpu_run, read the trace buffer. All expected entries appeared with
> > correctly formatted output.
>
> Thanks for the testing!
>
> >
> > One question: kvm_hyp_trace_init() returns early when
> > is_kernel_in_hyp_mode() is true. On VHE-capable hardware, pKVM uses
> > hVHE. So it seams that the entire hyp tracing subsystem (not just
> > hyp_printk) is non-functional in hVHE mode. Is hVHE support
> > intentionally deferred?
>
> You got me scared for a moment but I did try hVHE and it seems alright:
>
> [ 5.369985] kvm [1]: Protected hVHE mode initialized successfully
>
> $ ls /sys/kernel/tracing/remotes/hypervisor/
>
> is_kernel_in_hyp_mode() just checks if the kernel is running at EL2 which it
> shouldn't in the hVHE case?
I'll try again and report back, must be user error.
/fuad
>
> >
> > Cheers,
> > /fuad
> >
> > >
> > > Even though not strictly related to trace_hyp_printk, I have added the
> > > following two patches:
> > >
> > > * KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > >
> > > This one mainly intends to support one of the new features I have
> > > posted here [1], which allows to enable tracing as early as
> > > possible. I have added it here to limit cross-posting.
> > >
> > > * KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > >
> > > This one is just a cleanup.
> > >
> > > [1] https://lore.kernel.org/all/20260605163825.1762953-1-vdonnefort@google.com/
> > >
> > > Vincent Donnefort (4):
> > > KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > > KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > > tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
> > > KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
> > >
> > > arch/arm64/include/asm/kvm_asm.h | 4 +-
> > > arch/arm64/include/asm/kvm_hypevents.h | 14 ++++
> > > arch/arm64/include/asm/kvm_hyptrace.h | 8 +++
> > > arch/arm64/kernel/image-vars.h | 1 +
> > > arch/arm64/kernel/vmlinux.lds.S | 4 ++
> > > .../define_hypevents.h} | 0
> > > .../kvm/hyp/include/nvhe/define_events.h | 2 -
> > > arch/arm64/kvm/hyp/include/nvhe/trace.h | 65 +++++++++++++++++++
> > > arch/arm64/kvm/hyp/nvhe/events.c | 6 ++
> > > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> > > arch/arm64/kvm/hyp_trace.c | 60 ++++++++++++++++-
> > > include/trace/define_remote_events.h | 19 +++++-
> > > 12 files changed, 176 insertions(+), 9 deletions(-)
> > > rename arch/arm64/{include/asm/kvm_define_hypevents.h => kvm/define_hypevents.h} (100%)
> > >
> > >
> > > base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> > > --
> > > 2.54.0.1136.gdb2ca164c4-goog
> > >
^ permalink raw reply
* Re: [PATCH v1 4/4] KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
From: Vincent Donnefort @ 2026-06-15 8:29 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <CA+EHjTwqp=Hjzyn469Gvm-JRNovfnj=0eFB5+Kei_9pRQrnG0Q@mail.gmail.com>
On Sun, Jun 14, 2026 at 04:25:00PM +0100, Fuad Tabba wrote:
> Hi Vincent,
>
> On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > Create an event to allow developers to log pretty much anything into the
> > hypervisor tracing buffer with trace_hyp_printk(), just like the kernel
> > tracing has the function trace_printk().
> >
> > trace_hyp_printk("foobar");
> > trace_hyp_printk("foo=%d", foo);
> > trace_hyp_printk("foo=%d bar=0x%016llx", foo, bar);
> >
> > To ensure writing into the tracing buffer is fast, store the string
> > format into a kernel-accessible ELF section. The hypervisor only has to
> > write into the event the string ID, which is the delta between the
> > hyp_string_fmt and the start of the ELF section.
> >
> > To not waste tracing buffer data, use a dynamic size. Each
> > argument is 8 bytes and the in-kernel printing function can simply know
> > how many of them there are by looking at the event length.
> >
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/arch/arm64/include/asm/kvm_hypevents.h b/arch/arm64/include/asm/kvm_hypevents.h
> > index 743c49bd878f..8465b523cb1d 100644
> > --- a/arch/arm64/include/asm/kvm_hypevents.h
> > +++ b/arch/arm64/include/asm/kvm_hypevents.h
> > @@ -57,4 +57,18 @@ HYP_EVENT(selftest,
> > ),
> > RE_PRINTK("id=%llu", __entry->id)
> > );
> > +
> > +/*
> > + * trace_hyp_printk() has too many specificities to be declared with HYP_EVENT().
> > + * However, we can use a REMOTE_EVENT macro to automatically do the declaration
> > + * for the kernel side.
> > + */
> > +REMOTE_EVENT_CUSTOM_PRINTK(hyp_printk,
> > + 0, /* id will be overwritten during hyp event init */
> > + RE_STRUCT(
> > + re_field(u16, fmt_id)
> > + re_field(u64, args[])
> > + ),
> > + __hyp_trace_printk(evt, seq)
> > +);
> > #endif
> > diff --git a/arch/arm64/include/asm/kvm_hyptrace.h b/arch/arm64/include/asm/kvm_hyptrace.h
> > index de133b735f72..46097105fdd8 100644
> > --- a/arch/arm64/include/asm/kvm_hyptrace.h
> > +++ b/arch/arm64/include/asm/kvm_hyptrace.h
> > @@ -23,4 +23,12 @@ extern struct remote_event __hyp_events_end[];
> > extern struct hyp_event_id __hyp_event_ids_start[];
> > extern struct hyp_event_id __hyp_event_ids_end[];
> >
> > +#define HYP_STRING_FMT_MAX_SIZE 128
> > +
> > +struct hyp_string_fmt {
> > + const char fmt[HYP_STRING_FMT_MAX_SIZE];
> > +};
> > +
> > +extern struct hyp_string_fmt __hyp_string_fmts_start[];
> > +extern struct hyp_string_fmt __hyp_string_fmts_end[];
> > #endif
> > diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> > index d4c7d45ae6bc..ec03621d7a81 100644
> > --- a/arch/arm64/kernel/image-vars.h
> > +++ b/arch/arm64/kernel/image-vars.h
> > @@ -141,6 +141,7 @@ KVM_NVHE_ALIAS(__hyp_rodata_end);
> > #ifdef CONFIG_NVHE_EL2_TRACING
> > KVM_NVHE_ALIAS(__hyp_event_ids_start);
> > KVM_NVHE_ALIAS(__hyp_event_ids_end);
> > +KVM_NVHE_ALIAS(__hyp_string_fmts_start);
> > #endif
> >
> > /* pKVM static key */
> > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> > index e1ac876200a3..b6d62642b6bd 100644
> > --- a/arch/arm64/kernel/vmlinux.lds.S
> > +++ b/arch/arm64/kernel/vmlinux.lds.S
> > @@ -324,6 +324,10 @@ SECTIONS
> > __hyp_events_start = .;
> > *(SORT(_hyp_events.*))
> > __hyp_events_end = .;
> > +
> > + __hyp_string_fmts_start = .;
> > + *(_hyp_string_fmts)
> > + __hyp_string_fmts_end = .;
> > }
> > #endif
> > /*
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/define_events.h b/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> > index 776d4c6cb702..370e8c2d39fe 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> > @@ -10,5 +10,3 @@
> > #define HYP_EVENT_MULTI_READ
> > #include <asm/kvm_hypevents.h>
> > #undef HYP_EVENT_MULTI_READ
> > -
> > -#undef HYP_EVENT
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/trace.h b/arch/arm64/kvm/hyp/include/nvhe/trace.h
> > index 8813ff250f8e..3d0b5c634bb3 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/trace.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/trace.h
> > @@ -46,6 +46,69 @@ static inline pid_t __tracing_get_vcpu_pid(struct kvm_cpu_context *host_ctxt)
> > void *tracing_reserve_entry(unsigned long length);
> > void tracing_commit_entry(void);
> >
> > +/*
> > + * The trace_hyp_printk boilerplate is too fiddly to be declared with
> > + * HYP_EVENT():
> > + *
> > + * The string format is stored into a kernel-accessible ELF section. The
> > + * hypervisor only writes the format ID.
> > + *
> > + * The function has a variadic prototype. We have no easy way to know each
> > + * argument width so they must all cast to u64.
> > + */
> > +#define REMOTE_EVENT_CUSTOM_PRINTK(...)
> > +
> > +#define __TO_U64_0()
> > +#define __TO_U64_1(x) , (u64)(x)
> > +#define __TO_U64_2(x, ...) , (u64)(x) __TO_U64_1(__VA_ARGS__)
> > +#define __TO_U64_3(x, ...) , (u64)(x) __TO_U64_2(__VA_ARGS__)
> > +#define __TO_U64_4(x, ...) , (u64)(x) __TO_U64_3(__VA_ARGS__)
> > +#define __TO_U64_5(x, ...) , (u64)(x) __TO_U64_4(__VA_ARGS__)
> > +#define __TO_U64_6(x, ...) , (u64)(x) __TO_U64_5(__VA_ARGS__)
> > +#define __TO_U64_7(x, ...) , (u64)(x) __TO_U64_6(__VA_ARGS__)
> > +#define __TO_U64_8(x, ...) , (u64)(x) __TO_U64_7(__VA_ARGS__)
> > +
> > +#define __TO_U64_X(N, ...) CONCATENATE(__TO_U64_, N)(__VA_ARGS__)
> > +#define __TO_U64(...) __TO_U64_X(COUNT_ARGS(__VA_ARGS__), ##__VA_ARGS__)
> > +
> > +REMOTE_EVENT_FORMAT(hyp_printk, HE_STRUCT(he_field(u16, fmt_id) he_field(u64, args[])));
> > +extern struct hyp_event_id hyp_event_id_hyp_printk;
> > +
> > +static __always_inline void __trace_hyp_printk(struct hyp_string_fmt *fmt, int nr_args, ...)
> > +{
> > + struct remote_event_format_hyp_printk *entry;
> > + va_list va;
> > + int i;
> > +
> > + if (!atomic_read(&hyp_event_id_hyp_printk.enabled))
> > + return;
> > +
> > + entry = tracing_reserve_entry(struct_size(entry, args, nr_args));
> > + if (!entry)
> > + return;
> > +
> > + entry->hdr.id = hyp_event_id_hyp_printk.id;
> > + entry->fmt_id = fmt - __hyp_string_fmts_start;
>
> nit: fmt_id is u16, the subtraction is ptrdiff_t. Silent truncation if
> the section ever has more than 65536 entries. Not realistic today, but
> a WARN_ON on the section size in hyp_trace_init_events() would catch
> it at boot for free.
Ack. That wouldn't cost anything. I'll add that in a v2
>
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Tested-by: Fuad Tabba <tabba@google.com>
>
> Cheers,
> /fuad
>
>
> > +
> > + va_start(va, nr_args);
> > + for (i = 0; i < nr_args; i++)
> > + entry->args[i] = va_arg(va, u64);
> > + va_end(va);
> > +
> > + tracing_commit_entry();
> > +}
> > +
> > +
> > +#define trace_hyp_printk(__fmt, __args...) \
> > +do { \
> > + static struct hyp_string_fmt __used __section("_hyp_string_fmts") fmt = { \
> > + .fmt = __fmt \
> > + }; \
> > + BUILD_BUG_ON(sizeof(__fmt) > HYP_STRING_FMT_MAX_SIZE); \
> > + /* __TO_U64 prepends a comma if there are arguments */ \
> > + __trace_hyp_printk(&fmt, COUNT_ARGS(__args) __TO_U64(__args)); \
> > +} while (0)
> > +
> > int __tracing_load(unsigned long desc_va, size_t desc_size);
> > void __tracing_unload(void);
> > int __tracing_enable(bool enable);
> > @@ -58,6 +121,8 @@ static inline void *tracing_reserve_entry(unsigned long length) { return NULL; }
> > static inline void tracing_commit_entry(void) { }
> > #define HYP_EVENT(__name, __proto, __struct, __assign, __printk) \
> > static inline void trace_##__name(__proto) {}
> > +#define REMOTE_EVENT_CUSTOM_PRINTK(...)
> > +#define trace_hyp_printk(fmt, args...) do { } while (0)
> >
> > static inline int __tracing_load(unsigned long desc_va, size_t desc_size) { return -ENODEV; }
> > static inline void __tracing_unload(void) { }
> > diff --git a/arch/arm64/kvm/hyp/nvhe/events.c b/arch/arm64/kvm/hyp/nvhe/events.c
> > index add9383aadb5..12223d2e3618 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/events.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/events.c
> > @@ -9,6 +9,12 @@
> >
> > #include <nvhe/define_events.h>
> >
> > +/*
> > + * The hyp_printk event is not declared with HYP_EVENT in kvm_hypevents.h,
> > + * so we manually add the boilerplate here.
> > + */
> > +HYP_EVENT(hyp_printk, 0, 0, 0, 0);
> > +
> > int __tracing_enable_event(unsigned short id, bool enable)
> > {
> > struct hyp_event_id *event_id = &__hyp_event_ids_start[id];
> > diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> > index 821bc93ecdd1..187a8a295d6f 100644
> > --- a/arch/arm64/kvm/hyp_trace.c
> > +++ b/arch/arm64/kvm/hyp_trace.c
> > @@ -391,6 +391,9 @@ static struct trace_remote_callbacks trace_remote_callbacks = {
> >
> > static const char *__hyp_enter_exit_reason_str(u8 reason);
> >
> > +struct remote_event_format_hyp_printk;
> > +static void __hyp_trace_printk(struct remote_event_format_hyp_printk *entry, struct trace_seq *seq);
> > +
> > #include "define_hypevents.h"
> >
> > static const char *__hyp_enter_exit_reason_str(u8 reason)
> > @@ -409,6 +412,61 @@ static const char *__hyp_enter_exit_reason_str(u8 reason)
> > return strs[min(reason, HYP_REASON_UNKNOWN)];
> > }
> >
> > +static void __hyp_trace_printk(struct remote_event_format_hyp_printk *entry, struct trace_seq *seq)
> > +{
> > + const char *fmt = (const char *)(&__hyp_string_fmts_start[entry->fmt_id]);
> > + struct ring_buffer_event *evt = (void *)entry - RB_EVNT_HDR_SIZE;
> > + int nr_args;
> > +
> > + trace_seq_putc(seq, ' ');
> > +
> > + if ((void *)fmt >= (void *)__hyp_string_fmts_end) {
> > + trace_seq_printf(seq, "Unknown hyp_string_fmt ID %d\n", entry->fmt_id);
> > + return;
> > + }
> > +
> > + nr_args = (ring_buffer_event_length(evt) -
> > + offsetof(struct remote_event_format_hyp_printk, args)) / sizeof(entry->args[0]);
> > + switch (nr_args) {
> > + case 0:
> > + trace_seq_printf(seq, fmt);
> > + break;
> > + case 1:
> > + trace_seq_printf(seq, fmt, entry->args[0]);
> > + break;
> > + case 2:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1]);
> > + break;
> > + case 3:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2]);
> > + break;
> > + case 4:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> > + entry->args[3]);
> > + break;
> > + case 5:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> > + entry->args[3], entry->args[4]);
> > + break;
> > + case 6:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> > + entry->args[3], entry->args[4], entry->args[5]);
> > + break;
> > + case 7:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> > + entry->args[3], entry->args[4], entry->args[5], entry->args[6]);
> > + break;
> > + default:
> > + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1],
> > + entry->args[2], entry->args[3], entry->args[4], entry->args[5],
> > + entry->args[6], entry->args[7]);
> > + break;
> > + }
> > +
> > + if (seq->buffer[trace_seq_used(seq) - 1] != '\n')
> > + trace_seq_putc(seq, '\n');
> > +}
> > +
> > static void __init hyp_trace_init_events(void)
> > {
> > struct hyp_event_id *hyp_event_id = __hyp_event_ids_start;
> > --
> > 2.54.0.1136.gdb2ca164c4-goog
> >
^ permalink raw reply
* Re: [PATCH v1 0/4] trace_hyp_printk() for pKVM/nVHE hypervisor
From: Vincent Donnefort @ 2026-06-15 8:27 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <CA+EHjTxditViT-yd+y-DZ8zM7dATVEpe8qWNGbugq6sL7KN+uw@mail.gmail.com>
On Sun, Jun 14, 2026 at 01:57:56PM +0100, Fuad Tabba wrote:
> Hi Vincent,
>
> On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > Hi all,
> >
> > This series adds a hypervisor event "hyp_printk" which enables
> > developers to log pretty much anything into the hypervisor tracing
> > buffer, just like the kernel function trace_printk().
> >
> > This enables rich logging from the hypervisor, while leaving all the
> > string parsing burden to the kernel. This has been the main way of
> > debugging pKVM in Android.
>
> I tested the series on v7.1-rc7 under QEMU (cortex-a53 CPU, pKVM nVHE):
> - Booted a host under pKVM with a non-protected kvmtool guest (npVM)
> and a protected kvmtool guest (pVM).
> - Functional test: added a temporary trace_hyp_printk() call site in
> handle___kvm_vcpu_run() with 0-arg, 1-arg, and 2-arg calls. Mounted
> tracefs, enabled the hyp_printk event, ran a kvmtool guest to trigger
> vcpu_run, read the trace buffer. All expected entries appeared with
> correctly formatted output.
Thanks for the testing!
>
> One question: kvm_hyp_trace_init() returns early when
> is_kernel_in_hyp_mode() is true. On VHE-capable hardware, pKVM uses
> hVHE. So it seams that the entire hyp tracing subsystem (not just
> hyp_printk) is non-functional in hVHE mode. Is hVHE support
> intentionally deferred?
You got me scared for a moment but I did try hVHE and it seems alright:
[ 5.369985] kvm [1]: Protected hVHE mode initialized successfully
$ ls /sys/kernel/tracing/remotes/hypervisor/
is_kernel_in_hyp_mode() just checks if the kernel is running at EL2 which it
shouldn't in the hVHE case?
>
> Cheers,
> /fuad
>
> >
> > Even though not strictly related to trace_hyp_printk, I have added the
> > following two patches:
> >
> > * KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> >
> > This one mainly intends to support one of the new features I have
> > posted here [1], which allows to enable tracing as early as
> > possible. I have added it here to limit cross-posting.
> >
> > * KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> >
> > This one is just a cleanup.
> >
> > [1] https://lore.kernel.org/all/20260605163825.1762953-1-vdonnefort@google.com/
> >
> > Vincent Donnefort (4):
> > KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> > KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> > tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
> > KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
> >
> > arch/arm64/include/asm/kvm_asm.h | 4 +-
> > arch/arm64/include/asm/kvm_hypevents.h | 14 ++++
> > arch/arm64/include/asm/kvm_hyptrace.h | 8 +++
> > arch/arm64/kernel/image-vars.h | 1 +
> > arch/arm64/kernel/vmlinux.lds.S | 4 ++
> > .../define_hypevents.h} | 0
> > .../kvm/hyp/include/nvhe/define_events.h | 2 -
> > arch/arm64/kvm/hyp/include/nvhe/trace.h | 65 +++++++++++++++++++
> > arch/arm64/kvm/hyp/nvhe/events.c | 6 ++
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> > arch/arm64/kvm/hyp_trace.c | 60 ++++++++++++++++-
> > include/trace/define_remote_events.h | 19 +++++-
> > 12 files changed, 176 insertions(+), 9 deletions(-)
> > rename arch/arm64/{include/asm/kvm_define_hypevents.h => kvm/define_hypevents.h} (100%)
> >
> >
> > base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> > --
> > 2.54.0.1136.gdb2ca164c4-goog
> >
^ permalink raw reply
* Re: [PATCH v4 2/6] drm/verisilicon: add register-level macros for DC8000
From: Icenowy Zheng @ 2026-06-15 8:24 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: <20260615065003.76661-3-a0987203069@gmail.com>
在 2026-06-15一的 14:49 +0800，Joey Lu写道：
> Add register-level constants needed by the forthcoming DC8000
> (DCUltraLite)
> hardware ops:
>
> VSDC_DISP_IRQ_VSYNC(n) in vs_crtc_regs.h: bit mask for per-output
> VSYNC interrupt bits in DISP_IRQ_STA (0x147C) / DISP_IRQ_EN
> (0x1480),
> which are the IRQ registers used by DCUltraLite in place of the
> DC8200
> TOP_IRQ_ACK / TOP_IRQ_EN registers.
>
> VSDC_FB_CONFIG_ENABLE (bit 0), VSDC_FB_CONFIG_VALID (bit 3) and
> VSDC_FB_CONFIG_RESET (bit 4) in vs_primary_plane_regs.h: control
> bits
> in the FB_CONFIG register used by DCUltraLite for framebuffer
> enable
> and per-frame commit handshake.
Validated against DC8000 register list.
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
>
> No behaviour change for existing DC8200 platforms.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
> drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> index c7930e817635..d4da22b08cd5 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> @@ -54,6 +54,7 @@
> #define VSDC_DISP_GAMMA_DATA(n) (0x1460 +
> 0x4 * (n))
>
> #define VSDC_DISP_IRQ_STA 0x147C
> +#define VSDC_DISP_IRQ_VSYNC(n) BIT(n)
>
> #define VSDC_DISP_IRQ_EN 0x1480
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> index cbb125c46b39..67d4b00f294e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> @@ -16,6 +16,9 @@
> #define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
>
> #define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
> +#define VSDC_FB_CONFIG_ENABLE BIT(0)
> +#define VSDC_FB_CONFIG_VALID BIT(3)
> +#define VSDC_FB_CONFIG_RESET BIT(4)
> #define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
> #define VSDC_FB_CONFIG_ROT_MASK GENMASK(13,
> 11)
> #define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
^ permalink raw reply
* Re: [PATCH v4 1/6] dt-bindings: display: verisilicon, dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-06-15 8:19 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: <20260615065003.76661-2-a0987203069@gmail.com>
在 2026-06-15一的 14:49 +0800，Joey Lu写道：
> The existing schema hard-codes the five-clock/three-reset/dual-port
> topology of the DC8200 IP block, preventing reuse for single-output
> variants such as the Verisilicon DCUltraLite used in the Nuvoton
> MA35D1
> SoC.
>
> Rework the schema so that variant-specific constraints are expressed
> via
> allOf/if blocks:
>
> - Add nuvoton,ma35d1-dcu to the SoC-specific compatible enum. The
> generic verisilicon,dc fallback remains the driver-binding string.
> - Move clock and reset items descriptions into the per-variant
> allOf/if
> blocks; keep only minItems/maxItems at the top level so the base
> schema
> accepts all variants.
> - Restore full items lists for clock-names and reset-names at the top
> level with minItems so the names are validated against the
> descriptions.
> - Keep ports in the global required list and keep
> additionalProperties: false.
> - Add an allOf/if block for thead,th1520-dc8200: five-clock (core,
> axi,
> ahb, pix0, pix1), three-reset (core, axi, ahb), required resets.
> - Add an allOf/if block for nuvoton,ma35d1-dcu: two-clock (core,
> pix0),
> one-reset (core), required resets.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/display/verisilicon,dc.yaml | 80
> +++++++++++++++++--
> 1 file changed, 73 insertions(+), 7 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> index 9dc35ab973f2..0c41286b8223 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:
> @@ -26,14 +27,12 @@ properties:
> maxItems: 1
>
> clocks:
> - items:
> - - description: DC Core clock
> - - description: DMA AXI bus clock
> - - description: Configuration AHB bus clock
> - - description: Pixel clock of output 0
> - - description: Pixel clock of output 1
Clock descriptions should still be in the global part instead of the
per-compatible part.
In the per-compatible part, clock-names should be constraint for SoCs.
> + minItems: 2
> + maxItems: 5
>
> clock-names:
> + minItems: 2
> + maxItems: 5
> items:
> - const: core
> - const: axi
> @@ -42,12 +41,16 @@ properties:
> - const: pix1
>
> resets:
> + minItems: 1
> + maxItems: 3
> items:
> - description: DC Core reset
> - description: DMA AXI bus reset
> - description: Configuration AHB bus reset
>
> reset-names:
> + minItems: 1
> + maxItems: 3
> items:
> - const: core
> - const: axi
> @@ -59,7 +62,7 @@ properties:
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description: The first output channel , endpoint 0 should be
> + description: The first output channel, endpoint 0 should be
If you really want to fix this, please make it a separated patch
instead of doing it here, for commit atomicity.
Thanks,
Icenowy
> used for DPI format output and endpoint 1 should be used
> for DP format output.
>
> @@ -77,6 +80,69 @@ required:
> - clock-names
> - ports
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: thead,th1520-dc8200
> + then:
> + properties:
> + clocks:
> + minItems: 5
> + maxItems: 5
> + items:
> + - description: DC Core clock
> + - description: DMA AXI bus clock
> + - description: Configuration AHB bus clock
> + - description: Pixel clock of output 0
> + - description: Pixel clock of output 1
> +
> + clock-names:
> + minItems: 5
> + maxItems: 5
> +
> + resets:
> + minItems: 3
> + maxItems: 3
> +
> + reset-names:
> + minItems: 3
> + maxItems: 3
> +
> + required:
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nuvoton,ma35d1-dcu
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + items:
> + - description: DC Core clock
> + - description: Pixel clock of output 0
> +
> + clock-names:
> + minItems: 2
> + maxItems: 2
> +
> + resets:
> + minItems: 1
> + maxItems: 1
> +
> + reset-names:
> + maxItems: 1
> +
> + required:
> + - resets
> + - reset-names
> +
> additionalProperties: false
>
> examples:
^ 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