Re: [PATCH v3 1/5] ASoC: dt-bindings: fsl,imx-asrc: update port binding to support multiple paths

On 11/08/2026 04:28, Shengjiu Wang wrote:

On Mon, Aug 10, 2026 at 3:14 PM Krzysztof Kozlowski [off-list ref] wrote:

quoted

On Tue, Aug 04, 2026 at 06:02:14PM +0800, shengjiu.wang@oss.nxp.com wrote:

quoted

From: Shengjiu Wang <redacted>

The i.MX ASRC hardware supports up to three conversion pairs (A, B, C).

Which SoC? Did you read this binding you are changing?

The i.MX35 ASRC (the original) already supports three conversion pairs
(A, B, C).
All subsequent SoCs that reuse this IP -- including i.MX53, i.MX8QM, i.MX8QXP,
i.MX952, share the same three-pair hardware. This binding covers all of them.

quoted

quoted

The existing binding exposed only a single generic audio-graph port,
which cannot represent independent conversion paths when multiple pairs
are in use simultaneously.

Add a ports container that enumerates up to three sub-ports, each
representing an independent conversion path:
  port@0 -- conversion path 0
  port@1 -- conversion path 1
  port@2 -- conversion path 2

Each sub-port references audio-graph-port.yaml as before. Hardware pairs
are allocated dynamically at stream open time; each active stream
direction (playback or capture) on a port consumes one hardware pair.

For backwards compatibility, keep the old single port property but mark

Why? Did the old hardware change that it has more ports/paths?

The hardware has always supported three pairs; the original binding simply
did not expose them all. This patch corrects the binding to match what the
hardware has always been capable of.

quoted

quoted

it deprecated. A schema constraint (not: required: [port, ports]) ensures
that both forms cannot be used at the same time. The binding example is
updated to show the preferred ports form.

No existing upstream DTS file for fsl,imx-asrc uses the previously
documented single 'port' node, so this change does not break any
in-tree device tree.

Does it break other users of this binding?

No. The existing single 'port' property is kept and marked deprecated
so that any out-of-tree device tree still works without modification.
The new 'ports' form is additive only.

quoted

Why mentioning upstream in the first place? Either this change breaks
ABI or not, explain that.

The deprecated 'port' property is retained, so this change is fully backwards
compatible and does not break ABI.

So why? Drop redundant parts.

Best regards,
Krzysztof