Re: [RFC][PATCH] Consolidate Samsung MAINTAINERS
Am Dienstag, 15. November 2011, 08:11:05 schrieb Kukjin Kim: Kukjin Kim wrote: Heiko Stübner wrote: Am Sonntag 23 Oktober 2011, 00:12:14 schrieb Heiko Stübner: These days most Samsung stuff gets in the kernel through Kukjin Kim. This patch changes MAINTAINERS to reflect this. By adding Kukjin Kim to the maintainers for S3C2410, S3C244x and S3C64xx alongside Ben Dooks the extra entries become identical to the base ARM/SAMSUNG entry and can move into it. Also the S3C2416 gets a maintainer through the s3c24* wildcard - as it did not have one until now. Signed-off-by: Heiko Stuebner he...@sntech.de --- ping? Hi Heiko, Basically I'm ok on this but need to get the agreement from Ben Dooks. Hi Ben, How do you think about this? If you don't want this, please let me know. seems ok then :-) Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: pl330: Fix a race condition
On 29/11/11 03:41, Boojin Kim wrote: Javi Merino 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. Cheers, Javi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: pl330: Fix a race condition
On 29 November 2011 15:23, Javi Merino javi.mer...@arm.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
