From patchwork Mon Dec 2 05:34:14 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 3263671 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.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1249B9F373 for ; Mon, 2 Dec 2013 05:35:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CE6FD2026C for ; Mon, 2 Dec 2013 05:34:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DA2F220263 for ; Mon, 2 Dec 2013 05:34:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752884Ab3LBFen (ORCPT ); Mon, 2 Dec 2013 00:34:43 -0500 Received: from mail-qa0-f54.google.com ([209.85.216.54]:62677 "EHLO mail-qa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752840Ab3LBFea (ORCPT ); Mon, 2 Dec 2013 00:34:30 -0500 Received: by mail-qa0-f54.google.com with SMTP id f11so3973571qae.6 for ; Sun, 01 Dec 2013 21:34:29 -0800 (PST) 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:in-reply-to :references:in-reply-to:references; bh=wrCTSlgdX/JjLmNWzUkp3uWb9ltVeS7smo+twYMCzCQ=; b=DFhKBzPsadwnzRCc7hwGTx0XhaT+5M8c4EZsPAx6n7TAgAV8SBfTdecB559Mhii1b7 sknrzdG/0f/TjBXtAWP/ilXFr+EWrc4R25ZlQpdK+IlG5Ulv2y4Yzo26XkZKVpz8Mo+1 x53o8BoQElIE0GHtkBAV2NQAOpM48IH/3ZDJlcyrlj7/XP/h3yxNabIOUkLHhz3ofWOr 3HUQ8vwqGBrYBK2cnUmFwfRzcLt6DOjGh+jIwepFyRXYiiwqil5OwQEqD8S9vtMVAA8U qSfDunW7qynn0BiGfjM1s4czq8e5Fj3aZChluAyD7bdAs8YR7jLZ/CkQNBId2FlAHWOY sGjA== X-Gm-Message-State: ALoCoQmWwYvM0f6pwvs0AVbR0w+Vaq62Bs/Yn+G1D3byD4/MfXXrjePhvK8ZDqwdF+QBx1rzUr3I X-Received: by 10.49.131.5 with SMTP id oi5mr68928154qeb.38.1385962469382; Sun, 01 Dec 2013 21:34:29 -0800 (PST) Received: from localhost (git.linaro.org. [54.235.93.228]) by mx.google.com with ESMTPSA id p20sm151057567qay.0.2013.12.01.21.34.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 01 Dec 2013 21:34:28 -0800 (PST) From: Viresh Kumar To: rjw@rjwysocki.net Cc: linaro-kernel@lists.linaro.org, patches@linaro.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Viresh Kumar Subject: [PATCH V2 3/5] cpufreq: pcc: send new set of notification for transition failures Date: Mon, 2 Dec 2013 11:04:14 +0530 Message-Id: <3d86feabdc6f223b68a4936c9529b4edec3e39ba.1385962178.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 1.7.12.rc2.18.g61b472e In-Reply-To: References: In-Reply-To: References: 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 In the current code, if we fail during a frequency transition we simply send the POSTCHANGE notification with old frequency. This isn't enough. One of the core user of these notifications is the code responsible for keeping loops_per_jiffy aligned with frequency change. And mostly it is written as: if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) || (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) { update-loops-per-jiffy... } So, suppose we are changing to a higher frequency and failed during transition, then following will happen: - CPUFREQ_PRECHANGE notification with freq-new > freq-old - CPUFREQ_POSTCHANGE notification with freq-new == freq-old The first one will update loops_per_jiffy and second one will do nothing. Even if we send the 2nd notification by exchanging values of freq-new and old, some users of these notifications might get unstable. This can be fixed by simply calling cpufreq_notify_post_transition() with error code and this routine will take care of sending notifications in correct order. Also it fills freqs.old before starting the first notification, this was missing since ever. Signed-off-by: Viresh Kumar --- drivers/cpufreq/pcc-cpufreq.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c index e2b4f40..1c0f106 100644 --- a/drivers/cpufreq/pcc-cpufreq.c +++ b/drivers/cpufreq/pcc-cpufreq.c @@ -213,6 +213,7 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy, cpu, target_freq, (pcch_virt_addr + pcc_cpu_data->input_offset)); + freqs.old = policy->cur; freqs.new = target_freq; cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); @@ -228,25 +229,20 @@ static int pcc_cpufreq_target(struct cpufreq_policy *policy, memset_io((pcch_virt_addr + pcc_cpu_data->input_offset), 0, BUF_SZ); status = ioread16(&pcch_hdr->status); + iowrite16(0, &pcch_hdr->status); + + cpufreq_notify_post_transition(policy, &freqs, status != CMD_COMPLETE); + spin_unlock(&pcc_lock); + if (status != CMD_COMPLETE) { pr_debug("target: FAILED for cpu %d, with status: 0x%x\n", cpu, status); - goto cmd_incomplete; + return -EINVAL; } - iowrite16(0, &pcch_hdr->status); - cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); pr_debug("target: was SUCCESSFUL for cpu %d\n", cpu); - spin_unlock(&pcc_lock); return 0; - -cmd_incomplete: - freqs.new = freqs.old; - cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); - iowrite16(0, &pcch_hdr->status); - spin_unlock(&pcc_lock); - return -EINVAL; } static int pcc_get_offset(int cpu)