Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 6/17/2019 9:47 AM, Viresh Kumar wrote:
On 17-06-19, 09:37, Rajendra Nayak wrote:


On 6/17/2019 9:20 AM, Viresh Kumar wrote:
On 14-06-19, 10:57, Viresh Kumar wrote:
Hmm, so this patch won't break anything and I am inclined to apply it again :)

Does anyone see any other issues with it, which I might be missing ?

I have updated the commit log a bit more to clarify on things, please let me
know if it looks okay.

      opp: Don't overwrite rounded clk rate
      The OPP table normally contains 'fmax' values corresponding to the
      voltage or performance levels of each OPP, but we don't necessarily want
      all the devices to run at fmax all the time. Running at fmax makes sense
      for devices like CPU/GPU, which have a finite amount of work to do and
      since a specific amount of energy is consumed at an OPP, its better to
      run at the highest possible frequency for that voltage value.
      On the other hand, we have IO devices which need to run at specific
      frequencies only for their proper functioning, instead of maximum
      possible frequency.
      The OPP core currently roundup to the next possible OPP for a frequency
      and select the fmax value. To support the IO devices by the OPP core,
      lets do the roundup to fetch the voltage or performance state values,
      but not use the OPP frequency value. Rather use the value returned by
      clk_round_rate().
      The current user, cpufreq, of dev_pm_opp_set_rate() already does the
      rounding to the next OPP before calling this routine and it won't
      have any side affects because of this change.

Looks good to me. Should this also be documented someplace that dev_pm_opp_set_rate()
would not be able to distinguish between its users trying to scale CPU/GPU's vs IO
devices, so its the callers responsibility to round it accordingly before calling the
API?

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0fbc77f05048..bae94bfa1e96 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -751,8 +751,11 @@ static int _set_required_opps(struct device *dev,
   * @dev:        device for which we do this operation
   * @target_freq: frequency to achieve
   *
- * This configures the power-supplies and clock source to the levels specified
- * by the OPP corresponding to the target_freq.
+ * This configures the power-supplies to the levels specified by the OPP
+ * corresponding to the target_freq, and programs the clock to a value <=
+ * target_freq, as rounded by clk_round_rate(). Device wanting to run at fmax
+ * provided by the opp, should have already rounded to the target OPP's
+ * frequency.
   */

Perfect, thanks.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux