[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140816063517.GB13884@Nokia-N900>
Date: Sat, 16 Aug 2014 08:35:17 +0200
From: Pavel Machek <pavel@....cz>
To: Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc: linux-pm@...r.kernel.org,
Thierry Reding <thierry.reding@...il.com>,
Terje Bergstr?m <tbergstrom@...dia.com>,
Stephen Warren <swarren@...dotorg.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
Mikko Perttunen <mperttunen@...dia.com>
Subject: Re: [RFC v2 1/3] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class
Hi!
> Also adds a class type PM_QOS_SUM that aggregates the values by summing them.
>
> It can be used by memory controllers to calculate the optimum clock frequency
> based on the bandwidth needs of the different memory clients.
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
> ---
> Documentation/power/pm_qos_interface.txt | 4 +++-
> include/linux/pm_qos.h | 5 ++++-
> kernel/power/qos.c | 27 ++++++++++++++++++++++++++-
> 3 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
> index a5da5c7..57782e8 100644
> --- a/Documentation/power/pm_qos_interface.txt
> +++ b/Documentation/power/pm_qos_interface.txt
> @@ -5,7 +5,8 @@ performance expectations by drivers, subsystems and user space applications on
> one of the parameters.
>
> Two different PM QoS frameworks are available:
> -1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput.
> +1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput,
> +memory_bandwidth.
> 2. the per-device PM QoS framework provides the API to manage the per-device latency
> constraints and PM QoS flags.
>
> @@ -13,6 +14,7 @@ Each parameters have defined units:
> * latency: usec
> * timeout: usec
> * throughput: kbs (kilo bit / sec)
> + * memory bandwidth: kbs (kilo bit / sec)
Would mega bits per second make sense here?
I suppose some many-core systems would have memory bandwith
in > 10 terabit/sec, overflowing u32.
Plus, if driver in 3/3 is just an example, perhaps comment
should explain that clearly?
Otherwise looks good,
Acked-by: Pavel Machek <pavel@....cz>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists