devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Asutosh Das (asd)" <asutoshd@codeaurora.org>
To: Rob Herring <robh@kernel.org>
Cc: Subhash Jadavani <subhashj@codeaurora.org>,
	Can Guo <cang@codeaurora.org>,
	Vivek Gautam <vivek.gautam@codeaurora.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Vinayak Holikatti <vinholikatti@gmail.com>,
	"James E.J. Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Venkat Gopalakrishnan <venkatg@codeaurora.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Malaterre <malat@debian.org>,
	devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level
Date: Tue, 24 Jul 2018 09:04:34 +0530	[thread overview]
Message-ID: <f1d3af9d-3ff0-c15b-013d-013ba6dde287@codeaurora.org> (raw)
In-Reply-To: <CAL_JsqLXUvUj8n=1Xv-_ssqB6rayMvxOTnGzeN1vS9yx4-jqOQ@mail.gmail.com>

On 7/23/2018 8:06 PM, Rob Herring wrote:
> On Sun, Jul 22, 2018 at 9:20 PM Asutosh Das (asd)
> <asutoshd@codeaurora.org> 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 <subhashj@codeaurora.org>
>>>>
>>>> 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 <subhashj@codeaurora.org>
>>>> Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
>>>> Signed-off-by: Can Guo <cang@codeaurora.org>
>>>> Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
>>>> ---
>>>>    .../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
> 

Ok - Thanks.
I'm gonna make the following changes in v2:
1. Remove these entries from DT
2. Add support for these entries in sysfs.
3. Keep 3 as the default value for [rpm/spm]-levels

-asd

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

      reply	other threads:[~2018-07-24  3:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1530880006.git.asutoshd@codeaurora.org>
2018-07-06 12:30 ` [PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level Asutosh Das
2018-07-11 10:50   ` Adrian Hunter
2018-07-23  3:09     ` Asutosh Das (asd)
2018-07-11 20:33   ` Rob Herring
2018-07-23  3:20     ` Asutosh Das (asd)
2018-07-23 14:36       ` Rob Herring
2018-07-24  3:34         ` Asutosh Das (asd) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f1d3af9d-3ff0-c15b-013d-013ba6dde287@codeaurora.org \
    --to=asutoshd@codeaurora.org \
    --cc=cang@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=malat@debian.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.petersen@oracle.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh@kernel.org \
    --cc=subhashj@codeaurora.org \
    --cc=venkatg@codeaurora.org \
    --cc=vinholikatti@gmail.com \
    --cc=vivek.gautam@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).