archive mirror
 help / color / mirror / Atom feed
	Taniya Das <>,
	Rajendra Nayak <>,
	Amit Nischal <>
Subject: [RFD] Voltage dependencies for clocks (DVFS)
Date: Mon, 18 Jun 2018 13:44:39 -0700	[thread overview]
Message-ID: <> (raw)

Hi All,

A number of vendors, including Qualcomm, support sophisticated digital 
voltage rail management based on the state (rate and enable) of each 
clock in the system.  In a Qualcomm SOC we require the ability to assert 
a vote on both a regulator enable and voltage corner (essentially a 
quantified voltage level) when clocks are enabled or have their rate 
set.  Importantly, if a clock is disabled, it must release its required 
voltage vote.
In general clients of the clock framework are not aware of the mapping 
between their performance level (clock rate) and voltage requirement, 
because it comes as part of the clock controller design and not the core 
design, and also because the clock controller elements themselves have 
voltage requirements that must be included in the relationship (i.e. 
PLLs need minimum voltage levels to operate at a given output 

The solution we have deployed for many years is to associate a regulator 
and voltage level with each clock rate, and manage voting for the 
associated regulator in the clock framework during state changes.  There 
are two issues with this solution that have been raised by maintainers:

1. The use of the regulator framework to track voltage corners has been 
deemed invalid.  We are in the process of changing our implementation to 
use genpd, which is being modified to support aggregation, and is viewed 
as acceptable in principle.
2. In some SOCs, control over voltages may itself require enabling or 
configuring a clock (think an I2C regulator for example).  In such a 
design, the regulator->clock and clock->regulator dependencies 
introduces a potential deadlock.

The second concern above is the more challenging.  A proposal to use OPP 
to manage core DVFS has been made, but suffers from three major 
problems: first, it requires clients to use OPP for setting their rate, 
but the clock framework for other control (i.e. enable or disable). Not 
only is this confusing and (I would claim) ugly, it would also be very 
easy for clients to accidentally call clk_set_rate directly instead of 
going via OPP, resulting in invalid DVFS operating points.  The second 
problem is that OPP does not allow for removing a voltage vote entirely 
when the clock is disabled - which is a fundamental requirement for the 
design to be power optimal.  The third problem is that semantically 
using OPP for requesting specific functional frequencies (i.e. for a  
serial bus) is an abuse of that framework.  It requires the clients to 
find the "performance level" that matches the specific frequency they 
require, then request that performance level - when what they really 
want is to "set rate" on the clock to a specific, known, frequency.

We have avoided the deadlock concern in Qualcomm SOCs by never having a 
clock dependency to control a voltage rail.  This is admittedly not a 
good general solution (although it does appear to be perfectly 
acceptable for current SOCs that have such clock/voltage requirements).

So the question to everybody is how to manage clock-driven DVFS in a 
safe and acceptable fashion?  Would an integrated solution in the clock 
framework with a requirement that SOCs using it not have a 
regulator->clock path be acceptable (it works for us at least)?


             reply	other threads:[~2018-06-18 20:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 20:44 grahamr [this message]
2018-07-02  5:13 ` [RFD] Voltage dependencies for clocks (DVFS) Michael Turquette
2018-07-04  6:55 ` Viresh Kumar
2018-07-04 12:50   ` Ulf Hansson
2018-07-04 12:54     ` Rafael J. Wysocki
2018-07-04 12:58       ` Ulf Hansson
2018-07-20 17:12     ` Stephen Boyd
2018-07-20 17:56       ` Michael Turquette
2018-07-24 23:13         ` Stephen Boyd
2018-07-25  5:51           ` Michael Turquette
2018-07-23  8:26       ` Peter De Schrijver
2018-07-24 23:04         ` Stephen Boyd
2018-07-25  5:44           ` Michael Turquette
2018-07-25 11:27             ` Peter De Schrijver
2018-07-25 18:40               ` Michael Turquette
2018-07-31 11:56               ` Ulf Hansson
2018-07-31 20:02                 ` grahamr
2018-08-23 13:20                   ` Ulf Hansson
2018-09-18 23:00                     ` Michael Turquette
2018-09-19  7:05                       ` Geert Uytterhoeven
2018-09-19 18:07                         ` Michael Turquette
2018-09-25 13:11                           ` Geert Uytterhoeven
2018-09-25 13:11                             ` Geert Uytterhoeven
2018-09-25 21:26                       ` grahamr
2018-09-25 21:26                         ` grahamr
2018-10-01 19:00                         ` Michael Turquette
2018-10-04  0:37                           ` Graham Roff
2018-10-04 21:23                             ` Michael Turquette
2018-09-18 17:25                   ` Kevin Hilman
2018-08-03 23:05                 ` Michael Turquette
2018-08-23 12:13                   ` Ulf Hansson
2018-09-18 22:48                     ` Michael Turquette
2018-07-31 10:35       ` Ulf Hansson
2018-08-03 21:11         ` Michael Turquette
2018-08-23 11:10           ` Ulf Hansson
2018-07-05  8:19 ` Peter De Schrijver

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).