Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5882239imm; Mon, 23 Jul 2018 07:40:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeIXPn5+ywx8gcZn0R4F4sfQ9jNyMON9SVnJ8NBOoP8dr1Tqsewm0QJRZzK9oStEWd5tC9i X-Received: by 2002:a63:ec14:: with SMTP id j20-v6mr12317943pgh.28.1532356815737; Mon, 23 Jul 2018 07:40:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532356815; cv=none; d=google.com; s=arc-20160816; b=OIDHyOKKM1jjTGw/UFiFdS2J1iBE14zYtn5W3s5UsMjr+SYGpA/nR8lmQ85OgNB+c8 kHE66KJeO85O9k09ZYCRV0b2xHthtI7Md0iyqmzReJaqvY5+PKboQK6MenLeLKcuvJsw +Vg/ZuQHMs5J+8NZGo72L9ewCDoGOeIAJvKPwDehkv1aeGcTGucZYr0WObjgSl7IYVAC DVbf8SM4o2MvdXADgmanjNliITWh0vcLJ3FhuraEHb52ZcEEPWOimlPEVqBn5+lD+0A4 dlfopEtLtx0uidvhhWIlRwRBgj2JYoSAyPuHup8UquqjTWSs8SFBIWotf0BT5esWudBw Rl1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=DRX1p7RhR505p9ZssNdrBpQnajl1KLith8JP21raWmI=; b=OsGBHry4kSahaejcwfK6nomW/Zpeg62ucIaH4vlaxVY4+Lsf+fDLJNfghkqGuIsMY9 D04EVOPZ9EBJcGXNMhaA37Ihi0+ABwfEX/pSyBjXYTastTtOOcRutEjw9ZVJj+FzGrpY feXYQJCNQpjiSL0VZugH8roYHjljSUL2HJXe8VG+E3WsqD/r4V1nRRHzVdiSdHuOHhF5 z7IQ52dSPG5LzsYyGLOjkHozu4Rf+o77mnpvbOI3cPoreqF8srZvAbc6r7SCfOSgUNMC HL8cdFG4dD+eqkl7iu/uRSnm7MhIN0/CF+yQpMGYWVPuN043lGaNvHaiTkk2rSYD21mm nxpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0Sal2WlJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3-v6si8543681plb.246.2018.07.23.07.40.00; Mon, 23 Jul 2018 07:40:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0Sal2WlJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388552AbeGWPie (ORCPT + 99 others); Mon, 23 Jul 2018 11:38:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:37650 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387877AbeGWPid (ORCPT ); Mon, 23 Jul 2018 11:38:33 -0400 Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A97420882; Mon, 23 Jul 2018 14:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532356620; bh=BrlHw/MuIvccOi5JajEX9n2D3npeFiJeki0tPtugQMk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0Sal2WlJcohlt2siRYC4oi5G95AHISHCcxp6WlowbcIVgL6/lU21bUkwodKWYWRPO /NlCZsv8T54LVq9108Be1/qZhbkZub97z+tg9hZjDO21DauaCXv8t2kPna1GZdO1vI YWAhFdbG+/OePigtLn3Iw1F6zRmU0RPnQqeNzXNg= Received: by mail-qt0-f173.google.com with SMTP id c15-v6so825932qtp.0; Mon, 23 Jul 2018 07:37:00 -0700 (PDT) X-Gm-Message-State: AOUpUlGUORygnrFLRroCpn91b1LVDRmCOCUBKnoYInv1f1TUxXMgeZxk ynRi+vZZ+9H8ajko4qx2l9TCi/eKGnC7j3QJ3w== X-Received: by 2002:a0c:98a4:: with SMTP id f33-v6mr11299974qvd.81.1532356619639; Mon, 23 Jul 2018 07:36:59 -0700 (PDT) MIME-Version: 1.0 References: <20180711203317.GA14983@rob-hp-laptop> <4b85de8b-d03e-da93-704b-e70922a9fbea@codeaurora.org> In-Reply-To: <4b85de8b-d03e-da93-704b-e70922a9fbea@codeaurora.org> From: Rob Herring Date: Mon, 23 Jul 2018 08:36:48 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level To: Asutosh Das Cc: Subhash Jadavani , Can Guo , Vivek Gautam , Rajendra Nayak , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , linux-scsi@vger.kernel.org, linux-arm-msm , Venkat Gopalakrishnan , Mark Rutland , Mathieu Malaterre , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 22, 2018 at 9:20 PM Asutosh Das (asd) wrote: > > On 7/12/2018 2:03 AM, Rob Herring wrote: > > On Fri, Jul 06, 2018 at 06:00:31PM +0530, Asutosh Das wrote: > >> From: Subhash Jadavani > >> > >> UFS device and link can be put in multiple different low power modes hence > >> UFS driver supports multiple different low power modes. By default UFS > >> driver selects the default (optimal) low power mode (which gives moderate > >> power savings and have relatively less enter and exit latencies) but > >> we might have to tune this default power mode for different chipset > >> platforms to meet the low power requirements/goals. Hence this patch > >> adds option to change default UFS low power mode (level). > >> > >> Signed-off-by: Subhash Jadavani > >> Signed-off-by: Venkat Gopalakrishnan > >> Signed-off-by: Can Guo > >> Signed-off-by: Asutosh Das > >> --- > >> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 11 ++++++++ > >> drivers/scsi/ufs/ufshcd-pltfrm.c | 14 +++++++++++ > >> drivers/scsi/ufs/ufshcd.c | 29 +++++++++++++++------- > >> drivers/scsi/ufs/ufshcd.h | 4 +-- > >> 4 files changed, 47 insertions(+), 11 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > >> index c39dfef..f564d9a 100644 > >> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > >> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt > >> @@ -38,6 +38,15 @@ Optional properties: > >> defined or a value in the array is "0" then it is assumed > >> that the frequency is set by the parent clock or a > >> fixed rate clock source. > >> +- rpm-level : UFS Runtime power management level. Following PM levels are supported: > >> + 0 - Both UFS device and Link in active state (Highest power consumption) > >> + 1 - UFS device in active state but Link in Hibern8 state > >> + 2 - UFS device in Sleep state but Link in active state > >> + 3 - UFS device in Sleep state and Link in hibern8 state (default PM level) > >> + 4 - UFS device in Power-down state and Link in Hibern8 state > >> + 5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption) > >> +- spm-level : UFS System power management level. Allowed PM levels are same as rpm-level. > > > > What's the default? > > > > I assume these are minimums? The OS can pick higher power states. This > > seems to be a bit Linux specific (as 'runtime PM' could be considered > > Linux specific). For every other device, we don't put this type of > > information in DT, but is user controlled. > I didn't completely understand your comment. > Do you not want these properties to be in DT file? Right, not if it is a user decision. > When you say user-controlled, do you mean control it through sysfs entries? Yes. > > So really, wouldn't 1 > > property be sufficient for cases where a mode doesn't work due to > > some h/w limitation. Otherwise, it is an OS or user decision. > I didn't completely understand this. Could you please elaborate on your > intent here? The case that makes sense for this to be in DT is if there are h/w limitations that prevent some low power modes. In such a case, that limit is not likely specific to runtime PM or system suspend. > >> -lanes-per-direction : number of lanes available per direction - either 1 or 2. > >> Note that it is assume same number of lanes is used both > >> directions at once. If not specified, default is 2 lanes per direction. > >> @@ -66,4 +75,6 @@ Example: > >> freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; > >> phys = <&ufsphy1>; > >> phy-names = "ufsphy"; > >> + rpm-level = <3>; > > > > Why specified if 3 is the default? > Ah yes - that should be removed. > I'll remove it in v2. > > > > >> + spm-level = <5>; > > > > These seem like sane defaults. When and why would you use some > > different? > I think each of the deeper sleep modes are associated with an increasing > wakeup latency. For e.g. '0' would have the highest power-consumption > and no resume latency at all as compared to '5'. > So depending on use-cases other modes may be chosen. The use-case can change in a running system. For example if you are plugged in, then you probably don't want to enter a lower power mode. Rob