From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris.brezillon@free-electrons.com (Boris BREZILLON) Date: Wed, 14 May 2014 09:30:59 +0200 Subject: [PATCH v3 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support In-Reply-To: <20140514005119.16152.19787@quantum> References: <1399633911-7094-1-git-send-email-boris.brezillon@free-electrons.com> <1399633911-7094-6-git-send-email-boris.brezillon@free-electrons.com> <20140514005119.16152.19787@quantum> Message-ID: <53731BB3.4060504@free-electrons.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Mike, On 14/05/2014 02:51, Mike Turquette wrote: > Quoting Boris BREZILLON (2014-05-09 04:11:49) >> +struct clk_ops ar100_ops = { >> + .recalc_rate = ar100_recalc_rate, >> + .determine_rate = ar100_determine_rate, >> + .set_parent = ar100_set_parent, >> + .get_parent = ar100_get_parent, >> + .set_rate = ar100_set_rate, >> +}; > I might be having a brain fart, but is there a valid case for having > both a .recalc_rate and a .determine_rate? I believe that the former > will never be used and the latter will always be used by the clock > framework core. I think you're mistaking recalc_rate for round_rate. AFAIK, recalc_rate is mandatory for a clk that implement either round_rate or determine_rate. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris BREZILLON Subject: Re: [PATCH v3 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support Date: Wed, 14 May 2014 09:30:59 +0200 Message-ID: <53731BB3.4060504@free-electrons.com> References: <1399633911-7094-1-git-send-email-boris.brezillon@free-electrons.com> <1399633911-7094-6-git-send-email-boris.brezillon@free-electrons.com> <20140514005119.16152.19787@quantum> Reply-To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20140514005119.16152.19787@quantum> List-Post: , List-Help: , List-Archive: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Subscribe: , List-Unsubscribe: , To: Mike Turquette , =?UTF-8?B?RW1pbGlvIEzDs3Bleg==?= , Samuel Ortiz , Lee Jones Cc: Chen-Yu Tsai , Maxime Ripard , Philipp Zabel , Shuge , kevin-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org, Hans de Goede , Randy Dunlap , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dev-3kdeTeqwOZ9EV1b7eY7vFQ@public.gmane.org List-Id: devicetree@vger.kernel.org Hello Mike, On 14/05/2014 02:51, Mike Turquette wrote: > Quoting Boris BREZILLON (2014-05-09 04:11:49) >> +struct clk_ops ar100_ops = { >> + .recalc_rate = ar100_recalc_rate, >> + .determine_rate = ar100_determine_rate, >> + .set_parent = ar100_set_parent, >> + .get_parent = ar100_get_parent, >> + .set_rate = ar100_set_rate, >> +}; > I might be having a brain fart, but is there a valid case for having > both a .recalc_rate and a .determine_rate? I believe that the former > will never be used and the latter will always be used by the clock > framework core. I think you're mistaking recalc_rate for round_rate. AFAIK, recalc_rate is mandatory for a clk that implement either round_rate or determine_rate. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbaENHbU (ORCPT ); Wed, 14 May 2014 03:31:20 -0400 Received: from top.free-electrons.com ([176.31.233.9]:44176 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752295AbaENHbN (ORCPT ); Wed, 14 May 2014 03:31:13 -0400 Message-ID: <53731BB3.4060504@free-electrons.com> Date: Wed, 14 May 2014 09:30:59 +0200 From: Boris BREZILLON User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Mike Turquette , =?UTF-8?B?RW1pbGlvIEzDs3Bleg==?= , Samuel Ortiz , Lee Jones CC: Chen-Yu Tsai , Maxime Ripard , Philipp Zabel , Shuge , kevin@allwinnertech.com, Hans de Goede , Randy Dunlap , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dev@linux-sunxi.org Subject: Re: [PATCH v3 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support References: <1399633911-7094-1-git-send-email-boris.brezillon@free-electrons.com> <1399633911-7094-6-git-send-email-boris.brezillon@free-electrons.com> <20140514005119.16152.19787@quantum> In-Reply-To: <20140514005119.16152.19787@quantum> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mike, On 14/05/2014 02:51, Mike Turquette wrote: > Quoting Boris BREZILLON (2014-05-09 04:11:49) >> +struct clk_ops ar100_ops = { >> + .recalc_rate = ar100_recalc_rate, >> + .determine_rate = ar100_determine_rate, >> + .set_parent = ar100_set_parent, >> + .get_parent = ar100_get_parent, >> + .set_rate = ar100_set_rate, >> +}; > I might be having a brain fart, but is there a valid case for having > both a .recalc_rate and a .determine_rate? I believe that the former > will never be used and the latter will always be used by the clock > framework core. I think you're mistaking recalc_rate for round_rate. AFAIK, recalc_rate is mandatory for a clk that implement either round_rate or determine_rate. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com