On Thu, Aug 6, 2026 at 1:06 AM Frank Li [off-list ref] wrote:
On Wed, Aug 05, 2026 at 02:57:59PM +0800, Shengjiu Wang wrote:
quoted
On Tue, Aug 4, 2026 at 10:39 PM Frank Li [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).
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
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.
if no existing upstream DTS file use it, you can direct replace with ports
That is to avoid any downstream use of the 'port', so not directly replace it.
Does downstream strictly run DTB_CHECK ?
I don't know if anyone downstream uses the 'port' or not. so keep it
in this file but
mark it is as deprecated to avoid any impact of this change (add 'ports')
Best regards
Shengjiu Wang