From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754031Ab2CTRqQ (ORCPT ); Tue, 20 Mar 2012 13:46:16 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:27418 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752837Ab2CTRqM (ORCPT ); Tue, 20 Mar 2012 13:46:12 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6654"; a="174123420" Message-ID: In-Reply-To: <20120320140220.GE32469@S2101-09.ap.freescale.net> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <1331878280-2758-3-git-send-email-mturquette@linaro.org> <20120320140220.GE32469@S2101-09.ap.freescale.net> Date: Tue, 20 Mar 2012 10:46:11 -0700 (PDT) Subject: Re: [PATCH v7 2/3] clk: introduce the common clock framework From: "Saravana Kannan" To: "Shawn Guo" Cc: "Mike Turquette" , "Russell King" , "Paul Walmsley" , "Linus Walleij" , patches@linaro.org, "Stephen Boyd" , "Sascha Hauer" , "Mark Brown" , "Magnus Damm" , linux-kernel@vger.kernel.org, "Saravana Kannan" , linaro-dev@lists.linaro.org, "Jeremy Kerr" , "Arnd Bergman" , linux-arm-kernel@lists.infradead.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Priority: 3 (Normal) Importance: Normal Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, March 20, 2012 7:02 am, Shawn Guo wrote: > On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: > ... >> +struct clk_ops { >> + int (*prepare)(struct clk_hw *hw); >> + void (*unprepare)(struct clk_hw *hw); >> + int (*enable)(struct clk_hw *hw); >> + void (*disable)(struct clk_hw *hw); >> + int (*is_enabled)(struct clk_hw *hw); >> + unsigned long (*recalc_rate)(struct clk_hw *hw, >> + unsigned long parent_rate); > > I believe I have heard people love the interface with parent_rate > passed in. I love that too. But I would like to ask the same thing > on .round_rate and .set_rate as well for the same reason why we have > it for .recalc_rate. In my case, for most clocks, set rate involves reparenting. So, what does passing parent_rate for these even mean? Passing parent_rate seems more apt for recalc_rate since it's called when the parent rate changes -- so, the actual parent itself is not expected to change. I could ignore the parameter, but just wondering how many of the others see value in this. And if we do add this parameter, it shouldn't be made mandatory for the platform driver to use it (due to other assumptions the clock framework might make). -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 From: skannan@codeaurora.org (Saravana Kannan) Date: Tue, 20 Mar 2012 10:46:11 -0700 (PDT) Subject: [PATCH v7 2/3] clk: introduce the common clock framework In-Reply-To: <20120320140220.GE32469@S2101-09.ap.freescale.net> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <1331878280-2758-3-git-send-email-mturquette@linaro.org> <20120320140220.GE32469@S2101-09.ap.freescale.net> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, March 20, 2012 7:02 am, Shawn Guo wrote: > On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote: > ... >> +struct clk_ops { >> + int (*prepare)(struct clk_hw *hw); >> + void (*unprepare)(struct clk_hw *hw); >> + int (*enable)(struct clk_hw *hw); >> + void (*disable)(struct clk_hw *hw); >> + int (*is_enabled)(struct clk_hw *hw); >> + unsigned long (*recalc_rate)(struct clk_hw *hw, >> + unsigned long parent_rate); > > I believe I have heard people love the interface with parent_rate > passed in. I love that too. But I would like to ask the same thing > on .round_rate and .set_rate as well for the same reason why we have > it for .recalc_rate. In my case, for most clocks, set rate involves reparenting. So, what does passing parent_rate for these even mean? Passing parent_rate seems more apt for recalc_rate since it's called when the parent rate changes -- so, the actual parent itself is not expected to change. I could ignore the parameter, but just wondering how many of the others see value in this. And if we do add this parameter, it shouldn't be made mandatory for the platform driver to use it (due to other assumptions the clock framework might make). -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.