Why DMA PL330 peripheral transfer does not support burst request?
Jassi Brar
jassisinghbrar at gmail.com
Fri May 18 15:02:44 EDT 2012
On Fri, May 18, 2012 at 7:48 AM, Lee Booi Lim <lee.booi.lim at gmail.com> wrote:
> Appreciate if you could share with me on what is the weird behaviour
> seen. Is it because of DMA PL330 hardware bug? We have seen a problem
> on DMA PL330 that happens in DMA burst mode. If a DMA channel is
> programmed to wait for a burst from the peripheral (let's takes an
> example of RX path), somehow transfer error happened in the middle due
> to the peripheral is not able to trigger a burst as it does not have
> enough data. In this case, the DMA channel will be killed if the
> driver / application detects timeout on the transfer. However, the DMA
> PL330 is not able to resume to normal even with DMAKILL and DMAFLUSHP,
> that particular DMA channel will remain in waiting for burst mode. If
> the DMA transfer is restarted with single transfer, the request will
> be ignored. The waiting for burst state can only be reset if a cold
> reset to the DMA PL330 controller happen or a burst is actually
> happen.
>
> May I know whether the similar behaviour is observed in 6440? If not,
> could you please share with me on the behaviour you have observed so
> that I can try to reproduce it.
>
It's been almost 3yrs now, I don't remember exactly. IIRC it was evt0
of 6440 and the problem was random skips in sine wave playback over
I2S, while it worked just fine over an evt1. Please note the *IIRC*, I
have suffered those audio issues for many reasons.
Apparently you have changed the micro-code in the driver. So I can't
say much about what you observe. I might be able to suggest something
useful if I know what your SoC and code looks like and if the original
driver didn't work for you.
> As you have mentioned that the bottleneck is always at the
> peripherals, may I know is this a fair assumption? Please correct me
> if I get you wrong, you meant that the peripheral is always slower in
> pulling out the data from DMAC or putting data into DMAC, right? You
> are not saying that the peripheral cannot support burst mode, right?
>
I meant peripherals produce/consume data at a rate slower than the dma
could provide even at single burst.
Though thinking about it again, I shouldn't have generalized for every
peripheral-dmac combination. Which is yours?
More information about the linux-arm-kernel
mailing list