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, 21 Jun 2012 11:58:42 +0530 Message-ID: <4FE2BF1A.308@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> <4FD03C3F.5000707@ti.com> <20120620113933.GF12766@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from na3sys009aog102.obsmtp.com ([74.125.149.69]:50201 "EHLO na3sys009aog102.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753266Ab2FUG2v (ORCPT ); Thu, 21 Jun 2012 02:28:51 -0400 Received: by obcva7 with SMTP id va7so502943obc.34 for ; Wed, 20 Jun 2012 23:28:48 -0700 (PDT) In-Reply-To: <20120620113933.GF12766@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 On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote: > * Rajendra Nayak [120606 22:33]: >> 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. > > We should sort out those issues, sounds like we're missing few > interfaces.. > >> -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/ > > Well the PM code should be a loadable module using standard driver > interfaces.. Maybe all it takes is adding few functions that both > drivers/clk and mach-omap2 code can use without exposing all the registers? > Then we may have a better idea what infrastructure pieces are missing. > >> -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/ > > Maybe clockdomains could be also handled with some functions without > exposing all the registers in the headers? Is moving some of the mach-omap2 headers into mach/include and plat/include and using them in drivers/clk/omap an acceptable first step? I see both the other architectures (imx and spear) in drivers/clk already doing it. > > Tony