On Wed, Apr 27, 2011 at 11:48 AM, Menon, Nishanth <nm@xxxxxx> wrote:
> 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.
No, there can be voltage requirements on both, and the higher voltage
requirement of the two must be used.
> 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
