alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Lars-Peter Clausen <lars@metafoo.de>,
	nsekhar@ti.com, Liam Girdwood <lgirdwood@gmail.com>,
	Jyri Sarha <jsarha@ti.com>,
	zonque@gmail.com
Subject: Re: [PATCH v2 3/4] ASoC: davinci-mcasp: Constraint on the period and buffer size based on FIFO usage
Date: Tue, 18 Mar 2014 14:35:48 +0200	[thread overview]
Message-ID: <53283DA4.2080609@ti.com> (raw)
In-Reply-To: <20140317165214.GT11706@sirena.org.uk>

On 03/17/2014 06:52 PM, Mark Brown wrote:
> This is all sounding like the thing that needs to be looked at here is
> mplayer so we understand what's going wrong with regard to the buffer
> sizes.

The error which was printed by mplayer was the snd_pcm_hw_params() failure.
Prior to this call it calls number of snd_pcm_hw_params_set_* including:
snd_pcm_hw_params_set_buffer_time_near()
snd_pcm_hw_params_set_periods_near()

all without error.

So I recompiled alsa-lib with debug and compiled mplayer on the board as well.
I only kept the constraint for the period size from this patch (no constraint
on buffer size).

The compiled and original mplayer binary is working fine, no errors :o
Then I recompiled alsa-lib without debug (as it was before): same thing, moth
mplayer binary works fine and it picks correct buffer configuration.

I'll resend the last two patch and place the constraint only to the period size.

> It's sounding like if we should be doing it this is a general
> thing which we should be constraining presumably it'd apply to all
> drivers, not just this one, and so shouldn't be being fixed in the
> driver but it's not obvious to me why the period constraint isn't
> sufficient.

It can only be done if we have fixed FIFO for the dai. Right now this is kind
of true for McASP. In HW we actually have 64 32bit word FIFO and currently you
can set the desired FIFO depth via DT/pdata. I'm not really happy about this
since it creates this constraint on the buffer allocation when the SoC is
using eDMA (when sDMA is in used with McASP we do not have such issue).
McBSP also have FIFO on OMAPs, but there I do not lock the FIFO depth, it is
adaptive based on the period/buffer size.

If we have more device with fixed FIFO depth then it make sense to handle the
constraint in the core.

However in case of McASP it is still not that straight forward. The DMA burst
size depends on the number of channels, number of used serializers and the
AFIFO's depth configuration. At the end the period size need to be constraint
to be steps of DMA burst size for eDMA.

Not sure if this is applicable for other SoCs.

-- 
Péter

  reply	other threads:[~2014-03-18 12:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14 14:42 [PATCH v2 0/4] ASoC: davinci: edma dmaengine PCM and mcasp preparation Peter Ujfalusi
2014-03-14 14:42 ` [PATCH v2 1/4] ASoC: davinci: Add edma dmaengine platform driver Peter Ujfalusi
2014-03-16 10:54   ` Lars-Peter Clausen
2014-03-17 16:20   ` Mark Brown
2014-03-14 14:42 ` [PATCH v2 2/4] ASoC: davinci-mcasp: Provide correct filter_data for dmaengine for non-DT boot Peter Ujfalusi
2014-03-17 16:21   ` Mark Brown
2014-03-14 14:42 ` [PATCH v2 3/4] ASoC: davinci-mcasp: Constraint on the period and buffer size based on FIFO usage Peter Ujfalusi
2014-03-16 11:18   ` Lars-Peter Clausen
2014-03-17 13:28     ` Peter Ujfalusi
2014-03-17 16:52       ` Mark Brown
2014-03-18 12:35         ` Peter Ujfalusi [this message]
2014-03-18 12:42           ` Mark Brown
2014-03-14 14:42 ` [PATCH v2 4/4] ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback Peter Ujfalusi
2014-03-17 16:44   ` 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=53283DA4.2080609@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=nsekhar@ti.com \
    --cc=zonque@gmail.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;
as well as URLs for NNTP newsgroup(s).