Mike Chan <m...@android.com> writes: > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman > <khil...@deeprootsystems.com> wrote: >> Mike Chan <m...@android.com> 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.) That's the pie-in-the-sky future I'm hoping for, and I hope to get some broader discussions around this going at some conferences this later year (LinuxCon in Aug, Plumbers in Nov, etc.) We had some early discussions in this direction at ELC already, but it needs some more thought and discussion. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
