Re: [PATCH 0/1] Group and resource assignments for TWL4030

[Tony Lindgren <tony@atomide.com>]

* David Brownell <david-b@pacbell.net> [090303 15:38]:
> On Friday 27 February 2009, Tony Lindgren wrote:
> > * Peter 'p2' De Schrijver <peter.de-schrijver@nokia.com> [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