From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759616AbdLSNsV (ORCPT ); Tue, 19 Dec 2017 08:48:21 -0500 Received: from lelnx194.ext.ti.com ([198.47.27.80]:27786 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbdLSNsQ (ORCPT ); Tue, 19 Dec 2017 08:48:16 -0500 Subject: Re: [PATCH v3 4/5] ARM: davinci: convert to common clock framework To: David Lechner , CC: Kevin Hilman , References: <1512785711-15064-1-git-send-email-david@lechnology.com> <1512785711-15064-5-git-send-email-david@lechnology.com> From: Sekhar Nori Message-ID: Date: Tue, 19 Dec 2017 19:17:13 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1512785711-15064-5-git-send-email-david@lechnology.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Saturday 09 December 2017 07:45 AM, David Lechner wrote: > This converts the clocks in mach-davinci to the common clock framework. > > Most of the patch just involves renaming struct clk to struct davinci_clk. > There is also a struct clk_hw added to provide the bridge between the > existing clock implementation and the common clock framework. > > The clk_get_parent and clk_set_parent callbacks are dropped because all > clocks currently (effectivly) have a single parent, in which case the > common clock framework does not want you to implement these functions > yourself. > > clk_unregister() is dropped because it is not used anywhere in > mach-davinci. > > EXPORT_SYMBOL() is removed from functions not used outside of mach-davinci. > > Fixed checkpatch.pl warning about bare use of unsigned in dump_clock(). > > Signed-off-by: David Lechner The cleanups leading upto this patch look fine, but I am not sure about this patch itself. Ideally, we should have moved to drivers/clk also. And shared code with keystone too since the PSC and PLL implementations of the two architectures are quite similar. I could think of this as an intermediate step while we get there, but I am afraid of the churn that would cause. For example, if we reuse keystone driver, we will be using clk_psc and we can get rid of the davinci_clk that this patch introduces. So unless there is big roadblock to moving to drivers/clk, we should probably do that in one shot. Thanks, Sekhar