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]
Date:	Mon, 5 Dec 2011 19:18:28 -0600
From:	"Menon, Nishanth" <nm@...com>
To:	khugans@...eaurora.org
Cc:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	skannan@...eaurora.org, mattw@...eaurora.org,
	jchokshi@...eaurora.org, sboyd@...eaurora.org
Subject: Re: Extending OPP Functionality

Hi,
On Mon, Dec 5, 2011 at 19:12, <khugans@...eaurora.org> wrote:
> We have a number of drivers that manage power/performance levels in their
> own ways and we are looking for a way to consolidate these similar
> implementations in one place.  We want to scale multiple voltage levels,
> clocks and bandwidth requests along with each other. For example our L2
> depends on two power rail voltages.
yes, most SoCs have independent voltage rails as well.

> We’ve observed that OPP tackles this for single voltage-frequency pair,
> but doesn’t manage additional data that may be associated with
> performance/power levels.  Would it make sense to extend OPP to handle
> implementation-specific data pointers to handle this generically?
Initial design of OPP library was to tackle the problem of having a generic
definition of an OPP. the wider question is do we want OPP library as purely
a data storage and retrieval entity or do we want to extend  the way devfreq
layer currently does forward and move regulators and others under OPP
library, my personal opinion of gluing that information should be in
higher levels
and not restrict based on what kind of framework is being used to represent
clock or voltage (not all SoCs might have regulator implementation for
voltage rails OR some might have extensions that are not completely scalable).

Just my 2 cents - but the extension by itself is trivial.

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/

Powered by blists - more mailing lists