From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF56CC433E0 for ; Wed, 27 May 2020 05:55:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 83811208DB for ; Wed, 27 May 2020 05:55:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590558951; bh=PcP0elMmxsxvC2yH2JORrMx/2zoxr/+2rXhvhlQJreI=; h=In-Reply-To:References:Subject:From:Cc:To:Date:List-ID:From; b=l2JQKATt/8bLL9XSbalgpK7GwT/eN3pq9F7mbv0bLbAcW3cdp8kzaVcSSf83yd0lT e6SRdo/85n6FKuyEmwmNoccgIk5scCAoWZVv4Q/IM/+B4wQ48NFlIsblLkzzYV26G3 tiuGpQSsTsDuMLGoDChviK3PJNuX5X2X3/+3XCEg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726963AbgE0Fzv (ORCPT ); Wed, 27 May 2020 01:55:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:44600 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbgE0Fzu (ORCPT ); Wed, 27 May 2020 01:55:50 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2AD90206F1; Wed, 27 May 2020 05:55:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590558950; bh=PcP0elMmxsxvC2yH2JORrMx/2zoxr/+2rXhvhlQJreI=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=OhocTK+Uz/yQpuW5nOGw7pZ64VE+pkmrKgYxsJ2bRR0uxGgVQ2y0o9D4cPASOhtDi BO4Dxh6HPtbHVS6xKrNo17LfFDr5RI1a1n7MSnYtLvgbpoQO6Agjwr3JRq27IRQQnj jTwS8Lc73ngULTpqDPrjBZ6AgWcHKM0PZlKadvBI= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20200330231617.17079-3-digetx@gmail.com> References: <20200330231617.17079-1-digetx@gmail.com> <20200330231617.17079-3-digetx@gmail.com> Subject: Re: [PATCH v1 2/5] clk: Introduce clk_round_rate_unboundly() From: Stephen Boyd Cc: linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org To: Chanwoo Choi , Dmitry Osipenko , Jonathan Hunter , Kyungmin Park , Michael Turquette , MyungJoo Ham , Thierry Reding Date: Tue, 26 May 2020 22:55:49 -0700 Message-ID: <159055894944.88029.2029223648098859689@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Dmitry Osipenko (2020-03-30 16:16:14) > In same cases it may be desired to round clock's rate without taking into > account current min/max requests made by the clock's users. One example is > building up OPP table based on a possible clock rates. Shouldn't the OPP table come from firmware/DT? I don't quite understand why we're generating OPP tables on top of the rate rounding API. clk_round_rate() is supposed to tell us what rate we'll get if we call clk_set_rate() with the same arguments. An unboundly version of that doesn't make sense.=20 I wonder if perhaps the clk provider should be populating OPP tables in this case? Or basically anything besides adding another clk consumer API to solve this problem. Who is the caller? Something later in this series?