Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751618AbdL0BGl (ORCPT ); Tue, 26 Dec 2017 20:06:41 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:54882 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbdL0BGk (ORCPT ); Tue, 26 Dec 2017 20:06:40 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org E2FBF60398 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Tue, 26 Dec 2017 17:06:38 -0800 From: Stephen Boyd To: Alexander Kochetkov Cc: linux-clk@vger.kernel.org, LKML , LAK , linux-rockchip@lists.infradead.org, Michael Turquette , Heiko Stuebner , Elaine Zhang Subject: Re: [PATCH 1/2] clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and expose Message-ID: <20171227010638.GP7997@codeaurora.org> References: <1513872282-5370-1-git-send-email-al.kochet@gmail.com> <1513872282-5370-2-git-send-email-al.kochet@gmail.com> <20171221200743.GM7997@codeaurora.org> <8EC4D15B-4A89-43FA-953E-95AF81417067@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8EC4D15B-4A89-43FA-953E-95AF81417067@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2187 Lines: 45 On 12/25, Alexander Kochetkov wrote: > > > 21 дек. 2017 г., в 23:07, Stephen Boyd написал(а): > > > > Can you convert to the determine_rate op instead of round_rate? > > That function should tell you the min/max limits so that you > > don't need to query that information from the core. > > I converted rockchip_fractional_approximation() to rockchip_determine_rate() (see the patch attached). > If it increase parent’s clock for out of limits value, than clock request will fail with -EINVAL, like > with round_rate() approach. > > The problem is that min/max limits provided to determine_rate() is for clock for which the determine_rate() > was called. While rockchip_determine_rate() (rockchip_fractional_approximation()) requires information > about parent clock limits. Are these limits the min/max limits that the parent clk can output at? Or the min/max limits that software has constrained on the clk? > > How can I know parents clock limits for current clock? Implement determine_rate() for each parent clocks > the same way I did for this one clock? If the parent can change rate, then the idea is that the child will calculate the limits that it can handle based on what it can do with the incoming min/max constraints, and then call __clk_determine_rate() on its parent with a request structure that has limits for whatever the child clk is able to handle. The parent can then determine a rate it can output that's within that range and tell the child clk if it will satisfy the constraints or not along with the resulting rate it will output when the __clk_determine_rate() function returns. I would expect the constraints to get closer together the higher in the tree we go. I haven't looked in detail at this rockchip_fractional_approximation() code, but it shouldn't be doing the work of both the child rate determination and the parent rate determination in one place. It should work with the parent to figure out the rate the parent can provide and then figure out how to achieve the desired rate from there. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project