"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
