From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH 0/1] Group and resource assignments for TWL4030 Date: Thu, 5 Mar 2009 16:16:26 -0800 Message-ID: <20090306001625.GF6784@atomide.com> References: <1234271495-11705-1-git-send-email-peter.de-schrijver@nokia.com> <20090215164851.GA19407@codecarver.research.nokia.com> <20090227165949.GB11594@atomide.com> <200903031538.16757.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-01-bos.mailhop.org ([63.208.196.178]:58132 "EHLO mho-01-bos.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751549AbZCFAQc (ORCPT ); Thu, 5 Mar 2009 19:16:32 -0500 Content-Disposition: inline In-Reply-To: <200903031538.16757.david-b@pacbell.net> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: David Brownell Cc: Peter 'p2' De Schrijver , "linux-omap@vger.kernel.org" * David Brownell [090303 15:38]: > On Friday 27 February 2009, Tony Lindgren wrote: > > * Peter 'p2' De Schrijver [090215 08:49]: > > > On Fri, Feb 13, 2009 at 09:55:21PM +0100, ext David Brownell wrote: > > > > On Tuesday 10 February 2009, Peter 'p2' De Schrijver wrote: > > > > > > > > > > This patch introduces support for board specific group assignments of TWL4030 > > > > > resources. The resource type and type2 fields can also be specified. > > > > > > > > Do we have any real examples yet of needing to assign > > > > resources to anything other than P1 (processor)? > > > > > > Yes. On our custom hardware we use it to assign CLKEN to P3. > > P3 roughly translating to "system running", with > no regard to whether ARM(s) or DSP are active, yes? > > I've seen hardware which hooks CLKEN to the enable > line for a 2.8V regulator, and REGEN to the enable > line for a 2.5V regulator. > > Table 5-8 of the chip manual tells me those, along > with HFCLOCK and a few other resources, are already > assigned to the P3 (and P1 and P2) groups by device > reset. So that use case isn't quite complete. At > least some of this look like normal paranoia, to > defend against hardware and bootloader oddities. ;) > > > I'm not sure how those should be modeled within > the regulator framework. My first thought is to > just let those particular resources live outside > that framework, until there's a need for another > solution ... the main virtue of that framework is > to have a standard way for Linux to manage things, > but these are resources it won't be managing. > The secondary virtue of "visibility into hardware" > isn't very compelling here IMO. > > > > BTW, this should be discussed and integrated via the driver lists, > > in this case that's Samuel Ortiz and LKML. > > Actually this is related to the twl4030-power.c > driver which has not yet gone upstream. I'm not > sure there'd be much point to discussing this on > the PM list though. > > > So let me suggest a slightly different approach: > > - Peter updates $SUBJECT patch to address the > comments from me (data shrink) and Felipe > (use those RES_* symbols in res_config_addrs) > > - Tony merges that to the OMAP tree > > - Peter starts work on merging twl4030-power.c > to mainline (discuss on LKML etc) > > There will be a few more issues to sort with this > driver. There are section warnings generated by > some of the platform code, and the generic script > doesn't work at all on Beagle. This sounds OK to me as long as Peter is fine with that. Tony