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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20121107145352.GA15742@kahuna>
Date:	Wed, 7 Nov 2012 08:53:52 -0600
From:	Nishanth Menon <nm@...com>
To:	Joshua Emele <jemele@...il.com>
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 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.

-- 
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/