linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed
@ 2019-07-09  4:01 Alex Levin
  2019-07-09 11:45 ` Andy Shevchenko
  0 siblings, 1 reply; 4+ messages in thread
From: Alex Levin @ 2019-07-09  4:01 UTC (permalink / raw)
  To: alsa-devel
  Cc: Pierre-Louis Bossart, Liam Girdwood, Jie Yang, Mark Brown,
	Jaroslav Kysela, Takashi Iwai, Andy Shevchenko, Alex Levin,
	linux-kernel, benzh, cujomalainey

sst_platform_pcm_pointer is called from both snd_pcm_period_elapsed and
from snd_pcm_ioctl. Calling read timestamp results in recalculating
pcm_delay and buffer_ptr (sst_calc_tstamp) which consumes buffers in a
faster rate than intended.
In a tested BSW system with chtrt5650, for a rate of 48000, the
measured rate was sometimes 10 times more than that.
After moving the timestamp read to period elapsed, buffer consumption is
as expected.

Signed-off-by: Alex Levin <levinale@chromium.org>
---
 sound/soc/intel/atom/sst-mfld-platform-pcm.c | 23 +++++++++++++-------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index 0e8b1c5eec88..196af0b30b41 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -265,16 +265,28 @@ static void sst_period_elapsed(void *arg)
 {
 	struct snd_pcm_substream *substream = arg;
 	struct sst_runtime_stream *stream;
-	int status;
+	struct snd_soc_pcm_runtime *rtd;
+	int status, ret_val;
 
 	if (!substream || !substream->runtime)
 		return;
 	stream = substream->runtime->private_data;
 	if (!stream)
 		return;
+
+	rtd = substream->private_data;
+	if (!rtd)
+		return;
+
 	status = sst_get_stream_status(stream);
 	if (status != SST_PLATFORM_RUNNING)
 		return;
+
+	ret_val = stream->ops->stream_read_tstamp(sst->dev, &stream->stream_info);
+	if (ret_val) {
+		dev_err(rtd->dev, "stream_read_tstamp err code = %d\n", ret_val);
+		return;
+	}
 	snd_pcm_period_elapsed(substream);
 }
 
@@ -658,20 +670,15 @@ static snd_pcm_uframes_t sst_platform_pcm_pointer
 			(struct snd_pcm_substream *substream)
 {
 	struct sst_runtime_stream *stream;
-	int ret_val, status;
+	int status;
 	struct pcm_stream_info *str_info;
-	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 
 	stream = substream->runtime->private_data;
 	status = sst_get_stream_status(stream);
 	if (status == SST_PLATFORM_INIT)
 		return 0;
+
 	str_info = &stream->stream_info;
-	ret_val = stream->ops->stream_read_tstamp(sst->dev, str_info);
-	if (ret_val) {
-		dev_err(rtd->dev, "sst: error code = %d\n", ret_val);
-		return ret_val;
-	}
 	substream->runtime->delay = str_info->pcm_delay;
 	return str_info->buffer_ptr;
 }
-- 
2.22.0.410.gd8fdbe21b5-goog


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed
  2019-07-09  4:01 [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed Alex Levin
@ 2019-07-09 11:45 ` Andy Shevchenko
  2019-07-10 23:15   ` Curtis Malainey
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Shevchenko @ 2019-07-09 11:45 UTC (permalink / raw)
  To: Alex Levin
  Cc: alsa-devel, Pierre-Louis Bossart, Liam Girdwood, Jie Yang,
	Mark Brown, Jaroslav Kysela, Takashi Iwai, linux-kernel, benzh,
	cujomalainey

On Mon, Jul 08, 2019 at 09:01:47PM -0700, Alex Levin wrote:
> sst_platform_pcm_pointer is called from both snd_pcm_period_elapsed and
> from snd_pcm_ioctl. Calling read timestamp results in recalculating
> pcm_delay and buffer_ptr (sst_calc_tstamp) which consumes buffers in a
> faster rate than intended.
> In a tested BSW system with chtrt5650, for a rate of 48000, the
> measured rate was sometimes 10 times more than that.
> After moving the timestamp read to period elapsed, buffer consumption is
> as expected.

From code prospective it looks good. You may take mine
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Though I'm not an expert in the area, Pierre and / or Liam should give
their blessing.

> 
> Signed-off-by: Alex Levin <levinale@chromium.org>
> ---
>  sound/soc/intel/atom/sst-mfld-platform-pcm.c | 23 +++++++++++++-------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> index 0e8b1c5eec88..196af0b30b41 100644
> --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> @@ -265,16 +265,28 @@ static void sst_period_elapsed(void *arg)
>  {
>  	struct snd_pcm_substream *substream = arg;
>  	struct sst_runtime_stream *stream;
> -	int status;
> +	struct snd_soc_pcm_runtime *rtd;
> +	int status, ret_val;
>  
>  	if (!substream || !substream->runtime)
>  		return;
>  	stream = substream->runtime->private_data;
>  	if (!stream)
>  		return;
> +
> +	rtd = substream->private_data;
> +	if (!rtd)
> +		return;
> +
>  	status = sst_get_stream_status(stream);
>  	if (status != SST_PLATFORM_RUNNING)
>  		return;
> +
> +	ret_val = stream->ops->stream_read_tstamp(sst->dev, &stream->stream_info);
> +	if (ret_val) {
> +		dev_err(rtd->dev, "stream_read_tstamp err code = %d\n", ret_val);
> +		return;
> +	}
>  	snd_pcm_period_elapsed(substream);
>  }
>  
> @@ -658,20 +670,15 @@ static snd_pcm_uframes_t sst_platform_pcm_pointer
>  			(struct snd_pcm_substream *substream)
>  {
>  	struct sst_runtime_stream *stream;
> -	int ret_val, status;
> +	int status;
>  	struct pcm_stream_info *str_info;
> -	struct snd_soc_pcm_runtime *rtd = substream->private_data;
>  
>  	stream = substream->runtime->private_data;
>  	status = sst_get_stream_status(stream);
>  	if (status == SST_PLATFORM_INIT)
>  		return 0;
> +
>  	str_info = &stream->stream_info;
> -	ret_val = stream->ops->stream_read_tstamp(sst->dev, str_info);
> -	if (ret_val) {
> -		dev_err(rtd->dev, "sst: error code = %d\n", ret_val);
> -		return ret_val;
> -	}
>  	substream->runtime->delay = str_info->pcm_delay;
>  	return str_info->buffer_ptr;
>  }
> -- 
> 2.22.0.410.gd8fdbe21b5-goog
> 

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed
  2019-07-09 11:45 ` Andy Shevchenko
@ 2019-07-10 23:15   ` Curtis Malainey
  2019-07-17 15:30     ` [alsa-devel] " Pierre-Louis Bossart
  0 siblings, 1 reply; 4+ messages in thread
From: Curtis Malainey @ 2019-07-10 23:15 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Alex Levin, ALSA development, Pierre-Louis Bossart,
	Liam Girdwood, Jie Yang, Mark Brown, Jaroslav Kysela,
	Takashi Iwai, Linux Kernel Mailing List, Ben Zhang,
	Curtis Malainey

On Tue, Jul 9, 2019 at 4:45 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Jul 08, 2019 at 09:01:47PM -0700, Alex Levin wrote:
> > sst_platform_pcm_pointer is called from both snd_pcm_period_elapsed and
> > from snd_pcm_ioctl. Calling read timestamp results in recalculating
> > pcm_delay and buffer_ptr (sst_calc_tstamp) which consumes buffers in a
> > faster rate than intended.
> > In a tested BSW system with chtrt5650, for a rate of 48000, the
> > measured rate was sometimes 10 times more than that.
> > After moving the timestamp read to period elapsed, buffer consumption is
> > as expected.
>
> From code prospective it looks good. You may take mine
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Though I'm not an expert in the area, Pierre and / or Liam should give
> their blessing.
>
Agreed, Liam or Pierre should also give their ok since this is one of
the closed source firmware drivers.

Reviewed-by: Curtis Malainey <cujomalainey@chromium.org>
> >
> > Signed-off-by: Alex Levin <levinale@chromium.org>
> > ---
> >  sound/soc/intel/atom/sst-mfld-platform-pcm.c | 23 +++++++++++++-------
> >  1 file changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> > index 0e8b1c5eec88..196af0b30b41 100644
> > --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> > +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
> > @@ -265,16 +265,28 @@ static void sst_period_elapsed(void *arg)
> >  {
> >       struct snd_pcm_substream *substream = arg;
> >       struct sst_runtime_stream *stream;
> > -     int status;
> > +     struct snd_soc_pcm_runtime *rtd;
> > +     int status, ret_val;
> >
> >       if (!substream || !substream->runtime)
> >               return;
> >       stream = substream->runtime->private_data;
> >       if (!stream)
> >               return;
> > +
> > +     rtd = substream->private_data;
> > +     if (!rtd)
> > +             return;
> > +
> >       status = sst_get_stream_status(stream);
> >       if (status != SST_PLATFORM_RUNNING)
> >               return;
> > +
> > +     ret_val = stream->ops->stream_read_tstamp(sst->dev, &stream->stream_info);
> > +     if (ret_val) {
> > +             dev_err(rtd->dev, "stream_read_tstamp err code = %d\n", ret_val);
> > +             return;
> > +     }
> >       snd_pcm_period_elapsed(substream);
> >  }
> >
> > @@ -658,20 +670,15 @@ static snd_pcm_uframes_t sst_platform_pcm_pointer
> >                       (struct snd_pcm_substream *substream)
> >  {
> >       struct sst_runtime_stream *stream;
> > -     int ret_val, status;
> > +     int status;
> >       struct pcm_stream_info *str_info;
> > -     struct snd_soc_pcm_runtime *rtd = substream->private_data;
> >
> >       stream = substream->runtime->private_data;
> >       status = sst_get_stream_status(stream);
> >       if (status == SST_PLATFORM_INIT)
> >               return 0;
> > +
> >       str_info = &stream->stream_info;
> > -     ret_val = stream->ops->stream_read_tstamp(sst->dev, str_info);
> > -     if (ret_val) {
> > -             dev_err(rtd->dev, "sst: error code = %d\n", ret_val);
> > -             return ret_val;
> > -     }
> >       substream->runtime->delay = str_info->pcm_delay;
> >       return str_info->buffer_ptr;
> >  }
> > --
> > 2.22.0.410.gd8fdbe21b5-goog
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [alsa-devel] [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed
  2019-07-10 23:15   ` Curtis Malainey
@ 2019-07-17 15:30     ` Pierre-Louis Bossart
  0 siblings, 0 replies; 4+ messages in thread
From: Pierre-Louis Bossart @ 2019-07-17 15:30 UTC (permalink / raw)
  To: Curtis Malainey, Andy Shevchenko
  Cc: ALSA development, Linux Kernel Mailing List, Takashi Iwai,
	Jie Yang, Liam Girdwood, Ben Zhang, Mark Brown, Curtis Malainey,
	Alex Levin



On 7/10/19 6:15 PM, Curtis Malainey wrote:
> On Tue, Jul 9, 2019 at 4:45 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>>
>> On Mon, Jul 08, 2019 at 09:01:47PM -0700, Alex Levin wrote:
>>> sst_platform_pcm_pointer is called from both snd_pcm_period_elapsed and
>>> from snd_pcm_ioctl. Calling read timestamp results in recalculating
>>> pcm_delay and buffer_ptr (sst_calc_tstamp) which consumes buffers in a
>>> faster rate than intended.
>>> In a tested BSW system with chtrt5650, for a rate of 48000, the
>>> measured rate was sometimes 10 times more than that.
>>> After moving the timestamp read to period elapsed, buffer consumption is
>>> as expected.
>>
>>  From code prospective it looks good. You may take mine
>> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>>
>> Though I'm not an expert in the area, Pierre and / or Liam should give
>> their blessing.
>>
> Agreed, Liam or Pierre should also give their ok since this is one of
> the closed source firmware drivers.
> 
> Reviewed-by: Curtis Malainey <cujomalainey@chromium.org>

Humm, this first review after my Summer break isn't straightforward.

By moving the timestamp update to the period elapsed event, don't you 
prevent the use of this driver in no-interrupt mode - which I understood 
as the baseline for Chrome?

And I also don't get how this timestamp might lead to 10x speed issues, 
this driver has been around for a number of years and that specific 
error was never seen. What is different in this platform and can this be 
seen e.g. on a Cyan device?


>>>
>>> Signed-off-by: Alex Levin <levinale@chromium.org>
>>> ---
>>>   sound/soc/intel/atom/sst-mfld-platform-pcm.c | 23 +++++++++++++-------
>>>   1 file changed, 15 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
>>> index 0e8b1c5eec88..196af0b30b41 100644
>>> --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
>>> +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
>>> @@ -265,16 +265,28 @@ static void sst_period_elapsed(void *arg)
>>>   {
>>>        struct snd_pcm_substream *substream = arg;
>>>        struct sst_runtime_stream *stream;
>>> -     int status;
>>> +     struct snd_soc_pcm_runtime *rtd;
>>> +     int status, ret_val;
>>>
>>>        if (!substream || !substream->runtime)
>>>                return;
>>>        stream = substream->runtime->private_data;
>>>        if (!stream)
>>>                return;
>>> +
>>> +     rtd = substream->private_data;
>>> +     if (!rtd)
>>> +             return;
>>> +
>>>        status = sst_get_stream_status(stream);
>>>        if (status != SST_PLATFORM_RUNNING)
>>>                return;
>>> +
>>> +     ret_val = stream->ops->stream_read_tstamp(sst->dev, &stream->stream_info);
>>> +     if (ret_val) {
>>> +             dev_err(rtd->dev, "stream_read_tstamp err code = %d\n", ret_val);
>>> +             return;
>>> +     }
>>>        snd_pcm_period_elapsed(substream);
>>>   }
>>>
>>> @@ -658,20 +670,15 @@ static snd_pcm_uframes_t sst_platform_pcm_pointer
>>>                        (struct snd_pcm_substream *substream)
>>>   {
>>>        struct sst_runtime_stream *stream;
>>> -     int ret_val, status;
>>> +     int status;
>>>        struct pcm_stream_info *str_info;
>>> -     struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>>
>>>        stream = substream->runtime->private_data;
>>>        status = sst_get_stream_status(stream);
>>>        if (status == SST_PLATFORM_INIT)
>>>                return 0;
>>> +
>>>        str_info = &stream->stream_info;
>>> -     ret_val = stream->ops->stream_read_tstamp(sst->dev, str_info);
>>> -     if (ret_val) {
>>> -             dev_err(rtd->dev, "sst: error code = %d\n", ret_val);
>>> -             return ret_val;
>>> -     }
>>>        substream->runtime->delay = str_info->pcm_delay;
>>>        return str_info->buffer_ptr;
>>>   }
>>> --
>>> 2.22.0.410.gd8fdbe21b5-goog
>>>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-07-17 15:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-09  4:01 [PATCH] ASoC: Intel: Atom: read timestamp moved to period_elapsed Alex Levin
2019-07-09 11:45 ` Andy Shevchenko
2019-07-10 23:15   ` Curtis Malainey
2019-07-17 15:30     ` [alsa-devel] " Pierre-Louis Bossart

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).