On Tue, Aug 16, 2016 at 03:51:10PM +0200, Krzysztof Kozlowski wrote:
On 08/16/2016 03:34 PM, Krzysztof Kozlowski wrote:
Hi,
RFC, please, do not apply, maybe except patch #1 which is harmless.
Introduction
The patchset brings new entity: clock controller representing a hardware block. The clock controller comes with its own prepare lock which is used then in many places. The idea is to fix the deadlock mentioned in commit 10ff4c5239a1 ("i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared") and commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA deadlock by keeping clock prepared").
Damn, I forgot to describe the overall idea. :) It is mentioned in patch 15 but probably not many will have enough of patience to reach it.
The locking idea
Clock controllers representing different hardware blocks, will contain its own prepare lock which protects the clocks inside controller. The hierarchy itself is protected by global lock.
In prepare path, the global prepare lock is removed. This is direct solution for the deadlock.
Clock hierarchy imposes also hierarchy between controllers so when a prepare happens, also parents have to be locked.
Following locking design was chosen:
- For prepare/unprepare paths: lock only clock controller and its parents.
- For recalc rates paths: lock global lock, the controller and its children.
- For reparent paths: lock entire tree up down (children and parents) and the global lock as well.
In each case of traversing the clock hierarchy, the locking of controllers is always from children to parents.
Best regards, Krzysztof
I have been playing with these patches on my Arndale board and they certainly do seem to resolve the interaction issues I have been SPI and the clocking framework, which is awesome and lets me sensibly add the clocking framework into our codec drivers. I will keep investigating and for what its worth have a little more detailed look through the code.
Thanks, Charles