RE: Future of resource framework?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> ________________________________________
> From: Gopinath, Thara
> Sent: Friday, June 04, 2010 4:20 PM
> To: Gadiyar, Anand; Kevin Hilman; Mike Chan
> Cc: linux-omap@xxxxxxxxxxxxxxx; Paul Walmsley
> Subject: RE: Future of resource framework?
> 
> >>-----Original Message-----
> >>From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of
> >>Gadiyar, Anand
> >>Sent: Friday, June 04, 2010 8:32 AM
> >>To: Kevin Hilman; Mike Chan
> >>Cc: linux-omap@xxxxxxxxxxxxxxx; Paul Walmsley
> >>Subject: RE: Future of resource framework?
> >>
> >>Kevin Hilman wrote:
> >>> Mike Chan <mike@xxxxxxxxxxx> writes:
> >>>
> >>> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
> >>> > <khilman@xxxxxxxxxxxxxxxxxxx> wrote:
> >>> >> Mike Chan <mike@xxxxxxxxxxx> writes:
> >>> >>
> >>> >>> I'm not sure if this has been discussed, yet but since it seems that
> >>> >>> the resource framework will not be making it upstream, I am curious
> >>> >>> what are the replacements under consideration. I am starting to see
> >>> >>> similar issues on other platforms (msm / tegra) so more generic
> >>> >>> (non-omap) solution might be something to consider.
> >>> >>
> >>> >> Hi Mike,
> >>> >>
> >>> >> Which parts of the SRF do you currently use and find useful?  It would
> >>> >> be helpful for us to to understand the parts you see as useful and
> >>> >> potentially helpful to generalize.
> >>> >>
> >>> >
> >>> > Off the top of my head, for Droid specifically, OPP values are useful,
> >>> > although in theory if you changed OPP requests to cpu throughput that
> >>> > might give the equivalent functionality.
> >>> >
> >>> > Memory bus speeds / bandwidth, although its tied to CPU, which
> >>> > ultimately ends up in a cpu speed bump.
> >>> >
> >>> > Although most of the usage I've seen are just hacks, ie: the driver
> >>> > knows it needs 550mhz from the cpu so it will request some bogus
> >>> > value.
> >>> >
> >>> >
> >>> >> As you know, the current implementation has a several layers
> >>> >> and attempts to manage several things: OPPs, latencies etc.
> >>> >>
> >>> >> Our current plans are essentially to break up the "one framework to
> >>> >> rule them all" philosophy and design of SRF and manage the various
> >>> >> pieces by exending other layers such as the new OPP layer and voltage
> >>> >> layers.  Latencies are being managed by the omap_device layer and we
> >>> >> will hopefully have some discussions with the broader linux-pm
> >>> >> community about generalizing that more into the generic driver model
> >>> >> over this year.
> >>> >>
> >>> >
> >>> > Bus speed is a common resource I see for omap / msm / tegra. Clocks
> >>> > for devices also.
> >>> >
> >>> > ie: If I'm doing heavy mem operation and need max memory bus, I might
> >>> > need to request higher performance. (which might mean 600mhz on
> >>> > omap34030, on msm it might mean AXI clock running at 128mhz, and
> >>> > something else on tegra).
> >>> >
> >>> > Or if I'm doing graphics, I may need to up the gfx clock rate, or
> >>> > swich which pll its sourcing etc.. etc..
> >>> >
> >>> > It doesn't look like pm qos has bus support, or even clock support,
> >>> > and this gets tricky if you want something semi-general.
> >>>
> >>> What we're hoping to work towards (and has come up in the suspend
> >>> blocker related discussions) is moving towards a way to track
> >>> per-device (or per-subsystem) constraints like latency and throughput
> >>> in real world terms (usecs, bytes/sec, etc.) that would be general
> >>> way.
> >>>
> >>> These constraints would then be visible to the bus- or
> >>> platform-specific code that could make intelligent decisions with them
> >>> (i.e whether or not to raise/lower OPP or bus speed, or whether or not
> >>> to power down a powerdomain etc.)
> >>>
> >>
> >>
> >>What if a driver knows that it cannot afford to let the PM layer
> >>turn off the power domain at certain points of time (maybe as long
> >>as a USB cable is connected). How can this be specified in terms
> >>of a latency or throughput constraint?
> >>
> >>Just curious, since I don't understand current OMAP3 PM code
> >>as well as I would like to.
> 
> Latency should internally map to a power domain state for the power domain
> associated with the device. And the SRF/new replacement fmwk should take care
> of taking requests from all devices associated with a power domain and
> programming the power domain to hit the accepted low power state.

Sure. But how do I pick a latency number, when that's not quite what the
driver wants.

The driver wants to prevent "loss of hardware context" - which is a different
"real world" term than latency.

- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux