e Rajashekar, Madhusudhan
> Cc: Turquette, Mike; Dasgupta, Romit; Cousson, Benoit; 'Paul Walmsley';
> linux-omap@vger.kernel.org; Titiano, Patrick
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
>
> "Madhusudhan" writes:
> An assumption in this thread is that ondemand/conservative can't scale
> fast enough, but that is not true. The Android UI sluggishness
> mentioned by Benoit was solved by lowering the cpufreq
> transition_latency time from 10 million ns to 300,000ns. I have not
> gotten the exact worst case ti
t; 'Paul Walmsley'; linux-omap@vger.kernel.org; Titiano, Patrick
>> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
>> framework functions
>>
>> Kevin Hilman wrote:
>> > "Dasgupta, Romit" writes:
>> >
>> >> H
tiano, Patrick
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
>
> Kevin Hilman wrote:
> > "Dasgupta, Romit" writes:
> >
> >> Hello Benoit,
> >> One comment below:
> >
Kevin Hilman wrote:
"Dasgupta, Romit" writes:
Hello Benoit,
One comment below:
In fact, this is Mike who started that analysis. We discussed that internally
and
our point is that if the CPUFreq ondemand or conservative heuristic is not able
to increase quickly enough
"Dasgupta, Romit" writes:
> Hello Benoit,
> One comment below:
>>
>> In fact, this is Mike who started that analysis. We discussed that
>> internally and
>> our point is that if the CPUFreq ondemand or conservative heuristic is not
>> able
>> to increase quickly enough
Hello Benoit,
One comment below:
>
> In fact, this is Mike who started that analysis. We discussed that internally
> and
> our point is that if the CPUFreq ondemand or conservative heuristic is not
> able
> to increase quickly enough the CPU need to handle correctly the U
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > >> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> > >> Sent: Wednesday, October 28, 2009 1:38 PM
> > >> To: Kevin Hilman
> > >> Cc: Dasgupta\, Romit; l
On Thu, Oct 29, 2009 at 01:09:25PM +0530, Dasgupta, Romit wrote:
[Reflowed into 80 columns - you might want to look at your MUA setup.]
> The sampling intervals for the cpufreq governors are quite large
> and thus the latency for the frequency change to occur is large.
> This was s
ginal Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Thursday, October 29, 2009 4:15 AM
> To: Chikkature Rajashekar, Madhusudhan
> Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@vger.kernel.org'
> Subject: Re: [PATCH] omap-pm: Fixes behavio
Romit; linux-om...@vger.kernel.org
>> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
>> framework functions
>>
>> On Tue, 13 Oct 2009, Kevin Hilman wrote:
>>
>> > "Dasgupta, Romit" writes:
>> >
>> &
PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
>
> On Tue, 13 Oct 2009, Kevin Hilman wrote:
>
> > "Dasgupta, Romit" writes:
> >
> > > (Tested on Zoom2).
> > >
> > > 'omap_pm_dsp_set_min_opp' &
On Tue, 13 Oct 2009, Kevin Hilman wrote:
> "Dasgupta, Romit" writes:
>
> > (Tested on Zoom2).
> >
> > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> > struct device *. This is a problem because invoking these functions from
> > different clients would result in setting
On Tue, 13 Oct 2009, Kevin Hilman wrote:
> "Dasgupta, Romit" writes:
>
> > (Tested on Zoom2).
> >
> > 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> > struct device *. This is a problem because invoking these functions from
> > different clients would result in setting
"Dasgupta, Romit" writes:
> (Tested on Zoom2).
>
> 'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
> struct device *. This is a problem because invoking these functions from
> different clients would result in setting of the resource level as requested
> by
> the last cal
of some shared resource framework
functions
(Tested on Zoom2).
'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
struct device *. This is a problem because invoking these functions from
different clients would result in setting of the resource level
(Tested on Zoom2).
'omap_pm_dsp_set_min_opp' & 'omap_pm_cpu_set_freq' were using their own
struct device *. This is a problem because invoking these functions from
different clients would result in setting of the resource level as requested by
the last caller. Fixes this by introducing a struct de
17 matches
Mail list logo
