From patchwork Wed Dec 24 06:09:48 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 5536431 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id CAA27BEEA8 for ; Wed, 24 Dec 2014 06:11:01 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 00061201BC for ; Wed, 24 Dec 2014 06:11:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 10E9420108 for ; Wed, 24 Dec 2014 06:11:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbaLXGK4 (ORCPT ); Wed, 24 Dec 2014 01:10:56 -0500 Received: from mail-ig0-f178.google.com ([209.85.213.178]:42142 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751417AbaLXGK3 (ORCPT ); Wed, 24 Dec 2014 01:10:29 -0500 Received: by mail-ig0-f178.google.com with SMTP id hl2so6593193igb.5 for ; Tue, 23 Dec 2014 22:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=pJC/drOrAjyZBZZXR57RaFvtfQlPu2BeOj0F1uhHUqc=; b=lFwRBWzdienfc6NUvvEeXrLRAITLGT4sFkSuRwUtKDPntgfygr9EwB19HzHqwmrsmb YWf+FsXFEZOOsnFqfIvYutvt/ZT0sniYwHAlNpF1Gv4BrvDZQt2n1wDmn3HcLIc06jgA H7BsNuFyoFZZUr9zl+VQ4iY6llt620T86UTqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=pJC/drOrAjyZBZZXR57RaFvtfQlPu2BeOj0F1uhHUqc=; b=UitISKOJL5Ti7VpS3ixKeXqjaABiWBNAMlNZjNEikz9mB5mvhqR/D7ZtlgIY1AtSpz k0VsSPcI2rU3KvFOzK5sHUaZ/mX7tdEqanl+eVqCVhasCJ4hUOsPw/8LO9zKac6FT2AV QfQEQGP1VbZ/EApel+bGih2LWbjEG1WvYMJZ9qW5z6CYYy5dlQy1tqWoncH1R6+5/WiM whmBz/vGKbYHwXkAmyqN/QJ0Oduesx/dPm4aj4mYGsaKHzrMgco39Zfs1Hx6eM6L31nR /yn+PGuRGFBGZOJcbr3bKIGSjYXeR79hiz4N6l5vyi83eIHGSuLYSzdjC+ijXNFyXYBY Gs9w== X-Gm-Message-State: ALoCoQnLwZUPDhhmqmGaSiPKziue1SfOFqqej9WiB2EIZ+k122+5jSROz4WCwE4x7HM+m8x0eJSZ X-Received: by 10.50.50.140 with SMTP id c12mr18677011igo.5.1419401426497; Tue, 23 Dec 2014 22:10:26 -0800 (PST) Received: from tictac.mtv.corp.google.com ([172.22.65.76]) by mx.google.com with ESMTPSA id f9sm10945635iod.24.2014.12.23.22.10.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Dec 2014 22:10:25 -0800 (PST) From: Doug Anderson To: rjw@rjwysocki.net, viresh.kumar@linaro.org Cc: Heiko Stuebner , Dmitry Torokhov , Chris Zhong , linux-arm-kernel@lists.infradead.org, Sonny Rao , Dylan Reid , Doug Anderson , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] cpufreq: suspend cpufreq governors on shutdown Date: Tue, 23 Dec 2014 22:09:48 -0800 Message-Id: <1419401388-20171-1-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.2.0.rc0.207.ga3a616c 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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_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 We should stop cpufreq governors when we shut down the system. If we don't do this, we can end up with this deadlock: 1. cpufreq governor may be running on a CPU other than CPU0. 2. In machine_restart() we call smp_send_stop() which stops CPUs. If one of these CPUs was actively running a cpufreq governor then it may have the mutex / spinlock needed to access the main PMIC in the system (perhaps over I2C) 3. If a machine needs access to the main PMIC in order to shutdown then it will never get it since the mutex was lost when the other CPU stopped. 4. We'll hang (possibly eventually hitting the hard lockup detector). Let's avoid the problem by stopping the cpufreq governor at shutdown, which is a sensible thing to do anyway. Signed-off-by: Doug Anderson Acked-by: Viresh Kumar --- Changes in v2: - Add a comment about why we register - Don't create cpufreq_shutdown() wrapper function drivers/cpufreq/cpufreq.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index a09a29c..33f3d65 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -2550,6 +2551,14 @@ int cpufreq_unregister_driver(struct cpufreq_driver *driver) } EXPORT_SYMBOL_GPL(cpufreq_unregister_driver); +/* + * Stop cpufreq at shutdown to make sure it isn't holding any locks + * or mutexes when secondary CPUs are halted. + */ +static struct syscore_ops cpufreq_syscore_ops = { + .shutdown = cpufreq_suspend, +}; + static int __init cpufreq_core_init(void) { if (cpufreq_disabled()) @@ -2558,6 +2567,8 @@ static int __init cpufreq_core_init(void) cpufreq_global_kobject = kobject_create(); BUG_ON(!cpufreq_global_kobject); + register_syscore_ops(&cpufreq_syscore_ops); + return 0; } core_initcall(cpufreq_core_init);