Hi Akhil, Actually, this provides custom events for governors, with different behaviors per each governor, while Matthias's give you the effects not targeted for a specific governor. Could you please show me why (the usage cases) you need this additional event for governors? (You need to implement an event handler in each governor for this approach). Cheers, MyungJoo On Fri, Jun 1, 2018 at 8:43 PM, Akhil P Oommen <akhilpo@xxxxxxxxxxxxxx> wrote: > > > 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@xxxxxxxxxxxxxx> >>> --- >>> 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. -- MyungJoo Ham, Ph.D. S/W Center, Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
