public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jianqun Xu <jay.xu@rock-chips.com>
To: Lars-Peter Clausen <lars@metafoo.de>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Vinod Koul <vinod.koul@intel.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Mark Brown <broonie@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	Sonny Rao <sonnyrao@chromium.org>,
	Addy Ke <addy.ke@rock-chips.com>,
	Boojin Kim <boojin.kim@samsung.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, alsa-devel@alsa-project.org,
	linux-spi@vger.kernel.org, Yiwei Cai <cain.cai@rock-chips.com>,
	Jianqun Xu <xjq@rock-chips.com>
Subject: Re: [PATCH v6 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1
Date: Thu, 15 Oct 2015 18:47:26 +0800	[thread overview]
Message-ID: <561F843E.8040803@rock-chips.com> (raw)
In-Reply-To: <561F6990.7080809@metafoo.de>

在 2015年10月15日 16:53, Lars-Peter Clausen 写道:
> On 10/15/2015 03:36 AM, Shawn Lin wrote:
> [...]
>> +
>> +	if (snd_dmaengine_pcm_get_caps(&pdev->dev, &dma_caps) == 0) {
>> +		if (dma_caps.max_burst > 4) {
>> +			i2s->playback_dma_data.maxburst = 4;
>> +			i2s->capture_dma_data.maxburst = 4;
>> +		} else {
>> +			i2s->playback_dma_data.maxburst = 1;
>> +			i2s->capture_dma_data.maxburst = 1;
> So this is what this is all about? I though you might have to program some
> FIFO threshold registers in the peripheral itself.
>
> But it seems all this does is to read the maximum burst length from the DMA
> controller only to tell the DMA controller that this is the maximum burst
> length it should use. That seems rather unnecessary.
>
> The maxburst field of the dma_data indicates the maximum burst length that
> the audio peripheral can handle. Typically this is the number of samples the
> audio FIFO can receive without overflowing after sending the DMA request
> signal. Since as the name suggests this is the maximum burst size the DMA
> controller is free to choose a burst size smaller than this when writing
> data to the peripheral.
>
> So in your case instead of introducing all these facilities to query the
> maximum burst size it should be OK to simply reduce the burst size in the
> DMA controller itself when it gets a request with a burst size larger than
> it can handle, or is there a reason why this is not possible?
Agree with Lars, it's better to fix on DMA driver side since issue 
caused by dma-controller instead of i2s controller
>
> - Lars
>
>
>

-- 
Jianqun Xu | Software engineer | 18750760928



      reply	other threads:[~2015-10-15 10:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15  1:34 [PATCH v6 0/10] Fix broken DMAFLUSHP on Rockchips platform Shawn Lin
2015-10-15  1:35 ` [PATCH v6 01/10] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit Shawn Lin
2015-10-15  4:08   ` Vinod Koul
2015-10-15  6:51     ` Shawn Lin
2015-10-15  1:35 ` [PATCH v6 02/10] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp Shawn Lin
2015-10-15  1:35 ` [PATCH v6 03/10] DMA: pl330: add quirk for broken no flushp Shawn Lin
2015-10-15  1:35 ` [PATCH v6 04/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform Shawn Lin
2015-10-15  1:35 ` [PATCH v6 05/10] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform Shawn Lin
2015-10-15  1:36 ` [PATCH v6 06/10] DMA: dmaengine: expose max burst capability to clients Shawn Lin
2015-10-15  1:36 ` [PATCH v6 07/10] DMA: pl330: add max burst for dmaengine Shawn Lin
2015-10-15  1:36 ` [PATCH v6 08/10] spi: rockchip: modify DMA max burst to 1 Shawn Lin
2015-10-15  1:36 ` [PATCH v6 09/10] snd: dmaengine-pcm: add snd_dmaengine_pcm_get_caps interface Shawn Lin
2015-10-15  3:07   ` [alsa-devel] " kbuild test robot
2015-10-15  4:05   ` Vinod Koul
2015-10-15  6:50     ` Shawn Lin
2015-10-15  1:36 ` [PATCH v6 10/10] ASoC: rockchip_i2s: modify DMA max burst to 1 Shawn Lin
2015-10-15  3:20   ` kbuild test robot
2015-10-15  8:53   ` Lars-Peter Clausen
2015-10-15 10:47     ` Jianqun Xu [this message]

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=561F843E.8040803@rock-chips.com \
    --to=jay.xu@rock-chips.com \
    --cc=addy.ke@rock-chips.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=boojin.kim@samsung.com \
    --cc=broonie@kernel.org \
    --cc=cain.cai@rock-chips.com \
    --cc=dianders@chromium.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=perex@perex.cz \
    --cc=shawn.lin@rock-chips.com \
    --cc=sonnyrao@chromium.org \
    --cc=tiwai@suse.com \
    --cc=vinod.koul@intel.com \
    --cc=xjq@rock-chips.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