On 一, 2012-06-11 at 23:09 +0530, Durgadoss R wrote: > This patch series attempts to add some simple governors/ > throttling algorithms to the generic thermal layer. Oh, this is something what I want to do, but not sure when. Thanks, Durga. > Although this patch set creates simple governors which depend > on the platform data provided, we can start here, and write > some really smart algorithms that will do the wonder!! > > Patch 1/4: Creates necessary infrastructure required to > add throttling algorithms in thermal_sys.c > 1. Introduces the get_trend callback seems duplicate work of my patch set. :( > 2. Introduces the notify_thermal_framework() API > 3. Exposes sysfs to show/store the throttle_policy > yes, I think we need this. > Patch 2/4: Introduce fair_share governor > This throttles the cooling_devices according to their > weights (and hence the name; Suggestion are welcome :-). > The weights in turn describe the effectiveness of a > particular cooling device in cooling a thermal zone. > > Patch 3/4: Introduce step_wise governor > This throttles/de-throttles the cooling devices one > step at a time. This is exactly similar to the code > we have in thermal_zone_device_update function. The > intention is to move all 'throttling logic' related > code outside thermal_sys.c and keep them separate. totally agree. This is in my TODO list as well. :) BTW, we may need an easy "userspace" governor as well. > > Patch 4/4: Platform data patch > This patch is not for merge. Just as an example to > show how we can provide platform data to thermal > framework. Not that we do not know how to fill structures, > I felt the patch set is in-complete without this. That's > why it is here. From next versions, I will ignore this one. > > TODO on these patch sets: > * Sync up with Rui's latest patches agreed. > * Add more protection and tidy up the existing ones > * Expose the weights and cooling devices through sysfs (Read-Only) what do you mean "cooling devices"? > * Remove all throttling related code(if we all agree) from thermal_sys.c Ack! > * In fair_share, before setting new state, check if there are other zones, > which do not want the 'state' to be changed. Yep, I think this is handled in my arbitrator patch. :p > (To do this, we have to loop through the thermal_tz_list and > thermal_cdev_list inside fair_share.c. Need to see how good it is > to make this lists public) IMO, these governors should just update the thermal_instance, and then invokes thermal_zone_do_update(). They should not change the cooling state directly. > * If we all agree, use step_wise and remove linear_throttle from thermal_sys.c agreed. > * Enhance notify_user_space(), so that the use land can extract some sane > information out of UEvent. > > WishList: > * Find a way to provide platform data so that we can map cooling devices > for a trip point in a thermal zone. hmm, what information do we need except "weight"? I think we can register the weight information when do the binding, like I did for "upper" and "lower" limits. > * Make all _throttle methods have same signature. This way we can make use > of function pointers and make the code a bit simpler. what does signature mean? > * The simple governors heavily depend on the platform data provided. We > can think of some really smart logic, that depends on very minimal platform > data, and do things on its own :-) > * Make other subsystem core files register with the thermal framework as a > thermal sensor or as a cooling device as appropriate. > (I am thinking of Power Supply, Video, cpufreq for now) about cpufreq, I think Amit has some work on this. hah > * Ah, Find time to do all this ! > me too. :) Again, thanks for your work, they are good ideas. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
