Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932333AbcJLH6G (ORCPT ); Wed, 12 Oct 2016 03:58:06 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:44792 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754521AbcJLH5u (ORCPT ); Wed, 12 Oct 2016 03:57:50 -0400 From: Stewart Smith To: Gautham R Shenoy , Balbir Singh Cc: Michael Ellerman , "Gautham R. Shenoy" , "skiboot\@lists.ozlabs.org" , Benjamin Herrenschmidt , Paul Mackerras , "Rafael J. Wysocki" , Daniel Lezcano , Michael Neuling , Vaidyanathan Srinivasan , "Shreyas B. Prabhu" , Shilpasri G Bhat , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH 2/2] powernv: Pass PSSCR value and mask to power9_idle_stop In-Reply-To: <20161007072058.GC13873@in.ibm.com> References: <21e080ffa52f432b40750028a624aee1baebbaf7.1475130107.git.ego@linux.vnet.ibm.com> <87int84d6w.fsf@concordia.ellerman.id.au> <0e7ad8ff-8c44-86bc-f560-258bc7b29a32@gmail.com> <20161007072058.GC13873@in.ibm.com> User-Agent: Notmuch/0.21+24~gbceb651 (http://notmuchmail.org) Emacs/25.1.1 (x86_64-redhat-linux-gnu) Date: Wed, 12 Oct 2016 16:35:35 +1100 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16101205-0028-0000-0000-000005CAA6CB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005896; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000186; SDB=6.00767222; UDB=6.00367072; IPR=6.00543375; BA=6.00004803; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012958; XFM=3.00000011; UTC=2016-10-12 05:35:43 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16101205-0029-0000-0000-00002FF610A3 Message-Id: <87lgxuf7tk.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-12_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120091 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4306 Lines: 107 Gautham R Shenoy writes: > On Tue, Oct 04, 2016 at 10:33:27PM +1100, Balbir Singh wrote: >> >> >> On 04/10/16 21:32, Michael Ellerman wrote: >> > "Gautham R. Shenoy" writes: >> > >> >> From: "Gautham R. Shenoy" >> >> >> >> The power9_idle_stop method currently takes only the requested stop >> >> level as a parameter and picks up the rest of the PSSCR bits from a >> >> hand-coded macro. This is not a very flexible design, especially when >> >> the firmware has the capability to communicate the psscr value and the >> >> mask associated with a particular stop state via device tree. >> >> >> >> This patch modifies the power9_idle_stop API to take as parameters the >> >> PSSCR value and the PSSCR mask corresponding to the stop state that >> >> needs to be set. These PSSCR value and mask are respectively obtained >> >> by parsing the "ibm,cpu-idle-state-psscr" and >> >> "ibm,cpu-idle-state-psscr-mask" fields from the device tree. >> >> >> >> In addition to this, the patch adds support for handling stop states >> >> for which ESL and EC bits in the PSSCR are zero. As per the >> >> architecture, a wakeup from these stop states resumes execution from >> >> the subsequent instruction as opposed to waking up at the System >> >> Vector. >> > >> > That looks good. >> > >> >> This patch depends on the following skiboot patch that exports the >> >> PSSCR values and the mask for all the stop states: >> >> https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html >> > >> > But we can't depend on a skiboot patch. The kernel has to cope with >> > running on an old skiboot. >> > > Hmm.. We can still do that. The older skiboot only provides the RL > field of the PSSCR value for each stop state and the corresponding > PSSCR mask is set to 0xF in the older skiboot for all the stop states. > > We can insist that the future skiboot sets the ESL, EC, PSLL, TR, MTL > and the the RL fields of the PSSCR for any exported stop state. This > should be reflected in the psscr_mask of that stop state. Thus, the > psscr_mask of any stop state proposed in the future will have: > (PSSCR_ESL_MASK | PSCCR_EC_MASK | PSCCR_PSLL_MASK | PSSCR_TR_MASK | > PSSCR_MTL_MASK | PSSCR_RL_MASK) bits set in the skiboot. > > To handle the older firmware, we can do something like the following > during the discovery of the stop states to mimic the behaviour present > in the 4.8 kernel running on older firmware. > > =============== drivers/cpuidle/cpuidle-powernv.c ======================= > /* > * By default we set the ESL and EC bits in the PSSCR. > * The MTL and PSLL are set to the maximum value possible as per the > * ISA, i.e 15. > * The Transition Rate is set to the Maximum value 3. > */ > #define DEFAULT_PSSCR_VAL PSSCR_ESL_MASK | \ > PSCCR_EC_MASK | PSCCR_PSLL_MASK |\ > PSSCR_TR_MASK | PSSCR_MTL_MASK > > #define DEFAULT_PSSCR_MASK PSSCR_ESL_MASK | \ > PSCCR_EC_MASK | PSCCR_PSLL_MASK |\ > PSSCR_TR_MASK | PSSCR_MTL_MASK | \ > PSSCR_RL_MASK > > > static int powernv_add_idle_states(void) > { > . > . > . > for (i = 0; i < dt_idle_states; i++) { > u64 val, mask; > . > . > . > val = (DEFAULT_PSSCR_VAL & ~psscr_mask[i]) | psscr_val[i]; > mask = DEFAULT_PSSCR_MASK | psscr_mask[i]; > stop_psscr_table[nr_idle_states].val = val; > stop_psscr_table[nr_idle_states].mask = mask; > } > } > ============================================================================ > > > Is this approach ok ? What if we just treat the 0xF state from firmware as special and set it to DEFAULT_PSSCR_MASK in that case? That deals with old skiboot, new kernel, and sets a pretty small special case that's easy to track into the future as something we should watch out for. Additionally, if we make skiboot set sane values in ~DEFAULT_PSSCR_MASK for valid fields in PSSCR on boot/(also kexec?), then we should end up in a situation where everything works with everything (even if you don't get the best power saving). Specifically, new skiboot, old kernel... but it looks like there's nothing currently missing there Should this patch also have Fixes: 3005c597ba4 and CC to stable? -- Stewart Smith OPAL Architect, IBM.