From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC] OMAP3 : PM : Handle variable length OPP tables
Date: Thu, 10 Sep 2009 11:29:36 -0700 [thread overview]
Message-ID: <87my528xgv.fsf@deeprootsystems.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301DD6C43CA@dbde02.ent.ti.com> (Sanjeev Premi's message of "Mon\, 7 Sep 2009 20\:09\:34 +0530")
"Premi, Sanjeev" <premi@ti.com> writes:
> Hi all,
>
> There is no generic function to translate an OPP to FREQ and vice versa.
> Came across the problem while trying to submit a follow-up to earlier
> patch for change in mpurate via bootargs.
>
> The function get_opp in resource34xx.c, but it is always called with an
> explicit addition of MAX_VDDn_OPP e.g.
>
> opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate);
> opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate);
>
> This is 'addition' is required as there is no encapsulation of the
> MIN and MAX VDDs associated to the table.
>
> The patch below fixes this issue; buy creating a 'table' object with
> necessary information. It can also help in getting rid of the
> empty {0, 0, 0} at index 0 of each OPP table.
>
> At the moment, it does not break any functionality in resource34xx.c;
> migration to this encapsulation can be taken as next step.
>
> This code is bare 'git-diff' for early comments. Formal patch to follow...
>
> Best regards,
> Sanjeev
Is the goal of the min and max fields so you could have some OPPs
in the table that aren't valid for some SoCs? IOW, the 'max' value
might be higher on newer SoCs with higher OPPs.
What if you want a list of OPPs, but want to remove one from the
middle of the list? The min/max approach doesn't work here.
What about a also extending the struct omap_opp to have some sort of
valid field.
Kevin
>
> diff --git a/arch/arm/plat-omap/include/mach/omap-pm.h b/arch/arm/plat-omap/include/mach/omap-pm.h
> index 583e540..2357784 100644
> --- a/arch/arm/plat-omap/include/mach/omap-pm.h
> +++ b/arch/arm/plat-omap/include/mach/omap-pm.h
> @@ -33,6 +33,20 @@ struct omap_opp {
> u16 vsel;
> };
>
> +/* struct omap_opp_table - View OPP table as an object
> + * @min: Minimum OPP id
> + * @max: Maximim OPP id
> + * @opps: Pointer to array defining the OPPs.
> + *
> + * An OPP table has varied length. Knowing minimum and maximum
> + * OPP ids allow easy traversal.
> + */
> +struct omap_opp_table {
> + u8 min;
> + u8 max;
> + struct omap_opp* opps;
> +};
> +
> extern struct omap_opp *mpu_opps;
> extern struct omap_opp *dsp_opps;
> extern struct omap_opp *l3_opps;
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index fec7d00..c90b1af 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -33,6 +33,7 @@
> #include <mach/powerdomain.h>
> #include <mach/resource.h>
> #include <mach/omap34xx.h>
> +#include <mach/omap-pm.h>
>
> #include "prm-regbits-34xx.h"
> #include "pm.h"
> @@ -281,3 +282,50 @@ static int __init omap_pm_init(void)
> return error;
> }
> late_initcall(omap_pm_init);
> +
> +/*
> + * Get frequency corresponding to an OPP
> + */
> +int opp_to_freq(unsigned int* freq, struct omap_opp_table* table, u8 opp)
> +{
> + int i, found=0;
> +
> + if (table && table->opps) {
> + for (i=table->min; table->opps[i].opp_id <= table->max; i++)
> + if (table->opps[i].opp_id == opp) {
> + found = 1;
> + break;
> + }
> +
> + if (found) {
> + *freq = table->opps[i].rate;
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Get OPP corresponding to a frequency
> + */
> +int freq_to_opp(u8* opp, struct omap_opp_table* table, unsigned long freq)
> +{
> + int i, found=0;
> +
> + if (table && table->opps) {
> + for (i=table->min; table->opps[i].opp_id <= table->max; i++)
> + if (table->opps[i].rate == freq) {
> + found = 1;
> + break;
> + }
> +
> + if (found) {
> + *opp = table->opps[i].opp_id;
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-09-10 18:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-07 14:39 [RFC] OMAP3 : PM : Handle variable length OPP tables Premi, Sanjeev
2009-09-10 18:29 ` Kevin Hilman [this message]
2009-09-11 6:12 ` Premi, Sanjeev
2009-09-11 21:21 ` Kevin Hilman
2009-09-14 11:06 ` Premi, Sanjeev
2009-09-30 18:10 ` Kevin Hilman
2009-09-30 18:13 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87my528xgv.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=premi@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox