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:
1. For prepare/unprepare paths: lock only clock controller and its
parents.
2. For recalc rates paths: lock global lock, the controller and its
children.
3. 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
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
