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

[David Brownell <david-b@pacbell.net>]

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.

- Dave