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);
...
}
Now what happens if I have a dev with two frequencies,
>> Moreover, from a silicon perspective, there is always a simple link
>> from a single frequency to a minimum voltage for a given circuit.
>> There is no need to group them into OPPs, which seem to have a group
>> of clocks and their frequencies that map to a single voltage. That is
>> an artifact of the way TI specifies voltages.
>>
>> I don't think DVFS is even the right place for any sort of governor.
>> DVFS is very simple - to increase to a specific clock speed, the
>> voltage must be immediately be raised, with minimum or no delay, to a
>> specified value that is specific to that clock. When the frequency is
>> lowered, the voltage should be decreased. There is a tiny bit of
>> policy to determine when to delay dropping the voltage in case the
>> frequency will immediately be raised again, but nowhere near the
>> complexity of what is shown here.
>>
>> I proposed in a different thread on LKML that DVFS be handled within
>> the generic clock implementation. Platforms would register a
>> regulator and a table of voltages for each struct clock that required
>> DVFS, and the voltages would be changed on normal clk_* requests.
>> This maintains compatibility with existing clk_* calls.
>
> 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?
>
> 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.
>
>> There is a place for a GPU, etc., frequency governor, but it is a
>> completely separate issue from DVFS, and should not be mixed in. I
>> could have a GPU that is not voltage scalable, but could still benefit
>> from lowering the frequency when it is not in use. A devfreq
>> interface sounds perfect for this, as long as it only ends up calling
>> clk_* functions, and those functions handle getting the voltage
>> correct.
>
> Regards,
> Nishanth Menon
> PS:
> https://lists.linux-foundation.org/pipermail/linux-pm/2011-April/031113.html
> for start of thread
>
--
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
