Paul/Kevin,
As Madhu explained it looks like there are instances where we forcibly need to bump up to a higher CPU + L3 frequencies (VDD1 + VDD2 scaling). I understand that this should be done by cpufreq governors but here is reason that I think the current cpufreq governors won't be able to handle.
Large latency response:
The sampling intervals for the cpufreq governors are quite large and thus the latency for the frequency change to occur is large. This was seen in Android UI responsiveness. The initial response of the UI seems to be quite sluggish until after a while when the cpufreq governors would catch up to the required MIPS. I know that Patrick (Cc'd) did some experiments with conservative governor but my understanding is that it still has this basic problem.
Tied to the above is necessity for high MIPS for short duration:
I also presume that there might be situations where we need very high MIPS but for a very very short interval of time. This would never bump up the frequency as it would more or less be ignored by the cpufreq governors.
Please let me know what you think.
Thanks,
-Romit
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, October 29, 2009 4:15 AM
> To: Chikkature Rajashekar, Madhusudhan
> Cc: 'Paul Walmsley'; Dasgupta, Romit; 'linux-omap@xxxxxxxxxxxxxxx'
> Subject: Re: [PATCH] omap-pm: Fixes behaviour of some shared resource
> framework functions
>
> "Madhusudhan" <madhu.cr@xxxxxx> writes:
>
> >> -----Original Message-----
> >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> >> owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley
> >> Sent: Wednesday, October 28, 2009 1:38 PM
> >> To: Kevin Hilman
> >> Cc: Dasgupta\, Romit; linux-omap\@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" <romit@xxxxxx> 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 caller. Fixes this by introducing a struct device * to the
> >> parameter
> >> > > list for these functions.
> >> > > Signed-off-by: Romit Dasgupta <romit@xxxxxx>
> >> >
> >> >
> >> > This looks like the right fix to me.
> >> >
> >> > Paul, any comments?
> >>
> >>
> >> Wait a minute, I am retracting my ack.
> >>
> >>
> >> Romit, the only caller of omap_pm_dsp_set_min_opp() should be
> DSPBridge
> >> and the only caller of omap_pm_cpu_set_freq() should be CPUFreq. So the
> >> struct device * pointer is not necessary, unless I am missing something.
> >> Can you please explain what you're trying to do?
> >>
> > I believe that omap_pm_cpu_set_freq() can be called by drivers to setup the
> > optimal vdd1 opp, right? For example MMC works at opp1 but the
> performance
> > is certainly better at opp3.When ondemand is enabled drivers need to put
> > certain constraints on vdd1 opp otherwise performance will be hurt. So, if
> > the API takes care of device level calls then drivers can call this fn.
>
> So, the root use case is a power vs. performance policy decision. And
> using the proposed solution, a single driver gets to make a system
> wide policy decision. I don't like this.
>
> For your MMC usecase, I think we need some clarifications.
>
> What exactly does "better" performance mean. Is it better throughput
> that is needed? or is it really the MPU side that is not
> running/responding fast enough.
>
> If it's throughput, then omap_pm_set_min_bus_tput() should be used.
>
> If it's the MPU, what exactly is the problem with ondemand. Is it
> that it doesn't respond fast enough? Or that it never switches to a
> higher OPP.
>
> 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
