Re: [PATCH v4 00/15] PM QoS: add a per-device latency constraints class

Hi Rafael,

2011/8/12 Rafael J. Wysocki [off-list ref]:

On Thursday, August 11, 2011, jean.pihet@newoldbits.com wrote:

quoted

From: Jean Pihet <redacted>

This patch set is in an RFC state, for review and comments.

...

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html