From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755003AbbIRP4S (ORCPT ); Fri, 18 Sep 2015 11:56:18 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60867 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754960AbbIRP4O (ORCPT ); Fri, 18 Sep 2015 11:56:14 -0400 Date: Fri, 18 Sep 2015 08:56:12 -0700 From: Stephen Boyd To: Scott Wood Cc: Mike Turquette , linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, Boris Brezillon , Chao Xie , Krzysztof Kozlowski , Javier Martinez Canillas , Tomasz Figa , Maxime Ripard , Emilio =?iso-8859-1?Q?L=F3pez?= , Tero Kristo , Geert Uytterhoeven Subject: Re: [PATCH 02/26] clk: Replace __clk_get_num_parents with clk_hw_get_num_parents() Message-ID: <20150918155612.GY23081@codeaurora.org> References: <1438362246-6664-1-git-send-email-sboyd@codeaurora.org> <1438362246-6664-3-git-send-email-sboyd@codeaurora.org> <1442535513.19102.83.camel@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1442535513.19102.83.camel@freescale.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 On 09/17, Scott Wood wrote: > On Fri, 2015-07-31 at 10:03 -0700, Stephen Boyd wrote: > > Mostly converted with the following semantic patch: > > > > @@ > > struct clk_hw *E; > > @@ > > > > -__clk_get_num_parents(E->clk) > > +clk_hw_get_num_parents(E) > > I don't understand why this is considered a clock provider API. How is a > clock consumer, such as cpufreq, supposed to find out the number of parents > or similar information, so that it knows what its options are for calling > clk_set_parent()? > > This is the caller I had in mind: > http://patchwork.ozlabs.org/patch/507619/ > > Surely asking the clock to describe itself is better than what that cpufreq > driver currently does, which is to look in the device tree and make > assumptions about how that maps to what the clock provider driver does... > All the APIs that were converted were private to the common clock framework and in clk-provider.h, not clk.h. clk.h is the consumer API that's supported by more than just the common clock framework, so whatever we do for the consumer API needs to be put there. For example, we recently added a clk_has_parent() API that can be used to probe for possible parents of a clock. Perhaps we need something else in this case so that consumers can iterate over each parent of a clock? Feel free to suggest a consumer API. Is there any reason why we can't use DT OPPs for the code that you're patching here? At a quick glance it looks like we could leave this driver behind and move to cpufreq-dt.c and then use OPPs to populate the possible frequencies and affinity. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project