Received: by 10.213.65.68 with SMTP id h4csp211148imn; Fri, 23 Mar 2018 03:00:33 -0700 (PDT) X-Google-Smtp-Source: AG47ELv1N8GqXcemaNXymV4DOTs5vmeCRdCM6jBAgdx4ToZ8TTjSPN3evMwAvgoCRtvh9uDCLk0y X-Received: by 10.101.69.76 with SMTP id x12mr13934393pgr.63.1521799233911; Fri, 23 Mar 2018 03:00:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521799233; cv=none; d=google.com; s=arc-20160816; b=hbjFBhc0voHkV2G5ovXOGTRYWf69wg+fJDjFh7ksBPp2vnicuIPbn5mbJNdy7ix13J jvuTZA+sBkF2yZWzYDrZ7tIciEBI6C/YM8azRR++Yt6Swak21goBQ4bpc0cf1hL9Mqqo Ruh6vl0LwiV5hkVwjhT2L13Me1btjnGEw7PmYCkaXSOf5X5uNMpuGOeeET+W+zXTyP3g rRIphocF6KvnUurEeN97apusNdxqnsCVlQLaG16wYwskHenf6m4vX8U5cMzW36duFKs9 h1zMxvxTLEPrPQDTJi/yuu+SD+OYfnWW6dqa5AwaM3ttg+3lTFGs7G18zKaDwtp7UxFU ZMZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=HntS00pjMPRWvUU2GFyhhNoIcGONKNzLo7KZK0Z6BrY=; b=olYDT6Vk8H05NGZH2+hdf+L47b36m0U6X65h4sLshYMktXUUZNru+DgO9DMV6FqYaq 2lXwHUyd5NkT9lGH+5kghiFVmoh5IWLOqXOIECv+aZ9gbFH6HpH1FQGFpyFFg2vUMGU2 AMIHQUY02Ho1svwuxDXDoE/l7RBrAWJnHydCVRE6Sfo4x6atHrbZiqPVr//B542hI/On bQ+eTSQQJHAelTaFhf4VPDBZ30qjqKYsJsmrWk4yIixLnIsl6ivKjfx90uTQZC8BD95q 0sE2dz+wyN8ehi51VmAaOgomEG2m8hcKHBQDJMmAKCARULUxRmPP/wH5qYaz80G2WIa1 bqXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 22si5820491pgg.390.2018.03.23.03.00.18; Fri, 23 Mar 2018 03:00:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753282AbeCWJ7I (ORCPT + 99 others); Fri, 23 Mar 2018 05:59:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:35948 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752446AbeCWJ7C (ORCPT ); Fri, 23 Mar 2018 05:59:02 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 55CBF134B; Fri, 23 Mar 2018 09:59:01 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Walleij , Quentin Schulz , Maxime Ripard , Michael Turquette , Jerome Brunet , Sasha Levin Subject: [PATCH 4.15 57/84] clk: use round rate to bail out early in set_rate Date: Fri, 23 Mar 2018 10:54:11 +0100 Message-Id: <20180323095420.613871629@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323095411.913234798@linuxfoundation.org> References: <20180323095411.913234798@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jerome Brunet [ Upstream commit ca5e089a32c5ffba6c5101fdabdd6dea18041c34 ] The current implementation of clk_core_set_rate_nolock() bails out early if the requested rate is exactly the same as the one set. It should bail out if the request would not result in a rate a change. This is important when the rate is not exactly what is requested, which is fairly common with PLLs. Ex: provider able to give any rate with steps of 100Hz - 1st consumer request 48000Hz and gets it. - 2nd consumer request 48010Hz as well. If we were to perform the usual mechanism, we would get 48000Hz as well. The clock would not change so there is no point performing any checks to make sure the clock can change, we know it won't. This is important to prepare the addition of the clock protection mechanism Acked-by: Linus Walleij Tested-by: Quentin Schulz Tested-by: Maxime Ripard Acked-by: Michael Turquette Signed-off-by: Jerome Brunet Signed-off-by: Michael Turquette Link: lkml.kernel.org/r/20171201215200.23523-6-jbrunet@baylibre.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/clk/clk.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1642,16 +1642,37 @@ static void clk_change_rate(struct clk_c clk_pm_runtime_put(core); } +static unsigned long clk_core_req_round_rate_nolock(struct clk_core *core, + unsigned long req_rate) +{ + int ret; + struct clk_rate_request req; + + lockdep_assert_held(&prepare_lock); + + if (!core) + return 0; + + clk_core_get_boundaries(core, &req.min_rate, &req.max_rate); + req.rate = req_rate; + + ret = clk_core_round_rate_nolock(core, &req); + + return ret ? 0 : req.rate; +} + static int clk_core_set_rate_nolock(struct clk_core *core, unsigned long req_rate) { struct clk_core *top, *fail_clk; - unsigned long rate = req_rate; + unsigned long rate; int ret = 0; if (!core) return 0; + rate = clk_core_req_round_rate_nolock(core, req_rate); + /* bail early if nothing to do */ if (rate == clk_core_get_rate_nolock(core)) return 0; @@ -1660,7 +1681,7 @@ static int clk_core_set_rate_nolock(stru return -EBUSY; /* calculate new rates and get the topmost changed clock */ - top = clk_calc_new_rates(core, rate); + top = clk_calc_new_rates(core, req_rate); if (!top) return -EINVAL;