On Wed, Apr 27, 2011 at 13:29, Colin Cross <ccross@xxxxxxxxxx> wrote:
> 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
Agreed, module runs on clocks - Lets say n clocks provide a module
it's functionality.
> 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,
we do have it - it depends on what the OPP table represents. we do
have modules which have both interface and functional clocks on OMAP
as well. for a module(represented by struct device *) which has n
clocks, choose the scheme of representation of clock that depends on
voltage for the module.
in the example you provided "the display block can have an interface
clock as well as a pixel clock" - I suppose you mean:
{.pclk = x, .iclk = y, .v = z}
The question I'd ask is this : for a voltage z, is the dependency on
pclk or iclk? I can expect a dependency of pclk to iclk requirement
(considering pixel clock drives an external display for example). the
table reduces to just
{.iclk = y, .v = z} and a different table that has divisor for .iclk
to pclk which is SoC based.
OPP table is just a storage and retrieval mechanism, it is upto SoC
frameworks to choose the most adequate of solutions - e.g. OMAP has
omap_device, hwmod and a clock framework for more intricate control to
work in conjunction with cpuidle frameworks as well.
There is cross domain dependency which OMAP (yet to be pushed to
mainline) has - example: when OMAP4's MPUs are at a certain OPP, L3
(OMAP's SoC bus) needs to be at least a certain OPP - these are
framework which may be very custom to OMAP itself.
---
Regards,
Nishanth Menon
--
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
