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