All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
To: Sameer Pujar <spujar@nvidia.com>,
	broonie@kernel.org, lgirdwood@gmail.com,  robh+dt@kernel.org,
	krzk+dt@kernel.org, perex@perex.cz, tiwai@suse.com,
	 peter.ujfalusi@linux.intel.com,
	pierre-louis.bossart@linux.intel.com
Cc: oder_chiou@realtek.com, devicetree@vger.kernel.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	jonathanh@nvidia.com, thierry.reding@gmail.com,
	linux-tegra@vger.kernel.org
Subject: Re: [RFC PATCH v2 4/6] ASoC: soc-pcm: tweak DPCM BE hw_param() call order
Date: Mon, 28 Mar 2022 08:29:45 -0700	[thread overview]
Message-ID: <51c8d2541ccff2689b9164ab9b671b0b2514e65f.camel@linux.intel.com> (raw)
In-Reply-To: <1648448050-15237-5-git-send-email-spujar@nvidia.com>

On Mon, 2022-03-28 at 11:44 +0530, Sameer Pujar wrote:
> For DPCM links, the order of hw_param() call depends on the sequence
> of
> BE connection to FE. It is possible that one BE link can provide
> clock
> to another BE link. In such cases consumer BE DAI, to get the rate
> set
> by provider BE DAI, can use the standard clock functions only if
> provider
> has already set the appropriate rate during its hw_param() stage.
> 
> Presently the order is fixed and does not depend on the provider and
> consumer relationships. So the clock rates need to be known ahead of
> hw_param() stage.
> 
> This patch tweaks the hw_param() order by connecting the provider BEs
> late to a FE. With this hw_param() calls for provider BEs happen
> first
> and then followed by consumer BEs. The consumers can use the standard
> clk_get_rate() function to get the rate of the clock they depend on.
> 
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
>  TODO:
>   * The FE link is not considered in this. For Tegra it is fine to
>     call hw_params() for FE at the end. But systems, which want to
> apply
>     this tweak for FE as well, have to extend this tweak to FE.
>   * Also only DPCM is considered here. If normal links require such
>     tweak, it needs to be extended.
> 
>  sound/soc/soc-pcm.c | 60
> ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
> index 9a95468..5829514 100644
> --- a/sound/soc/soc-pcm.c
> +++ b/sound/soc/soc-pcm.c
> @@ -1442,6 +1442,29 @@ static int dpcm_prune_paths(struct
> snd_soc_pcm_runtime *fe, int stream,
>  	return prune;
>  }
>  
> +static bool defer_dpcm_be_connect(struct snd_soc_pcm_runtime *rtd)
> +{
> +	struct snd_soc_dai *dai;
> +	int i;
> +
> +	if (!(rtd->dai_link->dai_fmt & SND_SOC_DAIFMT_FORMAT_MASK))
> +		return false;
Is this check necessary?
> +
> +	if ((rtd->dai_link->dai_fmt &
> SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) ==
> +	    SND_SOC_DAIFMT_CBC_CFC) {
> +
> +		for_each_rtd_cpu_dais(rtd, i, dai) {
> +
> +			if (!snd_soc_dai_is_dummy(dai))
> +				return true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
> +#define MAX_CLK_PROVIDER_BE 10
> +
>  static int dpcm_add_paths(struct snd_soc_pcm_runtime *fe, int
> stream,
>  	struct snd_soc_dapm_widget_list **list_)
>  {
> @@ -1449,7 +1472,8 @@ static int dpcm_add_paths(struct
> snd_soc_pcm_runtime *fe, int stream,
>  	struct snd_soc_dapm_widget_list *list = *list_;
>  	struct snd_soc_pcm_runtime *be;
>  	struct snd_soc_dapm_widget *widget;
> -	int i, new = 0, err;
> +	struct snd_soc_pcm_runtime *prov[MAX_CLK_PROVIDER_BE];
> +	int i, new = 0, err, count = 0;
>  
>  	/* Create any new FE <--> BE connections */
>  	for_each_dapm_widgets(list, i, widget) {
> @@ -1489,6 +1513,40 @@ static int dpcm_add_paths(struct
> snd_soc_pcm_runtime *fe, int stream,
>  		    (be->dpcm[stream].state !=
> SND_SOC_DPCM_STATE_CLOSE))
>  			continue;
>  
> +		/* Connect clock provider BEs at the end */
> +		if (defer_dpcm_be_connect(be)) {
> +			if (count >= MAX_CLK_PROVIDER_BE) {
What determines MAX_CLK_PROVIDER_BE? why 10? Can you use rtd->num_cpus
instead? 
Thanks,
Ranjani


  parent reply	other threads:[~2022-03-28 15:30 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-28  6:14 [RFC PATCH v2 0/6] Flexible codec clock configuration Sameer Pujar
2022-03-28  6:14 ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 1/6] ASoC: dt-bindings: Convert rt5659 bindings to YAML schema Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar
2022-03-28  7:02   ` Krzysztof Kozlowski
2022-03-28  7:02     ` Krzysztof Kozlowski
2022-03-28 12:51   ` Rob Herring
2022-03-28 12:51     ` Rob Herring
2022-03-28 13:26     ` Sameer Pujar
2022-03-28 13:26       ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 2/6] ASoC: dt-bindings: Add audio-graph-port bindings to rt5659 Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar
2022-03-28  7:03   ` Krzysztof Kozlowski
2022-03-28  7:03     ` Krzysztof Kozlowski
2022-03-28  7:58     ` Sameer Pujar
2022-03-28  7:58       ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 3/6] ASoC: dt-bindings: Extend clock bindings of rt5659 Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar
2022-03-28  7:06   ` Krzysztof Kozlowski
2022-03-28  7:06     ` Krzysztof Kozlowski
2022-03-28  7:58     ` Sameer Pujar
2022-03-28  7:58       ` Sameer Pujar
2022-03-28  8:07       ` Krzysztof Kozlowski
2022-03-28  8:07         ` Krzysztof Kozlowski
2022-03-28 13:19         ` Sameer Pujar
2022-03-28 13:19           ` Sameer Pujar
2022-03-28 13:28           ` Krzysztof Kozlowski
2022-03-28 13:28             ` Krzysztof Kozlowski
2022-03-29  8:27             ` Sameer Pujar
2022-03-29  8:27               ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 4/6] ASoC: soc-pcm: tweak DPCM BE hw_param() call order Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar
2022-03-28 15:11   ` Amadeusz Sławiński
2022-03-29  8:28     ` Sameer Pujar
2022-03-28 15:29   ` Ranjani Sridharan [this message]
2022-03-29  8:31     ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 5/6] ASoC: rt5659: Expose internal clock relationships Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar
2022-03-28  6:14 ` [RFC PATCH v2 6/6] ASoC: tegra: Get clock rate in consumer mode Sameer Pujar
2022-03-28  6:14   ` Sameer Pujar

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=51c8d2541ccff2689b9164ab9b671b0b2514e65f.camel@linux.intel.com \
    --to=ranjani.sridharan@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=robh+dt@kernel.org \
    --cc=spujar@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.