From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751925AbdLMG63 (ORCPT ); Wed, 13 Dec 2017 01:58:29 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:48710 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751523AbdLMG6A (ORCPT ); Wed, 13 Dec 2017 01:58:00 -0500 From: "Gautham R. Shenoy" To: Shilpasri G Bhat , viresh.kumar@linaro.org, rjw@rjwysocki.net, huntbag@linux.vnet.ibm.com, akshay.adiga@linux.vnet.ibm.com, Michael Ellerman , Vaidyanathan Srinivasan , Balbir Singh Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "Gautham R. Shenoy" Subject: [v3 PATCH 0/3] powernv-cpufreq: Multiple pstate related fixes. Date: Wed, 13 Dec 2017 12:27:38 +0530 X-Mailer: git-send-email 1.8.3.1 X-TM-AS-GCONF: 00 x-cbid: 17121306-0056-0000-0000-000003F78F7C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008197; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00959492; UDB=6.00485256; IPR=6.00739513; BA=6.00005740; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018516; XFM=3.00000015; UTC=2017-12-13 06:57:58 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17121306-0057-0000-0000-0000082ECF3D Message-Id: <1513148261-21097-1-git-send-email-ego@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-13_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712130099 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Gautham R. Shenoy" This is a third version of the patch to fix pstate related issues in the powernv-cpufreq driver. The previous versions can be found here: [v2]: https://lkml.org/lkml/2017/12/7/1562 [v1]: https://lkml.org/lkml/2017/11/29/1338 On POWERNV platform, Pstates are 8-bit values. On POWER8 they are negatively numbered while on POWER9 they are positively numbered. Thus, on POWER9, the maximum number of pstates could be as high as 256. In multiple places, the current code interprets pstates as a signed 8-bit value which subsequently gets assigned to a signed integer variable. This causes a problem on POWER9 platforms which have more than 128 pstates. On such systems, on a CPU that is in a lower pstate whose number is greater than 128, querying the current pstate via the pstate_to_idx() returns a "pstate X is out of bound" error message and the current pstate is reported as the nominal pstate. This is due to the manner in which the bounds are checked in pstate_to_idx which again depends on the sign of pstates and whether the pstates max to min are monotonically increasing or decreasing. Further the current code makes a couple of assumptions which is not guaranteed by the device-tree bindings: 1) Pstate ids are continguous. 2) Every Pstate should always lie between the max and the min pstates that are explicitly reported in the device tree. Both these assumptions are unwarranted and can change on future platforms. In this patch-series, we fix the implementation via the following changes: PATCH 1: Define a helper function to correctly extract the pstates from the PMCR and take care of any sign extentions. This is an immediate fix to add the ability to handle more than 128 pstates on POWER9 systems. PATCH 2: Define a hash-map which will return the index into the cpufreq frequency table for a given pstate. Use this hashmap in the implementation of pstate_to_idx(). This does away with the assumptions (1) mentioned above, and will work with non continguous pstate ids. If no entry exists for a particular pstate, then such a pstate is treated as being out of bounds. This gets rid of assumption (2). PATCH 3: Treat pstates as opaque 8-bit values consistent with the definitions in the PMSR and PMCR. We no longer need any sign-extentions nor do we require to interpret the sign of the pstates anywhere in the code. Gautham R. Shenoy (3): powernv-cpufreq: Add helper to extract pstate from PMSR powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates powernv-cpufreq: Treat pstates as opaque 8-bit values drivers/cpufreq/powernv-cpufreq.c | 139 ++++++++++++++++++++++++-------------- 1 file changed, 90 insertions(+), 49 deletions(-) -- 1.9.4