Hi Rafael, 2011/8/12 Rafael J. Wysocki <rjw@xxxxxxx>: > On Thursday, August 11, 2011, jean.pihet@xxxxxxxxxxxxxx wrote: >> From: Jean Pihet <j-pihet@xxxxxx> >> >> This patch set is in an RFC state, for review and comments. >> ... >> >> >> Questions: >> 1. the user space API is still under discussions on linux-omap and linux-pm MLs, >> cf. [1]. The idea is to add a user-space API for the devices constratins >> PM QoS, using a sysfs entry per device >> >> [1] http://marc.info/?l=linux-omap&m=131232344503327&w=2 >> >> ToDo: >> 1. write Documentation for the new PM QoS class, once the RFC is agreed on >> 2. validate the constraints framework on OMAP4 HW (done on OMAP3) >> 3. Need testing on platforms other than OMAP >> 4. refine the power domains wake-up latency and the cpuidle figures >> 5. re-visit the OMAP power domains states initialization procedure. Currently >> the power states that have been changed from the constraints API which were >> applied before the initialization of the power domains are lost >> >> >> Based on the master branch of the linux-omap git tree (3.0.0-rc7). Compile >> tested using OMAP and x86 generic defconfigs. >> >> Lightly tested on OMAP3 Beagleboard (ES2.x). >> Need testing on platforms other than OMAP, because of the impact on the >> device insertion/removal in device_pm_add/remove > > The patchset looks really good to me, I don't think I have any major > complaints about this version. Ok good to hear it! I tried to address all comments and concerns in this release. > > The only thing I'd like to ask at the moment is whether or not the > compilation of drivers/base/power/qos.c should depend on > CONFIG_PM_RUNTIME. Do you think it will be used by system suspend code on any > platforms? I would say it should only depend on CONFIG_PM because the dev PM QoS API can be used from any kernel code, being runtime PM code or not. I leave the decision to the PM framework experts. > > Also, I'd like to take the final patchset for 3.2, Ok good! > but I don't feel > confident enough about the OMAP patches. The OMAP patches have been reviewed a few times already and the comments have been taken into account. Also i has been tested correctly on OMAP3. > If you want me to take them too, > please make sure they are ACKed by the OMAP maintainers. For sure I need the Acks. I guess I now need to annoy OMAP folks about it ;p In the case the Acks are not gathered on time the generic patches could be merged in, then the OMAP generic code. Do you think it is a viable option? The only concern I have is about the on-going OMAP PM initialization clean-up task, cf. ToDo list: >> 5. re-visit the OMAP power domains states initialization procedure. Currently >> the power states that have been changed from the constraints API which were >> applied before the initialization of the power domains are lost On the other hand some testing is needed on platforms other than OMAP, because of the impact on the device insertion/removal in device_pm_add/remove functions. I tested the SD card insertion/removal on OMAP3. > > Thanks, > Rafael > Thanks, Jean -- 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
