Common clock and dvfs

MyungJoo Ham myungjoo.ham at samsung.com
Fri May 6 04:13:25 EDT 2011


On Fri, May 6, 2011 at 6:08 AM, Cousson, Benoit <b-cousson at ti.com> wrote:
[]
>
> Devices will indeed never care about voltage directly, but that will happen
> indirectly because of:
> - voltage domains dependency: Changing the MPU or IVA voltage domain might
> force the CORE voltage to increase its voltage due to HW limitation. We
> cannot have the CPU at 1GHz while the interconnect is at the lowest OPP.
> - voltage domain increase due to one device frequency increase might force
> the other voltage domain devices to increase their frequency.
> - Thermal management might be a good example as well, but in general
> changing the main contributors frequency (MPU, GPU) should be enough.
>
> In both cases, the indirect voltage change will trigger potentially
> frequency change.
>
> vdd1 <--> vdd2
>  |         |
>  +----+    +----+
>  |    |    |    |
> devA devB devC devD
>
> With such partitioning, an increase of devA OPP, will increase vdd1 that
> will trigger an increase of vdd2 that will then broadcast to devices that
> belong to it. devC and devD might or not increase their frequency to reduce
> the energy consumption.
> Any devices like processors that can run fast and idle must run at the max
> frequency allowed by the current voltage.

As long as the voltage change in vdd1, which changes vdd2 (vdd1 and 2
are consumers of the same regulator, right?), can update OPP entries
related (enable/disable entries), devfreq can handle this.

If the clocks and devices (A~D) related are using devfreq, disabling,
enabling, and adding OPPs will instantly affect devfreq and adjust
clock frequency based on the enabled OPP entries only. Thus, if a
module is increasing the voltage, it just needs to disable some
low-voltage OPP entries although some set_min/max APIs mentioned by
Colin will be more useful.


-- 
MyungJoo Ham (함명주), Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858



More information about the linux-arm-kernel mailing list