On 08/22/2016 11:45 AM, Ashwin Chaugule wrote: > Hi Al, > > On Mon, Aug 22, 2016 at 10:16 AM, Al Stone <a...@redhat.com> 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.
I've looked in linux-next and linux-pm; I could have missed it, but I didn't see it...my bad, if I did. >> 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: >>> On 08/01/2016 02:31 PM, Viresh Kumar wrote: >>>> [+ Ashwin's new email id..] >>>> >>>> On 20-07-16, 15:10, Al Stone wrote: >>>>> 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 <ashwi...@google.com> > > Cheers, > Ashwin. > Thanks, Ashwin. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com -----------------------------------
