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