[REPOST PATCH v4 0/2] PM QoS: Add support for memory bandwidth constraints

[REPOST PATCH v4 0/2] PM QoS: Add support for memory bandwidth constraints

[Tomeu Vizoso]

Hi,

this is just a rebase on top of latest linux-next. Follows the original blurb:

Some device drivers need to sustain transfers to or from external memory at
given fixed rates for a period of time. If we wait for the devfreq drivers to
react to this load, the user is likely going to perceive glitches in the user
experience.

Some common scenarios that would benefit from it are display controllers
setting a new mode, USB drivers starting isochronous transfers, camera drivers
starting to capture and hw media codecs doing their thing.

I'm proposing adding a new PM_QOS_MEMORY_BANDWIDTH class that device drivers
can use to register their memory bandwidth needs right when they become known,
so the external memory clock can be set at the optimum frequency, thus
preventing glitches.

There have been similar proposals before [0], the first main concern being that
constraints need to refer to a global resource such as CPUs. If they referred
to a network NIC or to a UART, there would be no way of knowing how to actually
constrain each device because there would be a single list of requests.

In this case, the memory bus is a global resource just like the CPUs are, and
all requests in this class will apply to a single device driver in any
particular system.

The second serious concern was that constraints need to be defined in a way
generic enough so they can be consumed in a wide array of particular systems
without placing the burden of taking into account hw specifics in the driver of
the memory client.

Here, the PM_QOS_MEMORY_BANDWIDTH constraints are specified always in kbs,
being the amount of data that the device driver wants to see transferred per
second. This allows for example for a camera driver to calculate the
appropriate value based on the size of each frame and the desired FPS and,
depending on the particular system where the camera block is used, the
appropriate external memory driver will convert that to the bus clock frequency
that makes sense for the hardware at hand.

The first patch adds the new class and also a new PM_QOS_SUM class type.

The second illustrates how the driver for such a memory client would request
its memory bandwidth requirement.

Most vendor trees carry their own solution for this specific issue, so it would
be pretty neat if mainline gained a similar mechanism so we get more power
management goodies in the right place.

[0] https://lkml.org/lkml/2012/3/10/165

Thanks,

Tomeu

Tomeu Vizoso (2):
  PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class
  drm/tegra: Request memory bandwidth for the display controller

 Documentation/power/pm_qos_interface.txt |  4 +++-
 drivers/gpu/drm/tegra/dc.c               | 15 +++++++++++++++
 drivers/gpu/drm/tegra/drm.h              |  3 +++
 include/linux/pm_qos.h                   |  5 ++++-
 kernel/power/qos.c                       | 27 ++++++++++++++++++++++++++-
 5 files changed, 51 insertions(+), 3 deletions(-)

-- 
1.9.3

[REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

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-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>

---

v3: * Changed units to be megabits per second
---
 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..129f7c0 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: mbs (mega bit / sec)
 
 
 1. PM QoS framework
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 9ab4bf7..636e828 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -15,6 +15,7 @@ enum {
 	PM_QOS_CPU_DMA_LATENCY,
 	PM_QOS_NETWORK_LATENCY,
 	PM_QOS_NETWORK_THROUGHPUT,
+	PM_QOS_MEMORY_BANDWIDTH,
 
 	/* insert new class ID */
 	PM_QOS_NUM_CLASSES,
@@ -32,6 +33,7 @@ enum pm_qos_flags_status {
 #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
+#define PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE	0
 #define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE	0
 #define PM_QOS_LATENCY_TOLERANCE_DEFAULT_VALUE	0
 #define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT	(-1)
@@ -69,7 +71,8 @@ struct dev_pm_qos_request {
 enum pm_qos_type {
 	PM_QOS_UNITIALIZED,
 	PM_QOS_MAX,		/* return the largest value */
-	PM_QOS_MIN		/* return the smallest value */
+	PM_QOS_MIN,		/* return the smallest value */
+	PM_QOS_SUM		/* return the sum */
 };
 
 /*
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 884b770..5f4c006 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -105,11 +105,27 @@ static struct pm_qos_object network_throughput_pm_qos = {
 };
 
 
+static BLOCKING_NOTIFIER_HEAD(memory_bandwidth_notifier);
+static struct pm_qos_constraints memory_bw_constraints = {
+	.list = PLIST_HEAD_INIT(memory_bw_constraints.list),
+	.target_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.default_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.no_constraint_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.type = PM_QOS_SUM,
+	.notifiers = &memory_bandwidth_notifier,
+};
+static struct pm_qos_object memory_bandwidth_pm_qos = {
+	.constraints = &memory_bw_constraints,
+	.name = "memory_bandwidth",
+};
+
+
 static struct pm_qos_object *pm_qos_array[] = {
 	&null_pm_qos,
 	&cpu_dma_pm_qos,
 	&network_lat_pm_qos,
-	&network_throughput_pm_qos
+	&network_throughput_pm_qos,
+	&memory_bandwidth_pm_qos,
 };
 
 static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
@@ -130,6 +146,9 @@ static const struct file_operations pm_qos_power_fops = {
 /* unlocked internal variant */
 static inline int pm_qos_get_value(struct pm_qos_constraints *c)
 {
+	struct plist_node *node;
+	int total_value = 0;
+
 	if (plist_head_empty(&c->list))
 		return c->no_constraint_value;
 
@@ -140,6 +159,12 @@ static inline int pm_qos_get_value(struct pm_qos_constraints *c)
 	case PM_QOS_MAX:
 		return plist_last(&c->list)->prio;
 
+	case PM_QOS_SUM:
+		plist_for_each(node, &c->list)
+			total_value += node->prio;
+
+		return total_value;
+
 	default:
 		/* runtime check for not using enum */
 		BUG();
-- 
1.9.3

[REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

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@collabora.com>
Acked-by: Pavel Machek <pavel@ucw.cz>

---

v3: * Changed units to be megabits per second
---
 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..129f7c0 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: mbs (mega bit / sec)
 
 
 1. PM QoS framework
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 9ab4bf7..636e828 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -15,6 +15,7 @@ enum {
 	PM_QOS_CPU_DMA_LATENCY,
 	PM_QOS_NETWORK_LATENCY,
 	PM_QOS_NETWORK_THROUGHPUT,
+	PM_QOS_MEMORY_BANDWIDTH,
 
 	/* insert new class ID */
 	PM_QOS_NUM_CLASSES,
@@ -32,6 +33,7 @@ enum pm_qos_flags_status {
 #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE	(2000 * USEC_PER_SEC)
 #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE	0
+#define PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE	0
 #define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE	0
 #define PM_QOS_LATENCY_TOLERANCE_DEFAULT_VALUE	0
 #define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT	(-1)
@@ -69,7 +71,8 @@ struct dev_pm_qos_request {
 enum pm_qos_type {
 	PM_QOS_UNITIALIZED,
 	PM_QOS_MAX,		/* return the largest value */
-	PM_QOS_MIN		/* return the smallest value */
+	PM_QOS_MIN,		/* return the smallest value */
+	PM_QOS_SUM		/* return the sum */
 };
 
 /*
diff --git a/kernel/power/qos.c b/kernel/power/qos.c
index 884b770..5f4c006 100644
--- a/kernel/power/qos.c
+++ b/kernel/power/qos.c
@@ -105,11 +105,27 @@ static struct pm_qos_object network_throughput_pm_qos = {
 };
 
 
+static BLOCKING_NOTIFIER_HEAD(memory_bandwidth_notifier);
+static struct pm_qos_constraints memory_bw_constraints = {
+	.list = PLIST_HEAD_INIT(memory_bw_constraints.list),
+	.target_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.default_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.no_constraint_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
+	.type = PM_QOS_SUM,
+	.notifiers = &memory_bandwidth_notifier,
+};
+static struct pm_qos_object memory_bandwidth_pm_qos = {
+	.constraints = &memory_bw_constraints,
+	.name = "memory_bandwidth",
+};
+
+
 static struct pm_qos_object *pm_qos_array[] = {
 	&null_pm_qos,
 	&cpu_dma_pm_qos,
 	&network_lat_pm_qos,
-	&network_throughput_pm_qos
+	&network_throughput_pm_qos,
+	&memory_bandwidth_pm_qos,
 };
 
 static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
@@ -130,6 +146,9 @@ static const struct file_operations pm_qos_power_fops = {
 /* unlocked internal variant */
 static inline int pm_qos_get_value(struct pm_qos_constraints *c)
 {
+	struct plist_node *node;
+	int total_value = 0;
+
 	if (plist_head_empty(&c->list))
 		return c->no_constraint_value;
 
@@ -140,6 +159,12 @@ static inline int pm_qos_get_value(struct pm_qos_constraints *c)
 	case PM_QOS_MAX:
 		return plist_last(&c->list)->prio;
 
+	case PM_QOS_SUM:
+		plist_for_each(node, &c->list)
+			total_value += node->prio;
+
+		return total_value;
+
 	default:
 		/* runtime check for not using enum */
 		BUG();
-- 
1.9.3

[REPOST PATCH v4 2/2] drm/tegra: Request memory bandwidth for the display controller

[Tomeu Vizoso]

For now the amount requested is based solely on the current mode's refresh
rate.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Pavel Machek <pavel@ucw.cz>

---

v4: * Use vertical refresh rate when calculating the bandwidth requirement

v3: * Fixed the bandwidth calculation, and have the units be mbps
---
 drivers/gpu/drm/tegra/dc.c  | 15 +++++++++++++++
 drivers/gpu/drm/tegra/drm.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 6553fd2..8a3fee8 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -9,6 +9,7 @@
 
 #include <linux/clk.h>
 #include <linux/debugfs.h>
+#include <linux/pm_qos.h>
 #include <linux/reset.h>
 
 #include "dc.h"
@@ -753,6 +754,8 @@ static void tegra_crtc_disable(struct drm_crtc *crtc)
 	}
 
 	drm_vblank_off(drm, dc->pipe);
+
+	pm_qos_update_request(&dc->qos_request, PM_QOS_DEFAULT_VALUE);
 }
 
 static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -839,6 +842,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
 	struct tegra_dc *dc = to_tegra_dc(crtc);
 	struct tegra_dc_window window;
 	u32 value;
+	unsigned long bandwidth;
 	int err;
 
 	drm_vblank_pre_modeset(crtc->dev, dc->pipe);
@@ -879,6 +883,12 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
 	if (err < 0)
 		dev_err(dc->dev, "failed to enable root plane\n");
 
+	bandwidth = window.stride[0] * window.dst.h * 8;
+	bandwidth *= drm_mode_vrefresh(mode);
+	bandwidth /= 1024 * 1024;
+
+	pm_qos_update_request(&dc->qos_request, bandwidth);
+
 	return 0;
 }
 
@@ -1499,6 +1509,9 @@ static int tegra_dc_probe(struct platform_device *pdev)
 		return err;
 	}
 
+	pm_qos_add_request(&dc->qos_request, PM_QOS_MEMORY_BANDWIDTH,
+			   PM_QOS_DEFAULT_VALUE);
+
 	platform_set_drvdata(pdev, dc);
 
 	return 0;
@@ -1509,6 +1522,8 @@ static int tegra_dc_remove(struct platform_device *pdev)
 	struct tegra_dc *dc = platform_get_drvdata(pdev);
 	int err;
 
+	pm_qos_remove_request(&dc->qos_request);
+
 	err = host1x_client_unregister(&dc->client);
 	if (err < 0) {
 		dev_err(&pdev->dev, "failed to unregister host1x client: %d\n",
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index e89c70f..a99e533d 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -12,6 +12,7 @@
 
 #include <uapi/drm/tegra_drm.h>
 #include <linux/host1x.h>
+#include <linux/pm_qos.h>
 
 #include <drm/drmP.h>
 #include <drm/drm_crtc_helper.h>
@@ -120,6 +121,8 @@ struct tegra_dc {
 	struct drm_pending_vblank_event *event;
 
 	const struct tegra_dc_soc_info *soc;
+
+	struct pm_qos_request qos_request;
 };
 
 static inline struct tegra_dc *
-- 
1.9.3

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> 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@collabora.com>
> Acked-by: Pavel Machek <pavel@ucw.cz>

Hi Rafael,

will you take this one for 3.18?

Thanks,

Tomeu

> ---
>
> v3: * Changed units to be megabits per second
> ---
>  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..129f7c0 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: mbs (mega bit / sec)
>
>
>  1. PM QoS framework
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 9ab4bf7..636e828 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -15,6 +15,7 @@ enum {
>         PM_QOS_CPU_DMA_LATENCY,
>         PM_QOS_NETWORK_LATENCY,
>         PM_QOS_NETWORK_THROUGHPUT,
> +       PM_QOS_MEMORY_BANDWIDTH,
>
>         /* insert new class ID */
>         PM_QOS_NUM_CLASSES,
> @@ -32,6 +33,7 @@ enum pm_qos_flags_status {
>  #define PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE       (2000 * USEC_PER_SEC)
>  #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE       (2000 * USEC_PER_SEC)
>  #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE        0
> +#define PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE  0
>  #define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE    0
>  #define PM_QOS_LATENCY_TOLERANCE_DEFAULT_VALUE 0
>  #define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT (-1)
> @@ -69,7 +71,8 @@ struct dev_pm_qos_request {
>  enum pm_qos_type {
>         PM_QOS_UNITIALIZED,
>         PM_QOS_MAX,             /* return the largest value */
> -       PM_QOS_MIN              /* return the smallest value */
> +       PM_QOS_MIN,             /* return the smallest value */
> +       PM_QOS_SUM              /* return the sum */
>  };
>
>  /*
> diff --git a/kernel/power/qos.c b/kernel/power/qos.c
> index 884b770..5f4c006 100644
> --- a/kernel/power/qos.c
> +++ b/kernel/power/qos.c
> @@ -105,11 +105,27 @@ static struct pm_qos_object network_throughput_pm_qos = {
>  };
>
>
> +static BLOCKING_NOTIFIER_HEAD(memory_bandwidth_notifier);
> +static struct pm_qos_constraints memory_bw_constraints = {
> +       .list = PLIST_HEAD_INIT(memory_bw_constraints.list),
> +       .target_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
> +       .default_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
> +       .no_constraint_value = PM_QOS_MEMORY_BANDWIDTH_DEFAULT_VALUE,
> +       .type = PM_QOS_SUM,
> +       .notifiers = &memory_bandwidth_notifier,
> +};
> +static struct pm_qos_object memory_bandwidth_pm_qos = {
> +       .constraints = &memory_bw_constraints,
> +       .name = "memory_bandwidth",
> +};
> +
> +
>  static struct pm_qos_object *pm_qos_array[] = {
>         &null_pm_qos,
>         &cpu_dma_pm_qos,
>         &network_lat_pm_qos,
> -       &network_throughput_pm_qos
> +       &network_throughput_pm_qos,
> +       &memory_bandwidth_pm_qos,
>  };
>
>  static ssize_t pm_qos_power_write(struct file *filp, const char __user *buf,
> @@ -130,6 +146,9 @@ static const struct file_operations pm_qos_power_fops = {
>  /* unlocked internal variant */
>  static inline int pm_qos_get_value(struct pm_qos_constraints *c)
>  {
> +       struct plist_node *node;
> +       int total_value = 0;
> +
>         if (plist_head_empty(&c->list))
>                 return c->no_constraint_value;
>
> @@ -140,6 +159,12 @@ static inline int pm_qos_get_value(struct pm_qos_constraints *c)
>         case PM_QOS_MAX:
>                 return plist_last(&c->list)->prio;
>
> +       case PM_QOS_SUM:
> +               plist_for_each(node, &c->list)
> +                       total_value += node->prio;
> +
> +               return total_value;
> +
>         default:
>                 /* runtime check for not using enum */
>                 BUG();
> --
> 1.9.3
>

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Rafael J. Wysocki]

On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> > 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@collabora.com>
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Hi Rafael,
> 
> will you take this one for 3.18?

Quite likely, but I'm traveling now, so I'll do that after I'm back home
in a few days.  I'll write to you if there are any problems.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
>> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> > 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@collabora.com>
>> > Acked-by: Pavel Machek <pavel@ucw.cz>
>>
>> Hi Rafael,
>>
>> will you take this one for 3.18?
>
> Quite likely, but I'm traveling now, so I'll do that after I'm back home
> in a few days.  I'll write to you if there are any problems.

Don't want to be annoying, but thought I might ping you just in case
this fell through the cracks.

Regards,

Tomeu

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

On 24 September 2014 15:32, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
>> On 14 September 2014 19:06, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
>> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
>> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
>> >> > 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-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> >> > Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
>> >>
>> >> Hi Rafael,
>> >>
>> >> will you take this one for 3.18?
>> >
>> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
>> > in a few days.  I'll write to you if there are any problems.
>>
>> Don't want to be annoying, but thought I might ping you just in case
>> this fell through the cracks.
>
> No, it didn't.
>
> I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
> later through the Tegra DRM driver, right?

Yes, that was Stephen's suggestion:

https://lkml.org/lkml/2014/8/25/439

Cheers,

Tomeu

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

On 24 September 2014 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
>> On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
>> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> >> > 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@collabora.com>
>> >> > Acked-by: Pavel Machek <pavel@ucw.cz>
>> >>
>> >> Hi Rafael,
>> >>
>> >> will you take this one for 3.18?
>> >
>> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
>> > in a few days.  I'll write to you if there are any problems.
>>
>> Don't want to be annoying, but thought I might ping you just in case
>> this fell through the cracks.
>
> No, it didn't.
>
> I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
> later through the Tegra DRM driver, right?

Yes, that was Stephen's suggestion:

https://lkml.org/lkml/2014/8/25/439

Cheers,

Tomeu

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Rafael J. Wysocki]

On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
> On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> >> > 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@collabora.com>
> >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> >>
> >> Hi Rafael,
> >>
> >> will you take this one for 3.18?
> >
> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
> > in a few days.  I'll write to you if there are any problems.
> 
> Don't want to be annoying, but thought I might ping you just in case
> this fell through the cracks.

No, it didn't.

I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
later through the Tegra DRM driver, right?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Rafael J. Wysocki]

On Wednesday, September 24, 2014 03:31:55 PM Tomeu Vizoso wrote:
> On 24 September 2014 15:32, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
> >> On 14 September 2014 19:06, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> >> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
> >> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
> >> >> > 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-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> >> >> > Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> >> >>
> >> >> Hi Rafael,
> >> >>
> >> >> will you take this one for 3.18?
> >> >
> >> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
> >> > in a few days.  I'll write to you if there are any problems.
> >>
> >> Don't want to be annoying, but thought I might ping you just in case
> >> this fell through the cracks.
> >
> > No, it didn't.
> >
> > I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
> > later through the Tegra DRM driver, right?
> 
> Yes, that was Stephen's suggestion:
> 
> https://lkml.org/lkml/2014/8/25/439

OK, patch [1/2] queued up for 3.18, thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Rafael J. Wysocki]

On Wednesday, September 24, 2014 03:31:55 PM Tomeu Vizoso wrote:
> On 24 September 2014 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
> >> On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
> >> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> >> >> > 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@collabora.com>
> >> >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> >> >>
> >> >> Hi Rafael,
> >> >>
> >> >> will you take this one for 3.18?
> >> >
> >> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
> >> > in a few days.  I'll write to you if there are any problems.
> >>
> >> Don't want to be annoying, but thought I might ping you just in case
> >> this fell through the cracks.
> >
> > No, it didn't.
> >
> > I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
> > later through the Tegra DRM driver, right?
> 
> Yes, that was Stephen's suggestion:
> 
> https://lkml.org/lkml/2014/8/25/439

OK, patch [1/2] queued up for 3.18, thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Tomeu Vizoso]

On 26 September 2014 01:51, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, September 24, 2014 03:31:55 PM Tomeu Vizoso wrote:
>> On 24 September 2014 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
>> >> On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> >> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
>> >> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> >> >> > 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@collabora.com>
>> >> >> > Acked-by: Pavel Machek <pavel@ucw.cz>
>> >> >>
>> >> >> Hi Rafael,
>> >> >>
>> >> >> will you take this one for 3.18?
>> >> >
>> >> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
>> >> > in a few days.  I'll write to you if there are any problems.
>> >>
>> >> Don't want to be annoying, but thought I might ping you just in case
>> >> this fell through the cracks.
>> >
>> > No, it didn't.
>> >
>> > I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
>> > later through the Tegra DRM driver, right?
>>
>> Yes, that was Stephen's suggestion:
>>
>> https://lkml.org/lkml/2014/8/25/439
>
> OK, patch [1/2] queued up for 3.18, thanks!

Hi Rafael,

I don't see this one in linux-next yet.

Regards,

Tomeu

Re: [REPOST PATCH v4 1/2] PM / QoS: Add PM_QOS_MEMORY_BANDWIDTH class

[Rafael J. Wysocki]

On Friday, October 10, 2014 08:59:22 AM Tomeu Vizoso wrote:
> On 26 September 2014 01:51, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Wednesday, September 24, 2014 03:31:55 PM Tomeu Vizoso wrote:
> >> On 24 September 2014 15:32, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Wednesday, September 24, 2014 10:42:13 AM Tomeu Vizoso wrote:
> >> >> On 14 September 2014 19:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> >> > On Friday, September 12, 2014 11:11:25 AM Tomeu Vizoso wrote:
> >> >> >> On 3 September 2014 17:49, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> >> >> >> > 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@collabora.com>
> >> >> >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> >> >> >>
> >> >> >> Hi Rafael,
> >> >> >>
> >> >> >> will you take this one for 3.18?
> >> >> >
> >> >> > Quite likely, but I'm traveling now, so I'll do that after I'm back home
> >> >> > in a few days.  I'll write to you if there are any problems.
> >> >>
> >> >> Don't want to be annoying, but thought I might ping you just in case
> >> >> this fell through the cracks.
> >> >
> >> > No, it didn't.
> >> >
> >> > I'm wondering about patch [2/2], though.  I'm assuming that you'll push you
> >> > later through the Tegra DRM driver, right?
> >>
> >> Yes, that was Stephen's suggestion:
> >>
> >> https://lkml.org/lkml/2014/8/25/439
> >
> > OK, patch [1/2] queued up for 3.18, thanks!
> 
> Hi Rafael,
> 
> I don't see this one in linux-next yet.

My bad, I skipped the pm-qos branch by mistake.  Sorry about that.

This week I'm attending conferences, but I'll push it to Linus next week
if the merge windown is still open then.

Rafael