All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Gopinath, Thara" <thara@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
	"Sawant, Anand" <sawant@ti.com>,
	"Cousson, Benoit" <b-cousson@ti.com>
Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain
Date: Mon, 20 Sep 2010 11:00:31 -0700	[thread overview]
Message-ID: <87iq20xpkw.fsf@deeprootsystems.com> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB0329539FDB@dbde02.ent.ti.com> (Thara Gopinath's message of "Fri, 17 Sep 2010 20:18:02 +0530")

"Gopinath, Thara" <thara@ti.com> writes:

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Thursday, September 16, 2010 8:52 PM
>>>To: Gopinath, Thara
>>>Cc: linux-omap@vger.kernel.org; paul@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit
>>>Subject: Re: [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage
>>>domain
>>>
>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>[...]
>>>
>>>>>>> +struct device **opp_init_voltage_params(struct voltagedomain *voltdm,
>>>>>>> +					int *dev_count)
>>>>>>> +{
>>>>>>> +	struct device_opp *dev_opp;
>>>>>>> +	struct device **dev_list;
>>>>>>> +	int count = 0, i = 0;
>>>>>>> +
>>>>>>> +	list_for_each_entry(dev_opp, &dev_opp_list, node) {
>>>>>>> +		if (!dev_opp->oh->vdd_name)
>>>>>>> +			continue;
>>>>>>> +
>>>>>>> +		if (!strcmp(dev_opp->oh->vdd_name, voltdm->name)) {
>>>>>>> +			dev_opp->oh->voltdm = voltdm;
>>>>>>
>>>>>>Couldn't we assign the voltdm at opp_add() time since you added it as
>>>>>>part of the hwmod?
>>>>
>>>> We cannot as the voltage layer is not initialized at the point of opp_add.
>>>> Having said this, today voltage layer is dependent on opp layer only to figure out
>>>> the current nominal voltage from the opp table. If that can be some how decoupled we
>>>> can initialize voltage layer early on and implement this.
>>>
>>>We could decouple the voltage init into and early init and late init to
>>>handle this.
>
> Hello Kevin,
>
> Yes we could. In fact I do not like the idea of voltage layer
> dependent on opp layer itself. So here is my proposal. Maintain a
> variable in the main per vdd structure omap_vdd_info curr_volt which
> will get updated each time a voltage scale is attempted.

OK

> Now the only issue is during boot up how does the voltage layer know
> what voltage each vdd should be put into ? A piece of code can be
> implemented in pm34xx.c/pm44xx.c init functions to read the clock rate
> associated with each vdd , call into the opp layer to get the
> corresponding voltage ( basically the sequence we do today everytime
> in voltage layer when the API to get nominal voltage is called) and
> call omap_voltage_scale_vdd with the corresponding voltage. This way
> we can fully decouple voltage laye from opp layer and make voltage
> init an early_initcall. We might still need a late_initcall to
> register debugfs entries though.  What is your take on this ?

Not sure I fully follow this suggestions, but why not just wait until 
both OPP and voltage late init are fully done before allowing any
voltage scaling?

Alternatively, I just did a quick experiment and the device_initcall in
pm.c (that initializes the MPU, IVA/DSP and L3 devices, as well as does
the OPP layer init) could be made a subsys_initcall, so that by the time
SR + voltage are init'd (using device_initcall), OPP layer is fully
initialized.

Kevin

  reply	other threads:[~2010-09-20 18:00 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18 11:19 [PATCH 00/13] OMAP: Basic DVFS framework Thara Gopinath
2010-08-18 11:20 ` [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver Thara Gopinath
2010-08-27 23:53   ` Kevin Hilman
2010-08-30 22:56     ` Kevin Hilman
2010-09-16  9:59     ` Gopinath, Thara
2010-09-16 15:20       ` Kevin Hilman
2010-09-17 14:33         ` Gopinath, Thara
2010-09-01 22:51   ` Kevin Hilman
2010-09-02  7:43     ` Thomas Petazzoni
2010-09-02  8:17       ` Nishanth Menon
2010-09-02 10:00         ` Felipe Balbi
2010-09-02 10:17           ` Nishanth Menon
2010-09-02 10:28             ` Felipe Balbi
2010-09-02 10:40               ` Nishanth Menon
2010-09-02 11:16                 ` Felipe Balbi
2010-09-02 17:47         ` Kevin Hilman
2010-09-02 18:46           ` Nishanth Menon
2010-09-02 18:56             ` Kevin Hilman
2010-09-03  7:09     ` Gopinath, Thara
2010-09-03 16:41       ` Kevin Hilman
2010-09-03 17:30         ` Mark Brown
2010-09-03 18:00           ` Kevin Hilman
2010-09-03 18:20             ` Mark Brown
2010-09-06 19:59               ` Eduardo Valentin
2010-09-06 20:21                 ` Liam Girdwood
2010-09-06 21:21                 ` Mark Brown
2010-11-23  9:26               ` Thomas Petazzoni
2010-11-24  9:45               ` Thomas Petazzoni
2010-11-24  9:51                 ` Mark Brown
2010-09-03 18:27       ` Kevin Hilman
2010-09-06 11:01         ` Mark Brown
2010-08-18 11:20 ` [PATCH 02/13] OMAP: Introduce API in the OPP layer to find the opp entry corresponding to a voltage Thara Gopinath
2010-08-18 11:20 ` [PATCH 03/13] OMAP: Introduce voltage domain information in the hwmod structures Thara Gopinath
2010-08-18 11:20 ` [PATCH 04/13] OMAP: Introduce API to return a device list associated with a voltage domain Thara Gopinath
2010-08-28  0:52   ` Kevin Hilman
2010-08-28  0:54     ` Kevin Hilman
2010-09-16 10:04     ` Gopinath, Thara
2010-09-16 15:22       ` Kevin Hilman
2010-09-17 14:48         ` Gopinath, Thara
2010-09-20 18:00           ` Kevin Hilman [this message]
2010-09-02  0:33   ` Kevin Hilman
2010-09-16 10:10     ` Gopinath, Thara
2010-09-16 15:23       ` Kevin Hilman
2010-08-18 11:20 ` [PATCH 05/13] OMAP: Introduce device specific set rate and get rate in device opp structures Thara Gopinath
2010-09-02 23:41   ` Kevin Hilman
2010-09-16 10:21     ` Gopinath, Thara
2010-09-16 15:28       ` Kevin Hilman
2010-09-17 14:55         ` Gopinath, Thara
2010-09-18 10:13           ` Cousson, Benoit
2010-09-20 17:35             ` Kevin Hilman
2010-09-29 11:16             ` Gopinath, Thara
2010-09-29 20:25               ` Cousson, Benoit
2010-08-18 11:20 ` [PATCH 06/13] OMAP: Voltage layer changes to support DVFS Thara Gopinath
2010-08-18 11:20 ` [PATCH 07/13] OMAP: Introduce dependent voltage domain support Thara Gopinath
2010-08-18 11:20 ` [PATCH 08/13] OMAP: Introduce device set_rate and get_rate Thara Gopinath
2010-08-18 11:20 ` [PATCH 09/13] OMAP: Disable smartreflex across DVFS Thara Gopinath
2010-08-18 11:20 ` [PATCH 10/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices Thara Gopinath
2010-08-31  0:06   ` Kevin Hilman
2010-08-18 11:20 ` [PATCH 11/13] OMAP3: Update cpufreq driver to use the new set_rate API Thara Gopinath
2010-08-18 11:20 ` [PATCH 12/13] OMAP3: Introduce voltage domain info in the hwmod structures Thara Gopinath
2010-08-18 11:20 ` [PATCH 13/13] OMAP3: Add voltage dependency table for VDD1 Thara Gopinath

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=87iq20xpkw.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.