| Message ID | 1442213477-63721-1-git-send-email-koro.chen@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Any suggestion for this patch? On Mon, 2015-09-14 at 14:51 +0800, Koro Chen wrote: > In capture, there is chance that hw_ptr reported at IRQ is > a little smaller than period_size due to internal AFE buffer. > In the case of ping-pong buffer: > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------| > hw_ptr < period_size > > This available buffer will not be read since its size is smaller than > avail_min (which is period_size by default), and read thread continues > to sleep. If the next hw_ptr is just a little larger than buffer_size, > overrun occurs. One more period can hold the possible unread buffer. > > Signed-off-by: Koro Chen <koro.chen@mediatek.com> > --- > sound/soc/mediatek/mtk-afe-pcm.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c > index d190fe0..f5baf3c 100644 > --- a/sound/soc/mediatek/mtk-afe-pcm.c > +++ b/sound/soc/mediatek/mtk-afe-pcm.c > @@ -549,6 +549,23 @@ static int mtk_afe_dais_startup(struct snd_pcm_substream *substream, > memif->substream = substream; > > snd_soc_set_runtime_hwparams(substream, &mtk_afe_hardware); > + > + /* > + * Capture cannot use ping-pong buffer since hw_ptr at IRQ may be > + * smaller than period_size due to AFE's internal buffer. > + * This easily leads to overrun when avail_min is period_size. > + * One more period can hold the possible unread buffer. > + */ > + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { > + ret = snd_pcm_hw_constraint_minmax(runtime, > + SNDRV_PCM_HW_PARAM_PERIODS, > + 3, > + mtk_afe_hardware.periods_max); > + if (ret < 0) { > + dev_err(afe->dev, "hw_constraint_minmax failed\n"); > + return ret; > + } > + } > ret = snd_pcm_hw_constraint_integer(runtime, > SNDRV_PCM_HW_PARAM_PERIODS); > if (ret < 0)
On Wed, Sep 23, 2015 at 06:03:19PM +0800, Koro Chen wrote: > Any suggestion for this patch? > > On Mon, 2015-09-14 at 14:51 +0800, Koro Chen wrote: > > In capture, there is chance that hw_ptr reported at IRQ is > > a little smaller than period_size due to internal AFE buffer. > > In the case of ping-pong buffer: Please don't top post or send content free pings. I'm not entirely sure what you're asking for here - the patch has been applied, what further suggestions were you looking for?
On Wed, 2015-09-23 at 09:12 -0700, Mark Brown wrote: > On Wed, Sep 23, 2015 at 06:03:19PM +0800, Koro Chen wrote: > > Any suggestion for this patch? > > > > On Mon, 2015-09-14 at 14:51 +0800, Koro Chen wrote: > > > In capture, there is chance that hw_ptr reported at IRQ is > > > a little smaller than period_size due to internal AFE buffer. > > > In the case of ping-pong buffer: > > Please don't top post or send content free pings. I'm not entirely sure > what you're asking for here - the patch has been applied, what further > suggestions were you looking for? I am sorry about the top posting ping... will never do this again. OK thank you, now I see the patch is already in the tree, but I am sure I didn't get the mail titled "Applied xxx to the asoc tree", so I didn't know the patch status. Maybe something was wrong with the mail system?
On Thu, Sep 24, 2015 at 09:39:49AM +0800, Koro Chen wrote: > OK thank you, now I see the patch is already in the tree, but I am sure > I didn't get the mail titled "Applied xxx to the asoc tree", so I didn't > know the patch status. Maybe something was wrong with the mail system? Possibly your mail system flagged it as spam?
On Thu, Sep 24, 2015 at 10:11:53AM -0700, Mark Brown wrote: > On Thu, Sep 24, 2015 at 09:39:49AM +0800, Koro Chen wrote: > > > OK thank you, now I see the patch is already in the tree, but I am sure > > I didn't get the mail titled "Applied xxx to the asoc tree", so I didn't > > know the patch status. Maybe something was wrong with the mail system? > > Possibly your mail system flagged it as spam? I didn't receive it either and it doesn't seem to be in the archives. Sascha
On Thu, Sep 24, 2015 at 07:31:42PM +0200, Sascha Hauer wrote: > On Thu, Sep 24, 2015 at 10:11:53AM -0700, Mark Brown wrote: > > Possibly your mail system flagged it as spam? > I didn't receive it either and it doesn't seem to be in the archives. Initially they weren't CCed to the list.
diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c index d190fe0..f5baf3c 100644 --- a/sound/soc/mediatek/mtk-afe-pcm.c +++ b/sound/soc/mediatek/mtk-afe-pcm.c @@ -549,6 +549,23 @@ static int mtk_afe_dais_startup(struct snd_pcm_substream *substream, memif->substream = substream; snd_soc_set_runtime_hwparams(substream, &mtk_afe_hardware); + + /* + * Capture cannot use ping-pong buffer since hw_ptr at IRQ may be + * smaller than period_size due to AFE's internal buffer. + * This easily leads to overrun when avail_min is period_size. + * One more period can hold the possible unread buffer. + */ + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { + ret = snd_pcm_hw_constraint_minmax(runtime, + SNDRV_PCM_HW_PARAM_PERIODS, + 3, + mtk_afe_hardware.periods_max); + if (ret < 0) { + dev_err(afe->dev, "hw_constraint_minmax failed\n"); + return ret; + } + } ret = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); if (ret < 0)
In capture, there is chance that hw_ptr reported at IRQ is a little smaller than period_size due to internal AFE buffer. In the case of ping-pong buffer: |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------| hw_ptr < period_size This available buffer will not be read since its size is smaller than avail_min (which is period_size by default), and read thread continues to sleep. If the next hw_ptr is just a little larger than buffer_size, overrun occurs. One more period can hold the possible unread buffer. Signed-off-by: Koro Chen <koro.chen@mediatek.com> --- sound/soc/mediatek/mtk-afe-pcm.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)