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. - Dave -- 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
