[alsa-devel] [PATCH] ASoC: tegra: fix maxburst settings in dmaengine code
From: Stephen Warren swarren@nvidia.com
The I2S controllers are programmed with an "attention" level of 4 DWORDs. This must match the configuration passed to the DMA driver, so that when they burst in data, they don't overflow the available FIFO space. Also, the burst size is relevant to the destination for playback, and source for capture, not vice-versa as originally written.
Signed-off-by: Stephen Warren swarren@nvidia.com --- Mark, I'd like to take this patch through the Tegra tree, since it's a dependency for the series that converts Tegra to dmaengine. Thanks.
sound/soc/tegra/tegra_pcm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c index 5658bce..8d6900c 100644 --- a/sound/soc/tegra/tegra_pcm.c +++ b/sound/soc/tegra/tegra_pcm.c @@ -334,11 +334,11 @@ static int tegra_pcm_hw_params(struct snd_pcm_substream *substream, if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; slave_config.dst_addr = dmap->addr; - slave_config.src_maxburst = 0; + slave_config.dst_maxburst = 4; } else { slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; slave_config.src_addr = dmap->addr; - slave_config.dst_maxburst = 0; + slave_config.src_maxburst = 4; } slave_config.slave_id = dmap->req_sel;
On Thu, Sep 06, 2012 at 05:47:33PM -0600, Stephen Warren wrote:
Mark, I'd like to take this patch through the Tegra tree, since it's a dependency for the series that converts Tegra to dmaengine. Thanks.
Since it's a fix I was going to send it as a patch for 3.6 so that shouldn't be an issue?
On 09/06/2012 07:00 PM, Mark Brown wrote:
On Thu, Sep 06, 2012 at 05:47:33PM -0600, Stephen Warren wrote:
Mark, I'd like to take this patch through the Tegra tree, since it's a dependency for the series that converts Tegra to dmaengine. Thanks.
Since it's a fix I was going to send it as a patch for 3.6 so that shouldn't be an issue?
Oh right, that makes sense too, thanks.
On 09/06/2012 07:36 PM, Stephen Warren wrote:
On 09/06/2012 07:00 PM, Mark Brown wrote:
On Thu, Sep 06, 2012 at 05:47:33PM -0600, Stephen Warren wrote:
Mark, I'd like to take this patch through the Tegra tree, since it's a dependency for the series that converts Tegra to dmaengine. Thanks.
Since it's a fix I was going to send it as a patch for 3.6 so that shouldn't be an issue?
Oh right, that makes sense too, thanks.
Mark,
This patch shows up in your ASoC for-next branch, but not in your for-3.6 or for-3.7 branches. I think gitk is telling me that you simply forgot to push your latest for-3.6 branch to kernel.org when you pushed your updated for-next.
Anyway, since this patch didn't make 3.6-rc5, it is difficult for me to use as a baseline for any branches destined for 3.7, since I'm supposed to send my pull requests to arm-soc before 3.6-rc6 is released, yet if this patch goes into 3.6, it won't be there until 3.6-rc6 at the earliest.
I'm not sure how best to resolve this; is it possible for me to take the patch through the Tegra tree instead, as I originally intended?
On Mon, Sep 10, 2012 at 12:03:31PM -0600, Stephen Warren wrote:
Anyway, since this patch didn't make 3.6-rc5, it is difficult for me to use as a baseline for any branches destined for 3.7, since I'm supposed to send my pull requests to arm-soc before 3.6-rc6 is released, yet if this patch goes into 3.6, it won't be there until 3.6-rc6 at the earliest.
I'm not sure how best to resolve this; is it possible for me to take the patch through the Tegra tree instead, as I originally intended?
Just merge the pull request in. I should send something out on Thursday I expect, though no guarantees about -rc6. It doesn't seem sensible to not merge the fix.
Or bend the rules for arm-soc by putting it in your own -next branch and then rebasing before it gets pulled into arm-soc. This would seem a sensible thing in general given arm-soc has this sort of model, it'd avoid what is essentially an extended merge window for arm-soc but still give things exposure in -next before they hit arm-soc itself.
On Thu, Sep 06, 2012 at 05:47:33PM -0600, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
The I2S controllers are programmed with an "attention" level of 4 DWORDs. This must match the configuration passed to the DMA driver, so that when they burst in data, they don't overflow the available FIFO space. Also, the burst size is relevant to the destination for playback, and source for capture, not vice-versa as originally written.
Applied, thanks.
participants (2)
-
Mark Brown -
Stephen Warren