* Re: [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Marc Zyngier @ 2026-04-21 16:45 UTC (permalink / raw)
To: Jing Zhang
Cc: KVM, KVMARM, ARMLinux, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Paolo Bonzini
In-Reply-To: <20260421164112.2448553-1-jingzhangos@google.com>
On Tue, 21 Apr 2026 17:41:12 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
>
> ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
> marked as signed in the cpufeature table. This led
> kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
> systems with PMUv3p8 or newer, as the signed extraction of the field
> (e.g., 0b1000 for PMUv3p8) would result in a negative value.
>
> Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
> and updating the KVM initialization code to use unsigned extraction.
> While at it, ensure that both the 'Not Implemented' (0b0000) and
> 'Implementation Defined' (0b1111) values are correctly handled as
> indicating the absence of a standard PMUv3.
>
> Signed-off-by: Jing Zhang <jingzhangos@google.com>
https://lore.kernel.org/all/20260305-james-kvm-pmuver-sign-v2-0-ee80a125af9b@linaro.org/
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Conor Dooley @ 2026-04-21 16:43 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown,
linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260421-add-mcu-fan-khadas-vim4-v4-1-447114a28f2d@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Apr 21, 2026 at 01:49:18PM +0200, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Jing Zhang @ 2026-04-21 16:41 UTC (permalink / raw)
To: KVM, KVMARM, ARMLinux, Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Paolo Bonzini,
Jing Zhang
ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
marked as signed in the cpufeature table. This led
kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
systems with PMUv3p8 or newer, as the signed extraction of the field
(e.g., 0b1000 for PMUv3p8) would result in a negative value.
Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
and updating the KVM initialization code to use unsigned extraction.
While at it, ensure that both the 'Not Implemented' (0b0000) and
'Implementation Defined' (0b1111) values are correctly handled as
indicating the absence of a standard PMUv3.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
---
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kvm/debug.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 32c2dbcc0c641..1b5e37a1a41b4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -565,7 +565,7 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
* We can instantiate multiple PMU instances with different levels
* of support.
*/
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_EL1_DebugVer_SHIFT, 4, 0x6),
ARM64_FTR_END,
};
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 3ad6b7c6e4ba7..2834d7ef9dedb 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -75,8 +75,10 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
void kvm_init_host_debug_data(void)
{
u64 dfr0 = read_sysreg(id_aa64dfr0_el1);
+ u64 pmuver;
- if (cpuid_feature_extract_signed_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT) > 0)
+ pmuver = cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT);
+ if (pmuv3_implemented(pmuver))
*host_data_ptr(nr_event_counters) = FIELD_GET(ARMV8_PMU_PMCR_N,
read_sysreg(pmcr_el0));
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Will Deacon @ 2026-04-21 16:38 UTC (permalink / raw)
To: Robin Murphy; +Cc: leo.jiang1224, joro, iommu, linux-arm-kernel
In-Reply-To: <0fdf4b1f-90f2-4f69-9d2b-dc5f608e9c1c@arm.com>
On Tue, Apr 21, 2026 at 04:56:47PM +0100, Robin Murphy wrote:
> On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> > From: LoserJL <leo.jiang1224@foxmail.com>
> >
> > In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> > dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> > allocates at least PAGE_SIZE, retrying with a smaller size after
> > a PAGE_SIZE failure is logically redundant.
>
> Says who? It's certainly not a guarantee offered by the DMA API itself, and
> indeed some allocation paths can definitely still allocate less than a page
> - e.g. anything which hits a per-device or global coherent pool.
>
> > Moreover, if a sub-page retry were to succeed due to concurrent memory
> > release, the hardware would be configured with a smaller queue depth
> > despite a full page being allocated. This leads to inefficient memory
> > usage and unnecessary hardware performance limitation.
> >
> > Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> > consistency and optimal hardware configuration.
>
> That's really not an argument - even if an allocator does happen to
> over-allocate for the requested size, that is hardly the caller's concern;
> and as far as "optimal" queue sizes go in this case, those very much depend
> on the number of CPUs issuing commands and volume of expected stall/PRI
> events - in many cases PAGE_SIZE would already be far too small to really
> work well.
>
> Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
> queue, there would be very little chance of the subsequent allocation(s) for
> the stream table succeeding, so realistically the driver is probably going
> to end up failing to probe in such circumstances anyway.
That's all true, but tbf I think I just fscked up the comparison in
d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") so
I'm not against fixing that up even though the "rationale" given by
Loser doesn't make a whole lot of sense.
Will
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: Ferass El Hafidi @ 2026-04-21 16:37 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Changes in v3:
>- Change position of the entry in the amlogic.yaml.
>- Change formatting of the Amlogic W150S1 Wi-Fi module comment.
>- Fix several formatting issues.
>
>Changes in v2:
>- Split dt-bindings and dts changes into separate patches.
>- Updated model string to match documented vendor prefix.
>- Put vddio_sd states array in a single line.
>- Added a comment for the unsupported Amlogic W150S1 Wi-Fi module.
>
Where did the rest of the cover letter go?
>Christian Stefan Kövér-Draxl (2):
> dt-bindings: arm: amlogic: add support for Amediatech X98Q
> arm64: dts: amlogic: add support for X98Q
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: amlogic: add support for X98Q
From: Ferass El Hafidi @ 2026-04-21 16:33 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-3-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Add dts enabling core hardware for the Amediatech X98Q.
>
You should explain what the Amediatech X98Q is. You did this in the v2's
cover letter, but it should additionally go in here too so it's visible
in git commits in the kernel. What hardware does it have? Maybe also what is
enabled in the DT?
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
><...>
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v2 5/9] ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
From: Daniel Golle @ 2026-04-21 16:12 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jaroslav Kysela,
Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <95e1067c-3c8e-4dd4-997d-f3be9d2cba29@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Mon, Apr 20, 2026 at 07:08:01PM +0100, Mark Brown wrote:
> On Mon, Apr 20, 2026 at 02:13:34AM +0100, Daniel Golle wrote:
>
> > +static int mt2701_afe_hdmi_trigger(struct snd_pcm_substream *substream, int cmd,
> > + struct snd_soc_dai *dai)
> > +{
> > + struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
> > +
> > + switch (cmd) {
> > + case SNDRV_PCM_TRIGGER_START:
> > + case SNDRV_PCM_TRIGGER_RESUME:
> > + /* Ungate HDMI and SPDIF power islands. */
> > + regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
> > + AUDIO_TOP_CON0_PDN_HDMI_CK |
> > + AUDIO_TOP_CON0_PDN_SPDIF_CK, 0);
>
> It looks like we have clock API clocks for HDMI and S/PDIF on this SoC
> (see clk-mt2701-aud.c) - are there going to be problem with peering
> directly at the register? We do manage some clocks via the clock API
> but not those ones.
Yeah, you are right. That came from a super-old vendor driver and I
didn't realise the exact same gate bits are alrady driven by the
clock driver. I'll drop that and prepare v3...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Maxime Ripard @ 2026-04-21 16:10 UTC (permalink / raw)
To: Brian Masney
Cc: Sebastian Reichel, Alexey Charkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea
In-Reply-To: <aeZOMnZfBcBHzR8c@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]
Hi Brian, Alexey,
On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > Dear all,
> > >
> > > Need the help of the collective wisdom of the community.
> > >
> > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > clock for arbitrary display modes supported by the RK3576 SoC.
> > >
> > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > supporting different ranges of display modes, roughly as follows:
> > > - VP0: 4K 120Hz
> > > - VP1: 2.5k 60Hz
> > > - VP2: 1080p 60Hz
Do any of those have an additional multiplier or divider after the PLL?
I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
/ 8). 2.5k @ 60 might be a bit more problematic, but my point is that
for HDMI/DP, most resolutions all have a pixel clock that are multiples
of 148.5MHz.
If you manage to get the PLL to the highest you need (1188MHz), and then
apply dividers, you don't need to change the PLL frequency anymore.
> > > Each one obviously needs a pixel clock. The required frequencies for the
> > > pixel clocks vary greatly depending on the display mode, and need to be
> > > matched within a tight tolerance, or else many displays will refuse to
> > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > be obtained using integer dividers from its default clock source (GPLL
> > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > screen on most displays by default.
> > >
> > > The clock sources are of course configurable, in particular there are muxes
> > > connected to each VP for selecting the source of the pixel clock:
> > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > its dedicated dclk_vpX_src mux
> > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > >
> > > While the system PLLs can be configured to output a wide range of
> > > frequencies, they are shared between many system components. E.g. on the
> > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > GPLL: 1188 MHz, enable count 20
> > > CPLL: 1000 MHz, enable count 17
> > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > predividers, so are less flexible)
> > >
> > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > frequency on the fly to satisfy the requirements of the selected display
> > > mode.
> > >
> > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > three consumers while changing the PLL frequency on the fly sounds like
> > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > HDMI output out of the equation, because it can be driven from the HDMI
> > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > makes the decision of which dclk source to use for a VP block dependent on
> > > which downstream consumer is connected to it (HDMI vs. something else).
> >
> > It becomes more messy: The HDMI PHY cannot be used as clock source
> > for modes exceeding 4K@60Hz.
> >
> > > Even then we somehow need two devices to cooperate in picking a PLL
> > > frequency that satisfies the requirements of both of them, and change to it
> > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > for that?..
It's not *just* the CCF though. You will disrupt the other, already
active display, which might affect the user because the screen will
blank, throw off the vblank timings and thus userspace, etc.
Brian's solution is great progress on that front already, but if you can
just save yourself the trouble, I'd advise you to do that instead :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Leonardo Bras @ 2026-04-21 16:07 UTC (permalink / raw)
To: Breno Leitao
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, mark.rutland,
leo.yan, linux-arm-kernel, linux-kernel, palmer, paulmck,
puranjay, usama.arif, rmikey, kernel-team
In-Reply-To: <20260421-arm64_always_inline-v2-1-c59d1400514d@debian.org>
On Tue, Apr 21, 2026 at 08:58:57AM -0700, Breno Leitao wrote:
> The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
> underlying primitives: the __daif_* path on most systems, and the
> __pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
> leaf primitives are already __always_inline, but the wrappers themselves
> are plain "static inline".
>
> That is unsafe for noinstr callers: nothing prevents the compiler from
> emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
> out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
> breaks the noinstr contract on the entry/idle paths that rely on these
> helpers.
>
> x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
> ("x86/entry: __always_inline irqflags for noinstr").
>
> Force-inline all of the arch_local_irq_*() wrappers so they cannot be
> emitted out-of-line:
>
> - arch_local_irq_enable()
> - arch_local_irq_disable()
> - arch_local_save_flags()
> - arch_irqs_disabled_flags()
> - arch_irqs_disabled()
> - arch_local_irq_save()
> - arch_local_irq_restore()
>
> The primary motivation is noinstr safety. There is a useful side effect
> for fleet-wide profiling: when the wrapper is emitted out-of-line,
> samples taken inside it during the post-WFI IRQ unmask in
> default_idle_call() are attributed to arch_local_irq_enable rather than
> default_idle_call(), and the FP-unwinder loses default_idle_call() from
> the chain.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - Expand the functions that uses always_inline in arm64
> - Link to v1: https://patch.msgid.link/20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org
> ---
> arch/arm64/include/asm/irqflags.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index d4d7451c2c129..a8cb5a5c93b78 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_enable(void)
> +static __always_inline void arch_local_irq_enable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_enable();
> @@ -68,7 +68,7 @@ static __always_inline void __pmr_local_irq_disable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_disable(void)
> +static __always_inline void arch_local_irq_disable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_disable();
> @@ -90,7 +90,7 @@ static __always_inline unsigned long __pmr_local_save_flags(void)
> /*
> * Save the current interrupt enable state.
> */
> -static inline unsigned long arch_local_save_flags(void)
> +static __always_inline unsigned long arch_local_save_flags(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_save_flags();
> @@ -109,7 +109,7 @@ static __always_inline bool __pmr_irqs_disabled_flags(unsigned long flags)
> return flags != GIC_PRIO_IRQON;
> }
>
> -static inline bool arch_irqs_disabled_flags(unsigned long flags)
> +static __always_inline bool arch_irqs_disabled_flags(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled_flags(flags);
> @@ -128,7 +128,7 @@ static __always_inline bool __pmr_irqs_disabled(void)
> return __pmr_irqs_disabled_flags(__pmr_local_save_flags());
> }
>
> -static inline bool arch_irqs_disabled(void)
> +static __always_inline bool arch_irqs_disabled(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled();
> @@ -160,7 +160,7 @@ static __always_inline unsigned long __pmr_local_irq_save(void)
> return flags;
> }
>
> -static inline unsigned long arch_local_irq_save(void)
> +static __always_inline unsigned long arch_local_irq_save(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_irq_save();
> @@ -187,7 +187,7 @@ static __always_inline void __pmr_local_irq_restore(unsigned long flags)
> /*
> * restore saved IRQ state
> */
> -static inline void arch_local_irq_restore(unsigned long flags)
> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_restore(flags);
>
> ---
> base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
> change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
Looks correct to what was discussed in V1. FWIW:
Reviewed-by: Leonardo Bras <leo.bras@arm.com>
^ permalink raw reply
* Re: [PATCH 12/18] KVM: arm64: selftests: Add missing GIC CDEN to no-vgic-v5 selftest
From: Joey Gouly @ 2026-04-21 16:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-13-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:53PM +0100, Marc Zyngier wrote:
> From: Sascha Bischoff <sascha.bischoff@arm.com>
>
> The selftest mistakenly omitted the GIC CDEN instruction from the
> testing. Add it in.
Compared against the list of instructions in the spec.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
>
> Fixes: ce29261ec648 ("KVM: arm64: selftests: Add no-vgic-v5 selftest")
> Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> tools/testing/selftests/kvm/arm64/no-vgic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/kvm/arm64/no-vgic.c b/tools/testing/selftests/kvm/arm64/no-vgic.c
> index b14686ef17d12..e09e3fac904f4 100644
> --- a/tools/testing/selftests/kvm/arm64/no-vgic.c
> +++ b/tools/testing/selftests/kvm/arm64/no-vgic.c
> @@ -159,6 +159,7 @@ static void guest_code_gicv5(void)
> check_gicv5_gic_op(CDAFF);
> check_gicv5_gic_op(CDDI);
> check_gicv5_gic_op(CDDIS);
> + check_gicv5_gic_op(CDEN);
> check_gicv5_gic_op(CDEOI);
> check_gicv5_gic_op(CDHM);
> check_gicv5_gic_op(CDPEND);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 14/20] drm/mode-config: Create drm_mode_config_create_state()
From: Dmitry Baryshkov @ 2026-04-21 16:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-14-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:21PM +0100, Maxime Ripard wrote:
> drm_mode_config_reset() can be used to create the initial state, but
> also to return to the initial state, when doing a suspend/resume cycle
> for example.
>
> It also affects both the software and the hardware, and drivers can
> choose to reset the hardware as well. Most will just create an empty
> state and the synchronisation between hardware and software states will
> effectively be done when the first commit is done.
>
> That dual role can be harmful, since some objects do need to be
> initialized but also need to be preserved across a suspend/resume cycle.
> drm_private_obj are such objects for example.
>
> Thus, let's create another helper for drivers to call to initialize
> their state when the driver is loaded, so we can make
> drm_mode_config_reset() only about handling suspend/resume and similar.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 12 +++++-
> drivers/gpu/drm/drm_mode_config.c | 87 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 1 +
> 3 files changed, 98 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 10/20] drm/crtc: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 16:01 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-10-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:17PM +0100, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software tate, reset it, but
> also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with crtcs.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_crtc.h | 13 +++++++++
> 4 files changed, 84 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 16/20] drm/atomic: Drop private obj state allocation
From: Dmitry Baryshkov @ 2026-04-21 15:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-16-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:23PM +0100, Maxime Ripard wrote:
> Now that drm_dev_register() calls drm_mode_config_create_state() for
> every modeset driver, the private obj states will be initialized at
> driver registration automatically if they haven't already.
>
> Thus, the explicit initial allocation we have in
> drm_atomic_private_obj_init() is now redundant, and we can remove it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 7 -------
> 1 file changed, 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Breno Leitao @ 2026-04-21 15:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, mark.rutland
Cc: leo.bras, leo.yan, linux-arm-kernel, linux-kernel, palmer,
paulmck, puranjay, usama.arif, rmikey, kernel-team, Breno Leitao
The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
underlying primitives: the __daif_* path on most systems, and the
__pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
leaf primitives are already __always_inline, but the wrappers themselves
are plain "static inline".
That is unsafe for noinstr callers: nothing prevents the compiler from
emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
breaks the noinstr contract on the entry/idle paths that rely on these
helpers.
x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
("x86/entry: __always_inline irqflags for noinstr").
Force-inline all of the arch_local_irq_*() wrappers so they cannot be
emitted out-of-line:
- arch_local_irq_enable()
- arch_local_irq_disable()
- arch_local_save_flags()
- arch_irqs_disabled_flags()
- arch_irqs_disabled()
- arch_local_irq_save()
- arch_local_irq_restore()
The primary motivation is noinstr safety. There is a useful side effect
for fleet-wide profiling: when the wrapper is emitted out-of-line,
samples taken inside it during the post-WFI IRQ unmask in
default_idle_call() are attributed to arch_local_irq_enable rather than
default_idle_call(), and the FP-unwinder loses default_idle_call() from
the chain.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Expand the functions that uses always_inline in arm64
- Link to v1: https://patch.msgid.link/20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org
---
arch/arm64/include/asm/irqflags.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
index d4d7451c2c129..a8cb5a5c93b78 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
barrier();
}
-static inline void arch_local_irq_enable(void)
+static __always_inline void arch_local_irq_enable(void)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_enable();
@@ -68,7 +68,7 @@ static __always_inline void __pmr_local_irq_disable(void)
barrier();
}
-static inline void arch_local_irq_disable(void)
+static __always_inline void arch_local_irq_disable(void)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_disable();
@@ -90,7 +90,7 @@ static __always_inline unsigned long __pmr_local_save_flags(void)
/*
* Save the current interrupt enable state.
*/
-static inline unsigned long arch_local_save_flags(void)
+static __always_inline unsigned long arch_local_save_flags(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_local_save_flags();
@@ -109,7 +109,7 @@ static __always_inline bool __pmr_irqs_disabled_flags(unsigned long flags)
return flags != GIC_PRIO_IRQON;
}
-static inline bool arch_irqs_disabled_flags(unsigned long flags)
+static __always_inline bool arch_irqs_disabled_flags(unsigned long flags)
{
if (system_uses_irq_prio_masking()) {
return __pmr_irqs_disabled_flags(flags);
@@ -128,7 +128,7 @@ static __always_inline bool __pmr_irqs_disabled(void)
return __pmr_irqs_disabled_flags(__pmr_local_save_flags());
}
-static inline bool arch_irqs_disabled(void)
+static __always_inline bool arch_irqs_disabled(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_irqs_disabled();
@@ -160,7 +160,7 @@ static __always_inline unsigned long __pmr_local_irq_save(void)
return flags;
}
-static inline unsigned long arch_local_irq_save(void)
+static __always_inline unsigned long arch_local_irq_save(void)
{
if (system_uses_irq_prio_masking()) {
return __pmr_local_irq_save();
@@ -187,7 +187,7 @@ static __always_inline void __pmr_local_irq_restore(unsigned long flags)
/*
* restore saved IRQ state
*/
-static inline void arch_local_irq_restore(unsigned long flags)
+static __always_inline void arch_local_irq_restore(unsigned long flags)
{
if (system_uses_irq_prio_masking()) {
__pmr_local_irq_restore(flags);
---
base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH v2 20/20] drm/bridge_connector: Convert to atomic_create_state
From: Dmitry Baryshkov @ 2026-04-21 15:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Laurent Pinchart
In-Reply-To: <20260320-drm-mode-config-init-v2-20-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:27PM +0100, Maxime Ripard wrote:
> The connector created by drm_bridge_connector only initializes a
> pristine state in reset, which is equivalent to that atomic_create_state
> would expect. Let's convert to it.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Dmitry Baryshkov @ 2026-04-21 15:57 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <dd39f423-1598-4749-8c95-98b8daf69680@suse.de>
On Tue, Apr 21, 2026 at 05:33:12PM +0200, Thomas Zimmermann wrote:
>
>
> Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > > Almost all drivers, and our documented skeleton, call
> > > drm_mode_config_reset() prior to calling drm_dev_register() to
> > > initialize its DRM object states.
> > >
> > > Now that we have drm_mode_config_create_state() to create that initial
> > > state if it doesn't exist, we can call it directly in
> > > drm_dev_register(). That way, we know that the initial atomic state will
> > > always be allocated without any boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
> > > 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
> > > unsigned long flags)
> > > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > > ret = drm_modeset_register_all(dev);
> > > if (ret)
> > > goto err_unload;
> > > +
> > > + ret = drm_mode_config_create_state(dev);
> > > + if (ret)
> > > + goto err_unload;
> >
> > Way too late. Lets rather go through drivers and call this where they
> > currently call drm_mode_config_reset() for initialization. This can be a
> > single-patch mass conversion IMHO.
>
> On a second thought, can't we modify the suspend code and leave the reset
> as-is for now? I'd still be interested to use reset as a means of
> initializing the hardware or loading state on probe. So keeping the _reset()
> calls in place might be helpful for that.
But isn't it the expected behaviour? The driver can reset(), but if
it didn't, the default would be to create empty working state. In the
end, the drivers also can call this function to create the state, don't
they (and then perform the readout logic)?
>
> What's the long-term plan here?
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > > }
> > > drm_panic_register(dev);
> > > drm_client_sysrq_register(dev);
> > > DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
> > >
> >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 0/6] Add Rockchip RK3576 PWM Support Through MFPWM
From: Jonathan Cameron @ 2026-04-21 15:56 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
Damon Ding, kernel, Jonas Karlman, Alexey Charkov, linux-rockchip,
linux-pwm, devicetree, linux-arm-kernel, linux-kernel, linux-iio,
Conor Dooley
In-Reply-To: <20260420-rk3576-pwm-v5-0-ae7cfbbe5427@collabora.com>
On Mon, 20 Apr 2026 15:52:37 +0200
Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> This series introduces support for some of the functions of the new PWM
> silicon found on Rockchip's RK3576 SoC. Due to the wide range of
> functionalities offered by it, including many parts which this series'
> first iteration does not attempt to implement for now. The drivers are
> modelled as an MFD, with no leakage of the MFD-ness into the binding, as
> it's a Linux implementation detail.
Just thought I'd point out that as this includes the linux-iio
list sashiko took a look at it. Quite a few things and at least
the first one I looked at was valid (a dereference before a validity
check)
https://sashiko.dev/#/patchset/20260420-rk3576-pwm-v5-0-ae7cfbbe5427%40collabora.com
Whilst this tool does generate some false positives, it also finds
quite a few things it seems us humans fail to spot.
Jonathan
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Robin Murphy @ 2026-04-21 15:56 UTC (permalink / raw)
To: leo.jiang1224, will; +Cc: joro, iommu, linux-arm-kernel
In-Reply-To: <tencent_F6E384A40D990A279B460A0CDE1927FDF509@qq.com>
On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> From: LoserJL <leo.jiang1224@foxmail.com>
>
> In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> allocates at least PAGE_SIZE, retrying with a smaller size after
> a PAGE_SIZE failure is logically redundant.
Says who? It's certainly not a guarantee offered by the DMA API itself,
and indeed some allocation paths can definitely still allocate less than
a page - e.g. anything which hits a per-device or global coherent pool.
> Moreover, if a sub-page retry were to succeed due to concurrent memory
> release, the hardware would be configured with a smaller queue depth
> despite a full page being allocated. This leads to inefficient memory
> usage and unnecessary hardware performance limitation.
>
> Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> consistency and optimal hardware configuration.
That's really not an argument - even if an allocator does happen to
over-allocate for the requested size, that is hardly the caller's
concern; and as far as "optimal" queue sizes go in this case, those very
much depend on the number of CPUs issuing commands and volume of
expected stall/PRI events - in many cases PAGE_SIZE would already be far
too small to really work well.
Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
queue, there would be very little chance of the subsequent allocation(s)
for the stream table succeeding, so realistically the driver is probably
going to end up failing to probe in such circumstances anyway.
Thanks,
Robin.
> Signed-off-by: LoserJL <leo.jiang1224@foxmail.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..e0ec118ff560 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4418,7 +4418,14 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
> qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
> q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
> GFP_KERNEL);
> - if (q->base || qsz < PAGE_SIZE)
> + /*
> + * If allocation succeeds, we're done. If it fails, only retry
> + * if the requested size is still larger than a page. Since
> + * dmam_alloc_coherent() allocates at least PAGE_SIZE, retrying
> + * with a sub-page size is logically redundant and could lead
> + * to sub-optimal hardware configuration.
> + */
> + if (q->base || qsz <= PAGE_SIZE)
> break;
>
> q->llq.max_n_shift--;
^ permalink raw reply
* Re: [PATCH 05/18] KVM: arm64: vgic: Constify struct irq_ops usage
From: Joey Gouly @ 2026-04-21 15:54 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-6-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:46PM +0100, Marc Zyngier wrote:
> vgic-v5 has introduced much more prevalent usage of the struct
> irq_ops mechanism.
>
> In the process, it becomes evident that suffers from two related
> problems:
>
> - it contains flags, rather than only callbacks
> - it is mutable, because we need to update the above flags
>
> Swap the flags for a helper retrieving the flags, and make all
> irq_ops const, something that is slightly satisfying.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> ---
> arch/arm64/kvm/arch_timer.c | 14 +++++++++-----
> arch/arm64/kvm/vgic/vgic-v5.c | 2 +-
> arch/arm64/kvm/vgic/vgic.c | 2 +-
> include/kvm/arm_vgic.h | 9 +++++----
> 4 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
> index cbea4d9ee9552..f003df76fdda7 100644
> --- a/arch/arm64/kvm/arch_timer.c
> +++ b/arch/arm64/kvm/arch_timer.c
> @@ -52,11 +52,17 @@ static u64 kvm_arm_timer_read(struct kvm_vcpu *vcpu,
> enum kvm_arch_timer_regs treg);
> static bool kvm_arch_timer_get_input_level(int vintid);
>
> -static struct irq_ops arch_timer_irq_ops = {
> +static unsigned long kvm_arch_timer_get_irq_flags(void)
> +{
> + return kvm_vgic_global_state.no_hw_deactivation ? VGIC_IRQ_SW_RESAMPLE : 0;
> +}
> +
> +static const struct irq_ops arch_timer_irq_ops = {
> + .get_flags = kvm_arch_timer_get_irq_flags,
> .get_input_level = kvm_arch_timer_get_input_level,
> };
>
> -static struct irq_ops arch_timer_irq_ops_vgic_v5 = {
> +static const struct irq_ops arch_timer_irq_ops_vgic_v5 = {
> .get_input_level = kvm_arch_timer_get_input_level,
> .queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
> .set_direct_injection = vgic_v5_set_ppi_dvi,
> @@ -1392,8 +1398,6 @@ static int kvm_irq_init(struct arch_timer_kvm_info *info)
> return -ENOMEM;
> }
>
> - if (kvm_vgic_global_state.no_hw_deactivation)
> - arch_timer_irq_ops.flags |= VGIC_IRQ_SW_RESAMPLE;
> WARN_ON(irq_domain_push_irq(domain, host_vtimer_irq,
> (void *)TIMER_VTIMER));
> }
> @@ -1591,8 +1595,8 @@ static bool kvm_arch_timer_get_input_level(int vintid)
> int kvm_timer_enable(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = vcpu_timer(vcpu);
> + const struct irq_ops *ops;
> struct timer_map map;
> - struct irq_ops *ops;
> int ret;
>
> if (timer->enabled)
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 0101ec3f55283..757484d2493b2 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -285,7 +285,7 @@ void vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, struct vgic_irq *irq, bool dvi)
> __assign_bit(ppi, cpu_if->vgic_ppi_dvir, dvi);
> }
>
> -static struct irq_ops vgic_v5_ppi_irq_ops = {
> +static const struct irq_ops vgic_v5_ppi_irq_ops = {
> .queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
> .set_direct_injection = vgic_v5_set_ppi_dvi,
> };
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> index 1e9fe8764584d..3ac6d49bc4876 100644
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -573,7 +573,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> }
>
> void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
> - struct irq_ops *ops)
> + const struct irq_ops *ops)
> {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, vintid);
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index ea793479ab254..fe49fb56dc3c9 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -205,7 +205,7 @@ struct vgic_irq;
> */
> struct irq_ops {
> /* Per interrupt flags for special-cased interrupts */
> - unsigned long flags;
> + unsigned long (*get_flags)(void);
>
> #define VGIC_IRQ_SW_RESAMPLE BIT(0) /* Clear the active state for resampling */
>
> @@ -271,7 +271,7 @@ struct vgic_irq {
> u8 priority;
> u8 group; /* 0 == group 0, 1 == group 1 */
>
> - struct irq_ops *ops;
> + const struct irq_ops *ops;
>
> void *owner; /* Opaque pointer to reserve an interrupt
> for in-kernel devices. */
> @@ -279,7 +279,8 @@ struct vgic_irq {
>
> static inline bool vgic_irq_needs_resampling(struct vgic_irq *irq)
> {
> - return irq->ops && (irq->ops->flags & VGIC_IRQ_SW_RESAMPLE);
> + return irq->ops && irq->ops->get_flags &&
> + (irq->ops->get_flags() & VGIC_IRQ_SW_RESAMPLE);
> }
>
> struct vgic_register_region;
> @@ -557,7 +558,7 @@ void kvm_vgic_init_cpu_hardware(void);
> int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> unsigned int intid, bool level, void *owner);
> void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
> - struct irq_ops *ops);
> + const struct irq_ops *ops);
> void kvm_vgic_clear_irq_ops(struct kvm_vcpu *vcpu, u32 vintid);
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> u32 vintid);
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: amlogic: add support for X98Q
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Add dts enabling core hardware for the Amediatech X98Q.
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
2 files changed, 250 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..c7752684dea6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-ugoos-am3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..3eecbc858522
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ * Based on meson-s4-s905y4-khadas-vim1s.dts:
+ * - Copyright (c) 2026 Khadas Technology Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+ /*
+ * Wireless SDIO Module (Amlogic W150S1)
+ * Note: There is no driver for this at the moment.
+ */
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: amlogic: add support for Amediatech X98Q
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Add the board binding for the Amediatech X98Q TV box
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..c0167fbc310a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -248,6 +248,13 @@ properties:
- const: amlogic,s805x2
- const: amlogic,s4
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
+
- description: Boards with the Amlogic Meson S4 S905Y4 SoC
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Changes in v3:
- Change position of the entry in the amlogic.yaml.
- Change formatting of the Amlogic W150S1 Wi-Fi module comment.
- Fix several formatting issues.
Changes in v2:
- Split dt-bindings and dts changes into separate patches.
- Updated model string to match documented vendor prefix.
- Put vddio_sd states array in a single line.
- Added a comment for the unsupported Amlogic W150S1 Wi-Fi module.
Christian Stefan Kövér-Draxl (2):
dt-bindings: arm: amlogic: add support for Amediatech X98Q
arm64: dts: amlogic: add support for X98Q
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
3 files changed, 257 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 13/20] drm/connector: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 15:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-13-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:20PM +0100, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software tate, reset it, but
> also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with connectors.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 45 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_connector.h | 13 +++++++++
> 4 files changed, 82 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io()
From: Hari Prasath G E @ 2026-04-21 15:50 UTC (permalink / raw)
To: Siddharth Vadapalli, nm, ssantosh
Cc: stable, linux-kernel, linux-arm-kernel, srk, s-adivi
In-Reply-To: <20260413065125.627180-1-s-vadapalli@ti.com>
Hello Siddharth,
Thanks for the patch.
On 4/13/2026 12:21 PM, Siddharth Vadapalli wrote:
> k3_ringacc_ring_pop_tail_io() invokes k3_ringacc_ring_access_io() with the
> access mode incorrectly set to K3_RINGACC_ACCESS_MODE_POP_HEAD instead of
> K3_RINGACC_ACCESS_MODE_POP_TAIL. Fix this.
>
> Fixes: 3277e8aa2504 ("soc: ti: k3: add navss ringacc driver")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
> Hello,
>
> This patch is based on commit
> 028ef9c96e96 Linux 7.0
> of Mainline Linux.
>
> I noticed (visually) the incorrect access mode while working on:
> https://lore.kernel.org/r/20260325123850.638748-1-s-vadapalli@ti.com/
>
> Regards,
> Siddharth.
>
> drivers/soc/ti/k3-ringacc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
> index 7602b8a909b0..24f658e8c1dc 100644
> --- a/drivers/soc/ti/k3-ringacc.c
> +++ b/drivers/soc/ti/k3-ringacc.c
> @@ -1083,7 +1083,7 @@ static int k3_ringacc_ring_pop_io(struct k3_ring *ring, void *elem)
> static int k3_ringacc_ring_pop_tail_io(struct k3_ring *ring, void *elem)
> {
> return k3_ringacc_ring_access_io(ring, elem,
> - K3_RINGACC_ACCESS_MODE_POP_HEAD);
> + K3_RINGACC_ACCESS_MODE_POP_TAIL);
I see that you have noticed this visually and fixed this,was there any
impact you faced without this change like data corruption or something ?
It would be better to mention the impact this change brings-in by doing
some analysis.
There is a similar function k3_ringacc_ring_pop_tail_proxy() few lines
above where the same change might be required.
Regards,
Hari
> }
>
> /*
^ permalink raw reply
* Re: [PATCH v2 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-11-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:18PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ 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