Re: [PATCH] omap-pm: Fixes behaviour of some shared resource framework functions

[Kevin Hilman <khilman@deeprootsystems.com>]

"Madhusudhan" <madhu.cr@ti.com> writes:

>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] 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@ti.com> 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@ti.com>
>> >
>> >
>> > 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