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: > 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html