1. 13 Dec, 2020 5 commits
    • Ionela Voinescu's avatar
      cppc_cpufreq: replace per-cpu data array with a list · 05540e8e
      Ionela Voinescu authored
      
      
      The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
      functional issues (2) when CPUs are hotplugged out, due to per-cpu data
      being improperly initialised.
      
      (1) The amount of information needed for CPPC performance control in its
          cpufreq driver depends on the domain (PSD) coordination type:
      
          ANY:    One set of CPPC control and capability data (e.g desired
                  performance, highest/lowest performance, etc) applies to all
                  CPUs in the domain.
      
          ALL:    Same as ANY. To be noted that this type is not currently
                  supported. When supported, information about which CPUs
                  belong to a domain is needed in order for frequency change
                  requests to be sent to each of them.
      
          HW:     It's necessary to store CPPC control and capability
                  information for all the CPUs. HW will then coordinate the
                  performance state based on their limitations and requests.
      
          NONE:   Same as HW. No HW coordination is expected.
      
          Despite this, the previous initialisation code would indiscriminately
          allocate memory for all CPUs (all_cpu_data) and unnecessarily
          duplicate performance capabilities and the domain sharing mask and type
          for each possible CPU.
      
      (2) With the current per-cpu structure, when having ANY coordination,
          the cppc_cpudata cpu information is not initialised (will remain 0)
          for all CPUs in a policy, other than policy->cpu. When policy->cpu is
          hotplugged out, the driver will incorrectly use the uninitialised (0)
          value of the other CPUs when making frequency changes. Additionally,
          the previous values stored in the perf_ctrls.desired_perf will be
          lost when policy->cpu changes.
      
      Therefore replace the array of per cpu cpu_data with a list. The memory
      for each structure is allocated at policy init, where a single structure
      can be allocated per policy, not per cpu. In order to accommodate the
      struct list_head node in the cppc_cpudata structure, the now unused cpu
      and cur_policy variables are removed.
      
      For example, on a arm64 Juno platform with 6 CPUs: (0, 1, 2, 3) in PSD1,
      (4, 5) in PSD2 - ANY coordination
      
      Memory allocation comparison shows:
      
      Before patch:
      
       - ANY coordination:
         total    slack      req alloc/free  caller
             0        0        0     0/1     _kernel_size_le_hi32+0x0xffff800008ff7810
             0        0        0     0/6     _kernel_size_le_hi32+0x0xffff800008ff7808
           128       80       48     1/0     _kernel_size_le_hi32+0x0xffff800008ffc070
           768        0      768     6/0     _kernel_size_le_hi32+0x0xffff800008ffc0e4
      
      After patch:
      
       - ANY coordination:
          total    slack      req alloc/free  caller
           256        0      256     2/0     _kernel_size_le_hi32+0x0xffff800008fed410
             0        0        0     0/2     _kernel_size_le_hi32+0x0xffff800008fed274
      
      Additional changes:
       - A pointer to the policy's cppc_cpudata is stored in policy->driver_data
       - All data allocation is done from the driver's init function
       - Driver registration is skipped if _CPC entries are not present.
      Signed-off-by: Ionela Voinescu's avatarIonela Voinescu <ionela.voinescu@arm.com>
      05540e8e
    • Ionela Voinescu's avatar
      ACPI: processor: fix NONE coordination for domain mapping failure · 64c06e9b
      Ionela Voinescu authored
      
      
      For errors parsing the _PSD domains, a separate domain is returned for
      each CPU in the failed _PSD domain with no coordination (as per previous
      comment). But contrary to the intention, the code was setting
      CPUFREQ_SHARED_TYPE_ALL as coordination type.
      
      Change shared_type to CPUFREQ_SHARED_TYPE_NONE in case of errors parsing
      the domain information. The function still returns the error and the caller
      is free to bail out the domain initialisation altogether in that case.
      
      Given that both functions return domains with a single CPU, this change
      does not affect the functionality, but clarifies the intention.
      Signed-off-by: Ionela Voinescu's avatarIonela Voinescu <ionela.voinescu@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Subject edit ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      64c06e9b
    • Ionela Voinescu's avatar
      cppc_cpufreq: expose information on frequency domains · 2784cef3
      Ionela Voinescu authored
      
      
      Use the existing sysfs attribute "freqdomain_cpus" to expose
      information to userspace about CPUs in the same frequency domain.
      Signed-off-by: Ionela Voinescu's avatarIonela Voinescu <ionela.voinescu@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      2784cef3
    • Ionela Voinescu's avatar
      cppc_cpufreq: clarify support for coordination types · a5e91e85
      Ionela Voinescu authored
      
      
      The previous coordination type handling in the cppc_cpufreq init code
      created some confusion: the comment mentioned "Support only SW_ANY for
      now" while only the SW_ALL/ALL case resulted in a failure. The other
      coordination types (HW_ALL/HW, NONE) were silently supported.
      
      Clarify support for coordination types while describing in comments the
      intended behavior.
      Signed-off-by: Ionela Voinescu's avatarIonela Voinescu <ionela.voinescu@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      a5e91e85
    • Ionela Voinescu's avatar
      cppc_cpufreq: use policy->cpu as driver of frequency setting · 51bb1532
      Ionela Voinescu authored
      
      
      Considering only the currently supported coordination types (ANY, HW,
      NONE), this change only makes a difference for the ANY type, when
      policy->cpu is hotplugged out. In that case the new policy->cpu will
      be different from ((struct cppc_cpudata *)policy->driver_data)->cpu.
      
      While in this case the controls of *ANY* CPU could be used to drive
      frequency changes, it's more consistent to use policy->cpu as the
      leading CPU, as used in all other cppc_cpufreq functions. Additionally,
      the debug prints in cppc_set_perf() would no longer create confusion
      when referring to a CPU that is hotplugged out.
      Signed-off-by: Ionela Voinescu's avatarIonela Voinescu <ionela.voinescu@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      51bb1532
  2. 11 Dec, 2020 35 commits