All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nenghua Cao <nhcao@marvell.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: dpcm: don't do hw_param when BE has done	hw_param
Date: Fri, 10 Jan 2014 19:21:34 +0800	[thread overview]
Message-ID: <52CFD7BE.5030907@marvell.com> (raw)
In-Reply-To: <s5htxdcxg0q.wl%tiwai@suse.de>

On 01/10/2014 06:55 PM, Takashi Iwai wrote:
> [Corrected mail addresses of both Mark and Liam]
> 
Hi, Takashi:
Thanks for correcting my mistake.
> At Fri, 10 Jan 2014 13:36:35 +0800,
> Nenghua Cao wrote:
>>
>> From: Nenghua Cao <nhcao@marvell.com>
>>
>>     It fixes the following case:
>>     Two FEs connects the same BE; FE1 & BE path has been opened and hw_paramed.
>> At this momment, FE2 & BE path is being opened and hw_paramed. The BE
>> dai will do hw_param again even if it has done hw_param. It is not
>> reasonable.
>> FE1------------>BE
>> FE2-------------^
> 
> What happens if FE2 tries to set up an incompatible hw_params?
> (Through a quick glance, it won't work properly well, too, though...)
> 
If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe
FE2 works well.
If FE2 uses the same param, BE hw_param function will be called twice
(This is the most happening case).
So we can't get benefits from it.
> 
> Takashi
> 
>>
>> Signed-off-by: Nenghua Cao <nhcao@marvell.com>
>> ---
>>  sound/soc/soc-pcm.c |    1 -
>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
>> index 891b9a9..ec07e37 100644
>> --- a/sound/soc/soc-pcm.c
>> +++ b/sound/soc/soc-pcm.c
>> @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream)
>>  			continue;
>>  
>>  		if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) &&
>> -		    (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
>>  		    (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE))
>>  			continue;
>>  
>> -- 
>> 1.7.0.4
>>
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>

WARNING: multiple messages have this Message-ID (diff)
From: Nenghua Cao <nhcao@marvell.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: dpcm: don't do hw_param when BE has done	hw_param
Date: Fri, 10 Jan 2014 19:21:34 +0800	[thread overview]
Message-ID: <52CFD7BE.5030907@marvell.com> (raw)
In-Reply-To: <s5htxdcxg0q.wl%tiwai@suse.de>

On 01/10/2014 06:55 PM, Takashi Iwai wrote:
> [Corrected mail addresses of both Mark and Liam]
> 
Hi, Takashi:
Thanks for correcting my mistake.
> At Fri, 10 Jan 2014 13:36:35 +0800,
> Nenghua Cao wrote:
>>
>> From: Nenghua Cao <nhcao@marvell.com>
>>
>>     It fixes the following case:
>>     Two FEs connects the same BE; FE1 & BE path has been opened and hw_paramed.
>> At this momment, FE2 & BE path is being opened and hw_paramed. The BE
>> dai will do hw_param again even if it has done hw_param. It is not
>> reasonable.
>> FE1------------>BE
>> FE2-------------^
> 
> What happens if FE2 tries to set up an incompatible hw_params?
> (Through a quick glance, it won't work properly well, too, though...)
> 
If FE2 uses an incompatible param, it will make FE1 doesn't work. Maybe
FE2 works well.
If FE2 uses the same param, BE hw_param function will be called twice
(This is the most happening case).
So we can't get benefits from it.
> 
> Takashi
> 
>>
>> Signed-off-by: Nenghua Cao <nhcao@marvell.com>
>> ---
>>  sound/soc/soc-pcm.c |    1 -
>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
>> index 891b9a9..ec07e37 100644
>> --- a/sound/soc/soc-pcm.c
>> +++ b/sound/soc/soc-pcm.c
>> @@ -1339,7 +1339,6 @@ static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream)
>>  			continue;
>>  
>>  		if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) &&
>> -		    (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
>>  		    (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE))
>>  			continue;
>>  
>> -- 
>> 1.7.0.4
>>
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>


  reply	other threads:[~2014-01-10 11:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10  5:36 [PATCH] ASoC: dpcm: don't do hw_param when BE has done hw_param Nenghua Cao
2014-01-10  5:36 ` Nenghua Cao
2014-01-10 10:55 ` [alsa-devel] " Takashi Iwai
2014-01-10 10:55   ` Takashi Iwai
2014-01-10 11:21   ` Nenghua Cao [this message]
2014-01-10 11:21     ` Nenghua Cao
2014-01-10 11:47     ` Liam Girdwood
2014-01-10 11:59       ` Nenghua Cao
2014-01-10 12:01         ` Takashi Iwai
2014-01-10 12:22           ` Nenghua Cao
2014-01-10 12:22             ` [alsa-devel] " Nenghua Cao
2014-01-10 13:34             ` Takashi Iwai
2014-01-10 12:29           ` Liam Girdwood
2014-01-10 12:51             ` Nenghua Cao
2014-01-10 12:51               ` [alsa-devel] " Nenghua Cao
2014-01-10 13:46             ` Takashi Iwai
2014-01-10 18:43               ` Liam Girdwood
2014-01-11  9:35                 ` Takashi Iwai
2014-01-11  9:35                   ` [alsa-devel] " Takashi Iwai
2014-01-11 12:08                   ` Mark Brown
2014-01-13 10:48                   ` Liam Girdwood
2014-01-13 10:57                     ` Takashi Iwai

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=52CFD7BE.5030907@marvell.com \
    --to=nhcao@marvell.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    /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.