Skip to content
Snippets Groups Projects
  1. Jun 28, 2022
  2. Jun 23, 2022
  3. May 30, 2022
  4. May 19, 2022
  5. May 17, 2022
  6. May 12, 2022
  7. May 11, 2022
  8. May 10, 2022
  9. May 09, 2022
  10. May 07, 2022
  11. May 06, 2022
    • Pierre Gondois's avatar
      cpufreq: CPPC: Register EM based on efficiency class information · 740fcdc2
      Pierre Gondois authored
      
      Performance states and energy consumption values are not advertised
      in ACPI. In the GicC structure of the MADT table, the "Processor
      Power Efficiency Class field" (called efficiency class from now)
      allows to describe the relative energy efficiency of CPUs.
      
      To leverage the EM and EAS, the CPPC driver creates a set of
      artificial performance states and registers them in the Energy Model
      (EM), such as:
      - Every 20 capacity unit, a performance state is created.
      - The energy cost of each performance state gradually increases.
      No power value is generated as only the cost is used in the EM.
      
      During task placement, a task can raise the frequency of its whole
      pd. This can make EAS place a task on a pd with CPUs that are
      individually less energy efficient.
      As cost values are artificial, and to place tasks on CPUs with the
      lower efficiency class, a gap in cost values is generated for adjacent
      efficiency classes.
      E.g.:
      - efficiency class = 0, capacity is in [0-1024], so cost values
        are in [0: 51] (one performance state every 20 capacity unit)
      - efficiency class = 1, capacity is in [0-1024], cost values
        are in [1*gap+0: 1*gap+51].
      
      The value of the cost gap is chosen to absorb a the energy of 4 CPUs
      at their maximum capacity. This means that between:
      1- a pd of 4 CPUs, each of them being used at almost their full
         capacity. Their efficiency class is N.
      2- a CPU using almost none of its capacity. Its efficiency class is
         N+1
      EAS will choose the first option.
      
      This patch also populates the (struct cpufreq_driver).register_em
      callback if the valid efficiency_class ACPI values are provided.
      
      Signed-off-by: default avatarPierre Gondois <Pierre.Gondois@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      740fcdc2
    • Pierre Gondois's avatar
      cpufreq: CPPC: Add per_cpu efficiency_class · d3c3db41
      Pierre Gondois authored
      
      In ACPI, describing power efficiency of CPUs can be done through the
      following arm specific field:
      ACPI 6.4, s5.2.12.14 'GIC CPU Interface (GICC) Structure',
      'Processor Power Efficiency Class field':
        Describes the relative power efficiency of the associated pro-
        cessor. Lower efficiency class numbers are more efficient than
        higher ones (e.g. efficiency class 0 should be treated as more
        efficient than efficiency class 1). However, absolute values
        of this number have no meaning: 2 isn’t necessarily half as
        efficient as 1.
      
      The efficiency_class field is stored in the GicC structure of the
      ACPI MADT table and it's currently supported in Linux for arm64 only.
      Thus, this new functionality is introduced for arm64 only.
      
      To allow the cppc_cpufreq driver to know and preprocess the
      efficiency_class values of all the CPUs, add a per_cpu efficiency_class
      variable to store them.
      
      At least 2 different efficiency classes must be present,
      otherwise there is no use in creating an Energy Model.
      
      The efficiency_class values are squeezed in [0:#efficiency_class-1]
      while conserving the order. For instance, efficiency classes of:
        [111, 212, 250]
      will be mapped to:
        [0 (was 111), 1 (was 212), 2 (was 250)].
      
      Each policy being independently registered in the driver, populating
      the per_cpu efficiency_class is done only once at the driver
      initialization. This prevents from having each policy re-searching the
      efficiency_class values of other CPUs. The EM will be registered in a
      following patch.
      
      The patch also exports acpi_cpu_get_madt_gicc() to fetch the GicC
      structure of the ACPI MADT table for each CPU.
      
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarPierre Gondois <Pierre.Gondois@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d3c3db41
    • Viresh Kumar's avatar
      cpufreq: Avoid unnecessary frequency updates due to mismatch · f55ae08c
      Viresh Kumar authored
      
      For some platforms, the frequency returned by hardware may be slightly
      different from what is provided in the frequency table. For example,
      hardware may return 499 MHz instead of 500 MHz. In such cases it is
      better to avoid getting into unnecessary frequency updates, as we may
      end up switching policy->cur between the two and sending unnecessary
      pre/post update notifications, etc.
      
      This patch has chosen allows the hardware frequency and table frequency
      to deviate by 1 MHz for now, we may want to increase it a bit later on
      if someone still complains.
      
      Reported-by: Rex-BC Chen's avatarRex-BC Chen <rex-bc.chen@mediatek.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Tested-by: default avatarJia-wei Chang <jia-wei.chang@mediatek.com>
      Reviewed-by: default avatarMatthias Brugger <matthias.bgg@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f55ae08c
    • Rex-BC Chen's avatar
      cpufreq: mediatek: Add opp notification support · c210063b
      Rex-BC Chen authored
      
      From this opp notifier, cpufreq should listen to opp notification and do
      proper actions when receiving events of disable and voltage adjustment.
      
      One of the user for this opp notifier is MediaTek SVS.
      The MediaTek Smart Voltage Scaling (SVS) is a hardware which calculates
      suitable SVS bank voltages to OPP voltage table.
      
      Signed-off-by: default avatarAndrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
      Signed-off-by: default avatarJia-Wei Chang <jia-wei.chang@mediatek.com>
      Signed-off-by: Rex-BC Chen's avatarRex-BC Chen <rex-bc.chen@mediatek.com>
      Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
      [ Viresh: Renamed opp_freq as current_freq and moved its initialization ]
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      c210063b
    • Jia-Wei Chang's avatar
      cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking() · 6a17b387
      Jia-Wei Chang authored
      
      Because the difference of sram and proc should in a range of min_volt_shift
      and max_volt_shift. We need to adjust the sram and proc step by step.
      
      We replace VOLT_TOL (voltage tolerance) with the platform data and update the
      logic to determine the voltage boundary and invoking regulator_set_voltage.
      
      - Use 'sram_min_volt' and 'sram_max_volt' to determine the voltage boundary
        of sram regulator.
      - Use (sram_min_volt - min_volt_shift) and 'proc_max_volt' to determine the
        voltage boundary of vproc regulator.
      
      Moreover, to prevent infinite loop when tracking voltage, we calculate the
      maximum value for each platform data.
      We assume min voltage is 0 and tracking target voltage using
      min_volt_shift for each iteration.
      The retry_max is 3 times of expeted iteration count.
      
      Signed-off-by: default avatarJia-Wei Chang <jia-wei.chang@mediatek.com>
      Signed-off-by: Rex-BC Chen's avatarRex-BC Chen <rex-bc.chen@mediatek.com>
      Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      6a17b387
    • Rex-BC Chen's avatar
      cpufreq: mediatek: Move voltage limits to platform data · ead858bd
      Rex-BC Chen authored
      
      Voltages and shifts are defined as macros originally.
      There are different requirements of these values for each MediaTek SoCs.
      Therefore, we add the platform data and move these values into it.
      
      Signed-off-by: default avatarJia-Wei Chang <jia-wei.chang@mediatek.com>
      Signed-off-by: Rex-BC Chen's avatarRex-BC Chen <rex-bc.chen@mediatek.com>
      Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      ead858bd
    • Rex-BC Chen's avatar
      cpufreq: mediatek: Unregister platform device on exit · f126fbad
      Rex-BC Chen authored
      
      We register the platform device when driver inits. However, we do not
      unregister it when driver exits.
      
      To resolve this, we declare the platform data to be a global static
      variable and rename it to be "cpufreq_pdev". With this global variable,
      we can do platform_device_unregister() when driver exits.
      
      Fixes: 501c574f ("cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC")
      Signed-off-by: Rex-BC Chen's avatarRex-BC Chen <rex-bc.chen@mediatek.com>
      [ Viresh: Commit log and Subject ]
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      f126fbad
  12. Apr 27, 2022
  13. Apr 26, 2022
Loading