From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz,
tiwai@suse.com, tony@atomide.com, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] soc: audio-graph-card2: use correct endpoint when getting link parameters
Date: Tue, 14 Jan 2025 11:04:54 +0200 [thread overview]
Message-ID: <98a19395-7056-48d1-ad89-fb057025f46c@gmail.com> (raw)
In-Reply-To: <87y0zdsxme.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san
On 14.01.25 г. 8:44 ч., Kuninori Morimoto wrote:
>
> Hi Ivaylo
>
> Sorry for the late review.
>
And sorry for the noise on my side.
>> We may have multiple links between ports, with each link
>> having different parameters. Currently, no matter the topology,
>> it is always port endpoint 0 that is used when setting parameters.
>>
>> On a complex sound system, like the one found on Motorola droid4,
>> hifi and voice DAIs require differents formats (i2s vs dsp_a)
>> and curently it is impossible to use DT to set that.
>>
>> Implementing the change leads to partially dropping of at least
>> 0dedbde5062d (ASoC: cpcap: Implement set_tdm_slot for voice call
>> support), as core does most of what is needed to configure voice DAI.
>>
>> We (on Maemo Leste ) use the patch (along with few others) to have
>> voice calls working properly on d4 through UCM.
>>
>> The patch is for linux 6.6, I want to know whether the
>> approach would be accepted before sending a proper patch for
>> current master.
>>
>> the original commit message follows:
>>
>> When link parameters are parsed, it is always endpoint@0 that is used and
>> parameters set to other endpoints are ignored.
>>
>> Fix that by using endpoint that is set in DT when parsing link parameters.
>>
>> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
>> ---
> (snip)
>> @@ -684,7 +683,6 @@ int audio_graph2_link_dpcm(struct asoc_simple_priv *priv,
>> {
>> struct device_node *ep = port_to_endpoint(lnk);
>> struct device_node *rep = of_graph_get_remote_endpoint(ep);
>> - struct device_node *rport = of_graph_get_remote_port(ep);
>> struct snd_soc_dai_link *dai_link = simple_priv_to_link(priv, li->link);
>> struct simple_dai_props *dai_props = simple_priv_to_props(priv, li->link);
>> int is_cpu = asoc_graph_is_ports0(lnk);
>> @@ -718,7 +716,7 @@ int audio_graph2_link_dpcm(struct asoc_simple_priv *priv,
>> dai_link->dynamic = 1;
>> dai_link->dpcm_merged_format = 1;
>>
>> - ret = graph_parse_node(priv, GRAPH_DPCM, rport, li, 1);
>> + ret = graph_parse_node(priv, GRAPH_DPCM, rep, li, 1);
>
> Please correct me if I was misunderstanding
> Is the main issue "remote" side endpoint ?
>
> You want to parse "remote" endpoint (= rep) directly, but the function
> requests "port" (= rport), and it will use endpoint0 ( != rep).
> Is this the main issue you want to fix ?
>
Yes, it is the 'remote' side endpoint, currently it is always remote
endpoint0 that is used, because when you get 'port', it is endpoint0 of
that port that core uses.
See:
https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-cpcap-mapphone.dtsi#L91
https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-mapphone-handset.dtsi#L65
and
https://github.com/maemo-leste/droid4-linux/blob/maemo-6.6.y/arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi#L476
as an example DTS that is using multiple endpoints per port and also
https://lkml.org/lkml/2018/3/27/1225
for what audio wiring looks like.
For voice calls the device does not use CPU, but we have C2C link
between modem and cpcap instead. However, we must correctly set DAI
format on cpcap side for for that link to work properly.
General speaking, we might have multiple endpoints connected for a
single port and when getting "link properties" I think we should use
remote endpoint that is linked to local endpoint, not always remote
endpoint0.
If it is still not clear what $subject patch tries to achieve, please
LMK and I'll try to elaborate even more, if possible.
Also, if you think core allows such 'routing' to be implemented without
the $subject functionality, please elaborate. I spent a good amount of
time back then with no luck.
Thanks and regards,
Ivo
next prev parent reply other threads:[~2025-01-14 9:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 7:11 Ivaylo Dimitrov
2025-01-13 5:55 ` Ivaylo Dimitrov
2025-01-13 13:40 ` Mark Brown
2025-01-13 16:24 ` Ivaylo Dimitrov
2025-01-13 17:01 ` Mark Brown
2025-01-13 21:38 ` Ivaylo Dimitrov
2025-01-14 6:44 ` Kuninori Morimoto
2025-01-14 9:04 ` Ivaylo Dimitrov [this message]
2025-01-14 23:49 ` Kuninori Morimoto
2025-01-15 6:10 ` Ivaylo Dimitrov
2025-01-20 16:27 ` [PATCH] ASoC: " Ivaylo Dimitrov
2025-01-20 23:35 ` Kuninori Morimoto
2025-01-21 6:23 ` Ivaylo Dimitrov
2025-01-21 6:48 ` [PATCH v2] " Ivaylo Dimitrov
2025-01-21 12:18 ` Mark Brown
2025-01-21 13:33 ` Ivaylo Dimitrov
2025-01-21 13:41 ` Mark Brown
2025-01-21 23:22 ` Kuninori Morimoto
2025-01-23 11:29 ` Mark Brown
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=98a19395-7056-48d1-ad89-fb057025f46c@gmail.com \
--to=ivo.g.dimitrov.75@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=tony@atomide.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
all inboxes | Powered by JetHome®