linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: jemele@acm.org
Cc: Kevin Hilman <khilman@ti.com>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	linux-omap@vger.kernel.org, cpufreq@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] cpufreq: OMAP: if an iva clock name is specified, load iva resources
Date: Wed, 7 Nov 2012 15:07:53 -0600	[thread overview]
Message-ID: <20121107210753.GA23274@kahuna> (raw)
In-Reply-To: <CALH_86ST1kF_csak_75Dk7dDupOqdCT=H11MKBeLsiyqi5vd_w@mail.gmail.com>

On 11:16-20121107, Joshua Emele wrote:
> On Wed, Nov 7, 2012 at 6:53 AM, Nishanth Menon <nm@ti.com> wrote:
> 
> > On 17:47-20121106, Joshua Emele wrote:
> > > +static int __cpuinit omap_iva_init(struct cpufreq_policy *policy)
> > > +{
> > > +     int result;
> > > +     if (!iva_clk_name) {
> > > +             pr_info("%s: iva unavailable\n", __func__);
> > > +             return 0;
> > > +     }
> > > +     iva_dev = omap_device_get_by_hwmod_name("iva");
> >
> > NAK. Reasons as follows:
> > a) cpufreq is purely meant for cpu, not IVA. we should instead be using
> > devfreq which is designed around the usage for co-processor
> > b) clubbing ARM's frequency decision is definitely NOT equal to IVA
> > frequency decision, not only is it wrong in terms of modularization, it
> > is wrong in terms of power benefits as well (not to mention weirdness
> > needed when you look at all OMAP SoC variants)
> > c) DVFS is not trivial around multiple co-processor transitions -> core
> > OPPs (as dependent OPP) needs to be addressed as well. ideally common
> > clock framework could take care of clock dependencies.
> It looks like you've done some work on an omap devfreq coprocessor driver (
> http://pastebin.pandaboard.org/index.php/view/85100576). Are there any
> plans to merge this driver?
It is an sample driver about how it could be done - this was not in any
form meant for merge. there are few angles to it:
a) ability for coprocessors to provide load and idle information back to
master processor
b) integrating it into regular existing framework.

Yes, the need is definitely identified, there are many different
solutions floating around in TI kernel forks, devfreq at the moment
seems to be the rationale choice in terms of a solution that is aligned
with community needs, so we are slowly building towards it.

Any contributions towards that is very appreciated ofcourse :). the
quick reference to latest code meant for 3.8 rc1 target could be found
here:
http://git.kernel.org/?p=linux/kernel/git/mzx/devfreq.git;a=summary

-- 
Regards,
Nishanth Menon

  parent reply	other threads:[~2012-11-07 21:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07  1:47 [PATCH 0/4] cpufreq: OMAP: if available, scale the iva coprocessor Joshua Emele
2012-11-07  1:47 ` [PATCH 1/4] cpufreq: OMAP: if an iva clock name is specified, load iva resources Joshua Emele
2012-11-07 14:53   ` Nishanth Menon
     [not found]     ` <CALH_86ST1kF_csak_75Dk7dDupOqdCT=H11MKBeLsiyqi5vd_w@mail.gmail.com>
2012-11-07 21:07       ` Nishanth Menon [this message]
2012-11-07  1:47 ` [PATCH 2/4] cpufreq: OMAP: for omap3 devices, specify the iva clock name Joshua Emele
2012-11-07  1:47 ` [PATCH 3/4] cpufreq: OMAP: ensure the iva coprocessor is at the same opp as the mpu Joshua Emele
2012-11-07  1:47 ` [PATCH 4/4] cpufreq: OMAP: scale the iva coprocessor if available Joshua Emele
2012-11-07 14:42 ` [PATCH 0/4] cpufreq: OMAP: if available, scale the iva coprocessor Santosh Shilimkar

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=20121107210753.GA23274@kahuna \
    --to=nm@ti.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=jemele@acm.org \
    --cc=khilman@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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).