From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S941655AbcKQR2l (ORCPT <rfc822;w@1wt.eu>);
        Thu, 17 Nov 2016 12:28:41 -0500
Received: from cmta18.telus.net ([209.171.16.91]:57102 "EHLO cmta18.telus.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932261AbcKQR1V (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 17 Nov 2016 12:27:21 -0500
X-Authority-Analysis: v=2.2 cv=RoIqFGuK c=1 sm=1 tr=0
 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17
 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=IkcTkHD0fZMA:10 a=YdQ60KfAI7ElewTniLcA:9
 a=QEXdDO2ut3YA:10
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
        "'Srinivas Pandruvada'" <srinivas.pandruvada@linux.intel.com>
Cc: "'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>,
        "'Linux PM list'" <linux-pm@vger.kernel.org>
References: 6pwucKlLvdmHH6pwzcpEkV
In-Reply-To: 6pwucKlLvdmHH6pwzcpEkV
Subject: RE: [PATCH v2] cpufreq: intel_pstate: Generic governors support
Date: Thu, 17 Nov 2016 09:27:15 -0800
Message-ID: <000301d240f7$d86604b0$89320e10$@net>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdI/sQhoe2HECVA2QDKYZFHc2OAEXQAn4UYQ
Content-Language: en-ca
X-CMAE-Envelope: MS4wfObv6GJDWXjtO8FionwVyXyTHCIkPijGrnHtJG/2u3UNHxYyvkhOkj2gZ8/1tU/fgWVV4vSWx7uh7UXNjO5xaLtBHTHltppMDnlX1LFs5z4OfvcHr/Nl
 cfx77Y2klixRxgMjBCGtq5jwPdpfruonC0MDpCanBjnbtbsZsOxr8hUqEqNoXMPUpupEMA/8XVpzKI5pDLAXpPZfjziZJVMz9o2IjDsIlG6PIEeFS7GxrkWr
 m1NWPAif+iWIuF/iyDckHoA63MGK8tADxEJTbmVWmntLaeuJ91F882dON2f1aLBb
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2016.11.15 18:35 Rafael J. Wysocki wrote:

> -> v2:
> Notice that intel_cpufreq_target() generally can be called on a CPU
> different from the target one, so it needs to ensure that the right
> MSR will be written, so update the code accordingly.  This makes
> the performance and powersave governors work with this driver as
> expected (at least).

With V2 I did the exact same tests with the ondemand, powersave,
and performance governors as I did with the previous versions 
of this patch. Now everything works fine and as expected.

Thanks.

Also from this previous reply to 
"[RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support":

On 2016.11.01 17:14 Srinivas Pandruvada wrote:
> On Tue, 2016-11-01 at 14:11 -0700, Doug Smythies wrote:
>> On 2016.10.22 17:17 Rafael J. Wysocki wrote: 
>> 
>> It is not clear to me why users that currently use
>> intel_pstate=disable on the kernel command line would benefit from
>> this change.
> Two reasons I think:
> - We have a big turbo zone, where current acpi-cpufreq can't select any
> target frequency even if controllable.
>
> - We can still target ACPI-CPPC compatible devices in legacy mode and
> later in non-legacy mode.

V2 also fixes the test results (I was using clock modulation as
my test case), that caused me to erroneously think there would
be no benefit from intel_pstate=passive over intel_pstate=disable
in cases where the user has to use disable for proper operation.

... Doug