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
prev parent 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