Re: [PATCH 0/1] Group and resource assignments for TWL4030
* David Brownell davi...@pacbell.net [090303 15:38]: On Friday 27 February 2009, Tony Lindgren wrote: * Peter 'p2' De Schrijver peter.de-schrij...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Group and resource assignments for TWL4030
On Wed, Mar 04, 2009 at 12:38:16AM +0100, ext David Brownell wrote: On Friday 27 February 2009, Tony Lindgren wrote: * Peter 'p2' De Schrijver peter.de-schrij...@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? Depends on the board. We use P3 to control the system oscillator. The SYSCLK_REQ output of OMAP3 is wired to the CLKREQ input on the TWL4030. OMAP3 will disable SYSCLK_REQ when the system clock is no longer necessary. (Eg, when going to chip retention). This obviously only works if CLKEN is only in P3. (Otherwise it won't be turned off as P1 is still active). A similar setup is used on the TI SDP3430 board. Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Group and resource assignments for TWL4030
* Peter 'p2' De Schrijver peter.de-schrij...@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. BTW, this should be discussed and integrated via the driver lists, in this case that's Samuel Ortiz and LKML. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Group and resource assignments for TWL4030
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. Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Group and resource assignments for TWL4030
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)? I'd sort of like to stick to simplifying assumptions, notably only P1 matters, until we have a clear need to switch to another one. This sort of thing ties into some patches I have floating around, to disable regulators turned on inappropriately by the boot loader. I was doing that in a late_initcall in the regulator driver ... but it's a bit messy, as the regulator framework has deficiencies in that area (too). - dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
