[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160819144640.GM21682@localhost.localdomain>
Date: Fri, 19 Aug 2016 15:46:40 +0100
From: Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To: Krzysztof Kozlowski <k.kozlowski@...sung.com>
CC: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...eaurora.org>,
Stephen Warren <swarren@...dotorg.org>,
Lee Jones <lee@...nel.org>, Eric Anholt <eric@...olt.net>,
Florian Fainelli <f.fainelli@...il.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
<bcm-kernel-feedback-list@...adcom.com>,
"Sylwester Nawrocki" <s.nawrocki@...sung.com>,
Tomasz Figa <tomasz.figa@...il.com>,
Kukjin Kim <kgene@...nel.org>,
Russell King <linux@...linux.org.uk>,
"Mark Brown" <broonie@...nel.org>, <linux-clk@...r.kernel.org>,
<linux-rpi-kernel@...ts.infradead.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>,
<linux-samsung-soc@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
<alsa-devel@...a-project.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Javier Martinez Canillas <javier@....samsung.com>,
<a.hajda@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks
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
Powered by blists - more mailing lists