On Fri, May 6, 2011 at 6:08 AM, Cousson, Benoit <b-cousson@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
