mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Extending OPP Functionality
@ 2011-12-06  1:12 khugans
  2011-12-06  1:18 ` Menon, Nishanth
  0 siblings, 1 reply; 2+ messages in thread
From: khugans @ 2011-12-06  1:12 UTC (permalink / raw)
  To: nm; +Cc: linux-pm, linux-kernel, skannan, mattw, jchokshi, sboyd

Hi Nishanth Menon,

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.

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?

Thanks,
Khugan



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Extending OPP Functionality
  2011-12-06  1:12 Extending OPP Functionality khugans
@ 2011-12-06  1:18 ` Menon, Nishanth
  0 siblings, 0 replies; 2+ messages in thread
From: Menon, Nishanth @ 2011-12-06  1:18 UTC (permalink / raw)
  To: khugans; +Cc: linux-pm, linux-kernel, skannan, mattw, jchokshi, sboyd

Hi,
On Mon, Dec 5, 2011 at 19:12, <khugans@codeaurora.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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-12-06  1:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-06  1:12 Extending OPP Functionality khugans
2011-12-06  1:18 ` Menon, Nishanth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®