From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752586AbcF2HXk (ORCPT <rfc822;w@1wt.eu>);
	Wed, 29 Jun 2016 03:23:40 -0400
Received: from mailout2.w1.samsung.com ([210.118.77.12]:50728 "EHLO
	mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752494AbcF2HXi (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 29 Jun 2016 03:23:38 -0400
X-AuditID: cbfec7f5-f792a6d000001302-b4-57737762e7a7
To: Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@codeaurora.org>, linux-clk@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Tomasz Figa <tomasz.figa@gmail.com>,
        Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Andrzej Hajda <a.hajda@samsung.com>,
        Javier Martinez Canillas <javier@osg.samsung.com>
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Subject: clk: Per controller locks (prepare & enable)
X-Enigmail-Draft-Status: N1110
Message-id: <57737761.2020708@samsung.com>
Date: Wed, 29 Jun 2016 09:23:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsVy+t/xa7pJ5cXhBhPPaFjcWneO1WLjjPWs
	Fm/ermGyeP3C0GLT42usFh977rFaXN41h81i7ZG77BYXT7laHH7Tzmrx40w3i8WqXX8YHXg8
	3t9oZfe43NfL5LFz1l12j81L6j229AMZfVtWMXp83iQXwB7FZZOSmpNZllqkb5fAldG3Zwlz
	wS+OisNT/rM1MM5m72Lk5JAQMJFY27efBcIWk7hwbz1bFyMXh5DAUkaJ57dOMkM4zxglOh5s
	AOsQEVjEJNG13RkkwSxwmFHi6vN3zCAJNgFjic3Ll7CB2MICphLr/51lhhgrJ9HbPQlsBa+A
	lsTSf1vBalgEVCX+b/7HCmKLCkRIzNr+gwmiRlDix+R7QPUcQAvUJaZMyQUJMwvIS2xe85Z5
	AiP/LCRVsxCqZiGpWsDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJBq+7mBceszqEKMA
	B6MSD6/GoaJwIdbEsuLK3EOMEhzMSiK8ncXF4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5Z+56
	HyIkkJ5YkpqdmlqQWgSTZeLglGpgNHN2bnP51q3zuqR64n5Z0QsvNM6m+K1cKTWvIHrFztOT
	elcdMg0ofX+gPVHa5FpAaCpbuqnv7yVLruspPjI1T5Bes2xn4AHrJYE9e5aVLYv+pzxhx4Nl
	a7MWFt19v1W5NimRw7Dk4MyfMzxP5tcb16z/s0PXVe6sqlQNj3DlGSt2z2PnIvMmKLEUZyQa
	ajEXFScCAMByktiCAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,


Problems:
1. Deadlocks on prepare lock in following scenario:
 - prepare_enable(some external clock through i2c)
   - i2c transfer
     - prepare_enable(i2c lock in SoC)
       - deadlock
See [1]. We implemented a workaround for this in few places like
10ff4c5239a1 ("i2c: exynos5: Fix possible ABBA deadlock by keeping I2C
clock prepared") and 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock by
keeping clock prepared")

The goal would be to remove also this workaround.

2. The global prepare and enable locks are over-used. I didn't test the
congestion but intuition says that they could be improved.


Solution:
Make this locks per controller. This will directly solve problem #1
because these are different controllers. Still in-controller deadlock
could occur but we couldn't find a real case with it.


Question:
What do you think about it? I know that talk is cheap and code looks
better but before starting the work I would like to hear some
comments/opinions/ideas.


Best regards,
Krzysztof


[1]
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/34/steps/Boot%20odroid/logs/serial