ABBA deadlock in Common Clock Framework

2014-07-02 Thread Tomasz Figa
Hi All, While testing linux-next (next-20140625) on Exynos4412-based TRATS2 board, from time to time I hit a deadlock between clk_disable_unused() of Common Clock Framework and parallel clk_prepare() from s3c24xx-i2c driver. I believe the following is happening (in processes 1 and 2): 1:

Re: ABBA deadlock in Common Clock Framework

2014-07-02 Thread Russell King - ARM Linux
On Wed, Jul 02, 2014 at 12:59:04PM +0200, Tomasz Figa wrote: Hi All, While testing linux-next (next-20140625) on Exynos4412-based TRATS2 board, from time to time I hit a deadlock between clk_disable_unused() of Common Clock Framework and parallel clk_prepare() from s3c24xx-i2c driver. This

Re: ABBA deadlock in Common Clock Framework

2014-07-02 Thread Peter De Schrijver
On Wed, Jul 02, 2014 at 12:59:04PM +0200, Tomasz Figa wrote: Hi All, While testing linux-next (next-20140625) on Exynos4412-based TRATS2 board, from time to time I hit a deadlock between clk_disable_unused() of Common Clock Framework and parallel clk_prepare() from s3c24xx-i2c driver. I

Re: ABBA deadlock in Common Clock Framework

2014-07-02 Thread Sylwester Nawrocki
On 02/07/14 13:49, Peter De Schrijver wrote: Or if you use notifiers which use i2c... See also http://comments.gmane.org/gmane.linux.kernel/1553699. One workaround is to always leave the clock of the i2c controller in a prepared state. Keeping the clock always prepared might not be that bad,