Why DMA PL330 peripheral transfer does not support burst request?

Why DMA PL330 peripheral transfer does not support burst request?

[Lee Booi Lim]

Hi,

I found that DMA driver for PL330 only supports single request and not
burst request. The burst length is by default set to 1 in both the
functions pl330_prep_slave_sg and pl330_prep_dma_cyclic
(linux/drivers/dma/pl330.c).

desc->rqcfg.brst_size = pch->burst_sz;

desc->rqcfg.brst_len = 1;


Even though the device_control (pl330_control) function allows the
client driver to pass in the burst length through slave DMA
configuration. The burst_len  is always default to 1.

pch->burst_len = slave_config->src_maxburst;


The peripheral transfer request is programmed such a way that it is
always waiting for single request (
linux/arch/arm/common/pl330.c)
. In this case, the burst request would not be handled.

976 static inline int _ldst_devtomem(unsigned dry_run, u8 buf[],
977                 const struct _xfer_spec *pxs, int cyc)
978 {
979         int off = 0;
980
981         while (cyc--) {
982                 off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
983                 off += _emit_LDP(dry_run, &buf[off], SINGLE, pxs->r->peri);
984                 off += _emit_ST(dry_run, &buf[off], ALWAYS);
985                 off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
986         }
987
988         return off;
989 }
990
991 static inline int _ldst_memtodev(unsigned dry_run, u8 buf[],
992                 const struct _xfer_spec *pxs, int cyc)
993 {
994         int off = 0;
995
996         while (cyc--) {
997                 off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
998                 off += _emit_LD(dry_run, &buf[off], ALWAYS);
999                 off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
1000                 off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
1001         }
1002
1003         return off;
1004 }

May I know is there any reason to constraint the transfer to be single
and ignore the burst request? If the watermark of burst is hit then
the dr_type will be set to BURST, in this PL330 will not perform the
DMA transfer since that the DMASTPS or DMALDPS will be treated as
DMANOP.

Besides that, DMARMB and DMAWMB are not enforced for peripheral
transfer. Is it safe to do so?

Thanks,
Lee Booi

Why DMA PL330 peripheral transfer does not support burst request?

[Lee Booi Lim]

Hi,

The DMA can be programmed to receive burst or single request. For
DMAWFPS, the DMA controller will proceed to execute the rest of
microcode even if the peripheral is requesting a burst request. The
request_type in the DMA PL330 will be set to single in this case and
the request type from peripheral is ignored. I misinterpreted that the
DMASTP[S/B] or DMALDP[S/B] is based on peripheral request type. Even
though the code works, it constrains the DMA controller from
performing burst transfer. The performance is going to be slower to
perform multiple single transfer when compared to multiple burst
transfer (for burst case, some data might still be transferred as
single if remaining bytes < burst_len * burst_size).

So my questions are as below:
1. Why the burst transfer mode is not supported? Is it for simplicity,
so that it will work for all cases no matter the peripheral is
requesting burst/single? Or is it because of hardware constraint that
is not documented? Why the performance is sacrificed?

2. By allowing the slave config to be passed in the burst length
through device_control (pl330_control) function and yet the burst_len
is always hard coded to 1 seems that misleading.
            pch->burst_sz = __ffs(slave_config->src_addr_width);
            pch->burst_len = slave_config->src_maxburst;
            pch->burst_sz = __ffs(slave_config->dst_addr_width);
            pch->burst_len = slave_config->dst_maxburst;

           desc->rqcfg.brst_size = pch->burst_sz;
           desc->rqcfg.brst_len = 1; (in pl330_prep_slave_sg and
pl330_prep_dma_cyclic functions)

3. May I know whether the DMARMB and DMAWMB are needed in PL330
peripheral transfer functions? (Memory barriers are explicitly called
in memory-to-memory transfer function.) We are doing a load and then
store, without the read/write memory barrier will there be cases that
the data store is executed first before valid data from DMALD is
available?

4. DMA PL330 is programmed to do a flushp each time after a single
transfer, what is the purpose of that? The DMAFLUSHP is being issued
each round may degrade the performance of DMA transfer also. Is it to
cater for DMA transfer with single in response to burst request? Why
can't the flushp being issued before the start of any single transfer
and issued again after all single transfer?
> 997                 off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 998                 off += _emit_LD(dry_run, &buf[off], ALWAYS);
> 999                 off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 1000                 off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);

5. DMAFLUSHP is used to initialize and resync the particular
peripheral to the DMA PL330 controller. Why the DMAFLUSHP is not
issued at the beginning of peripheral to/from memory transfer before
any data transfer is carried out?

Appreciate if anybody who are the maintainer of the code or who has
run the code before to share your knowledge on this to me as I am new
to DMA PL330.

Thanks,
Lee Booi

On Fri, May 11, 2012 at 6:30 PM, Lee Booi Lim <lee.booi.lim@gmail.com> wrote:
> Hi,
>
> I found that DMA driver for PL330 only supports single request and not
> burst request. The burst length is by default set to 1 in both the
> functions pl330_prep_slave_sg and pl330_prep_dma_cyclic
> (linux/drivers/dma/pl330.c).
>
> desc->rqcfg.brst_size = pch->burst_sz;
>
> desc->rqcfg.brst_len = 1;
>
>
> Even though the device_control (pl330_control) function allows the
> client driver to pass in the burst length through slave DMA
> configuration. The burst_len ?is always default to 1.
>
> pch->burst_len = slave_config->src_maxburst;
>
>
> The peripheral transfer request is programmed such a way that it is
> always waiting for single request (
> linux/arch/arm/common/pl330.c)
> . In this case, the burst request would not be handled.
>
> 976 static inline int _ldst_devtomem(unsigned dry_run, u8 buf[],
> 977 ? ? ? ? ? ? ? ? const struct _xfer_spec *pxs, int cyc)
> 978 {
> 979 ? ? ? ? int off = 0;
> 980
> 981 ? ? ? ? while (cyc--) {
> 982 ? ? ? ? ? ? ? ? off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 983 ? ? ? ? ? ? ? ? off += _emit_LDP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 984 ? ? ? ? ? ? ? ? off += _emit_ST(dry_run, &buf[off], ALWAYS);
> 985 ? ? ? ? ? ? ? ? off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
> 986 ? ? ? ? }
> 987
> 988 ? ? ? ? return off;
> 989 }
> 990
> 991 static inline int _ldst_memtodev(unsigned dry_run, u8 buf[],
> 992 ? ? ? ? ? ? ? ? const struct _xfer_spec *pxs, int cyc)
> 993 {
> 994 ? ? ? ? int off = 0;
> 995
> 996 ? ? ? ? while (cyc--) {
> 997 ? ? ? ? ? ? ? ? off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 998 ? ? ? ? ? ? ? ? off += _emit_LD(dry_run, &buf[off], ALWAYS);
> 999 ? ? ? ? ? ? ? ? off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> 1000 ? ? ? ? ? ? ? ? off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
> 1001 ? ? ? ? }
> 1002
> 1003 ? ? ? ? return off;
> 1004 }
>
> May I know is there any reason to constraint the transfer to be single
> and ignore the burst request? If the watermark of burst is hit then
> the dr_type will be set to BURST, in this PL330 will not perform the
> DMA transfer since that the DMASTPS or DMALDPS will be treated as
> DMANOP.
>
> Besides that, DMARMB and DMAWMB are not enforced for peripheral
> transfer. Is it safe to do so?
>
> Thanks,
> Lee Booi

Why DMA PL330 peripheral transfer does not support burst request?

[Jassi Brar]

On Mon, May 14, 2012 at 3:05 PM, Lee Booi Lim <lee.booi.lim@gmail.com> wrote:

> Even though the code works, it constrains the DMA controller from
> performing burst transfer. The performance is going to be slower to
> perform multiple single transfer when compared to multiple burst
> transfer (for burst case, some data might still be transferred as
> single if remaining bytes < burst_len * burst_size).
>
> So my questions are as below:
> 1. Why the burst transfer mode is not supported? Is it for simplicity,
> so that it will work for all cases no matter the peripheral is
> requesting burst/single? Or is it because of hardware constraint that
> is not documented? Why the performance is sacrificed?
>
Yes, it was meant to cover every case. IIRC 6440(?) behaved a bit weirdly
with bursts despite me, I believed, doing the things rightly.
Anyways since it is for peripherals, dma wouldn't be the performance bottleneck.


> 2. By allowing the slave config to be passed in the burst length
> through device_control (pl330_control) function and yet the burst_len
> is always hard coded to 1 seems that misleading.
> ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->src_addr_width);
> ? ? ? ? ? ?pch->burst_len = slave_config->src_maxburst;
> ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->dst_addr_width);
> ? ? ? ? ? ?pch->burst_len = slave_config->dst_maxburst;
>
> ? ? ? ? ? desc->rqcfg.brst_size = pch->burst_sz;
> ? ? ? ? ? desc->rqcfg.brst_len = 1; (in pl330_prep_slave_sg and
> pl330_prep_dma_cyclic functions)
>
The unused pch->burst_len setting came with slave support to the pl330's
dmaengine driver, which was added later by Boojin Kim (CC'ed).

> 3. May I know whether the DMARMB and DMAWMB are needed in PL330
> peripheral transfer functions? (Memory barriers are explicitly called
> in memory-to-memory transfer function.) We are doing a load and then
> store, without the read/write memory barrier will there be cases that
> the data store is executed first before valid data from DMALD is
> available?
>
No. By the PL330 manual
  "These enable write-after-read/read-after-write sequences to the same address
location with no hazards".
Since peripherals' FIFO exchange data with memory, we don't run that risk.
Hence only Mem->Mem transfers have the barriers.

> 4. DMA PL330 is programmed to do a flushp each time after a single
> transfer, what is the purpose of that? The DMAFLUSHP is being issued
> each round may degrade the performance of DMA transfer also. Is it to
> cater for DMA transfer with single in response to burst request? Why
> can't the flushp being issued before the start of any single transfer
> and issued again after all single transfer?
>> 997 ? ? ? ? ? ? ? ? off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
>> 998 ? ? ? ? ? ? ? ? off += _emit_LD(dry_run, &buf[off], ALWAYS);
>> 999 ? ? ? ? ? ? ? ? off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
>> 1000 ? ? ? ? ? ? ? ? off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
>
Again this was for robustness and to work with most peripherals.
Though I think we could do flush only once before the start of a transfer.

Why DMA PL330 peripheral transfer does not support burst request?

[Lee Booi Lim]

Are you referring to? S5P6440? May I know what is the weird behaviour?
If this is related to 6440 only, can the driver be modified to support
burst and yet allow to use single transfer to cater for 6440 case?

Even the bottleneck is at peripherals, some peripherals do support
burst mode. So that would be some performance gain if burst transfer
is allowed.

Thanks.

On Tue, May 15, 2012 at 2:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>
> On Mon, May 14, 2012 at 3:05 PM, Lee Booi Lim <lee.booi.lim@gmail.com> wrote:
>
> > Even though the code works, it constrains the DMA controller from
> > performing burst transfer. The performance is going to be slower to
> > perform multiple single transfer when compared to multiple burst
> > transfer (for burst case, some data might still be transferred as
> > single if remaining bytes < burst_len * burst_size).
> >
> > So my questions are as below:
> > 1. Why the burst transfer mode is not supported? Is it for simplicity,
> > so that it will work for all cases no matter the peripheral is
> > requesting burst/single? Or is it because of hardware constraint that
> > is not documented? Why the performance is sacrificed?
> >
> Yes, it was meant to cover every case. IIRC 6440(?) behaved a bit weirdly
> with bursts despite me, I believed, doing the things rightly.
> Anyways since it is for peripherals, dma wouldn't be the performance bottleneck.
>
>
> > 2. By allowing the slave config to be passed in the burst length
> > through device_control (pl330_control) function and yet the burst_len
> > is always hard coded to 1 seems that misleading.
> > ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->src_addr_width);
> > ? ? ? ? ? ?pch->burst_len = slave_config->src_maxburst;
> > ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->dst_addr_width);
> > ? ? ? ? ? ?pch->burst_len = slave_config->dst_maxburst;
> >
> > ? ? ? ? ? desc->rqcfg.brst_size = pch->burst_sz;
> > ? ? ? ? ? desc->rqcfg.brst_len = 1; (in pl330_prep_slave_sg and
> > pl330_prep_dma_cyclic functions)
> >
> The unused pch->burst_len setting came with slave support to the pl330's
> dmaengine driver, which was added later by Boojin Kim (CC'ed).
>
> > 3. May I know whether the DMARMB and DMAWMB are needed in PL330
> > peripheral transfer functions? (Memory barriers are explicitly called
> > in memory-to-memory transfer function.) We are doing a load and then
> > store, without the read/write memory barrier will there be cases that
> > the data store is executed first before valid data from DMALD is
> > available?
> >
> No. By the PL330 manual
> ?"These enable write-after-read/read-after-write sequences to the same address
> location with no hazards".
> Since peripherals' FIFO exchange data with memory, we don't run that risk.
> Hence only Mem->Mem transfers have the barriers.
>
> > 4. DMA PL330 is programmed to do a flushp each time after a single
> > transfer, what is the purpose of that? The DMAFLUSHP is being issued
> > each round may degrade the performance of DMA transfer also. Is it to
> > cater for DMA transfer with single in response to burst request? Why
> > can't the flushp being issued before the start of any single transfer
> > and issued again after all single transfer?
> >> 997 ? ? ? ? ? ? ? ? off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> >> 998 ? ? ? ? ? ? ? ? off += _emit_LD(dry_run, &buf[off], ALWAYS);
> >> 999 ? ? ? ? ? ? ? ? off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
> >> 1000 ? ? ? ? ? ? ? ? off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
> >
> Again this was for robustness and to work with most peripherals.
> Though I think we could do flush only once before the start of a transfer.

Why DMA PL330 peripheral transfer does not support burst request?

[Lee Booi Lim]

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.

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?

Appreciate if you can share your views and experiences to me.

Thanks,
Lee Booi

On Tue, May 15, 2012 at 4:39 PM, Lee Booi Lim <lee.booi.lim@gmail.com> wrote:
> Are you referring to? S5P6440? May I know what is the weird behaviour?
> If this is related to 6440 only, can the driver be modified to support
> burst and yet allow to use single transfer to cater for 6440 case?
>
> Even the bottleneck is at peripherals, some peripherals do support
> burst mode. So that would be some performance gain if burst transfer
> is allowed.
>
> Thanks.
>
> On Tue, May 15, 2012 at 2:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>>
>> On Mon, May 14, 2012 at 3:05 PM, Lee Booi Lim <lee.booi.lim@gmail.com> wrote:
>>
>> > Even though the code works, it constrains the DMA controller from
>> > performing burst transfer. The performance is going to be slower to
>> > perform multiple single transfer when compared to multiple burst
>> > transfer (for burst case, some data might still be transferred as
>> > single if remaining bytes < burst_len * burst_size).
>> >
>> > So my questions are as below:
>> > 1. Why the burst transfer mode is not supported? Is it for simplicity,
>> > so that it will work for all cases no matter the peripheral is
>> > requesting burst/single? Or is it because of hardware constraint that
>> > is not documented? Why the performance is sacrificed?
>> >
>> Yes, it was meant to cover every case. IIRC 6440(?) behaved a bit weirdly
>> with bursts despite me, I believed, doing the things rightly.
>> Anyways since it is for peripherals, dma wouldn't be the performance bottleneck.
>>
>>
>> > 2. By allowing the slave config to be passed in the burst length
>> > through device_control (pl330_control) function and yet the burst_len
>> > is always hard coded to 1 seems that misleading.
>> > ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->src_addr_width);
>> > ? ? ? ? ? ?pch->burst_len = slave_config->src_maxburst;
>> > ? ? ? ? ? ?pch->burst_sz = __ffs(slave_config->dst_addr_width);
>> > ? ? ? ? ? ?pch->burst_len = slave_config->dst_maxburst;
>> >
>> > ? ? ? ? ? desc->rqcfg.brst_size = pch->burst_sz;
>> > ? ? ? ? ? desc->rqcfg.brst_len = 1; (in pl330_prep_slave_sg and
>> > pl330_prep_dma_cyclic functions)
>> >
>> The unused pch->burst_len setting came with slave support to the pl330's
>> dmaengine driver, which was added later by Boojin Kim (CC'ed).
>>
>> > 3. May I know whether the DMARMB and DMAWMB are needed in PL330
>> > peripheral transfer functions? (Memory barriers are explicitly called
>> > in memory-to-memory transfer function.) We are doing a load and then
>> > store, without the read/write memory barrier will there be cases that
>> > the data store is executed first before valid data from DMALD is
>> > available?
>> >
>> No. By the PL330 manual
>> ?"These enable write-after-read/read-after-write sequences to the same address
>> location with no hazards".
>> Since peripherals' FIFO exchange data with memory, we don't run that risk.
>> Hence only Mem->Mem transfers have the barriers.
>>
>> > 4. DMA PL330 is programmed to do a flushp each time after a single
>> > transfer, what is the purpose of that? The DMAFLUSHP is being issued
>> > each round may degrade the performance of DMA transfer also. Is it to
>> > cater for DMA transfer with single in response to burst request? Why
>> > can't the flushp being issued before the start of any single transfer
>> > and issued again after all single transfer?
>> >> 997 ? ? ? ? ? ? ? ? off += _emit_WFP(dry_run, &buf[off], SINGLE, pxs->r->peri);
>> >> 998 ? ? ? ? ? ? ? ? off += _emit_LD(dry_run, &buf[off], ALWAYS);
>> >> 999 ? ? ? ? ? ? ? ? off += _emit_STP(dry_run, &buf[off], SINGLE, pxs->r->peri);
>> >> 1000 ? ? ? ? ? ? ? ? off += _emit_FLUSHP(dry_run, &buf[off], pxs->r->peri);
>> >
>> Again this was for robustness and to work with most peripherals.
>> Though I think we could do flush only once before the start of a transfer.

Why DMA PL330 peripheral transfer does not support burst request?

[Jassi Brar]

On Fri, May 18, 2012 at 7:48 AM, Lee Booi Lim <lee.booi.lim@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?

Why DMA PL330 peripheral transfer does not support burst request?

[Lee Booi Lim]

On Sat, May 19, 2012 at 3:02 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> On Fri, May 18, 2012 at 7:48 AM, Lee Booi Lim <lee.booi.lim@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.

I have not make changes to the driver to support burst yet. The PL330
hardware problem was found by my friend on the use case test (not
running Linux) for the PL330 but not using Linux driver. That's why I
thought that you have disabled the burst support due to this PL330
bug. ARM has acknowledged the scenario I described above as a PL330
controller hardware bug.  So seems that we saw a different problem.
The above scenario only happens if burst mode is supported in the
driver. Evt0 and evt1 refer to event in DMA channel?

>
>> 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?

We are thinking to include the support burst mode since the
peripherals IP that we are using supports burst mode (e.g. Designware
SPI).