* Re: [PATCH v4] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: Rob Herring (Arm) @ 2026-04-15 21:34 UTC (permalink / raw)
To: phucduc.bui
Cc: tglx, linux-input, krzk, dmitry.torokhov, linux-kernel, conor+dt,
conor, devicetree, mingo, krzk+dt, marex
In-Reply-To: <20260403040714.106093-1-phucduc.bui@gmail.com>
On Fri, 03 Apr 2026 11:07:14 +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Document the "wakeup-source" property for the ti,tsc2005 touchscreen
> controllers to allow the device to wake the system from suspend.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>
> changes:
> v4: Drop redundant "type: boolean" for wakeup-source to use the core
> definition from dt-schema (as suggested by Rob Herring).
> v3: Remove blank lines (suggested by Conor).
> v2: Revise the commit content and remove patch1 related to I2C and SPI
> wakeup handling
> .../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 05/11] dt-bindings: media: Add nxp neoisp support
From: Rob Herring (Arm) @ 2026-04-15 21:31 UTC (permalink / raw)
To: Antoine Bouyer
Cc: anthony.mcgivern, linux-media, alexi.birlinger, conor+dt,
ai.luthra, devicetree, julien.vuillaumier, krzk+dt, imx, mchehab,
laurent.pinchart, frank.li, michael.riesch, linux-kernel,
paul.elder, daniel.baluta, jacopo.mondi, peng.fan
In-Reply-To: <20260413160331.2611829-6-antoine.bouyer@nxp.com>
On Mon, 13 Apr 2026 18:03:25 +0200, Antoine Bouyer wrote:
> Add the yaml binding for NXP's Neo Image Signal Processor (ISP).
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> ---
> .../bindings/media/nxp,imx95-neoisp.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/media/nxp,neoisp.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
Documentation/devicetree/bindings/media/nxp,imx95-neoisp.example.dtb: /example-0/isp@4ae00000: failed to match any schema with compatible: ['nxp,neoisp-imx95-b0']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260413160331.2611829-6-antoine.bouyer@nxp.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Rob Herring (Arm) @ 2026-04-15 21:29 UTC (permalink / raw)
To: Biju
Cc: linux-spi, Biju Das, devicetree, Geert Uytterhoeven, Mark Brown,
Magnus Damm, Krzysztof Kozlowski, Prabhakar Mahadev Lad,
linux-kernel, Conor Dooley, linux-renesas-soc, Fabrizio Castro
In-Reply-To: <20260402131020.143123-2-biju.das.jz@bp.renesas.com>
On Thu, 02 Apr 2026 14:10:16 +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
> the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v1->v2:
> * Collected tag
> ---
> .../bindings/spi/renesas,rzv2h-rspi.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: pm660: add thermal monitor
From: Richard Acayan @ 2026-04-15 21:05 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <4311c618-f084-44c5-86e2-7f97661d887b@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 11:15:57AM +0200, Konrad Dybcio wrote:
> On 3/3/26 3:25 AM, Richard Acayan wrote:
> > On Tue, Feb 10, 2026 at 10:59:20AM +0100, Konrad Dybcio wrote:
> >> On 2/10/26 3:18 AM, Richard Acayan wrote:
> >>> The thermal monitor is used to monitor arbitrary ADC-based thermal
> >>> sensors. It is suitable for use in thermal zones. Add support for it in
> >>> PM660.
> >>>
> >>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >>> ---
> >>> arch/arm64/boot/dts/qcom/pm660.dtsi | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> index 156b2ddff0dc..7cedf6980b34 100644
> >>> --- a/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> @@ -197,6 +197,16 @@ channel@85 {
> >>> };
> >>> };
> >>>
> >>> + pm660_adc_tm: adc-tm@3400 {
> >>> + compatible = "qcom,spmi-adc-tm-hc";
> >>> + reg = <0x3400>;
> >>> + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
> >>> + #thermal-sensor-cells = <1>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + status = "disabled";
> >>
> >> Can we enable it by default?
> >
> > This is for the ADC thermal monitor, and not the ADC itself. I don't see
> > the need to allocate channels just so this can be enabled by default,
> > since the thermal monitor's purpose is mostly to send interrupts when
> > the ADC values go above or below a certain threshold.
>
> Sorry, this fell through the cracks
>
> I see your argument, but at the same time, there are channels that are
> always present (e.g. VPH_PWR) and any way to reduce the boilerplate is
> welcome
If you saw my first sentence in the reply, why are we talking about
VPH_PWR? I don't understand if you're asking for the thermal monitor to
handle a voltage sensor here.
^ permalink raw reply
* Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst @ 2026-04-15 20:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <125cad6c-fb58-4498-a967-41778f6f91f6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]
On Sun, 2026-04-12 at 15:22 +0200, Krzysztof Kozlowski wrote:
> On 12/04/2026 15:21, Markus Probst wrote:
> > On Sun, 2026-04-12 at 10:26 +0200, Krzysztof Kozlowski wrote:
> > > On Sat, Apr 11, 2026 at 05:27:35PM +0200, Markus Probst wrote:
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - synology,ds923p-microp
> > > > + - synology,ds918p-microp
> > > > + - synology,ds214play-microp
> > > > + - synology,ds225p-microp
> > > > + - synology,ds425p-microp
> > > > + - synology,ds710p-microp
> > > > + - synology,ds1010p-microp
> > > > + - synology,ds723p-microp
> > > > + - synology,ds1522p-microp
> > > > + - synology,rs422p-microp
> > > > + - synology,ds725p-microp
> > > > + - synology,ds118-microp
> > > > + - synology,ds124-microp
> > > > + - synology,ds223-microp
> > > > + - synology,ds223j-microp
> > > > + - synology,ds1823xsp-microp
> > > > + - synology,rs822p-microp
> > > > + - synology,rs1221p-microp
> > > > + - synology,rs1221rpp-microp
> > > > + - synology,ds925p-microp
> > > > + - synology,ds1525p-microp
> > > > + - synology,ds1825p-microp
> > >
> > > Previous comment is not resolved. For example you stated that ds723p is
> > > compatible with ds725p, so this should be expressed.
> > Using this expression?
> >
> > properties:
> > compatible:
> > oneOf:
> > - enum:
> > - synology,ds923p-microp
> > - synology,ds1522p-microp
> > - enum:
> > - synology,ds918p-microp
> > - synology,ds415p-microp
> > - const: synology,ds214play-microp
> > ...
> > ?
> > If so shall there each be a description?
>
> No, you changed nothing. You need fallbacks, please read example-schema
> or DTS101 slides.
The documentation says to "use fallback compatibles when devices are
the same as or a superset of prior implementations" [1].
Differences are not publicly documented in this device, making it hard
to tell if it is a superset or the same implementation. This would make
no device a fallback, as compatibility is not guaranteed. I could
imagine it would be an ABI breakage if a fallback is no longer
considered compatible with a device later on.
If deciding based on driver compatibility (accepting loss of features
and accounting for future driver features), one device entry would look
like this:
- items:
- const: synology,ds923p-microp
- const: synology,ds1522p-microp
- const: synology,ds925p-microp # no current sensor from here
- const: synology,ds425p-microp
- const: synology,ds1525p-microp
- const: synology,ds918p-microp
- const: synology,ds1823xsp-microp # no fan failure check from here
- const: synology,ds1825p-microp
which isn't maintainable in this size for ~22 entries.
But the example schema
- items:
- enum:
- vendor,soc4-ip
- vendor,soc3-ip
- vendor,soc2-ip
- enum:
- vendor,soc1-ip
also does not have all of the previous devices as fallbacks (assuming
"vendor,soc3-ip" is compatible with "vendor,soc2-ip" and so on).
Only adding devices as fallbacks with the exact same known feature set
would ignore the other devices with less features which would still
work (e.g. "synology,ds925p-microp" would still work on a ds923+, but
the "current sensor" would not be accessible).
So my question is, what makes a device eligible to be a fallback for
another device?
Just using the one device that is compatible with most of the devices
(having the least features) for all of the compatible devices as
fallback like in the example?
I would prefer a generic "synology,microp-x64" entry as fallback only,
which only supports the baseline of features (power led, status led,
shutdown/reboot, power button, fan speed), which all devices I am aware
of support.
But documentation explicitly states "DON’T use wildcards or device-
family names in compatible strings" [1], so I think I am not allowed to
do that.
Thanks
- Markus Probst
[1] https://docs.kernel.org/devicetree/bindings/writing-bindings.html
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v2 06/24] ASoC: dt-bindings: Add RZ/G3E (R9A09G047) sound binding
From: Rob Herring @ 2026-04-15 20:57 UTC (permalink / raw)
To: John Madieu
Cc: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260402090524.9137-7-john.madieu.xa@bp.renesas.com>
On Thu, Apr 02, 2026 at 11:05:05AM +0200, John Madieu wrote:
> The RZ/G3E shares the same audio IP as the R-Car variants but differs
> in several aspects: it supports up to 5 DMA controllers per audio
> channel, requires additional clocks (47 total including per-SSI ADG
> clocks, SCU domain clocks and SSIF supply) and additional reset lines
> (14 total including SCU, ADG and Audio DMAC peri-peri resets).
>
> Add a dedicated devicetree binding for the RZ/G3E sound controller.
> The binding references the common renesas,rsnd-common.yaml schema for
> shared property and subnode definitions.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: New patch
>
> .../sound/renesas,r9a09g047-sound.yaml | 371 ++++++++++++++++++
> 1 file changed, 371 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> new file mode 100644
> index 000000000000..1dfe9bab3382
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,r9a09g047-sound.yaml
> @@ -0,0 +1,371 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,r9a09g047-sound.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas RZ/G3E Sound Controller
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> + - John Madieu <john.madieu.xa@bp.renesas.com>
> +
> +description:
> + The RZ/G3E (R9A09G047) integrates an R-Car compatible sound controller
> + with extended DMA channel support (up to 5 DMACs per direction), additional
> + clock domains, and additional reset lines compared to the R-Car Gen2/Gen3
> + variants.
> +
> +allOf:
> + - $ref: renesas,rsnd-common.yaml#
> +
> +properties:
> + compatible:
> + const: renesas,r9a09g047-sound
> +
> + reg:
> + maxItems: 5
> +
> + reg-names:
> + items:
> + - const: scu
> + - const: adg
> + - const: ssiu
> + - const: ssi
> + - const: audmapp
> +
> + clocks:
> + maxItems: 47
> +
> + clock-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: src.9
> + - const: src.8
> + - const: src.7
> + - const: src.6
> + - const: src.5
> + - const: src.4
> + - const: src.3
> + - const: src.2
> + - const: src.1
> + - const: src.0
> + - const: mix.1
> + - const: mix.0
> + - const: ctu.1
> + - const: ctu.0
> + - const: dvc.0
> + - const: dvc.1
> + - const: clk_a
> + - const: clk_b
> + - const: clk_c
> + - const: clk_i
> + - const: ssif_supply
> + - const: scu
> + - const: scu_x2
> + - const: scu_supply
> + - const: adg.ssi.9
> + - const: adg.ssi.8
> + - const: adg.ssi.7
> + - const: adg.ssi.6
> + - const: adg.ssi.5
> + - const: adg.ssi.4
> + - const: adg.ssi.3
> + - const: adg.ssi.2
> + - const: adg.ssi.1
> + - const: adg.ssi.0
> + - const: audmapp
> + - const: adg
> +
> + resets:
> + maxItems: 14
> +
> + reset-names:
> + items:
> + - const: ssi-all
> + - const: ssi.9
> + - const: ssi.8
> + - const: ssi.7
> + - const: ssi.6
> + - const: ssi.5
> + - const: ssi.4
> + - const: ssi.3
> + - const: ssi.2
> + - const: ssi.1
> + - const: ssi.0
> + - const: scu
> + - const: adg
> + - const: audmapp
> +
> + rcar_sound,dvc:
> + description: DVC subnode.
> + type: object
Move 'additionalProperties' here.
blank line after.
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
blank line
> + properties:
> + dmas:
> + maxItems: 5
blank line
> + dma-names:
> + maxItems: 5
> + allOf:
Don't need 'allOf'
> + - items:
> + enum:
> + - tx
blank line
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas:
> + maxItems: 10
> + dma-names:
> + maxItems: 10
> + allOf:
> + - items:
> + enum:
> + - tx
> + - rx
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
Most of these are already required by the common schema. No need to
duplicate.
> +
> +unevaluatedProperties: false
^ permalink raw reply
* Re: [PATCH v2 05/24] ASoC: dt-bindings: renesas,rsnd: Split into generic and SoC-specific parts
From: Rob Herring @ 2026-04-15 20:51 UTC (permalink / raw)
To: John Madieu
Cc: Geert Uytterhoeven, Kuninori Morimoto, Vinod Koul, Mark Brown,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Frank Li, Liam Girdwood, Magnus Damm,
Thomas Gleixner, Jaroslav Kysela, Takashi Iwai, Philipp Zabel,
Claudiu Beznea, Biju Das, Fabrizio Castro, Lad Prabhakar,
John Madieu, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, dmaengine, linux-sound
In-Reply-To: <20260402090524.9137-6-john.madieu.xa@bp.renesas.com>
On Thu, Apr 02, 2026 at 11:05:04AM +0200, John Madieu wrote:
> The current renesas,rsnd.yaml binding file handles all supported SoCs
> in a single schema, resulting in deeply nested if/else/then constructs
> that become increasingly difficult to maintain. Each new SoC addition
> amplifies this complexity, making reviews harder and diffs noisier than
> they need to be.
>
> Refactor the binding by extracting the common properties shared across
> all SoCs into a dedicated renesas,rsnd-common.yaml schema, and keeping
> only SoC-specific constraints (required nodes, port counts, clock names,
> etc.) in per-SoC or per-family files that $ref the common part.
>
> This prepares the ground for upcoming SoCs such as the RZ/G3E, which
> introduces a different set of audio resources compared to existing
> R-Car Gen variants. With the split in place, adding RZ/G3E support
> becomes a self-contained change that neither bloats a monolithic schema
> nor buries new constraints inside ever-deeper conditional blocks.
>
> No functional change in validation behaviour for existing device trees.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: New patch
>
> .../bindings/sound/renesas,rsnd-common.yaml | 196 +++++++++++
> .../bindings/sound/renesas,rsnd.yaml | 319 +++++-------------
> 2 files changed, 274 insertions(+), 241 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> new file mode 100644
> index 000000000000..ec6bf644d1a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd-common.yaml
> @@ -0,0 +1,196 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/renesas,rsnd-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car/RZ Sound Common Properties
> +
> +maintainers:
> + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> +
> +description:
> + Common property and subnode definitions shared by Renesas R-Car and RZ
> + sound controller bindings.
> +
> +select: false
> +
> +properties:
> + compatible: true
> +
> + reg: true
> +
> + reg-names: true
Drop these as they should be defined in the device specfic schemas.
> +
> + "#sound-dai-cells":
> + description:
> + Must be 0 for a single-DAI system and 1 for a multi-DAI system.
> + enum: [0, 1]
> +
> + "#clock-cells":
> + description:
> + Must be 0 when the system has audio_clkout and 1 when it has
> + audio_clkout0/1/2/3.
> + enum: [0, 1]
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + clock-frequency:
> + description: Audio clock output frequency for audio_clkout0/1/2/3.
> +
> + clkout-lr-asynchronous:
> + description: audio_clkoutn is asynchronous with lr-clock.
> + $ref: /schemas/types.yaml#/definitions/flag
> +
> + power-domains: true
> +
> + resets: true
> +
> + reset-names: true
> +
> + clocks: true
> +
> + clock-names: true
And drop these unless you have some global constraints.
> +
> + port:
> + $ref: audio-graph-port.yaml#/definitions/port-base
> + unevaluatedProperties: false
Blank line
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + $ref: audio-graph-port.yaml#/definitions/endpoint-base
Blank line
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
Blank line
(and similar throughout)
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + unevaluatedProperties: false
Move after $ref.
> +
> + rcar_sound,dvc:
> + description: DVC subnode.
> + type: object
> + patternProperties:
> + "^dvc-[0-1]$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
Move after 'type'.
> +
> + rcar_sound,mix:
> + description: MIX subnode.
> + type: object
> + patternProperties:
> + "^mix-[0-1]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,ctu:
> + description: CTU subnode.
> + type: object
> + patternProperties:
> + "^ctu-[0-7]$":
> + type: object
> + additionalProperties: false
> + additionalProperties: false
> +
> + rcar_sound,src:
> + description: SRC subnode.
> + type: object
> + patternProperties:
> + "^src-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + additionalProperties: false
> +
> + rcar_sound,ssiu:
> + description: SSIU subnode.
> + type: object
> + patternProperties:
> + "^ssiu-[0-9]+$":
> + type: object
> + additionalProperties: false
> + properties:
> + dmas: true
> + dma-names: true
> + required:
> + - dmas
> + - dma-names
> + additionalProperties: false
> +
> + rcar_sound,ssi:
> + description: SSI subnode.
> + type: object
> + patternProperties:
> + "^ssi-[0-9]$":
> + type: object
> + additionalProperties: false
> + properties:
> + interrupts:
> + maxItems: 1
> + dmas: true
> + dma-names: true
> + shared-pin:
> + description: Shared clock pin.
> + $ref: /schemas/types.yaml#/definitions/flag
> + pio-transfer:
> + description: PIO transfer mode.
> + $ref: /schemas/types.yaml#/definitions/flag
> + no-busif:
> + description: BUSIF is not used for the mem-to-SSI via DMA case.
> + $ref: /schemas/types.yaml#/definitions/flag
> + required:
> + - interrupts
> + additionalProperties: false
> +
> +patternProperties:
> + 'rcar_sound,dai(@[0-9a-f]+)?$':
Why does this have a unit-address, but no 'reg' property? That should be
dropped.
> + description: DAI subnode.
> + type: object
> + patternProperties:
> + "^dai([0-9]+)?$":
> + type: object
> + additionalProperties: false
> + properties:
> + playback:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + capture:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + anyOf:
> + - required:
> + - playback
> + - required:
> + - capture
> + additionalProperties: false
> +
> + 'ports(@[0-9a-f]+)?$':
> + $ref: audio-graph-port.yaml#/definitions/port-base
This is 'ports', not 'port', so not the right ref.
> + unevaluatedProperties: false
> + patternProperties:
> + '^port(@[0-9a-f]+)?$':
> + $ref: "#/properties/port"
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +additionalProperties: true
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> index e8a2acb92646..0d989922a5b4 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml
> @@ -9,8 +9,11 @@ title: Renesas R-Car Sound Driver
> maintainers:
> - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> -properties:
> +description:
> + Binding for Renesas R-Car Gen1/Gen2/Gen3/Gen4 and RZ/G1/G2 sound
> + controllers using the standard RSND layout.
>
> +properties:
> compatible:
> oneOf:
> # for Gen1 SoC
> @@ -67,34 +70,6 @@ properties:
> minItems: 1
> maxItems: 5
>
> - "#sound-dai-cells":
> - description: |
> - it must be 0 if your system is using single DAI
> - it must be 1 if your system is using multi DAIs
> - This is used on simple-audio-card
> - enum: [0, 1]
> -
> - "#clock-cells":
> - description: |
> - it must be 0 if your system has audio_clkout
> - it must be 1 if your system has audio_clkout0/1/2/3
> - enum: [0, 1]
> -
> - "#address-cells":
> - const: 1
> -
> - "#size-cells":
> - const: 0
> -
> - clock-frequency:
> - description: for audio_clkout0/1/2/3
> -
> - clkout-lr-asynchronous:
> - description: audio_clkoutn is asynchronizes with lr-clock.
> - $ref: /schemas/types.yaml#/definitions/flag
> -
> - power-domains: true
> -
> resets:
> minItems: 1
> maxItems: 11
> @@ -109,181 +84,45 @@ properties:
> maxItems: 31
>
> clock-names:
> - description: List of necessary clock names.
> - # details are defined below
> -
> - # ports is below
> - port:
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - "^endpoint(@[0-9a-f]+)?":
> - $ref: audio-graph-port.yaml#/definitions/endpoint-base
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - unevaluatedProperties: false
> -
> - rcar_sound,dvc:
> - description: DVC subnode.
> - type: object
> - patternProperties:
> - "^dvc-[0-1]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 1
> - dma-names:
> - const: tx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,mix:
> - description: MIX subnode.
> - type: object
> - patternProperties:
> - "^mix-[0-1]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,ctu:
> - description: CTU subnode.
> - type: object
> - patternProperties:
> - "^ctu-[0-7]$":
> - type: object
> - additionalProperties: false
> - additionalProperties: false
> -
> - rcar_sound,src:
> - description: SRC subnode.
> - type: object
> - patternProperties:
> - "^src-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - additionalProperties: false
> -
> - rcar_sound,ssiu:
> - description: SSIU subnode.
> - type: object
> - patternProperties:
> - "^ssiu-[0-9]+$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - dmas:
> - maxItems: 2
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - required:
> - - dmas
> - - dma-names
> - additionalProperties: false
> -
> - rcar_sound,ssi:
> - description: SSI subnode.
> - type: object
> - patternProperties:
> - "^ssi-[0-9]$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - interrupts:
> - maxItems: 1
> - dmas:
> - minItems: 2
> - maxItems: 4
> - dma-names:
> - allOf:
> - - items:
> - enum:
> - - tx
> - - rx
> - - txu # if no ssiu node
> - - rxu # if no ssiu node
> -
> - shared-pin:
> - description: shared clock pin
> - $ref: /schemas/types.yaml#/definitions/flag
> - pio-transfer:
> - description: PIO transfer mode
> - $ref: /schemas/types.yaml#/definitions/flag
> - no-busif:
> - description: BUSIF is not used when [mem -> SSI] via DMA case
> - $ref: /schemas/types.yaml#/definitions/flag
> - required:
> - - interrupts
> - additionalProperties: false
> + description: List of clock names.
> + minItems: 1
> + maxItems: 31
> +
> + "#sound-dai-cells": true
> +
> + "#clock-cells": true
> +
> + "#address-cells": true
> +
> + "#size-cells": true
> +
> + clock-frequency: true
> +
> + clkout-lr-asynchronous: true
> +
> + power-domains: true
> +
> + port: true
> +
> + rcar_sound,dvc: true
> +
> + rcar_sound,mix: true
> +
> + rcar_sound,ctu: true
> +
> + rcar_sound,src: true
> +
> + rcar_sound,ssiu: true
> +
> + rcar_sound,ssi: true
Use 'unevaluatedProperties' and drop all of these.
>
> patternProperties:
> - # For DAI base
> - 'rcar_sound,dai(@[0-9a-f]+)?$':
> - description: DAI subnode.
> - type: object
> - patternProperties:
> - "^dai([0-9]+)?$":
> - type: object
> - additionalProperties: false
> -
> - properties:
> - playback:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - capture:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
> - anyOf:
> - - required:
> - - playback
> - - required:
> - - capture
> - additionalProperties: false
> -
> - 'ports(@[0-9a-f]+)?$':
> - $ref: audio-graph-port.yaml#/definitions/port-base
> - unevaluatedProperties: false
> - patternProperties:
> - '^port(@[0-9a-f]+)?$':
> - $ref: "#/properties/port"
> -
> -required:
> - - compatible
> - - reg
> - - reg-names
> - - clocks
> - - clock-names
> + 'rcar_sound,dai(@[0-9a-f]+)?$': true
> + 'ports(@[0-9a-f]+)?$': true
>
> allOf:
> - - $ref: dai-common.yaml#
> + - $ref: renesas,rsnd-common.yaml#
>
> - # --------------------
> - # reg/reg-names
> - # --------------------
> - # for Gen1
> - if:
> properties:
> compatible:
> @@ -295,11 +134,10 @@ allOf:
> maxItems: 3
> reg-names:
> items:
> - enum:
> - - sru
> - - ssi
> - - adg
> - # for Gen2/Gen3
> + - const: sru
> + - const: ssi
> + - const: adg
> +
> - if:
> properties:
> compatible:
> @@ -310,16 +148,34 @@ allOf:
> then:
> properties:
> reg:
> - minItems: 5
> + maxItems: 5
> reg-names:
> items:
> - enum:
> - - scu
> - - adg
> - - ssiu
> - - ssi
> - - audmapp
> - # for Gen4
> + - const: scu
> + - const: adg
> + - const: ssiu
> + - const: ssi
> + - const: audmapp
> + resets:
> + maxItems: 11
> + reset-names:
> + items:
> + oneOf:
> + - const: ssi-all
> + - pattern: '^ssi\.[0-9]$'
> + clocks:
> + maxItems: 31
> + clock-names:
> + items:
> + oneOf:
> + - const: ssi-all
> + - pattern: '^ssi\.[0-9]$'
> + - pattern: '^src\.[0-9]$'
> + - pattern: '^mix\.[0-1]$'
> + - pattern: '^ctu\.[0-1]$'
> + - pattern: '^dvc\.[0-1]$'
> + - pattern: '^clk_(a|b|c|i)$'
> +
> - if:
> properties:
> compatible:
> @@ -336,38 +192,19 @@ allOf:
> - ssiu
> - ssi
> - sdmc
> -
> - # --------------------
> - # clock-names
> - # --------------------
> - - if:
> - properties:
> - compatible:
> - contains:
> - const: renesas,rcar_sound-gen4
> - then:
> - properties:
> - clock-names:
> - maxItems: 3
> + resets:
> + maxItems: 2
> + reset-names:
> items:
> - enum:
> - - ssi.0
> - - ssiu.0
> - - clkin
> - else:
> - properties:
> + - const: ssiu.0
> + - const: ssi.0
> + clocks:
> + maxItems: 3
> clock-names:
> - minItems: 1
> - maxItems: 31
> items:
> - oneOf:
> - - const: ssi-all
> - - pattern: '^ssi\.[0-9]$'
> - - pattern: '^src\.[0-9]$'
> - - pattern: '^mix\.[0-1]$'
> - - pattern: '^ctu\.[0-1]$'
> - - pattern: '^dvc\.[0-1]$'
> - - pattern: '^clk_(a|b|c|i)$'
> + - const: ssiu.0
> + - const: ssi.0
> + - const: clkin
>
> unevaluatedProperties: false
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 01/24] dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
From: Rob Herring (Arm) @ 2026-04-15 20:32 UTC (permalink / raw)
To: John Madieu
Cc: Claudiu Beznea, Mark Brown, Jaroslav Kysela, Krzysztof Kozlowski,
Philipp Zabel, Frank Li, Takashi Iwai, Geert Uytterhoeven,
Biju Das, linux-renesas-soc, devicetree, Fabrizio Castro,
Vinod Koul, linux-sound, Stephen Boyd, Conor Dooley,
Thomas Gleixner, Michael Turquette, dmaengine, linux-kernel,
Liam Girdwood, linux-clk, John Madieu, Magnus Damm, Lad Prabhakar,
Kuninori Morimoto
In-Reply-To: <20260402090524.9137-2-john.madieu.xa@bp.renesas.com>
On Thu, 02 Apr 2026 11:05:00 +0200, John Madieu wrote:
> RZ/V2H, RZ/V2N, and RZ/G3E support external audio clock inputs
> (AUDIO_CLKA, AUDIO_CLKB, AUDIO_CLKC) that can be used by the Audio Clock
> Generator (ADG) to derive internal audio clocks. These clocks are optional
> and their frequencies are set by the board.
>
> Update the bindings to allow these optional clocks for all RZ/V2H family
> SoCs.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v2: Remove maxItems as it not needed with items lists.
>
> .../devicetree/bindings/clock/renesas,rzv2h-cpg.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: firmware: qcom,scm: Document SCM on Hawi SoC
From: Rob Herring (Arm) @ 2026-04-15 20:30 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Guru Das Srinagesh, linux-kernel, Konrad Dybcio, linux-arm-msm,
devicetree, Krzysztof Kozlowski, Bjorn Andersson, Robert Marko,
Conor Dooley
In-Reply-To: <20260401123825.589452-1-mukesh.ojha@oss.qualcomm.com>
On Wed, 01 Apr 2026 18:08:25 +0530, Mukesh Ojha wrote:
> Document SCM compatible for the Qualcomm Hawi SoC.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Dawid Glazik @ 2026-04-15 18:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <d74e7aa8-1110-469a-ac7e-3829c2458852@kernel.org>
On 4/9/2026 9:30 AM, Krzysztof Kozlowski wrote:
> On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
>> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>>> Introduce the device-tree bindings for I3C global registers found on
>>> AST2600 SoCs.
>>>
>>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>>> ---
>>> I wasn't sure if I should add newline at the end of the
>>> file or not so I took
>>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>>> as an example.
>>
>> Answer is: you cannot have patch warnings.
>>
>> Documentation/devicetree/bindings/i3c does not have patch warning, does
>> it?
>
> And if you tested this code with standard tools, you would see that...
>
> Best regards,
> Krzysztof
Thank you for the review and feedback. This is my first contribution to
Linux kernel so I'm still learning the process and toolchain. I
apologize for the rookie mistakes. I will address all the issues you've
pointed out and resubmit the series.
Best regards,
Dawid
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-04-15 17:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260415-sensible-kiwi-of-argument-44d6ed@quoll>
On 2026-04-15 09:03 +02:00, Krzysztof Kozlowski wrote:
> On Tue, Apr 14, 2026 at 12:02:54PM +0530, Kaustabh Chakraborty wrote:
>> +description: |
>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> + 8-bit brightness control for each channel, typically used as status
>> + indicators in mobile phones.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: common.yaml#
>
> Rob's comment is still valid:
> 1. How do you address one of three LEDs in non-RGB case?
> 2. Where is multi-color?
Yes, multi-color should have been added here.
>
> And based on this alone without other properties, I say this should be
> part of top-level schema. Separate node is fine, but no need for
> separate binding.
BTW, for loading the sub-device driver via platform (as it won't be a
separate binding) the driver *must* be built-in. Although not related to
bindings, this seems counter-intuitive. I see the same problem with the
PMIC charger.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: st: Fix SAI addresses on stm32mp251
From: Olivier MOYSAN @ 2026-04-15 17:00 UTC (permalink / raw)
To: Marek Vasut, linux-arm-kernel
Cc: Alexandre Torgue, Conor Dooley, Krzysztof Kozlowski,
Maxime Coquelin, Rob Herring, devicetree, linux-kernel,
linux-stm32
In-Reply-To: <20260411130300.19603-1-marex@nabladev.com>
Hi Marek,
On 4/11/26 15:02, Marek Vasut wrote:
> The second field of SAI register addresses should be within 0x3f0 bytes
> from the start of the SAI register addresses, the second field describes
> the ID registers which are at that addrses. Currently, the second field
> does not match RM, fix it.
>
> Fixes: bf26d75a95f1 ("arm64: dts: st: add sai support on stm32mp251")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Olivier Moysan <olivier.moysan@foss.st.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> ---
> arch/arm64/boot/dts/st/stm32mp251.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> index 673fbc5632e69..9c63fdb5a885a 100644
> --- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
> @@ -1202,7 +1202,7 @@ spi5: spi@40280000 {
>
> sai1: sai@40290000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x40290000 0x4>, <0x4029a3f0 0x10>;
> + reg = <0x40290000 0x4>, <0x402903f0 0x10>;
> ranges = <0 0x40290000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1236,7 +1236,7 @@ sai1b: audio-controller@40290024 {
>
> sai2: sai@402a0000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x402a0000 0x4>, <0x402aa3f0 0x10>;
> + reg = <0x402a0000 0x4>, <0x402a03f0 0x10>;
> ranges = <0 0x402a0000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1270,7 +1270,7 @@ sai2b: audio-controller@402a0024 {
>
> sai3: sai@402b0000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x402b0000 0x4>, <0x402ba3f0 0x10>;
> + reg = <0x402b0000 0x4>, <0x402b03f0 0x10>;
> ranges = <0 0x402b0000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -1362,7 +1362,7 @@ usart1: serial@40330000 {
>
> sai4: sai@40340000 {
> compatible = "st,stm32mp25-sai";
> - reg = <0x40340000 0x4>, <0x4034a3f0 0x10>;
> + reg = <0x40340000 0x4>, <0x403403f0 0x10>;
> ranges = <0 0x40340000 0x400>;
> #address-cells = <1>;
> #size-cells = <1>;
Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com>
Thanks for your patch
BRs
Olivier
^ permalink raw reply
* Re: [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Antony Kurniawan Soemardi @ 2026-04-15 15:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <caa589af-f026-4664-8fb9-6b23b0e087f9@oss.qualcomm.com>
On 4/14/2026 3:07 PM, Konrad Dybcio wrote:
> On 4/14/26 10:06 AM, Konrad Dybcio wrote:
>> On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
>>> From: Antony Kurniawan Soemardi <linux@smankusors.com>
>>>
>>> msm8960 uses the same clock descriptor as apq8064 but lacked the
>>
>> This doesn't quite seem to be the case, some fields differ and
>> apq8064 additionally has:
>>
>> QCOM_RPM_PM8821_SMPS1
>> QCOM_RPM_PM8821_SMPS2
>> QCOM_RPM_PM8821_LDO1
>> QCOM_RPM_VDDMIN_GPIO
>
> Ah hmm, the MFD driver seems to provide *all* RPM resources..
What I meant by "clock descriptor" in the commit message was
specifically the subset corresponding to RPM managed clocks. From what I
can tell based on downstream code, msm8960 and apq8064 seem to share the
same set of RPM clocks, even though the overall resource lists differ.
Is that understanding correct?
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH RFC v2 02/11] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
From: Mark Brown @ 2026-04-15 16:26 UTC (permalink / raw)
To: Jerome Brunet
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: <1jy0ios3f9.fsf@starbuckisacylon.baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
On Wed, Apr 15, 2026 at 04:28:58PM +0200, Jerome Brunet wrote:
> 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 ?
FWIW this seems like a sensible plan to me.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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 00/11] Add support for AUDIN driver in Amlogic GXBB
From: Krzysztof Kozlowski @ 2026-04-15 15:53 UTC (permalink / raw)
To: Jerome Brunet, 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: <1jh5pcs2gw.fsf@starbuckisacylon.baylibre.com>
On 15/04/2026 16:49, Jerome Brunet wrote:
> 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
>
My comments are still unanswered. One of the devices looks like
artificially split from some other, because one word register is not a
device.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: iio: gyroscope: add mount-matrix for bmg160
From: Vishwas Rajashekar via B4 Relay @ 2026-04-15 15:43 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
H. Nikolaus Schaller
Cc: linux-iio, devicetree, linux-kernel, luca, Vishwas Rajashekar
From: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
Adds mount-matrix as an optional property to dt-bindings
for the bmg160 gyroscope as the driver reads this optional
property during probe.
Signed-off-by: Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
---
The bmg160 driver reads an optional mount-matrix using
"iio_read_mount_matrix" in "bmg160_core_probe" and stores
this orientation data in "struct bmg160_data". As the "mount-matrix"
property is used by the driver, this change proposes to add it to
the corresponding dt-bindings.
---
Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
index 3c6fe74af0b8..ea8689660adf 100644
--- a/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
+++ b/Documentation/devicetree/bindings/iio/gyroscope/bosch,bmg160.yaml
@@ -22,6 +22,9 @@ properties:
vdd-supply: true
vddio-supply: true
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
spi-max-frequency:
maximum: 10000000
---
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
change-id: 20260414-bmg160-mount-matrix-dt-binding-e76ddde94866
Best regards,
--
Vishwas Rajashekar <vishwas.dev@vrajashkr.com>
^ permalink raw reply related
* [PATCH 9/9] ARM: dts: mediatek: mt7623n-bananapi-bpi-r2: add HDMI audio machine node
From: Daniel Golle @ 2026-04-15 15:24 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>
Instantiate the mediatek,mt2701-hdmi-audio machine on the
BananaPi BPI-R2, binding the AFE HDMI playback path to the
on-chip HDMI transmitter acting as the generic HDMI codec.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts
index a37f3fa223c72..139a76764faa0 100644
--- a/arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mediatek/mt7623n-bananapi-bpi-r2.dts
@@ -132,6 +132,13 @@ memory@80000000 {
device_type = "memory";
reg = <0 0x80000000 0 0x80000000>;
};
+
+ sound-hdmi {
+ compatible = "mediatek,mt7623n-hdmi-audio",
+ "mediatek,mt2701-hdmi-audio";
+ mediatek,platform = <&afe>;
+ mediatek,audio-codec = <&hdmi0>;
+ };
};
&bls {
--
2.53.0
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: mediatek: mt7623: wire HDMI audio path clocks into AFE
From: Daniel Golle @ 2026-04-15 15:24 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>
Mirror the MT2701 change for the MT7623 SoC dtsi: add HADDS2PLL,
audio_hdmi, audio_spdf and audio_apll to the AFE clocks list and
reparent the AUDPLL mux to HADDS2PLL_98M. Required for HDMI audio
on MT7623N boards via the shared mt2701 AFE driver.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
arch/arm/boot/dts/mediatek/mt7623.dtsi | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/mediatek/mt7623.dtsi b/arch/arm/boot/dts/mediatek/mt7623.dtsi
index 71ac2b94c6ba3..4eb028ffee6f5 100644
--- a/arch/arm/boot/dts/mediatek/mt7623.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt7623.dtsi
@@ -665,7 +665,11 @@ afe: audio-controller {
<&audsys CLK_AUD_AFE_CONN>,
<&audsys CLK_AUD_A1SYS>,
<&audsys CLK_AUD_A2SYS>,
- <&audsys CLK_AUD_AFE_MRGIF>;
+ <&audsys CLK_AUD_AFE_MRGIF>,
+ <&topckgen CLK_TOP_HADDS2PLL_294M>,
+ <&audsys CLK_AUD_HDMI>,
+ <&audsys CLK_AUD_SPDF>,
+ <&audsys CLK_AUD_APLL>;
clock-names = "infra_sys_audio_clk",
"top_audio_mux1_sel",
@@ -700,15 +704,22 @@ afe: audio-controller {
"audio_afe_conn_pd",
"audio_a1sys_pd",
"audio_a2sys_pd",
- "audio_mrgif_pd";
+ "audio_mrgif_pd",
+ "hadds2pll_294m",
+ "audio_hdmi_pd",
+ "audio_spdf_pd",
+ "audio_apll_pd";
assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
<&topckgen CLK_TOP_AUD_MUX2_SEL>,
<&topckgen CLK_TOP_AUD_MUX1_DIV>,
- <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+ <&topckgen CLK_TOP_AUD_MUX2_DIV>,
+ <&topckgen CLK_TOP_AUDPLL_MUX_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
- <&topckgen CLK_TOP_AUD2PLL_90M>;
- assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ <&topckgen CLK_TOP_AUD2PLL_90M>,
+ <0>, <0>,
+ <&topckgen CLK_TOP_HADDS2PLL_98M>;
+ assigned-clock-rates = <0>, <0>, <49152000>, <45158400>, <0>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: mediatek: mt2701: wire HDMI audio path clocks into AFE
From: Daniel Golle @ 2026-04-15 15:24 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 the HADDS2 PLL 294 MHz root, the audio_hdmi and audio_spdf
interface gates and the audio_apll gate to the MT2701 AFE node,
and reparent the AUDPLL mux to HADDS2PLL_98M so the HDMI audio
serial clock path has a stable 294.912 MHz source. The clock
names match the updated mediatek,mt2701-audio binding.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
arch/arm/boot/dts/mediatek/mt2701.dtsi | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/mediatek/mt2701.dtsi b/arch/arm/boot/dts/mediatek/mt2701.dtsi
index 128b87229f3d5..80c8c7e6a422a 100644
--- a/arch/arm/boot/dts/mediatek/mt2701.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt2701.dtsi
@@ -464,7 +464,11 @@ afe: audio-controller {
<&audsys CLK_AUD_AFE_CONN>,
<&audsys CLK_AUD_A1SYS>,
<&audsys CLK_AUD_A2SYS>,
- <&audsys CLK_AUD_AFE_MRGIF>;
+ <&audsys CLK_AUD_AFE_MRGIF>,
+ <&topckgen CLK_TOP_HADDS2PLL_294M>,
+ <&audsys CLK_AUD_HDMI>,
+ <&audsys CLK_AUD_SPDF>,
+ <&audsys CLK_AUD_APLL>;
clock-names = "infra_sys_audio_clk",
"top_audio_mux1_sel",
@@ -499,15 +503,22 @@ afe: audio-controller {
"audio_afe_conn_pd",
"audio_a1sys_pd",
"audio_a2sys_pd",
- "audio_mrgif_pd";
+ "audio_mrgif_pd",
+ "hadds2pll_294m",
+ "audio_hdmi_pd",
+ "audio_spdf_pd",
+ "audio_apll_pd";
assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
<&topckgen CLK_TOP_AUD_MUX2_SEL>,
<&topckgen CLK_TOP_AUD_MUX1_DIV>,
- <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+ <&topckgen CLK_TOP_AUD_MUX2_DIV>,
+ <&topckgen CLK_TOP_AUDPLL_MUX_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
- <&topckgen CLK_TOP_AUD2PLL_90M>;
- assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+ <&topckgen CLK_TOP_AUD2PLL_90M>,
+ <0>, <0>,
+ <&topckgen CLK_TOP_HADDS2PLL_98M>;
+ assigned-clock-rates = <0>, <0>, <49152000>, <45158400>, <0>;
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH 6/9] ASoC: mediatek: mt2701: add machine driver for on-chip HDMI codec
From: Daniel Golle @ 2026-04-15 15:24 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 a simple ASoC machine driver that wires the MT2701/MT7623N
AFE HDMI playback path to the on-chip HDMI transmitter exposed
as a generic hdmi-audio-codec "i2s-hifi" DAI.
The driver binds to "mediatek,mt2701-hdmi-audio". MT7623N device
trees carry "mediatek,mt7623n-hdmi-audio" as a board-specific
fallback, matching the dt-binding.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
sound/soc/mediatek/Kconfig | 10 +++
sound/soc/mediatek/mt2701/Makefile | 1 +
sound/soc/mediatek/mt2701/mt2701-hdmi.c | 114 ++++++++++++++++++++++++
3 files changed, 125 insertions(+)
create mode 100644 sound/soc/mediatek/mt2701/mt2701-hdmi.c
diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index 3a1e1fa3fe5cc..fa076e7854adc 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -26,6 +26,16 @@ config SND_SOC_MT2701_CS42448
Select Y if you have such device.
If unsure select "N".
+config SND_SOC_MT2701_HDMI
+ tristate "ASoC Audio driver for MT2701 with on-chip HDMI codec"
+ depends on SND_SOC_MT2701
+ select SND_SOC_HDMI_CODEC
+ help
+ This adds the ASoC machine driver for MediaTek MT2701 and
+ MT7623N boards routing the AFE I2S back-end to the on-chip
+ HDMI transmitter via the generic HDMI codec.
+ If unsure select "N".
+
config SND_SOC_MT2701_WM8960
tristate "ASoc Audio driver for MT2701 with WM8960 codec"
depends on SND_SOC_MT2701 && I2C
diff --git a/sound/soc/mediatek/mt2701/Makefile b/sound/soc/mediatek/mt2701/Makefile
index 507fa26c39452..59623d3d3a038 100644
--- a/sound/soc/mediatek/mt2701/Makefile
+++ b/sound/soc/mediatek/mt2701/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_SND_SOC_MT2701) += snd-soc-mt2701-afe.o
# machine driver
obj-$(CONFIG_SND_SOC_MT2701_CS42448) += mt2701-cs42448.o
+obj-$(CONFIG_SND_SOC_MT2701_HDMI) += mt2701-hdmi.o
obj-$(CONFIG_SND_SOC_MT2701_WM8960) += mt2701-wm8960.o
diff --git a/sound/soc/mediatek/mt2701/mt2701-hdmi.c b/sound/soc/mediatek/mt2701/mt2701-hdmi.c
new file mode 100644
index 0000000000000..a84907879c04e
--- /dev/null
+++ b/sound/soc/mediatek/mt2701/mt2701-hdmi.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * mt2701-hdmi.c -- MT2701 HDMI ALSA SoC machine driver
+ *
+ * Copyright (c) 2026 Daniel Golle <daniel@makrotopia.org>
+ *
+ * Based on mt2701-cs42448.c
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <sound/soc.h>
+
+enum {
+ DAI_LINK_FE_HDMI_OUT,
+ DAI_LINK_BE_HDMI_I2S,
+};
+
+SND_SOC_DAILINK_DEFS(fe_hdmi_out,
+ DAILINK_COMP_ARRAY(COMP_CPU("PCM_HDMI")),
+ DAILINK_COMP_ARRAY(COMP_DUMMY()),
+ DAILINK_COMP_ARRAY(COMP_EMPTY()));
+
+SND_SOC_DAILINK_DEFS(be_hdmi_i2s,
+ DAILINK_COMP_ARRAY(COMP_CPU("HDMI I2S")),
+ DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "i2s-hifi")),
+ DAILINK_COMP_ARRAY(COMP_EMPTY()));
+
+static struct snd_soc_dai_link mt2701_hdmi_dai_links[] = {
+ [DAI_LINK_FE_HDMI_OUT] = {
+ .name = "HDMI Playback",
+ .stream_name = "HDMI Playback",
+ .trigger = { SND_SOC_DPCM_TRIGGER_POST,
+ SND_SOC_DPCM_TRIGGER_POST },
+ .dynamic = 1,
+ .playback_only = 1,
+ SND_SOC_DAILINK_REG(fe_hdmi_out),
+ },
+ [DAI_LINK_BE_HDMI_I2S] = {
+ .name = "HDMI BE",
+ .no_pcm = 1,
+ .playback_only = 1,
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBC_CFC,
+ SND_SOC_DAILINK_REG(be_hdmi_i2s),
+ },
+};
+
+static struct snd_soc_card mt2701_hdmi_soc_card = {
+ .name = "mt2701-hdmi",
+ .owner = THIS_MODULE,
+ .dai_link = mt2701_hdmi_dai_links,
+ .num_links = ARRAY_SIZE(mt2701_hdmi_dai_links),
+};
+
+static int mt2701_hdmi_machine_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &mt2701_hdmi_soc_card;
+ struct device *dev = &pdev->dev;
+ struct device_node *platform_node;
+ struct device_node *codec_node;
+ struct snd_soc_dai_link *dai_link;
+ int ret;
+ int i;
+
+ platform_node = of_parse_phandle(dev->of_node, "mediatek,platform", 0);
+ if (!platform_node)
+ return dev_err_probe(dev, -EINVAL,
+ "Property 'mediatek,platform' missing\n");
+
+ for_each_card_prelinks(card, i, dai_link) {
+ if (dai_link->platforms->name)
+ continue;
+ dai_link->platforms->of_node = platform_node;
+ }
+
+ codec_node = of_parse_phandle(dev->of_node, "mediatek,audio-codec", 0);
+ if (!codec_node) {
+ of_node_put(platform_node);
+ return dev_err_probe(dev, -EINVAL,
+ "Property 'mediatek,audio-codec' missing\n");
+ }
+ mt2701_hdmi_dai_links[DAI_LINK_BE_HDMI_I2S].codecs->of_node = codec_node;
+
+ card->dev = dev;
+
+ ret = devm_snd_soc_register_card(dev, card);
+
+ of_node_put(platform_node);
+ of_node_put(codec_node);
+ return ret;
+}
+
+static const struct of_device_id mt2701_hdmi_machine_dt_match[] = {
+ { .compatible = "mediatek,mt2701-hdmi-audio" },
+ { .compatible = "mediatek,mt7623n-hdmi-audio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mt2701_hdmi_machine_dt_match);
+
+static struct platform_driver mt2701_hdmi_machine = {
+ .driver = {
+ .name = "mt2701-hdmi",
+ .of_match_table = mt2701_hdmi_machine_dt_match,
+ },
+ .probe = mt2701_hdmi_machine_probe,
+};
+module_platform_driver(mt2701_hdmi_machine);
+
+MODULE_DESCRIPTION("MT2701 HDMI ALSA SoC machine driver");
+MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:mt2701-hdmi");
--
2.53.0
^ permalink raw reply related
* [PATCH 5/9] ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
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>
Extend the MT2701/MT7623N AFE driver with the HDMI playback path:
- a new HDMI DMA memif (MT2701_MEMIF_HDMI) mapped to the
AFE_HDMI_OUT_{CON0,BASE,CUR,END} registers;
- a PCM_HDMI front-end DAI (S16_LE only, 44.1k/48k) which feeds
the memif via DPCM;
- an HDMI BE DAI wrapping the AFE_8CH_I2S_OUT_CON engine that
serialises L/R samples towards the on-chip HDMI transmitter.
Sample-rate programming uses the empirically determined
HDMI_BCK_DIV = 45 * 48000 / rate - 1 formula in AUDIO_TOP_CON3,
which covers 44.1 kHz and 48 kHz within the 6-bit divider range.
The AFE_HDMI_CONN0 interconnect is programmed to route memif
output pairs to the serializer inputs with L/R in the right order
for hdmi-audio-codec.
The existing I2S engine helpers (mt2701_mclk_configuration,
mt2701_i2s_path_enable, mt2701_afe_i2s_path_disable) are reused
for the HDMI BE so that MCLK at 128*fs and the ASYS I2S3 FS field
are programmed and cleanly released across open/close cycles.
Only S16_LE and 44.1k/48k are exposed to userspace. Other rates
fall outside the 6-bit BCK divider range, and wider sample
formats require DMA BIT_WIDTH programming that the current memif
setup does not handle. These limits match what the MT8173 AFE
driver exposes for its HDMI path.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 2 +
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 281 +++++++++++++++++-
2 files changed, 282 insertions(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 7b15283d6351e..8b6f3a200048a 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -33,6 +33,7 @@ enum {
MT2701_MEMIF_UL5,
MT2701_MEMIF_DLBT,
MT2701_MEMIF_ULBT,
+ MT2701_MEMIF_HDMI,
MT2701_MEMIF_NUM,
MT2701_IO_I2S = MT2701_MEMIF_NUM,
MT2701_IO_2ND_I2S,
@@ -41,6 +42,7 @@ enum {
MT2701_IO_5TH_I2S,
MT2701_IO_6TH_I2S,
MT2701_IO_MRG,
+ MT2701_IO_HDMI,
};
enum {
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index fcae38135d93f..61b4fb512be35 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -13,6 +13,7 @@
#include <linux/mfd/syscon.h>
#include <linux/of.h>
#include <linux/pm_runtime.h>
+#include <sound/pcm_params.h>
#include "mt2701-afe-common.h"
#include "mt2701-afe-clock-ctrl.h"
@@ -542,6 +543,221 @@ static const struct snd_soc_dai_ops mt2701_btmrg_ops = {
.hw_params = mt2701_btmrg_hw_params,
};
+/*
+ * HDMI BE DAI -- drives the on-SoC 8-channel I2S engine whose output
+ * feeds the HDMI transmitter audio port.
+ *
+ * The HDMI audio hardware path is:
+ * HDMI memif DMA (AFE_HDMI_OUT_*) -> interconnect mux (AFE_HDMI_CONN0)
+ * -> 8-channel I2S engine (AFE_8CH_I2S_OUT_CON) -> HDMI TX audio port
+ *
+ * The I2S3 clock tree provides the bit/master clocks; we set its
+ * mclk_rate to 128*fs (matching HDMI_AUD_MCLK_128FS) and let
+ * mt2701_mclk_configuration program the PLL/divider path.
+ */
+#define MT2701_HDMI_I2S_PATH 3
+
+static int mt2701_afe_hdmi_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt2701_afe_private *afe_priv = afe->platform_priv;
+ int ret;
+
+ if (!afe_priv->hadds2pll_ck || !afe_priv->audio_hdmi_ck) {
+ dev_err(afe->dev, "HDMI audio clocks not available\n");
+ return -ENODEV;
+ }
+
+ ret = clk_prepare_enable(afe_priv->hadds2pll_ck);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(afe_priv->audio_hdmi_ck);
+ if (ret)
+ goto err_hdmi;
+
+ if (afe_priv->audio_spdf_ck) {
+ ret = clk_prepare_enable(afe_priv->audio_spdf_ck);
+ if (ret)
+ goto err_spdf;
+ }
+
+ if (afe_priv->audio_apll_ck) {
+ ret = clk_prepare_enable(afe_priv->audio_apll_ck);
+ if (ret)
+ goto err_apll;
+ }
+
+ ret = mt2701_afe_enable_mclk(afe, MT2701_HDMI_I2S_PATH);
+ if (ret)
+ goto err_mclk;
+
+ return 0;
+
+err_mclk:
+ if (afe_priv->audio_apll_ck)
+ clk_disable_unprepare(afe_priv->audio_apll_ck);
+err_apll:
+ if (afe_priv->audio_spdf_ck)
+ clk_disable_unprepare(afe_priv->audio_spdf_ck);
+err_spdf:
+ clk_disable_unprepare(afe_priv->audio_hdmi_ck);
+err_hdmi:
+ clk_disable_unprepare(afe_priv->hadds2pll_ck);
+ return ret;
+}
+
+static void mt2701_afe_hdmi_shutdown(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt2701_afe_private *afe_priv = afe->platform_priv;
+
+ mt2701_afe_disable_mclk(afe, MT2701_HDMI_I2S_PATH);
+ if (afe_priv->audio_apll_ck)
+ clk_disable_unprepare(afe_priv->audio_apll_ck);
+ if (afe_priv->audio_spdf_ck)
+ clk_disable_unprepare(afe_priv->audio_spdf_ck);
+ clk_disable_unprepare(afe_priv->audio_hdmi_ck);
+ clk_disable_unprepare(afe_priv->hadds2pll_ck);
+}
+
+static int mt2701_afe_hdmi_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt2701_afe_private *afe_priv = afe->platform_priv;
+ unsigned int channels = params_channels(params);
+ unsigned int rate = params_rate(params);
+ unsigned int divp1;
+ unsigned int val;
+ unsigned int i;
+ int ret;
+
+ /*
+ * Compute AUDIO_TOP_CON3.HDMI_BCK_DIV up front. The divider
+ * drives an internal reference for the HDMI transmitter's
+ * audio packet engine; it must scale with the sample rate so
+ * that the packet engine's timing matches the data flowing in
+ * from the AFE memif/I2S3 side. Empirically, with audpll_sel
+ * parented to hadds2pll_98m (98.304 MHz), the correct value at
+ * 48 kHz is div = 44 (i.e. (div+1) = 45), giving 1.0923 MHz.
+ * Scaling inversely with rate: (div + 1) = 45 * 48000 / rate.
+ * Integer rounding introduces small (<1%) errors at 32 kHz;
+ * 44.1 kHz is nearly exact via round-to-nearest. Reject rates
+ * that fall outside the 6-bit divider range before touching
+ * any hardware so no side effects are left behind on error.
+ */
+ divp1 = (45U * 48000U + rate / 2) / rate;
+ if (divp1 == 0 || divp1 > 64)
+ return -EINVAL;
+
+ /*
+ * Park the I2S3 clock tree at 128*fs -- this is the MCLK that
+ * the ASYS I2S3 engine uses to derive its BCK/LRCK. The engine
+ * outputs BCK = 64*fs (stereo, 32-bit word length).
+ */
+ afe_priv->i2s_path[MT2701_HDMI_I2S_PATH].mclk_rate = rate * 128;
+ ret = mt2701_mclk_configuration(afe, MT2701_HDMI_I2S_PATH);
+ if (ret)
+ return ret;
+
+ /* Program and start the ASYS I2S3 engine (FS, I2S mode, enable). */
+ mt2701_i2s_path_enable(afe,
+ &afe_priv->i2s_path[MT2701_HDMI_I2S_PATH],
+ SNDRV_PCM_STREAM_PLAYBACK, rate);
+
+ regmap_update_bits(afe->regmap, AUDIO_TOP_CON3,
+ AUDIO_TOP_CON3_HDMI_BCK_DIV_MASK,
+ AUDIO_TOP_CON3_HDMI_BCK_DIV(divp1 - 1));
+
+ /* Channel count into the HDMI output memif (bits [7:4]). */
+ regmap_update_bits(afe->regmap, AFE_HDMI_OUT_CON0,
+ 0x000000f0, channels << 4);
+
+ /*
+ * Interconnect mux -- map DMA input slots to HDMI output slots.
+ * Each output takes a 3-bit field at shift (i*3). Swap the first
+ * two inputs so that the DMA's interleaved L/R pair lands on the
+ * correct HDMI L/R output slots. Remaining slots are identity.
+ */
+ val = (1 << 0) | (0 << 3); /* O20 <- I21, O21 <- I20 */
+ for (i = 2; i < 8; i++)
+ val |= ((i & 0x7) << (i * 3));
+ regmap_write(afe->regmap, AFE_HDMI_CONN0, val);
+
+ /*
+ * 8-channel I2S framing: standard I2S, 32-bit slots,
+ * LRCK/BCK inverted. The wire protocol is fixed.
+ */
+ regmap_update_bits(afe->regmap, AFE_8CH_I2S_OUT_CON,
+ AFE_8CH_I2S_OUT_CON_WLEN_MASK |
+ AFE_8CH_I2S_OUT_CON_I2S_DELAY |
+ AFE_8CH_I2S_OUT_CON_LRCK_INV |
+ AFE_8CH_I2S_OUT_CON_BCK_INV,
+ AFE_8CH_I2S_OUT_CON_WLEN_32BIT |
+ AFE_8CH_I2S_OUT_CON_I2S_DELAY |
+ AFE_8CH_I2S_OUT_CON_LRCK_INV |
+ AFE_8CH_I2S_OUT_CON_BCK_INV);
+ return 0;
+}
+
+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);
+ /* Enable HDMI output memif. */
+ regmap_update_bits(afe->regmap, AFE_HDMI_OUT_CON0, 0x1, 0x1);
+ /* Enable 8-channel I2S engine. */
+ regmap_update_bits(afe->regmap, AFE_8CH_I2S_OUT_CON,
+ AFE_8CH_I2S_OUT_CON_EN,
+ AFE_8CH_I2S_OUT_CON_EN);
+ return 0;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ regmap_update_bits(afe->regmap, AFE_8CH_I2S_OUT_CON,
+ AFE_8CH_I2S_OUT_CON_EN, 0);
+ regmap_update_bits(afe->regmap, AFE_HDMI_OUT_CON0, 0x1, 0);
+ regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
+ AUDIO_TOP_CON0_PDN_HDMI_CK |
+ AUDIO_TOP_CON0_PDN_SPDIF_CK,
+ AUDIO_TOP_CON0_PDN_HDMI_CK |
+ AUDIO_TOP_CON0_PDN_SPDIF_CK);
+ return 0;
+ }
+ return -EINVAL;
+}
+
+static int mt2701_afe_hdmi_hw_free(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
+ struct mt2701_afe_private *afe_priv = afe->platform_priv;
+
+ mt2701_afe_i2s_path_disable(afe,
+ &afe_priv->i2s_path[MT2701_HDMI_I2S_PATH],
+ SNDRV_PCM_STREAM_PLAYBACK);
+ return 0;
+}
+
+static const struct snd_soc_dai_ops mt2701_afe_hdmi_ops = {
+ .startup = mt2701_afe_hdmi_startup,
+ .shutdown = mt2701_afe_hdmi_shutdown,
+ .hw_params = mt2701_afe_hdmi_hw_params,
+ .hw_free = mt2701_afe_hdmi_hw_free,
+ .trigger = mt2701_afe_hdmi_trigger,
+};
+
static struct snd_soc_dai_driver mt2701_afe_pcm_dais[] = {
/* FE DAIs: memory intefaces to CPU */
{
@@ -628,6 +844,19 @@ static struct snd_soc_dai_driver mt2701_afe_pcm_dais[] = {
},
.ops = &mt2701_single_memif_dai_ops,
},
+ {
+ .name = "PCM_HDMI",
+ .id = MT2701_MEMIF_HDMI,
+ .playback = {
+ .stream_name = "HDMI Multich",
+ .channels_min = 2,
+ .channels_max = 8,
+ .rates = (SNDRV_PCM_RATE_44100 |
+ SNDRV_PCM_RATE_48000),
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ },
+ .ops = &mt2701_single_memif_dai_ops,
+ },
/* BE DAIs */
{
.name = "I2S0",
@@ -748,7 +977,20 @@ static struct snd_soc_dai_driver mt2701_afe_pcm_dais[] = {
},
.ops = &mt2701_btmrg_ops,
.symmetric_rate = 1,
- }
+ },
+ {
+ .name = "HDMI I2S",
+ .id = MT2701_IO_HDMI,
+ .playback = {
+ .stream_name = "HDMI 8CH I2S Playback",
+ .channels_min = 2,
+ .channels_max = 8,
+ .rates = (SNDRV_PCM_RATE_44100 |
+ SNDRV_PCM_RATE_48000),
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ },
+ .ops = &mt2701_afe_hdmi_ops,
+ },
};
static const struct snd_kcontrol_new mt2701_afe_o00_mix[] = {
@@ -927,6 +1169,14 @@ static const struct snd_soc_dapm_route mt2701_afe_pcm_routes[] = {
{"I16I17", "Multich I2S2 Out Switch", "DLM"},
{"I18I19", "Multich I2S3 Out Switch", "DLM"},
+ /*
+ * HDMI FE -> BE direct route. The HDMI memif has its own DMA
+ * path that feeds the 8-channel internal I2S straight into the
+ * HDMI transmitter; no mixer/interconnect selection is exposed
+ * to the user.
+ */
+ {"HDMI 8CH I2S Playback", NULL, "HDMI Multich"},
+
{ "I12", NULL, "I12I13" },
{ "I13", NULL, "I12I13" },
{ "I14", NULL, "I14I15" },
@@ -1207,6 +1457,35 @@ static const struct mtk_base_memif_data memif_data_array[MT2701_MEMIF_NUM] = {
.agent_disable_shift = 16,
.msb_reg = -1,
},
+ {
+ /*
+ * HDMI memif feeds the on-SoC 8-channel internal I2S that
+ * drives the HDMI transmitter audio port. Unlike the
+ * standard memifs, the enable bit, channel count and bit
+ * width all live in AFE_HDMI_OUT_CON0, so mono/fs/hd/agent
+ * fields are left at -1 and programmed from the BE DAI ops
+ * instead.
+ */
+ .name = "HDMI",
+ .id = MT2701_MEMIF_HDMI,
+ .reg_ofs_base = AFE_HDMI_OUT_BASE,
+ .reg_ofs_cur = AFE_HDMI_OUT_CUR,
+ .reg_ofs_end = AFE_HDMI_OUT_END,
+ .fs_reg = -1,
+ .fs_shift = -1,
+ .fs_maskbit = 0,
+ .mono_reg = -1,
+ .mono_shift = -1,
+ .enable_reg = AFE_HDMI_OUT_CON0,
+ .enable_shift = 0,
+ .hd_reg = -1,
+ .hd_shift = -1,
+ .hd_align_reg = -1,
+ .hd_align_mshift = 0,
+ .agent_disable_reg = -1,
+ .agent_disable_shift = 0,
+ .msb_reg = -1,
+ },
};
static const struct mtk_base_irq_data irq_data[MT2701_IRQ_ASYS_END] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 4/9] ASoC: mediatek: mt2701: add optional 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>
The HDMI audio output path on MT2701/MT7623N is rooted in HADDS2PLL
and gated by the audio_hdmi, audio_spdf and audio_apll power gates.
Acquire these four clocks from device tree using devm_clk_get_optional
so that existing platforms which do not wire up HDMI audio keep
probing unchanged. Actual clock enable/prepare is deferred to the
upcoming HDMI DAI startup path.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../mediatek/mt2701/mt2701-afe-clock-ctrl.c | 22 +++++++++++++++++++
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 4 ++++
2 files changed, 26 insertions(+)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index ae620890bb3ac..5a2bcf027b4fb 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -95,6 +95,28 @@ int mt2701_init_clock(struct mtk_base_afe *afe)
afe_priv->mrgif_ck = NULL;
}
+ /*
+ * Optional HDMI audio clocks. Platforms that do not wire up the
+ * HDMI output (e.g. MT2701 devkits using only the I2S BE DAIs)
+ * may omit these; in that case the HDMI BE DAI simply cannot be
+ * enabled, but the rest of the AFE still probes.
+ */
+ afe_priv->hadds2pll_ck = devm_clk_get_optional(afe->dev, "hadds2pll_294m");
+ if (IS_ERR(afe_priv->hadds2pll_ck))
+ return PTR_ERR(afe_priv->hadds2pll_ck);
+
+ afe_priv->audio_hdmi_ck = devm_clk_get_optional(afe->dev, "audio_hdmi_pd");
+ if (IS_ERR(afe_priv->audio_hdmi_ck))
+ return PTR_ERR(afe_priv->audio_hdmi_ck);
+
+ afe_priv->audio_spdf_ck = devm_clk_get_optional(afe->dev, "audio_spdf_pd");
+ if (IS_ERR(afe_priv->audio_spdf_ck))
+ return PTR_ERR(afe_priv->audio_spdf_ck);
+
+ afe_priv->audio_apll_ck = devm_clk_get_optional(afe->dev, "audio_apll_pd");
+ if (IS_ERR(afe_priv->audio_apll_ck))
+ return PTR_ERR(afe_priv->audio_apll_ck);
+
return 0;
}
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 32bef5e2a56d9..7b15283d6351e 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -90,6 +90,10 @@ struct mt2701_afe_private {
struct mt2701_i2s_path *i2s_path;
struct clk *base_ck[MT2701_BASE_CLK_NUM];
struct clk *mrgif_ck;
+ struct clk *hadds2pll_ck;
+ struct clk *audio_hdmi_ck;
+ struct clk *audio_spdf_ck;
+ struct clk *audio_apll_ck;
bool mrg_enable[MTK_STREAM_NUM];
const struct mt2701_soc_variants *soc;
--
2.53.0
^ permalink raw reply related
* [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
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