devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	bard.liao@intel.com, Conor Dooley <conor+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 5/5] dt-bindings: audio-graph-port: add channel-map-index property
Date: Thu, 26 Oct 2023 16:22:48 -0500	[thread overview]
Message-ID: <20231026212248.GA383937-robh@kernel.org> (raw)
In-Reply-To: <878r7rbg0v.wl-kuninori.morimoto.gx@renesas.com>

On Wed, Oct 25, 2023 at 02:19:13AM +0000, Kuninori Morimoto wrote:
> This patch adds channel-map-index property to enable handling

Don't write commit messages with 'This patch' or 'This commit'. See the 
documentation on writing patches.

> CPU:Codec = N:M connection.

This is not answering Why?

> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  .../devicetree/bindings/sound/audio-graph-port.yaml | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> index 60b5e3fd1115..2a7e0784d591 100644
> --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
> @@ -93,6 +93,19 @@ definitions:
>                minimum: 1
>                maximum: 64
>  
> +      channel-map-index:
> +        description: It indicates CPU/Codec DAIs channel mapping index if number of
> +          CPU(N) / Codec(M) were not same in one dai-link. channel-map-index is not
> +          needed if the numbers were 1:M or N:1 or N==M. Same indexed CPU <-> Codec
> +          will be paired. This is CPUx2 <-> Codecx3 sample.
> +                                   CPUA   { ... .channel-map-index = <0>;   }
> +          [0] CPUA <---> CodecA    CPUB   { ... .channel-map-index = <1 2>; }
> +          [1] CPUB <-+-> CodecB
> +          [2]        \-> CodecC    CodecA { ... .channel-map-index = <0>; }
> +                                   CodecB { ... .channel-map-index = <1>; }
> +                                   CodecC { ... .channel-map-index = <2>; }

We have 2 different meanings for channel-map-index here. We have the 
codecs defining "I am index N" and then the CPUs defining "I'm connected 
to codec N". That's confusing to start with. Made-up indices are 
something we try to avoid in DT. Are the numbers here (0, 1, 2) 
significant? The normal way we link from one node to another is 
phandles. Why not use phandles here:

CPUA   { ... .channel-map-index = <&CodecA>;   }
CPUB   { ... .channel-map-index = <&CodecB &CodecC>; }


However, we also have OF graph to define complex topologies/connections 
AND we're already using it for this binding. So why not here? You can 
always have more than 1 port and/or endpoint. Generally, multiple ports 
are independent/simultaneous data connections and multiple endpoints are 
either 1:N fanout or N:1 muxed connections.

Rob

  reply	other threads:[~2023-10-26 21:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25  2:18 [PATCH v6 0/5] ASoC: makes CPU/Codec channel connection map more generic Kuninori Morimoto
2023-10-25  2:18 ` [PATCH v6 1/5] " Kuninori Morimoto
2023-10-25  5:33   ` Liao, Bard
2023-10-25  2:18 ` [PATCH v6 2/5] ASoC: audio-graph-card2: add CPU:Codec = N:M support Kuninori Morimoto
2023-10-25  2:18 ` [PATCH v6 3/5] ASoC: audio-graph-card2-custom-sample: tidyup comment / numbering Kuninori Morimoto
2023-10-25  2:18 ` [PATCH v6 4/5] ASoC: audio-graph-card2-custom-sample: add CPU/Codec = N:M sample Kuninori Morimoto
2023-10-25  2:19 ` [PATCH v6 5/5] dt-bindings: audio-graph-port: add channel-map-index property Kuninori Morimoto
2023-10-26 21:22   ` Rob Herring [this message]
2023-10-26 23:35     ` Kuninori Morimoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231026212248.GA383937-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).