Messages in this thread | | | Date | Thu, 1 Sep 2011 17:28:20 +0200 | Subject | Re: [PATCH 0/5] PM: Generic PM domains and device PM QoS | From | Jean Pihet <> |
| |
Rafael,
On Wed, Aug 31, 2011 at 12:17 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > Hi, > > This patchset illustrates how device PM QoS may be used along with > PM domains in my view. > > Actually, it consists of two parts. Namely, patches [1-3/5] seem to be > suitable for 3.2, unless somebody hates them, The patches [1-3/5] are ok (reviewed only) excepted some remarks I have.
> but patches [4-5/5] are > total RFC. They haven't been tested, only compiled, so the use of them > is not encouraged (they may kill your dog or make your cat go wild, or > do something equally nasty, so beware). That looks like a disclaimer ;p
> Their purpose is to illustrate > an idea that I'd like to discuss at the PM miniconference during the > LPC. There is some code for OMAP that dynamically updates the worst case values for devices activation and de-activation; cf._omap_device_activate and _omap_device_deactivate in arch/arm/plat-omap/omap_device.c. The idea is to start with reference figures (worst case measured on board) at boot and then update the worst case values at runtime. Based on the PM QoS values and the worst case latency values the next power domains states can be determined. Unfortunately this is not (yet) implemented.
I am wondering if the patches [4-5/5] are meant to replace the OMAP code, which would be really nice.
> > [1/5] - Split device PM domain data into a "base" and additional fields > (one need_restore field at the moment, but the subsequent patches > add more fields). > > [2/5] - Make runtime PM always release power.lock if power.irq_safe is set. > > [3/5] - Add function for reading device PM QoS values safely. > > [4/5] - Add governor function for stopping devices. > > [5/5] - Add generic PM domain power off governor function. > > Thanks, > Rafael > >
Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |