lkml.org 
[lkml]   [2018]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] PM / devfreq: Add support for alerts
From
Date


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.

\
 
 \ /
  Last update: 2018-06-01 13:44    [W:0.230 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site