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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux