Linux Power Management development
 help / color / mirror / Atom feed
From: Akhil P Oommen <akhilpo@codeaurora.org>
To: myungjoo.ham@samsung.com,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mka@chromium.org" <mka@chromium.org>
Cc: "jcrouse@codeaurora.org" <jcrouse@codeaurora.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [RFC] PM / devfreq: Add support for alerts
Date: Fri, 1 Jun 2018 17:13:47 +0530	[thread overview]
Message-ID: <f099a5b1-bd4e-d888-92c1-7366820881e8@codeaurora.org> (raw)
In-Reply-To: <20180531061720epcms1p31f5451bcf3150a7dddd33e1e415bb730@epcms1p3>



On 5/31/2018 11:47 AM, MyungJoo Ham wrote:
>> Currently, DEVFREQ reevaluates the device state periodically and/or
>> based on the OPP list changes. Private API has to be exposed to allow
>> the device driver to alert/notify the governor to reevaluate when a new
>> set of data is available. This makes the governor more coupled to a
>> particular device driver. We can improve here by exposing a DEVFREQ API
>> to allow the device drivers to send generic alerts to the governor.
>>
>> Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
>> ---
>>   drivers/devfreq/devfreq.c  | 21 +++++++++++++++++++++
>>   drivers/devfreq/governor.h |  1 +
>>   include/linux/devfreq.h    |  5 +++++
>>   3 files changed, 27 insertions(+)
>>
> Hello Akhil,
>
> It appears that this will have the same effect with
> "[PATCH 08/11] PM / devfreq: Make update_devfreq() public" from Matthias Kaehlcke, doesn't it?
>
>
> Cheers,
> MyungJoo
>
Hi MyngJoo,

The patch you mentioned is a step in the right direction. But this patch 
allows:
1. the governor to decide whether to reevaluate or not. I feel it would 
be a better architecture (better Separation of Concern) if that decision 
is left to the governor alone.
2. the devices to share multiple types of alerts. A governor may use 
these alerts for internal bookkeeping/algorithm and decide to reevaluate 
policy when it is necessary. Since we are opening up a new devfreq API 
for devices, isn't it better to go for a generic one?

Regards,
Akhil.

  reply	other threads:[~2018-06-01 11:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180531053717epcas5p48e0d962e2108d04529b4582a70cd7d5a@epcms1p3>
2018-05-31  5:36 ` [RFC] PM / devfreq: Add support for alerts Akhil P Oommen
2018-05-31  6:17   ` MyungJoo Ham
2018-06-01 11:43     ` Akhil P Oommen [this message]
2018-06-04 13:24       ` MyungJoo Ham

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=f099a5b1-bd4e-d888-92c1-7366820881e8@codeaurora.org \
    --to=akhilpo@codeaurora.org \
    --cc=cw00.choi@samsung.com \
    --cc=jcrouse@codeaurora.org \
    --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=mka@chromium.org \
    --cc=myungjoo.ham@samsung.com \
    /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