* David Brownell <david-b@xxxxxxxxxxx> [090303 15:38]: > On Friday 27 February 2009, Tony Lindgren wrote: > > * Peter 'p2' De Schrijver <peter.de-schrijver@xxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
