From: Chanwoo Choi <cw00.choi@samsung.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>
Cc: 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-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Vivek Gautam <vivek.gautam@codeaurora.org>
Subject: Re: [PATCH 1/3] PM / devfreq: Actually support providing freq_table
Date: Tue, 24 Apr 2018 11:48:06 +0900 [thread overview]
Message-ID: <5ADE9AE6.9090601@samsung.com> (raw)
In-Reply-To: <20180424002016.9205-2-bjorn.andersson@linaro.org>
Hi,
On 2018년 04월 24일 09:20, Bjorn Andersson wrote:
> The code in devfreq_add_device() handles the case where a freq_table is
> passed by the client, but then requests min and max frequences from
> the, in this case absent, opp tables.
>
> Read the min and max frequencies from the frequency table, which has
> been built from the opp table if one exists, instead of querying the
> opp table.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> An alternative approach is to clarify in the devfreq code that it's not
> possible to pass a freq_table and then in patch 3 create an opp table for the
> device in runtime; although the error handling of this becomes non-trivial.
>
> Transitioning the UFSHCD to use opp tables directly is hindered by the fact
> that the Qualcomm UFS hardware has two different clocks that needs to be
> running at different rates, so we would need a way to describe the two rates in
> the opp table. (And would force us to change the DT binding)
>
> drivers/devfreq/devfreq.c | 22 ++++------------------
> 1 file changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index fe2af6aa88fc..086ced50a13d 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -74,30 +74,16 @@ static struct devfreq *find_device_devfreq(struct device *dev)
>
> static unsigned long find_available_min_freq(struct devfreq *devfreq)
> {
> - struct dev_pm_opp *opp;
> - unsigned long min_freq = 0;
> -
> - opp = dev_pm_opp_find_freq_ceil(devfreq->dev.parent, &min_freq);
> - if (IS_ERR(opp))
> - min_freq = 0;
> - else
> - dev_pm_opp_put(opp);
> + struct devfreq_dev_profile *profile = devfreq->profile;
>
> - return min_freq;
> + return profile->freq_table[0];
It is wrong. The thermal framework support the devfreq-cooling device
which uses the dev_pm_opp_enable/disable().
In order to find the correct available min frequency,
the devfreq have to use the OPP function instead of using the first entry
of the freq_table array.
> }
>
> static unsigned long find_available_max_freq(struct devfreq *devfreq)
> {
> - struct dev_pm_opp *opp;
> - unsigned long max_freq = ULONG_MAX;
> -
> - opp = dev_pm_opp_find_freq_floor(devfreq->dev.parent, &max_freq);
> - if (IS_ERR(opp))
> - max_freq = 0;
> - else
> - dev_pm_opp_put(opp);
> + struct devfreq_dev_profile *profile = devfreq->profile;
>
> - return max_freq;
> + return profile->freq_table[profile->max_state - 1];
> }
ditto.
>
> /**
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2018-04-24 2:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 0:20 [PATCH 0/3] Fix UFS and devfreq interaction Bjorn Andersson
2018-04-24 0:20 ` [PATCH 1/3] PM / devfreq: Actually support providing freq_table Bjorn Andersson
2018-04-24 2:48 ` Chanwoo Choi [this message]
2018-04-24 5:29 ` Bjorn Andersson
2018-04-24 6:09 ` MyungJoo Ham
2018-04-24 18:48 ` Bjorn Andersson
2018-04-24 7:26 ` Chanwoo Choi
2018-04-24 18:38 ` Bjorn Andersson
2018-04-24 0:20 ` [PATCH 2/3] scsi: ufs: Extract devfreq registration Bjorn Andersson
2018-04-24 21:08 ` Subhash Jadavani
2018-04-24 0:20 ` [PATCH 3/3] scsi: ufs: Use freq table with devfreq Bjorn Andersson
2018-04-24 22:08 ` Subhash Jadavani
2018-04-24 22:14 ` Bjorn Andersson
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=5ADE9AE6.9090601@samsung.com \
--to=cw00.choi@samsung.com \
--cc=bjorn.andersson@linaro.org \
--cc=jejb@linux.vnet.ibm.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=myungjoo.ham@samsung.com \
--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).