linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Collins <collinsd@codeaurora.org>
To: Rajendra Nayak <rnayak@codeaurora.org>,
	viresh.kumar@linaro.org, sboyd@kernel.org, andy.gross@linaro.org,
	ulf.hansson@linaro.org
Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver
Date: Thu, 14 Jun 2018 11:17:35 -0700	[thread overview]
Message-ID: <bd8999bd-a3ae-b7e2-a805-b31d38571ec6@codeaurora.org> (raw)
In-Reply-To: <f6b166ee-538f-c8b7-3be5-57c20a599d47@codeaurora.org>

Hello Rajendra,

On 06/13/2018 11:54 PM, Rajendra Nayak wrote:
> On 06/14/2018 06:02 AM, David Collins wrote:
>> On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
...
>>> +static int rpmhpd_power_off(struct generic_pm_domain *domain)
>>> +{
>>> +	struct rpmhpd *pd = domain_to_rpmhpd(domain);
>>> +	int ret = 0;
>>> +
>>> +	mutex_lock(&rpmhpd_lock);
>>> +
>>> +	if (pd->level[0] == 0)
>>> +		ret = rpmhpd_aggregate_corner(pd, 0);
>>
>> I'm not sure that we want to have the 'pd->level[0] == 0' check,
>> especially when considering aggregation with the peer pd.  I understand
>> its intention to try to keep enable state and level setting orthogonal.
>> However, as it stands now, the final request sent to hardware would differ
>> depending upon the order of calls.  Consider the following example.
>>
>> Initial state:
>> pd->level[0] == 0
>> pd->corner = 5, pd->enabled = true, pd->active_only = false
>> pd->peer->corner = 7, pd->peer->enabled = true, pd->peer->active_only = true
>>
>> Outstanding requests:
>> RPMH_ACTIVE_ONLY_STATE = 7, RPMH_WAKE_ONLY_STATE = 7, RPMH_SLEEP_STATE = 5
>>
>> Case A:
>> 	1. set pd->corner = 6
>> 		--> new value request: RPMH_SLEEP_STATE = 6
>> 		--> duplicate value requests: RPMH_ACTIVE_ONLY_STATE = 7,
>> 			RPMH_WAKE_ONLY_STATE = 7
>> 	2. power_off pd->peer
>> 		--> no requests
> 
> I am not sure why there would be no requests, since we do end up aggregating
> with pd->peer->corner = 0.
> So the final state would be
> 
> RPMH_ACTIVE_ONLY_STATE = max(6, 0) = 6
> RPMH_WAKE_ONLY_STATE = 6
> RPMH_SLEEP_STATE = max(6, 0) = 6

Argh, my example was ruined by a one character typo.  I meant to have:

	Initial state:
	pd->level[0] != 0


>>
>> 	Final state:
>> 	RPMH_ACTIVE_ONLY_STATE = 7
>> 	RPMH_WAKE_ONLY_STATE = 7
>> 	RPMH_SLEEP_STATE = 6
>>
>> Case B:
>> 	1. power_off pd->peer
>> 		--> no requests
> 
> Here it would be again be aggregation based on pd->peer->corner = 0
> so,
> RPMH_ACTIVE_ONLY_STATE = max(5, 0) = 5
> RPMH_WAKE_ONLY_STATE = 5
> RPMH_SLEEP_STATE = max(5, 0) = 5
> 
>> 	2. set pd->corner = 6
>> 		--> new value requests: RPMH_ACTIVE_ONLY_STATE = 6,
>> 		       RPMH_WAKE_ONLY_STATE = 6, RPMH_SLEEP_STATE = 6
>>
>> 	Final state:
>> 	RPMH_ACTIVE_ONLY_STATE = 6
>> 	RPMH_WAKE_ONLY_STATE = 6
>> 	RPMH_SLEEP_STATE = 6
> 
> correct,
> RPMH_ACTIVE_ONLY_STATE = max(6, 0) = 6
> RPMH_WAKE_ONLY_STATE = 6
> RPMH_SLEEP_STATE = max(6, 0) = 6
> 
>>
>> Without the check, Linux would vote for the lowest supported level when
>> power_off is called.  This seems semantically reasonable given that the
>> consumer is ok with the power domain going fully off and that would be the
>> closest that we can get.
> 
> So are you suggesting I replace
> 
>>> +	if (pd->level[0] == 0)
>>> +		ret = rpmhpd_aggregate_corner(pd, 0);
> 
> with
> 
>>> +	ret = rpmhpd_aggregate_corner(pd, pd->level[0]);

Yes, this is the modification that I'm requesting.


> I can see what you said above makes sense but if its
>> Initial state:
>> pd->level[0] != 0
> 
> Was that what you meant?

Yes.


> I can't seem to see any ARC resources on 845 which seem to 
> have a 'pd->level[0] != 0' but looks like thats certainly a
> possibility we need to handle?

The command DB interface for ARC resources was designed to support the
situation of a power domain that could not be fully disabled and is
instead limited to some minimum level.

Thanks,
David

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

  reply	other threads:[~2018-06-14 18:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12  4:40 [PATCH v3 0/7] Add powerdomain driver for corners on msm8996/sdm845 Rajendra Nayak
2018-06-12  4:40 ` [PATCH v3 1/7] dt-bindings: power: Add qcom rpm power domain driver bindings Rajendra Nayak
2018-06-12  4:40 ` [PATCH v3 2/7] soc: qcom: rpmpd: Add a Power domain driver to model corners Rajendra Nayak
2018-06-12  7:39   ` Ulf Hansson
2018-06-25 17:15   ` Rob Herring
2018-06-12  4:40 ` [PATCH v3 3/7] soc: qcom: rpmpd: Add support for get/set performance state Rajendra Nayak
2018-06-12  4:40 ` [PATCH v3 4/7] arm64: dts: msm8996: Add rpmpd device node Rajendra Nayak
2018-06-12  4:40 ` [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings Rajendra Nayak
2018-06-12  5:39   ` Bjorn Andersson
2018-06-12  6:40     ` Rajendra Nayak
2018-06-13 22:12   ` David Collins
2018-06-14  6:26     ` Rajendra Nayak
2018-06-19  9:59       ` Viresh Kumar
2018-06-12  4:40 ` [PATCH v3 6/7] soc: qcom: Add RPMh Power domain driver Rajendra Nayak
2018-06-12  7:46   ` Ulf Hansson
2018-06-12 19:06   ` Rob Herring
2018-06-13  3:25     ` Rajendra Nayak
2018-06-12 19:42   ` Matthias Kaehlcke
2018-06-13  3:30     ` Rajendra Nayak
2018-06-14  0:32   ` David Collins
2018-06-14  6:54     ` Rajendra Nayak
2018-06-14 18:17       ` David Collins [this message]
2018-06-15  9:25         ` Ulf Hansson
2018-06-15 21:46           ` David Collins
2018-06-16 12:13             ` Ulf Hansson
2018-06-12  4:40 ` [PATCH v3 7/7] soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init Rajendra Nayak
2018-06-13 22:28   ` David Collins
2018-06-14  6:35     ` Rajendra Nayak
2018-06-19 10:10       ` Viresh Kumar
2018-06-25  8:57         ` Ulf Hansson
2018-06-25 10:10           ` Rajendra Nayak
2018-06-12  7:47 ` [PATCH v3 0/7] Add powerdomain driver for corners on msm8996/sdm845 Ulf Hansson

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=bd8999bd-a3ae-b7e2-a805-b31d38571ec6@codeaurora.org \
    --to=collinsd@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=viresh.kumar@linaro.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).