Re: Future of resource framework?

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

 



On Thu, Jun 3, 2010 at 4:52 PM, Kevin Hilman
<khilman@xxxxxxxxxxxxxxxxxxx> 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.)
>

I saw a little bit on lkml / linux-pm but I may have missed some of the threads.
I'm assuming these changes you're talking about are going to be an
extension to pm qos.

> 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.
>

I think for OMAP we will be ok with the existing / incremental changes
to the SRF. Your overview of the pie-in-the-sky might be promising but
I'm not sure how timely things will happen. I suppose I should track
linux-pm more closely, I'd rather not do a bunch of throw-away work on
pm qos.

-- Mike

> Kevin
>
--
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