From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754871AbcHSOr0 (ORCPT ); Fri, 19 Aug 2016 10:47:26 -0400 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:58997 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750889AbcHSOrY (ORCPT ); Fri, 19 Aug 2016 10:47:24 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.wolfsonmicro.com Date: Fri, 19 Aug 2016 15:46:40 +0100 From: Charles Keepax To: Krzysztof Kozlowski CC: Michael Turquette , Stephen Boyd , Stephen Warren , Lee Jones , Eric Anholt , Florian Fainelli , Ray Jui , Scott Branden , , "Sylwester Nawrocki" , Tomasz Figa , Kukjin Kim , Russell King , "Mark Brown" , , , , , , , , Marek Szyprowski , Javier Martinez Canillas , , Bartlomiej Zolnierkiewicz Subject: Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks Message-ID: <20160819144640.GM21682@localhost.localdomain> References: <1471354514-24224-1-git-send-email-k.kozlowski@samsung.com> <65703100-1e16-6c34-babe-40e630180688@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <65703100-1e16-6c34-babe-40e630180688@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608190183 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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