* [PATCH 3/9] ASoC: mediatek: mt2701: add AFE HDMI register definitions
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Add register offsets and bit defines for the MT2701/MT7623N AFE
HDMI audio output path: the HDMI BCK divider in AUDIO_TOP_CON3,
the HDMI output memif control and descriptor registers, the 8-bit
AFE_HDMI_CONN0 interconnect, and the AFE_8CH_I2S_OUT_CON engine
that drives the HDMI TX serial link. These are a prerequisite for
adding an HDMI playback path to the mt2701 AFE driver and have no
behavioural effect on their own.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
sound/soc/mediatek/mt2701/mt2701-reg.h | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index c84d14cdd7ae8..b7a25bfb58662 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -10,10 +10,17 @@
#define _MT2701_REG_H_
#define AUDIO_TOP_CON0 0x0000
+#define AUDIO_TOP_CON3 0x000c
#define AUDIO_TOP_CON4 0x0010
#define AUDIO_TOP_CON5 0x0014
#define AFE_DAIBT_CON0 0x001c
#define AFE_MRGIF_CON 0x003c
+#define AFE_HDMI_OUT_CON0 0x0370
+#define AFE_HDMI_OUT_BASE 0x0374
+#define AFE_HDMI_OUT_CUR 0x0378
+#define AFE_HDMI_OUT_END 0x037c
+#define AFE_HDMI_CONN0 0x0390
+#define AFE_8CH_I2S_OUT_CON 0x0394
#define ASMI_TIMING_CON1 0x0100
#define ASMO_TIMING_CON1 0x0104
#define PWR1_ASM_CON1 0x0108
@@ -125,6 +132,34 @@
#define AFE_MEMIF_PBUF_SIZE_DLM_BYTE_MASK (0x3 << 12)
#define AFE_MEMIF_PBUF_SIZE_DLM_32BYTES (0x1 << 12)
+/* AUDIO_TOP_CON0 (0x0000) -- HDMI audio clock gating */
+#define AUDIO_TOP_CON0_PDN_HDMI_CK (0x1 << 20)
+#define AUDIO_TOP_CON0_PDN_SPDIF_CK (0x1 << 21)
+#define AUDIO_TOP_CON0_PDN_SPDIF2_CK (0x1 << 22)
+#define AUDIO_TOP_CON0_PDN_APLL_CK (0x1 << 23)
+
+/* AUDIO_TOP_CON3 (0x000c) -- HDMI BCK divider */
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV_MASK (0x3f << 8)
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV(x) (((x) & 0x3f) << 8)
+
+/* AFE_HDMI_OUT_CON0 (0x0370) */
+#define AFE_HDMI_OUT_CON0_OUT_ON (0x1 << 0)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_MASK (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_16 (0x0 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_32 (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_CH_NUM_MASK (0xf << 4)
+#define AFE_HDMI_OUT_CON0_CH_NUM(x) (((x) & 0xf) << 4)
+
+/* AFE_8CH_I2S_OUT_CON (0x0394) -- on-SoC 8-channel I2S that feeds HDMI TX */
+#define AFE_8CH_I2S_OUT_CON_EN (0x1 << 0)
+#define AFE_8CH_I2S_OUT_CON_BCK_INV (0x1 << 1)
+#define AFE_8CH_I2S_OUT_CON_LRCK_INV (0x1 << 2)
+#define AFE_8CH_I2S_OUT_CON_I2S_DELAY (0x1 << 3)
+#define AFE_8CH_I2S_OUT_CON_WLEN_MASK (0x3 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_16BIT (0x1 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_24BIT (0x2 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_32BIT (0x3 << 4)
+
/* I2S in/out register bit control */
#define ASYS_I2S_CON_FS (0x1f << 8)
#define ASYS_I2S_CON_FS_SET(x) ((x) << 8)
--
2.53.0
^ permalink raw reply related
* [PATCH 2/9] dt-bindings: sound: add mediatek,mt2701-hdmi-audio machine binding
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Describe the ASoC machine compatible used to wire the MT2701/MT7623N
AFE HDMI playback path to the on-chip HDMI transmitter acting as the
generic HDMI audio codec. MT7623N boards carry the same IP and use
the mt7623n- compatible as a fallback to mt2701-.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../sound/mediatek,mt2701-hdmi-audio.yaml | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
new file mode 100644
index 0000000000000..d08aee447b471
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-hdmi-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2701 HDMI audio machine driver
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ ASoC machine driver binding the MT2701 AFE HDMI playback path to
+ the on-chip HDMI transmitter via the generic HDMI audio codec.
+ The same HDMI audio IP is present on MT7623N.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt2701-hdmi-audio
+ - items:
+ - const: mediatek,mt7623n-hdmi-audio
+ - const: mediatek,mt2701-hdmi-audio
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the MT2701/MT7623N AFE platform node.
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the HDMI transmitter acting as audio codec.
+
+required:
+ - compatible
+ - mediatek,platform
+ - mediatek,audio-codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-hdmi {
+ compatible = "mediatek,mt7623n-hdmi-audio",
+ "mediatek,mt2701-hdmi-audio";
+ mediatek,platform = <&afe>;
+ mediatek,audio-codec = <&hdmi0>;
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH 1/9] dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Document four additional optional clocks feeding the HDMI audio
output path on MT2701 and MT7623N: the HADDS2 PLL (root of the
HDMI audio clock tree), the HDMI audio and S/PDIF interface power
gates, and the audio APLL root gate. Older device trees that do
not wire these up remain valid via minItems.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../bindings/sound/mediatek,mt2701-audio.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
index 45382c4d86aa3..9d4fc542cd72c 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
@@ -32,6 +32,7 @@ properties:
maxItems: 1
clocks:
+ minItems: 34
items:
- description: audio infra sys clock
- description: top audio mux 1
@@ -67,8 +68,13 @@ properties:
- description: top audio a1 sys pd
- description: top audio a2 sys pd
- description: audio merge interface pd
+ - description: HADDS2 PLL 294 MHz (HDMI audio path root)
+ - description: HDMI audio interface pd
+ - description: S/PDIF interface pd
+ - description: audio APLL root pd
clock-names:
+ minItems: 34
items:
- const: infra_sys_audio_clk
- const: top_audio_mux1_sel
@@ -104,6 +110,10 @@ properties:
- const: audio_a1sys_pd
- const: audio_a2sys_pd
- const: audio_mrgif_pd
+ - const: hadds2pll_294m
+ - const: audio_hdmi_pd
+ - const: audio_spdf_pd
+ - const: audio_apll_pd
required:
- compatible
--
2.53.0
^ permalink raw reply related
* [PATCH 0/9] ASoC: mediatek: mt2701: HDMI audio support
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
This series wires up on-chip HDMI audio on MT2701 and MT7623, from the
DRM bridge down through the AFE into a small machine driver that binds
the AFE HDMI BE to the HDMI TX codec already exposed by the
mediatek-drm-hdmi driver. Bindings, DT and a BananaPi R2 board node
are included.
In order to survive vblank or late hotplug of the monitor, the fix
submitted separately [1] is required as well.
Everything here was developed for and tested on a BananaPi R2
(MT7623N), which turns ten years old this year -- a nice occasion to
finally land native HDMI audio for a SoC which was truly ahead of its
time.
[1]: https://patchwork.kernel.org/project/linux-mediatek/patch/a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org/
Daniel Golle (9):
dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
dt-bindings: sound: add mediatek,mt2701-hdmi-audio machine binding
ASoC: mediatek: mt2701: add AFE HDMI register definitions
ASoC: mediatek: mt2701: add optional HDMI audio path clocks
ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
ASoC: mediatek: mt2701: add machine driver for on-chip HDMI codec
ARM: dts: mediatek: mt2701: wire HDMI audio path clocks into AFE
ARM: dts: mediatek: mt7623: wire HDMI audio path clocks into AFE
ARM: dts: mediatek: mt7623n-bananapi-bpi-r2: add HDMI audio machine
node
.../bindings/sound/mediatek,mt2701-audio.yaml | 10 +
.../sound/mediatek,mt2701-hdmi-audio.yaml | 47 +++
arch/arm/boot/dts/mediatek/mt2701.dtsi | 21 +-
arch/arm/boot/dts/mediatek/mt7623.dtsi | 21 +-
.../dts/mediatek/mt7623n-bananapi-bpi-r2.dts | 7 +
sound/soc/mediatek/Kconfig | 10 +
sound/soc/mediatek/mt2701/Makefile | 1 +
.../mediatek/mt2701/mt2701-afe-clock-ctrl.c | 22 ++
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 6 +
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 281 +++++++++++++++++-
sound/soc/mediatek/mt2701/mt2701-hdmi.c | 114 +++++++
sound/soc/mediatek/mt2701/mt2701-reg.h | 35 +++
12 files changed, 564 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
create mode 100644 sound/soc/mediatek/mt2701/mt2701-hdmi.c
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Add Broadcom channel priority commands
From: Luiz Augusto von Dentz @ 2026-04-15 15:19 UTC (permalink / raw)
To: Sasha Finkelstein
Cc: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, linux-kernel, asahi, linux-arm-kernel,
linux-bluetooth, netdev
In-Reply-To: <CAMT+MTQ6orj5tpiGL9hz8m2TGiBjA-9D_0e1iLt=_dXBFHcOgg@mail.gmail.com>
Hi Sasha,
On Wed, Apr 15, 2026 at 8:34 AM Sasha Finkelstein <fnkl.kernel@gmail.com> wrote:
>
> On Tue, 14 Apr 2026 at 16:00, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > > + if (sock)
> > > + set_bit(SOCK_CUSTOM_SOCKOPT, &sock->flags);
> >
> > This is more complicated than it needs to be. I'd just add a new
> > callback, `hdev->set_priority(handle, skb->priority)`, so the driver
> > is called whenever it needs to elevate a connection's priority, that
> > said there could be cases where a connection needs its priority set
> > momentarily to transmit A2DP, followed by OBEX packets that are best
> > effort. Therefore, `hci_conn` will probably need to track the priority
> > so it can detect when it needs changing on a per skb basis.
>
> I have tested per-skb priorities, and unfortunately, this does not work.
> If something tries to send a low-priority packet (for example - a volume
> adjustment), a priority drop causes the same kind of dropout that is
> caused by scans. It appears that the only way to make this hardware work
> is to set the entire hci connection as high priority for as long as it
> is being used to transmit audio.
Ok, then maybe we should decrease the priority, so it can only go up.
That said, in a multiple connection scenario, we cannot really tell
what should be prioritized if we cannot momentarily decrease the
priority.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH v29 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs properties
From: Conor Dooley @ 2026-04-15 15:19 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260415-upstream_i2c-v29-2-317c1a905ae1@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
On Wed, Apr 15, 2026 at 01:14:03PM +0800, Ryan Chen wrote:
> Add the aspeed,global-regs phandle to reference the AST2600 global
> registers syscon node, containing the SoC-common I2C register set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
I hate to do it to you on v29, but can you please explain what this
"soc-common i2c register set" actually is/does in your commit message.
The patch seems fine, so with that
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> Changes in v29:
> - remove aspeed,enable-dma properties.
>
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
>
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> index de2c359037da..0c769efb76a5 100644
> --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> @@ -37,6 +37,12 @@ properties:
> resets:
> maxItems: 1
>
> + aspeed,global-regs:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle reference to the i2c global syscon node, containing the
> + SoC-common i2c register set.
> +
> required:
> - reg
> - compatible
> @@ -59,4 +65,5 @@ examples:
> resets = <&syscon ASPEED_RESET_I2C>;
> clock-frequency = <100000>;
> interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + aspeed,global-regs = <&i2c_global>;
> };
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v29 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML
From: Conor Dooley @ 2026-04-15 15:16 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260415-upstream_i2c-v29-1-317c1a905ae1@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On Wed, Apr 15, 2026 at 01:14:02PM +0800, Ryan Chen wrote:
> The AST2600 I2C controller introduces a completely new register layout
> with separate controller and target register blocks, unlike the mixed
> register layout used by AST2400/AST2500.
>
> Move AST2600 I2C binding from aspeed,i2c.yaml to a dedicated
> aspeed,ast2600-i2c.yaml schema.
>
> Besides the split, this also adjusts for AST2600-specific requirements.
> - require two reg regions (controller register block + buffer block)
> - use clock-frequency for bus speed description
> - interrupts are required on AST2600
> - use correct DTS coding style in example
>
> No compatible strings are changed.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
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
* Re: [PATCH] pwm: atmel-tcb: Fix sleeping function called from invalid context
From: Uwe Kleine-König @ 2026-04-15 15:12 UTC (permalink / raw)
To: Sangyun Kim
Cc: nicolas.ferre, alexandre.belloni, claudiu.beznea, linux-pwm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260415093433.2359955-1-sangyun.kim@snu.ac.kr>
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
Hello Sangyun (I hope this is the right part of your name to address
you, feel free to tell me, when I'm wrong),
On Wed, Apr 15, 2026 at 06:34:33PM +0900, Sangyun Kim wrote:
> atmel_tcb_pwm_apply() holds tcbpwmc->lock as a spinlock via
> guard(spinlock)() and then calls atmel_tcb_pwm_config(), which calls
> clk_get_rate() twice. clk_get_rate() acquires clk_prepare_lock (a
> mutex), so this is a sleep-in-atomic-context violation.
>
> On CONFIG_DEBUG_ATOMIC_SLEEP kernels every pwm_apply_state() that
> enables or reconfigures the PWM triggers a "BUG: sleeping function
> called from invalid context" warning.
>
> All callers of tcbpwmc->lock (the .request and .apply callbacks) run in
> process context and only need mutual exclusion against each other, so
> use a mutex instead of a spinlock and allow the sleeping calls inside
> atmel_tcb_pwm_config().
>
> Fixes: 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards")
> Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
The issue is real. I first thought the lock isn't needed at all and can
better be dropped, but the chip lock doesn't cover .request().
It would be great if you could rework the patch to keep the spinlock and
instead make use of clk_rate_exclusive_get() at probe time and then
store the rate in struct atmel_tcb_pwm_chip.
Or alternatively drop the lock and call guard(pwmchip)(chip) in
.request(). (This however would require to move the GUARD definition to
a header.)
Without the mutex we could then do:
diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
index f9ff78ba122d..70856be12517 100644
--- a/drivers/pwm/pwm-atmel-tcb.c
+++ b/drivers/pwm/pwm-atmel-tcb.c
@@ -431,6 +431,7 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
}
chip->ops = &atmel_tcb_pwm_ops;
+ chip->atomic = true;
tcbpwmc->channel = channel;
tcbpwmc->width = config->counter_width;
which is nice for some usages.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* [soc:for-next] BUILD SUCCESS a578ece7a274f9c4d69eda571a16d9fc47501cd0
From: kernel test robot @ 2026-04-15 15:11 UTC (permalink / raw)
To: Krzysztof Kozlowski; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: a578ece7a274f9c4d69eda571a16d9fc47501cd0 soc: document merges
elapsed time: 1188m
configs tested: 179
configs skipped: 5
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260415 gcc-13.4.0
arc randconfig-002-20260415 gcc-15.2.0
arc vdk_hs38_smp_defconfig gcc-15.2.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260415 clang-23
arm randconfig-002-20260415 clang-23
arm randconfig-003-20260415 gcc-8.5.0
arm randconfig-004-20260415 clang-17
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260415 gcc-15.2.0
arm64 randconfig-002-20260415 gcc-14.3.0
arm64 randconfig-003-20260415 gcc-13.4.0
arm64 randconfig-004-20260415 clang-19
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260415 gcc-9.5.0
csky randconfig-002-20260415 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig clang-23
hexagon randconfig-001-20260415 clang-18
hexagon randconfig-001-20260415 clang-23
hexagon randconfig-002-20260415 clang-18
hexagon randconfig-002-20260415 clang-23
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 buildonly-randconfig-001-20260415 clang-20
i386 buildonly-randconfig-002-20260415 gcc-14
i386 buildonly-randconfig-004-20260415 gcc-14
i386 buildonly-randconfig-005-20260415 gcc-14
i386 defconfig clang-20
i386 randconfig-001-20260415 gcc-14
i386 randconfig-002-20260415 clang-20
i386 randconfig-003-20260415 gcc-13
i386 randconfig-004-20260415 clang-20
i386 randconfig-005-20260415 clang-20
i386 randconfig-011-20260415 gcc-14
i386 randconfig-012-20260415 clang-20
i386 randconfig-013-20260415 gcc-14
i386 randconfig-014-20260415 gcc-14
i386 randconfig-015-20260415 clang-20
i386 randconfig-016-20260415 gcc-14
i386 randconfig-017-20260415 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260415 clang-18
loongarch randconfig-002-20260415 clang-18
loongarch randconfig-002-20260415 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260415 clang-18
nios2 randconfig-001-20260415 gcc-10.5.0
nios2 randconfig-002-20260415 clang-18
nios2 randconfig-002-20260415 gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260415 gcc-9.5.0
parisc randconfig-002-20260415 gcc-9.5.0
parisc64 defconfig gcc-15.2.0
powerpc akebono_defconfig clang-23
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260415 gcc-9.5.0
powerpc randconfig-002-20260415 gcc-9.5.0
powerpc64 randconfig-001-20260415 gcc-9.5.0
powerpc64 randconfig-002-20260415 gcc-9.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260415 clang-23
riscv randconfig-001-20260415 gcc-9.5.0
riscv randconfig-002-20260415 clang-23
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260415 clang-23
s390 randconfig-001-20260415 gcc-15.2.0
s390 randconfig-002-20260415 clang-23
s390 randconfig-002-20260415 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh defconfig gcc-15.2.0
sh randconfig-001-20260415 clang-23
sh randconfig-001-20260415 gcc-13.4.0
sh randconfig-002-20260415 clang-23
sh randconfig-002-20260415 gcc-11.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260415 gcc-8.5.0
sparc randconfig-002-20260415 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260415 clang-23
sparc64 randconfig-002-20260415 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig clang-23
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260415 clang-23
um randconfig-002-20260415 clang-23
um x86_64_defconfig clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260415 clang-20
x86_64 buildonly-randconfig-002-20260415 clang-20
x86_64 buildonly-randconfig-002-20260415 gcc-13
x86_64 buildonly-randconfig-003-20260415 clang-20
x86_64 buildonly-randconfig-003-20260415 gcc-14
x86_64 buildonly-randconfig-004-20260415 clang-20
x86_64 buildonly-randconfig-005-20260415 clang-20
x86_64 buildonly-randconfig-006-20260415 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-071-20260415 clang-20
x86_64 randconfig-072-20260415 clang-20
x86_64 randconfig-073-20260415 gcc-13
x86_64 randconfig-074-20260415 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa randconfig-001-20260415 gcc-8.5.0
xtensa randconfig-002-20260415 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Conor Dooley @ 2026-04-15 15:10 UTC (permalink / raw)
To: jian.hu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260415-clkmsr_a1_t7-v2-1-02b6314427e6@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
On Wed, Apr 15, 2026 at 04:33:41PM +0800, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
In the future, please note why fallback compatibles are not suitable in
patches like this.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> .../devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> index 39d4637c2d08..b1200e6940ac 100644
> --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> @@ -24,6 +24,8 @@ properties:
> - amlogic,meson-sm1-clk-measure
> - amlogic,c3-clk-measure
> - amlogic,s4-clk-measure
> + - amlogic,a1-clk-measure
> + - amlogic,t7-clk-measure
>
> reg:
> maxItems: 1
>
> --
> 2.47.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable
From: Daniel Golle @ 2026-04-15 15:04 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, Junzhi Zhao,
Jie Qiu, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel
In-Reply-To: <a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org>
Notify hdmi-codec of the current sink plugged state from
mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
via mtk_hdmi_update_plugged_status(). This matches the pattern used
by dw-hdmi, which invokes handle_plugged_change() from the bridge
enable and disable paths so that ASoC jack state stays in sync with
the actual sink presence across atomic commit cycles, and not only
on CEC HPD transitions.
Userspace audio daemons (e.g. pipewire) rely on the jack state to
route streams, restore per-sink volume levels, and recover the last
used device after a reconnect. Without this, those transitions are
missed whenever the sink change is driven by a mode set rather than
by a bare HPD event.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 9050d7785f109..565bb72c9b63a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1013,6 +1013,8 @@ static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
hdmi->curr_conn = NULL;
hdmi->enabled = false;
+
+ mtk_hdmi_update_plugged_status(hdmi);
}
static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
@@ -1082,6 +1084,8 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
mtk_hdmi_clk_enable_audio(hdmi);
hdmi->enabled = true;
+
+ mtk_hdmi_update_plugged_status(hdmi);
}
static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable
From: Daniel Golle @ 2026-04-15 15:04 UTC (permalink / raw)
To: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, Junzhi Zhao,
Jie Qiu, dri-devel, linux-mediatek, linux-kernel,
linux-arm-kernel
The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed the
HDMI TX internal audio measurement block which derives CTS values
for the ACR packets embedded in the TMDS stream. These clocks are
enabled once at driver probe time and then left untouched across
bridge atomic_enable / atomic_disable cycles.
On every observed stale-state event -- a blank/unblank cycle, or
a cold boot with the monitor off followed by a later hotplug --
the measurement block remains armed against the previous state
and fails to latch a valid CTS on the subsequent bridge enable.
Video recovers cleanly but the audio data islands never regain
lock and the HDMI sink sees no audio, even though the ASoC stack,
the AFE, and the HDMI TX audio packetizer are all programmed
correctly.
Debugging the issue of audio no longer working after vblank it was
found that an unbind+bind of the mediatek-drm-hdmi platform driver
recovers audio in all such scenarios without disturbing video.
The only audio-relevant side effect of that rebind is an off->on edge
on CLK_MM_HDMI_AUDIO / CLK_MM_HDMI_SPDIF via the probe path. Pulsing
those two clocks directly at the end of mtk_hdmi_bridge_atomic_enable
reproduces that recovery on every enable and doesn't hurt on the
first enable after boot.
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1ea2598547800..9050d7785f109 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1065,6 +1065,22 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
phy_power_on(hdmi->phy);
mtk_hdmi_send_infoframe(hdmi, &hdmi->mode);
+ /*
+ * Pulse the HDMI TX audio clocks off/on on every bridge enable.
+ * The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed
+ * the HDMI TX internal audio measurement block that derives CTS
+ * for the ACR packets embedded in the TMDS stream. Without an
+ * off->on edge at bridge enable the block can stay armed against
+ * stale state from a previous enable (e.g. after blank/unblank,
+ * or after a monitor that was off at boot is plugged in later)
+ * and fails to latch a valid CTS, leaving the audio path silent
+ * even though video recovers. The pulse is what an unbind+bind
+ * of the HDMI platform driver effectively does, and it recovers
+ * audio in all observed stale-state scenarios.
+ */
+ mtk_hdmi_clk_disable_audio(hdmi);
+ mtk_hdmi_clk_enable_audio(hdmi);
+
hdmi->enabled = true;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/1] ASoC: pxa2xx-ac97: Use devm_gpiod_get_optional()
From: Andy Shevchenko @ 2026-04-15 15:03 UTC (permalink / raw)
To: Peng Fan, linux-arm-kernel, linux-sound, linux-kernel
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Jaroslav Kysela,
Takashi Iwai, Andy Shevchenko
No need to open code the devm_gpiod_get_optional() wrapper.
Instead of checking for a certain error code, check for NULL.
This improves readability of the code.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
v3: rebased on top of the latest changes to the driver
v2: added tag (Peng), rebased on top of latest ASoC tree
sound/arm/pxa2xx-ac97-lib.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c
index 79eb557d4942..47889f6003c1 100644
--- a/sound/arm/pxa2xx-ac97-lib.c
+++ b/sound/arm/pxa2xx-ac97-lib.c
@@ -330,16 +330,12 @@ int pxa2xx_ac97_hw_probe(struct platform_device *dev)
if (dev->dev.of_node) {
/* Assert reset using GPIOD_OUT_HIGH, because reset is GPIO_ACTIVE_LOW */
- rst_gpio = devm_gpiod_get(&dev->dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(rst_gpio)) {
- ret = PTR_ERR(rst_gpio);
- if (ret == -ENOENT)
- reset_gpio = -1;
- else if (ret)
- return ret;
- } else {
- reset_gpio = desc_to_gpio(rst_gpio);
- }
+ rst_gpio = devm_gpiod_get_optional(&dev->dev, "reset", GPIOD_OUT_HIGH);
+ ret = PTR_ERR(rst_gpio);
+ if (ret)
+ return ret;
+
+ reset_gpio = rst_gpio ? desc_to_gpio(rst_gpio) : -1;
} else {
if (cpu_is_pxa27x())
reset_gpio = 113;
--
2.50.1
^ permalink raw reply related
* [PATCH v3 2/2] mmc: dw_mmc: exynos: increase DMA threshold value for exynos7870
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In-Reply-To: <20260415-dwmmc-dma-thr-v3-0-31014d36b6ee@disroot.org>
Exynos 7870 compatible controllers, such as SDIO ones are not able to
perform DMA transfers for small sizes of data (~16 to ~512 bytes),
resulting in cache issues in subsequent transfers. Increase the DMA
transfer threshold to 512 to allow the shorter transfers to take place,
bypassing DMA.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mmc/host/dw_mmc-exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 261344d3a8cfe..4b76b997ddc15 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -141,6 +141,7 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
priv->ctrl_type == DW_MCI_TYPE_EXYNOS7870_SMU) {
/* Quirk needed for certain Exynos SoCs */
host->quirks |= DW_MMC_QUIRK_FIFO64_32;
+ host->dma_threshold = 512;
}
if (priv->ctrl_type == DW_MCI_TYPE_ARTPEC8) {
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] Configuring DMA threshold value for DW-MMC controllers
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In Samsung Exynos 7870 devices with Broadcom Wi-Fi, it has been observed
that small sized DMA transfers are unreliable and are not written
properly, which renders the cache incoherent.
Experimental observations say that DMA transfer sizes of somewhere
around 64 to 512 are intolerable. We must thus implement a mechanism to
fall back to PIO transfer in this case. One such approach, which this
series implements is allowing the DMA transfer threshold, which is
already defined in the driver, to be configurable.
Note that this patch is likely to be labelled as a workaround. These
smaller transfers seem to be successful from downstream kernels,
however efforts to figure out how so went in vain. It is also very
possible that the downstream Broadcom Wi-Fi SDIO driver uses PIO
transfers as well.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
Changes in v3:
- Move host->dma_threshold default to dw_mci_alloc_host() (Shawn Lin)
- Move comment to document struct dw_mci::dma_threshold (Shawn Lin)
- Link to v2: https://lore.kernel.org/r/20260414-dwmmc-dma-thr-v2-0-4058078f5361@disroot.org
Changes in v2:
- Remove dt-binding to set DMA threshold (Krzysztof Kozlowski)
- Add comment to describe struct dw_mci::dma_threshold (Shawn Lin)
- Set DMA threshold in Exynos 7870 DW-MMC driver (Krzysztof Kozlowski)
- Link to v1: https://lore.kernel.org/r/20260412-dwmmc-dma-thr-v1-0-75a2f658eee3@disroot.org
---
Kaustabh Chakraborty (2):
mmc: dw_mmc: implement option for configuring DMA threshold
mmc: dw_mmc: exynos: increase DMA threshold value for exynos7870
drivers/mmc/host/dw_mmc-exynos.c | 1 +
drivers/mmc/host/dw_mmc.c | 4 ++--
drivers/mmc/host/dw_mmc.h | 2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
---
base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
change-id: 20260412-dwmmc-dma-thr-1090d8285ea7
Best regards,
--
Kaustabh Chakraborty <kauschluss@disroot.org>
^ permalink raw reply
* [PATCH v3 1/2] mmc: dw_mmc: implement option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In-Reply-To: <20260415-dwmmc-dma-thr-v3-0-31014d36b6ee@disroot.org>
Some controllers, such as certain Exynos SDIO ones, are unable to
perform DMA transfers of small amount of bytes properly. Following the
device tree schema, implement the property to define the DMA transfer
threshold (from a hard coded value of 16 bytes) so that lesser number of
bytes can be transferred safely skipping DMA in such controllers. The
value of 16 bytes stays as the default for controllers which do not
define it. This value can be overridden by implementation-specific init
sequences.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mmc/host/dw_mmc.c | 4 ++--
drivers/mmc/host/dw_mmc.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 20193ee7b73eb..3b4157f34d11f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -40,7 +40,6 @@
SDMMC_INT_RESP_ERR | SDMMC_INT_HLE)
#define DW_MCI_ERROR_FLAGS (DW_MCI_DATA_ERROR_FLAGS | \
DW_MCI_CMD_ERROR_FLAGS)
-#define DW_MCI_DMA_THRESHOLD 16
#define DW_MCI_FREQ_MAX 200000000 /* unit: HZ */
#define DW_MCI_FREQ_MIN 100000 /* unit: HZ */
@@ -821,7 +820,7 @@ static int dw_mci_pre_dma_transfer(struct dw_mci *host,
* non-word-aligned buffers or lengths. Also, we don't bother
* with all the DMA setup overhead for short transfers.
*/
- if (data->blocks * data->blksz < DW_MCI_DMA_THRESHOLD)
+ if (data->blocks * data->blksz < host->dma_threshold)
return -EINVAL;
if (data->blksz & 3)
@@ -3185,6 +3184,7 @@ struct dw_mci *dw_mci_alloc_host(struct device *dev)
host = mmc_priv(mmc);
host->mmc = mmc;
host->dev = dev;
+ host->dma_threshold = 16;
return host;
}
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 42e58be74ce09..f29d40158dc59 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -107,6 +107,7 @@ struct dw_mci_dma_slave {
* @ciu_clk: Pointer to card interface unit clock instance.
* @fifo_depth: depth of FIFO.
* @data_addr_override: override fifo reg offset with this value.
+ * @dma_threshold: data threshold value in bytes to carry out a DMA transfer.
* @wm_aligned: force fifo watermark equal with data length in PIO mode.
* Set as true if alignment is needed.
* @data_shift: log2 of FIFO item size.
@@ -163,6 +164,7 @@ struct dw_mci {
void __iomem *regs;
void __iomem *fifo_reg;
u32 data_addr_override;
+ u32 dma_threshold;
bool wm_aligned;
struct scatterlist *sg;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: gpio: zynq: Sort compatible strings alphabetically
From: Conor Dooley @ 2026-04-15 15:01 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-2-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
On Wed, Apr 15, 2026 at 04:26:26PM +0530, Shubhrajyoti Datta wrote:
> Sort the compatible string alphabetically.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
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
* Re: [PATCH v2 2/3] dt-bindings: gpio: Add EIO GPIO compatible to gpio-zynq
From: Conor Dooley @ 2026-04-15 15:01 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-3-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
On Wed, Apr 15, 2026 at 04:26:27PM +0530, Shubhrajyoti Datta wrote:
> EIO (Extended IO) is a GPIO block found on xa2ve3288 silicon..
Why does the compatible have a "1.0" when it is in silicon?
Why doesn't the compatible contain "xa2ve3288"?
Why is this device not compatible with existing ones, since
gpio-lines-names appears to be the sole difference?
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> ---
>
> Changes in v2:
> - Add description of EIO block in the dt-bindings patch
>
> .../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> index 30a7f836c341..1ca067217509 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> @@ -12,6 +12,7 @@ maintainers:
> properties:
> compatible:
> enum:
> + - xlnx,eio-gpio-1.0
> - xlnx,pmc-gpio-1.0
> - xlnx,versal-gpio-1.0
> - xlnx,zynq-gpio-1.0
> @@ -30,7 +31,7 @@ properties:
>
> gpio-line-names:
> description: strings describing the names of each gpio line
> - minItems: 58
> + minItems: 52
> maxItems: 174
>
> interrupt-controller: true
> @@ -89,6 +90,17 @@ allOf:
> minItems: 116
> maxItems: 116
>
> + - if:
> + properties:
> + compatible:
> + enum:
> + - xlnx,eio-gpio-1.0
> + then:
> + properties:
> + gpio-line-names:
> + minItems: 52
> + maxItems: 52
> +
> required:
> - compatible
> - reg
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 00/11] Add support for AUDIN driver in Amlogic GXBB
From: Jerome Brunet @ 2026-04-15 14:49 UTC (permalink / raw)
To: Valerio Setti
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <20260411-audin-rfc-v2-0-4c8a6ec5fcab@baylibre.com>
On sam. 11 avril 2026 at 16:57, Valerio Setti <vsetti@baylibre.com> wrote:
> This series adds support for I2S audio input (AUDIN) on the Amlogic GXBB
> platform.
>
> It has been largely reshaped compared to what proposed in v1. Instead of
> adding an HACK commit to allow AIU to export its clock so that also
> AUDIN can control it, now the design closely follows what was implemented
> in the Meson AXG platform. "aiu-encoder-i2s" becomes the shared interface
> for playback/capture and it controls pins and clocks; data formatting
> is implemented in formatters which are named "aiu-formatter-i2s" and
> "audin-decoder-i2s" [1].
> Formatters are DAPM widgets which are dynamically attached/detached to
> the streams when the latters starts/stop, respectively.
>
> As of now only I2S input is supported, because it's the only one
> I could physically test in my setup, but other input sources (ex: SPDIF)
> are also allowed according to the SOC's manual and can be added in the
> future.
> This series was tested on an OdroidC2 board (Amlogic S905 SOC) with an
> NXP SGTL5000 codec connected to its I2S input port.
>
> Since this work brings GX platform very close to the AXG one, once this
> series is accepted, follow up work will be done in order to unify
> GX and AXG formatters so as to minimize the number of implementations.
>
> The series a bit long and it includes changes to drivers, dt-bindings and
> device-tree. Of course this only happens because this is an RFC and I
> wanted to give a full overview of what will be the final design. If no
> objection is raised, this patch series will be split into 3: one for
> reshaping AIU and introducing formatters, one to add AUDIN driver and its
> dt-bindings, one for the device-tree changes.
>
> [1]: Different naming for the aiu part is related to the fact that
> "aiu-encoder-i2s" is already used for the interface and the goal
> of this series was to introduce the minimum amount of changes that allow
> I2S capture to work. Renaming can be implemented in the future as follow up
> activity.
Thanks a lot for this awesome work Valerio. I know this was a lot of
effort. With Mark and Krzysztof comments addressed
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
For the next revision, I think you can drop the RFC tag and split the
series.
You have spent a lot of time studying the existing amlogic audio driver
support. If you feel like it, you could add yourself as a reviewer or
maintainer of the Amlogic audio drivers. :)
>
> v1 -> v2:
> - Reshaped design so that GX platforms will use the same design
> pattern of AXG ones. This helped removing the need for an HACK commit.
>
> --
> 2.39.5
>
> ---
> Valerio Setti (11):
> ASoC: meson: gx: add gx-formatter and gx-interface
> ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
> ASoC: meson: aiu: introduce I2S output formatter
> ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
> ASoC: dt-bindings: amlogic: add schema for audin-formatter and audin-toddr
> ASoC: meson: gx: add AUDIN I2S Decoder driver
> ASoC: meson: gx: add AUDIN FIFO driver
> ASoC: meson: aiu: add I2S Capture DAI
> ASoC: meson: gx-card: add support for AUDIN FIFO
> arm64: dts: amlogic: gx: add nodes for AUDIN decoder and FIFO
> arm64: dts: amlogic: odroid-c2: add support for I2S audio input
>
> .../sound/amlogic,meson-gx-audin-decoder-i2s.yaml | 49 +++
> .../sound/amlogic,meson-gx-audin-fifo.yaml | 63 +++
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 32 ++
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 34 ++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 26 ++
> sound/soc/meson/Kconfig | 17 +
> sound/soc/meson/Makefile | 6 +
> sound/soc/meson/aiu-encoder-i2s.c | 219 +++++++----
> sound/soc/meson/aiu-formatter-i2s.c | 106 +++++
> sound/soc/meson/aiu.c | 37 +-
> sound/soc/meson/aiu.h | 4 +
> sound/soc/meson/audin-decoder-i2s.c | 218 +++++++++++
> sound/soc/meson/audin-fifo.c | 432 +++++++++++++++++++++
> sound/soc/meson/gx-card.c | 14 +-
> sound/soc/meson/gx-formatter.c | 304 +++++++++++++++
> sound/soc/meson/gx-formatter.h | 47 +++
> sound/soc/meson/gx-interface.h | 50 +++
> 17 files changed, 1567 insertions(+), 91 deletions(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260410-audin-rfc-243bcbf95e43
>
> Best regards,
--
Jerome
^ permalink raw reply
* Re: Highmem on AXM and K2
From: Stefan Wiehler @ 2026-04-15 14:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <f609436a-dd4a-43ac-9259-384d3695e709@nokia.com>
Hi Arnd,
I would like to inform you that after some internal discussion, we
decided not to continue with my experiments to transition from
VMSPLIT_3G towards VMSPLIT_2G{_OPT} on the K2. The K2 is used in a
legacy product after all, and the more senior colleagues were quite
concerned about making such a major change due to various hacks that
might fall apart along the way.
Therefore, we will go the CIP path by staying with the last SLTS kernel
with full highmem support. Therefore, we would be very glad if this is
the case for at least the next SLTS kernel, supposedly to be released in
2027, as we should then be able (despite barely) to meet our projected
EOL of 2037.
Thank you for your help so far!
Kind regards,
Stefan
^ permalink raw reply
* Re: [PATCH v5] nvme: Skip trace complete_rq on host path error
From: Keith Busch @ 2026-04-15 14:43 UTC (permalink / raw)
To: 전민식
Cc: hch@lst.de, Justin Tee, axboe@kernel.dk, sven@kernel.org,
j@jannau.net, neal@gompa.dev, sagi@grimberg.me,
justin.tee@broadcom.com, nareshgottumukkala83@gmail.com,
paul.ely@broadcom.com, James Smart, kch@nvidia.com,
linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org, 이은수,
칸찬
In-Reply-To: <20260415084107epcms2p71b9c0d252180653ab96a9f5f2121be71@epcms2p7>
On Wed, Apr 15, 2026 at 05:41:07PM +0900, 전민식 wrote:
> Hi Keith, hch
>
> Gentle ping for review on [PATCH v5] nvme: Skip trace complete_rq on
> host path error.
>
> I agree with your propsed approach. Should I send a new version(v6)
> based on that?
Yes, I hadn't seen an updated patch yet so was just waiting for that.
Or was this one on me to submit?
^ permalink raw reply
* Re: [PATCH v3 0/2] media: verisilicon: Simplification and clean up
From: Benjamin Gaignard @ 2026-04-15 14:35 UTC (permalink / raw)
To: nicolas.dufresne, p.zabel, mchehab, Frank.Li, s.hauer, kernel,
festevam, heiko, mcoquelin.stm32, alexandre.torgue, wens,
jernej.skrabec, samuel
Cc: linux-kernel, linux-media, linux-rockchip, imx, linux-arm-kernel,
linux-stm32, linux-sunxi, kernel
In-Reply-To: <20260415140420.282084-1-benjamin.gaignard@collabora.com>
Le 15/04/2026 à 16:04, Benjamin Gaignard a écrit :
> Simplify motion vectors and reference allocation with common helpers.
> Since it requires to move some of codecs specific functions and
> structure in codecs header files add a patch to finish the clean up.
I forgot to mention that this series depends on
https://patchwork.linuxtv.org/project/linux-media/patch/20260415073801.58369-1-benjamin.gaignard@collabora.com/
>
> Benjamin Gaignard (2):
> media: verisilicon: Simplify motion vectors and rfc buffers allocation
> media: verisilicon: Clean up messy include
>
> drivers/media/platform/verisilicon/hantro.h | 31 +-
> .../media/platform/verisilicon/hantro_av1.c | 7 -
> .../media/platform/verisilicon/hantro_av1.h | 100 +++-
> .../platform/verisilicon/hantro_g1_h264_dec.c | 1 +
> .../verisilicon/hantro_g1_mpeg2_dec.c | 2 +-
> .../platform/verisilicon/hantro_g1_vp8_dec.c | 2 +-
> .../media/platform/verisilicon/hantro_g2.c | 36 --
> .../platform/verisilicon/hantro_g2_hevc_dec.c | 26 +-
> .../platform/verisilicon/hantro_g2_vp9_dec.c | 12 +-
> .../media/platform/verisilicon/hantro_h264.c | 2 +-
> .../media/platform/verisilicon/hantro_h264.h | 98 ++++
> .../media/platform/verisilicon/hantro_hevc.c | 37 +-
> .../media/platform/verisilicon/hantro_hevc.h | 82 ++++
> .../media/platform/verisilicon/hantro_hw.h | 446 +-----------------
> .../media/platform/verisilicon/hantro_mpeg2.c | 1 +
> .../media/platform/verisilicon/hantro_mpeg2.h | 27 ++
> .../platform/verisilicon/hantro_postproc.c | 29 +-
> .../media/platform/verisilicon/hantro_v4l2.c | 262 +++++++++-
> .../media/platform/verisilicon/hantro_vp8.c | 1 +
> .../media/platform/verisilicon/hantro_vp8.h | 29 ++
> .../media/platform/verisilicon/hantro_vp9.h | 104 ++++
> .../media/platform/verisilicon/imx8m_vpu_hw.c | 5 +
> .../verisilicon/rockchip_vpu2_hw_h264_dec.c | 2 +-
> .../verisilicon/rockchip_vpu2_hw_mpeg2_dec.c | 2 +-
> .../verisilicon/rockchip_vpu2_hw_vp8_dec.c | 2 +-
> .../verisilicon/rockchip_vpu981_hw_av1_dec.c | 16 +-
> .../platform/verisilicon/rockchip_vpu_hw.c | 3 +
> .../platform/verisilicon/stm32mp25_vpu_hw.c | 2 +
> .../media/platform/verisilicon/sunxi_vpu_hw.c | 1 +
> 29 files changed, 796 insertions(+), 572 deletions(-)
> create mode 100644 drivers/media/platform/verisilicon/hantro_h264.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_hevc.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_mpeg2.h
> create mode 100644 drivers/media/platform/verisilicon/hantro_vp8.h
>
^ permalink raw reply
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-15 14:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <5d645bb0-22cd-4e96-b8b6-15c4bb83d87d@kernel.org>
On Thu Apr 2, 2026 at 7:43 AM BST, Krzysztof Kozlowski wrote:
> On 02/04/2026 04:19, Alexey Klimov wrote:
>> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>>> Hi all,
>>>>
>>>> This patch series introduces support for the APM-to-AP mailbox on the
>>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>>> co-processor using ACPM.
>>>>
>>>> The Exynos850 mailbox operates similarly to the existing gs101
>>>> implementation, but the register offsets and IRQ mask bits differ.
>>>> This series abstracts these differences into platform-specific data
>>>> structures matched via the device tree.
>>>>
>>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>>
>>>> In theory this can be split into two series with correct dependecies:
>>>> device tree node requires clock changes to be merged. The suggestion
>>>> is to let this go through Samsung SoC tree with corresponding acks
>>>> if it is okay.
>>>
>>> I don't understand why this cannot be split into two seris
>>> *practically*. What is exactly the dependency between mailbox and DTS,
>>> that it had to be combined here?
>>
>> Do you suggest to send 3 single patches with proper dependencies
>> description? DT bindings change first, then mailbox change that specifically
>> depends on dt-bindings change and then dts update (which will depend on both)?
>>
>> I thought that mbox driver change depends implicitly on bindings update?
>
> Please don't answer to a question with a question. Actually three
> questions. If you cannot give argument why there is a dependency, feels
> to me like you send something you do not understand.
Sorry. You're right on the first part. Couldn't say anything about last part.
So I saw series where DTS enablement changes are included in the series
after changes in drivers were introduced. I guess it is more preferred
to split out DTS changes (also considering that kernel without these
changes should be able to boot with new DTS and vice versa). I can split
out DTS change(s), yes. There should/must be no dependency. Thanks.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: amlogic: t7: Add UART controllers nodes
From: Ronald Claveau @ 2026-04-15 14:32 UTC (permalink / raw)
To: Xianwei Zhao
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <68577e42-2fdb-4b66-84a4-610acb8b975b@amlogic.com>
Hi Xianwei,
On 4/15/26 1:38 PM, Xianwei Zhao wrote:
> Hi Ronald,
>
> On 2026/4/15 19:16, Ronald Claveau wrote:
>> Add device tree nodes for UART B through F (serial@7a000 to
>> serial@82000), completing the UART controller description for the T7
>> SoC. Each node includes the peripheral clock.
>>
>> While at it, move the uart_a node to its correct position in the
>> bus address order (0x78000) to comply with the DT requirement that
>> nodes be sorted by their reg address. Complete the
>> uart_a node with its peripheral clock (CLKID_SYS_UART_A) and the
>> associated clock-names, matching the vendor default clock assignment,
>> consistent with the other UART nodes.
>>
>> Signed-off-by: Ronald Claveau<linux-kernel-dev@aliel.fr>
>> ---
>> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 61 +++++++++++++++++++
>> ++++++----
>> 1 file changed, 54 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/
>> boot/dts/amlogic/amlogic-t7.dtsi
>> index 531931cc1437c..56b015cfbd6d1 100644
>> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
>> @@ -577,13 +577,6 @@ gpio_intc: interrupt-controller@4080 {
>> <10 11 12 13 14 15 16 17 18
>> 19 20 21>;
>> };
>>
>> - uart_a: serial@78000 {
>> - compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> - reg = <0x0 0x78000 0x0 0x18>;
>> - interrupts = <GIC_SPI 168
>> IRQ_TYPE_EDGE_RISING>;
>> - status = "disabled";
>> - };
>> -
>> gp0: clock-controller@8080 {
>> compatible = "amlogic,t7-gp0-pll";
>> reg = <0x0 0x8080 0x0 0x20>;
>> @@ -713,6 +706,60 @@ pwm_ao_cd: pwm@60000 {
>> status = "disabled";
>> };
>>
>> + uart_a: serial@78000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x78000 0x0 0x18>;
>> + interrupts = <GIC_SPI 168
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_A>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>
> The xtal clock is defined in the board-level DTS file, while it is
> referenced in the DTSI file, which seems a bit unusual.
>
> On other chips, the xtal clock is usually defined directly in the DTSI
> file.
>
Thanks for your feedback.
I have tested with clock removed in the DTS, and it is ok.
I will send the modification in V2.
>> + status = "disabled";
>> + };
>> +
>> + uart_b: serial@7a000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x7a000 0x0 0x18>;
>> + interrupts = <GIC_SPI 169
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_B>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>> + status = "disabled";
>> + };
>> +
>> + uart_c: serial@7c000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x7c000 0x0 0x18>;
>> + interrupts = <GIC_SPI 170
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_C>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>> + status = "disabled";
>> + };
>> +
>> + uart_d: serial@7e000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x7e000 0x0 0x18>;
>> + interrupts = <GIC_SPI 171
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_D>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>> + status = "disabled";
>> + };
>> +
>> + uart_e: serial@80000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x80000 0x0 0x18>;
>> + interrupts = <GIC_SPI 172
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_E>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>> + status = "disabled";
>> + };
>> +
>> + uart_f: serial@82000 {
>> + compatible = "amlogic,t7-uart",
>> "amlogic,meson-s4-uart";
>> + reg = <0x0 0x82000 0x0 0x18>;
>> + interrupts = <GIC_SPI 173
>> IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&xtal>, <&clkc_periphs
>> CLKID_SYS_UART_F>, <&xtal>;
>> + clock-names = "xtal", "pclk", "baud";
>> + status = "disabled";
>> + };
>> +
>> sd_emmc_a: mmc@88000 {
>> compatible = "amlogic,t7-mmc",
>> "amlogic,meson-axg-mmc";
>> reg = <0x0 0x88000 0x0 0x800>;
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH RFC v2 02/11] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
From: Jerome Brunet @ 2026-04-15 14:28 UTC (permalink / raw)
To: Mark Brown
Cc: Valerio Setti, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <58d1df89-7c97-4e2f-af15-93d1f7bce5a7@sirena.org.uk>
On mar. 14 avril 2026 at 17:13, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Apr 11, 2026 at 04:57:27PM +0200, Valerio Setti wrote:
>
>> @@ -200,13 +200,17 @@ static int aiu_encoder_i2s_hw_params(struct snd_pcm_substream *substream,
>
>> - aiu_encoder_i2s_divider_enable(component, true);
>> + ret = gx_stream_set_cont_clocks(ts, iface->fmt);
>> + if (ret)
>> + dev_err(dai->dev, "failed to apply continuous clock setting\n");
>> +
>> + aiu_encoder_i2s_divider_enable(component, 1);
>
> If we're checking the error here we should probably return it as well.
> Including the error code in the log message is also generally helpful.
>
>> @@ -214,16 +218,20 @@ static int aiu_encoder_i2s_hw_params(struct snd_pcm_substream *substream,
>> static int aiu_encoder_i2s_hw_free(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> + struct gx_stream *ts = snd_soc_dai_get_dma_data(dai, substream);
>> struct snd_soc_component *component = dai->component;
>>
>> - aiu_encoder_i2s_divider_enable(component, false);
>> -
>> - return 0;
>> + /* This is the last substream open and that is going to be closed. */
>> + if (snd_soc_dai_active(dai) <= 1)
>> + aiu_encoder_i2s_divider_enable(component, 0);
>> + return gx_stream_set_cont_clocks(ts, 0);
>> }
>
> Note that we only hw_free() if we preprared, but we enable in
> hw_params().
Huh interresting, I had not thought of that. Valerio and I discussed the
clock part a lot for this rework. It is the crux since since the
interface and clock setting lives in the AIU subsys but serves both the
AIU and AUDIN subsys.
Valerio maybe you could keep function above just to set the rate, but
enabling the clocks through a DAPM supply widget ? This is kind of what
the AXG is doing.
what do you think ?
(actually in the AXG the each formatter widget call CCF
clk_prepare_enable() but a supply widget poking the register would do
the same thing)
>
>> @@ -284,6 +295,8 @@ static int aiu_encoder_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
>> if (ret)
>> dev_err(dai->dev, "Failed to set sysclk to %uHz", freq);
>>
>> + aiu->i2s.iface.mclk_rate = freq;
>> +
>> return ret;
>> }
>
> This means we store the new rate even if the set above failed.
--
Jerome
^ 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