linux-kernel - Re: [PATCH 1/4] cpufreq: OMAP: if an iva clock name is specified, load iva resources

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20121107210753.GA23274@kahuna>
Date:	Wed, 7 Nov 2012 15:07:53 -0600
From:	Nishanth Menon <nm@...com>
To:	<jemele@....org>
CC:	Kevin Hilman <khilman@...com>, "Rafael J. Wysocki" <rjw@...k.pl>,
	<linux-omap@...r.kernel.org>, <cpufreq@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] cpufreq: OMAP: if an iva clock name is specified,
 load iva resources

On 11:16-20121107, Joshua Emele wrote:
> On Wed, Nov 7, 2012 at 6:53 AM, Nishanth Menon <nm@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/