On Thu, Apr 28, 2011 at 3:37 AM, Colin Cross <ccross@xxxxxxxxxx> wrote:
> (sorry, missent the earlier one)
>
> On Wed, Apr 27, 2011 at 11:07 AM, Menon, Nishanth <nm@xxxxxx> wrote:
>> On Wed, Apr 27, 2011 at 12:49, Colin Cross <ccross@xxxxxxxxxx> wrote:
>> +l-o
>>
>>> I'm a little confused about the design for this, and OPP as well. ÂOPP
>>> matches a struct device * and a frequency to a voltage, which is not a
>>> generically useful pairing, as far as I can tell. ÂOn Tegra, it is
>>> quite possible for a single device to have multiple clocks that each
>>> have different voltage requirements, for example the display block can
>>> have an interface clock as well as a pixel clock. ÂSimplifying this to
>>> dev + freq = voltage seems very OMAP specific, and will be difficult
>>> or impossible to adapt to Tegra.
>> We have the same requirements as well(iclk,fclk,pixclk etc..)! We
>> group them under voltage domains in OMAP ;). if your issue was a
>> ability to have a single freq to a OPP, it is upto SoC to do the
>> proper mapping. Concept of an OPP still remains consistent - which is
>> for a voltage, there is only so much freq you can drive that specific
>> module to.
> No, that is still wrong. ÂYou don't drive a module at a frequency, you
> drive a clock. ÂYou can't map struct device * 1-1 to a clock. ÂLook at
> omap2_set_init_voltage:
> static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âstruct device *dev) {
> Â Â Â Â...
> ÂÂ Â Â Âclk = Âclk_get(NULL, clk_name);
> ÂÂ Â Â Âfreq = clk->rate;
> ÂÂ Â Â Âopp = opp_find_freq_ceil(dev, &freq);
> ÂÂ Â Â Â...
> }
>
> What happens if I have a dev with two frequencies? ÂI can only pass a
> dev into opp. ÂIt makes infinitely more sense to pass in a clock:
> opp_find_freq_ceil(clk, &freq).
What one instance of DVFS (devfreq) controls are clocks and
regulators. (a device may have multiple regulators as well as multiple
clocks)
What one instance of DVFS (devfreq) monitors (device load and/or
temperature) is a device that uses the clocks and regulators.
If we focus on the things that are controlled by DVFS, connecting DVFS
with clock seems fine; however, DVFS's decision is based on the status
of the device and the decision (monitoring result) configures a set of
clocks and regulators. The clocks are not configured independently
from others if the clocks are used by a DVFS-capable device. The
frequency/voltage pair (OPP in this patch) associated with a device
becomes a representative value of a specific configuration that
configures the set of clocks and regulators.
This is quite similar with CPUFREQ. CPUFREQ provides a single
frequency value as a result of monitoring; however the machine's
cpufreq driver may set multiple clocks and multiple voltage regulators
based on the representative value (which is usually the core clock)
although the cpufreq driver may need to control many more clocks with
different frequencies.
With multiple clocks of a device, if there is a clock that is required
to be set independently from the "representative" clock with DVFS, it
means that the DVFS monitoring result (load/temperature) is not a
scalar value but a vector (multi-dimensional value). That implies that
we need to monitor different and independent values, which in turn,
implies that we need separated devices. Note that the DVFS monitor
result from load and temperature combined is not a multi-dimensional
value because the temperature limits "maximum possible frequency or
voltage" and the load gives "preferred lower bound of frequency" that
can be overridden by the limit set by temperature.
Therefore, having one DVFS per clock where multiple clocks are
attached to a device will create multiple monitors that monitor the
same object(device behavior) with same metrics (load and temperature).
Besides, the reason I've started with "target" callback, not clk and
regulator names or pointers is that a device may have multiple clks
and regulators and the OPP may only show the representative
clock/regulators as CPUFREQ does. Especially when the order of
transitions of those multiple clocks and regulators matter (if they
are in a single device, it sometimes does), running a DVFS per clock,
not per device, will be bothersome if not disasterous.
>
>> It is upto SoC frameworks to implement the transitions. E.g. lets look
>> at scalability: How'd the mechanism proposed work with temperature
>> variances: Example: I dont want to hit 1.5GHz if temp >70C - wont it
>> be an SoC specific hack I'd need to introduce?
> No, because you're putting it in the wrong place, that is a policy
> decision. ÂHandle it in the clock framework, or handle it in the
> device driver. ÂThat's a bad example either way - what happens if you
> are already at 1.5GHz when the temperature crosses 70C? ÂYou need an
> interrupt that tells you the temperature is too high, and than needs
> to affect a policy decision at a much higher level than dvfs.
>
>>
>> All OPP framework does is store that maps, and leaves it to users to
>> choose regulators, clock framework variances, SoC temperature sensors
>> or what ever mechanisms they choose to allow through a transition.
> I understand its just a map, but its a map between two things that
> don't have a direct mapping in many SoCs. ÂI think if you changed
> every usage of struct dev * in opp to struct clk *, it would make much
> more sense. ÂThere is already a mapping from struct dev * to struct
> clk *, its called clk_get, and it takes a second parameter to allow
> devices to have multiple clocks.
Anyway, I agree that we need either one of the followings (at least in
the future)
1) OPP mapped with clock
or
2) multiple OPPs mapped with a dev, each OPP with a clock of the dev.
Still, DVFS(devfreq) would be better linked directly with a device
although we will need to tell which OPP of the device or which clock's
OPP should be linked as representative clock OPP.
> _______________________________________________
> linux-pm mailing list
> linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
Cheers!
- MyungJoo
--
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
