Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
Hi Amit, I am new here; so please bear with my questions/doubts :) On Wed, Feb 22, 2012 at 3:44 PM, Amit Daniel Kachhap wrote: > This patch adds support for generic cpu thermal cooling low level > implementations using frequency scaling up/down based on the request > from user. Different cpu related cooling devices can be registered by the > user and the binding of these cooling devices to the corresponding "Different cpu related cooling devices": Do you mean cooling devices for different CPUs (num_cpus) or are you referring to different customers aka consumer drivers who could use this framework and impose the cooling. > trip points can be easily done as the registration API's return the > cooling device pointer. The user of these api's are responsible for > passing clipping frequency in percentages. Why do you want to pass the clipping frequency in percentages? Wouldnt it be simpler for any platform sensor driver to just pass the frequency it wants to throttle the CPU? > + > + This interface function registers the cpufreq cooling device with the > name > + "thermal-cpufreq-%x". This api can support multiple instance of cpufreq > cooling > + devices. When you refer to cooling devices, is it the number of instances per-CPU that is supported? Sorry I am unable to follow. > + .polling_interval: polling interval for this cooling state. > + tab_size: the total number of cooling state. By cooling_state, I assume you are referring to the thermal state for the platform? or only for the CPU? > + mask_val: all the allowed cpu's where frequency clipping can happen. Why should this be a new variable? The policy->affected_cpus should be the same as this IMO? > + help > + This implements the generic cpu cooling mechanism through frequency > + reduction, cpu hotplug and any other ways of reducing temperature. > An Apart from reducing the CPU frequency, (probably) CPU hotplug, what other means of reducing CPU temperature? Or are you referring to any platform temperature controls? It isnt very clear from the documentation (at least to me) if this is only for CPU cooling or generic platform cooling. Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers'. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
Hi Amit, Thanks for the replies. One more query On Tue, Mar 13, 2012 at 10:37 AM, Amit Kachhap wrote: >> "Different cpu related cooling devices": Do you mean cooling devices >> for different CPUs (num_cpus) or are you referring to different >> customers aka consumer drivers who could use this framework and impose >> the cooling. > Correct but the consumer driver only has to use the other > thermal-sys.c functions. Only register cpu cooling devices is > implemented in this work. Am i right in noting that this framework then doesnt handle other devices for cooling like Graphics, LCD etc? Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On Tue, Mar 13, 2012 at 3:30 PM, Amit Kucheria wrote: > Sundar, Hi Amit, > At the moment it doesn't. But there was some discussion around > creating something that will work with devfreq. This would allow > peripheral drivers to be plugged in as well. Amit is investigating > that at present. What if we work towards a generic constraint framework which models thermals as a performance constraint. Drivers can register to this constraint; platform code can then decide to issue restrictions either to the CPU or other power-hungry peripherals based on the platform conditions. That also allows to model CPU frequency as a generic constraint but via an actual consumer, say the thermal driver. Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On Tue, Mar 13, 2012 at 4:22 PM, Amit Kachhap wrote: > Yes that should be helpful. Even the things your are suggesting are > somewhat same with some patches submitted which sets cpufreq min/max > constraint. Hmm..let me see how soon can I code up a rough implementation! Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: export kernel clock information to user space
On Sat, Oct 16, 2010 at 5:25 AM, Kevin Hilman wrote: > [..] > > That being said, I'm not against $SUBJECT patch, but I question it's > usefulness in terms of PM. What's more valuable for PM is the statitics > and knobs exported on a per-device level by the runtime PM core (and > AFAICT, already included into tools like powertop.) > IIRC, Vincent's suggestion is more valid for the HW guys who want to test out all kinds of possibilities *before* the OS and the support for the drivers becomes mature enough to concentrate on statistics and so on. Even I remember our HW guys requesting for bersek controls over regulators and clocks as a part of platform validation, when the OS was not mature enough in terms of a complete system-support. Cheers! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: export kernel clock information to user space
On Sun, Oct 17, 2010 at 9:11 AM, Yong Shen wrote: > BTW, 'cheers' is normally used in Australia and New Zealand. Are you from > there? Just curious. :) Oh really??..I am not aware of that all.I am from India :). IMO its cool. cheers! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH][ ARM cpu hotplug 2/2 ] Use common cpu hotplug code for UX500
Hello Vincent, On Mon, Nov 29, 2010 at 3:19 PM, Vincent Guittot wrote: > This patch extracts the common code of the cpu hotplug feature across > arm platforms. The goal is to only keep the specific stuff of the > platform in the sub-architecture. I have created a hotplug.c file in > the arm/common directory after studying the cpu hotplug code of > omap2, realview, s5pv310, ux500 and tegra. I have extracted 3 main > platform dependent functions: > -platform_enter_lowpower which prepares the platform for low power. > -platform_do_lowpower on which the cpu will loop until it becomes > really plugged (spurious wake up). This function must returned the cpu > Id in order to leave the unplug state. > -platform_leave_lowpower which restore the platform context. > An ux500 patch is available which uses the common/hotplug.c code. > This patch is quite short because the idle / power down functions are > not yet upstreamed > > I had posted a patch which does exactly the same thing sometime ago, but it got dropped off from the radar. The patch set can be referenced @ http://www.spinics.net/lists/arm-kernel/msg97600.html I remember getting it Acked by most of the platform maintainers, but Russell had some reservations on that. Cheers! - The views expressed in this email are my personal ones and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH][ ARM cpu hotplug 2/2 ] Use common cpu hotplug code for UX500
Hi Vincent, > On Mon, Nov 29, 2010 at 3:19 PM, Vincent Guittot > wrote: >> >> This patch extracts the common code of the cpu hotplug feature across >> arm platforms. The goal is to only keep the specific stuff of the >> platform in the sub-architecture. I have created a hotplug.c file in >> the arm/common directory after studying the cpu hotplug code of >> omap2, realview, s5pv310, ux500 and tegra. I have extracted 3 main >> platform dependent functions: >> -platform_enter_lowpower which prepares the platform for low power. >> -platform_do_lowpower on which the cpu will loop until it becomes >> really plugged (spurious wake up). This function must returned the cpu >> Id in order to leave the unplug state. >> -platform_leave_lowpower which restore the platform context. >> An ux500 patch is available which uses the common/hotplug.c code. >> This patch is quite short because the idle / power down functions are >> not yet upstreamed >> > I had posted a patch which does exactly the same thing sometime ago, but it got dropped off from the radar. The patch set can be referenced @ http://www.spinics.net/lists/arm-kernel/msg97600.html I remember getting it Acked by most of the platform maintainers, but Russell had some reservations on that. Cheers! -- - The views expressed in this email are my personal ones and do not necessarily echo my employers. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PM] 25/08/10 - Minutes for the Power Management WG weekly call
Hi, I am curious to know a bit more about one of the points mentioned below. Hope this is okay. On Wed, Aug 25, 2010 at 3:11 PM, Amit Kucheria wrote: > * ACTION: Amit K to talk to jeremy about power domain framework: DONE > * Jeremy needs help, will revisit in a few weeks Is there some details available for this; any generic overview of how this is going to progress? Cheers! Sundar ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PM] 25/08/10 - Minutes for the Power Management WG weekly call
Hi Amit, Thanx for the generous response :) On Mon, Sep 6, 2010 at 12:58 PM, Amit Kucheria 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
Re: Linaro Website Contact
Hi, Nice! I tried rebuilding the kernel while keeping the precompiled openembedded root filesystem. It could not boot beyond the point where the init starts. I followed the exact same steps to compile the kernel from linaro and it did compile without any problems. As for the image preparation there wasn't any problem either. I tried running several times but it gets stuck at the same point and there is no reponse to key presses. Thanks for any help! Regards, Sundar On Wed, Oct 31, 2012 at 10:22 PM, Loïc Minier wrote: > Hey > > (Cc:ing linaro-dev@ where we usually discuss technical stuff) > > On Wed, Oct 31, 2012, sundar.subramani...@gmail.com wrote: > > This is great. Just tried the pre-compiled image and works like a charm. > > It took a little longer than two minutes though on my i3/4Gig machine. > > Haven't yet tried compiling anything yet but how do i get started with > > porting some libraries to armv8? Just compile with the toolchain and run? > > Great! > > This page gives some ideas on how to rebuild the filesystem and how to > fix some common issues: > https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded > > Perhaps you want to try to build this or that software you care about, > or just try "bitbake world" to build as many things as possible and see > what breaks :-) > > Cheers, > -- > Loïc Minier > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
