From patchwork Mon Jan 11 17:36:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Juri Lelli X-Patchwork-Id: 8007311 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 139BC9F1C0 for ; Mon, 11 Jan 2016 17:38:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2619F20256 for ; Mon, 11 Jan 2016 17:38:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25FA1201EC for ; Mon, 11 Jan 2016 17:38:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933526AbcAKRiA (ORCPT ); Mon, 11 Jan 2016 12:38:00 -0500 Received: from foss.arm.com ([217.140.101.70]:57312 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932704AbcAKRhw (ORCPT ); Mon, 11 Jan 2016 12:37:52 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE1ED606; Mon, 11 Jan 2016 09:37:16 -0800 (PST) Received: from e106622-lin.cambridge.arm.com (e106622-lin.cambridge.arm.com [10.1.208.152]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 7909E3F24D; Mon, 11 Jan 2016 09:37:49 -0800 (PST) From: Juri Lelli To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org, peterz@infradead.org, rjw@rjwysocki.net, viresh.kumar@linaro.org, mturquette@baylibre.com, steve.muckle@linaro.org, vincent.guittot@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, juri.lelli@arm.com, Jonathan Corbet , linux-doc@vger.kernel.org Subject: [RFC PATCH 19/19] cpufreq: documentation: document locking scheme Date: Mon, 11 Jan 2016 17:36:00 +0000 Message-Id: <1452533760-13787-20-git-send-email-juri.lelli@arm.com> X-Mailer: git-send-email 2.2.2 In-Reply-To: <1452533760-13787-1-git-send-email-juri.lelli@arm.com> References: <1452533760-13787-1-git-send-email-juri.lelli@arm.com> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP CPUFreq locking scheme is quite complicated. Provide some initial documentation for it. Cc: Jonathan Corbet Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linux-doc@vger.kernel.org Signed-off-by: Juri Lelli --- Documentation/cpu-freq/core.txt | 44 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index ba78e7c..1838976 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -21,6 +21,7 @@ Contents: 1. CPUFreq core and interfaces 2. CPUFreq notifiers 3. CPUFreq Table Generation with Operating Performance Point (OPP) +4. CPUFreq locking scheme for internal data structures 1. General Information ======================= @@ -118,3 +119,46 @@ dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with addition to CONFIG_PM_OPP. dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table + +4. CPUFreq locking scheme for internal data structures +====================================================== +CPUFreq locking scheme has to guarantee ordering and mutual exclusion on +internal data structures while concurrent execution of CPU hotplug, OPP +selection, governor changes and driver changes might happen. + +Data structures depicted in the following diagram (except policyX data +structures, see below) are protected by cpufreq_ driver_lock RWLOCK (see +beginning of cpufreq.c). + + cpufreq_driver -> struct cpufreq_driver + + cpufreq_cpu_data (per-CPU) + + +---+---+---+ +---+ + | 0 | 1 | 2 | .. |N-1| + +-+-+-+-+-+-+ +-+-+ + | | | | + |---+ +--------+ + | | + | | + V V + cpufreq_policy_list --> policy0 -- .. -> policy(N-1)-+ + | + x + +Concurrent reads/updates of policyX data structures are guarded by policy-> +rwsem. The rules for this semaphore are (as also reported in include/linux/ +cpufreq.h): + + - any routine that wants to read from the policy structure will + do a down_read on this semaphore; + - any routine that will write to the policy structure and/or may take away + the policy altogether (eg. CPU hotplug), will hold this lock in write + mode before doing so. + +We then have another list that keeps track of available governors and that is +protected by cpufreq_governor_mutex MUTEX: + + cpufreq_governor_list --> governor0 -- .. --> governor(N-1) -+ + | + x