Hi Al,

On Mon, Aug 22, 2016 at 10:16 AM, Al Stone [off-list ref] wrote:

Maybe a top-post will get attention....

Yet another ping; this was first submitted on 20 July, and has received
no comments.  It has now been a month and other architectures are starting
to use CPPC so they will run into the same errors that this fixes.  Can
I get an ACK, NAK, or further instructions, please?

Apologies for the delay. I thought this patch was merged already.

Also adding Rafael on the ACPI side, just in case, since he's also reviewing
the Intel patches on the linux-acpi mailing list that are adding CPPC usage.

On 08/11/2016 12:15 PM, Al Stone wrote:

quoted

On 08/01/2016 02:31 PM, Viresh Kumar wrote:

quoted

[+ Ashwin's new email id..]

On 20-07-16, 15:10, Al Stone wrote:

quoted

When CPPC is being used by ACPI on arm64, user space tools such as
cpupower report CPU frequency values from sysfs that are incorrect.

What the driver was doing was reporting the values given by ACPI tables
in whatever scale was used to provide them.  However, the ACPI spec
defines the CPPC values as unitless abstract numbers.  Internal kernel
structures such as struct perf_cap, in contrast, expect these values
to be in KHz.  When these struct values get reported via sysfs, the
user space tools also assume they are in KHz, causing them to report
incorrect values (for example, reporting a CPU frequency of 1MHz when
it should be 1.8GHz).

The downside is that this approach has some assumptions:

   (1) It relies on SMBIOS3 being used, *and* that the Max Frequency
   value for a processor is set to a non-zero value.

   (2) It assumes that all processors run at the same speed, or that
   the CPPC values have all been scaled to reflect relative speed.
   This patch retrieves the largest CPU Max Frequency from a type 4 DMI
   record that it can find.  This may not be an issue, however, as a
   sampling of DMI data on x86 and arm64 indicates there is often only
   one such record regardless.  Since CPPC is relatively new, it is
   unclear if the ACPI ASL will always be written to reflect any sort
   of relative performance of processors of differing speeds.

   (3) It assumes that performance and frequency both scale linearly.

For arm64 servers, this may be sufficient, but it does rely on
firmware values being set correctly.  Hence, other approaches will
be considered in the future.

This has been tested on three arm64 servers, with and without DMI, with
and without CPPC support.

Changes for v5:
    -- Move code to cpufreq/cppc_cpufreq.c from acpi/cppc_acpi.c to keep
       frequency-related code together, and keep the CPPC abstract scale
       in ACPI (Prashanth Prakash)
    -- Fix the scaling to remove the incorrect assumption that frequency
       was always a range from zero to max; as a practical matter, it is
       not (Prasanth Prakash); this also allowed us to remove an over-
       engineered function to do this math.

This addresses my previous feedback. So FWIW, Acked-by: Ashwin
Chaugule [off-list ref]

Cheers,
Ashwin.