linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Gopinath, Thara" <thara@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"khilman@deeprootsystems.com" <khilman@deeprootsystems.com>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
	"Sawant, Anand" <sawant@ti.com>,
	"Basak, Partha" <p-basak2@ti.com>
Subject: Re: [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures.
Date: Mon, 02 Aug 2010 14:10:45 +0200	[thread overview]
Message-ID: <4C56B5C5.2070504@ti.com> (raw)
In-Reply-To: <1278065909-32148-4-git-send-email-thara@ti.com>

Hi Thara,

On 7/2/2010 12:18 PM, Gopinath, Thara wrote:
> This patch extends the device opp structure to contain
> info about the voltage domain to which the device belongs to
> and to contain pointers to scale the operating rate of the
> device. This patch also adds an API in the opp layer that
> can be used by the voltage layer to get a list of all the
> scalable devices belonging to a particular voltage domain.
> This API is to be typically called only once by the voltage
> layer per voltage domain instance and the device list should
> be stored. This approach makes it easy during dvfs to scale
> all the devices associated with a voltage domain and then
> scale the voltage domain.
>
> Signed-off-by: Thara Gopinath<thara@ti.com>
> ---
>   arch/arm/plat-omap/include/plat/opp.h |   37 +++++++++++++++++++++++++-
>   arch/arm/plat-omap/opp.c              |   47 +++++++++++++++++++++++++-------
>   2 files changed, 72 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/opp.h b/arch/arm/plat-omap/include/plat/opp.h
> index 893731f..15e1e70 100644
> --- a/arch/arm/plat-omap/include/plat/opp.h
> +++ b/arch/arm/plat-omap/include/plat/opp.h
> @@ -16,6 +16,7 @@
>
>   #include<linux/err.h>
>   #include<linux/cpufreq.h>
> +#include<linux/clk.h>
>
>   #include<plat/common.h>
>
> @@ -38,21 +39,45 @@
>    */
>   struct omap_opp_def {
>   	char *hwmod_name;
> +	char *vdd_name;

vdd should be an attribute of hwmod. For one hwmod in a soc we will 
always have the same vdd.
That will avoid to duplicate information and to have to populate that in 
each OPP entry (cf patch 6).

>
>   	unsigned long freq;
>   	unsigned long u_volt;
>
> +	int (*set_rate)(struct device *dev, unsigned long rate);
> +	unsigned long (*get_rate) (struct device *dev);

We might already discussed that, but why should we store that per OPP?
Cannot we store that per device?

Regards,
Benoit

  parent reply	other threads:[~2010-08-02 12:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02 10:18 [RFC 0/7] OMAP: Basic DVFS framework Thara Gopinath
2010-07-02 10:18 ` [RFC 1/7] OMAP: Introduce a user list for each voltage domain instance in the voltage driver Thara Gopinath
2010-07-02 10:18   ` [RFC 2/7] OMAP: Introduce API in the OPP layer to find the opp entry corresponding to a voltage Thara Gopinath
2010-07-02 10:18     ` [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures Thara Gopinath
2010-07-02 10:18       ` [RFC 4/7] OMAP: Voltage layer changes to support DVFS Thara Gopinath
2010-07-02 10:18         ` [RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device layer Thara Gopinath
2010-07-02 10:18           ` [RFC 6/7] OMAP3: Update OMAP3 opp tables to contain the voltage domain and device set rate get rate info Thara Gopinath
2010-07-02 10:18             ` [RFC 7/7] OMAP3: Update cpufreq driver to use the new set_rate API Thara Gopinath
2010-07-08  3:10               ` Pandita, Vikram
2010-07-08  3:11                 ` Gopinath, Thara
2010-07-02 11:52           ` [RFC 5/7] OMAP: Introduce set_rate and get_rate API in omap device layer Sripathy, Vishwanath
2010-07-12 14:48       ` [RFC 3/7] OMAP: Introduce voltage domain pointer and device specific set rate and get rate in device opp structures Thomas Petazzoni
2010-07-12 16:01         ` Paul Walmsley
2010-08-02 12:10       ` Cousson, Benoit [this message]
2010-08-04  4:01         ` Gopinath, Thara
2010-08-04  0:32       ` Kevin Hilman
2010-08-04  4:02         ` Gopinath, Thara
2010-08-04 21:06           ` Kevin Hilman
2010-08-05  5:48             ` Gopinath, Thara
2010-07-02 11:44   ` [RFC 1/7] OMAP: Introduce a user list for each voltage domain instance in the voltage driver Sripathy, Vishwanath
2010-08-03 23:49 ` [RFC 0/7] OMAP: Basic DVFS framework Kevin Hilman
2010-08-04  3:54   ` Gopinath, Thara

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=4C56B5C5.2070504@ti.com \
    --to=b-cousson@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=p-basak2@ti.com \
    --cc=paul@pwsan.com \
    --cc=sawant@ti.com \
    --cc=thara@ti.com \
    --cc=vishwanath.bs@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;
as well as URLs for NNTP newsgroup(s).