Re: [PATCH v3 1/5] ASoC: dt-bindings: fsl,imx-asrc: update port binding to support multiple paths
From: Shengjiu Wang
Date: Tue Aug 11 2026 - 03:40:00 EST
On Tue, Aug 11, 2026 at 1:44 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 11/08/2026 04:28, Shengjiu Wang wrote:
> > On Mon, Aug 10, 2026 at 3:14 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>
> >> On Tue, Aug 04, 2026 at 06:02:14PM +0800, shengjiu.wang@xxxxxxxxxxx wrote:
> >>> From: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> >>>
> >>> 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.
> >
> >>
> >>> 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.
> >
> >>
> >>> 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.
> >
> >>
> >> 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.
Ok, I will remove the sentence below in the commit message.
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.
best regards
Shengjiu Wang
>
> Best regards,
> Krzysztof