Re: [RFC/PATCH] OMAP PM interface

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

 



Paul Walmsley <paul@xxxxxxxxx> 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 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