All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	vireshk@kernel.org, rafael@kernel.org, daniel.lezcano@linaro.org,
	Dietmar.Eggemann@arm.com, amitk@kernel.org, rui.zhang@intel.com,
	myungjoo.ham@samsung.com, kyungmin.park@samsung.com
Subject: Re: [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into devfreq struct
Date: Thu, 11 Feb 2021 11:07:08 +0000	[thread overview]
Message-ID: <fe7763c8-22f7-65ad-94ee-3c4a78a3f6eb@arm.com> (raw)
In-Reply-To: <5bd13e13-202f-d059-da29-f82806c33a38@arm.com>

Hi Chanwoo,

On 2/3/21 10:21 AM, Lukasz Luba wrote:
> Hi Chanwoo,
> 
> Thank you for looking at this.
> 
> On 2/3/21 10:11 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> When accessing the max_freq and min_freq at devfreq-cooling.c,
>> even if can access 'user_max_freq' and 'lock' by using the 'devfreq' 
>> instance,
>> I think that the direct access of variables 
>> (lock/user_max_freq/user_min_freq)
>> of struct devfreq are not good.
>>
>> Instead, how about using the 'DEVFREQ_TRANSITION_NOTIFIER'
>> notification with following changes of 'struct devfreq_freq'?
> 
> I like the idea with devfreq notification. I will have to go through the
> code to check that possibility.
> 
>> Also, need to add codes into devfreq_set_target() for initializing
>> 'new_max_freq' and 'new_min_freq' before sending the DEVFREQ_POSTCHANGE
>> notification.
>>
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index 147a229056d2..d5726592d362 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -207,6 +207,8 @@ struct devfreq {
>>   struct devfreq_freqs {
>>          unsigned long old;
>>          unsigned long new;
>> +       unsigned long new_max_freq;
>> +       unsigned long new_min_freq;
>>   };
>>
>>
>> And I think that new 'user_min_freq'/'user_max_freq' are not necessary.
>> You can get the current max_freq/min_freq by using the following steps:
>>
>>     get_freq_range(devfreq, &min_freq, &max_freq);
>>     dev_pm_opp_find_freq_floor(pdev, &min_freq);
>>     dev_pm_opp_find_freq_floor(pdev, &max_freq);
>>
>> So that you can get the 'max_freq/min_freq' and then
>> initialize the 'freqs.new_max_freq and freqs.new_min_freq'
>> with them as following:
>>
>> in devfreq_set_target()
>>     get_freq_range(devfreq, &min_freq, &max_freq);
>>     dev_pm_opp_find_freq_floor(pdev, &min_freq);
>>     dev_pm_opp_find_freq_floor(pdev, &max_freq);
>>     freqs.new_max_freq = min_freq;
>>     freqs.new_max_freq = max_freq;
>>     devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> 
> I will plumb it in and check that option. My concern is that function
> get_freq_range() would give me the max_freq value from PM QoS, which
> might be my thermal limit - lower that user_max_freq. Then I still
> need
> 
> I've been playing with PM QoS notifications because I thought it would
> be possible to be notified in thermal for all new set values - even from
> devfreq sysfs user max_freq write, which has value higher that the
> current limit set by thermal governor. Unfortunately PM QoS doesn't
> send that information by design. PM QoS also by desing won't allow
> me to check first two limits in the plist - which would be thermal
> and user sysfs max_freq.
> 
> I will experiment with this notifications and share the results.
> That you for your comments.

I have experimented with your proposal. Unfortunately, the value stored
in the pm_qos which is read by get_freq_range() is not the user max
freq. It's the value from thermal devfreq cooling when that one is
lower. Which is OK in the overall design, but not for my IPA use case.

What comes to my mind is two options:
1) this patch proposal, with simple solution of two new variables
protected by mutex, which would maintain user stored values
2) add a new notification chain in devfreq to notify about new
user written value, to which devfreq cooling would register; that
would allow devfreq cooling to get that value instantly and store
locally

What do you think Chanwoo?

Regards,
Lukasz

  reply	other threads:[~2021-02-11 11:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 10:39 [RFC][PATCH 0/3] New thermal interface allowing IPA to get max power Lukasz Luba
2021-01-26 10:39 ` [RFC][PATCH 1/3] PM /devfreq: add user frequency limits into devfreq struct Lukasz Luba
2021-02-03 10:11   ` Chanwoo Choi
2021-02-03 10:21     ` Lukasz Luba
2021-02-11 11:07       ` Lukasz Luba [this message]
2021-02-11 22:27         ` Lukasz Luba
2021-02-15 15:00           ` Chanwoo Choi
2021-02-16 10:41             ` Lukasz Luba
2021-02-24  8:04               ` Chanwoo Choi
2021-01-26 10:40 ` [RFC][PATCH 2/3] thermal: devfreq_cooling: add new callback to get user limit for min state Lukasz Luba
2021-01-26 10:40 ` [RFC][PATCH 3/3] thermal: power_allocator: get proper max power limited by user Lukasz Luba
2021-01-27  9:15 ` [RFC][PATCH 0/3] New thermal interface allowing IPA to get max power Viresh Kumar
2021-01-27 10:11   ` Lukasz Luba
2021-01-27 10:13     ` Viresh Kumar
2021-02-01 11:23 ` Lukasz Luba
2021-02-01 14:21   ` Daniel Lezcano
2021-02-01 16:37     ` Lukasz Luba
2021-02-02  9:31   ` Chanwoo Choi
2021-02-02  9:56     ` Lukasz Luba
2021-02-01 14:19 ` Rafael J. Wysocki
2021-02-01 16:37   ` Lukasz Luba
2021-02-22 10:22 ` Daniel Lezcano
2021-02-22 12:10   ` Lukasz Luba

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=fe7763c8-22f7-65ad-94ee-3c4a78a3f6eb@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=amitk@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=vireshk@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.