[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOMWX4f2ZtfiK35caboPdsq7a0hfn5vp282fE3OaKvK=xzrX8Q@mail.gmail.com>
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