From patchwork Tue Jan 29 01:55:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 10785329 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1860713B5 for ; Tue, 29 Jan 2019 01:56:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0B3C92AC4E for ; Tue, 29 Jan 2019 01:56:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EDE022AEAA; Tue, 29 Jan 2019 01:56:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A16FA2AD5E for ; Tue, 29 Jan 2019 01:56:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727237AbfA2Bzw (ORCPT ); Mon, 28 Jan 2019 20:55:52 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:43889 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727163AbfA2Bzv (ORCPT ); Mon, 28 Jan 2019 20:55:51 -0500 Received: by mail-pg1-f194.google.com with SMTP id v28so8043663pgk.10 for ; Mon, 28 Jan 2019 17:55:51 -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:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZVULfzxWVElJMCwq1wy/pfgTajaNanG7YoLpOBVV2Xo=; b=jUKaesuMBcYZs2+V6aDk92VljfYqtRok693G/qZFfl7LLib7eOX9EsdPkuvDmPwBD9 0p+lqTRD9sHxAwAsOyUz7Jp3//WGeHbP4N3NWVWRZ5e2d42FCl6C+HvXkmf5prgHUOzr ZWIjSdzdaHege2yn2EYC65iy3/es1opNulvLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZVULfzxWVElJMCwq1wy/pfgTajaNanG7YoLpOBVV2Xo=; b=hGmrbfCgURah2cG6OSDIiis/UttY6kI6A8QuCZg8khEAmcdQBgvQy6GI4745KAi7MX zIvikaB/Du4VaPc4pto59KCf5SqN/wzmzbo+wEA+tORwyGsp2xG+i/BCRO+yRHVHl9St zZN33u/UWIj1+NDvZc8OXBBK5cddDVnaA/yhOJO3XCHENhqwQHihYRlcYLJ5yJw8pRZM OHBQODUjK45IAiq/bnGO70hEexyTb93QS9Jtm1KTdc7GHalyXvquW75KBITtAqYiL76m CFfonacSZvtIiszT3MzPv76TmDu3IQoujKLisPBe7vr7VY+z9Zi37PMejLMR+B7FyIs0 26cg== X-Gm-Message-State: AJcUukcO8zpuJGgvwHeYwIUpoV4lyW8JnXzOGFS5yMMzMMxduTjiMwDr u60f39MNTiYksQ7N5xc6OVW2qw== X-Google-Smtp-Source: ALg8bN4/xhmNqo5oaO4yiUUgEZkYF+UDzSOc37IkGAuSgTn9HIiVfMbpXgm91YkxZlFAgB94vBt5AQ== X-Received: by 2002:a63:86c1:: with SMTP id x184mr21780233pgd.305.1548726950808; Mon, 28 Jan 2019 17:55:50 -0800 (PST) Received: from smtp.gmail.com ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id g15sm142911530pfj.131.2019.01.28.17.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 17:55:49 -0800 (PST) From: Stephen Boyd To: linux-kernel@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, linux-serial@vger.kernel.org, linux-spi@vger.kernel.org, Rajendra Nayak , Ulf Hansson , Viresh Kumar , Doug Anderson Subject: [RFC/PATCH 1/5] OPP: Don't overwrite rounded clk rate Date: Mon, 28 Jan 2019 17:55:43 -0800 Message-Id: <20190129015547.213276-2-swboyd@chromium.org> X-Mailer: git-send-email 2.20.1.495.gaa96b0ce6b-goog In-Reply-To: <20190129015547.213276-1-swboyd@chromium.org> References: <20190129015547.213276-1-swboyd@chromium.org> MIME-Version: 1.0 Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Doing this allows us to call this API with any rate requested and have it not need to match in the OPP table. Instead, we'll round the rate up to the nearest OPP that we see so that we can get the voltage or level that's required for that OPP. This supports users of OPP that want to specify the 'fmax' tables of a device instead of every single frequency that they need. And for devices that required the exact frequency, we can rely on the clk framework to round the rate to the nearest supported frequency instead of the OPP framework to do so. Note that this may affect drivers that don't want the clk framework to do rounding, but instead want the OPP table to do the rounding for them. Do we have that case? Should we add some flag to the OPP table to indicate this and then not have that flag set when there isn't an OPP table for the device and also introduce a property like 'opp-use-clk' to tell the table that it should use the clk APIs to round rates instead of OPP? Signed-off-by: Stephen Boyd --- drivers/opp/core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/opp/core.c b/drivers/opp/core.c index e06a0ab05ad6..b6516d623c5a 100644 --- a/drivers/opp/core.c +++ b/drivers/opp/core.c @@ -704,7 +704,7 @@ static int _set_required_opps(struct device *dev, int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq) { struct opp_table *opp_table; - unsigned long freq, old_freq; + unsigned long freq, opp_freq, old_freq, old_opp_freq; struct dev_pm_opp *old_opp, *opp; struct clk *clk; int ret; @@ -743,13 +743,15 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq) goto put_opp_table; } - old_opp = _find_freq_ceil(opp_table, &old_freq); + old_opp_freq = old_freq; + old_opp = _find_freq_ceil(opp_table, &old_opp_freq); if (IS_ERR(old_opp)) { dev_err(dev, "%s: failed to find current OPP for freq %lu (%ld)\n", __func__, old_freq, PTR_ERR(old_opp)); } - opp = _find_freq_ceil(opp_table, &freq); + opp_freq = freq; + opp = _find_freq_ceil(opp_table, &opp_freq); if (IS_ERR(opp)) { ret = PTR_ERR(opp); dev_err(dev, "%s: failed to find OPP for freq %lu (%d)\n",