linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vishwanath BS <vishwanath.bs@ti.com>
To: linux-omap@vger.kernel.org
Cc: patches@linaro.org, Vishwanath BS <vishwanath.bs@ti.com>
Subject: [PATCH 13/13] OMAP: Add DVFS Documentation
Date: Fri, 21 Jan 2011 19:31:05 +0530	[thread overview]
Message-ID: <1295618465-15234-14-git-send-email-vishwanath.bs@ti.com> (raw)
In-Reply-To: <1295618465-15234-1-git-send-email-vishwanath.bs@ti.com>

Add Documentation for DVFS Framework

Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
---
 Documentation/arm/OMAP/omap_dvfs |  111 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 111 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/arm/OMAP/omap_dvfs

diff --git a/Documentation/arm/OMAP/omap_dvfs b/Documentation/arm/OMAP/omap_dvfs
new file mode 100644
index 0000000..b026643
--- /dev/null
+++ b/Documentation/arm/OMAP/omap_dvfs
@@ -0,0 +1,111 @@
+*=============*
+* DVFS Framework *
+*=============*
+(C) 2011 Vishwnath BS <vishwanath.bs@ti.com>, Texas Instruments Incorporated
+Contents
+--------
+1. Introduction
+2. Data Structure Organization
+3. DVFS APIs
+
+1. Introduction
+===============
+DVFS is a technique that uses the optimal operating frequency and voltage to
+allow a task to be performed in the required amount of time.
+OMAP processors have voltage domains whose voltage can be scaled to
+various levels depending on which the operating frequencies of certain
+devices belonging to the domain will also need to be scaled. This voltage
+frequency tuple is known as Operating Performance Point (OPP). A device
+can have multiple OPP's. Also a voltage domain could be shared between
+multiple devices. Also there could be dependencies between various
+voltage domains for maintaining system performance like VDD<X>
+should be at voltage v1 when VDD<Y> is at voltage v2.
+
+The design of this framework takes into account all the above mentioned points.
+To summarize the basic design of DVFS framework:-
+
+1. Have device opp tables for each device whose operating frequency can be
+   scaled. This is easy now due to the existance of hwmod layer which
+   allow storing of device specific info. The device opp tables contain
+   the opp pairs (frequency voltage tuples), the voltage domain pointer
+   to which the device belongs to, the device specific set_rate and
+   get_rate API's which will do the actual scaling of the device frequency
+   and retrieve the current device frequency.
+2. Introduce use counting on a per VDD basis. This is to take care multiple
+   requests to scale a VDD. The VDD will be scaled to the maximum of the
+   voltages requested.
+3. Keep track of all scalable devices belonging to a particular voltage
+   domain the voltage layer.
+4. Keep track of frequency requests for each of the device. This will enable
+   to scale individual devices to different frequency (even w/o scaling voltage
+   aka frequency throttling)
+5. Generic dvfs API that can be called by anybody to scale a device opp.
+   This API takes the device pointer and frequency to which the device
+   needs to be scaled to. This API then internally finds out the voltage
+   domain to which the device belongs to and the voltage to which the voltage
+   domain needs to be put to for the device to be scaled to the new frequency
+   from he device opp table. Then this API will add requested frequency into
+   the corresponding target device frequency list and add voltage request to
+   the corresponding vdd. Subsequently it calls voltage scale function which
+   will find out the highest requested voltage for the given vdd and scales
+   the voltage to the required one. It also runs through the list of all
+   scalable devices belonging to this voltage domain and scale them to the
+   appropriate frequencies using the set_rate pointer in the device opp tables.
+6. Handle inter VDD dependecies.
+
+
+2.  The Core DVFS data structure:
+=================================
+
+ 					|-------------------|			|-------------------|
+ 					|User2 (dev2, freq2)|			|User4 (dev4, freq4)|
+ 					|-------^-----------|			|-------^-----------|
+ 							|								|
+ 					|-------|-----------|			|-------|-----------|
+ 					|User1 (dev1, freq1)|			|User3 (dev3, freq3)|(omap_dev_user_list)
+ 					|-------^-----------|			|-------^-----------|
+                            |                               |
+ 						|---|--------------|             |------------------|
+ 		     |--------->| DEV1 (dev)       |------------>| DEV2 (dev)       |(omap_vdd_dev_list)
+ 			 |			|omap_dev_user_list|			 |omap_dev_user_list|
+ 			 |			|------------------|             |------------------|
+ 			 |
+   |---------|-----------|
+   |       VDD_n         |
+   |  omap_vdd_dev_list  |
+   |  omap_vdd_user_list |(omap_vdd_dvfs_info)
+   |                     |
+   |--------|------------|
+ 			|
+            |           |------------|  |------------|  |--------------|
+            |---------> | vdd_user1  |->|  vdd_user2 |->|   vdd_user3  | (omap_vdd_user_list)
+ 						| (dev, volt)|	| (dev, volt)|  | (dev, volt)  |
+ 						|------------|	|------------|	|--------------|
+
+3.  APIs:
+ =====
+ 1. omap_device_scale - Set a new rate at which the device is to operate
+
+  Examples:
+  1. Simple Device scaling:
+  Suppose module M wants to put device dev1 to frequency f1. Let's say that mdev
+  is the device * for module M. Then this could be achieved by
+  ret = omap_device_scale(mdev, dev1, f1)
+  if (ret)
+  	/* handle error *.
+
+  2. Frequency Throttling
+  Suppose say there are 2 modules M1 and M2 in Voltage domain VDDx.
+  Module M1 wants to set VDDx to OPP100 voltage which means M1 and M2 will
+  be running at OPP100 frequency. Suppose Module M2 wants to run at OPP50
+  frequency (say f2_opp50) instead of OPP100. This can be achieved by
+
+  /* this operation will place M1 and M2 to run at OPP100 */
+  ret = omap_device_scale(mdev1, dev1, f1_opp100);
+  if (ret)
+  	/* handle error *.
+
+  /* This operation will bring M2 to run at f2_opp50 w/o decreasing VDDx voltage */
+  ret = omap_device_scale(mdev2, dev2, f2_opp50);
+  if (ret)
+  	/* handle error *.
-- 
1.7.0.4


  parent reply	other threads:[~2011-01-21 13:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-21 14:00 [PATCH 00/13] OMAP: Basic DVFS Framework Vishwanath BS
2011-01-21 14:00 ` [PATCH 01/13] OMAP: Introduce accessory APIs for DVFS Vishwanath BS
2011-02-03  1:07   ` Kevin Hilman
2011-02-08 11:22     ` Vishwanath Sripathy
2011-02-09 15:35       ` Kevin Hilman
2011-01-21 14:00 ` [PATCH 02/13] OMAP: Introduce device specific set rate and get rate in omap_device structure Vishwanath BS
2011-02-03 23:46   ` Kevin Hilman
2011-02-07 13:36     ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 03/13] OMAP: Implement Basic DVFS Vishwanath BS
2011-02-04  1:14   ` Kevin Hilman
2011-02-07 14:18     ` Vishwanath Sripathy
2011-02-09 15:59       ` Kevin Hilman
2011-02-09 16:24         ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 04/13] OMAP: Introduce dependent voltage domain support Vishwanath BS
2011-02-04 15:37   ` Kevin Hilman
2011-02-07 14:34     ` Vishwanath Sripathy
2011-02-10 16:36       ` Kevin Hilman
2011-02-11  4:41         ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 05/13] OMAP: Introduce device scale implementation Vishwanath BS
2011-02-04 16:04   ` Kevin Hilman
2011-02-07 14:56     ` Vishwanath Sripathy
2011-02-10 16:37       ` Kevin Hilman
2011-01-21 14:00 ` [PATCH 06/13] OMAP: Disable Smartreflex across DVFS Vishwanath BS
2011-02-04 16:06   ` Kevin Hilman
2011-02-07 14:58     ` Vishwanath Sripathy
2011-01-21 14:00 ` [PATCH 07/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices Vishwanath BS
2011-02-04 16:08   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS support Vishwanath BS
2011-02-04 16:09   ` Kevin Hilman
2011-02-14  9:34   ` Kahn, Gery
2011-02-14 12:49     ` Vishwanath Sripathy
2011-02-14 13:03       ` Menon, Nishanth
2011-02-14 13:42         ` Vishwanath Sripathy
2011-02-14 15:35       ` Kahn, Gery
2011-04-13 14:13   ` Jarkko Nikula
2011-04-13 17:57     ` Vishwanath Sripathy
2011-04-14 12:28       ` Jarkko Nikula
2011-01-21 14:01 ` [PATCH 09/13] OMAP3: Introduce voltage domain info in the hwmod structures Vishwanath BS
2011-02-04 16:10   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 10/13] OMAP3: Add voltage dependency table for VDD1 Vishwanath BS
2011-01-29  0:31   ` Kevin Hilman
2011-01-30 12:59     ` Vishwanath Sripathy
2011-01-31 15:38       ` Kevin Hilman
2011-02-28 11:48     ` Jarkko Nikula
2011-01-21 14:01 ` [PATCH 11/13] OMAP2PLUS: Replace voltage values with Macros Vishwanath BS
2011-02-04 16:44   ` Kevin Hilman
2011-01-21 14:01 ` [PATCH 12/13] OMAP2PLUS: Enable various options in defconfig Vishwanath BS
2011-01-21 14:01 ` Vishwanath BS [this message]
2011-02-04  1:38   ` [PATCH 13/13] OMAP: Add DVFS Documentation Kevin Hilman
2011-01-22 17:18 ` [PATCH 00/13] OMAP: Basic DVFS Framework Felipe Balbi
2011-01-24  6:01   ` Vishwanath Sripathy
2011-01-24  6:18     ` Felipe Balbi
2011-01-24 14:25       ` Vishwanath Sripathy
2011-01-24 15:25         ` Laurent Pinchart
2011-01-24 15:29         ` Felipe Balbi
2011-01-24 20:00   ` Kevin Hilman
2011-01-25  3:53     ` Felipe Balbi
2011-02-01 12:27 ` Vishwanath Sripathy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295618465-15234-14-git-send-email-vishwanath.bs@ti.com \
    --to=vishwanath.bs@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=patches@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).