On 29 November 2011 15:23, Javi Merino <javi.merino@xxxxxxx> wrote: >>>>>> 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. >>>>> >>>>> If _thrd_active(thrd) returns '1', that means there is an active >>>>> transfer still running or, if it has finished, you haven't called >>>>> pl330_update() to acknowledge that. pl330_update() calls _start() >>> as >>>>> soon as it can. >>>>> >>>>> drivers/dma/pl330.c registers the irq handler in pl330_probe(), so >>>>> when >>>>> the transaction finishes, pl330_update() should clear it and call >>>>> _start(). If there is any outstanding transaction, it should start >>>>> straight away. If there isn't, it would mark the channel as free, >>> so >>>>> _thrd_active() should return '0'. If _thrd_active() is still '1', >>> then >>>>> something has gone wrong in the way. >>>>> >>>>> Does this shed some light? >>>>> >>>> >>>> Your patch makes the memcpy operation on dmatest.c and net DMA be >>> frozen too >>>> as well as Samsung audio playback. >>> >>> Is the IRQ correctly registered in drivers/dma/pl330.c:pl330_probe()? >>> Do you get interrupts when the transfer finish? >> Sure. IRQ works well. > > Ok, so can you check if pl330_update() is correctly marking the request > as free? Do you know if there is another request in the queue when that > happens? > > Thomas, you said in a previous email that _thrd_active() always returned > '1'. Was that after a request in req[0] finished? > - If so, can you check that MARK_FREE was actually called for that > request in pl330_update()? > - If it was after a request in req[1] finished and there was a > request already waiting in req[0], can you debug why _start() > didn't activate it. > Javi, could you please check if you too get the memcpy failure with dmatest ? Thanks. -- 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
 |