Paul Walmsley <[EMAIL PROTECTED]> writes: > Linux PM QOS parameters: > > As of February, the mainline Linux kernel contains code that is > somewhat similar to the SRF: the Linux PM QOS parameters code, located > in kernel/pm_qos_params.c. (This code replaced the latency management > code that was present in earlier kernels.) Ideally, OMAP drivers > would be able to use this Linux PM QOS code directly, but the current > PM QOS code has some drawbacks: > > - It combines some power management parameters that should be kept > separate for maximum power savings on OMAP3. For example, in the PM > QOS code, CPU and DMA wakeup latency are combined into one > parameter; but on OMAP3, these are distinct parameters. The Linux > PM QOS code also combines all network power management knobs into > two non-device-specific parameters. OMAP2/3 systems can have > different network devices with different power management > requirements - for example, a wired Ethernet interface may have > different latency and throughput constraints than a wireless Ethernet > interface. > > - It does not yet cover all of the power management capabilities of > the OMAP3 architecture. It does not express latency constraints on > a per-device or per-powerdomain basis; it only covers > cpu_dma_latency and network throughput and latency, which would not > cover most of the OMAP3 devices. > > The result is that drivers using the current Linux PM QOS layer > directly are unlikely to reach the same level of power efficiency as > driver code using the Shared Resource Framework.
Paul, First, thanks for working on this. This is a huge step in the right direction in my opinon. Thanks! I've only given a quick glance so far at the actual patch, but my first comments are regarding the dismissal of the PM QoS framework. I totally agree that the QoS framework in its current form has several drawbacks and limitations. However, instead of re-designing something new, I think maybe we should first try to extend the QoS framework. I've had a few conversations with the Intel folks who worked on PM QoS and got it into mainline, especially Mark Gross. He is quite aware that it is only the very beginnings of a framework. He is also very interested in potential users and their concerns about limitations of the framework. Since it came out of Intel, PM QoS definitely has a PC/UMPC focus, but this is a perfect opportunity to help extend the framework to be useful in embedded systems. I'm sure the Intel guys will be happy to hear about potential users and use cases for the framework and why it should be extended/updated to work well in embedded. For starters, we could just use the existing PM QoS framework as it is and just add a new set of parameters. Then begin dissucions with the PM QoS folks as to how they could be generalized and unified with the existing ones. Thoughts? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
