From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753680AbcHPNvU (ORCPT ); Tue, 16 Aug 2016 09:51:20 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:42890 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753246AbcHPNvR (ORCPT ); Tue, 16 Aug 2016 09:51:17 -0400 X-AuditID: cbfec7f5-f792a6d000001302-56-57b31a5127b7 Subject: Re: [RFC 00/17] clk: Add per-controller locks to fix deadlocks To: Michael Turquette , Stephen Boyd , Stephen Warren , Lee Jones , Eric Anholt , Florian Fainelli , Ray Jui , Scott Branden , bcm-kernel-feedback-list@broadcom.com, Sylwester Nawrocki , Tomasz Figa , Kukjin Kim , Russell King , Mark Brown , linux-clk@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-i2c@vger.kernel.org, alsa-devel@alsa-project.org References: <1471354514-24224-1-git-send-email-k.kozlowski@samsung.com> Cc: Marek Szyprowski , Charles Keepax , Javier Martinez Canillas , a.hajda@samsung.com, Bartlomiej Zolnierkiewicz From: Krzysztof Kozlowski X-Enigmail-Draft-Status: N1110 Message-id: <65703100-1e16-6c34-babe-40e630180688@samsung.com> Date: Tue, 16 Aug 2016 15:51:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: <1471354514-24224-1-git-send-email-k.kozlowski@samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3euLhenOe1FyWoQRaZmhrxESSjVwS4UWZYJtuyg1qZzy8i+ ZIKZq2lali0DTUex0tlmYYNEp5XL24axzHImXsrSjTCj7LoLkd/+l9/D/8tDY8JZPJjOzDrJ KbIkUjHJx7t+P7eH7w02Jq2z/1iOBht6CfTSZuahB5V6AtWrn+KoYmSMRL+vDlCo9Vw/QHPO DgpNTd/noU8folDp6CcMNZ+vwZFh1E6gz5ccBLrw6wtA/aYqEpW9aaRQZV8LD5krngBU3zFE IduLrWj8hpFE7VNFBPrWfRFHzntjAH1sO48jnekn2BLCNs4UkGyB6xnJ9tttGOsaKKRYzXCP 25aoeexjzRDFGnTFJGusO8tOlv0g2aZSd1TSpAPsjCGUfXBr/55FyfxNxzhp5ilOERl7hJ9R 6FABudP/tMsyQeSDOr4K+NGQ2QBbXr8DPh0ErQ49qQJ8WshoAbymr6d8ZgJA64iW8FABzHb4 6n2zlxIx3wlo/mX0ngvdhUVfhHsKjJkEsMcyx/MUJBMNjXfqSN9GKFRfLMc9WsDEwl5TgTfH mZXQdLfBuxDIHISDus/AxyyG3644vLwfw8Je6zlMBWj3QAQctq3xxBizDBrvT2OXwWLNvAvN f0ozj6oGmA4EcrlpcuXRdNn6CKVEpszNSo9Iy5YZgO8ZZpuB9tlGM2BoIPYXdC4wJAkJySll nswMII2JRYL2QGOSUHBMkneGU2SnKnKlnNIMQmhcvERww+RKFDLpkpPcCY6Tc4p/LY/2C84H hVPRcZHBO1WN0tjhPOH7h0GWgfLa1IjaHK2qJvWR0Ha7ai3v+mbRdFRQdqd+oaWvK7w7YESw FJaqqZiU8R2J8tXynEXx2+68DQvMbHOkhSWKYqy7F+yT5LfeTImLrLRc+EOFFW+uLubFd1Ca uwmHdm10rkhY9fVwcsCc68BxJyHGlRmSqDWYQin5C+DQn0IIAwAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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