Hi Javi, On 6 October 2011 05:10, Javi Merino <javi.merino@xxxxxxx> wrote: > If two requests have been submitted and one of them is running, if you > call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time > between the spin_lock_irqsave() and the _state() check in which the > running transaction may finish. In that case, we don't receive the > interrupt (because they are disabled), but _start() sees that the DMA > is stopped, so it starts it. The problem is that it sends the > transaction that has just finished again, because pl330_update() > hasn't mark it as done yet. > > This patch fixes this race condition by not calling _start() if the > DMA is already executing transactions. When interrupts are reenabled, > pl330_update() will call _start(). > > Signed-off-by: Javi Merino <javi.merino@xxxxxxx> > Acked-by: Jassi Brar <jassi.brar@xxxxxxxxxxx> > --- > arch/arm/common/pl330.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c > index 97912fa..7129cfb 100644 > --- a/arch/arm/common/pl330.c > +++ b/arch/arm/common/pl330.c > @@ -1546,7 +1546,7 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op) > > /* Start the next */ > case PL330_OP_START: > - if (!_start(thrd)) > + if (!_thrd_active(thrd) && !_start(thrd)) > ret = -EIO; > break; On Samsung's Exynos4 platform, while testing audio playback with i2s interface, the above change causes the playback to freeze. The _thrd_active(thrd) call always returns '1' and hence _start(thrd) is not getting called. I have not debugged this much but if there is something that I am missing, please let me know. Meanwhile, I will continue checking on this. Thanks, Thomas. > > -- > 1.7.0.4 > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |