From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rajendra Nayak Subject: Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk Date: Thu, 07 Jun 2012 10:59:35 +0530 Message-ID: <4FD03C3F.5000707@ti.com> References: <1338552485-31325-1-git-send-email-rnayak@ti.com> <1338552485-31325-14-git-send-email-rnayak@ti.com> <20120605064250.GC12766@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from na3sys009aog101.obsmtp.com ([74.125.149.67]:33833 "EHLO na3sys009aog101.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752420Ab2FGF3n (ORCPT ); Thu, 7 Jun 2012 01:29:43 -0400 Received: by obbwd20 with SMTP id wd20so434428obb.4 for ; Wed, 06 Jun 2012 22:29:41 -0700 (PDT) In-Reply-To: <20120605064250.GC12766@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: mturquette@ti.com, paul@pwsan.com, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: > * Rajendra Nayak [120601 05:13]: >> The data is autogenerated using the OMAP autogeneration scripts (python >> scripts). Thanks to Mike Turquette for the initial efforts in updating >> the script which was later updated by me. >> All data is added into a new cclock44xx_data.c file, a later patch will get >> rid of clock44xx_data.c file. >> >> Signed-off-by: Rajendra Nayak >> --- >> arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++++++++++++++++++++++++++++++ >> arch/arm/mach-omap2/clock.h | 17 + >> arch/arm/mach-omap2/clock_common_data.c | 14 + >> arch/arm/mach-omap2/scrm44xx.h | 2 + >> 4 files changed, 2635 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c > > If you are adding new data anyways, why not add it to drivers/clock/omap > to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ regards, Rajendra > > Regards, > > Tony