On 07/12/11 07:52, Kukjin Kim wrote: > Jassi Brar wrote: >> >> 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 ? > > (Please adding me in this thread) > > Hi Javi, > How was going on the test? If any update, please let us know. I'm currently very busy at work, I'll run it as soon as I can. This appears to happen only in exynos, can't anybody else help with the debugging? Cheers, Javi -- 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
 |