> ________________________________________ > From: Gopinath, Thara > Sent: Friday, June 04, 2010 4:20 PM > To: Gadiyar, Anand; Kevin Hilman; Mike Chan > Cc: linux-omap@vger.kernel.org; Paul Walmsley > Subject: RE: Future of resource framework? > > >>-----Original Message----- > >>From: linux-omap-ow...@vger.kernel.org > >>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > >>Gadiyar, Anand > >>Sent: Friday, June 04, 2010 8:32 AM > >>To: Kevin Hilman; Mike Chan > >>Cc: linux-omap@vger.kernel.org; Paul Walmsley > >>Subject: RE: Future of resource framework? > >> > >>Kevin Hilman wrote: > >>> 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.) > >>> > >> > >> > >>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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
