Hi Amit, Thanx for the generous response :)
On Mon, Sep 6, 2010 at 12:58 PM, Amit Kucheria <amit.kuche...@linaro.org> wrote: > > The currently proposed bindings are documented on the DeviceTree wiki[1]. > Please understand that these are Device tree bindings, and it seems that we Okay. This seems more like moving out the current platform regulator bindings to the dtb. Please correct me if I am wrong. > might not need a new framework to track power domains since a lot of the work > is already handled by the regulator framework. Just to be sure, by a power domain, I refer to the domain on a SoC or a CPU. The bindings which I see here are basically regulators on the board. But on most ARM SoCs available like OMAP, U8500, different peripherals are grouped into different power domains aka "SoC regulators". I had a discussion with the regulator maintainers some time ago at http://lkml.org/lkml/2010/5/10/213 Based on the discussion, it felt that the current regulator framework cannot be moderated upon a the SoC power domain types. and hence my curiousity. > What are your interests? The above thread holds most of the discussion that we had. My idea is like - a generic framework that allows modelling of SoC power domains, hoping to integrate both clocks and regulators. There are platforms that dont implement DVS, hence a clock approach makes sense; A DVS only platfom has it easier to implement via regulators and so on. - able to manage dependencies on power domains in terms of constraints from children to parent domains, ability to manage independent power state transitions via specific SoC configurations Also, I am curious about few PM techniques that IMO can be exploited like Run time OPP management for peripherals based on use cases; like Hw accelerators that may run at half the voltage/clocking for reduced loads; storage devices running at reduced loads when the overall QoS parameters may signify a power-save mode vs performance mode etc. Please do let me know of your views on the above. Regards, Sundar _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
