On Tue, Jan 26, 2010 at 9:36 AM, Ai Li <aili@xxxxxxxxxxxxxx> wrote: >> Now what seems to be asked for is that something akin to the >> android WAKE_LOCK_IDLE "thing". >> >> Last night I gave some thought to this. One could put a boolean >> or bit mask flag into the aggregated value that when polled the >> poller could know to not go to any lower performing state or >> kick the system into higher performance states. Setting the >> flag would only happen from kernel API's and no notification >> trees would be called as it gets toggled. (that would kill fast >> path performance) > > Android WAKE_LOCK_IDLE is a very coarse setting. It does not take > advantage of the multiple performance states with their corresponding > latency values. WAKE_LOCK_IDLE potentially disallows some low > performance states when their latencies may be quite acceptable. In > contrast, an integer setting would allow a better match between the > requested latency value and the appropriate low power states. pm_qos > already provides the integer setting. IMO, the question is how to > enable hot-path flow through pm_qos... > There are a few lower power states on msm that we don't differentiate between when taking an idle lock. We don't use idle locks on omap. The resource framework in the omap tree is sufficient with the latency requirement calls in resource34xx.c/h I might be wrong here but it sounds like you're trying to solve a similar problem but working it into the pm-qos framework? Or am I confused on what the subject of this thread is? -- Mike > >> But as I thought about it it became clear the correct behavior >> is really a function of the parameter class. If the parameter >> is cpu_dma_latency then the flag would be used to simply disable >> CPUIDLE from doing any high latency idle states. However; such >> a flag for network bandwidth (a flag hit in some fast code path) >> shouldn't be telling the NIC to kick up from 100Mbs to 1000Mbs >> or go back. >> >> So what would a fast path pm-qos parameter look like and how >> would it be used, outside of CPUIDLE? >> > > Stating it in another way: the correct hot path behavior for each > parameter class is dependent on what the parameter class is. To > accommodate this, we could add a hot_path_fn in struct pm_qos_object. > It specifies the hot path behavior for the parameter class. In the > hot path flow, update_target() will call > pm_qos_array[pm_qos_class]->hot_path_fn() instead of the notifier > chain. > > With regards to NIC cards, I'm not sure what hot_path_fn() would > perform. Maybe the default hot_path_fn for PM_QOS_NETWORK_THROUGHPUT > does nothing; the platform code or NIC card code can register a > different hot_path_fn. > > ~Ai > > > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/linux-pm > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
