Message-Id: <1409759373-22696-1-git-send-email-tomeu.vizoso@collabora.com>
Date:	Wed,  3 Sep 2014 17:49:31 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	linux-pm@...r.kernel.org
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Terje Bergström <tbergstrom@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Pavel Machek <pavel@....cz>, 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>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: [REPOST PATCH v4 0/2] PM QoS: Add support for memory bandwidth constraints

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

--
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