> -----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. Regards, Madhu > > > - Paul > -- > 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 -- 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
