Future of resource framework?

Future of resource framework?

[Mike Chan]

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.

-- Mike

Re: Future of resource framework?

[Nishanth Menon]

Mike Chan had written, on 05/20/2010 05:37 PM, the following:
> 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
http://marc.info/?l=linux-omap&m=127206504624556&w=2 (we are getting to 
the one month expiry date btw..)

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

I know of one by Sanjeev Premi:
[1] http://marc.info/?l=linux-omap&m=125716806431649&w=2
it should be rather trivial to adapt it to opp layer and make it work.

-- 
Regards,
Nishanth Menon

Re: Future of resource framework?

[Kevin Hilman]

Mike Chan <mike@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.

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.

For the OPP management parts, you should expect RFC patches in the
next week or two that will start discussions on this.

Thanks for the input,

Kevin

Re: Future of resource framework?

[Mike Chan]

On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Mike Chan <mike@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.

-- Mike

> For the OPP management parts, you should expect RFC patches in the
> next week or two that will start discussions on this.
>
> Thanks for the input,
>
> Kevin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Future of resource framework?

[Kevin Hilman]

Mike Chan <mike@android.com> writes:

> On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>> Mike Chan <mike@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Future of resource framework?

[Mike Chan]

On Thu, Jun 3, 2010 at 4:52 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> Mike Chan <mike@android.com> writes:
>
>> On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
>> <khilman@deeprootsystems.com> wrote:
>>> Mike Chan <mike@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.)
>

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Future of resource framework?

[Gadiyar, Anand]

Kevin Hilman wrote:
> Mike Chan <mike@android.com> writes:
> 
> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
> > <khilman@deeprootsystems.com> wrote:
> >> Mike Chan <mike@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.

- Anand

RE: Future of resource framework?

[Gopinath, Thara]

>>-----Original Message-----
>>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@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 <mike@android.com> writes:
>>>
>>> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
>>> > <khilman@deeprootsystems.com> wrote:
>>> >> Mike Chan <mike@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.

Regards
Thara

RE: Future of resource framework?

[Gadiyar, Anand]

> ________________________________________
> 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-owner@vger.kernel.org [mailto:linux-omap-owner@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 <mike@android.com> writes:
> >>>
> >>> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
> >>> > <khilman@deeprootsystems.com> wrote:
> >>> >> Mike Chan <mike@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

Re: Future of resource framework?

[Mike Chan]

On Thu, Jun 3, 2010 at 8:01 PM, Gadiyar, Anand <gadiyar@ti.com> wrote:
> Kevin Hilman wrote:
>> Mike Chan <mike@android.com> writes:
>>
>> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
>> > <khilman@deeprootsystems.com> wrote:
>> >> Mike Chan <mike@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?
>

Are there cases for this in omap? From what I've seen with omap3430
(atleast our hw configuration for Droid) we haven't run into this
case.

If you want to prevent a particular domain from entering RET or OFF, I
believe you'd have to look at the latency values in the cpuidle34xx.c
(or whatever it maybe called in .35) and match those latency in your
driver against the PM_QOS_CPU_DMA_LATENCY. The omap cpuidle registers
a table of various cpu states, which are a combination of ON, RET and
OFF for various domains. (Note only handles a few domains so maybe you
need to extend the table or rev a new constraint type or something to
pm_qos).

It seems kind of hacky and not very general, but I've only seen a need
for something like this on msm7k / msm8k, and the need was an msm
specific driver and have not yet seen a need for this on omap[3403] or
tegra but things could change.

-- Mike

> Just curious, since I don't understand current OMAP3 PM code
> as well as I would like to.
>
> - Anand
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Future of resource framework?

[Felipe Balbi]

On Fri, Jun 04, 2010 at 05:01:49AM +0200, ext Gadiyar, Anand wrote:
>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.

that should be simple if you set latency to 10us or mpu frequency to 
500MHz should do it.

-- 
balbi

DefectiveByDesign.org

RE: Future of resource framework?

[Gopinath, Thara]

>>-----Original Message-----
>>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Mike
>>Chan
>>Sent: Tuesday, June 08, 2010 1:00 AM
>>To: Gadiyar, Anand
>>Cc: Kevin Hilman; linux-omap@vger.kernel.org; Paul Walmsley
>>Subject: Re: Future of resource framework?
>>
>>On Thu, Jun 3, 2010 at 8:01 PM, Gadiyar, Anand <gadiyar@ti.com> wrote:
>>> Kevin Hilman wrote:
>>>> Mike Chan <mike@android.com> writes:
>>>>
>>>> > On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
>>>> > <khilman@deeprootsystems.com> wrote:
>>>> >> Mike Chan <mike@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?
>>>
>>
>>Are there cases for this in omap? From what I've seen with omap3430
>>(atleast our hw configuration for Droid) we haven't run into this
>>case.
>>
>>If you want to prevent a particular domain from entering RET or OFF, I
>>believe you'd have to look at the latency values in the cpuidle34xx.c
>>(or whatever it maybe called in .35) and match those latency in your
>>driver against the PM_QOS_CPU_DMA_LATENCY. The omap cpuidle registers
>>a table of various cpu states, which are a combination of ON, RET and
>>OFF for various domains. (Note only handles a few domains so maybe you
>>need to extend the table or rev a new constraint type or something to
>>pm_qos).
>>
>>It seems kind of hacky and not very general, but I've only seen a need
>>for something like this on msm7k / msm8k, and the need was an msm
>>specific driver and have not yet seen a need for this on omap[3403] or
>>tegra but things could change.

PM_QOS takes care of interrupt and dma latencies which today in OMAP boils down
to MPU and Core power domain states. But this will not take care of other individual
power domains. For preventing other power domains from entering low power states,
there are power domain constraint in the SRF which again takes latencies and converts
them into power domain states.

But, yes if you want to prevent power domains from entering low power states for
Non-latency reasons like hw bug etc there is no clean solution. You ll have to
have a hack and use a dummy latency value and achieve the same.

Regards
Thara

>>
>>-- Mike
>>
>>> Just curious, since I don't understand current OMAP3 PM code
>>> as well as I would like to.
>>>
>>> - Anand
>>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html